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 12:37 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,

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*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls__*3B!!NEt6yMaO-gk!WjmuV7E8Mw6rIaDBNoBzdrOb19V5QnD5ieOAlSqsS7ep5ruJ951hAkyCvczVMYI*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C187c0f73b908456a2fb208da23077580*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637860812193372183*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=*2FpaWE*2B0JpHUtCDirsbXMwvuDbdkuCIRD8Wfo1tfsyew*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!XPzXhO-cZxJqPSoPXdg6bHYTnKWeJBfjd_JoAz5kPjMZ5DMQZpxcHv5RjfhJx1o$>