Subject: [bess] BGP CAR SAFI NLRI format

From: Srihari Sangli <[email-masked]>
Date: Wed, 14 Jul 2021 10:34:45 +0000

Hello,

Looking at the archives on this topic, there was a small discussion about the structure of the NLRI as proposed in the BGP CAR draft. The conversation was not conclusive and here’s my thought and a question related to the topic.

While the proposed NLRI format enables NLRI types to be encoded and provides extensibility, it also lists the key and non-key fields. If we go down this path, there may be a tendency to add more fields into the NLRI. While ‘Type-specific Key Fields’ may be justifiable (for obvious reasons of identifying the NLRI), the ‘Type-specific Non-Key Fields’ has a potential to grow.

Also, this is a departure from base BGP specification of NLRI and attributes where attributes carry the common information and non-key fields. Am wondering if the authors have done more investigation on this. Thanks.

srihari…

Juniper Business Use Only

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 14 Jul 2021 15:17:14 +0200

Hey Srihari,

While you are right in the notion of original BGP spec I think the
definition of what is key for someone remains very loose.

Just take a look at RFC5575 where key is defined as opaque bit string :)

   This NLRI is treated as an opaque bit string prefix by
   BGP.  Each bit string identifies a key to a database entry with which
   a set of attributes can be associated.

Best,

Robert

On Wed, Jul 14, 2021 at 12:35 PM Srihari Sangli <ssangli=
[email-masked]> wrote:

> Hello,
>
>
>
> Looking at the archives on this topic, there was a small discussion about
> the structure of the NLRI as proposed in the BGP CAR draft. The
> conversation was not conclusive and here’s my thought and a question
> related to the topic.
>
>
>
> While the proposed NLRI format enables NLRI types to be encoded and
> provides extensibility, it also lists the key and non-key fields. If we go
> down this path, there may be a tendency to add more fields into the NLRI.
> While ‘Type-specific Key Fields’ may be justifiable (for obvious reasons of
> identifying the NLRI), the ‘Type-specific Non-Key Fields’ has a potential
> to grow.
>
>
>
> Also, this is a departure from base BGP specification of NLRI and
> attributes where attributes carry the common information and non-key
> fields. Am wondering if the authors have done more investigation on this.
> Thanks.
>
>
>
> srihari…
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>