Re: WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
"Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email protected]> Fri, 29 Nov 2019 03:51:35 +0000
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com> |
--===============2169833428345733426== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM6PR07MB482356A327D714512EBAF2DBE0460AM6PR07MB4823eurp_" --_000_AM6PR07MB482356A327D714512EBAF2DBE0460AM6PR07MB4823eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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/1= 7/2019 to 12/2/2019] Sue, > On Nov 18, 2019, at 12:41 AM, Susan Hares <[email protected]<mailto:shares@= ndzh.com>> 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 specification It can be useful. > 3) Is this technology ready for deployment? > 4) Is the write-up of this technology in draft-ietf-idr-flowspec-pat= h-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 inte= ractions with other traffic actions. This was a known headache for similar= drafts such as redirect-to-ip. In particular, interaction with redirect-t= o-ip and redirect-to-vrf is needed. GV> Section "6. Validation Procedures" gives input on this. We discussed th= is with you long ago and hence this text was added. " 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. " This means that redirect-to-VRF will take absolute priority to not break rf= c5575bis 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 p= er 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 what= 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 then = 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 pr= escribe what needs to happen when the "redirect to indirection-id" 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 not 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 "redi= rect-to-ip" is incompatible with "redirect to indirection-id" and result in= invalid redirection rule, however to me that is already implied with enoug= h 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 defin= ed 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-type registry w= ill 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 nee= d 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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/idr --_000_AM6PR07MB482356A327D714512EBAF2DBE0460AM6PR07MB4823eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:= #800000 2px solid; } --></style> </head> <body> <font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;"> <div>Hi Jeff,</div> <div> </div> <div>Thanks for the feedback and suggestions.</div> <div> </div> <div>See inline: <font color=3D"#4472C4"><b>GV></b></font></div> <a name=3D"_MailEndCompose"></a> <div> </div> <div>-----Original Message-----<br> From: Idr <[email protected]> On Behalf Of Jeffrey Haas<br> Sent: Thursday, November 28, 2019 20:21<br> To: Sue Hares <[email protected]><br> Cc: [email protected]<br> Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/1= 7/2019 to 12/2/2019]</div> <div> </div> <div>Sue,</div> <div> </div> <div> </div> <div> </div> <div>> On Nov 18, 2019, at 12:41 AM, Susan Hares <<a href=3D"mailto:s= [email protected]">[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>> </div> <div>> You can obtain the draft at:</div> <div>> </div> <div>> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-idr-flowsp= ec-path-redirect/">https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec= -path-redirect/</a></div> <div>> </div> <div>> Consider in your review whether this draft: </div> <div>> </div> <div>> 1) Is compatible with draft-ietf-rf= c5575bis-17.txt? </div> <div> </div> <div>Yes. (Close enough.) The current version of the draft is i= mplementable.</div> <div> </div> <div>> 2) Whether the draft is useful for = deployments of flow specification</div> <div> </div> <div>It can be useful.</div> <div> </div> <div>> 3) Is this technology ready for dep= loyment? </div> <div>> 4) Is the write-up of this technolo= gy in draft-ietf-idr-flowspec-path-redirect clearly written and ready for p= ublication? </div> <div> </div> <div>Ready with minor issues, IMO:</div> <div> </div> <div>Procedure-wise, there needs to be a bit more text covering cases about= interactions with other traffic actions. This was a known headache f= or similar drafts such as redirect-to-ip. In particular, interaction = with redirect-to-ip and redirect-to-vrf is needed.</div> <div> </div> <div>GV> Section “6. Validation Procedures” gives input on t= his. We discussed this with you long ago and hence this text was added.</di= v> <div> </div> <div>“</div> <div> While it MUST NOT happen, and is seen as invalid combinat= ion, it is</div> <div> possible from a semantics perspective to have multiple cl= ashing</div> <div> redirect actions defined within a single flowspec rule.&n= bsp; For best and</div> <div> consistant compatibility with legacy implementations, the= redirect</div> <div> functionality as documented by rfc5575bis MUST NOT be bro= ken, and</div> <div> hence when a clash occurs, then rfc5575bis based redirect= MUST take</div> <div> priority. </div> <div>“</div> <div> </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> </div> <div> </div> <div>The text "A single flowspec rule MUST NOT have more as one indire= ction-id per S-ID. On a flowspec client the indirection-id with lowes= t S-ID MUST be imposed first for any given flowspec entry." Ther= e's no procedure for what happens in error handling when you do have more than one of the same S-ID. The text about the c= ase 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 then have on= es that do?</div> <div> </div> <div><font color=3D"#4472C4"><b>GV></b> What about the following rewrite= :</font></div> <div><font color=3D"#4472C4"> </font></div> <div><font color=3D"#4472C4">Original:</font></div> <div><font color=3D"#4472C4"> The 'S-ID' field identifies a 4 = bit Sequence ID field. This field is</font></div> <div><font color=3D"#4472C4"> used to provide a flowspec client= an indication how and where to</font></div> <div><font color=3D"#4472C4"> sequence the received indirection= -ids. The Sequence ID value 0</font></div> <div><font color=3D"#4472C4"> indicates that Sequence ID field = is NOT set and SHOULD be ignored. A</font></div> <div><font color=3D"#4472C4"> single flowspec rule MUST NOT hav= e more as one indirection-id per</font></div> <div><font color=3D"#4472C4"> S-ID. On a flowspec client = the indirection-id with lowest S-ID MUST</font></div> <div><font color=3D"#4472C4"> be imposed first for any given fl= owspec entry.</font></div> <div><font color=3D"#4472C4"> </font></div> <div><font color=3D"#4472C4">New:</font></div> <div><font color=3D"#4472C4"> The 'S-ID' field identifies a 4 b= it Sequence ID field. This field is</font></div> <div><font color=3D"#4472C4"> used to provide a flowspec client= an indication how and where to</font></div> <div><font color=3D"#4472C4"> sequence the received indirection= -ids. The Sequence ID value 0</font></div> <div><font color=3D"#4472C4"> indicates that Sequence ID field = is NOT set and <b>**</b><b>all</b><b> other sequence ID's**</b> </font></di= v> <div><font color=3D"#4472C4"> SHOULD be ignored. A</font>= </div> <div><font color=3D"#4472C4"> single flowspec rule MUST NOT hav= e more as one indirection-id per</font></div> <div><font color=3D"#4472C4"> S-ID. On a flowspec client = the indirection-id with lowest S-ID MUST</font></div> <div><font color=3D"#4472C4"> be imposed first for any given fl= owspec entry.</font></div> <div><font color=3D"#4472C4"> </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 “redirect to indirection-id” does not result in a valid redirection:</font></div> <div><font color=3D"#4472C4"> </font></div> <div><font color=3D"#4472C4">"</font></div> <div><font color=3D"#4472C4"> While it MUST NOT happen, and is = seen as invalid combination, it is</font></div> <div><font color=3D"#4472C4"> possible from a semantics perspec= tive to have multiple clashing</font></div> <div><font color=3D"#4472C4"> redirect actions defined within a= single flowspec rule. For best and</font></div> <div><font color=3D"#4472C4"> consistant compatibility with leg= acy implementations, the redirect</font></div> <div><font color=3D"#4472C4"><b> functionality as documented by= rfc5575bis MUST NOT be broken</b>, and</font></div> <div><font color=3D"#4472C4"> hence when a clash occurs, then <= b>rfc5575bis based redirect MUST take</b></font></div> <div><font color=3D"#4472C4"><b> priority</b>. Additional= ly, if the "Redirect to indirection-id" does not</font></div> <div><font color=3D"#4472C4"> result in a valid redirection, th= en the flowspec rule MUST be</font></div> <div><font color=3D"#4472C4"> processed as if the "Redirec= t to indirection-id" community was not</font></div> <div><font color=3D"#4472C4"> attached to the flowspec route.</= font></div> <div><font color=3D"#4472C4">"</font></div> <div><font color=3D"#4472C4"> </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 “redirect-to-ip” is incompati= ble with “redirect to indirection-id” and result in invalid red= irection rule, however to me that is already implied with enough detail in the text above)</font></div> <div> </div> <div>A few IANA issues:</div> <div>I see the type registry is currently registered with IANA (code point = 0x09). However, the sub-type registry is not established for some rea= son?</div> <div>The ID-Type field likely needs its own IANA registry. Values 1-5= are defined in this draft.</div> <div> </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> </div> <div>The flags field (one octet) currently has 3 bits reserved. In th= e past, we've not done a registry for such cases (c.f. graceful restart) un= til 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.</div> <div> </div> <div><font color=3D"#4472C4"><b>G/</b></font></div> <div> </div> <div> </div> <div>> </div> <div>> Thank you for considering this draft. </div> <div>> </div> <div>> Cheerily, Susan Hares </div> <div>> </div> <div>> _______________________________________________</div> <div>> Idr mailing list</div> <div>> <a href=3D"mailto:[email protected]">[email protected]</a></div> <div>> <a href=3D"https://www.ietf.org/mailman/listinfo/idr">https://www= ..ietf.org/mailman/listinfo/idr</a></div> <div> </div> <div>_______________________________________________</div> <div>Idr mailing list</div> <div><a href=3D"mailto:[email protected]">[email protected]</a></div> <div><a href=3D"https://www.ietf.org/mailman/listinfo/idr">https://www.ietf= ..org/mailman/listinfo/idr</a></div> <div> </div> </span></font> </body> </html> --_000_AM6PR07MB482356A327D714512EBAF2DBE0460AM6PR07MB4823eurp_-- --===============2169833428345733426== 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 --===============2169833428345733426==--