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

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