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

[Greg Mirsky <[e-mail]>]

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]> 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]>
> *Sent:* Thursday, April 21, 2022 1:46 PM
> *To:* John E Drake <jdrake=[e-mail]>
> *Cc:* Haoyu Song <[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 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://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%7C7f1d75d4771642c67f1108da23d7fbf2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637861707803494069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dhKRZALzsWh%2Bx69Owa7sLwWM2KwcObfei9CVXMjq6vQ%3D&reserved=0>
>
> _______________________________________________
> mpls mailing list
> [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%7C7f1d75d4771642c67f1108da23d7fbf2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637861707803494069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QPgGaUF8GVu8IjbnFN2bFck2NKQBRtfSgs7E3XZ22u8%3D&reserved=0>
>
>