Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

[Gunter Van De Velde <[e-mail]>]

Hi Robert,


While understanding your point, it does feel like opening a potential can of worms with respect to validation of all possible combinations humanly possible. Is the use-case for this capability solid enough that we need this complication? There seems nothing broken with keeping things simple. 


G/


Sent from iCloud

On November 29, 2019 at 10:34 AM, Robert Raszuk <[e-mail]> wrote:


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) <[e-mail]> wrote:

Hi Jeff,
 
Thanks for the feedback and suggestions.
 
See inline: GV>
 
-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Jeffrey Haas
Sent: Thursday, November 28, 2019 20:21
To: Sue Hares <[e-mail]>
Cc: [e-mail]
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 <[e-mail]> 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-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 “6. Validation Procedures” gives input on this. We discussed this 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 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 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 prescribe 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 “redirect-to-ip” is incompatible with “redirect to indirection-id” 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-type 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
> [e-mail]
> https://www..ietf.org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf..org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr