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

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 <gregimirsky@gmail.com> 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=
> 40juniper.net@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>>
>>
>> Comments inline below.
>>
>>
>>
>> Yours Irrespectively,
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* Haoyu Song <haoyu.song@futurewei.com>
>> *Sent:* Thursday, April 21, 2022 12:37 PM
>> *To:* John E Drake <jdrake@juniper.net>
>> *Cc:* Tony Li <tony.li@tony.li>; Dongjie (Jimmy) <jie.dong@huawei.com>;
>> mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org;
>> draft-bocci-mpls-miad-adi-requirements@ietf.org; DetNet Chairs <
>> detnet-chairs@ietf.org>
>> *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 <jdrake@juniper.net>
>> *Sent:* Wednesday, April 20, 2022 12:54 PM
>> *To:* Haoyu Song <haoyu.song@futurewei.com>
>> *Cc:* Tony Li <tony.li@tony.li>; Dongjie (Jimmy) <jie.dong@huawei.com>;
>> mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org;
>> draft-bocci-mpls-miad-adi-requirements@ietf.org; DetNet Chairs <
>> detnet-chairs@ietf.org>
>> *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 <haoyu.song@futurewei.com>
>> *Sent:* Wednesday, April 20, 2022 2:18 PM
>> *To:* John E Drake <jdrake@juniper.net>
>> *Cc:* Tony Li <tony.li@tony.li>; Dongjie (Jimmy) <jie.dong@huawei.com>;
>> mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org;
>> draft-bocci-mpls-miad-adi-requirements@ietf.org; DetNet Chairs <
>> detnet-chairs@ietf.org>
>> *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 <jdrake@juniper.net>
>> *Sent:* Wednesday, April 20, 2022 10:04 AM
>> *To:* Haoyu Song <haoyu.song@futurewei.com>
>> *Cc:* Tony Li <tony.li@tony.li>; Dongjie (Jimmy) <jie.dong@huawei.com>;
>> mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org;
>> draft-bocci-mpls-miad-adi-requirements@ietf.org; DetNet Chairs <
>> detnet-chairs@ietf.org>
>> *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 <haoyu.song@futurewei.com>
>> 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
>> mpls@ietf.org
>>
>> 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
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>