Return-Path: X-Original-To: idr@mail2.ietf.org Delivered-To: idr@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 08C818F0348E for ; Sun, 23 Nov 2025 05:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3umFffl7leuw for ; Sun, 23 Nov 2025 05:31:26 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 500B88F03483 for ; Sun, 23 Nov 2025 05:31:26 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-64166a57f3bso5244044a12.1 for ; Sun, 23 Nov 2025 05:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1763904679; x=1764509479; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jcFcTSfYjIejj2ECQcEceAlAUZyniPpiRsjk+qwUj84=; b=NVZ7mkm/M0vEpgR42iLxhOMG0lpyTVQyHkqoVsFP+F4F6GzDs+YY60w46AGbPz7h4p 5IBKwNqYTZ6hNgpMH7/mMBM+x9FuCkYHVOZOP3IthQy0JD08aPrGKw4060gUDSRVcIa1 Oly5dSWa5LDH6s8OYQUy7cI3W818WBva/Rxr1rLvATHkBek+468JtaScanDkQUVGIBAc gAxpladuUZx3g14gNsaeUIn/cJx4y6tsPwse0svisZYd+/LkpUS6m2qRn73WYcNKRiYl 9LNckQnN5vZXNms7dTHnOugohjsTuMJ35Ut6DuvSbPPfVc62vHYLIPXOYPub5rD4WuoX lebg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763904679; x=1764509479; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jcFcTSfYjIejj2ECQcEceAlAUZyniPpiRsjk+qwUj84=; b=uHtWxxtyb5nYJjPjFeyel4nN3GY7ZaStxdyDrBxJhD3xIX/wU3BMkTH83YX+kVWGgu 10HbH9BVvLY4eBXTaJpL/7QIOLStkx3GPL1XfsF/ucZz8xnd3o0Uh1UVVfw94xlutjsV Us337WikyvF1d4Hbra+avttBDIgJPw5WwvhxhXp9xRVRdY+tS6aloMlTMuOsCZ+vmkwI bM7TLFQZgGmt3qr4DwIvlsOPEmolHNSPbmtU9Q/9a9a/HWk0/6jv9SvrONHC69Oibnpp RgtYb5lkh9Fm/8kYEyGhQH9csCqI+p5Nbr9t1v0mADygaOT53fDOGaIO270CkjRVV99D TUYw== X-Forwarded-Encrypted: i=1; AJvYcCWr6lMylairbE6H2+5Gg/pg7wkafmyYOhkMsYlNYIBGxU4op0sploAsalaRKtviCi3ET5A=@ietf.org X-Gm-Message-State: AOJu0YxDqlDJ2F/7f+NJyF6uY8igssU+NSIujr1MfbkJt+tKJjqlDOCL dSL3DvKlKbphfz9m01VpSH+zshnq7mJIjD/n1K5Xnlw6nMRIqN/+ddSvSwNlU9aumdxROtfqsuk syFE1U7x/8Asq2sL62Oyk6zORbKqPgkWjPGGgfleVvm1SFCmT5C6+ X-Gm-Gg: ASbGncupfzNuke+NKEH5ffusOejRCi+uGYbxeTZl2qjEBpr16fUGxHkDlm+S4IzkaYf a6l+1yJNIdl2btuBTxbpI+KPG9HGIES7+DLyXd6VCgQyaKJeCPd5sNK1idXj+taWnoL3qEmuhgu 7ejxhJJmYTosFuetvhyHEYJ8IDMUQYm/CUZEKMeyEEUbcSpv855j6Crr0w5CBLYC1/KVnI6ewQf lL6wrzgFmfMUUgZhH7g0orhdEsMvKV1I9exeaX0g79mBnKxkOdDebMW/3kHkawg5lK6p/8cSeyt HMTPXg== X-Google-Smtp-Source: AGHT+IHEHuIcReFMVei/5gXv6gyskLxp1C42+RZ9kpIU3ZCP4vjAc+20QDoBqC0OL2jfHVt7GxjKk6GeIwZAQNSxOEk= X-Received: by 2002:a05:6402:4302:b0:640:980c:a952 with SMTP id 4fb4d7f45d1cf-64554335c5bmr8242140a12.11.1763904678275; Sun, 23 Nov 2025 05:31:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sun, 23 Nov 2025 14:31:07 +0100 X-Gm-Features: AWmQ_bk5QDqEADBlROWhYNSmKDLR5gBR9eyV1ZCF-k6QUrmLtLSr1ScnIIg8des Message-ID: To: Dmytro Shypovalov Content-Type: multipart/alternative; boundary="000000000000c43ad00644430f51" Message-ID-Hash: E6A4BIH2KODUUYH7YJ5J4SPYFYYX2NT3 X-Message-ID-Hash: E6A4BIH2KODUUYH7YJ5J4SPYFYYX2NT3 X-MailFrom: robert@raszuk.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: bruno.decraene@orange.com, Kyrylo Yatsenko , "idr@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_RFC_8277_clarifications?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c43ad00644430f51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dmytro, Have you perhaps considered using MPLS Label Stack Sub-TLV as described in section 3.6 of RFC9012 ? Thx, Robert On Sun, Nov 23, 2025 at 2:08=E2=80=AFPM Dmytro Shypovalov wrote: > Hi Bruno, thanks for your response. > > BGP-SRTE is definitely a more superior protocol and as an SR-TE controlle= r > developer, I always prefer it whenever possible. However, many router > implementations don't support BGP-SRTE and BGP-LU is a nice workaround th= at > is widely supported. And it's definitely better than PCEP (anything is > better than PCEP). > > I just wanted to clarify this behaviour, because the discussion came up > when Kyrylo was implementing multiple labels support in FRR and discovere= d > this limitation, but it's never mentioned in the RFC. > > Regards, > Dmytro > > On Thu, 20 Nov 2025 at 09:27, wrote: > >> Hi Dmytro, >> >> >> >> Thanks for your message. >> >> Please see inline my 2 cents >> >> >> >> *From:* Dmytro Shypovalov >> *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 advertis= e >> host routes, which given max 255 bits of NLRI, leaves us with theoretica= l >> 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=E2=80=A6 >> >> (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=E2=80=A6) of more than one labe= l.) >> >> 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-L= U? >> >> >> >> 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 ( =F0=9F=98=89 ), 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 confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ > Idr mailing list -- idr@ietf.org > To unsubscribe send an email to idr-leave@ietf.org > --000000000000c43ad00644430f51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dmytro,

