IDR not S-IDR ? (or I missed the tie-in to S-IDR...)
On 02/06/2013 01:47 PM, Stewart Bryant wrote: > The following errata was filed, but this is beyond the scope > of an errata system to address. > > I think that the right process is for the WG to decide the answer > and if necessary for someone to write up a short update to > RFC5291 > > I will close the errata with a pointer to this thread in the > SIDR archive. > > Stewart > > > Errata ID: 3468 > > *Status: Reported > Type: Technical > * > Reported By: David Lamparter > Date Reported: 2013-01-22 > > Section 5 says: > > 5. Outbound Route Filtering Capability > > > A BGP speaker that is willing to receive ORF entries from its peer, > or a BGP speaker that would like to send ORF entries to its peer, > advertises this to the peer by using the Outbound Route Filtering > Capability, as described below. > > The Outbound Route Filtering Capability is a new BGP Capability > [BGP-CAP] defined as follows: > > Capability code: 3 > > Capability length: variable > > Capability value: one or more of the entries as shown in Figure 3. > > +--------------------------------------------------+ > | Address Family Identifier (2 octets) | > +--------------------------------------------------+ > | Reserved (1 octet) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (1 octet) | > +--------------------------------------------------+ > | Number of ORFs (1 octet) | > +--------------------------------------------------+ > | ORF Type (1 octet) | > +--------------------------------------------------+ > | Send/Receive (1 octet) | > +--------------------------------------------------+ > | ... | > +--------------------------------------------------+ > | ORF Type (1 octet) | > +--------------------------------------------------+ > | Send/Receive (1 octet) | > +--------------------------------------------------+ > > Figure 3: Outbound Route Filtering Capability Encoding > > Notes: > > RFC5291 does not specify how the ORF capability is supposed to be used > in conjunction with multiple enabled AFI/SAFI combinations. The text > can be interpreted as either "one capability instance will be sent, > carrying multiple blocks as described in Figure 3" or as "the > capability will be supplied in more than instance". > > Note also that RFC3392 [BGP-CAP] Section 4 reads: > > BGP speakers MAY include more than one instance of a capability (as > identified by the Capability Code) with non-zero Capability Length > field, but with different Capability Value, and either the same or > different Capability Length. Processing of these capability > instances is specific to the Capability Code and MUST be described in > the document introducing the new capability. > > Latter description of how multiple instances of the capability are to be > processed - albeit relatively obvious - is nowhere to be found in RFC5291. > > > Respectfully requesting a clarification, > > David Lamparter > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
