Re: [mpls] MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

[IJsbrand Wijnands <[e-mail]>]

Dear WG,

Here are my comments and observations;

Following the ongoing discussion on the MPLS WG list, it seems there is disagreement/confusion whether PSD should be part of the MNA requirements draft. I have read the draft-ietf-mpls-mna-requirements draft, my conclusion is this draft invalidates ISD altogether. I’m assuming that when ISD is referenced, it is the encoding as specified in draft-ietf-mpls-mna-hdr-03

I’ll give a few examples;

1.2 Background

“...These solutions rely on either the built-in next-protocol
   indicator in the header or the knowledge of the format and size of
   the header to access the following packet data.  The node is
   required to be able to parse the new header, which is unrealistic
   in an incremental deployment environment. “

The background discussed other solutions in this space (i.e. I-D.song-mpls-extension-header etc..), and invalidates them on the premises that it introduces a new header and has a build-in next-protocol indicator. IMO, ISD is no different. Adding an Opcode inside the MPLS Label value is like adding a new protocol inside of MPLS.

“...New use cases therefore require the definition of extensions to the
   MPLS architecture and label stack operations that can be used across
   these use cases in order to minimise implementation complexity and
   promote interoperability and extensibility.

I can go along with adding 11 bits of data in the MPLS header (using TTL and TC). These fields could be repurposed without violating the MPLS architecture. But as soon as more data needs to be encoded, the solution becomes very complex to parse. Data is spread out over multiple MPLS labels and/or is not contiguous within the label value. There is also no reuse of any MPLS implementation logic if the 20 bit label is not a simple lookup key.

3.1.  General Requirements

“...1.   MPLS combines extensibility, flexibility and efficiency by using
        control plane context combined with a simple data plane
        mechanism to allow the network to make forwarding decisions
        about a packet.  Any solution MUST maintain these properties of
        MPLS.”

Any solution MUST maintain these properties of MPLS, does ISD fit that statement? It doesn’t come even close IMO.

“...5.   The design of any MNA solution SHOULD be such that an LSR is
        able to efficiently parse the label stack.”

Efficiently parse the label stack, how can you claim that ISD can be parsed efficiently? The processing of ISD has nothing to do with any existing MPLS forwarding logic.

“...7.   MNA solutions MUST NOT increase the size of the MPLS label stack
        more than is necessary.”

When it comes to encoding more than 11 bits, potentially many labels need to be added. PSD is much more efficient in terms of encoding and limiting the size of the Label stack.


To me ISD makes sense if the amount of data encoded isn’t more than 11 bits, otherwise I would prefer the MPLS WG to exploring solutions based on PSD.

Thx,

Ice.




> On 18 Sep 2023, at 22:33, Loa Andersson <[e-mail]> wrote:
> 
> 
> Working Group,
> 
> This is to initiate a two week working group last call on
> draft-ietf-mpls-mna-requirements-07.
> 
> Please send your comments to the MPLS WG mailing list ([e-mail]).
> 
> There are no IPR disclosures against this document.
> 
> All the authors (no contributors on this document) have stated on the working group mailing list that they are not aware of any IPRs that relates to this document.
> 
> This working group last call ends October 4, 2023.
> 
> 
> /Loa
> for the MPLS wg chairs
> 
> -- 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls