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

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

Robert,

That was actually the initial design, but the control plane overhead was considered to be excessive.  Either way, an RFC will be needed.

Yours Irrespectively,

John



Juniper Business Use Only
From: Robert Raszuk <[e-mail]>
Sent: Thursday, April 21, 2022 4:55 PM
To: Greg Mirsky <[e-mail]>
Cc: John E Drake <[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,

Let's observe that PLR can use a different label range to mark protected packets - pretty easy to do so especially with the concept of domain wide labels.

Hence no need for any special marking anywhere in the stack nor NAS insertion to accomplish the goal.

And 100% backwards compatible with existing MPLSv1 data plane.

Yes the down side is no new RFC needed - sorry about that :).

Cheers.
R.

On Thu, 21 Apr 2022 at 22:46, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
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://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$>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!ReIkcIVJNqlusWNcrXRWP10_Vkvitzh2Z4r6RJ__DiL600rhiBtM-UWrA5LOzX0$>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!ReIkcIVJNqlusWNcrXRWP10_Vkvitzh2Z4r6RJ__DiL600rhiBtM-UWrA5LOzX0$>