Re: [mpls] Thoughts on Ancillary Data Indicators.

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 <bruno.decraene@orange.com> wrote:

> 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:loa@pi.nu]
> > 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: loa@pi.nu
> > Senior MPLS Expert                          loa.pi.nu@gmail.com
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>