Subject: [mpls] Thoughts on Ancillary Data Indicators.

From: Loa Andersson <[email-masked]>
Date: Thu, 8 Jul 2021 11:10:59 +0200

Design Team,

We have discussed how to carry ancillary data in  in an MPLS packet and 
how to include indicators on the presences of such data in the label 
stack since the design team started. I think we have some convergence 
and that it is time to float an idea that could be the basis for a 
consensus. Please note that the actual consensus call will be made on 
the mpls wg mailing list, while this is for discussion preparing such a 
consensus call in the design team.

The proposals we have for indicators often rely on assignment of a base 
special purpose label. The number of such labels are limited.

I think we can agree on the following:

- We want to limit the number of new assignments of base special purpose
   labels as much as possible

- We have a standardized associated channel, the GAL/GACH. We are not
   going to change the associated channel. The associated will remain as
   specified in RFC 5586. The ACH is found immediately after the label
   carrying the Bottom of Stack (BoS) bit.

- We therefore need a (base) special purpose label to serve as the
   forwarding action indicator carrier.

- It is attractive to "re-purpose" the ELI to also fill the role as a
   general (generic?) forwarding action indicator. This may be done by
   using the TTL and TC fields of the ELI as flags indicating which
   service is requested.

   However, in order to do this it must be shown that there is no
   potential interference between the normal service supplied by the
   ELI/EL and the services indicated by the flags.

- If we can't demonstrate the non-interference then we should assign
   specific forwarding indicator action base special purpose label and
   leave the ELI/EL unchanged.

- The flag field of the re-purposed ELI of the the specially assigned
   forwarding action indicator label must be made extendable. These
   labels "only" have 11 bits (8 bit TTL and 3 bit TC fields) that can
   be used as flags. Already in the very preliminary discussions we have
   had so far are almost using all the 11 bits, making the it necessary
   to make the indicator extendable.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 8 Jul 2021 12:04:49 +0000

Hi Loa,

In one of the earlier email/discussion I believe someone mentioned that as long as a GAL is present, then the data after BoS is to be interpreted as  GACH.

Unless we can say for certain that GAL/GACH will never co-exist with other ancillary data, it seems that we'll have to do one of the following:

1. A new base special label will indicate the presence of ancillary data, and existing GACH will be indicated by either GAL or this new base special label.
2. The GAL with existing nibble+version covers existing GACH, and GAL with a new nibble+version covers both existing GACH and new ancillary data.

My wiki page is based on #2.

Jeffrey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Thursday, July 8, 2021 5:11 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Thoughts on Ancillary Data Indicators.

[External Email. Be cautious of content]

Design Team,

/Loa

--

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!VuvG_Q5kaZ2CiTnO7sHS7AIkYrIbWwQ-e-EeXkqlKwHeVKVxfOvQVBbhpiduhFD4$

Juniper Business Use Only

---

From: <[email-masked]>
Date: Thu, 8 Jul 2021 12:25:07 +0000

Hi Loa,

1 clarification question.

>    to make the indicator extendable.

Do you mean 11 possible use of a flag, or 11 simultaneous use of the 11 flags within one network?
Given that MPLS is used within a trusted administrative domain, the semantic of these bits could be defined on a per administrative domain basis. This could allow for the definition/standardization of 10s of usages, with the restriction of only allowing 11 running within on AS/network.

Thanks,
Regards,
--Bruno

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Thursday, July 8, 2021 11:11 AM
> 
> Design Team,
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Jul 2021 13:28:36 +0000

Loa,

Another possibility is to have an FAI special purpose label in which the TTL/TC bits are intact followed by another label in which the TTL/TC bits are also intact but in which the twenty bit label field has been turned into a set of twenty bit flags.

Yours Irrespectively,

John

> We have discussed how to carry ancillary data in  in an MPLS packet and how to
> include indicators on the presences of such data in the label stack since the
> design team started. I think we have some convergence and that it is time to
> float an idea that could be the basis for a consensus. Please note that the actual
> consensus call will be made on the mpls wg mailing list, while this is for
> discussion preparing such a consensus call in the design team.
> 
> The proposals we have for indicators often rely on assignment of a base special
> purpose label. The number of such labels are limited.
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-gk!TT41je-3_SvAKNifs5hqIDE9r8daiUPp6rJSGPeoxwsM10P_yX-
> zttu4FhZtw6E$

---

From: Haoyu Song <[email-masked]>
Date: Thu, 8 Jul 2021 16:40:06 +0000

I would prefer a solution for simplicity that GAL/GACH will never coexist with other ancillary data. I don't see a reason why they are both needed in a packet. After all, GAL is for control channel packet and EH is mainly used for serving user traffic.

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 8, 2021 5:05 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Loa,

