Re: [mpls] Thoughts on Ancillary Data Indicators.

[[e-mail]]

Hi Loa,

1 clarification question.

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

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

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: Thursday, July 8, 2021 11:11 AM
> 
> 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]

_________________________________________________________________________________________________________________________

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.