I agree with Jorge.. In fact I find the tone of the comment to be very inappropriate:
*> In case of best effort/flex algo we must mandate user to set corresponding locator as BGP nexthop for srv6 routes.* *No we MUST not mandate anything to the user. * *We MUST provide flexibility to address all deployment cases user may have. * *Best,* *R.* On Mon, Jul 19, 2021 at 3:47 PM Rabadan, Jorge (Nokia - US/Mountain View) < [email protected]> wrote: > Hi Rajesh, > > > > The draft is written so that the next-hop address MAY be covered by the > locator, but there are cases in which the next-hop address is not part of > the locator prefix, and there are implementations already allowing that, so > I don’t agree the document should mandate what you are suggesting. > > > > Thanks. > > Jorge > > > > *From: *Rajesh M <[email protected]> > *Date: *Monday, July 19, 2021 at 3:24 PM > *To: *Rajesh M <[email protected]>, Ketan Talaulikar > (ketant) <[email protected]>, [email protected] <[email protected]>, > Clarence Filsfils (cfilsfil) <[email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, > Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]> > *Cc: *[email protected] <[email protected]>, [email protected] <[email protected]>, > Shraddha Hegde <[email protected]>, [email protected] <[email protected]>, > Srihari Sangli <[email protected]> > *Subject: *RE: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > Hi Authors, > > > > Please respond. > > > > Thanks > > Rajesh > > > > > > Juniper Business Use Only > > *From:* spring <[email protected]> *On Behalf Of *Rajesh M > *Sent:* Thursday, July 15, 2021 4:36 PM > *To:* Ketan Talaulikar (ketant) <[email protected]>; [email protected]; > Clarence Filsfils (cfilsfil) <[email protected]>; [email protected]; > [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; Shraddha Hegde <[email protected]>; > [email protected] > *Subject:* [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > *[External Email. Be cautious of content]* > > > > Hi All, > > > > As per this draft, this is how resolution must work. > > > > 1)For Non Intent service Route: > > if BGP next hop is not reachable return. > > Resolve SRv6 Service SID for forwarding. > > > > 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR > Policy): > > BGP next hop is not reachable return. > > Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if > successfully resolves then return. > > Resolve BGP next hop for forwarding (in case above is not success). > > > > > > *Using Service SID (overlay),for resolution is definitely not recommended.* > > > > *Instead in case of srv6, we always resolve on BGP nexthop. This will be > in line with BGP legacy.* > > *In case of best effort/flex algo we must mandate user to set > corresponding locator as BGP nexthop for srv6 routes.* > > *I think this is a reasonable mandate.* > > > > Thanks > > Rajesh > > > > Juniper Business Use Only >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
