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

[Robert Raszuk <[e-mail]>]

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) <
[e-mail]> 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.
>
>
>
>
>
> ***
>
>    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 <[e-mail]>
> *Sent:* Monday, December 2, 2019 19:30
> *To:* Jeffrey Haas <[e-mail]>; Van De Velde, Gunter (Nokia -
> BE/Antwerp) <[e-mail]>
> *Cc:* [e-mail]; Sue Hares <[e-mail]>
> *Subject:* Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt
> [11/17/2019 to 12/2/2019]
>
>
>
>
>
> 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?
>
>
>
> 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/
>
>
>