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

Inline: GV2>

-----Original Message-----
From: Jeffrey Haas <[email protected]> 
Sent: Monday, December 2, 2019 18:26
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>
Cc: Sue Hares <[email protected]>; [email protected]
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Gunter,

On Fri, Nov 29, 2019 at 03:51:35AM +0000, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> > 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

Redirect-ip isn't even mentioned in the draft.

Part of the reason to raise this is whether intentional interactions could happen.  As an example, redirect-ip is specced to be permitted in the context of a VRF redirection.

I suspect in the majority of the cases that path-redirect is intended involving segment routing that following a segment path from a VRF context doesn't make much sense.  However, some of the cases are left as much more abstract and perhaps they could?

My point is that a bit more normative text on the various cases would be needed for interoperable code.

***
GV2> The original concept was to have an abstract steering correlation towards a 32bit tunnel-ID (This is an action, opaque to VRF, or any other associated contexts). If indeed a matter of context is added to the redirection id (for example the 32 bits represent a Segment path) then that few more normative text could be added on the cases.
***

> > 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.

Aside comment: Any possibility this could be renamed Seq-Id or something similar to avoid name confusion to SID?

The text above is clearer, but I'm not sure it really helps your case.  Here is what I believe the intent to be in pseudo-code:

if Seq-ID == 0 is present:
  apply actions, if possible.
  exit
foreach s in Seq-Id 1..15:
  if s is present:
     if action for s is possible:
        apply it.
        exit
     else:
        continue

Basically, try each sequence in turn.  If you can do something with it, you're done.  If you can't (the indirection can't be applied for numerous reasons), try next.  S-ID zero is intended to be a "hard stop".

***
GV2> Thanks. let me think on how to integrate this best
***

The 'C' bit also looks like it only changes the stream behavior and doesn't impact whether the rule is terminating or not.

***
GV2> correct
***

What's still not covered, since these are extended communities, is cases like there are two of a given S-ID present.  Perhaps it was added via blind policy?  What do you do?  

***
GV2> ok, my personal understanding is that rule is invalid, and then the flowspec rule MUST be
processed as if the "Redirect to indirection-id" community was not attached to the flowspec route.
***

> "
>    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 
> GV> "redirect-to-ip" is incompatible with "redirect to indirection-id" 
> GV> and result in invalid redirection rule, however to me that is 
> GV> already implied with enough detail in the text above)

redirect-to-ip is not core to 5575bis, so clarity as to precedence would be helpful, I think.

***
GV2> ack, will add that line
***

> > 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.

Understood.  They sometimes like to operate this way.  

-- Jeff

G/

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr