[Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review

["Dongjie (Jimmy)" <[e-mail]>]

Hi all,

As you may have noticed, during the IETF review of draft-ietf-idr-rfc5575bis, there was some discussion about the description of bit/flag settings in this draft.

Based on the discussion in IESG, our AD Alvaro suggested to make following changes to the draft:

(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.

In summary, it is suggested that in the bit/flag descriptions, “SHOULD be set to 0…”  is replaced with “MUST be set to 0…”.

Before making those changes, we’d like to poll the implementers (especially who reported their implementations to IDR before) about whether such changes can have an impact to your implementation.

This poll will last for one week and end on May 6th. Looking forward to your feedbacks. Thanks.

Best regards,
Jie

From: Alvaro Retana [mailto:[e-mail]]
Sent: Saturday, April 25, 2020 1:00 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; The IESG <[e-mail]<mailto:[e-mail]>>
Subject: RE: Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

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]<mailto:[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.