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= 40juniper....@dmarc.ietf.org> 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… > > > > Juniper Business Use Only > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
