Changes between Version 2 and Version 3 of RFC 5492, Capabilities Advertisement with BGP-4


Ignore:
Timestamp:
Jul 6, 2016, 11:15:32 AM (3 years ago)
Author:
jgs@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RFC 5492, Capabilities Advertisement with BGP-4

    v2 v3  
    22
    33* Section 4 talks about how "BGP speakers MAY include more than one instance of a capability ... with different Capability Value". The historical reason for this is because RFC 4760 specified that the MP-BGP capability be advertised like that, multiple instances of the capability, one for each AFI/SAFI. However, it was the authors' intent to discourage such idioms in the future, preferring to put all necessary data into a single capability as TLVs barring a reason to do otherwise. In any case, people writing documents that introduce new capabilities need to be clear about exactly how their capability is supposed to be formatted – either as TLVs within a single instance of the capability, or as multiple capabilities.
     4* Section 5 mentions that when sending an Unsupported Capability NOTIFICATION, "Each such capability is encoded in the same way as it would be encoded in the OPEN message." The intent here is that each individual capability should be encoded. There is no need to encode the Optional Parameter Type 2 ("Capabilities") header itself, since the Unsupported Capability notification is particular to Capabilities anyway, it's implicit.