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

[Jeffrey Haas <[e-mail]>]

Jie,

On Wed, May 06, 2020 at 04:10:03PM +0000, Dongjie (Jimmy) wrote:
> > > 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.
> 
> Both descriptions work for me, and both can be found in existing RFCs. 
> 
> Perhaps my understanding to Postel’s Maxim is slightly different (I'm not a native English speaker:), to me "MUST be ignored" aligns more with "be liberal in what you accept", as the reserved Flags are always ignored, hence always accepted on receipt.

Your understanding is a valid one.

Where the story is perhaps easier to understand is think about it from the
perspective of the feature that then uses these bits.  There are two inputs:
- If you are expecting to be talking to a conformant v1 of a specification
  that says "MUST be set to zero", your expectation is that it is safe to
  use these bits for the next version of a thing, because:
- Conformant v1 will ignore it when that is no longer true. 

If you have the reverse:
- If you are expecting that the values SHOULD be set to zero in v1, it is
  the same as saying they may be otherwise in v1.
- If you are saying that they MUST be ignored, in v2 you're saying don't
  ignore some of them.  Is that okay given the uncertainty for v1 vs v2?

This is a very subtle area.  It would be nice if IETF chooses one.

Regardless of the language, our desire is v1 leaves them as zero and pays no
attention to them so that v2 can set them and v1 doesn't care.

> > 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.
> 
> Thanks for providing the implementation information. 
> 
> I'd also like to provide information about Huawei's implementation, the behavior is similar: The reserved bits are set to zero on originator, and are ignored on receipt. Also the reserved bits are kept unchanged when the route is further propagated. 

We have similar behavior then.

This is another point worth putting into a FAQ because the behavioral
changes for originating vs. propagating can be confusing to new people.

> > 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.
> 
> Both the above cases you mentioned are valid, and IMO they reflect generic issues which deserve some further discussion. Based on discussion, maybe we could produce a set of generic rules related to the setting, receipt and processing of the reserved fields in both NLRI and BGP attributes, or even other protocols. Such rules could provide guidance for the specification of the reserved fields in future.
> 
> What do you think?

I agree.

-- Jeff