Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04

["John G. Scudder" <[e-mail]>]

On Jun 24, 2016, at 2:43 PM, John G. Scudder <[e-mail]> wrote:
> 
>> 1) Section 2, Protocol Extensions.
>> 
>> You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type' since that is
>> 
>> what any implementation would reasonably interpret it as, and that is the registry you are using a code point from. So it
>> 
>> might be better to say in the text above the figure at the top of page 3 that the length and type fields in [RFC4271]
>> 
>> are set to 0xFF.
> 
> Is your proposal to use the diagram verbatim from 4271, but say in the prose that the type and length are 0xFF? I'm fine with whatever seems clearer to folks.

Upon reviewing the draft, I prefer to leave the diagram as is. The context is that the diagram is preceded by "the OPEN message format is modified to be the following", and then the diagram is given:

...blah blah...
       |                         BGP Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0xFF     |      0xFF     |  Extended Opt. Parm. Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |             Optional Parameters (variable)                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

By contrast, here's the diagram from RFC 4271:

...blah blah...
       |                         BGP Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opt Parm Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |             Optional Parameters (variable)                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we want to keep the RFC 4271 diagram verbatim, I think quite a bit of rewrite would ensue and it probably wouldn't result in a more readable document, especially from the perspective of a person implementing the new spec. And of course, someone implementing stock 4271 doesn't need to refer to the draft. In looking back at your note, I think the disconnect is here:

>> You have labelled the existing Length and Type fields as 0xFF. I assume the meaning of the second is still 'Type' since that is
>> 
>> what any implementation would reasonably interpret it as, and that is the registry you are using a code point from. 

Upon consideration, I'd say no. In the context of the draft (as you point out, the proposed update to 4271), the two fields constitute a 16-bit field which, when set to all ones, indicates the next sixteen bits are to be used as a length field, and the sixteen bits after that to be used as a type field. In a legacy implementation, it's just as you say -- those sixteen bits are length and type.

My suggestion is instead of modifying the diagram, we could revise the prefatory text as follows.

OLD:
Accordingly, when the length of Optional Parameters in the BGP OPEN
message is greater than 255, the OPEN message format is modified to 
be the following:

NEW:
Accordingly, when the length of Optional Parameters in the BGP OPEN
message is greater than 255, the OPEN message format is modified as
follows, repurposing the Optional Parameters Length field as well as
the first Parameter Type field to indicate the use of the extended 
format:

Seem reasonable? The question is addressed to the entire WG, not just Matthew. In particular, it would be interesting to hear from implementors as to whether the spec is clear and unambiguous as to when and how to use the extended format.

Thanks,

--John