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

From: "Susan Hares" <[email-masked]>
Date: Mon, 18 Nov 2019 00:41:56 -0500

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? 

2)      Whether the draft is useful for deployments of flow specification

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? 

Thank you for considering this draft. 

Cheerily, Susan Hares

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 26 Nov 2019 06:09:48 +0000

Hi Sue & WG,

I support the publication of this document.

1) Yes
2) Yes, it's useful.
3) Yes, I think it's ready.
4) Yes

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 18, 2019 1:42 PM
To: [email-masked]
Subject: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

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?

Cheerily, Susan Hares

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Thu, 28 Nov 2019 06:24:24 +0000

Hi Sue & WG,

1) Yes
2) Yes, it's useful for adjust traffic
3) Yes.
4) Yes

Thanks,
Shunwan

Cheerily, Susan Hares

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 28 Nov 2019 09:37:20 +0000

We have implemented this draft in commercial code. See tracking wiki:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-flowspec-path-redirect%20implementations

Not sure if required from WG operational perspective: As co-author I support publication.

G/

From: Idr <[email-masked]> On Behalf Of Wanghaibo (Rainsword)
Sent: Thursday, November 28, 2019 13:24
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Hi Sue & WG,

1) Yes

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, November 18, 2019 1:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

  1.  Is compatible with draft-ietf-rfc5575bis-17.txt?
  2.  Whether the draft is useful for deployments of flow specification
  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?

Cheerily, Susan Hares

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 28 Nov 2019 11:44:35 +0000

I support this document for publication.
It is useful technology, ready for deployments and existing implementations.

Thanks.
Jorge

Cheerily, Susan Hares

---

From: Lizhenbin <[email-masked]>
Date: Thu, 28 Nov 2019 12:02:21 +0000

Hi Sue & WG,
I support the last call of this document as the co-author. In the past years it is proved that the use cases proposed in the draft is very useful
and the solution is practical. After several rounds of refining the document is well written and ready for publication.

Best Regards,
Zhenbin (Robin)

Cheerily, Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Nov 2019 08:21:07 -0500

Sue,

> On Nov 18, 2019, at 12:41 AM, Susan Hares <[email-masked]> wrote:
> 

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.

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

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?

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.

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.

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

---

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 28 Nov 2019 17:19:34 +0000

I support the publication of this draft. It provides the needed capability to perform redirection to tunnel in general and to segment routing tunnel in particular.

Regards,
Mustapha.

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Monday, November 18, 2019 12:42 AM
To: [email-masked]
Subject: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Cheerily, Susan Hares

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 28 Nov 2019 17:23:37 +0000

Support, well written document

Regards

Hooman

From: Idr <[email-masked]> On Behalf Of Aissaoui, Mustapha (Nokia - CA/Ottawa)
Sent: Thursday, November 28, 2019 12:20 PM
To: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Regards,
Mustapha.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: Monday, November 18, 2019 12:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Cheerily, Susan Hares

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 28 Nov 2019 18:10:03 +0000

YES

2)       Whether the draft is useful for deployments of flow specification
YES, it is being deployed in customer environments

YES as mentioned before

YES

From: Idr <[email-masked]> on behalf of Lizhenbin <[email-masked]>
Date: Thursday, 28 November 2019 at 13:02
To: Susan Hares <[email-masked]>, IDR <[email-masked]>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Hi Sue & WG,

Best Regards,
Zhenbin (Robin)

Cheerily, Susan Hares

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 Nov 2019 03:51:35 +0000

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

It can be useful.

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

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:

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.

G/

> [email-masked]<mailto:[email-masked]>

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 Nov 2019 10:34:26 +0100

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:

> 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].
> >
> 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>
>
> https://www.ietf..org/mailman/listinfo/idr
> <https://www.ietf.org/mailman/listinfo/idr>
>