F3-CAR-Issue-1: BGP-CAR Appendix A.7 Anycast EP Scenario

[sa1231-coder]

• Revision of sections in A.7 and B.2 to address any unclear issues regarding ANYCAST. (After all issues are cleared, then the WG should be queried regarding these two sections). -Discussion of CAR view on the use of color to indicate egress domain visibility.

[sa1231-coder]

Added clarifications to examples in Appendix A.7 to describe Anycast and ingress load-balancing across distinct egress domains behaviors in more detail. Added specific text about the use of color to indicate egress domain visibility.

[suehares]

Issue F3-CAR-Issue 1:

After you have cleared F3-CAR-Issue-2, you should start a WG discussion on this issue before you close it.

Why sequence this after F3-CAR-2?
Before tackling the example, it would be good to get agreement on the definitions (1.1) and key mechanisms key mechanisms (route validation (2.4), route resolution (2.5), and AIGP (2.6), and error handling (2.10)).

If you think you must have this example to make progress with the mechanisms, this will inform you that A.7 and B.2 are not really appendix material.

If that is the case, then at least get agreement on the definition (section 1.1) before starting the IDR discussion on this topic.

[suehares]

Chair's review: 1, You need to include the resolution which which sub-bullet in section A.7 resolve this issue. If you believe this issue to be resolved in section, then a point to section A.4 needs to be included.

After you address item 1, then I will review again.

After I review, then you need to send an email message to the IDR list with F3-CAR-Issue-1: BGP-CAR Appendix A.7 Anycast EP Scenario **Summary of resolution: (2-3 lines of summarizing change)

Change to text: Provide a diff of the text that indicates what changed.

Sue

========================================== A.7. Advertising BGP CAR routes for shared IP addresses

This example describes a case where a route for the same transport IP address is originated from multiple nodes in different network domains.

One use of this scenario is an Anycast transport service, where packet encapsulation (e.g., LSP) may terminate on any one among a set of nodes. All the nodes are capable of forwarding the inner payload, typically via an IP lookup in the global table for Internet routes.

A couple of variations of the use-case are described in the example below.

One node is shown in each domain, but there will be multiple nodes in practice for redundancy.

Example-1: Anycast with forwarding to nearest

Rao, et al. Expires 22 July 2023 [Page 53]

Internet-Draft BGP Color-Aware Routing (CAR) January 2023

Both E2 and E3 advertise Anycast (shared) IP (IP1, C1) with same label L1

An ingress PE E1 receives by default the best path(s) for (IP1, C1) propagated through BGP hops across the network.

The paths to (IP1, C1) from E2 and E3 may merge at a common node along the path to E1, forming equal cost multipaths or active- backup paths at that node

Service route V/v is advertised from egress domains D1 and D2 with color C1 and next-hop IP1.

Traffic for V/v steered at E1 via (IP1, C1) is forwarded to either E2 or E3 (or both) as determined by routing along the network (nodes in the path).

Example-2: Anycast with egress domain visibility at ingress PE

E2 advertises (IP1, C1) and E3 advertises (IP1, C2) CAR routes for the Anycast IP IP1. C1 and C2 are colors assigned to distinguish the egress domains originating the routes to IP1.

An ingress PE E1 receives the best path(s) propagated through BGP hops across the network for both (IP1, C1) and (IP1, C2).

The CAR routes (IP1, C1) and (IP1, C2) do not get merged at any intermediate node, providing E1 control over path selection and load-balancing of traffic across these two routes. Each route may itself provide multipathing or Anycast to a set of egress nodes.

Service route V/v advertised from egress domain D1 and D2 with colors C1 and C2 respectively, but with same next-hop IP1.

E1 will resolve and steer V/v path from D1 via (IP1, C1) and path from D2 via (IP2, C2). E1 will load-balance traffic to V/v across the two paths as determined by a local load-balancing policy.

Traffic for colored service routes steered at E1 is forwarded to either E2 or E3 (or load-balanced across both) as determined by E1.

In above example, D1 and D2 belonged to the same color or administrative domain. If D1 and D2 belonged to different color domains, the domains will coordinate the assignment of colors to be used with shared IP IP1 such that they do not cause conflicts. For instance, in Example-1 :

Rao, et al. Expires 22 July 2023 [Page 54]

Internet-Draft BGP Color-Aware Routing (CAR) January 2023

D1 and D2 may both use C1 when they originate CAR route for IP1.

In this case, naturally neither D1 nor D2 will use C1 for some other intent Alternatively, D1 may use C2 and D2 may use C3 for originating a CAR route for IP1 for the same intent.

In this case, D1 will not use C3 for originating CAR route for IP1 for some other intent. Similarly, D2 will not use C2 for originating CAR route for IP1 for some other intent.

[suehares]

This was posted to the IDR Mail list as: https://mailarchive.ietf.org/arch/msg/idr/eD2BeBMQxl_xndKNDlZA84LYn9Y/

No comments were received.

[suehares]

I am re-opening so you can submit a https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/github-issues-status.txt

We'll publish this file on github and idr wiki along with draft-ietf-idr-bgp-car-02 for WG LC.

Cheers, Sue

[suehares]

[suehares]

Issue F3-CAR-Issue 1: Definition added for intent with RFC9315 + Spring document linked.

Definition added in -01. for route validation.

No definition added for: route validation, AIGP and Error handling.

[suehares]

Sue review section A.7 for readability. Technology is ok.

[suehares]

Section A.7 is not easily read. Perhaps it would be better to duplicate the diagrams and give the specific announcement on the diagrams.

Example 1: page 54, example 1,

• Service route V/v is advertised from egress domains D1 and D2 with color C1 and next-hop IP1.

• Traffic for V/v steered at E1 via (IP1, C1) is forwarded to either E2 or E3 (or both) as determined by routing along the network (nodes in the path).

Is the V/v serve route being advertised from D2 (from E2) and D3 (from E3) for this example to D1? The text is unclear.

Example 2: page 54, example 1,

• Service route V/v advertised from egress domain D1 and D2 with colors C1 and C2 respectively, but with same next-hop IP1.

  • E1 will resolve and steer V/v path from D1 via (IP1, C1) and path from D2 via (IP2, C2). E1 will load-balance traffic to V/v across the two paths as determined by a local load-balancing policy.

• Traffic for colored service routes steered at E1 is forwarded to either E2 or E3 (or load-balanced across both) as determined by E1.

Is the V/v serve route being advertised from D2 (from E2) and D3 (from E3) for this example to D1? The text is unclear.

Just a reminder - "naturally" in the text below might be removed and reduce confusion:

• D1 and D2 may both use C1 when they originate CAR route for IP1.

  • In this case, naturally neither D1 nor D2 will use C1 for some other intent

[dhrao1]

Actually, the issue was that there was a typo in the example such that the text did not match the figure.

The egress domains should be D2 and D3; instead of D1 and D2. Will fix. Thank you for catching it !

[dhrao1]

Updated intent definition in terminology:

- Intent + Intent (in routing):

Any combination of the following behaviors: a. Topology path selection (e.g. minimize metric, avoid resource), b. NFV service insertion (e.g. service chain steering), c. per-hop behavior (e.g. 5G slice).

+ More specific concept w.r.t. routing beyond best-effort, compared to intent as declarative abstraction in [RFC9315]

[suehares]

I consider this ready for external review.

[sa1231-coder]

Comment/ were addressed in draft-ietf-idr-bgp-car-02. After that WG has been polled with WGLC and no further comments have been raised.