Closed sa1231-coder closed 8 months ago
Section 2.9.3 is updated to use LCM-EC color when present for route validation, resolution and AIGP. Section 2.10 is added to explicitly state LCM-EC and BGP Color EC usage.
F3-CAR-Issue 3: Handling of LCM and Extended Communities
Shepherd Comment: The text that is changed is below in bold:
When a CAR route crosses the originator's color domain boundary, LCM- EC is added. LCM-EC conveys the local color mapping for the intent (e.g. low latency) in other (transit or destination) color domains.
An implementation SHOULD NOT send more than one instance of the LCM- EC. However, if more than one instance is received, an implementation MUST disregard all instances other than the one with the numerically highest value.
If present, LCM-EC is the effective intent of a BGP CAR route.
LCM-EC Color is used instead of the Color in CAR route NLRI for procedures described in earlier sections such as route validation, resolution, AIGP calculation and steering.
The new section 2.10 is a nice addition to the CAR draft. Please verify that the following pairing in that text is accurate:
After you finish the IDR Review of F3-CAR-Issue-2, you may want to go on to cover this issue before F3-CAR-Issue-3 in a specific all.
This issue is not resolved until you complete the IDR WG mail call of your issues.
This issue needs to be re-opened.
Sue will re-read new section 2.10 for answering question F3-CAR-Issue-3. (Thursday night).
DJ and Swadesh consider adding a comment that points to RFC9012 color not being used.
Error handling in section 2.9.2.2
This TLV provides the equivalent functionality as Label-Index TLV of [RFC8669] for Transport CAR route in SR-MPLS deployments. It provides much better packing efficiency by carrying label Index in NLRI instead of the BGP Prefix SID attribute. The BGP Prefix SID Attribute SHOULD be omitted from the labeled color-aware routes when the attribute is being used to only convey the Label Index TLV.
Editor's comments: What happens if the "SHOULD" is not followed? Does the BGP Prefix SID Attribute get ignored?
If so, please indicate this at this point.
Section 2.10 refers to sections B.2, 2.5, 2.8, and B.3. Section 2.5 refers to section A.3.2. Section 2.8 refers to Appendix B. All of these sections were reviewed in the review of section 2.10.
Section 2.10 Text: Both LCM-EC and BGP Color Extended Community may be present with a BGP CAR route. Example: BGP CAR route (E, C1) from color domain D1, with LCM-EC C2 in color domain D2, may also carry Color-EC C3 and next-hop N in a transit network domain within D2 that has intent C3 available and resolves C2 via C3
It is "Color-EC C3" or LCM-EC C3",? The color is on: 1) NLRI, 2) LCM Extended community, and 3) Color-EC C3
It the Color-EC C3 applied by local policy in mapping to the transport?
I'm having trouble mapping this text to the example in B.3.
Sue's note. I'll re-read sections 2.10, B.2, 2.5, 2.8, and B.3 again on Monday (6/5) prior to our chat.
The text above refers to a combination case where both LCM-EC and Color-EC are present on a CAR route. The behavior is a combination of examples in Appendix B.2 and B.3.
As described in Appendix B.2, the next-hop color (C3 in above text) may be mapped by local policy on an ingress BR within color domain D2, or by attaching the Color-EC at an egress BR within color domain D2.
Note: NLRI color is C1 LCM-EC color is C2 (since different color domain D2) Color-EC color is C3 (in a transit domain within color domain D2 where C2 is being resolved via intra-domain intent C3)
Editorial: Appendix.B.3 - lacks the link.
Since the example comes from sections B.2 and B.3, I was trying to determine how to indicate this fact to the readers of the text. Do you have any suggestions?
I consider this issue ready for external review.
Comment/clarification were addressed in draft-ietf-idr-bgp-car-02. After that WG has been polled with WGLC and no further comments have been raised.
-Appendix B.2 should be clarified after F3-CAR-Issue-2 has been expanded to include: