[mpls] Re: PSD technical issues

[Haoyu Song <[e-mail]>]

Hi Greg,

We don’t want to limit the potential use of MNA. I can envision the case we want to apply it for just a section of the LSP (e.g., IOAM). In this case, the node has to know how to insert the PSD.

Besides, what you said is actually prove that the node needs to understand how to parse the packet into deep layer. You said ”some implementations try to determine if the payload is an IP packet and calculate hash on the characteristic fields.” This is only possible the node can look beyond the label stack.

Regards,
Haoyu

From: Greg Mirsky <[e-mail]>
Sent: Thursday, May 1, 2025 2:14 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,
Thank you for the clarification. Personally, I don't see any benefit from using the P node and MNA encapsulating node. If you have any scenario that makes it worth the effort, I would appreciate it if you listed it. But even if a P node acts only as a transit MNA node, I expect it to support MNA's HBH scope. Thus, the PSD solution must coexist with existing PSHs. Some of these, e.g., PW and EVPN, use heuristics in load-balancing. AFAIK, some implementations try to determine if the payload is an IP packet and calculate hash on the characteristic fields. In your opinion, what impact PSD will have on MPLS networks where such method is used?

Regards,
Greg

On Thu, May 1, 2025 at 12:54 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Sorry for the confusing. My question is: will we allow a P node to initiate a PSD MNA?
I think some use cases would require this. Or have we prohibited such possibilities?

Regards,
Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 4:33 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] PSD technical issues

Hi Haoyu,
which of these options do you support? Also, can you explain what is "egress P node"? AFAIK, nodes on the edge of the service domain are referred to as PE nodes. Nodes inside the domain are referred to as P nodes. I am puzzled by a new term "egress P node" you introduce. Is that suppose to be equivalent to a PE node? If that is the case, then your proposal doesn't solve the problem of processing PSD by a P node.
Furthermore, I believe that technology limitations must not impede on the development of new technologies. I subscribe to "If you build it, they will come" philosophy. Yes, we must recognize limited capabilities in deployed networks and provide means to preserve existing services they deliver. But, I believe, over time networks will advance and operators will be able to use advanced mechanisms.
I apologize, but I cannot understand your last point. Perhaps you will chose to re-word it.

Regards,
Greg

On Wed, Apr 30, 2025 at 4:16 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Well, I can summarize several possible solutions:

  1.  Make PSD immediately after the BoS, and remove PSD first at egress P node.
  2.  As you said, use the control plane to notify the P node what to expect.
  3.  Exclude using these use cases when PSD is used and vice versa.
  4.  Unify these use cases with the PSD mechanism.

Points that against the use of offset field:

  1.  it creates major obstacles for production adoption. Many hardware can’t support the parsing of it.
  2.  I don’t think MNA must share the same PE node with the other use cases. So when the PSD and its indicator are generated, the same problem occurs: if the node does not know what’s present in the packet, it can’t properly insert the PSD and set the offset in the first place.

Haoyu

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 6:42 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] PSD technical issues

Hi Haoyu,
can please explain how a P node would "read and skip", for example, d-ACH? What would a P node use to distinguish between PW's ACH and d-ACH? I'd point out to you, that such differentiation is critical because the length of d-ACH is eight octets while ACH's - four. So, please explain how you envision that would work without re-working PW, EVPN, and DetNet control planes.

Regards,
Greg

On Wed, Apr 30, 2025 at 2:51 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> 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]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 5:16 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, April 30, 2025 4:38 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Wednesday, April 30, 2025 1:16 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>>; mpls <[e-mail]<mailto:[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