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

[Ketan Talaulikar <[e-mail]>]

Hi Jeff,

Sorry for the delay in getting back on this one.

I was specifically referring to the Color Extended Community and
implementations do support multiple instances of it on a single BGP service
(e.g. L3VPN) route.

Working on collecting implementation information here.

Thanks,
Ketan

On Tue, Mar 8, 2022 at 9:52 PM Jeffrey Haas <[e-mail]> wrote:

> Ketan,
>
> The point you're hearing is that this is a well known hole in the specs.
> There's already some level of discussion that's happened at least with the
> IDR chairs that we need to get broader discussion about the point in the
> BGP related working groups.
>
> If you're aware of implementations that actually use more than one
> community, please unicast it to me and I'll collect it for the wiki.  I'm
> personally aware of implementations that just pick "the first one", which
> may not be the one encoded on the wire as "first".
>
>
>
> - Jeff
>
>
> On Mar 8, 2022, at 1:46 AM, Ketan Talaulikar <[e-mail]>
> wrote:
>
> 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
>>
>>
>>
>