F3-CAR-Issue-2: BGP-CAR Consensus on the need for resolution schemes

[sa1231-coder]

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

[sa1231-coder]

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.

[suehares]

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.

1. Provide (or link the code changes) for section 2.5

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.

[suehares]

2. Provide changes for section 1.1

Description: Section 1.1. is updated with missing information regarding resolution over traditional routing/TE path.

What changed:

1. Intent (definition)
2. Color (definition)
3. Colored Services Route
4. Color-Aware Path to (E2,C)
5. Color-Aware Route (E2,C)
6. Services Route Auotmated Steering on Color-aware path
7. Color Domain
8. Resolution of a BGP CAR Route (E,C)
9. Resolution vs. Steering 9a. Service Steering 9b. Intra-Domain Resolution

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

[suehares]

Action 2: Query IDR WG on the following definitions:

Section 1.1 Terminology change

1. Intent - formating only
2. 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 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.

[suehares]

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

1. Color service route is defined as: "An egress PE E2 colors its BGP VPN route V/v to indicate the intent that it requets for the traffic bound to V/v. The color is encoded as BGP Color Extended Community per [RFC9012]. "

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

2. Color-Aware Path to (E2, C) is defined as: "A routed path to E2 which satisfies the intent associated with color C.
   Several technologies may provide a Color-Aware Path to (E2, C): SR Policy [RFC9256], IGP Flex-Algo [I-D.ietf-lsr-flex-algo], BGP CAR specified in this document. "

[Shepherd's comments: Is there a reason you left out RFC9351? My comment on E2 for #1 applies to this definition.]

3. Color-Aware Route to (E2, C) is defined as: "A routed path to E2 which satisfies the intent associated with color C.
   Several technologies may provide a Color-Aware Path (E2, C): SR Policy [RFC9256], IGP Flex-Algo [RFC9350], BGP CAR."

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

4. Color Domain is defined as: " A set of nodes which share the same Color-to-Intent mapping.
   This set can be organized in one or several IGP instances or BGP domains. Color re-mapping may happen at color domain boundaries."

[Shepherd's Comments: Please put this before Service Automated Steering on Color-Aware path. See my comments below.]

5. Service Route Automated Steering on Color-aware path is defined as: "E1 automatically steers a C-colored service route V/v from E2 onto an (E2, C) path. If several such paths exist, a preference scheme is used to select the best path. (e.g. IGP Flex-Algo first then BGP CAR then SR policy.)

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

[suehares]

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:

1. Resolution of a BGP CAR Route (E,C) is defined as " An inter-domain BGP CAR route (E, C) from N of a BGP is resolved on an intra-domain color-aware CAR route path (N, C) where N is the next-hop of the (E, C) BGP CAR route.

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

[suehares]

Section 2.6 problems:

Topic: F3-CAR-Issue 2d: AIGP changes (section 2.6)

Summary: You need to discuss the AIGP refinement on the list as a separate topic.

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:

• How is it set? Does the origin set the AIGP?
• Is there any commonality across domains?

[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:

1. Are you adding a specific value for the penalty?
2. Is the penalty value able to be configured? ]

[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:

1. What level of thresholds should be set?
2. What amount of churn has been measured? ]

[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:

1. Why is this mentioned here? Is it critical for appropriate uses or just a set of refinements?
2. Is this suggested because of the concern over churn? [end of Shepherd's note 4]

[suehares]

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:

1. F3-CAR-Issue 2a Section Error handling

[suehares]

Action 2: Query IDR WG on the following definitions:

Section 1.1 Terminology change

1. Intent - formatting only
2. 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.

• Please note that I do not see an RFC reference. You are quoting the spring document (https://datatracker.ietf.org/doc/html/draft-hr-spring-intentaware-routing-using-color-01#name-intent)

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.

[suehares]

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.

[dhrao1]

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)

[suehares]

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

• (value by user policy). For instance, when color C1 path is not available,
• and route resolves via color C2 path (e.g., Appendix A.3)

[dhrao1]

Hi Sue,

yes the value is set by user policy

[suehares]

I realize we are done to "nits" in words. We'll close this once you post your review.

[suehares]

I consider this ready for external review.

[sa1231-coder]

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.