Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

[Robert Raszuk <[e-mail]>]

> One is to signal an SR policy, the other is to specify an explicit path
in an MPLS tunnel of a TEA attached a route.

Except that "SR Policy" is nothing else then the explicit path :)

Cheers,
R.



On Fri, Dec 30, 2022 at 3:44 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Hi Robert,
>
>
>
> Please see zzh7> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, December 30, 2022 5:19 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] WG adoption of
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to
> 1/13/2023
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
> Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that
> is attached
>
> > to a unicast prefix or a multicast tree route signaled from a controller.
>
>
>
> Actually it is precisely what authors
> of draft-ietf-idr-segment-routing-te-policy considers to be a fit.
>
>
>
> You are now mixing "SR Policy" with "SR Policy Color" :)
>
>
>
> Zzh7> draft-ietf-idr-segment-routing-te-policy is about “Advertising
> Segment Routing Policies”. In an SR policy, you can have policy color with
> it:
>
>
>
>    +------------------+
>
>    |  NLRI Length     | 1 octet
>
>    +------------------+
>
>    |  Distinguisher   | 4 octets
>
>    +------------------+
>
>    |  Policy Color    | 4 octets
>
>    +------------------+
>
>    |  Endpoint        | 4 or 16 octets
>
>    +------------------+
>
>
>
> Zzh7> In my previous email I said “… that draft is for a controller to
> signal that policy to the root, with the tunnel endpoint/color and
> candidate path encoded in the NLRI and other information encoded in a TEA
> with a special “SR Policy” tunnel type”. Where did I mix "SR Policy" with
> "SR Policy Color"?
>
>
>
>
>
> Take a look at section 2.4.4.2.1.  Segment Type A - it is exactly what you
> are proposing as new sub-TLV for TEA:
>
>
>
> Zzh7> It’s clear that you did NOT read the subject draft well. More below.
>
>
>
> draft-ietf-idr-segment-routing-te-policy:
>
>
>
>    The Type A Segment Sub-TLV encodes a single SR-MPLS SID.  The format
>    is as follows and is used to encode MPLS Label fields as specified in
>    [RFC3032] [RFC5462].:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |   Length      |     Flags     |   RESERVED    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Label                        | TC  |S|       TTL     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> Your draft:
>
>
>
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |     Type      |   Length      |     Flags     |   RESERVED    |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |          Label                        | TC  |S|       TTL     |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> It is clear that this is not efficient on-the-wire encoding format, and it
>
> involves additional encoding/decoding processing.
>
> Zzh7> As the above quoted text (I marked it red) shows, I was pointing
> out the efficiency issue of existing encoding scheme – that’s why the
> subject draft proposes the compact format:
>
> 3.1.  Segment Type L
>
>
>
>    The Type L Segment Sub-TLV encodes multiple SR-MPLS SIDs.  The format
>
>    is as follows and is used to encode MPLS Label fields as specified in
>
>    [RFC3032] [RFC5462]:
>
>
>
>      0                   1                   2                   3
>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |     Type TBD1   |   Length      |     Flags     |   RESERVED  |
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |          Label                        | TC  |S|       TTL    //
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     //          Repeated Label Entries                              |
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> In fact if you look at section 2.2
> of draft-ietf-idr-segment-routing-te-policy you will find exactly the
> solution to your use case by encoding SR Policy Candidate Path in TEA.
>
>
>
> Zzh7> You’re not reading my earlier email. Let me quote it here:
>
>
>
> Zzh6> … that draft is for a controller to signal that policy to the root, with
> the tunnel endpoint/color and candidate path encoded in the NLRI and other
> information encoded in a TEA with a special “SR Policy” tunnel type.
>
> Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that
> is attached to a unicast prefix or a multicast tree route signaled from a
> controller. There is no reason the mix the two use cases.
>
>
>
> Zzh7> When a controller advertises a route (e.g. for a VPN prefix), it can
> attach a TEA to specify the tunnel destination information already. Now we
> want to be able to specify the explicit path as well. We don’t need/want to
> use a special SR Policy Tunnel for it (as you quoted below it has a lot of
> policy, candidate path information that are totally irrelevant). All we
> need to do is to attach this new label stack sub-TLV to the existing “MPLS”
> tunnel in the TEA.
>
>
>
> 2.2.  SR Policy and Tunnel Encapsulation Attribute
>
>    The content of the SR Policy Candidate Path is encoded in the Tunnel
>    Encapsulation Attribute defined in [RFC9012] using a Tunnel-Type
>    called SR Policy Type with codepoint 15.  The use of SR Policy
>    Tunnel-type is applicable only for the AFI/SAFI pairs of (1/73,
>    2/73).
>
>    The SR Policy Encoding structure is as follows:
>
>    SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
>    Attributes:
>       Tunnel Encapsulation Attribute (23)
>          Tunnel Type: SR Policy (15)
>              Binding SID
>              SRv6 Binding SID
>              Preference
>              Priority
>              Policy Name
>              Policy Candidate Path Name
>              Explicit NULL Label Policy (ENLP)
>              Segment List
>                  Weight
>                  Segment
>                  Segment
>                  ...
>              ...
>
>    Figure 2: SR Policy Encoding
>
>
>
> That is why in my first mail I asked if you are trying to do SR-MPLS-LIGHT
> here essentially overwriting draft-ietf-idr-segment-routing-te-policy
> proposal.
>
>
>
> Zzh7> It’s definitely not “overwriting”, and
> draft-ietf-idr-segment-routing-te-policy is not appropriate for my use
> case. They are entirely two different things. One is to signal an SR
> policy, the other is to specify an explicit path in an MPLS tunnel of a TEA
> attached a route.
>
>
>
> Zzh7> Jeffrey
>
>
>
> Many thx,
> R.
>
>
>
>
>
>
>
> On Fri, Dec 30, 2022 at 3:02 AM Jeffrey (Zhaohui) Zhang <
> [e-mail]> wrote:
>
> Please see zzh6> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Thursday, December 29, 2022 5:10 PM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Cc:* Susan Hares <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] WG adoption of
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to
> 1/13/2023
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Jeffrey,
>
>
>
> Zzh5> It’s “outside the scope” of RFC9012, not that TEAs are **prohibited**
> with other AFI/SAFI.
>
>
>
> What I should say was prohibited without a new spec extending the use of
> TEA to other AFI/SAFIs. To the best of my reading the subject draft does
> not extend use of TEA to other AFI/SAFIs.
>
>
>
> Zzh6> The subject draft is only defining a new label stack sub-TLV for the
> purpose of steering traffic to the tunnel endpoint in a TEA that could
> attached to the routes of the AFI/SAFIs in RFC9012 itself. As you say, the
> subject draft does not extend use of TEA to other AFI/SAFIs. What’s wrong
> with that?
>
> Zzh6> The same could be used for multicast tree routes as well. That is
> indeed for a different AFI/SAFI, and there is another draft for that. That
> draft is not the subject draft here, but what’s wrong with that?
>
>
>
> Zzh5> That draft is about signaling **policy** - a totally different use
> case. What this draft does is to allow, for a particular tunnel in a TEA,
> the steering of traffic to the tunnel endpoint.
>
>
>
> Sorry but SR policy is exactly for steering traffic to the tunnel
> endpoint. Yes the name "policy" is chosen very poorly as it does not
> reflect what most of us understand by "policy" but it is what it is.
>
>
>
> Zzh6> Policy is indeed a poor name to me as well. An SR policy is another
> name for a named tunnel that may have different candidate paths, and that
> draft is for a controller to signal that policy to the root, with the
> tunnel endpoint/color and candidate path encoded in the NLRI and other
> information encoded in a TEA with a special “SR Policy” tunnel type.
>
> Zzh6> It is not fit for encoding explicit path for a tunnel in a TEA that
> is attached to a unicast prefix or a multicast tree route signaled from a
> controller. There is no reason the mix the two use cases.
>
> Zzh7> Jeffrey
>
>
>
> Thx,
> R.
>
>