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

[Ketan Talaulikar <[e-mail]>]

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.


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


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


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


>
>
> 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 - 4.3.  <https://www.rfc-editor.org/rfc/rfc9012.html#section-4.3>Color
> Extended Community
> <https://www.rfc-editor.org/rfc/rfc9012.html#name-color-extended-community>
>
> The Color Extended Community is a Transitive Opaque Extended Community
> with the encoding shown in Figure 15
> <https://www.rfc-editor.org/rfc/rfc9012.html#ref-color-extended-community>
> .
>
>    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)                   |
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 15 <https://www.rfc-editor.org/rfc/rfc9012.html#figure-15>: Color
> Extended Community
> <https://www.rfc-editor.org/rfc/rfc9012.html#name-color-extended-community-2>
>
> *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 Section
> 8 <https://www.rfc-editor.org/rfc/rfc9012.html#recursive-nh-resolution>.
>
> *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
>
>
>
>
>