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,

Zzh4> Looks like we’re talking about two different directions – I am
talking about controller to PEs yet you’re talking about PEs to
controllers. Can you elaborate your use case?

I  do not have a use case for this draft, but I am struggling all along to
understand yours. Lecture of the draft does not help with that :)

Ok so we have established that you would like to have a controller to apply
a Tunnel Encap Attribute to m-cast routes and send it to ingress PEs
including a new sub-TLV which will contain a SR-MPLS label stack to be
applied to steer the traffic from ingress to egress - in a very topology
depended underlays.

So with that being established I only have two final questions:

*Question A) *

What NLRI labels are part of those multicast routes which would carry
Tunnel Encapsulation Attribute ? With that please note section 6 of RFC9012
which prohibits use of this attribute in any other AFI/SAFI then those
enumerated there:

6.  Semantics and Usage of the Tunnel Encapsulation Attribute

   The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
   UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
   Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
   1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
   or 25/70 (Ethernet VPN, usually known as EVPN).  Use of the Tunnel
   Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
   outside the scope of this document.

*Question B) *

Don't we have a dedicated mechanism to do exactly SR-MPLS policy signalling
from controllers to ingress nodes in the form of
https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/
?

I would rather make sure that your application is covered in this document
rather then trying to smuggle an alternative mechanism in a quite covered
fashion :)

Kind regards,
Robert