Re: [Idr] [spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

[Gyan Mishra <[e-mail]>]

On Thu, May 28, 2020 at 6:32 AM Ketan Talaulikar (ketant) <[e-mail]>
wrote:

> Hi Gyan,
>
>
>
> Could I refer you to the examples in
> https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-05#section-4
> as that might clarify the various options for signalling redundant
> information (both as different BGP NLRI, via redundant BGP paths, or via
> multiple protocol sources).
>
>  Gyan> Thanks Ketan.  So this scenario would be example 2 recommended with
> “auto RD” type 1 unique by loopback so both paths are installed in BGP sent
> to SR-TE for instantiation which now picks greater candidate path number as
> Active path.
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra <[e-mail]>
>
> *Sent:* 22 May 2020 00:48
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Chengli (Cheng Li) <[e-mail]>; Fangsheng <[e-mail]>;
> Ketan Talaulikar (ketant) <[e-mail]>; SPRING WG <[e-mail]>;
> Yangang <[e-mail]>;
> [e-mail]; idr wg <[e-mail]>;
> stefano previdi <[e-mail]>
> *Subject:* Re: [spring] [Idr] Comments: Route Origin Community in SR
> Policy(draft-ietf-spring-segment-routing-policy)
>
>
>
>
>
> On Wed, May 20, 2020 at 8:59 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
>
>
> > the node-address is generated by CSG1
>
>
>
> I don't think CSG1 needs to "generate" anything. Peers which send you
> particular policy are well known at CSG1.
>
>
>
> > The process described above will result in a waste of redundant
> candidate paths on CSG1,
>
>
>
> Well what you call "waste" I call redundancy. Sure keeping extra paths
> requires some cost, but building redundancy in control plane pays off.
>
>
>
>     Gyan> I agree with Robert that the additional candidate path sent by
> the RR could be used for redundancy.   However, I think the context of  SR
> TE is that each candidate path is a single path option not multiple as the
> redundancy is provided by different candidate paths.  That is the issue I
> am guessing.
>
>
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Wed, May 20, 2020 at 2:32 PM Fangsheng <[e-mail]> wrote:
>
> Hi Robert,
>
> Take the following picture as an example, I think you can understand our
> problem more easily.
>
> The controller needs to notify the headend CSG1 through BGP SR Policy to
> create a candidate path of SR Policy. This BGP SR Policy route will be
> advertised to CSG1 through RR1 and RR2.
>
> According to the definition in draft, the key of a candidate path is
> <Protocol-Origin, originator, discriminator>, where originator = <ASN,
> node-address>, so a complete candidate path key is <Protocol-Origin, ASN,
> node-address , discriminator>.
>
> However, in this specific example, the node-address is generated by CSG1,
> and because CSG1 receives BGP SR Policy routes from RR1 and RR2,
> respectively, CSG1 will get two different node-addresses. CSG1 thinks that
> it is necessary to create two  candidate paths, and the controller does not
> know what the node-address CSG1 will eventually generate. Maybe:
>
> Candidate path 1’ key:  <*BGP,RR1’s ASN, RR1’ BGP Router ID,
> discriminator1*>
>
> Candidate path 2’ key:  <*BGP,RR2’s ASN, RR2’ BGP Router ID,
> discriminator2*>
>
> The process described above will result in a waste of redundant candidate
> paths on CSG1,
>
> At the same time, when CSG1 needs to announce the SR Policy information to
> the controller through BGP LS, it needs to carry the keys of the candidate
> path in it, and the controller cannot recognize these keys.
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
> *发件人**:* Ketan Talaulikar (ketant) [mailto:[e-mail]]
> *发送时间**:* 2020年5月18日 20:00
> *收件人**:* Robert Raszuk <[e-mail]>
> *抄送**:* Chengli (Cheng Li) <[e-mail]>;
> [e-mail]; idr wg <[e-mail]>;
> SPRING WG <[e-mail]>; Fangsheng <[e-mail]>; stefano
> previdi <[e-mail]>
> *主题**:* 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 <[e-mail]>
> *Sent:* 30 April 2020 14:46
> *To:* Ketan Talaulikar (ketant) <[e-mail]>
> *Cc:* Chengli (Cheng Li) <[e-mail]>;
> [e-mail]; idr wg <[e-mail]>;
> SPRING WG <[e-mail]>; Fangsheng <[e-mail]>; stefano
> previdi <[e-mail]>
> *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=
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Chengli (Cheng Li)
> *Sent:* 30 April 2020 07:34
> *To:* [e-mail]
> *Cc:* SPRING WG <[e-mail]>; huruizhao <[e-mail]>;
> Fangsheng <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> spring mailing list
> [e-mail]
> 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