Re: [mpls] Thoughts on Ancillary Data Indicators.

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, July 8, 2021 12:40 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Loa Andersson <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: RE: [mpls] Thoughts on Ancillary Data Indicators.

[External Email. Be cautious of content]


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 <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 8, 2021 5:05 AM
To: Loa Andersson <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

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 <[e-mail]> On Behalf Of Loa Andersson
Sent: Thursday, July 8, 2021 5:11 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: [mpls] Thoughts on Ancillary Data Indicators.

[External Email. Be cautious of content]


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: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]
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$

Juniper Business Use Only

_______________________________________________
mpls mailing list
[e-mail]
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$

Juniper Business Use Only

Juniper Business Use Only