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

[Robert Raszuk <[e-mail]>]

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

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:

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.

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.

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.

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