Re: [mpls] Concerns about ISD

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

Hi,

You've made it clear that you don't like in-stack ancillary data, despite the many attempts to explain to you why it's necessary in
some cases.

I did a check of current proposed network actions  and found the following:  resource partition, E2E Loss Measurement, E2E OAM,
HBH OAM, entropy, no reroute, flow ID, 5G slice ID, traffic accounting, bounded delay, and L2 Frame Reassembly.  Of those, I think
resource partition, entropy, no-reroute, flow ID, traffic accounting, and bounded delay are candidates for having in-stack ancillary
data.  Detnet may also have some use for it.

The questions you ask in your email, below, are to be answered by any MNA solution draft.  A draft defining a given network action
will need to specify, among other things, whether that network action requires ancillary data, what is that ancillary data, and if it is
in-stack or post-stack.

Yours Irrespectively,

John



Juniper Business Use Only
From: Tianran Zhou <zhoutianran=[e-mail]>
Sent: Thursday, April 14, 2022 10:02 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]

It's still far from complete. A lot of concerns about ISD have not been addressed.
You occasionally ignore my reply. Let's firstly see my comments on your reply.

T.

From: John E Drake [mailto:jdrake=[e-mail]]
Sent: Wednesday, April 13, 2022 9:28 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Concerns about ISD

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]<mailto:zhoutianran=[e-mail]>>
Sent: Tuesday, April 12, 2022 9:17 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>; 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,

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

ZTR2> So you point out a new RFC8662, which is not Tony pointed. You kept taking EL for example. However, EL is a very simple one. It's still a label and we can use very simple way to implement.
But the ISD in https://datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa/__;!!NEt6yMaO-gk!VvyxGcx5k7uU0lELz7nl2Q5YfQhBAbZhdLOM4dHqfWUFDq6bor50CE9BKmM1l2Q$> is not that case.
You simply assume all ISD could be processed. If we look into it deeply, there are a lot of questions regarding to ISD.
What's the MSD capability you considered(5 or 6 or so)? What's the use case from the use case document you want to use ISD?
How many data you are going to put into the ISD without exceeding the MSD? What if the ISD exceed the MSD?
For an end to end path as indicated in the SR stack, if you do not put the data into PSD, you need to repeat put ISD in the stack multi times. How many times you would expect?
In this case at least PSD is necessary so that the end node know what to do.
If at least two ISDs put in the stack, this will occupy the already constrained MSD. This will also at least impact the egress node.
With so many issues, together with those I raised in the my first mail in this thread, I can only conclude the ISD is a fancy design but really useless, even harmful.


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

ZTR2> You simply assume the ISD could be processed. But you do not well consider the scenario and the whole solution. And you cannot guarantee the ISD will not exceed the MSD.
As you mentioned, if ISD exceed the MSD, you also asserted, below, that the problem would be solved by not imposing ISD.

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

ZTR2> I know a set of new terms are introduced in the new framework draft when Tony joined. What's the difference to the terms already in MAID? What's the value/benefit to introduce and use the new terms? Does these all really discussed? Are there any consensus in the minute? I do not actually care about any terms only if I can understand. But do not consider creating new terms is the contribution to the community. They cannot really solve problem.

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
ZTR2> You said "Tony has been making for the past few email iterations". But you still not answer my question. Please make any statement based on the fact.
And let me clarify. I support PSD, and hope PSD would be included. I just oppose to ISD.


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