[Idr] Re: RFC 8277 clarifications

[[e-mail]]

Hi Dmytro,

Thanks for your message.
Please see inline my 2 cents

From: Dmytro Shypovalov <[e-mail]>
Sent: Wednesday, November 19, 2025 11:19 PM


Dear IDR WG,

I've been working on an SR-TE project using BGP-LU to influence traffic engineering paths. This requires the advertisement of multiple labels.

RFC8277 seems to have 2 conflicting statements

Section 2.1:


   the Count is the maximum

   number of labels that the BGP speaker sending the Capability can

   process in a received UPDATE of the specified AFI/SAFI.  If the Count

   is 255, then no limit has been placed on the number of labels that

   can be processed in a received UPDATE of the specified AFI/SAFI.

This assumes the BGP update can have up to 255 labels (in theory).

This probably needs to be read as an additional limit. (in addition to some other constraints, e.g., the one you described below)
We need to consider that BGP LU was originally specified in RFC 3107. That BGP capability has been added by 8277 as a patch, mostly to accommodate some non-compliant implementations if you ask me.

Section 2.3:


   - Length:



      The Length field consists of a single octet.  It specifies the

      length in bits of the remainder of the NLRI field.



      Note that for each label, the length is increased by 24 bits (20

      bits in the Label field, plus 3 bits in the Rsrv field, plus 1 S

      bit).

If we use BGP-LU with multiple labels for SR-TE, it will always advertise host routes, which given max 255 bits of NLRI, leaves us with theoretical maximum of 9 labels for IPv4 and 5 labels for IPv6. The RFC message format will not be able to support more labels, regardless of platform capabilities.

Alas…
(note that at the time of RFC 3107, that was probably considered as good enough. To the point that some implementations did not even allow the emission (fine) and reception (less fine…) of more than one label.)
RFC 8277 could have revisited a few things, but did not (presumably to minimize the impact on existing implementation, among other things)

But I've seen vendor implementations advertising multi label capability with more labels.

Cf above: we should probably assume that the minimum of all limits is to be used: min (capability sig, encoding space)

Am I missing something? Is there a way to advertise more labels in BGP-LU?

I guess that we could always define a new spec to revisit the whole thing, but that would imply a large effort and sufficient interest (read $$) from enough parties.
In the meantime ( 😉 ), have you considered the advertisement of SR Policies in BGP https://datatracker.ietf.org/doc/html/rfc9830 ?

Regards,
--Bruno


Regards,
Dmytro
____________________________________________________________________________________________________________
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.