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> 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] > *Sent:* Monday, May 18, 2020 8:00 PM > *To:* Robert Raszuk <rob...@raszuk.net> > *Cc:* Chengli (Cheng Li) <c...@huawei.com>; > draft-ietf-spring-segment-routing-pol...@ietf.org; idr wg <i...@ietf.org>; > SPRING WG <spring@ietf.org>; Fangsheng <fangsh...@huawei.com>; stefano > previdi <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> > *Sent:* 30 April 2020 14:46 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> > *Cc:* Chengli (Cheng Li) <chengl...@huawei.com>; > draft-ietf-spring-segment-routing-pol...@ietf.org; idr wg <i...@ietf.org>; > SPRING WG <spring@ietf.org>; Fangsheng <fangsh...@huawei.com>; stefano > previdi <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> 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> *On Behalf Of *Chengli (Cheng Li) > *Sent:* 30 April 2020 07:34 > *To:* draft-ietf-spring-segment-routing-pol...@ietf.org > *Cc:* SPRING WG <spring@ietf.org>; huruizhao <huruiz...@huawei.com>; > Fangsheng <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 > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
