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

From: John Scudder <[email-masked]>
Date: Tue, 15 Feb 2022 21:01:33 +0000

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

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 16 Feb 2022 17:02:35 +0530

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 <[email-masked]> 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”.
>
> - 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.
>

---

From: John Scudder <[email-masked]>
Date: Wed, 16 Feb 2022 19:21:41 +0000

Hi Ketan,

> On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 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.

Thanks.

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

I would, instead, have imagined it moving in the other direction, both because it seems as though it makes more sense in the IDR doc, and because the SPRING doc is even further along (past WGLC, past IETF LC, scheduled for tomorrow’s IESG telechat). I don’t want to cross the streams of discussion more than necessary, but the reason I see it being more natural in the IDR than the SPRING doc is because "Given that [draft-ietf-spring-segment-routing-policy] is an architecture document, it describes the architecture and not really the protocol mechanisms. This is in line with other SPRING documents. The normative language for the BGP mechanism is in the IDR document.” 

I acknowledge it’s not a cut-and-dried question and there are other ways to resolve it that while less satisfying in terms of making the documents self-contained, also are less invasive. The minimal one, I guess, is to provide a table of names and values in the IDR document, something along the lines of

Type Code	Symbolic Name	Description
—————	———————	—————	
0			Default handling	Steering falls back to default handling if no policy with color
1			Prefer color		Steering favors following policies with the given color, but respects BGP next hop
2			Override next hop	Steering favors following policies with the given color, overriding BGP next hop if necessary
3			Reserved			Reserved for future use

You may not agree with the symbolic names and descriptions I’ve just written out, that’s fine, it’s just a first attempt. The table would be accompanied by an expansion of the descriptive prose in the section, to give the reader at least a general idea of what’s going on over in the SPRING doc.

Also, the more I think about it, the more I think that creating an IANA registry for these code points is a good idea. It seems fussy for a single unallocated code point, but might prevent something unfortunate like two future drafts both trying to allocate the reserved code point for themselves. 

(I assume it’s way too late to move the field to the other end of the Reserved bits? If it were at the other end it would be possible to grow it naturally in the future if required, by allocating additional bits. As it is now, if you grew it by one bit, code point 1 would become code point 2, 2 would become 4, and so on. Or if you prefer, 0b01 would become 0b010, 0b10 would become 0b010, and so on. Oh well, too bad so sad.)

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 20:22:17 +0530

Hi John,

I'll work on these changes along with my co-authors for the IDR document
first and share it with you/WG for feedback.

Thanks,
Ketan

On Thu, Feb 17, 2022 at 12:51 AM John Scudder <[email-masked]> wrote:

> > 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.
>
> Thanks.
>
> I would, instead, have imagined it moving in the other direction, both
> because it seems as though it makes more sense in the IDR doc, and because
> the SPRING doc is even further along (past WGLC, past IETF LC, scheduled
> for tomorrow’s IESG telechat). I don’t want to cross the streams of
> discussion more than necessary, but the reason I see it being more natural
> in the IDR than the SPRING doc is because "Given that
> [draft-ietf-spring-segment-routing-policy] is an architecture document, it
> describes the architecture and not really the protocol mechanisms. This is
> in line with other SPRING documents. The normative language for the BGP
> mechanism is in the IDR document.”
>
> I acknowledge it’s not a cut-and-dried question and there are other ways
> to resolve it that while less satisfying in terms of making the documents
> self-contained, also are less invasive. The minimal one, I guess, is to
> provide a table of names and values in the IDR document, something along
> the lines of
>
> 1                       Prefer color            Steering favors following
> policies with the given color, but respects BGP next hop
> 2                       Override next hop       Steering favors following
> policies with the given color, overriding BGP next hop if necessary
> 3                       Reserved                        Reserved for
> future use
>
> You may not agree with the symbolic names and descriptions I’ve just
> written out, that’s fine, it’s just a first attempt. The table would be
> accompanied by an expansion of the descriptive prose in the section, to
> give the reader at least a general idea of what’s going on over in the
> SPRING doc.
>
> Also, the more I think about it, the more I think that creating an IANA
> registry for these code points is a good idea. It seems fussy for a single
> unallocated code point, but might prevent something unfortunate like two
> future drafts both trying to allocate the reserved code point for
> themselves.
>
> (I assume it’s way too late to move the field to the other end of the
> Reserved bits? If it were at the other end it would be possible to grow it
> naturally in the future if required, by allocating additional bits. As it
> is now, if you grew it by one bit, code point 1 would become code point 2,
> 2 would become 4, and so on. Or if you prefer, 0b01 would become 0b010,
> 0b10 would become 0b010, and so on. Oh well, too bad so sad.)
>
> —John