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

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

Hi,

That is certainly not the intent.  We will need the same structure even if we decide that all ancillary data is post-stack.  This is what you pointed out in our NSH discussion.

Sent from my iPhone

On Apr 22, 2022, at 2:01 PM, Haoyu Song <[e-mail]> wrote:



[External Email. Be cautious of content]

   *  Network Action Indication (NAI): An indication in the packet that
      a certain network action is to be perfomed.  There may be
      associated ancillary data in the packet.

   *  Network Action Sub-Stack (NAS): A set of related, contiguous Label
      Stack Entries (LSEs).  The first LSE contains the NAI.  The TC and
      TTL values in the sub-stack may be redefined.  The label field in
      the second and following LSE may be redefined.  Solutions MUST NOT
      redefine the S bit.


Hi John,

Apart from many discussions on whether or not “sub stack” is proper to describe its behavior, the above definition does couple NAI and ISD together, which has a strong implication on a particular solution.  I don’t think the framework document should fortify it for now for reasons I have explained in the previous email.

Best regards,
Haoyu

From: John E Drake <[e-mail]>
Sent: Friday, April 22, 2022 10:37 AM
To: Haoyu Song <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; Stewart Bryant <[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

No, the network actions specified in the sub-stack define whether there is in-stack or post-stack ancillary data.
Sent from my iPhone


On Apr 22, 2022, at 1:11 PM, Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:

[External Email. Be cautious of content]

Hi John,

Thanks for the explanation. Do you mean NAS only means to indicate and include a sub stack but it has nothing to do with PSD?

Best regards,
Haoyu

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 22, 2022 10:08 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[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,

It’s up to the definition of a network action whether that action requires ancillary data, what is that ancillary data, and whether that ancillary data is in-stack or post-stack.

The network actions sub-stack consists of an identifier indicating a sub-stack, the network actions to be performed on the packet, and the in-stack ancillary data, if any, for those network actions.
Sent from my iPhone

On Apr 22, 2022, at 1:00 PM, Haoyu Song <[e-mail]<mailto:[e-mail]>> wrote:

[External Email. Be cautious of content]

Hi John,

I think the terse statement doesn’t help to advance the discussion. It’s better to provide more explanation for your opinion.

I’m with Jie and think the current term binds together the indicator and the ISD prematurely. When it’s still in doubt that if ISD is necessary, it might be too early to force such a binding. A term always has its implications. I prefer to make it open and general at this stage. Thanks!

Best regard,
Haoyu


From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of John E Drake
Sent: Friday, April 22, 2022 5:48 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Cc: [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

Tony has already proposed and defined network action sub-stack indicator which is exactly right.

Yours Irrespectively,

John



Juniper Business Use Only
From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 22, 2022 6:08 AM
To: Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Cc: John E Drake <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[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 Stewart,

Thanks for sharing your opinion.

One of my concern is that there are two types of indicators, and they cannot be represented using the same term.

   - The first one (call it indicator-1) is used to indicate the presence of any non-forwarding-label information in the packet. As discussed it may be realized as a bSPL. It does not indicate the type of actions to be performed.

   - The second type of indicator (call it indicator-2) is used to indicate the presence of a specific type of action. Such action may or may not have associated data with it.  This may be realized as a Flag or an action type in the packet.

The semantics and processing of the above two indicators are different, thus we need two separate terms for them.

Perhaps we can call the first one Ancillary Information Indicator (if you think “data” is specific to the parameters), and the second one Network Action Indicator. I’m open to the terms as long as we agree that we need two of them.

Best regards,
Jie

From: Stewart Bryant [mailto:[e-mail]]
Sent: Thursday, April 21, 2022 10:21 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Stewart Bryant <[e-mail]<mailto:[e-mail]>>; John E Drake <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[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 Jie

On 18 Apr 2022, at 16:23, Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>> wrote:

Hi John,

The diffs show that the term ADI was in the previous versions of the requirements document, and just replaced by NAI in the latest version:

https://www.ietf.org/rfcdiff?url2=draft-bocci-mpls-miad-adi-requirements-04.txt<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Frfcdiff*3Furl2*3Ddraft-bocci-mpls-miad-adi-requirements-04.txt__*3B!!NEt6yMaO-gk!UhgTylz3aWWV1_HnrZtQUhs1LldCoOPeHMUA-T0r9xeepnzpXNIPTfRVbyI1f0s*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7Cf8bffb79942449084e8e08da245e7f38*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862285567696478*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3D8LoXhTVLL8pN*2BAT7fxFRcglccAA3Hty8kLoh71cMhLM*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SimYKO4tIdXkt1zFTdSZJ57R0hDQpceC6U6qhLnI9AGCuiXIfrNFXqfQ_vmt_g4*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C345db177521448d3490708da2482b637*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862441087426516*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3D7yQVTqVumKKIyZMFlf4G7xr0IDkRLQGOXzbzvvjcBVk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ta49RApersjK2Z1QCZeSwNFM4ZYG_aiMW7rCIGu2jhI9DVoN6_J0mDB5QgRzp2Q*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C53023cda2d8e42fd8ef608da2486beb3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862458420895609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=ec4rHQeIOsTPV2SwnBbjTUL545cSg8QFlUYMIEFQYbk*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!RfuqgmBUefy0h8CD21GTqGTCHFNv9HAyVto27Whg83uTGuI6k3dnqeHhlrn2Vho$>

No it is more than just a name change. There is a concept change and we re-wrote a bunch of text to align with the NAI approach. For example an NAI may not have AD to indicate.


And the draft name still shows that the requirements were originally on ADI.

We agreed that for continuity this should be changed on adoption.


As Robert and I mentioned, the term ancillary data is generic and refers to all types network actions information, including those with and without additional action data.  Thus NAI can be considered as one type of ancillary data.

No an action is an action (a doing thing) and data is a parameter of qualifier to such an action.

Of course you can have an ADI with null data but you have to explain that each time. The NAI is a cleaner concept.


And ADI is the indicator of the presence of ANY non-label information in the MPLS packet.

Yes, but note that it is a DATA indicator not an action indicator and there may be no data.

I think that this has become a discussion on the precise semantics of various English expressions rather that an engineering discussion on how this will work and what its utility is. I would very much like to move from the English to the engineering.

Best regards

Stewart


Following it there may be indicators of each specific network action. And my understanding is the requirements in section 3.2 was mainly on the ADI.




Best regards,
Jie

From: John E Drake [mailto:jdrake=[e-mail]]
Sent: Monday, April 18, 2022 10:02 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: [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,

I just checked and the term ‘ancillary data indicator (ADI)’ is *not* used in the requirements draft.

Yours Irrespectively,

John


Juniper Business Use Only
From: John E Drake
Sent: Monday, April 18, 2022 8:24 AM
To: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: [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

Jimmy,

I think it was Matthew who noted that the requirements draft initially focused too much on ancillary data rather than on network actions and that ancillary data is actually a characteristic of a network action.  I.e., when you define a network action, you define, among other things, whether it has ancillary data, what is that ancillary data, and whether the ancillary data is in-stack or post-stack.  Given this, there is no need for an ancillary data indicator and we should probably retire the term.

Yours Irrespectively,

John


Juniper Business Use Only
From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Monday, April 18, 2022 6:37 AM
To: Robert Raszuk <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: [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 Greg and Robert,

Thanks for the discussion. I agree with Robert’s interpretation and analysis here.

It is also my understanding that the definition of ADI and NAI are different.  ADI is used to indicate that there is information in addition to the legacy label stack in the packet, while NAI is used to indicate a certain type of network action. The existence of NAI and the optional data associated with the action need an indicator, which is the ADI.

Best regards,
Jie

From: Robert Raszuk [mailto:[e-mail]]
Sent: Monday, April 18, 2022 6:03 AM
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: 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 Greg,

Yes indeed both definitions are very different.

AD definition treats anything new to the current label stack as an optional add-on == ancillary while NAI treats only optional parameters or metadata associated with newly defined actions as ancillary.

Basically two different perspectives :)

Cheers,
R.



On Sun, 17 Apr 2022 at 23:57, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,
thank you for sharing your understanding of these terms. I believe, quite strongly, that synchronizing our interpretations of terms, building a clear unambiguous dictionary is essential to progressing any collaborative project. Let's see how this discussion goes.
There may be some further tightening of the dictionary in the framework document as NAI(ADI) defined as follows:
Network Action Indication (NAI): An indication in the packet that a certain network action is to be perfomed. There may be associated ancillary data in the packet.
That definition led me to my understanding of the relationship between indicators and ancillary data.

Regards,
Greg

On Sun, Apr 17, 2022 at 8:01 AM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

> As I understand it, some network actions may not have ancillary data associated.

I was under the impression reading Jie's note that actions *itself* are the Ancillary Data. Your definition of "Ancillary Data" seems to be limited to action parameters or metadata which is likely why you draw such conclusions.

See the definition which clearly supports my understanding of it:


Ancillary Data (AD): Data relating to the MPLS packet that may be

      used to affect the forwarding or other processing of that packet,

      either at an Label Edge Router (LER) [RFC4221] or Label Switching

      Router (LSR).  This data may be encoded within a network action

      sub-stack (see below) (in-stack data), and/or after the bottom of

      the label stack (post-stack data).

Best,
Robert.


On Sat, 16 Apr 2022 at 02:33, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jie,
thank you for your detailed analysis. I have a question about the use of ADI vs. NAI in our documents. As I understand it, some network actions may not have ancillary data associated. If that is correct, referring to these actions as Ancillary Data Indicators might be confusing to a reader. Should these network actions be referred to as no-Ancillary Data Indicators (NADI)? That seems confusing to me even more. I find NAI being a logical generic term that clearly characterizes network actions that don't have ancillary data associated as well as network actions that have associated ancillary data. In my opinion, it is the definition of the particular network action that defines the required behavior and associates it with any data that we refer to as ancillary data. I am supporting the change in terminology and using NAI in our documents, including the requirements draft.

What do you think?

Regards,
Greg

On Thu, Apr 14, 2022 at 8:13 PM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

Thanks to the authors for the effort on this document. I believe this is useful work which will help to guide the framework and solution design.

Compared to the previous version (-03), there are many changes in the recent update, which takes some time to give it a review. And I suggest people to also check the diffs from the previous version.

Please find below some of my comments and suggestions to this document, and I'd appreciate the authors' thoughts.

1. It is a good start that the requirements are classified into 3 categories:

        - General Requirements
        - Requirements on ADIs
        - Requirements on Ancillary Data

Since the requirements are driven by the use cases, rather than the on-going framework or candidate solutions, it is important and reasonable to keep using the general terms "Ancillary Data Indicator" and "Ancillary Data" in the requirements, and remove the solution specific terms (such as ISD, PSD, NAS) from this document.

2. In this version the term "Ancillary Data Indicator" is changed to "Network Action Indicator". While there is some difference between the definition of the two terms:

Ancillary Data Indicator (ADI): A indicator in the MPLS label stack that ancillary data exists in this packet.  It MAY also indicate the specific type of the ancillary data.

Network Action Indication (NAI): An indication in the packet that a certain network action is to be performed.  There may be associated ancillary data in the packet.

The above definition shows that ADI firstly is the indicator of the existence of the ancillary data, and optionally can be the indicator of specific type of ancillary data.  While NAI is only the indicator of a certain type of network action.

Thus NAI cannot replace ADI directly in this document. I'd suggest to add the ADI back to the terminology section, and change all the NAI in section 3.2 back to ADI. If needed, the requirements on NAI can be added as separate items.

3. For backward compatibility and consistency, It is suggested to add the below items to section 3.1 as general requirements:

1) Solutions meeting the requirements set out in this document MUST be compatible with existing MPLS mechanisms.

2) Solutions meeting the requirements set out in this document MUST reuse existing MPLS mechanisms when possible.

3) For network actions which are developed or under development in IETF, the encoding and processing of the network action data MUST be reused.

Best regards,
Jie

> -----Original Message-----
> From: mpls [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Loa Andersson
> Sent: Wednesday, April 13, 2022 5:29 PM
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs
> <[e-mail]<mailto:[e-mail]>>
> Subject: [mpls] working group adoption poll on
> draft-bocci-mpls-miad-adi-requirements
>
> Working Group,
>
> This is to start a two week poll on adopting poll on
> draft-bocci-mpls-miad-adi-requirements
> as a MPLS working group document.
>
> THough we normally do two weeks pretty stric, in this case I have allowed a
> couple of extra days due to holliday season.
>
> Please send your comments (support/not support) to the mpls working group
> mailing list ([e-mail]<mailto:[e-mail]>). Please give a technical motivation for your
> support/not support, especially if you think that the document should not be
> adopted as a working group document.
>
> There is no IPRs disclosure against this document.
>
> The both authors have stated on the MPLS wg mailing list that they are
> unaware of any IPRs that relates to this document.
>
> The working group adoption poll ends May 2, 2022.
>
> /Loa
> --
> Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
> Bronze Dragon Consulting             phone: [phone]
>
> _______________________________________________
> mpls mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*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!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7Cf8bffb79942449084e8e08da245e7f38*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862285567696478*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DQtVogMnQquYkhFW2wnqlSokZ4sq7*2F4xqvkRvIuBPlIk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SimYKO4tIdXkt1zFTdSZJ57R0hDQpceC6U6qhLnI9AGCuiXIfrNFXqfQSQ27WDo*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C345db177521448d3490708da2482b637*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862441087426516*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3Dacbu46JCfSUr4mDyERKTuhhIWH7hEKx7AhCNfstIt4g*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ta49RApersjK2Z1QCZeSwNFM4ZYG_aiMW7rCIGu2jhI9DVoN6_J0mDB5gSoJ5jQ*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C53023cda2d8e42fd8ef608da2486beb3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862458420895609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=Mwb9fQGNJul1HSGwlXa*2BKRLQfIMGj4cW2Xu1Jr*2BQQW8*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!RfuqgmBUefy0h8CD21GTqGTCHFNv9HAyVto27Whg83uTGuI6k3dnqeHhd0hk0HY$>

_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*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!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7Cf8bffb79942449084e8e08da245e7f38*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862285567696478*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DQtVogMnQquYkhFW2wnqlSokZ4sq7*2F4xqvkRvIuBPlIk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SimYKO4tIdXkt1zFTdSZJ57R0hDQpceC6U6qhLnI9AGCuiXIfrNFXqfQSQ27WDo*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C345db177521448d3490708da2482b637*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862441087426516*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3Dacbu46JCfSUr4mDyERKTuhhIWH7hEKx7AhCNfstIt4g*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ta49RApersjK2Z1QCZeSwNFM4ZYG_aiMW7rCIGu2jhI9DVoN6_J0mDB5gSoJ5jQ*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C53023cda2d8e42fd8ef608da2486beb3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862458420895609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=Mwb9fQGNJul1HSGwlXa*2BKRLQfIMGj4cW2Xu1Jr*2BQQW8*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!RfuqgmBUefy0h8CD21GTqGTCHFNv9HAyVto27Whg83uTGuI6k3dnqeHhd0hk0HY$>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*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!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7Cf8bffb79942449084e8e08da245e7f38*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862285567696478*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DQtVogMnQquYkhFW2wnqlSokZ4sq7*2F4xqvkRvIuBPlIk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SimYKO4tIdXkt1zFTdSZJ57R0hDQpceC6U6qhLnI9AGCuiXIfrNFXqfQSQ27WDo*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C345db177521448d3490708da2482b637*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862441087426516*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3Dacbu46JCfSUr4mDyERKTuhhIWH7hEKx7AhCNfstIt4g*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ta49RApersjK2Z1QCZeSwNFM4ZYG_aiMW7rCIGu2jhI9DVoN6_J0mDB5gSoJ5jQ*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C53023cda2d8e42fd8ef608da2486beb3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862458420895609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=Mwb9fQGNJul1HSGwlXa*2BKRLQfIMGj4cW2Xu1Jr*2BQQW8*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!RfuqgmBUefy0h8CD21GTqGTCHFNv9HAyVto27Whg83uTGuI6k3dnqeHhd0hk0HY$>
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam11.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*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!UhgTylz3aWWV1_HnrZtQUhs1LldCoOPeHMUA-T0r9xeepnzpXNIPTfRVcvYEgeE*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7Cf8bffb79942449084e8e08da245e7f38*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862285567696478*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DKM*2BkQ44cJ6XM0*2BIZqkfzRxzK0slZSs5Eu73cqmXpem8*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!SimYKO4tIdXkt1zFTdSZJ57R0hDQpceC6U6qhLnI9AGCuiXIfrNFXqfQP2ytBzI*24*26data*3D05*7C01*7Chaoyu.song*40futurewei.com*7C345db177521448d3490708da2482b637*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862441087426516*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3DXqrzVFUp9Rs6bbJtUAj7JwxJG1oi*2F3qcg4n0La05QAs*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKiolJSoqKioqKioqKioqKioqKiUlKioqJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Ta49RApersjK2Z1QCZeSwNFM4ZYG_aiMW7rCIGu2jhI9DVoN6_J0mDB56gJjyK4*24&data=05*7C01*7Chaoyu.song*40futurewei.com*7C53023cda2d8e42fd8ef608da2486beb3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637862458420895609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=gVM8H8cHmO6ms4EqbTA6aWlr0lkrQCul6qakqshkpeU*3D&reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!RfuqgmBUefy0h8CD21GTqGTCHFNv9HAyVto27Whg83uTGuI6k3dnqeHhNcgD-9E$>