[mpls] Re: Addressing draft-ietf-mpls-mna-hdr review comments

[Balázs Varga A <[e-mail]>]

Hi Toni,

Thanks for your comments. Some reactions:

> The gist of this comment seems to be to allow Format B to carry additional ISD by having following Format D LSEs. Is that correct?
Yes correct. Otherwise any operation requiring more than 13 bits is allowed only in “Format C:”

> We did consider this approach earlier and it was the consensus from the silicon folks that continue bits were harder to implement than counts.
> We did not receive significant contrary opinions.
Ok. I may have missed such a consensus call. Anyway before finalizing MNA formats may
worth for a reconsideration, whether the assumptions during the consensus still apply.

> Many of those bits were used in a previous version of the draft to support PSD.  If we want to support PSD in the future,
> we might want to re-use them.
Is it not something to be defined by e.g., “opcode” characteristics?

> The opcodes in Format B/C are allocated specifically to avoid being interpreted as an SPL.  Yes, it would be nice to have
> one mechanism that would apply in both place, but consistently burning a full bit seems excessive.
Ack.

Thanks & Cheers
Bala’zs

From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Tuesday, June 4, 2024 6:47 PM
To: Balázs Varga A <[e-mail]>
Cc: Adrian Farrel <[e-mail]>; Jaganbabu Rajamanickam (jrajaman) <[e-mail]>; mpls <[e-mail]>; mpls-chairs <[e-mail]>; [e-mail]
Subject: Re: [mpls] Addressing draft-ietf-mpls-mna-hdr review comments


[WG chair hat: off]

Hi Balázs,



1, Number of formats
Agree, it is not possible to solve MNA with less than 4 formats, but they could be somewhat improved.


I’m not seeing anything actionable in this comment.



2, Order of the various formats (I think this is inline with Adrian’s former comments as well)
It is mandatory to start MNA with a “format A”, followed by a “format B” label.
But the rule for format C and D would be more optimal with the following rules:
- format D: it must have a preceding “format B” or “format C”
- format C: used if a new function related data have to be added to MNA

So the following format orders should be valid examples:
- A, B, C, D, D, C -- > 3 opcodes with data (one with “long” data)
- A, B, D, D, C, D, D -- > 2 opcodes with “long” data
- A, B, D -- > 1 opcode with data

Yes, that needs format adjustments (see further comments below), but would provide some gains.


The gist of this comment seems to be to allow Format B to carry additional ISD by having following Format D LSEs. Is that correct?


3, No need of “NAL”, use “Continue-bit” instead
We may get rid of NAL. I think NASL is mandatory and critical as it provides information where the MNA ends.
NAL refers to a single function. I think the main decision regarding MNA on a node is:
- Do I care about MNA?
            - If NO: node can read NASL and jump to the next label after MNA.
            - If YES: node can read the MNA and process it.

In case of MNA processing instead of “NAL” just a single bit (Continue-bit) could be enough to signal whether
the next 32 bit is still data for the “opcode”. Such a C-bit is somewhat similar to the concept of S-bit.

The usage of a “Continue-bit” would allow the new rules regarding format order (see comment 2.)
Furthermore it can support a cleaner format design. (see next comments)


We did consider this approach earlier and it was the consensus from the silicon folks that continue bits were harder to implement than counts.
We did not receive significant contrary opinions.



FORMAT specific comments
4, Actual Format-B in the draft:
- Number of “reserved” bits
I dislike the current Format B. Why to have 4 reserved bits? We have the “opcode”, so using some bits of
the data field as Flag is easy to achieve, when the opcode operation is defined.
The draft also names such an example in “14.1.1.  Network Action Flags without AD”.


Many of those bits were used in a previous version of the draft to support PSD.  If we want to support PSD in the future,
we might want to re-use them.



5, Actual Format-D in the draft:
I have found the leading bit somewhat strange:
   *  1 (1 bit) : The most significant bit MUST be set.  This prevents
      legacy implementations from misinterpreting this LSE as containing
      a special label.
In my view legacy implementations may misinterpret already Format B/C, as all opcodes below 64 starts with
zero. So this seems to be not a useful field in format D.


The opcodes in Format B/C are allocated specifically to avoid being interpreted as an SPL.  Yes, it would be nice to have
one mechanism that would apply in both place, but consistently burning a full bit seems excessive.

Tony