kalirajv
commented
1 year ago From: Kaliraj Vairavakkalai kaliraj@juniper.net Date: Friday, June 16, 2023 at 2:42 PM To: Dongjie (Jimmy) jie.dong@huawei.com, Susan Hares shares@ndzh.com, Natrajan Venkataraman natv@juniper.net, Reshma Das dreshma@juniper.net Cc: idr-chairs@ietf.org idr-chairs@ietf.org, Wanghaibo (Rainsword) rainsword.wang@huawei.com Subject: Re: Revised D.2 for discussion at 10:00pm Beijing time. Hi Jie,
Thanks for the revised text. Please find the latest version with most of the suggested changes incorporated.
https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/main/draft-ietf-idr-bgp-ct.txt
please see inline for one question. KV>
Thanks Kaliraj
From: Dongjie (Jimmy) jie.dong@huawei.com Date: Friday, June 16, 2023 at 1:19 AM To: Susan Hares shares@ndzh.com, Kaliraj Vairavakkalai kaliraj@juniper.net, Natrajan Venkataraman natv@juniper.net, Reshma Das dreshma@juniper.net Cc: idr-chairs@ietf.org idr-chairs@ietf.org, Wanghaibo (Rainsword) rainsword.wang@huawei.com Subject: RE: Revised D.2 for discussion at 10:00pm Beijing time. [External Email. Be cautious of content]
Hi Sue and CT authors,
Thanks for the discussion yesterday. After some discussion with the CPR authors, please find proposed text and comments inline:
Best regards, Jie
From: Susan Hares [shares@ndzh.com](mailto:shares@ndzh.com) Sent: Wednesday, June 14, 2023 9:14 PM To: Dongjie (Jimmy) [jie.dong@huawei.com](mailto:jie.dong@huawei.com) Subject: Revised D.2 for discussion at 10:00pm Beijing time.
D.2. Color encoded Service SID (CPR) approach
CPR is defined in the document: Colorful Prefix Routing for SRv6 based services [Colorful-Prefix-Routing-SRv6], and uses IPv6 Unicast (AFI/SAFI = 2/1) as a transport family.
CPR uses color encoded service SRv6 SIDs, without a separate transport SRv6 SID.
[Jie] Suggest to change the above sentence to:
CPR uses color encoded SRv6 service SIDs to determine the intent-aware transport paths for the service, without a separate transport SRv6 SID.
It routes using "Colorful Prefix" locators in the transport layer, which are carried in the IPv6 Unicast BGP family.
BGP CT facilitates the CPR approach by providing intent-driven paths for the "Colorful Prefix" locator routes that carry a mapping community, by using Nexthop Resolution Scheme (Section 6) for those IPv6 unicast family routes.
[Jie] Suggest to change the above sentence to:
A Nexthop Resolution Scheme similar to that of BGP CT (Section 6) is used on IPv6 unicast family to resolve “Colorful Prefix” locator routes that carry a mapping community to intent-aware paths in each domain.
By virtue of the CPR SID allocation scheme, the service SIDs inherit the Intent of the corresponding Colorful Prefix route just by performing longest prefix match in forwarding plane.
Vairavakkalai & Venkatar Expires 16 December 2023 [Page 73]
Internet-Draft BGP Classful Transport Planes June 2023
D.2.1. Analysis of CPR approach
The CPR approach can be used to support intent driven routing while minimizing SRv6 encapsulation overhead, at the cost of careful SID numbering and planning. The state in the transport network is a function of total number of Colorful Prefixes.
In the CPR approach, a unique service SID is allocated for each combination of service function (e.g. Prefix, VRF or Nexthop) and Intent (Coloring Prefix) at the egress node.
[Jie] Suggest to change the above sentence to:
In the CPR approach, typically one service SID is allocated for each service function (e.g. VRF) which is associated with a specific intent. In some special scenarios, for example, when different service routes in the same VRF are with different intents, a unique service SID would need to be allocated for each intent associated with the VRF.
Such that per egress SN,
Total_Num_Color_Prefixes = Num_Intents.and,
Total_Num_Service_SIDs = Num_Service_Functions * Num_Intents.[Jie] Suggest to remove the above equations, as discussed this is not the usual case, and it has been covered in the proposed text above.
This "Total_Num_Service_SIDs" scale may have an impact on overall convergence while executing operational procedures like Colorful Prefix locator modification, where all the service routes have to be readvertised with their new Service SID computed as a result of the Colorful Prefix locator change.
[Jie] As discussed the colorful prefix locator modification is not a common event in the network. For a service which needs to be associated with a different intent, only the service routes of such service need to be readvertised, instead of all service routes. This is similar to the case when BGP CT is used and the intent of a service function is changed.
Thus I’d suggest to remove the above text.
When an egress SN signals a change of Intent on service routes, that will involve per service route convergence in forwarding at the ingress SN because the Intent is encoded in the service SID.
[Jie] Thinking about it again, my understanding is that for BGP CT, with the change of intent on the serviced routes, all the impacted service routes also need to be readvertised with a new color community, and this also requires per service route convergence in forwarding plane, as the resolution of service routes to the CT route also needs to be updated. This is similar to the resolution of service routes to CPR route. There may be some optimization for both mechanisms while I’d say it is implementation specific?
Thus I’d suggest to either remove the above text, or clarify that forwarding plane convergence is implementation specific.
However, the CPR mechanism preserves BGP PIC (Prefix scale Independent Convergence) for the egress SN failure scenario where only Colorful Prefix routes need to be withdrawn.
CPR achieves strict Intent based forwarding for the service routes. Fallback to best effort transport class is achieved by numbering all SRv6 CPR locators at the egress SN to fall in the same subnet as the SRv6 locator that uses best effort transport class. Custom Intents that provide fallback between different color transport classes can be achieved by allocating a CPR prefix for each such intent combination, and advertising that CPR prefix with an appropriate BGP CT mapping community, that maps to a customized resolution scheme.
[JIe] As discussed, allocating different CPR for customized fallback policy is just one option. Thus suggest to change the last sentence to:
Customized intent fallback between different color transport classes may be achieved by allocating a CPR prefix for each such intent fallback policy, and advertising that CPR prefix with an appropriate mapping community, that maps to a customized resolution scheme. Alternatively, the intent fallback policy may be provisioned on the ingress nodes directly.
Further, IPv6 unicast family is widely deployed to carry Internet Service routes. Repurposing IPv6 unicast family to carry Transport routes also may impact the operational complexity and security aspects in the network.
[Jie] For inter-domain SRv6 BE forwarding, SRv6 locators are already advertised in IPv6 unicast. This is not newly introduced by CPR. That said, some mechanism may used to control the advertisement of the SRv6 locator prefixes.
I’d suggest to clarify that using IPv6 unicast for transport route is needed for SRv6 inter-domain forwarding, not a new behavior introduced by CPR.
KV> Please give us a pointer to some SRv6 spec that uses IPv6-Unicast as a transport family. So that we can incorporate this comment. KV> We will push the changes so far to IETF. We can push this additional change in a further version. Thanks.
neonatty
suehares
Please find some of my comments to the descriptions in D.2 of draft-bgp-ct
D.2. Color encoded Service SID (CPR) approach This approach uses color encoded service SRv6 SIDs, without any transport SRv6 SID.
[Jie] This is a correct statement. With CPR, the overhead of dedicated SID for the transport path is saved. The service SIDs with colorful prefix can be used to indicate both the transport path and the service instance.
This approach a.k.a CPR is defined by Colorful Prefix Routing for SRv6 based services [Colorful-Prefix-Routing-SRv6] draft which uses IPv6 Unicast (AFI/SAFI = 2/1) as a transport family. This approach can be achieved by applying BGP CT procedures defined in this document to IPv6 unicast family.
[Jie] This statement is not quite accurate. CPR does not use RD/RT mechanism for route import. Suggest to remove this sentence.
In this approach, a unique service SID is allocated for each combination of service function (e.g. Prefix, VRF or Nexthop) and an egress SRv6 color sub-locator. This consumes "Num_Service_Functions x Num_SRv6-color-sub-locators" service SIDs per egress SN.
[Jie] This is not correct: a service SID represent specific service function (VPN, SFC, etc.) with a specific intent. Thus it is not the combination of the sub-locators and the service functions.
This approach can be used by devices that possess limited SID stacking capabilities to be able to support differential services at the cost of more state in the transport network. These color Service SIDs need to be present across the entire transport network for the forwarding to work. This makes the transport network state a function of the service layer SID state.
[Jie] Comparing to CT, there will be no more state in the transport network using CPR. The service SIDs are only maintained by the PE nodes, the P nodes and ASBRs only need to maintain the state of the colorful prefixes. This is the benefit of SRv6: packet forwarding is based on longest prefix matching, in contrast to the label swapping in MPLS.
Here it mentions the benefit of CPR is for devices with limited SID stacking capability, which is not quite correct. As Jingrong pointed out, the big difference between SRv6 and SR-MPLS data plane needs to be fully understood. SRv6 is not simply SID stacking, it requires the encapsulation of one or multiple SRH, together with one or multiple IPv6 headers. Saving one SID for the transport path could result in saving 48 bytes (IPv6 header+SRH fixed header) overhead.
This Service SID scale impacts the overall convergence while executing operational procedures like color sub-locator modification, where all the service routes have to be readvertised with their new Service SID computed as a result of the color sub-locator change. This also impacts BGP PIC (Prefix scale Independent Convergence) for the egress SN failure where all Service SIDs need to be withdrawn.
[Jie] Currently SRv6 service SIDs use the locator of the node as the covering prefix, if the locator changes, the service SIDs also needs to be readvertised. This is not something new introduced by CPR. Also the color sub-locators are usually provisioned via configuration or management plane, not sure what is the possible use case of color sub-locator modification.
This approach achieves strict color based forwarding for the service routes. However, it cannot achieve per service route fallback intent using resolution schemes as BGP CT procedures are not applied to service family routes.
[Jie] Thanks to the longest prefix matching, CPR can support fall back to the best effort path automatically if there is no matching route for the colorful sub-locator. In my understanding for CT the more complicated fallback mechanisms would be based on local configured policy. If so, the same policy could also be applied to the service routes with CPR.
-Jie