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

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

Hi Jeff, 

Thanks a lot for your reply, and sorry for the delay in response. Please see inline:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, April 30, 2020 10:48 AM
> To: Dongjie (Jimmy) <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; IDR List <[e-mail]>;
> [e-mail]
> Subject: Re: [Idr] Poll on the RFC5575bis implementations about the
> suggested changes during IETF review
> 
> 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.

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.

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

> 
> 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?

Best regards,
Jie

> 
> -- Jeff