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

[Susan Hares <[e-mail]>]

Ketan: 

 

My comment was directed at another purpose.  While you are collecting the color information from implementers, please go back and give more detail to the implementation report. 

 

Think about it this way, are listing every place in your document where you have a “SHOULD”,  “MAY” or “MUST”?  This is just a gentle reminder.  

 

One other hint - RFC5512 is obsolete, so your “spirit” should move on RFC9012.   I’m confused by why announcing the tunnel endpoints does not announce the tunnel. 

   

See my responses below.   Tell me when you are finished with this round of revisions.  I will take a pass at the shepherd report. 

 

I’m afraid this round of shepherd reports will take time. 

 

Sue 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 7:56 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

 

Hi Sue,

 

Sorry for the delay in response.

 

Before responding on the specific comments, I would like to clarify a couple of things. 

 

The bulk of this document is about introducing a new SAFI for signaling SR Policy via BGP. This SAFI uses TEA, not in the sense of RFC9012 (i.e. advertising encap info along with BGP service routes), but more in the spirit of RFC5512 (i.e. advertising a "tunnel" itself).

 

Then there is a very specific section 3 that covers extensions to the Color Extended Community. Now, this Color Extended Community is not applicable to the BGP SR Policy SAFI but to the BGP service routes (e.g. L3VPN) to indicate their steering over the SR Policy.

 

Please check inline below for responses.

 

On Tue, Mar 8, 2022 at 10:33 PM Susan Hares <[e-mail]> wrote:

Ketan: 

 

Thank you for your hard work on these open issues regarding color.  

 

Since Jeff mentions the Color Extended communities, let me add something that would have come up on my review. 

 

In section 2.3, what does "ignore the Endpoint Sub-TLv and Color-TLV mean? 

Does the peer drops these TLVs from the Tunnel encapsulation attribute or leave these sub-TLVs in the attribute?

 

KT> The Color Sub-TLV of the TEA is ignored since it is not required for the BGP SR Policy SAFI as the Color of the SR Policy is indicated in the NLRI. The same goes for the Endpoint Sub-TLV. If they are present in the TEA, they can be left as is. That is why the draft does not talk about removing them.

 

 Sue:  Please make it clear that you draft that you are leaving it in.   After I get the text for this inclusion, I will review the text as a whole.  RFC9012 had several reviews like this. 

This draft should indicate you update RFC9012 since this draft is changing the definition of RFC9012 for the flag bits.  

 

KT> Generally, when a new document defines new flags or bits from the reserved fields or unallocated bits, we do not use the "updates" tag for the base spec. At least, that is my observation. Here, the specification of RFC9012 with the "default" steering mode (i.e. Type 0) is unchanged, and new/additional modes are being introduced.

 Sue:   Adding flag bits IMHO needs an updates.  If you wish, I can check with Alvaro on that point. 

Please provide additional text on error handling in your document  (see section 4.3 of RFC9012 below).  

 

KT> This document does not change the base handling of the Color Extended Community as specified in RFC9012. I agree that we do need some more text to clarify the new steering modes and mechanisms related to it. We will work on this and get back.

 

Sue: I am holding my final shepherd review until you get a complete text.   The details are so important in this draft. 

 

How does RFC 9012 recursive next-hop error handling work for the ignored sub-TLV?

 

KT> The sub-TLVs are ignored as they are not applicable for the new SAFI and hence nothing needs to be done for them.

 Sue: Would you please carefully include words to that affect.   Would you also answer my questions below? 

 

For example, if you ignore the sub-TLVs and include one or more Extended Communities with color,  can you prevent the condition given in paragraph 2 of the text? 

 

Thanks, Sue  

 

 

 

Specific text is listed below

==========

 

Text in draft-ietf-idr-segment-routing-te-policy: 

 

2.3 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-16#section-2.3> .  Remote Endpoint and Color

 

   The Remote Endpoint and Color sub-TLVs, as defined in [RFC9012 <https://datatracker.ietf.org/doc/html/rfc9012> ], MAY

   also be present in the SR Policy encodings.

 

   The Remote Endpoint and Color Sub-TLVs of the Tunnel Encapsulation

   Attribute are not used for SR Policy encodings and therefore their

   value is irrelevant in the context of the SR Policy SAFI NLRI.  If

   present, the Remote Endpoint sub-TLV and the Color sub-TLV MUST be

   ignored by the BGP speaker.

 

 

Why are you not indicating you are modifying RFC9012 on the front page of your draft?

 

KT> This draft is introducing a new SAFI and explains the use of the existing TEA attribute for the new SAFI. It does not change or update anything for the TEA itself.

 

 

 

RFC 9012 -  <https://www.rfc-editor.org/rfc/rfc9012.html#section-4.3> 4.3.  <https://www.rfc-editor.org/rfc/rfc9012.html#name-color-extended-community> Color Extended Community

The Color Extended Community is a Transitive Opaque Extended Community with the encoding shown in  <https://www.rfc-editor.org/rfc/rfc9012.html#ref-color-extended-community> Figure 15.

   0                   1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  | 0x03 (1 octet)| 0x0b (1 octet)|        Flags (2 octets)       |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                      Color Value (4 octets)                   |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 <https://www.rfc-editor.org/rfc/rfc9012.html#figure-15> Figure 15:  <https://www.rfc-editor.org/rfc/rfc9012.html#name-color-extended-community-2> Color Extended Community

Error handling: 

No flags are defined in this document; this field MUST be set to zero by the originator and ignored by the receiver; the value MUST NOT be changed when propagating this extended community. The Color Value field is encoded as a 4-octet value by the administrator and is outside the scope of this document. For the use of this extended community, please see  <https://www.rfc-editor.org/rfc/rfc9012.html#recursive-nh-resolution> Section 8.

Section 8:  (RFc9012) 

 

(paragraph 2). 

However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains one or more Color sub-TLVs. In that case, packet P MUST NOT be sent through the tunnel contained in that TLV, unless U1 is carrying a Color Extended Community that is identified in one of U2's Color sub-TLVs.

KT> I am not sure of the applicability of this text to the document under discussion as explained at the start of the email. Please do let me know if I am missing something.

 

Thanks,

Ketan

 

 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Jeffrey Haas
Sent: Tuesday, March 8, 2022 11:22 AM
To: Ketan Talaulikar
Cc: [e-mail]; Sue Hares; [e-mail]
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

 

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