Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

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

Hi,

Comments inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Haoyu Song <[e-mail]>
Sent: Thursday, April 21, 2022 4:40 PM
To: John E Drake <[e-mail]>
Cc: Tony Li <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

[External Email. Be cautious of content]

Hi John,

Thanks for the explanation.
My understanding is that the reason to have multiple copies of NAS is due to the reachability concern. It’s assumed a node can only reach the first copy.
Now it’s also said that NFFRR in NAS could be set/reset on the path, which means it needs to be written to all the NAS copies for correctness. But the other NAS copies except the first one is assumed unreachable. So this doesn’t work.
Alternatively, one may choose to update the next NAS in the stack when popping the current one. But this needs extra in-stack operation (comparing and copying, not too much different from reinserting a new NAS).

[JD]  As I indicated, these are all issues for the NFFRR RFC to address

There are some other issues about the multi-copy idea. How does one know when and where to push a new copy (given devices may all have different capability)? What procedures need to be done (the label stack size keeps changing on the path, so the NAS copy pushing must be a dynamic process and can happen on any node)?

[JD]  Following the procedures pf RFC 8662, the ingress node, based upon information in the IGP, calculates where within the label stack copies of the NAS need to be placed.  Transit nodes do not perform NAS copy pushing

What’s the overhead (one advantage claimed by ISD is its compactness, but only one copy will nullify this)?

[JD]  I don’t recall this claim being made.  Rather, I think the claim was that a node would be able to access the NAS with its in-stack ancillary data expeditiously.  This is directly related to the issue, as described in RFC 8662, that a node may not be able to find the bottom of stack.  If it can’t find the bottom of stack, it certainly can’t find post-stack ancillary data

These are all from the operational point of view, in addition to the parsing performance issues which I have talked a lot in previous emails. I think all of these need to carefully reviewed and evaluated by the WG.

Best regards,
Haoyu


From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 21, 2022 12:53 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi,

Comments inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 21, 2022 12:37 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

[External Email. Be cautious of content]

Hi John,

You have described quite a bit of the behavior of NAS. It’s useful for future discussions. Thanks.

[JD]  You are most welcome, and I would like to apologize for the abrupt tone of my last several emails to you.  I just wasn’t thinking.

According to the DT discussion today, more are understood.  So I have some further questions.
NAS is something within the label stack but writable by intermediate nodes. Is this the stack operation?

[JD]  I think that this will be defined in the RFC which specifies a given network action.  As we discussed today, that is probably the case for NFFRR.

Besides, if NAS emerges at ToS, you said it’ll be popped and discarded. What if the NAS also needs to be applied to the labels below it? Whatever measures you will take here, are those the stack operations?

[JD]  What we have said is that the node which removes the forwarding label which would cause an NAS to rise to the top of stack must remove the NAS.  Per RFC 8662, there would be multiple copies of an NAS within the label stack so that subsequent nodes will operate on the next copy, until that copy would rise to the top of stack, at which point that copy is removed, and so on.  In today’s meeting, Tarek indicated that
for certain use cases we might have different NASes at different positions within a label stack.

Also, as we have noted, the NAS does not require the use of in-stack ancillary data.  If we were to decide that all network action were to be done with post-stack ancillary data, we would  still use the NAS to indicate the presence of post-stack ancillary data


Best regards,
Haoyu

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 20, 2022 12:54 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi,

Comments inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 20, 2022 2:18 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

[External Email. Be cautious of content]

John,

Can you name “a single entity” as “sub-stack” which implies more than one entities?

[JD]  A label is either an instruction or parameters associated with an instruction – think ELI/EL.  A NAS is simply a set of instructions and their associated parameters

In essence, the NAS is a new header which is inserted into MPLS label stack under the constraints of the MPLS label format. It has nothing to do with a label (so “sub” to what?).

[JD]  I don’t think you have been paying attention.  All NAS is doing is following the paradigm described above, but compressing the instructions and their parameters in order to conserve label stack space.  This is not rocket science

And the operation on it is certainly not a “stack operation” as well. It’s embedded in the label stack. You scan the label stack to reach it, parse it, and process it. When it emerge on the ToS, we still don’t know the behavior for handling it yet. Reinsert it to somewhere in the label stack? Whatever it is, this is not “stack operation”.

[JD]  This is nonsense.  The NAS  exactly follows the MPLS label stack paradigm.  It will rise to the top of the stack and then be popped.  It is not re-inserted into the label stack.  It exactly follows the model of RFC  8662

Best regards,
Haoyu

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 20, 2022 10:04 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Haoyu,

If you consider the NAS as a single entity it is completely consistent with the definition of a stack.  I think this remark is spurious and non-productive.

John
Sent from my iPhone

On Apr 20, 2022, at 12:58 PM, Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:

[External Email. Be cautious of content]


I propose Network Action Sub-stack Indcator (NSI) for this purpose.  Proposed definition:

                            An LSE used to indicate the presence of a Network Action Sub-stack.

We should also revise the definition of NAS to use this.


Hi Tony,

Stack means “first in last out”. It is used for MPLS label stack to describe the label processing procedure.
The encoded ISD is neither labels any more nor a stack in any sense, so both “sub” and “stack” are improper terms in my opinion. Thanks.

Best regards,
Haoyu

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WjmuV7E8Mw6rIaDBNoBzdrOb19V5QnD5ieOAlSqsS7ep5ruJ951hAkyCvczVMYI$<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls__*3B!!NEt6yMaO-gk!WjmuV7E8Mw6rIaDBNoBzdrOb19V5QnD5ieOAlSqsS7ep5ruJ951hAkyCvczVMYI*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C187c0f73b908456a2fb208da23077580*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637860812193372183*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3D*2FpaWE*2B0JpHUtCDirsbXMwvuDbdkuCIRD8Wfo1tfsyew*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!XPzXhO-cZxJqPSoPXdg6bHYTnKWeJBfjd_JoAz5kPjMZ5DMQZpxcHv5RjfhJx1o*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C68c206dfee114adf15c408da23d09308*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637861676006072288*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=DbKxnTITpukLR1M3b05cwhdigplTbG0ISdsDTZDbb8o*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKiUlKioqKioqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!WIRIIFr7OtdVSfudrstTwDHnZwARgdvbU_VzZ37LCqRVeMqnQvLFYB95E4nyM_U$>