Internal inconsistency of handling reserved bits

[boucadair]

https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/0cda9b95957203599f9418b0781d5575eab75557/draft-ietf-idr-bgp-ct.txt#L925C1-L926C27

This is not aligned with this part:

Reserved: A 2-octet reserved bits. That MUST be set to zero on transmission. This field SHOULD be ignored on reception and left unaltered.

[neonatty]

In the initial draft, this was aligned. This text for "Reserved" was modified after review from Jeff Haas (IDR Chair). We will work with Jeff to ascertain this discrepancy.

[neonatty]

@jhaas-pfrc , During your review, you had asked us to realign the above shown "Reserved" MUST/SHOULD clause from the initial clause of "That SHOULD be set to zero on transmission. This field MUST be ignored on reception and left unaltered." @boucadair mentions this as a discrepancy with 8277 NLRI "Resv" bits MUST/SHOULD clause. Could you please clarify why?

[kalirajv]

@boucadair , in Section 6, removed the rfc-8277 nlri layout example that was added for convenience. Like you had suggested in a previous comment.

[jhaas-pfrc]

@jhaas-pfrc , During your review, you had asked us to realign the above shown "Reserved" MUST/SHOULD clause from the initial clause of "That SHOULD be set to zero on transmission. This field MUST be ignored on reception and left unaltered." @boucadair mentions this as a discrepancy with 8277 NLRI "Resv" bits MUST/SHOULD clause. Could you please clarify why?

The behavior we need to see for new features is that version 1 of a feature MUST set it to zero, and SHOULD ignore it. This is because version 2 might set it to non-zero and version 1 needs to accept it, but version > 1 needs to know that version 1 was sending a consistent value rather than arbitrary (or user-configured) noise.

[neonatty]

@boucadair, please let us know if we can retain the SHOULD/MUST clause for "Reserved" field in TC Route Target Extended Community the same based on the above clarification from @jhaas-pfrc?

[kalirajv]

Hi Med (@boucadair ),

Following up on this issue. The reasoning given by Jeff explains the thought process behind the current handling of reserved bits in https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-16.html#section-4.3

And, we have removed the duplication of RFC-8277 text, and put a reference to RFC-8277 instead.

With these, please let us know if we can close this issue.

Thanks Kaliraj

[boucadair]

Thanks for removing the duplicate text.

For the MUST/SHOULD thing, as soon as you provide an example in the text when it is safe to (e.g., when it is safe to alter the receive content), then this is OK.

[kalirajv]

Reserved: A 2-octet reserved bits. That MUST be set to zero on transmission. This field SHOULD be ignored on reception and MUST be left unaltered.

Does this sound better? @boucadair and @jhaas-pfrc ?

I think Jeff's intent of putting a 'SHOULD be ignored on reception' was that we should be able to policy match on reserved bits in an old version, when a new version uses those bits. But I think it must still leave it unaltered. So does the above look better to both of your viewpoints?

Thanks Kaliraj

[kalirajv]

@boucadair, while we wait for Jeff to reply, do you agree with the proposed text?

Reserved: 2-octet reserved bits. This field MUST be set to zero on transmission. This field SHOULD be ignored on reception and MUST be left unaltered.

Wanted to check with you on what you think.

Thanks Kaliraj

[boucadair]

That's better. thanks.

[kalirajv]

Closing: https://mailarchive.ietf.org/arch/msg/idr/CrbnjpACHPMwb-so5XBdU6S2Hag/