Hi Gyan, Your question is a bit orthogonal to the thread and my apologies if I did not get it right.
Could you please check whether the following section clarifies what you were looking for? https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-07#section-8.4 The draft does not talk about the application of a specific Color Extended Community attribute to all routes belonging to a specific VRF since that is more of a local policy or implementation matter. Thanks, Ketan From: Gyan Mishra <hayabusa...@gmail.com> Sent: 01 June 2020 19:17 To: Chengli (Cheng Li) <c...@huawei.com> Cc: Fangsheng <fangsh...@huawei.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>; Robert Raszuk <rob...@raszuk.net>; SPRING WG <spring@ietf.org>; draft-ietf-spring-segment-routing-pol...@ietf.org; idr wg <i...@ietf.org>; stefano previdi <stef...@previdi.net> Subject: Re: [spring] [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) Ketan Thanks for sharing this draft. This draft below is the SR-TE policy itself but the piece I was missing was the BGP interaction between SR-TE and new SAFI to advertise SR-TE policy into BGP which is the critical component of the per VRF coloring schema to steer L3 vpn traffic. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-07 On Mon, Jun 1, 2020 at 3:25 AM Chengli (Cheng Li) <c...@huawei.com<mailto:c...@huawei.com>> wrote: Hi Ketan, Sorry for my delay, I saw the update, and it has addressed my comments, many thanks. Best, Cheng From: Ketan Talaulikar (ketant) [mailto:ket...@cisco.com<mailto:ket...@cisco.com>] Sent: Monday, May 18, 2020 8:00 PM To: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: Chengli (Cheng Li) <c...@huawei.com<mailto:c...@huawei.com>>; draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org>; idr wg <i...@ietf.org<mailto:i...@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Fangsheng <fangsh...@huawei.com<mailto:fangsh...@huawei.com>>; stefano previdi <stef...@previdi.net<mailto:stef...@previdi.net>> Subject: RE: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) Hi Robert, You are right that the “Originator” is not used in BGP best path and is just for a tie-breaking logic in SRTE between paths from different protocols and controllers. I doubt if there is a functional issue here. I thought that Chengli was bringing in some new/different requirement for the “Originator” field for some deployment design. I haven’t seen a response/clarification from him as yet, and so perhaps I misunderstood him in which case we are ok here. Thanks, Ketan From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: 30 April 2020 14:46 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>> Cc: Chengli (Cheng Li) <chengl...@huawei.com<mailto:chengl...@huawei.com>>; draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org>; idr wg <i...@ietf.org<mailto:i...@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Fangsheng <fangsh...@huawei.com<mailto:fangsh...@huawei.com>>; stefano previdi <stef...@previdi.net<mailto:stef...@previdi.net>> Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) Hi Chengli and Ketan, Well I think (perhaps to your surprise) the current text is actually correct. See the overall idea of section 2.4 is not to define the real source of the candidate path. That is done in section 2.5 The idea here is to keep multiple *paths or versions* of the candidate paths in the local system uniquely. See if you continue reading section 2.6 demystifies the real objective: The tuple <Protocol-Origin, originator, discriminator> uniquely identifies a candidate path. So the real originator is encoded in discriminator and here it just means the peer candidate path was received from. And if you read on this entire exercise only servers best path selection as described in section 2.9. .... the following order until only one valid best path is selected: 1. Higher value of Protocol-Origin is selected. 2. If specified by configuration, prefer the existing installed path. 3. Lower value of originator is selected. 4. Finally, the higher value of discriminator is selected. + The originator allows an operator to have multiple redundant controllers and still maintain a deterministic behaviour over which of them are preferred even if they are providing the same candidate paths for the same SR policies to the headend. Thx, R. On Thu, Apr 30, 2020 at 10:46 AM Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Hi Cheng, I assume you are recommending the use of Route Origin Extended Community (https://tools.ietf.org/html/rfc4360#section-5) for conveying the “Originator” when the SR Policy update is propagated over eBGP sessions via other eBGP/iBGP sessions instead of direct peering with the headend. I believe it does address the scenario you describe given that it is expected that SR Policy propagation via BGP is happening within a single administrative domain even if it comprises of multiple ASes. Also copying the IDR WG for inputs since this would likely need to be updated in draft-ietf-idr-segment-routing-te-policy. Thanks, Ketan From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Chengli (Cheng Li) Sent: 30 April 2020 07:34 To: draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org> Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; huruizhao <huruiz...@huawei.com<mailto:huruiz...@huawei.com>>; Fangsheng <fangsh...@huawei.com<mailto:fangsh...@huawei.com>> Subject: [spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy) Hi authors, In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how the node-address of "Originator of CP(Candidate Path)" is generated when the Protocol-Origin is BGP. It says: “Protocol-Origin is BGP SR Policy, it is provided by the BGP component on the headend and is: o the BGP Router ID and ASN of the node/controller signalling the candidate path when it has a BGP session to the headend, OR o the BGP Router ID of the eBGP peer signalling the candidate path along with ASN of origin when the signalling is done via one or more intermediate eBGP routers, OR o the BGP Originator ID [RFC4456] and the ASN of the node/controller when the signalling is done via one or more route-reflectors over iBGP session.” In the operator's network, in order to reduce the number of BGP sessions in controller and achieve scalability, the controller only establishes eBGP peer with the RR. And the RR establishes iBGP peers with the headends. As mentioned in the draft, the headend will use the RR's Router ID as the CP's node-address (the signaling is done via route transmission from RR to the headend instead of route reflection). The headend needs to carry the CP's key when reporting the SR Policy status to the controller through BGP-LS. And there is a problem that the controller may not recognize the key because the node-address is generated by the RR node. For network robustness, two or more RRs are usually deployed. This will introduce another problem.. When the same CP advertised by the controller is delivered to the headend through different RRs, the headend cannot distinguish whether it is the same CP because the node-address in the CPs' key comes from different RRs. To solve these problems, We recommend carrying the Route Origin Community (defined in RFC 4360) directly when the controller advertises BGP routes. In this way, the key of the CP is determined by the controller and will not change during the advertisement of BGP routes. Thanks, Cheng _______________________________________________ Idr mailing list i...@ietf.org<mailto:i...@ietf.org> https://www.ietf.org/mailman/listinfo/idr _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
