Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

[Ketan Talaulikar <[e-mail]>]

Hi John,

Thanks for your feedback and I agree that this is a somewhat odd situation.
I also agree with your proposed changes and can work on them as a co-author
of the IDR document.

Would you have any suggestions on how to address the remainder of your
concerns? Considering that this document is past WGLC in IDR, do you think
this content could move from the IDR to the SPRING document?

Thanks,
Ketan


On Wed, Feb 16, 2022 at 2:31 AM John Scudder <[e-mail]> wrote:

> Hi All,
>
> I just noticed that draft-ietf-idr-segment-routing-te-policy allocates,
> but doesn’t define, the “‘Color-only’ bits” from the Color Extended
> Community Flags. I have a few comments about this —
>
> - It’s quite unusual to do the allocation out of one document, but place
> the definition somewhere else, and in a document from a different WG no
> less. I can’t off-hand think of another IDR document that has done this.
> Unless there is a compelling reason not to provide the definition in-line,
> I think it should be provided here instead of referencing a different
> document.
> - The so-called “bits” are no longer flags, they’re a two-bit integer. I
> mean, it’s not wrong to say they’re still “bits” but only in the technical
> sense that everything we deal with in computing is bits. The two bits
> aren’t orthogonal, so they aren’t flags, as the name "Color Extended
> Community Flags” implies. So, it would be more appropriate to call this the
> “Color-only field”.
> - The text in Section 3 qualifies the use of the bits with “[w]hen the
> Color Extended Community is used for the purpose of steering the traffic
> into an SR Policy”. But the IANA registry doesn’t have any way of saying
> that the bits are only registered for this particular purpose. So, I think
> that clause is at best meaningless, and at worst misleading.
> - The lack of useful information in the IANA registration is unhelpful.
> Ideally, if the “bits” had actually been defined as flags, each flag would
> have been registered individually with a symbolic name that provided some
> hint about the semantics. Unfortunately I can’t think of anything more
> helpful to do than a rename, from "Color-only bits” to "Color-only field”.
>
> Suggested updates, to partly address the above points:
>
> - In Section 3:
>
> OLD:
>    When the Color Extended Community is used for the purpose of steering
>    the traffic into an SR Policy, two bits from the Flags field (as
>    defined in [I-D.ietf-idr-tunnel-encaps]) are used as follows:
> NEW:
>    Two bits are taken from the Color Extended Community Flags field (as
>    defined in [RFC9012]) and repurposed as a “Color-Only” field, as
> follows:
>
> - In Section 3, provide definitions for values 0, 1, and 2 of the
> Color-Only field (what spring-segment-routing-policy refers to as 00, 01,
> and 10) and note that value 3 (binary 11) is reserved. Since you’re
> reserving a value, potentially create a new registry for this field, I
> guess. Descriptive symbolic names would be nice too. I appreciate that
> pragmatically, the detailed description provided in
> spring-segment-routing-policy probably has to remain there. Nonetheless at
> least a table of names and values should be in this document.
>
> - In the IANA section, rename "Color-only bits” to "Color-only field”
>
> Thanks,
>
> —John