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

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

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]; [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