Closed sa1231-coder closed 8 months ago
Section 2.5 is updated with default resolution scheme. Additional control using local policy. Precedence is explicitly stated in updated version.
Section 1.1. is updated with missing information regarding resolution over traditional routing/TE path.
Section 2.6 (AIGP) already states additional penalty when resolving to next-hop not satisfying the intent (allowed by local policy).
Local policy is operator controlled, with precedence as documented. BGP bestpath takes path validation into account. No protocol specific error handling.
Topic: F3-CAR-Issue 2e: Section 2.5
Pleae do a call for the changes to this text. Note: This call should occur after calls 2a, 2b, 2c, and 2d.
Your summary: Section 2.5 is updated with default resolution scheme. Additional control using local policy. Precedence is explicitly stated in updated version.
Here are the changes for section 2.5 based on the diff
old text/ A BGP color-aware route (E2, C1) from N is automatically resolved over a color-aware route (N, C1) by default. The color-aware route (N, C1) is provided by color aware mechanisms such as IGP Flex-Algo, SR policy or recursively by BGP CAR.
When multiple resolutions are possible, the default preference should be: IGP Flex-Algo, SR Policy, RSVP-TE, BGP CAR, BGP LU.. /
New text / A BGP color-aware route (E2, C1) from N is automatically resolved over a color-aware route (N, C1) by default. The color-aware route (N, C1) is provided by color aware mechanisms such as IGP Flex-Algo, SR policy or recursively by BGP CAR. When multiple producers of (N,C1) are available, the default preference is: IGP Flex-Algo, SR Policy, BGP CAR./
Reason for changing: (please provide) - ?? Improve to include default resolution scheme and explicit precedence.
old-text-2 / Through local policy, a BGP color-aware route (E2, C1) from N may be resolved over a color-aware route (N, C2): i.e. the local policy maps the resolution of C1 over C2. For example, in a domain where resource R is known to not be present, the inter-domain intent C1="low delay and avoid R" may be resolved over an intra-domain path of intent C2="low delay". Another example is, if no (N, C1) path is available, and the user has allowed resolution via C2.
Resolution may also be automated using Color-EC as illustrated in Appendix B.2 . /
new-text-2/ Local policy can provide additional control and options:
A BGP color-aware route (E2, C1) from N may be resolved over a color-aware route (N, C2): i.e. the local policy maps the resolution of C1 over C2.
For example, in a domain where resource R is known to not be present, the inter-domain intent C1="low delay and avoid R" may be resolved over an intra-domain path of intent C2="low delay".
Another example is, if no (N, C1) path is available, and the user has allowed resolution to fallback via C2
Resolution may be mapped to traditional mechanisms that are unaware of color, such as RSVP-TE, IGP/LDP, BGP LU.
Local policy takes precedence over default color based automated resolution. For a CAR route, Color-EC color takes precedence over route NLRI color. /
Reason for change: Additional control using local policy.
Description: Section 1.1. is updated with missing information regarding resolution over traditional routing/TE path.
What changed:
Why each section changed needs to be recorded.
I suggest these are indicated in a status change file: https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/ in main or branch. github-issues-status.txt
Action 2: Query IDR WG on the following definitions:
Section 1.1 Terminology change
The following two definitions should be sent to the IDR WG to get agreement on these definitions in the WG.
Label this thread as Issue F2-CAR-Issue-2a: Definitions in 1.1
Intent is defined as: "Any combination of the following behaviors: a) Topology path selection (e.g. minimize metric, avoid resource) b) NFV Service insertion (e.g. service change steering), c) per-hop behavior (e.g. 5G slice).
Color is defined as: "A 32-bit numerical value associated with an intent: (e.g. low-cost vs. low-delays vs. avoiding some resources). As defined in [RFC9256]./
Shepherd's note: By the way, you may want to improve the English text in the Color definition. The use of versus (vs.) usually means a comparison of two items. You are comparing three items. Also, the phrase "As defined in [RFC9256]" as a separate sentence does not correctly indicated that it applies to the previous sentence. May I suggest
New-text :/ "A 32-bit numerical value associate with an intent (e.g. low cost vs. low delays and avoid some resources) as defined in [RFC9256]. /
This action item must be completed before you can close this item.
Action 3: After you have completed the call on Intent and Color definitions, please start a WG call for input on the following text.
Denote this call as: F2-CAR-Issue-2b Definitions in 1.1
[Shepherd's comments: This definition is unclear that PE E2 is any egress PE. Consider improving the text for this section. You can add this information on what PE E2 is assumed to be in the definitions.]
[Shepherd's comments: Is there a reason you left out RFC9351? My comment on E2 for #1 applies to this definition.]
[Shepherd's comments: I updated your text to indicate IGP Flex Algo going to RFC. Is there a reason you left out RFC9351? My comment on E2 for #1 applies to this definition.]
[Shepherd's Comments: Please put this before Service Automated Steering on Color-Aware path. See my comments below.]
[Shepherd's comments: Are you specifying a default scheme (per section 2.5) and allow operators to set an alternative. Then, this text is confusing. An possible alternative is:
new text/ If several paths exists, a preference scheme is used to select the best path. The default preference scheme is defined in section 2.5, but alternate prefence schemes may be used by a Color domain./ [end shepherd'x comments on 5.]
This is the end of definitions which do not mention CAR.
Action 4: After you have completed the call on Intent and Color definitions, please start a WG call for input on the following text.
Denote this call as: F2-CAR-Issue-2c Definitions in 1.1
Ask for confirmation of these definitions:
2, Resolution versus Steering In this document and consistently with the terminology of the SR Policy document [RFC9256], steering is used to describe the mapping of a service route onto a BGP CAR path while the term resolution is preserved for the mapping of an inter-domain BGP CAR route on an intra-domain color-aware path.
[Shepherd: If you are referring to RFC9252 section 2 for steering, then please indicate both the RFC and the section. If you are referring to RFC9252 in section 8, per-destination steering, please indicate this is your source. Please adjust your sentence to include the sections. I am hopeful that you if you are specific, the arguments on the IDR list will be lessened (unfortunately, no zero).
2a. ) Service Steering: Service route --> BGP CAR path (or other Color-Aware Routed Paths: (e.g. SR Policy).
[Shepherd's text: This text is not a useful definition. Alternate text/ Service route maps traffic to the BGP CAR Path (or other Color-Aware Routed Paths). One example of a Color-Aware Route Path is SR Policy. /]
2b. ) Intra-Domain Resolution: BGP CAR route -> intra-domain color aware path (e.g. SR Policy, IGP Flex-Algo, BGP CAR) or traditional routing/TE path (e.g. RSVP-TE, IGP/LDP, BGP-LU).
[Shepherd may I suggest that your text could use clarification.
Here's a suggestion for an alternative:
New text/ BGP CAR route resolution maps maps inter-Domain BGP Car route to an intra-domain Color aware path (e.g. SR Policy, IGP Flex-Algo, or BGP CAR) or a traditional routing path (such as IGP/LDP, or BGP-LU) or or a TE routing path (e.g. RSVP-TE). /
Section 2.6 problems:
Topic: F3-CAR-Issue 2d: AIGP changes (section 2.6)
I've provided you some questions that try to dig out a. specifics of the CAR-AIGP implementation, and b. The potential for church.
[Shepherd's note 1 on the following:
Information regarding the metric type used by the underlying intra-
domain mechanism can also be set.
Questions:
[end note 1]
[Shepherd's note 2 on the following:
If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, add a penalty in accumulated IGP metric. The discontinuity is also indicated to upstream nodes via a bit in the AIGP TLV.
Questions:
[end Shepherd's note 2]
[Shepherd's note 3: To avoid continuous IGP metric churn causing end to end BGP CAR churn, an implementation should provide thresholds to trigger AIGP update.
[Questions:
[End of Shepherd's note 3]
[Shepherd's note 4 on: Additional AIGP extensions may be defined to signal state for specific use-cases: MSD along the BGP CAR advertisement, Minimum MTU along the BGP CAR advertisement.
Question:
Issue F3-CAR-Issue 2f: Section Error handling
You made subtantial changes to the Error handling in -01.txt.
Please do a specific all for review of the revised text after you have completed the following review calls:
Action 2: Query IDR WG on the following definitions:
Section 1.1 Terminology change
- Intent - formatting only
- Color Definition Added - "As defined in RFC9256".
The following two definitions should be sent to the IDR WG to get agreement on these definitions in the WG.
Label this thread as Issue F2-CAR-Issue-2a: Definitions in 1.1
Intent is defined as: "Any combination of the following behaviors: a) Topology path selection (e.g. minimize metric, avoid resource) b) NFV Service insertion (e.g. service change steering), c) per-hop behavior (e.g. 5G slice).
Color is defined as: "A 32-bit numerical value associated with an intent: (e.g. low-cost vs. low-delays vs. avoiding some resources). As defined in [RFC9256]./
Shepherd's note: By the way, you may want to improve the English text in the Color definition. The use of versus (vs.) usually means a comparison of two items. You are comparing three items. Also, the phrase "As defined in [RFC9256]" as a separate sentence does not correctly indicate that it applies to the previous sentence. May I suggest
New-text :/ "A 32-bit numerical value associated with an intent (e.g. low cost vs. low delays and avoid some resources) as defined in [RFC9256]. /
This action item must be completed before you can close this item.
The RFC approved by the IRTF is https://datatracker.ietf.org/doc/rfc9315/.
You should indicate why you are using this definition and how it relates to the RFC definition. You will need to correct this in a -02.txt in CAR.
Section 2.6 (AIGP) already states additional penalty when resolving to next-hop not satisfying the intent (allowed by local policy).
If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, add a penalty in accumulated IGP metric.
Add information on what is transport discontinuity is. point to.
Updating text as:
If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, add a penalty in accumulated IGP metric + (by user policy). For instance, when color C1 path is not available, + and route resolves via color C2 path (e.g., Appendix A.3)
DJ -
Do you mean
If BGP CAR routes traverse across a discontinuity in the transport path for a given intent, add a penalty in accumulated IGP metric
Hi Sue,
yes the value is set by user policy
I realize we are done to "nits" in words. We'll close this once you post your review.
I consider this ready for external review.
Comment/clarification were addressed in draft-ietf-idr-bgp-car-02. Further updates are made to clarify route 1 and 2 recursive resolution in hierarchical routing design. After that WG has been polled with WGLC and interims. No further comments have been raised.
-CAR Sections 1.1 needs indicate that local BGP policy can customize or adjust the route validation (section 2.4), route resolution (2.5), and AIGP (2.6). -Section 2.10 should cover any issues regarding conflicts caused by local policy.