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

[Ketan Talaulikar <[e-mail]>]

Hi Jeff,

I tried to do a search for specs that use/reference the Color Extended
community and if they were assuming or introducing any semantics that
indicated the "singleton" usage that you bring up in your email. I was not
able to find any. It is possible that I've missed something and if so,
please point me to the concerned spec.

There is no limitation for the use of multiple Color Extended communities
of different colors with a route (irrespective of the reserved/flags field
values). This is possible for the steering use-cases over SR Policy and I
am aware of this support by implementations.

We can update this spec with clarification on this aspect, if necessary.

Thanks,
Ketan


On Tue, Mar 8, 2022 at 3:35 AM Jeffrey Haas <[e-mail]> wrote:

> Ketan,
>
> While I was reviewing the update you note below, I had a question
> regarding color extended community handling.
>
> One of the changes the color extended community had between RFC 5512 and
> RFC 9012 was moving the previously Reserved field to a flags field.
>
> In the prior context as a Reserved field, I believe many implementations
> treated the Color Extended Community as many BESS style Extended
> Communities are incidentally treated: singletons.  I.e. there should have
> only been a single instance of such an Extended Community on a route.
>
> A current fault in BESS specifications is the lack of clarity for what to
> do for such singleton entries.  We're desperately in need of a draft
> discussing the matter. :-)
>
> While I don't think this matter is something of your creation, since the
> SR-TE-Policy document is the first populating the Flags fields, it's
> perhaps important to discuss what should happen here.  Is it reasonable to
> think that the current desired behavior with the new flags is that it's a
> singleton entry and there should only be one Extended Community of type
> Color on a route, no matter their CO flags?  And perhaps similarly even if
> CO flags are present, there shouldn't be additional Extended Communities
> with those flags 00?
>
> It might be useful to discuss this in the draft.
>
> A complicating matter is whether there's ever likely to be Extended
> Community Colors that have other bits outside of the CO that you're
> defining wherein you'll want more than one Extended Community of that type.
>
> -- Jeff
>
>
> On Mar 7, 2022, at 7:38 AM, Ketan Talaulikar <[e-mail]>
> wrote:
>
> 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
>>>
>>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>