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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

We are indeed going in circles.

Let me just reply to the following point:


  *   And note that you never answered the fundamental point I was bringing since first email - BGP is p2mp protocol. Explicit path when attached to service routes will unlikely be a fit for all ingress PEs.

Your first email did not bring up that point. It was in your third email, and I immediately replied with two scenarios:


  1.  A theoretically scenario where the explicit path is closer to the egress router
  2.  A more practical case where the controller is sending the service routes to ingress routers

In a follow up email, I pointed a multicast use case where a controller is specifying the explicit path between an upstream tree node and a downstream tree node.

Jeffrey



Juniper Business Use Only
From: Robert Raszuk <[e-mail]>
Sent: Tuesday, January 3, 2023 12:35 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]; Susan Hares <[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]

Jeffrey,

Now you are also presumably reusing IGP extentions to ISIS and OSFP to signal domain wide labels .. no ?

Zzh> Where did you get that idea? The controller calculates the explicit path, represent it with a label stack, and put it in the MPLS tunnel in the TEA. Where is the hint of using IGP?

How does the controller know what explicit paths to send ?

How does node N in the network know where to forward the packet with label L1 ?

Are you using RSVP-TE ?

Are you using static label paths ?

Or are you counting on using RFC 8667 or RFC8663 extensions ?

Yet you are keep claiming this is not SR ...

Zzh> Where did I claim that? I am just saying that I am not using SR *policy*, and the TEA can still use an MPLS tunnel with an SR label stack.

SR policy is how folks call SR explicit paths. You can not just decouple those two as clearly you are using the latter.

So where it all get's down to is a question do we need inb BGP another way to carry SR policy from controller to ingress nodes.

And note that you never answered the fundamental point I was bringing since first email - BGP is p2mp protocol. Explicit path when attached to service routes will unlikely be a fit for all ingress PEs.

You could perhaps signal biding SIDs to say split the traffic between N planes for different m-cast groups (if that is the true use case), but why you can not do that with all SR tools already in place ?

Thx,
R.