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

[Ketan Talaulikar <[e-mail]>]

A further update was posted earlier today with changes in the Color
Extended Community related sections to align with the latest updates to
draft-ietf-spring-segment-routing-policy

https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16

Thanks,
Ketan


On Sat, Mar 5, 2022 at 4:21 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi John/Sue/WG,
>
> We have just posted an update with the changes along the lines suggested
> by John.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-15
>
> I understand that John may have further inputs that we can incorporate in
> the next update. Wanted to post this version in view of the upcoming
> cut-off so that the WG can provide their feedback.
>
> Thanks,
> Ketan
>
>
> On Thu, Feb 17, 2022 at 8:22 PM Ketan Talaulikar <[e-mail]>
> wrote:
>
>> 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 <[e-mail]> wrote:
>>
>>> Hi Ketan,
>>>
>>> > On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <[e-mail]>
>>> 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
>>
>>