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

From: Gunter Van De Velde <[email-masked]>
Date: Fri, 29 Nov 2019 10:13:39 -0000

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 <[email-masked]> 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) <[email-masked]> wrote:

Hi Jeff,
 
Thanks for the feedback and suggestions.
 
See inline: GV>
 
-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Thursday, November 28, 2019 20:21
To: Sue Hares <[email-masked]>
Cc: [email-masked]
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-masked]> 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
> [email-masked]
> https://www..ietf.org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf..org/mailman/listinfo/idr
 
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 Nov 2019 15:01:30 +0100

Gunter,

What is there to validate ? You validate if the flow spec update is
legitimate and at most comparing destination match against unicast src
which in all of redirect use cases will be disabled anyway - you can not
possibly consider valid rule to redirect coming from your eBGP peer :).

Also pls observe that you never validate actual actions ... what I am
suggesting is just a little add-on in actions.

Thx,
R.

On Fri, Nov 29, 2019 at 11:13 AM Gunter Van De Velde <
[email-masked]> wrote:

> 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
>
> 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 ...
>
>> See inline: *GV>*
>> > This begins a 2 week WG Last call on
>> draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019].
>> >
>> > 4)      Is the write-up of this technology in
>> draft-ietf-idr-flowspec-path-redirect clearly written and ready for
>> publication?
>>
>> 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.
>>
>> “
>> 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:
>>    indicates that Sequence ID field is NOT set and *****all** other
>> sequence ID's***
>>    SHOULD be ignored.  A
>> *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:
>>
>> "
>> *   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
>> *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?
>> *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/*
>>
>>
>> >
>> <https://www.ietf.org/mailman/listinfo/idr>
>>
>> <https://www.ietf.org/mailman/listinfo/idr>
>>