Hi Ketan Thank you for the response. I believe that does answer the general questions from a draft specification perspective. I had not read all the way through the draft so missed that section. I do have some Cisco specific SR-TE questions that I will ping you off list.
Kind regards Gyan On Mon, Jun 1, 2020 at 10:59 AM Ketan Talaulikar (ketant) <[email protected]> wrote: > 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 <[email protected]> > *Sent:* 01 June 2020 19:17 > *To:* Chengli (Cheng Li) <[email protected]> > *Cc:* Fangsheng <[email protected]>; Ketan Talaulikar (ketant) < > [email protected]>; Robert Raszuk <[email protected]>; SPRING WG < > [email protected]>; [email protected]; idr > wg <[email protected]>; stefano previdi <[email protected]> > *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) <[email protected]> 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:[email protected]] > *Sent:* Monday, May 18, 2020 8:00 PM > *To:* Robert Raszuk <[email protected]> > *Cc:* Chengli (Cheng Li) <[email protected]>; > [email protected]; idr wg <[email protected]>; > SPRING WG <[email protected]>; Fangsheng <[email protected]>; stefano > previdi <[email protected]> > *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 <[email protected]> > *Sent:* 30 April 2020 14:46 > *To:* Ketan Talaulikar (ketant) <[email protected]> > *Cc:* Chengli (Cheng Li) <[email protected]>; > [email protected]; idr wg <[email protected]>; > SPRING WG <[email protected]>; Fangsheng <[email protected]>; stefano > previdi <[email protected]> > *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= > [email protected]> 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 <[email protected]> *On Behalf Of *Chengli (Cheng Li) > *Sent:* 30 April 2020 07:34 > *To:* [email protected] > *Cc:* SPRING WG <[email protected]>; huruizhao <[email protected]>; > Fangsheng <[email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > -- > > <http://www.verizon.com/> > > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> > *Silver Spring, MD > <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
