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

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

[removed rtg-dir from cc, seemed excessive]

-05 posted which I believe addresses all comments to date. Please take a look. I've adjusted the diagram per (my understanding of) Matthew's comments. I'm ambivalent about it -- I'm not sure it's clearer, but I did manage to increase the page count :-o. I could go either way, if you have a distinct preference please say so.

--John

> On Jun 27, 2016, at 3:24 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> Fine. Works for me.
> 
> Thanks,
> Jakob.
> 
>> -----Original Message-----
>> From: John G. Scudder [mailto:[e-mail]]
>> Sent: Monday, June 27, 2016 11:53 AM
>> To: Jakob Heitz (jheitz) <[e-mail]>
>> Cc: Enke Chen (enkechen) <[e-mail]>; [e-mail]; [e-mail]; [e-mail];
>> Bocci, Matthew (Nokia - GB) <[e-mail]>; Susan Hares <[e-mail]>
>> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
>> 
>> On Jun 27, 2016, at 1:26 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
>>>> -----Original Message-----
>>>> From: John G. Scudder [mailto:[e-mail]]
>>>> Sent: Monday, June 27, 2016 9:25 AM
>>>> To: Jakob Heitz (jheitz) <[e-mail]>
>>>> Cc: Enke Chen (enkechen) <[e-mail]>; [e-mail]; [e-mail]; draft-ietf-idr-ext-opt-
>> [e-mail];
>>>> Bocci, Matthew (Nokia - GB) <[e-mail]>; Susan Hares <[e-mail]>
>>>> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
>>>> 
>>>> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
>>>>> 
>>>>> "An optional parameter with parameter type of 0xFF MUST NOT appear in the
>>>>> list of optional parameters other than in first place and if it does appear,
>>>>> then the optional parameters length MUST be 0xFF."
>>>> 
>>>> And it's a fatal error if it's not?
>>> 
>>> Absolutely. As you say, the session is not up yet.
>> 
>> I don't really mind doing this. I also don't mind not doing it, since it's basically a superfluous check -- the
>> Optional Parameter Type is sufficient to fully determine that the message uses the extended format. My slight
>> preference is for not doing it, since it's a few more lines of code (for the check), for a condition that is
>> exceedingly unlikely to occur, and doesn't matter if it does occur. So why spend the code?
>> 
>>>> (Remember this is before the session becomes established, so the principle of service survival above all that
>> would
>>>> applied in the error-handling spec doesn't apply.)
>>>> 
>>>>> There is really no reason to entertain other combinations and I don't
>>>>> want to have to write code to handle them.
>>>> 
>>>> Is there some reason insisting that the non-extended length field be 255 is better than ignoring it once you've
>>>> determined by inspection of the non-extended parameter type that the extended encoding is in use? The logic would
>> be,
>>>> if the (one byte, non-extended) parameter type = 255, then use the extended encoding, and ignore the one byte
>> non-
>>>> extended length field.
>>>> 
>>>> If we made this change, the spec would say, MUST send non-extended length as 255, MUST ignore on receipt if the
>>>> following eight bits (the non-extended type field) are 255.
>>> 
>>> To Enke's point, can we make the non-extended length at least 1?
>>> Legacy speakers...
>> 
>> Yes, you will see my suggestion was to make the length 255 on Tx (as you and Enke point out, it has to be >= 1, so
>> might as well choose 255 as any other value, and it jumps out nicely in a packet dump). Up for discussion was
>> whether to enforce the value on Rx, or ignore. You've spoken in favor of enforcing it, although I'm not sure what
>> the reason for your preference is.
>> 
>>> In addition: An otional parameter of type 255 MUST NOT appear in the
>>> list of optional parameters other than in first place.
>> 
>> Good point, thanks. I'll work something like that in.
>> 
>>> Should we set a maximum length of 4k?
>>> There will always be smaller boxes wishing to speak BGP that will never support extended messages.
>> 
>> I'm inclined to leave this alone -- if you can fit in <= 4k you will. If you can't fit in <= 4k, a peering with such
>> a box isn't going to work regardless. So either it'll be fine anyway, or it won't work nohow.
>> 
>> --John