Re: [mpls] draft-kbbma-mpls-1stnibble

[Haoyu Song <[e-mail]>]

Hi Bruno,

I agree with your consideration on the first nibble and don't feel we should rely on it as a protocol identifier.

Similar to your suggestions, our MPLS Extension Header (EH)  proposal actually provides a method to indicate the upper layer protocol type.
Basically, a bSPL serves as EH indicator, and immediately after the label stack is a 4 byte HEH, in which a field called "OUL" (original upper layer protocol type) tells the payload type if it's known. The type could be "unknown" if it is unknown (to comply with the current MPLS architecture).
Note that we allows 0 EHs in the packet and the HEH can still be used to indicate the payload type.
Please see fig. 1 and 2 in https://datatracker.ietf.org/doc/draft-song-mpls-extension-header/06/ for a quick reference. Thanks!

Best regards,
Haoyu

From: mpls <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, April 20, 2022 5:57 AM
To: Andrew G. Malis <[e-mail]>; Robert Raszuk <[e-mail]>
Cc: mpls <[e-mail]>
Subject: Re: [mpls] draft-kbbma-mpls-1stnibble

First of all, thank you for the draft, which is a basis for an important discussion.


I'm with Robert on this one. Trying to guess what's behind the MPLS stack does not seem inline with the MPLS architecture. Either you understand the bottom of stack label and you know the type of payload (and FEC) or you don't.
Agreed that some have done that in the past (in general with pro, yet with significant con), but that does not mean that we need to continue and keeps building on this.


I agree with some of the text of the draft, but not the creation of the registry which is going in the wrong direction of extending the use of this 1st nibble. Not to mention based on heuristic and SHOULD for new LSR (while IMHO MUST/REQUIRED would be needed).

Without much thinking on the proposal, if there is a need to identify the type of payload following the MPLS stack, I would a priori propose the following:
- define a new bSPL for "non IP Explicit NULL Label" (which is in line with IPv4 and IPv6 Explicit Null Label)
- either followed by specific header (whatever format but including a payload type), or using the TTL>0 field of this LSE to indicate a type of payload (which give us more than 200 possible types)

That way we have explicit indication of the type and format of the payload, at the cost of an additional LSE (4 octets).

Note that eventually a new bSPL may not be required. Possibly one could use a Multi-purpose bSPL or the ELI based indicators since (as per proposition in this draft) Load-Balancing would require to use an entropy label.

Thanks,
--Bruno



Orange Restricted
From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Andrew G. Malis
Sent: Tuesday, April 19, 2022 10:28 PM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Cc: mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] draft-kbbma-mpls-1stnibble

Robert,

Tell that to the folks that implemented heuristics-based ECMP back in the day. Now we have to pick up the pieces.

Cheers,
Andy


On Tue, Apr 19, 2022 at 3:24 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Andy,

That nibble already breaks MPLS architecture regardless that it has been in use for a long time.

There should be nothing MPLS related above S=1 in the packet.

Cheers,
R.

On Tue, 19 Apr 2022 at 19:29, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

That's completely out of the scope of this draft. The point of this draft is to document existing practice, create a new registry, and clarify the best way to do load balancing based on the type of payload.

The future stuff being discussed by the design team will be in a different draft. THEN you can complain about breaking the MPLS architecture! :-)

Cheers,
Andy


On Tue, Apr 19, 2022 at 10:44 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

Yes I got this.

But I am thinking about MNA. Where does PSD would sit in respect to the Figure 1 and Figure 2 ? Do you know ?

Thx,
R.



On Tue, 19 Apr 2022 at 16:42, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

As shown in Figures 1 and 2, there is exactly one payload with a post-stack header, but three types of post stack-payloads (and headers), thus the use of the plural in the draft. To quote the text:

   Figure 1 shows an MPLS packet with Layer 2 header X and a label stack
   Y ending with Label-n.  Figure 2 shows three examples of an MPLS
   payload, A, B and C.  The full MPLS packets thus are: [X, Y, A], [X,
   Y, B], and [X, Y, C].

I hope this clears things up.

Cheers,
Andy


On Tue, Apr 19, 2022 at 10:33 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

I just understood from the text in the draft that the main objective to define those values in IANA is to allow more post stack headers ...

...
First Nibble registry is to document the types of post-stack headers
   that may follow a label stack, and to simplify their parsing.

2.2.  Why Create a Registry

   The MPLS WG is currently engaged in updating the MPLS architecture;
   part of this work involves the use of post-stack headers.
...

Such post stack headers will likely sit between the nibble and payload - no ? And so far discussions about PSD insertion seems to be why this draft may have surfaced :)

Best,
R.





On Tue, 19 Apr 2022 at 16:14, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

I think you're misreading the draft. The nibble under discussion is the first nibble of the payload, such as zero for the control word, 4 or 6 for IP, etc. It IS the "PWE3 nibble" that you refer to in your email.

Cheers,
Andy


On Tue, Apr 19, 2022 at 9:57 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,

Pseudowire emulation is a network layer in itself. Sure it is free to define its own nibble.

Now we are talking about a new nibble between the last mpls label on the stack (S=1) and PWE3 nibble. Moreover that middle nibble will by definition be 1st one and will likely indicate the presence of a special container with additional instructions way before the PWE3 nibble sits.

Are you game with this ? Actually the entire reason for RFC4385 just got smashed :) Not to mention any of the existing implementations which will not be new nibble aware and will be based on ethertype 8847 just parse it as today say for ECMP ...

Best,
R.

On Tue, 19 Apr 2022 at 15:45, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:
Robert,

If this is the case, then how have we been using the Pseudowire Control Word for the past 20 years or so? Nothing in this draft contradicts what's been running in the field since the early days of the PWE3 working group, and codified in RFC 4385.

Cheers,
Andy


On Tue, Apr 19, 2022 at 8:03 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Dear WG,

I would like to make the observation that the draft-kbbma-mpls-1stnibble departs from MPLS Label Stack encoding as defined in RFC3032 (ref section 2.2 of RFC3032).

Post last label on the stack we are expecting Network Layer Protocol not some nibbles. This is no longer MPLSv1.

If folks want to start defining nibbles and post stack data which is not a network layer they are welcome but let's call it what it is - new MPLS architecture and let's call it MPLSv2.

Likely with new ethertype.

Kind regards,
Robert

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C01%7Chaoyu.song%40futurewei.com%7C98e3106b2e204cddeb5c08da22cd6809%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637860562890104317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=333%2BR93UFRdNH1J2wH5eaajV7KYo8V9xXs3tAiBs4fM%3D&reserved=0>

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.