[mpls] Re: PSD technical issues

[Joel Halpern <[e-mail]>]

The current operational paradigm does not provide for any way for P 
nodes to know about the presence of control word or detnet information.  
Nor does it provide for any means for P-nodes which are not supporting 
BIER to know about the presence or parsing of BIER information.  
Requiring that all nodes in the domain know how to parse these things is 
a major change in the operational paradigm.  And requiring that all 
nodes know about their presence would be a major change to the signaling 
protocol.  Asking those protocol suites to change their operations for 
our convenience does not seem a reasonable ask.  Nor does it seem 
consistent with the agreed requirements.

Yours,

Joel

On 4/30/2025 5:51 PM, Haoyu Song wrote:
>
> Greg,
>
> The fact that a P node is not required to handle the headers doesn’t 
> mean it cannot read and skip them. This is data plane feature. I don’t 
> know what “severe” complexity is added to the control plane. Even 
> there’s some extra work in control plane, that’s much better than 
> introducing complexity to the data plane.
>
> If it’s confirmed that no P node needs to touch those headers, we can 
> also put PSD MNA before those headers, and make sure the first action 
> is to remove the PSD MANs at egress node.
>
> Regards,
>
> Haoyu
>
> *From:*Greg Mirsky <[e-mail]>
> *Sent:* Wednesday, April 30, 2025 5:16 PM
> *To:* Haoyu Song <[e-mail]>
> *Cc:* Tony Li <[e-mail]>; Joel M. Halpern 
> <[e-mail]>; Loa Andersson <[e-mail]>; Dongjie (Jimmy) 
> <jie.dong=[e-mail]>; mpls <[e-mail]>
> *Subject:* Re: [mpls] PSD technical issues
>
> Hi Haoyu,
>
> I believe you misunderstand PW, EVPN, DetNet in MPLS, and BIER. Up to 
> now, a P node in any of these services is not required to handle PW 
> CW, ACH, d-CW, d-ACH, or BIER Header. As I understand the MNA 
> Framework and MNA Requirements, it is required that MNA HbH scope 
> works for P nodes in these services. Your proposal adds severe 
> complexity to the respective control planes.
>
> Regards,
>
> Greg
>
> On Wed, Apr 30, 2025 at 2:08 PM Haoyu Song <[e-mail]> 
> wrote:
>
>     Greg,
>
>     If the network supports these functions, sure the nodes should
>     have the knowledge to understand and parse the corresponding
>     headers. I don’t think this is an extra burden rather I think
>     that’s required. If these cases need to coexist, there could be
>     certain stipulations on the order they appear, and the parser
>     simply parses them one by one sequentially. It’s okay to parse
>     some headers without processing them. Anyway, these parsed headers
>     are still needed when reassemble the packet at the egress.
>
>     Regards,
>
>     Haoyu
>
>     *From:*Greg Mirsky <[e-mail]>
>     *Sent:* Wednesday, April 30, 2025 4:38 PM
>     *To:* Haoyu Song <[e-mail]>
>     *Cc:* Tony Li <[e-mail]>; Joel M. Halpern
>     <[e-mail]>; Loa Andersson <[e-mail]>; Dongjie (Jimmy)
>     <jie.dong=[e-mail]>; mpls <[e-mail]>
>     *Subject:* Re: [mpls] PSD technical issues
>
>     Hi Haoyu,
>
>     you've said, "But all the headers are self-explanatory." What is
>     self-explanatory in, for example, d-ACH? How do you differentiate
>     between ACH and d-ACH? You keep dismissing it by throwing around
>     technically-sounding soundbites. Still, the problem is that your
>     proposal to handle the combination of MNA PSD with the existing
>     PSHs requires all P nodes in the PW, DetNet, or BIER domain to
>     support PW, DetNet, and BIER and learn respective context labels.
>
>     Regards,
>
>     Greg
>
>     On Wed, Apr 30, 2025 at 10:44 AM Haoyu Song
>     <[e-mail]> wrote:
>
>         Hi Tony,
>
>         Many headers are of variable size if the optional fields are
>         included. But all the headers are self-explanatory. With the
>         header knowledge, it can be parsed and skipped. This applies
>         to the BIER header as well. Even if a node doesn't need to
>         process it, it can scan through the entire header properly and
>         find the header of interest after to process. I don't see a
>         problem for this conventional approach.
>
>         Regards,
>         Haoyu
>
>         -----Original Message-----
>         From: Tony Li <[e-mail]> On Behalf Of Tony Li
>         Sent: Wednesday, April 30, 2025 1:16 PM
>         To: Haoyu Song <[e-mail]>
>         Cc: Joel M. Halpern <[e-mail]>; Loa Andersson
>         <[e-mail]>; Greg Mirsky <[e-mail]>; Dongjie
>         (Jimmy) <jie.dong=[e-mail]>; mpls
>         <[e-mail]>
>         Subject: Re: [mpls] PSD technical issues
>
>         [WG chair hat: off]
>
>         Hi Haoyu,
>
>
>         > <HS> So we have only three cases to consider: pseudowire,
>         detnet, and BIER.
>         > If only the egress node needs to process them, they can be
>         located after PSD.
>         > If the intermediate nodes also needs to process them, then
>         they can be normally parsed and followed by PSD. I didn't look
>         into those use cases in detail. Can anybody tell me why the
>         above suggestion doesn't work.
>
>
>         BIER is the interesting case, as it’s multicast and definitely
>         requires intermediate nodes to examine the BIER information
>         and act on it.
>
>         Placing MNA PSD after the BIER header requires that all nodes
>         have an intimate knowledge of BIER and its variable length
>         encapsulation. Finding the PSD header would be dependent on
>         first correctly parsing BIER.
>
>         This dependency is most unfortunate as it makes the entire
>         architecture brittle and tightly coupled.  We would much
>         rather have things be loosely coupled and allow one protocol
>         to be independent of other protocols. Unfortunately, no
>         mechanism was put in place for this when we started MPLS, so
>         we want to do what we can to avoid these dependencies.
>
>         Regards,
>         Tony
>