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

From: Keyur Patel <[email-masked]>
Date: Sun, 1 Dec 2019 18:16:35 +0000

As a co-author, I support the publication.  Yes on all 4 questions. 😊

Regards,
Keyur

From: Idr <[email-masked]> on behalf of "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thursday, November 28, 2019 at 1:38 AM
To: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

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,

I support the publication of this document.

1) Yes
2) Yes, it’s useful for adjust traffic
3) Yes.
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]<mailto:[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].

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: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 2 Dec 2019 03:14:15 +0000

Yes, support because this document is really useful for steering packets into a specific path, such as steering packets into SFC.

1)      Is compatible with draft-ietf-rfc5575bis-17.txt?
Yes
2)      Whether the draft is useful for deployments of flow specification
Yes, useful for steering traffic into paths.

3)      Is this technology ready for deployment?
Yes.

4)      Is the write-up of this technology in draft-ietf-idr-flowspec-path-redirect clearly written and ready for publication?
Yes. Well, I think some editorial modifications should be made for titles and sub-titles about the upper cases issues.

Also, do we need to provide more text for security consideration?

1<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-1>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-2>
   2<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-2>.  indirection-id and indirection-id table . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-3>
   3<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-3>.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-3>
     3.1<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-3.1>.  Redirection shortest Path tunnel  . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-3>
     3.2<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-3.2>.  Redirection to path-engineered tunnels  . . . . . . . . .   4<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-4>
     3.3.  Redirection to complex dynamically constructed tunnels  .   5
   4<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-4>.  Redirect to indirection-id Community  . . . . . . . . . . . .   6<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-6>
   5<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#section-5>.  Redirect using localised indirection-id mapping table . . . .   8<https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-10#page-8>

Thanks for authors’ excellent contributions!
Cheng

From: Idr [mailto:[email-masked]] On Behalf Of Keyur Patel
Sent: Monday, December 02, 2019 2:17 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; 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,
Keyur

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 28, 2019 at 1:38 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

G/

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Wanghaibo (Rainsword)
Sent: Thursday, November 28, 2019 13:24
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[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

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: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 2 Dec 2019 12:38:36 +0000

Hi Sue,

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

Best regards,
Jie

To: [email-masked]

Cheerily, Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Dec 2019 12:26:21 -0500

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.

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

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

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?  

> "
>    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)

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

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 2 Dec 2019 12:30:09 -0500

Robert,

On Fri, Nov 29, 2019 at 10:34:26AM +0100, Robert Raszuk 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 ?

We had a bit of this discussion as part of the redirect-to-ip draft.  I
believe our discussion yielded that while we liked the idea and saw exactly
the types of behaviors of possible benefit, we also found it unlikely that
we'd get proper hardware support to do a copy to multiple destinations.

I know similar issues complicate most hardware implementations of
ipfix/netflow from past experience.

Somewhat similar to the flow analysis case, it's common to have a device act
as the primary receiver of such a flow to replicate it to the devices of
interest so as to offload the work from the forwarding linecards.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Dec 2019 19:29:40 +0100

> abstract and perhaps they could?

IMO using flow spec extension to specify a binding SID which in turn will
be replaced by explicit path is a huge mistake this draft is proposing.
Sure text can take everything but the operational complexity to
troubleshoot such network will be a nightmare. And if you would just
specify a single SID why not to specify the IP address and be done ? Router
will reach such IP via proper path.

Please observe that you are now trying to mimic BGP SR Policy propagation
which also includes mapping via color and policy to be used.

What happens when router will receive both in a conflicting manner ?

Btw what practical application is this draft trying to accomplish other
then pretty badly redo subset of BGP SR Policy work ?

Thx,
R/

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 3 Dec 2019 10:09:19 +0000

Inline: GV2>

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Monday, December 2, 2019 18:26
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: Sue 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]

Gunter,

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

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

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

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

-- Jeff

G/

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 3 Dec 2019 10:20:56 +0000

BGP SR policy is different in such a way that it can not steer based upon a flowspec tupple match. It uses a payload prefix and NH to select a particular path policy.

The original path-redirect had no additional assumptions associated and it referenced a 32bit number (Type 0 Seq-ID).
This 32bit number was used as opaque value to lookup forwarding information. If enabled, this is what I have in running code.

