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

[Jeffrey Haas <[e-mail]>]

Jie,

On Wed, Apr 29, 2020 at 02:52:30AM +0000, Dongjie (Jimmy) wrote:
> 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…”.

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