Subject: Re: [Idr] [Technical Errata Reported] RFC5291 (3468)

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Feb 2013 18:54:45 +0000

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
IDR archive.

Stewart

On 23/01/2013 04:31, RFC Errata System wrote:
> The following errata report has been submitted for RFC5291,
> "Outbound Route Filtering Capability for BGP-4".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5291&eid=3468
>
> --------------------------------------
> Type: Technical
> Reported by: David Lamparter <[email-masked]>
>
> Section: 5
>
> Original Text
> -------------
> 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
>
>
>
> Corrected Text
> --------------
>
>
> 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
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5291 (draft-ietf-idr-route-filter-17)
> --------------------------------------
> Title               : Outbound Route Filtering Capability for BGP-4
> Publication Date    : August 2008
> Author(s)           : E. Chen, Y. Rekhter
> Category            : PROPOSED STANDARD
> Source              : Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: David Lamparter <[email-masked]>
Date: Wed, 6 Feb 2013 21:49:23 +0100

> I will close the errata with a pointer to this thread in the

Thanks for the reply.  I was hoping that there would be an easy fix,
maybe because the approach was clear from discussions back at the
creation of the draft, but, alas, no such luck it seems.

-David

> > "Outbound Route Filtering Capability for BGP-4".
[...]
> > capability will be supplied in more than instance".
[...]

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Fri, 8 Feb 2013 05:05:02 +0000

>>        Capability value: one or more of the entries as shown in Figure

I agree this needs clarification/correction in the RFC.

Should be similar to the wordings in RFC4760 for multi protocol extensions
capability:

   A speaker that supports multiple <AFI, SAFI> tuples includes them as
   multiple Capabilities in the Capabilities Optional Parameter.

This is what the current implementations do (those I'm aware of).

- Pradosh