Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Kireeti,

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

From: Kireeti Kompella [mailto:kireeti.ietf@gmail.com]
Sent: Monday, July 12, 2021 10:43 PM
To: Loa Andersson <loa@pi.nu>
Cc: mpls@ietf.org; pals-chairs@ietf.org; spring-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
Subject: Re: [mpls] Thoughts on Ancillary Data Indicators.

Hi Loa,

See inline.

On Thu, Jul 8, 2021 at 2:11 AM Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> wrote:
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.

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.

- 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.

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

   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.

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: loa@pi.nu<mailto:loa@pi.nu>
Senior MPLS Expert                          loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com>
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls

_________________________________________________________________________________________________________________________

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.