[mpls] PSD and BIER - Re: Re: PSD technical issues

[Toerless Eckert <[e-mail]>]

1. I can not see why i would ever want to have somethink like

   MPLS-header1 + BIER-header + MPLS-header2

Where there is PSD in MPLS-header2 that is referred to by MPLS-header1.
If someone can describe why that would be useful, that would be great.

2. IMHO, any PSD required by MPLS-header1 have to be encoded in MPLS-header1, aka:
following it's label stack, but before the BIER-headee, and MPLS-header2 is completely
independent from MPLS-header2 and may have its own PSD or not.

Logically, my "lowest" layer of forwarding is done through MPLS-header1. It identifies
the hop/path to the next BIER node (BFR). It is consumed when arriving at that BFR. After
replication, a new MPLS-header1 is pushed. And MPLS-header2 is simply the payload of BIER,
aka: acted upon after each replication.

3. What is "interesting" (not to say problematic) is that the BIER header is a "consortium
monster" which originally was meant to be only the header for BIER over MPLS, but then
it was declared to be the "one header that eliminates the need for all other headers" -
when not using MPLS.  Luckily on this list nobody cares about the (IMHO bigger) issues when not
using MPLS, but there is also an issue IMHO when using MPLS. And that is that because of
this history, the BIER header includes definition that should have been separate from the
BIER header. 

  RFC8296: The BIER header is shown in Figure 1.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              BIFT-id                  | TC  |S|     TTL       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ...

The challenge is that the first 32-bit of the BIER-header is effectively assumed to be
the last LSE of the label stack when MPLS is used. And the BIFT-id in case of MPLS is
the MPLS label indicating that the next protocol following is BIER, as well as
indicating additional context for that BIER header (aka: you need multiple of
those labels to support BIER, one for each BFR-ID).

Of course, as far as MPLS is concerned, the actual next-protocol header is not the
full BIER header, but only the BIER-header after the first 32 bit. And the reason why
those first 32-bit are defined to be part of the BIER-header is because the non-MPLS
cases also need a BIFT-id and a TTL.

In any case, the challence of course is that in case of an MPLS-header with PSD, the
last byte of an MPLS header consisting of Label stack plus PSD would logically not be the last
LSE, but the last byte of the last PSD element. Unless we re-define something.

And it is IMHO quite likely, that existing BIER parsers for an MPLS forwarding engine in some
non-flexible forwarding engine would NOT be happy to not have the information of the
first 32-bit of the BIER header in the place where they are expecting them. Or have some
PSD data there. So IMHO, we should not change any of the data that likely needs to be parseable
as a contiguous block for the BIER header when using PSD, but rather amend appropriate definitions.

Aka: IMHO, when using PSD, the BoS LSE to indicate BIER AFTER PSD should simply be
a single label that says so "After PSD, there is BIER" (without the need to allocate range
of labels for this purpose). And then the first 32-bits of the BIER-header following the PSD
are unchanged, except that logically this is not anymore the last LSE of the label stack,
but just the MPLS label encoding method of BIFT-id. And of course those 32bit could not be
part of the actual label stack because then the PSD would be between labels of a single label
stack, contradicting it's name (Post Stack ...).

But of course, if anyone who actually deals with HW parsing of MPLS+PSD+BIER has a different
preference what would make introduction of PSD most easy (and that's different)
 - then please chime in ! In any case, we should find the definitions that make introduction
of PSD most easy for existing HW (that could even support PSD).

Cheers
    Toerless

On Wed, Apr 30, 2025 at 10:15:36AM -0700, Tony Li wrote:
> [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
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
---
[e-mail]