Jeffrey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Thursday, July 8, 2021 5:11 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Thoughts on Ancillary Data Indicators.

Design Team,

We have discussed how to carry ancillary data in  in an MPLS packet and how to include indicators on the presences of such data in the label stack since the design team started. I think we have some convergence and that it is time to float an idea that could be the basis for a consensus. Please note that the actual consensus call will be made on the mpls wg mailing list, while this is for discussion preparing such a consensus call in the design team.

The proposals we have for indicators often rely on assignment of a base special purpose label. The number of such labels are limited.

/Loa

--

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls__%3B!!NEt6yMaO-gk!VuvG_Q5kaZ2CiTnO7sHS7AIkYrIbWwQ-e-EeXkqlKwHeVKVxfOvQVBbhpiduhFD4%24&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C12211c3e40364a19695708d94208a49b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637613427156382446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=OcXJ2Gf6GxpoBfKp1idWpmISKs9OCfAAQChfxPsdqMw%3D&amp;reserved=0

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C12211c3e40364a19695708d94208a49b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637613427156382446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=17JV3otef1R0PJhFznpwelEUdTqlYEBHIWa1NljkhWg%3D&amp;reserved=0

---

From: Loa Andersson <[email-masked]>
Date: Sat, 10 Jul 2021 20:11:29 +0200

John,

Tou are right, this is an alternative.

However I tried not prescribe solutions, but address what we will 
require form such solutions.

It has be pointed out that I partly failed to dp and sometimes assumed a 
solution. It should be noted the the text is for discussion and 
improvement.

/Loa

--

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 12 Jul 2021 19:27:52 +0000

Not using GAL/GACH for EH is one thing, and different from whether we should from now on just use EH for everything ...

-----Original Message-----
From: Haoyu Song <[email-masked]>
Sent: Thursday, July 8, 2021 12:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: RE: [mpls] Thoughts on Ancillary Data Indicators.

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 8, 2021 5:05 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Loa,

Jeffrey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Thursday, July 8, 2021 5:11 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Thoughts on Ancillary Data Indicators.

Design Team,

/Loa

--

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls__*3B!!NEt6yMaO-gk!VuvG_Q5kaZ2CiTnO7sHS7AIkYrIbWwQ-e-EeXkqlKwHeVKVxfOvQVBbhpiduhFD4*24&amp;data=04*7C01*7Chaoyu.song*40futurewei.com*7C12211c3e40364a19695708d94208a49b*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637613427156382446*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=OcXJ2Gf6GxpoBfKp1idWpmISKs9OCfAAQChfxPsdqMw*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!XhC0tQ0281RpszxQP0ZebtPvHPmsce6-KXsrcLDikddss77GCpRtyjJBPHp5CIro$

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls&amp;data=04*7C01*7Chaoyu.song*40futurewei.com*7C12211c3e40364a19695708d94208a49b*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637613427156382446*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=17JV3otef1R0PJhFznpwelEUdTqlYEBHIWa1NljkhWg*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XhC0tQ0281RpszxQP0ZebtPvHPmsce6-KXsrcLDikddss77GCpRtyjJBPOIFPwXX$

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Jul 2021 13:42:49 -0700

Hi Loa,

See inline.

>    forwarding action indicator carrier.

The proposal in draft-kompella-mpls-mspl4fa does this, and at the same
time, collapses the requests of 5 or 6 SPLs to a single SPL.

>    using the TTL and TC fields of the ELI as flags indicating which

While I'd be happy if this was possible, backward compatibility MUST be
maintained without compromising functionality.

>    to make the indicator extendable.

Actually, the draft already had such an extension in place; the details
have been fleshed out a bit better in the new version (just posted).

The bit fields have changed as a consequence of my chat with Haoyu; some
have been removed, but more added, so all 11 bits have been used up. So the
extension header will be needed.

The -01 draft is clearer than the -00 draft on several fronts, and lists
issues needing resolution.  I'm sure more will come up after the MPLS WG
meeting.

Cheers,
Kireeti.

> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Jul 2021 13:57:01 -0700

Salut Bruno,

The current use of the 11 bits falls under "simultaneous use of 6 flags"
(plus an extension).

Certainly, the semantics of these bits/flags can be defined on a
per-administrative domain basis.  It complicates the implementation for the
vendor, though.  If we can agree on a set of flags common to most SPs/CSPs,
that would be a good start for the 6 flags.  The extensions flags could be
per-domain, and we have an idea for that (future version of draft).

Cheers,
Kireeti.

On Thu, Jul 8, 2021 at 5:25 AM <[email-masked]> wrote:

