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

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 5 Mar 2022 16:21:33 +0530

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 <[email-masked]>
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 <[email-masked]> wrote:
>
>> Hi Ketan,
>>
>> > On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <[email-masked]>
>> 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
>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 7 Mar 2022 18:08:36 +0530

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 <[email-masked]>
wrote:

> Hi John/Sue/WG,
>
> We have just posted an update with the changes along the lines suggested
> by John.
>
>
>>> 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
>>>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 Mar 2022 17:05:57 -0500

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 <[email-masked]> 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 <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 <[email-masked] <mailto:[email-masked]>> 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 <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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ketan,
> 
> > On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <[email-masked] <mailto:[email-masked]>> 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 8 Mar 2022 12:16:05 +0530

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 <[email-masked]> 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?
>
> 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
>
>
>>>> > 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 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
>>>>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 8 Mar 2022 11:22:26 -0500

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 <[email-masked]> 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. 
> 
> On Tue, Mar 8, 2022 at 3:35 AM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Ketan,
> 
>> On Mar 7, 2022, at 7:38 AM, Ketan Talaulikar <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 8 Mar 2022 12:02:58 -0500

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? 

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

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

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

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? 

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.

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

Ketan,

 

- Jeff

Hi Jeff,

Thanks,

Ketan

Ketan,

-- Jeff

Thanks,

Ketan

On Sat, Mar 5, 2022 at 4:21 PM Ketan Talaulikar <[email-masked]> wrote:

Hi John/Sue/WG,

Thanks,

Ketan

On Thu, Feb 17, 2022 at 8:22 PM Ketan Talaulikar <[email-masked]> wrote:

Hi John,

Thanks,

Ketan

Hi Ketan,

> On Feb 16, 2022, at 6:32 AM, Ketan Talaulikar <[email-masked]> wrote:
> 

Thanks.

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 17:00:38 +0530

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 <[email-masked]> 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
>
>
>>> 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
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>> 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.
>>>>>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 07:44:33 -0400

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:[email-masked]] 
Sent: Wednesday, March 23, 2022 7:31 AM
To: Jeffrey Haas
Cc: John Scudder; Sue Hares; [email-masked]; [email-masked]
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

Hi Jeff,

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.

Thanks,

Ketan

Ketan,

 

- Jeff

Hi Jeff,

Thanks,

Ketan

Ketan,

-- Jeff

Thanks,

Ketan

Hi John/Sue/WG,

Thanks,

Ketan

Hi John,

Thanks,

Ketan

Hi Ketan,

Thanks.

—John

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 23 Mar 2022 17:26:12 +0530

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.

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

> 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

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

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
>
> 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:[email-masked]] *On Behalf Of *Jeffrey Haas
> *Sent:* Tuesday, March 8, 2022 11:22 AM
> *To:* Ketan Talaulikar
> *Cc:* [email-masked]; Sue Hares;
> [email-masked]
> *Subject:* Re: [Idr] Color-only bits in
> draft-ietf-idr-segment-routing-te-policy
>
>
>
> Ketan,
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 08:14:40 -0400

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:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, March 23, 2022 7:56 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Color-only bits in draft-ietf-idr-segment-routing-te-policy

Hi Sue,

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.

Ketan: 

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. 

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. 

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. 

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? 

Thanks, Sue  

==========

 

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.

   0                   1                   2                   3

Error handling: 

Section 8:  (RFc9012) 

(paragraph 2). 

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

 

Ketan,

 

- Jeff

Hi Jeff,

Thanks,

Ketan

Ketan,

-- Jeff

Thanks,

Ketan

Hi John/Sue/WG,

Thanks,

Ketan

Hi John,

Thanks,

Ketan

Hi Ketan,

Thanks.

—John