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

[Susan Hares <[e-mail]>]

Ketan: 

 

Upgrading your draft-ietf-idr-segment-routing-te-policy with additional implementation details would also be helpful for this discussion. 

 

Cheers, Sue 

 

From: Ketan Talaulikar [mailto:[e-mail]] 
Sent: Wednesday, March 23, 2022 7:31 AM
To: Jeffrey Haas
Cc: John Scudder; Sue Hares; [e-mail]; [e-mail]
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

 

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