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

Hi Stewart,
Thanks for your comments. Sorry for missing your mail and late reply. Please refer to my reply inline identified by “[Robin]”.

Best Regards,
Robin

From: Stewart Bryant [mailto:sb@stewartbryant.com]
Sent: Wednesday, July 13, 2022 1:00 AM
To: Lizhenbin <lizhenbin@huawei.com>
Cc: Stewart Bryant <sb@stewartbryant.com>; n.leymann@telekom.de; mpls@ietf.org; draft-andersson-mpls-mna-fwk@ietf.org; mpls-chairs@ietf.org
Subject: Re: [mpls] Working Group Adoption Poll for draft-andersson-mpls-mna-fwk

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
[Robin] It is necessary to carry source for the true users’ packets. I think the SA in the OAM payload may not serve the purpose.

   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.
[Robin] In fact I am always curious about the design of no indication of payload type. You are familiar with the history and may introduce more details about it. In my opinion, the alternative ways you mentioned can work, but may be complex. In the current MPLS extensions design, the special purpose label may be introduced to indicate the PSD or maybe Next Header mechanisms will be introduced for the concatenated metadata. Personally thinking, they are the right and direct way like the mechanism to indicate the payload type. They are changing the old design philosophy and reinvent the IPv6 NH mechanism.

   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

[Robin] My thinking is that IPv6’s mechanism may be reused.

   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?

[Robin] I just talk about the point of ECMP’s implementation. In this point, IPv6’s implementation is simpler and more mature. For the point that the huge packet header effect forwarding performance, I agree with it, but it is another point. And if more metadata introduced for MPLS packets, the forwarding performance will also be effected because of huge packet header.

   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.
[Robin] It can be placed anywhere in the stack. Because of it, the implementation is more complex.

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,

[Robin] We are proposing an alternative way for reinventing MPLS. It is open for discussion. I have much concerned about the MPLS ISD and PSD design. In the history, even for the small change like entropy label, it takes a long time to be implemented by the major vendors. For the change like SFL, until now there is few implementations. I wonder like such a big change of MPLS ISD and PSD how long it will take for the major vendors to implement.

Best regards

Stewart

On 11 Jul 2022, at 13:13, Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>> 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:mpls-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Monday, July 11, 2022 8:06 PM
To: n.leymann@telekom.de<mailto:n.leymann@telekom.de>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; draft-andersson-mpls-mna-fwk@ietf.org<mailto:draft-andersson-mpls-mna-fwk@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>
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, n.leymann@telekom.de<mailto:n.leymann@telekom.de> 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 (mpls@ietf.org<mailto:mpls@ietf.org>).
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
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls