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

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Apr 2020 02:52:30 +0000

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:[email-masked]]
Sent: Saturday, April 25, 2020 1:00 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>
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) ([email-masked]<mailto:[email-masked]>) 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.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 29 Apr 2020 22:48:17 -0400

Jie,

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

The pattern we normally want to see is "MUST be set to zero and SHOULD be
ignored on receipt".

By requiring it to be set, you have expectations for a compliant
implementation of a given draft.

By ignoring it on receipt, you permit the field to be used for something
further in the future.

The above is consistent with Postel's Maxim.

With regard to Juniper's implementation:
- In sections 4.2.1.1 and 4.2.1.2 for operators, we originate zeroes when
  generating new NLRI in the reserved bits and we ignore them on receipt.
  However, we also propagate what we are sent and use when we're not the
  originator of that NLRI.
- In section 7.3 (traffic action), we similarly originate only the two bits
  in question and zero the rest of the fields if we set the community, but
  otherwise ignore the rest of the bits on receipt.
- In section 7.5 (DSCP), we originate zero and ignore the top order bit and
  any other bits that should be zero.

However, there are related things you're not asking:
- If we receive two NLRI that are otherwise functionally equivalent but have
  the must-be-zero bits set differently, they are different NLRI per the
  memcmp rule.
- The BGP extended communities suffer the common curse of all "magic"
  communities: More than one such extended community is present, we will
  pick the "first" one for use, where first is the internal lexicographical ordering
  of the collection of extended communities (again, roughly memcmp order).  We
  will also propagate all such received communities.  

-- Jeff

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 30 Apr 2020 04:14:16 -0700

On April 29, 2020 at 10:41:32 PM, Jeffrey Haas wrote:

Jeff:

Hi!

...
> The above is consistent with Postel's Maxim.

That makes sense.

> However, we also propagate what we are sent and use when we're not the

To make sure I understand: if 0s are not received, you ignore the
value and process the NLRI.

Does this behavior also apply to §4.2.2.12 (Fragment)?

Thanks!

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 30 Apr 2020 07:30:34 -0400

Alvaro,

> value and process the NLRI.

At the risk of getting into further English ambiguity, we do not use the
contents of the fields but preserve them.

This detail is particularly important vs. BGP (or other protocol) features
since sometimes an implementation will discard the ignored value on
propagation.  It causes all sorts of interesting interop bugs. :-)

> Does this behavior also apply to §4.2.2.12 (Fragment)?

I'm personally unable to confirm that detail right now.  The full set of
code leaves BGP land and goes deep enough into our firewall implementation
that I can't follow it.

And that said, once I get an answer from the group one way or the other,
we'd be aiming for "ignore the MBZ fields".

A discussion point that was held across the 5575 endeavor is that we SHALL
find implementations that are not fully compliant with various details of
the draft.  This isn't because it's on purpose.  It's simply that we're
cleaning up a lot of edge cases and implementations will take time to come
into compliance.  This is a feature, not a bug of our process.

-- Jeff