***
   ID-Type: 1 octet value.  This draft defines following Context Types:

      0 - Localised ID (The flowspec client uses the received 32-bit
      indirection-id to lookup forwarding information within the
      localised indirection-id table.  The allocation and programming of
      the localised indirection-id table is outside scope of the
      document)

      1 - Node ID with SID/index in MPLS-based Segment Routing (This
      means the 32-bit indirection-id is mapped to an MPLS label using
      the index as a global offset in the SID/label space)

      2 - Node ID with SID/label in MPLS-based Segment Routing (This
      means the 32-bit indirection-id is mapped to an MPLS label using
      the 32-bit indirection-id as global label)

      3 - Binding Segment ID with SID/index in MPLS-based Segment
      Routing (This means the 32-bit indirection-id is mapped to an MPLS
      binding label using the indirection-id as index for global offset
      in the SID/label space) [I-D.draft-ietf-spring-segment-routing]
      [6]

      4 - Binding Segment ID with SID/label in MPLS-based Segment
      Routing (This means 32-bit indirection-id is mapped to an MPLS
      binding label using the 32-bit indirection-id as global label) [I-
      D.draft-ietf-spring-segment-routing] [6]

      5 - Tunnel ID (Tunnel ID is within a single administrative domain
      a 32-bit globally unique tunnel identifier.  The allocation and
      programming of the Tunnel ID within the localised indirection-id
      table is outside scope of the document)

   Generalized indirection_id: 32-bit identifier used as indirection_id

***

I do have sympathy for your suggestion to simplify assuming if the general WG feels that there is too much overlap between the BGP SR Policy propagation and the current indirection Type 1, 2, 3, 4? We could drop those Type’s from the current draft and simplify interop complexity? That means we keep current proposed Type 0 and Type 5 (and rename Type 5 to something more sensible in that case).

G/

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

IMO using flow spec extension to specify a binding SID which in turn will be replaced by explicit path is a huge mistake this draft is proposing. Sure text can take everything but the operational complexity to troubleshoot such network will be a nightmare. And if you would just specify a single SID why not to specify the IP address and be done ? Router will reach such IP via proper path.

Please observe that you are now trying to mimic BGP SR Policy propagation which also includes mapping via color and policy to be used.

Btw what practical application is this draft trying to accomplish other then pretty badly redo subset of BGP SR Policy work ?

Thx,
R/

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Dec 2019 15:20:53 +0100

Hey Gunter,

> That means we keep current proposed Type 0 and Type 5
> (and rename Type 5 to something more sensible in that case).

Yes and that would be a great fix.

To sort of cover more explicitly then via type 0 types 2,3 & 4 you may
define new type to carry the "color". The same color as carried in BGP SR
Policy document if you want to be SR friendly :).

Then we should be fine.

Cheers,
R.,

On Tue, Dec 3, 2019 at 11:20 AM Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> BGP SR policy is different in such a way that it can not steer based upon
> a flowspec tupple match. It uses a payload prefix and NH to select a
> particular path policy.
>
>
>
> The original path-redirect had no additional assumptions associated and it
> referenced a 32bit number (Type 0 Seq-ID).
>
> This 32bit number was used as opaque value to lookup forwarding
> information. If enabled, this is what I have in running code.
>
>
>
>
>
> ***
>
> I do have sympathy for your suggestion to simplify assuming if the general
> WG feels that there is too much overlap between the BGP SR Policy
> propagation and the current indirection Type 1, 2, 3, 4? We could drop
> those Type’s from the current draft and simplify interop complexity? That
> means we keep current proposed Type 0 and Type 5 (and rename Type 5 to
> something more sensible in that case).
>
>
>
> G/
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, December 2, 2019 19:30
> *To:* Jeffrey Haas <[email-masked]>; Van De Velde, Gunter (Nokia -
> BE/Antwerp) <[email-masked]>
> *Cc:* [email-masked]; Sue Hares <[email-masked]>
> *Subject:* Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt
> [11/17/2019 to 12/2/2019]
>
>
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Dec 2019 15:47:15 -0500

Gunter,

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

It makes sense to do that then.  The redirect-ip case does specifically call
out that you can do the redirect in the VRF table context.  What you'll be
doing is effectively highlighting whether the abstract indirection table is
box-wide or scoped to specific tables.

Ideally, this will let you think through the yang implications of the
feature as well.

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

Thanks.  I think that will add needed clarity.

> processed as if the "Redirect to indirection-id" community was not attached to the flowspec route.

That's one option.  A similar one includes testing the usability of the
rule, as I noted in the pseudocode.  Let me drawn an analogy (perhaps a poor
one) from redirect-ip:

Consider a flowspec route with redirect-IP:A and redirect-ip:B.

If A is resolvable (per BGP route resolution rules) and B is not, it's
clearer that you want to use what can actually work.  If both are
resolvable, then an implementation may choose to use both for load
balancing.

Going back to indirection-id, if you have conflicting rules, but similar
"can this work" tests, do you really want to reject it solely because the
rules may appear conflicting?  Perhaps.

Unlike redirect-to-ip, I have no strong opinions about whether to permit
load balancing or other similar behaviors rather than consider it invalid.
What I will absolutely note is that troubleshooting this from extended
community output on a BGP route is likely to be more than a little awkward
at best.  Consider that most implementations tend to simply display extended
communities in their internal sort order (often effectively memcmp()) rather
than something that's more lexicographically ordered for troubleshooting
this feature.

-- Jeff