Re: WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
Robert Raszuk <[email protected]> Fri, 29 Nov 2019 10:34:26 +0100
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <CAOj+MMF5SXRuQ-KETkJMRQV4uu5LZyK75AKrKiUMEjpBA7d9ow@mail.gmail.com> |
--===============1907186676404201779== Content-Type: multipart/alternative; boundary="00000000000031f5c1059878f047" --00000000000031f5c1059878f047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunter, To your and Jeff's point regarding multiple redirect rules I have a bit different perspective. First let's observe that redirect could be realized in two forms (both are valid and used in practice): -A- redirect of the original flow -B- redirect of copy of the flow See while in -A- clearly one redirect must be used, in -B- on the other hand multiple redirects should be supported. One span, one security TAP, one TCP analyzer etc ... Your draft defines -A-. To add -B- all what is needed is just one bit flag. Would you consider it ? Cheers, R. On Fri, Nov 29, 2019 at 4:51 AM Van De Velde, Gunter (Nokia - BE/Antwerp) < [email protected]> wrote: > Hi Jeff, > > Thanks for the feedback and suggestions. > > See inline: *GV>* > > -----Original Message----- > From: Idr <[email protected]> On Behalf Of Jeffrey Haas > Sent: Thursday, November 28, 2019 20:21 > To: Sue Hares <[email protected]> > Cc: [email protected] > Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt > [11/17/2019 to 12/2/2019] > > Sue, > > > > > On Nov 18, 2019, at 12:41 AM, Susan Hares <[email protected]> wrote: > > > > This begins a 2 week WG Last call on > draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019]. > > > > You can obtain the draft at: > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ > > > > Consider in your review whether this draft: > > > > 1) Is compatible with draft-ietf-rfc5575bis-17.txt? > > Yes. (Close enough.) The current version of the draft is implementable. > > > 2) Whether the draft is useful for deployments of flow specificati= on > > It can be useful. > > > 3) Is this technology ready for deployment? > > 4) Is the write-up of this technology in > draft-ietf-idr-flowspec-path-redirect clearly written and ready for > publication? > > Ready with minor issues, IMO: > > Procedure-wise, there needs to be a bit more text covering cases about > interactions with other traffic actions. This was a known headache for > similar drafts such as redirect-to-ip. In particular, interaction with > redirect-to-ip and redirect-to-vrf is needed. > > GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D gives input on thi= s. We discussed > this with you long ago and hence this text was added. > > =E2=80=9C > While it MUST NOT happen, and is seen as invalid combination, it is > possible from a semantics perspective to have multiple clashing > redirect actions defined within a single flowspec rule. For best and > consistant compatibility with legacy implementations, the redirect > functionality as documented by rfc5575bis MUST NOT be broken, and > hence when a clash occurs, then rfc5575bis based redirect MUST take > priority. > =E2=80=9C > > This means that redirect-to-VRF will take absolute priority to not break > rfc5575bis behavior. > Having also redirect-to-ip will result in an invalid > > > The text "A single flowspec rule MUST NOT have more as one indirection-id > per S-ID. On a flowspec client the indirection-id with lowest S-ID MUST = be > imposed first for any given flowspec entry." There's no procedure for wh= at > happens in error handling when you do have more than one of the same S-ID= .. > The text about the case for S-ID of 0 is also a bit ambiguous. It feels > like it's reading "there is no sequence", but what do you do when you the= n > have ones that do? > > *GV>* What about the following rewrite: > > Original: > The 'S-ID' field identifies a 4 bit Sequence ID field. This field is > used to provide a flowspec client an indication how and where to > sequence the received indirection-ids. The Sequence ID value 0 > indicates that Sequence ID field is NOT set and SHOULD be ignored. A > single flowspec rule MUST NOT have more as one indirection-id per > S-ID. On a flowspec client the indirection-id with lowest S-ID MUST > be imposed first for any given flowspec entry. > > New: > The 'S-ID' field identifies a 4 bit Sequence ID field. This field is > used to provide a flowspec client an indication how and where to > sequence the received indirection-ids. The Sequence ID value 0 > indicates that Sequence ID field is NOT set and *****all** other > sequence ID's*** > SHOULD be ignored. A > single flowspec rule MUST NOT have more as one indirection-id per > S-ID. On a flowspec client the indirection-id with lowest S-ID MUST > be imposed first for any given flowspec entry. > > *GV>* In section *6. Validation procedure" there is text to handle the > error condition when the flowspec rule results in an invalid redirection, > that prescribe what needs to happen when the =E2=80=9Credirect to indirec= tion-id=E2=80=9D > does not result in a valid redirection: > > " > While it MUST NOT happen, and is seen as invalid combination, it is > possible from a semantics perspective to have multiple clashing > redirect actions defined within a single flowspec rule. For best and > consistant compatibility with legacy implementations, the redirect > * functionality as documented by rfc5575bis MUST NOT be broken*, and > hence when a clash occurs, then *rfc5575bis based redirect MUST take* > * priority*. Additionally, if the "Redirect to indirection-id" does no= t > result in a valid redirection, then the flowspec rule MUST be > processed as if the "Redirect to indirection-id" community was not > attached to the flowspec route. > " > > *GV>* Is there more to add to this? (We could add a line to detail that > =E2=80=9Credirect-to-ip=E2=80=9D is incompatible with =E2=80=9Credirect t= o indirection-id=E2=80=9D and > result in invalid redirection rule, however to me that is already implied > with enough detail in the text above) > > A few IANA issues: > I see the type registry is currently registered with IANA (code point > 0x09). However, the sub-type registry is not established for some reason= ? > The ID-Type field likely needs its own IANA registry. Values 1-5 are > defined in this draft. > > *GV>* Correct. There is a reason for this. When we asked IANA the > code-points they informed me that once the document get to RFC the sub-ty= pe > registry will be established by IANA. > > The flags field (one octet) currently has 3 bits reserved. In the past, > we've not done a registry for such cases (c.f. graceful restart) until we > need to start carving out those reserved bits for future extensions. I > leave it to the chairs' opinion whether we want this a priori or not. > > *G/* > > > > > > Thank you for considering this draft. > > > > Cheerily, Susan Hares > > > > _______________________________________________ > > Idr mailing list > > [email protected] > > https://www..ietf.org/mailman/listinfo/idr > <https://www.ietf.org/mailman/listinfo/idr> > > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf..org/mailman/listinfo/idr > <https://www.ietf.org/mailman/listinfo/idr> > > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr > --00000000000031f5c1059878f047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Gunter,<div><br></div><div>To your and Jeff's point re= garding multiple redirect rules I have a bit different perspective.=C2=A0</= div><div><br></div><div>First let's observe that redirect could be real= ized in two forms (both are valid and used in practice):=C2=A0</div><div><b= r></div><div>-A- redirect=C2=A0of the original flow=C2=A0</div><div>-B- red= irect of copy of the flow=C2=A0</div><div><br></div><div>See while in -A- c= learly one redirect must be used, in -B- on the other=C2=A0hand multiple re= directs should be supported. One span, one security TAP, one TCP analyzer e= tc ...=C2=A0</div><div><br></div><div>Your draft defines -A-. To add -B- al= l what is needed is just one bit flag.=C2=A0</div><div><br></div><div>Would= you consider it ?=C2=A0</div><div><br></div><div>Cheers,</div><div>R.</div= ><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div= class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 29= , 2019 at 4:51 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <<a href=3D"= mailto:[email protected]">[email protected]</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt"> <div>Hi Jeff,</div> <div>=C2=A0</div> <div>Thanks for the feedback and suggestions.</div> <div>=C2=A0</div> <div>See inline: <font color=3D"#4472C4"><b>GV></b></font></div> <a name=3D"m_-6399825029355686769__MailEndCompose"></a> <div>=C2=A0</div> <div>-----Original Message-----<br> From: Idr <<a href=3D"mailto:[email protected]" target=3D"_blank">idr= [email protected]</a>> On Behalf Of Jeffrey Haas<br> Sent: Thursday, November 28, 2019 20:21<br> To: Sue Hares <<a href=3D"mailto:[email protected]" target=3D"_blank">shar= [email protected]</a>><br> Cc: <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/1= 7/2019 to 12/2/2019]</div> <div>=C2=A0</div> <div>Sue,</div> <div>=C2=A0</div> <div>=C2=A0</div> <div>=C2=A0</div> <div>> On Nov 18, 2019, at 12:41 AM, Susan Hares <<a href=3D"mailto:s= [email protected]" target=3D"_blank">[email protected]</a>> wrote:</div> <div>> </div> <div>> This begins a 2 week WG Last call on draft-idr-flowspec-path-redi= rect-10.txt from [11/17/2019 to 12/2/2019]. </div> <div>>=C2=A0 </div> <div>> You can obtain the draft at:</div> <div>>=C2=A0 </div> <div>> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-idr-flowsp= ec-path-redirect/" target=3D"_blank">https://datatracker.ietf.org/doc/draft= -ietf-idr-flowspec-path-redirect/</a></div> <div>>=C2=A0 </div> <div>> Consider in your review whether this draft: </div> <div>>=C2=A0 </div> <div>> 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is compatible with draft-ietf-rf= c5575bis-17.txt? </div> <div>=C2=A0</div> <div>Yes.=C2=A0 (Close enough.)=C2=A0 The current version of the draft is i= mplementable.</div> <div>=C2=A0</div> <div>> 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Whether the draft is useful for = deployments of flow specification</div> <div>=C2=A0</div> <div>It can be useful.</div> <div>=C2=A0</div> <div>> 3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this technology ready for dep= loyment? </div> <div>> 4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the write-up of this technolo= gy in draft-ietf-idr-flowspec-path-redirect clearly written and ready for p= ublication? </div> <div>=C2=A0</div> <div>Ready with minor issues, IMO:</div> <div>=C2=A0</div> <div>Procedure-wise, there needs to be a bit more text covering cases about= interactions with other traffic actions.=C2=A0 This was a known headache f= or similar drafts such as redirect-to-ip.=C2=A0 In particular, interaction = with redirect-to-ip and redirect-to-vrf is needed.</div> <div>=C2=A0</div> <div>GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D gives input = on this. We discussed this with you long ago and hence this text was added.= </div> <div>=C2=A0</div> <div>=E2=80=9C</div> <div>=C2=A0=C2=A0 While it MUST NOT happen, and is seen as invalid combinat= ion, it is</div> <div>=C2=A0=C2=A0 possible from a semantics perspective to have multiple cl= ashing</div> <div>=C2=A0=C2=A0 redirect actions defined within a single flowspec rule.= =C2=A0 For best and</div> <div>=C2=A0=C2=A0 consistant compatibility with legacy implementations, the= redirect</div> <div>=C2=A0=C2=A0 functionality as documented by rfc5575bis MUST NOT be bro= ken, and</div> <div>=C2=A0=C2=A0 hence when a clash occurs, then rfc5575bis based redirect= MUST take</div> <div>=C2=A0=C2=A0 priority. </div> <div>=E2=80=9C</div> <div>=C2=A0</div> <div>This means that redirect-to-VRF will take absolute priority to not bre= ak rfc5575bis behavior.</div> <div>Having also redirect-to-ip will result in an invalid </div> <div>=C2=A0</div> <div>=C2=A0</div> <div>The text "A single flowspec rule MUST NOT have more as one indire= ction-id per S-ID.=C2=A0 On a flowspec client the indirection-id with lowes= t S-ID MUST be imposed first for any given flowspec entry."=C2=A0 Ther= e's no procedure for what happens in error handling when you do have more than one of the same S-ID.=C2=A0 The text about the c= ase for S-ID of 0 is also a bit ambiguous.=C2=A0 It feels like it's rea= ding "there is no sequence", but what do you do when you then hav= e ones that do?</div> <div>=C2=A0</div> <div><font color=3D"#4472C4"><b>GV></b> What about the following rewrite= :</font></div> <div><font color=3D"#4472C4">=C2=A0</font></div> <div><font color=3D"#4472C4">Original:</font></div> <div><font color=3D"#4472C4"> =C2=A0=C2=A0 The 'S-ID' field identif= ies a 4 bit Sequence ID field.=C2=A0 This field is</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 used to provide a flowspec client= an indication how and where to</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 sequence the received indirection= -ids.=C2=A0 The Sequence ID value 0</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 indicates that Sequence ID field = is NOT set and SHOULD be ignored.=C2=A0 A</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 single flowspec rule MUST NOT hav= e more as one indirection-id per</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 S-ID.=C2=A0 On a flowspec client = the indirection-id with lowest S-ID MUST</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 be imposed first for any given fl= owspec entry.</font></div> <div><font color=3D"#4472C4">=C2=A0</font></div> <div><font color=3D"#4472C4">New:</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 The 'S-ID' field identifi= es a 4 bit Sequence ID field.=C2=A0 This field is</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 used to provide a flowspec client= an indication how and where to</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 sequence the received indirection= -ids.=C2=A0 The Sequence ID value 0</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 indicates that Sequence ID field = is NOT set and <b>**</b><b>all</b><b> other sequence ID's**</b> </font>= </div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 SHOULD be ignored.=C2=A0 A</font>= </div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 single flowspec rule MUST NOT hav= e more as one indirection-id per</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 S-ID.=C2=A0 On a flowspec client = the indirection-id with lowest S-ID MUST</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 be imposed first for any given fl= owspec entry.</font></div> <div><font color=3D"#4472C4">=C2=A0</font></div> <div><font color=3D"#4472C4"><b>GV></b> In section *6. Validation proced= ure" there is text to handle the error condition when the flowspec rul= e results in an invalid redirection, that prescribe what needs to happen wh= en the =E2=80=9Credirect to indirection-id=E2=80=9D does not result in a valid redirection:</font></div> <div><font color=3D"#4472C4">=C2=A0</font></div> <div><font color=3D"#4472C4">"</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 While it MUST NOT happen, and is = seen as invalid combination, it is</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 possible from a semantics perspec= tive to have multiple clashing</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 redirect actions defined within a= single flowspec rule.=C2=A0 For best and</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 consistant compatibility with leg= acy implementations, the redirect</font></div> <div><font color=3D"#4472C4"><b>=C2=A0=C2=A0 functionality as documented by= rfc5575bis MUST NOT be broken</b>, and</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 hence when a clash occurs, then <= b>rfc5575bis based redirect MUST take</b></font></div> <div><font color=3D"#4472C4"><b>=C2=A0=C2=A0 priority</b>.=C2=A0 Additional= ly, if the "Redirect to indirection-id" does not</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 result in a valid redirection, th= en the flowspec rule MUST be</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 processed as if the "Redirec= t to indirection-id" community was not</font></div> <div><font color=3D"#4472C4">=C2=A0=C2=A0 attached to the flowspec route.</= font></div> <div><font color=3D"#4472C4">"</font></div> <div><font color=3D"#4472C4">=C2=A0</font></div> <div><font color=3D"#4472C4"><b>GV></b> Is there more to add to this? (W= e could add a line to detail that =E2=80=9Credirect-to-ip=E2=80=9D is incom= patible with =E2=80=9Credirect to indirection-id=E2=80=9D and result in inv= alid redirection rule, however to me that is already implied with enough detail in the text above)</font></div> <div>=C2=A0</div> <div>A few IANA issues:</div> <div>I see the type registry is currently registered with IANA (code point = 0x09).=C2=A0 However, the sub-type registry is not established for some rea= son?</div> <div>The ID-Type field likely needs its own IANA registry.=C2=A0 Values 1-5= are defined in this draft.</div> <div>=C2=A0</div> <div><font color=3D"#4472C4"><b>GV></b> Correct. There is a reason for t= his. When we asked IANA the code-points they informed me that once the docu= ment get to RFC the sub-type registry will be established by IANA. </font><= /div> <div>=C2=A0</div> <div>The flags field (one octet) currently has 3 bits reserved.=C2=A0 In th= e past, we've not done a registry for such cases (c.f. graceful restart= ) until we need to start carving out those reserved bits for future extensi= ons.=C2=A0 I leave it to the chairs' opinion whether we want this a priori or not.</div> <div>=C2=A0</div> <div><font color=3D"#4472C4"><b>G/</b></font></div> <div>=C2=A0</div> <div>=C2=A0</div> <div>>=C2=A0 </div> <div>> Thank you for considering this draft. </div> <div>>=C2=A0 </div> <div>> Cheerily, Susan Hares </div> <div>>=C2=A0 </div> <div>> _______________________________________________</div> <div>> Idr mailing list</div> <div>> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= ></div> <div>> <a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_= blank">https://www..ietf.org/mailman/listinfo/idr</a></div> <div>=C2=A0</div> <div>_______________________________________________</div> <div>Idr mailing list</div> <div><a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a></di= v> <div><a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_blank= ">https://www.ietf..org/mailman/listinfo/idr</a></div> <div>=C2=A0</div> </span></font> </div> _______________________________________________<br> Idr mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/idr" rel=3D"noreferrer" ta= rget=3D"_blank">https://www.ietf.org/mailman/listinfo/idr</a><br> </blockquote></div> --00000000000031f5c1059878f047-- --===============1907186676404201779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list [email protected] https://www.ietf.org/mailman/listinfo/idr --===============1907186676404201779==--