Re: [mpls] Working Group Adoption Poll for draft-andersson-mpls-mna-fwk

[Stewart Bryant <[e-mail]>]

Dear Robin


You need to reverence and discuss RFC4023


   1.  MPLS is lack of the source indication and MP2P connections may
   occur.  This causes the difficulty and complex process for OAM over
   MPLS.  Although SFL( [RFC8957<https://datatracker.ietf.org/doc/html/rfc8957>]) is defined, there is few
   implementation.


SFL is one way, you can also put the SA in the OAM payload


   2.  The payload type (for example, L2 or L3 packets) cannot be
   directly determined because there is no payload indication.

This is an MPLS design philosophy, but not intrinsic to the protocol. You could use one of a number of PW types including PW types that carry a generic payload identifier. Alternatively you could create a new FEC type that had the property that the last label was a payload type indicator, or that the payload started with a type indicator.


   3.  There is no metadata extensibility and it is difficult to
   encapsulate new forwarding attributes for the new features such as
   IETF network slicing, IFIT, and APN.


That is what MNA is designing


   4.  The process of the ECMP function is complex and affects
   forwarding performance.


Huge packet headers effect forwarding performance. Do you have published results for your MPLS forwarder performance and your SRv6 (which this clearly relates to) performance?


   Entropy labels or flow labels are placed at
   the bottom of the label stack for processing and the internal IP
   header information may have to be parsed for the purpose of ECMP.


That is not correct. That can be placed anywhere in the stack, including being repeated in the stack. The IP header only needs to be parsed if the option is taken not to include the ELI/EL pair.

So I am concerned at the validity of your arguments both as a draft in its own right and as a draft that is relevant to this discussion,

Best regards

Stewart



On 11 Jul 2022, at 13:13, Lizhenbin <[e-mail]<mailto:[e-mail]>> wrote:

Hi All,
In fact I think MPLS faces more challenges than the metadata extensibility. The following draft proposes another option to “reinvent” MPLS.
https://datatracker.ietf.org/doc/html/draft-li-mpls-gip6-mpls-00

Your comments are welcome.


Best Regards,
Robin




From: mpls [mailto:[e-mail]] On Behalf Of Lizhenbin
Sent: Monday, July 11, 2022 8:06 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Working Group Adoption Poll for draft-andersson-mpls-mna-fwk

Hi All,
Personally speaking I do not think the ISD (In Stack Data) is a reasonable design for MPLS and should not be incorporated the draft-andersson-mpls-mna-fwk.
MPLS label stack design is aligned with the era that the hardware capability is limited and provide a simple and clear method to cope with such issue and
extended the network functions well.  Now as the services are emerging and require metadata-based extension, the reasonable way is to introduce the
new design instead of disrupting the existing one.


Best Regards,
Robin



On 2022 -Jun-28, at 15:54, [e-mail]<mailto:[e-mail]> wrote:

Working Group,

This is to start a two week poll on adopting  draft-andersson-mpls-mna-fwk as a MPLS working group
document.

Please send your comments (support/not support) to the mpls working group mailing list ([e-mail]<mailto:[e-mail]>).
Please give a technical motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There are two IPRs disclosure against this document. Details can be found here:

https://datatracker.ietf.org/ipr/5703/
https://datatracker.ietf.org/ipr/5659/

An IPR poll was done, and all the authors and contributors have stated on the MPLS WG mailing list that
they are unaware of any other IPR that relates to this document

The working group adoption poll ends July 12th , 2022.

Nic
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls