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

[Haoyu Song <[e-mail]>]

Greg,

Unless I misunderstood what Stewart said this morning for my question, that’s my impression for NFFRR so far.
BTW, I don’t recall there’s any discussion about multiple different NAI/NAS in a packet and don’t know how it will work.

Best regards,
Haoyu
From: Greg Mirsky <[e-mail]>
Sent: Thursday, April 21, 2022 2:21 PM
To: Haoyu Song <[e-mail]>
Cc: John E Drake <jdrake=[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

Hi Haoyu,
I may not see a case for an intermediate node re-writing the existing NAI. I think that the node should impose a new NAS. I see the case for an intermediate node writing into PSD (e.g., HbH IOAM though I think that is too expensive and the IOAM Direct Export or Hybrid Two-Step are a better choice). To summarize, I don't see the need for an intermediate node to write into ISD and am open to discussing the node writing into PSD.
WDYT?

Regards,
Greg

On Thu, Apr 21, 2022 at 2:12 PM Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

I’m not familiar with NFFRR. All my questions in the other email is based on the following abstraction:

It’s an packet-by-packet data-plane action
It’s an action that can be updated on a path (i.e., its data is writable enroute)

These are sufficient to help us to think about the operational implications, if use cases bearing such characteristics would be allowed. Thanks!

Best regards,
Haoyu
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 21, 2022 1:46 PM
To: John E Drake <jdrake=[e-mail]<mailto:[e-mail]>>
Cc: Haoyu Song <[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 John and Haoyu,
I have several questions about the NFRR use case. As I understand it, a point of local repair (PLR) imposes NAS with the NFRR indicator so that it becomes ToS at the merge node (MN). If that is correct, then the MN will remove the NAS with the NFRR indicator as the packet is returned on the "normal" path. Hence, I don't see why an intermediate node would need to write into an existing in the label stack NAS in support of NFRR.

Regards,
Greg

On Thu, Apr 21, 2022 at 12:53 PM John E Drake <jdrake=[e-mail]<mailto:[e-mail]>> wrote:
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://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%7Cd4a5ea4ed3e64c0e0af608da23dcd91d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637861728713135321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XdpQSjBT1rn71VD57DtFtCYzmHG0wNIsdKth8agSWvA%3D&reserved=0>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C01%7Chaoyu.song%40futurewei.com%7Cd4a5ea4ed3e64c0e0af608da23dcd91d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637861728713135321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xilE%2FWf0bfzdnlMZMVaR1UqSu2vfUmZN%2BNuDMElZaiQ%3D&reserved=0>