Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

Hi!

As Rob mentioned, we talked about his DISCUSS during today’s IESG Telechat.

We’re all in agreement that the last thing we want to do is to break any
existing implementations, specially because this document is a bis.


I looked at rfc5575, and I didn’t find the same text there — I found no
specification of the setting of the bits, specially the reserved ones.

[I also did a quick and unscientific search of other routing documents and
found a mix of SHOULD/MUST and MUST/MUST constructs…]


Note that there are two distinct cases (in rfc5575bis):

(1) A bit is defined as 0, but the definition is: "0 -  SHOULD be set to
0…” (§4.2.1.1).  If it’s 0, then I see no reason for that not to be a
MUST.  In fact, if always set to 0 we’re probably over specifying the
field.   There are 3 occurrences of this in the document.

(2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST
be ignored”.  Again, if unused/reserved, I see no reason not to change to
MUST.  I think Rob makes a good point about extensibility.


Before any changes, and in the spirit of not breaking anything, we should
check whether anyone has an implementation what would be impacted.  I
assume/hope that the prototype implementations have already been fixed.

Jie:  As Shepherd, can you please do a quick poll of the people who
reported implementations to confirm that these changes won’t have an
impact?


Thanks!

Alvaro.





On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilton) ([e-mail])
wrote:

> Your question is a good one:
> But I don't understand why that means the
> sender is a "SHOULD be 0" not a "MUST be 0"?
>
> This text is inherited from RFC5575.
>
> Originally (which is not in any document)
> this was set because prototype implementations of
> RFC5575 had set it to a 1 during a rushed deployment.
>
> Whether these implementation still exist in the
> smaller boxes boxes from major vendors - I do not know.
>
> One of the habits of IDR is not to break existing BGP.
[RW]
Yes, and I fully support that pragmatic aim.