Re: [mpls] Concerns about ISD

[John E Drake <[e-mail]>]

Comments inline below, identified with [JD2].  I think it's time to move on from this discussion, as we seem to have completed it.

Yours Irrespectively,

John



Juniper Business Use Only
From: Tianran Zhou <zhoutianran=[e-mail]>
Sent: Tuesday, April 12, 2022 9:17 PM
To: John E Drake <[e-mail]>; Tony Li <[e-mail]>
Cc: [e-mail]
Subject: RE: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Hi,

Comments in line.

Tianran



Juniper Business Use Only
From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Tianran Zhou
Sent: Tuesday, April 12, 2022 2:36 AM
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Hi Tony,

>>Pushing data to PSD and beyond the RLSD will cause systems to be excluded from the path or take a significant performance hit.

If I know the RLSD of each node, there are many ways to prevent some nodes from pushing data to PSD.

[JD]  Given that you *only* want to use PSD, what is the above sentence proposing?

ZTR> If you followed the past few emails, Tony misled people that PSD will hinder the interoperability.

[JD2]  I understood his emails to say that many implementations cannot find the bottom of the label stack, as documented in RFC 8662.  Therefore, those implementations
would not be able to process ancillary post-stack data.  This is just fact

I just show you how PSD will not.

[JD2]  You did nothing of the kind.  You asserted, above, that the problem would be solved by not imposing ancillary post-stack data;  this is self-defeating

According to your description below on the ISD process, it's the same as PSD somehow. I did not see the ISD advantage.

[JD2]  I have no idea what the above statement is trying to say

I would like to know how ISD could survive if the ISD exceed the RLSD?

[JD]  The correct term is Network Actions  Sub-stack (NAS).  To answer your question, a transit node will miss the NAS regardless of whether it contains in-stack data.  This is the point that Tony has been making for the past few email iterations

ZTR> Creating new terms does not help the community. I do not care the fancy term you created.

[JD2]  The NAS, as described in the framework draft, consists of a network actions indicator, a specified set of network actions, and any ancillary in-stack data required by those network actions.  (If the specified network actions required ancillary post-stack data, it will also be present.)  The implications of the issue described in RFC 8662 are that multiple copies of an NAS may be required in an MPLS label stack and that some network actions may require ancillary in-stack data, which will be present in each copy of an NAS

Could you please point me out how many times Tony has clarified the ISD process? And where they are? I may have missed.
In my brain, Tony did not address any of my concerns on ISD, but only kept ignoring the fact I presented. It's not a good way for technique discussion.

[JD2] What I read is that you don't like in-stack data and an assertion, contrary to RFC 8662, that either all nodes can handle ancillary post-stack data or that if they can't, ancillary post-stack data won't be included

Best,
Tianran

From: Tony Li [mailto:[e-mail]] On Behalf Of Tony Li
Sent: Tuesday, April 12, 2022 2:03 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD


Hi Tianran,

ZTR2> PSD can work with RLSD, I cannot see how it will hinder the interoperability.


Pushing data to PSD and beyond the RLSD will cause systems to be excluded from the path or take a significant performance hit.

Tony