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

["Jakob Heitz (jheitz)" <[e-mail]>]

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