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

[Ketan Talaulikar <[e-mail]>]

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