Subject: [Idr] BGP per-destination state

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Mar 2022 16:01:33 -0400

Working Group,

As we work through the proposals for BGP routes with color, a discussion
point that's been raised has been about what we do with per-destination
state.  This discussion is particularly relevant for BGP-CAR, but Kaliraj
suggests that it is a more general point.

The relevant points of discussion are motivated from
draft-dskc-bess-bgp-car-03, sections 2.9.1/2.9.2 for "Type-specific Non-Kye
Fields".  In BGP-CAR, this field carries state that is similar to BGP
Labeled Unicast's label stack or other similar nexthop state.

The general motivation to want to use this form of encoding is to try to
maximize route packing.  While our protocol elders, several of whom are now
retired, didn't leave explicit notes in their RFCs about why they chose to
put labels next to the destination, we accept that it was done to enable
packing.

It's generally observed among implementors of BGP that maximimizing packing
and reducing total number of BGP Updates permits implementations to scale
better.  This avoids both per-packet framing overheads for I/O, but also
reduces cost of Path Attribute parsing and data structure construction.

For Internet purposes, packing is understood to be a modest optimization at
this point.  If you get 10 or more prefixes in a single Update, that's a lot.

For VPN and transport (BGP-LU, and similar) purposes, packing can often be
significant.  Distinct Path Attribute tuples are minimized.

draft-ietf-bess-srv6-services shows an interesting example of the lengths
we're trying to go to in order to achieve good packing: A non-varying
portion of the state is kept in the Path Attributes section while a tightly
coupled varying section is put in the traditional labels section.  This has
semantic overload considerations along with Error Handling considerations in
case the Path Attribute properties get decoupled for some reason.

At the polar opposite of such heroic efforts, bgpsec would force us to have
no Update packing at all.

BGP-CAR also motivates a related conversation: the TLVs have transitivity,
and one scope of such transitivity is nexthop change.  Working Group
participants are aware that such scoping behaviors are a common review point
I raise.

Kaliraj suggests during his presentation that rather than trying harder to
push for packing at the cost of encoding complexity that the desired
behaviors may belong in a different mechanism.  At least one suggestion is:

https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/

I find it important to also note that the BGP tunnel ecapsulation attribute
also has simliar properties applicable to this discussion:

https://www.rfc-editor.org/rfc/rfc9012.html

This thread is to try to get discussion on this topic.  This discussion will
likely influence how BGP-CAR moves forward if it is adopted as a Working
Group draft.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Mar 2022 22:09:45 +0100

Hi Jeff,

I would like to a little bit further highlight why VPN demux label has been
part of NLRI.

The primary motivation was indeed packing, but also common sense. Mostly
used (at that time) and in fact default label allocation mode fro L3VPNs in
some vendor was per prefix label allocation. That essentially meant that
you can not use any other label placement in an update as most VPN routes
coming from a given site to a VRF would likely share all other BGP path
attributes. So while in theory you could limit your packing to 1 net per
msg - in practice it would look not too well.

Clearly you could not use multi nexthop idea as all were coming from the
same next hop.

And the same here .. I do believe color should be per prefix. In fact I am
pretty sure we will see requests to have color more granular then that as
even per prefix is too coarse. Single prefix may run several apps and data
plane requirements for those apps are usually very different.

Kind regards,
Robert

On Tue, Mar 22, 2022 at 9:01 PM Jeffrey Haas <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Sun, 27 Mar 2022 16:34:41 +0000

Agree that with L3VPN per-prefix-label, packing will break, when we carry forwarding-information as an attribute. But there are other scaling problems with L3VPN service per-prefix-label, because of which it is not a preferred deployment model. And actually not even supported in some implementations.

When forwarding is indeed shared amongst different L3VPN prefixes (‘per table label’ or ‘per CE-nexthop label’), then packing will happen, even when we carry forwarding-information scoped as an attribute.

Also, want to clarify - Multi-NH attribute can be used to carry 1 or more nexthops. It doesn’t need to be “more than 1”.

Another case where Multi-NH will help is to reduce RIB-scale in Addpath deployments. Because multiple nexthops can be advertised in one route itself, instead of multiple BGP routes.

For more granular cases, Flowspec routes can be carried with “Redirect-IP-Nexthop + Color-community” today or more naturally the “Multi-NH attribute” to express forwarding over tunnels of specific colors. Using Multi-NH allows expressing multiple redirect nexthop addresses in a more natural way.

So I feel Multi-NH (carrying forwarding semantics as attribute) helps in more general cases, even though it may hurt packing in the historic “L3VPN-service family per-prefix-label” case.

Thanks,
Kaliraj

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, March 22, 2022 at 2:09 PM
To: Jeffrey Haas <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] BGP per-destination state
[External Email. Be cautious of content]

Hi Jeff,

I would like to a little bit further highlight why VPN demux label has been part of NLRI.

The primary motivation was indeed packing, but also common sense. Mostly used (at that time) and in fact default label allocation mode fro L3VPNs in some vendor was per prefix label allocation. That essentially meant that you can not use any other label placement in an update as most VPN routes coming from a given site to a VRF would likely share all other BGP path attributes. So while in theory you could limit your packing to 1 net per msg - in practice it would look not too well.

Clearly you could not use multi nexthop idea as all were coming from the same next hop.

And the same here .. I do believe color should be per prefix. In fact I am pretty sure we will see requests to have color more granular then that as even per prefix is too coarse. Single prefix may run several apps and data plane requirements for those apps are usually very different.

Kind regards,
Robert

On Tue, Mar 22, 2022 at 9:01 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Working Group,

https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/__;!!NEt6yMaO-gk!UEmbHBbcfY8JcSjS4ndol318Jzs8LlU4Fa4zUbCljUgvNe1ydp-UjQX3DWM7Ctap$>

https://www.rfc-editor.org/rfc/rfc9012.html<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9012.html__;!!NEt6yMaO-gk!UEmbHBbcfY8JcSjS4ndol318Jzs8LlU4Fa4zUbCljUgvNe1ydp-UjQX3DW1S5GnR$>

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!UEmbHBbcfY8JcSjS4ndol318Jzs8LlU4Fa4zUbCljUgvNe1ydp-UjQX3DX301MmU$>

Juniper Business Use Only