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

[Robert Raszuk <[e-mail]>]

Hi John,

The initial design may have assumed hop by hop LDP label distribution. I am
talking about domain wide labels which vastly simplify the scenario.

Not sure about RFC ... maybe informational or BCP at best :)  No extension
to control plane IMHO is required.

Yours,
R.





On Thu, 21 Apr 2022 at 23:06, John E Drake <[e-mail]> wrote:

> 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]> 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]> wrote:
>
> 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]>
> *Sent:* Wednesday, April 20, 2022 12:54 PM
> *To:* Haoyu Song <[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
>
>
>
> Hi,
>
>
>
> Comments inline below.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Haoyu Song <[e-mail]>
> *Sent:* Wednesday, April 20, 2022 2:18 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]*
>
>
>
> 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]>
> *Sent:* Wednesday, April 20, 2022 10:04 AM
> *To:* Haoyu Song <[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
>
>
>
> 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]> 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]
>
> 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]
> 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]
> https://www.ietf.org/mailman/listinfo/mpls
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!ReIkcIVJNqlusWNcrXRWP10_Vkvitzh2Z4r6RJ__DiL600rhiBtM-UWrA5LOzX0$>
>
>