Have you perhaps considered = using MPLS Label Stack Sub-TLV as described=C2=A0in section 3.6 of RFC9012 = ?

Thx,
Robert

On Sun, Nov 23, 2025 at 2:08=E2=80=AFPM Dmytro Shypovalov <dmytro@vegvisir.ie> wrote:
Hi Bruno, tha= nks for your response.

BGP-SRTE is definitely a more sup= erior protocol and as an SR-TE controller developer, I always prefer it whe= never possible. However, many router implementations don't support BGP-= SRTE and BGP-LU is a nice workaround that is widely supported. And it's= definitely better than PCEP (anything is better than PCEP).=C2=A0

I just wanted to clarify this behaviour, because the discu= ssion came up when Kyrylo was implementing multiple labels support in FRR a= nd discovered this limitation, but it's never mentioned in the RFC.

Regards,
Dmytro

On Thu, 20 Nov 2025 = at 09:27, <bruno.decraene@orange.com> wrote:

Hi Dmytro,

=C2=A0

Thanks for your message.=

Please see inline my 2 cents=

=C2=A0

From: Dmytro Shypovalov <dmytro@vegvisir.ie>
Sent: Wednesday, November 19, 2025 11:19 PM

=C2=A0

Dear IDR WG,<= /u>

=C2=A0

I've been working o= n an SR-TE project using BGP-LU to influence traffic engineering paths. Thi= s requires the advertisement of multiple labels.

=C2=A0

RFC8277 seems to have 2= conflicting statements

=C2=A0

Section 2.1:<= /u>

=C2=A0 

=C2=A0=C2=A0 the Count is the maximum<=
/u>
=C2=A0=C2=A0 number of labels that the BG=
P speaker sending the Capability can
=C2=A0=C2=A0 process in a received UPDATE=
 of the specified AFI/SAFI.=C2=A0 If the Count
=C2=A0=C2=A0 is 255, then no limit has be=
en placed on the number of labels that
=C2=A0=C2=A0 can be processed in a receiv=
ed UPDATE of the specified AFI/SAFI.

=C2=A0

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

=C2=A0

This probably needs to be read = as an additional limit. (in addition to some other constraints, e.g., the o= ne you described below)

We need to consider that BGP LU= was originally specified in RFC 3107. That BGP capability has been added b= y 8277 as a patch, mostly to accommodate some non-compliant implementations= if you ask me.

=C2=A0

Section 2.3:<= /u>

=C2=A0 

=C2=A0=C2=A0 - Length:

=C2=A0


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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 length in =
bits of the remainder of the NLRI field.


=C2=A0


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bits in th=
e Label field, plus 3 bits in the Rsrv field, plus 1 S


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bit).

=C2=A0

If we use BGP-LU with m= ultiple 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 I= Pv4 and 5 labels for IPv6. The RFC message format will not be able to support mor= e labels, regardless of platform capabilities.

=C2=A0

Alas=E2=80=A6

(note that at the time of RFC 3= 107, that was probably considered as good enough. To the point that some im= plementations did not even allow the emission (fine) and reception (less fi= ne=E2=80=A6) of more than one label.)

RFC 8277 could have revisited a= few things, but did not (presumably to minimize the impact on existing imp= lementation, among other things)

=C2=A0

Bu= t I've seen vendor implementations advertising multi label capability w= ith more labels.

=C2=A0

Cf above: we should probably as= sume that the minimum of all limits is to be used: min (capability sig, enc= oding space)

=C2=A0

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

=C2=A0

I guess that we could always de= fine a new spec to revisit the whole thing, but that would imply a large ef= fort and sufficient interest (read $$) from enough parties.

In the meantime ( = =F0=9F=98=89 ), have you considered the adverti= sement of SR Policies in BGP https://datatracker.ietf.org/doc/html/rfc9830 ?

=C2=A0

Regards,

--Bruno

=C2=A0

=C2=A0

Regards,<= /p>

Dmytro 

______________________________________________________________________=
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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.
_______________________________________________
Idr mailing list -- idr@i= etf.org
To unsubscribe send an email to idr-leave@ietf.org
--000000000000c43ad00644430f51--