> Given that MPLS is used within a trusted administrative domain, the
> semantic of these bits could be defined on a per administrative domain
> basis. This could allow for the definition/standardization of 10s of
> usages, with the restriction of only allowing 11 running within on
> AS/network.
>
> Thanks,
> Regards,
> --Bruno
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 13 Jul 2021 14:56:53 +0000

Hi Kireeti,

Speaking as co-author of [1], please see inline [Bruno]

From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, July 12, 2021 10:43 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Loa,

See inline.

On Thu, Jul 8, 2021 at 2:11 AM Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:
Design Team,

The proposal in draft-kompella-mpls-mspl4fa does this, and at the same time, collapses the requests of 5 or 6 SPLs to a single SPL.

While I'd be happy if this was possible, backward compatibility MUST be maintained without compromising functionality.
[Bruno]  This proposition is explored in [1]. There indeed multiple metrics:
- compatibility: I agree that this is a MUST. My understanding is that [1] (section 2 is 1 page so a quick read) is backward compatible with the EL RFC and deployed implementations. (in particular, the TC and TTL fields of the ELI are unchanged). Do we have the same understanding or do you have concerns on this point?
- functionality: everything else been the same, the more functionality, the better. I agree that using the currently unused EL/ELI bits for flags/indicators has limitations in term of the number of flags that can be supported  (with a limit of 11 simultaneous flags). How many years of MPLS growth can we buy with that? And this may eventually be extended as you proposed with LS FAH and LS FAD.
- cost and time to deploy before been able to use it: to me that’s an important factor. The longer the time (years) and the bigger the constraints (on legacy platform) the higher the benefits must be in order to justify the interest in a new technology. But YMMV I guess. In my experience, incremental benefit with incremental deployment helps. MPLS EL was good on this, but even with this, MPLS EL took some time to be deployed
[1] https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id#section-2

Best regards,
--Bruno

Actually, the draft already had such an extension in place; the details have been fleshed out a bit better in the new version (just posted).

The bit fields have changed as a consequence of my chat with Haoyu; some have been removed, but more added, so all 11 bits have been used up. So the extension header will be needed.

The -01 draft is clearer than the -00 draft on several fronts, and lists issues needing resolution.  I'm sure more will come up after the MPLS WG meeting.

Cheers,
Kireeti.

/Loa

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Haoyu Song <[email-masked]>
Date: Tue, 13 Jul 2021 18:15:20 +0000

Technically I don't see any reason why it cannot be in that way. EH is generic and extensible. In addition to the normal traffic, it can also be used for control packets.

Haoyu

-----Original Message-----
From: Haoyu Song <[email-masked]>
Sent: Thursday, July 8, 2021 12:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: RE: [mpls] Thoughts on Ancillary Data Indicators.

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 8, 2021 5:05 AM
To: Loa Andersson <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Loa,

Jeffrey

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Thursday, July 8, 2021 5:11 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: [mpls] Thoughts on Ancillary Data Indicators.

Design Team,

/Loa

--

_______________________________________________
mpls mailing list
[email-masked]
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*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls__*3B!!NEt6yMaO-gk!VuvG_Q5kaZ2CiTnO7sHS7AIkYrIbWwQ-e-EeXkqlKwHeVKVxfOvQVBbhpiduhFD4*24%26amp%3Bdata%3D04*7C01*7Chaoyu.song*40futurewei.com*7C12211c3e40364a19695708d94208a49b*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637613427156382446*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26amp%3Bsdata%3DOcXJ2Gf6GxpoBfKp1idWpmISKs9OCfAAQChfxPsdqMw*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!XhC0tQ0281RpszxQP0ZebtPvHPmsce6-KXsrcLDikddss77GCpRtyjJBPHp5CIro%24&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf9a542353856422b8eb808d9456b27df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617148800795668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1cj2NzZHFUdqCzXaaFUjCnwErtePI9mNIZ%2Fy6D4xx9E%3D&amp;reserved=0

_______________________________________________
mpls mailing list
[email-masked]
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*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls%26amp%3Bdata%3D04*7C01*7Chaoyu.song*40futurewei.com*7C12211c3e40364a19695708d94208a49b*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637613427156382446*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26amp%3Bsdata%3D17JV3otef1R0PJhFznpwelEUdTqlYEBHIWa1NljkhWg*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!XhC0tQ0281RpszxQP0ZebtPvHPmsce6-KXsrcLDikddss77GCpRtyjJBPOIFPwXX%24&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf9a542353856422b8eb808d9456b27df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617148800795668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QqpeGl9YWe9p62P3dMuNBy35QoiybQQeNMswp3HGN%2FY%3D&amp;reserved=0