Hi Shraddha I agree the fallback mechanisms are important to operators but as there are many complex scenarios related to fallback and some of which include SRv6 to SR-MPLS interworking, I agree that this is important and as such can be captured in a separate document that defines all the permutations in detail.
As this SRv6 BGP overlay services specification is critical for operators as it’s in WGLC I think it should proceed to publication. Kind Regards Gyan On Fri, Jul 23, 2021 at 12:40 PM Aissaoui, Mustapha (Nokia - CA/Ottawa) < mustapha.aissa...@nokia.com> wrote: > That is great. Thank you. > > > > Mustapha. > > > > *From:* Ketan Talaulikar (ketant) <ket...@cisco.com> > *Sent:* Friday, July 23, 2021 11:08 AM > *To:* Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissa...@nokia.com> > *Cc:* spr...@ietf.org; Shraddha Hegde <shrad...@juniper.net>; > bess@ietf.org; draft-ietf-bess-srv6-servi...@ietf.org > *Subject:* RE: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > < trimming list to mostly mailers > > > > > Hi Mustapha, > > > > I agree. > > > > Also after seeing Shraddha’s latest email, the coverage and details for > the fallback mechanisms that she seems to be looking for is quite vast and > better tackled in a separate document since this one has completed its > WGLC. Some of those concepts are applicable for MPLS as well and not SRv6 > specific. > > > > We (authors) will work on some text proposal and get back to the WG next > week. > > > > Thanks, > > Ketan > > > > *From:* Aissaoui, Mustapha (Nokia - CA/Ottawa) < > mustapha.aissa...@nokia.com> > *Sent:* 23 July 2021 19:20 > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com>; Rajesh M < > mraj...@juniper.net>; Rajesh M <mraj...@juniper.net>; Rabadan, Jorge > (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; > gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; > rob...@raszuk.net; bruno.decra...@orange.com > *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli <ssan...@juniper.net>; > Shraddha Hegde <shrad...@juniper.net>; bess@ietf.org > *Subject:* RE: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > Hi Ketan, > > I believe it will be worth expanding the text in > draft-ietf-bess-srv6-services to describe the two types of transport more > consistently and along the lines of what you wrote below. Also, I would > propose that we move away from terminology like best-effort service and > instead just mention shortest path forwarding in base topology or in > flex-algo topology. > > > > Mustapha. > > > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Ketan Talaulikar > (ketant) > *Sent:* Thursday, July 22, 2021 3:43 AM > *To:* Rajesh M <mraj...@juniper.net>; Rajesh M < > mrajesh=40juniper....@dmarc.ietf.org>; Rabadan, Jorge (Nokia - > US/Mountain View) <jorge.raba...@nokia.com>; gdawra.i...@gmail.com; > Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; rob...@raszuk.net; > bruno.decra...@orange.com > *Cc:* spr...@ietf.org; b...@ans.net; Srihari Sangli <ssan...@juniper.net>; > Shraddha Hegde <shrad...@juniper.net>; bess@ietf.org > *Subject:* Re: [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > Hi Rajesh, > > > > My apologies for the delay in my response. However, some of my co-authors > and other WG members have already clarified this point. Let me try to > summarize. > > > > The draft covers two SRv6 based mechanisms for the transport of services > between SRv6 PEs. (1) using SR Policy based steering (i.e. for service > routes with Color Extended Communities) using the H.encap construct along > with a list of SRv6 segments and the other (2) using H.encap with just the > SRv6 Service SID in the IPv6 DA. > > > > As mentioned in the draft, it is required to verify the reachability of > the SRv6 Service SID before the mechanism (2) can be used. This is an > explicit clarification for verification of reachability. In an MPLS-VPN > scenario, if the egress PE NH’s IP route is reachable at the ingress PE but > without an MPLS label, such a path cannot be used. This is semantically > similar. > > > > The mechanism (1) is different since the routing to the egress PE is via > SR Policy and hence the requirement for verification of reachability of the > SRv6 Service SID is not there. > > > > There is no mandate for the setting of the NH since that is left to > deployment design. > > > > I hope this helps in addition to the various clarifications already > provided by others. > > > > Thanks, > > Ketan > > > > *From:* Rajesh M <mraj...@juniper.net> > *Sent:* 22 July 2021 12:09 > *To:* Rajesh M <mrajesh=40juniper....@dmarc.ietf.org>; Rabadan, Jorge > (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; Ketan Talaulikar > (ketant) <ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils > (cfilsfil) <cfils...@cisco.com>; rob...@raszuk.net; > bruno.decra...@orange.com > *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde <shrad...@juniper.net>; > bess@ietf.org; Srihari Sangli <ssan...@juniper.net> > *Subject:* RE: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > Could Authors respond to this ? > > > > > > Juniper Business Use Only > > *From:* Rajesh M <mrajesh=40juniper....@dmarc.ietf.org> > *Sent:* Monday, July 19, 2021 7:28 PM > *To:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; > Rajesh M <mraj...@juniper.net>; Ketan Talaulikar (ketant) < > ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) < > cfils...@cisco.com>; rob...@raszuk.net; bruno.decra...@orange.com > *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde <shrad...@juniper.net>; > bess@ietf.org; Srihari Sangli <ssan...@juniper.net> > *Subject:* RE: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > *[External Email. Be cautious of content]* > > > > Hi All, > > > > For best effort service, flex algo – Resolve SRv6 Service SID for > forwarding. > > For SR-TE, CAR/CT - Resolve BGP next hop for forwarding. > > > > There is no unification here, it’s better to unify. > > Any other solution is OK. > > > > Thanks > > Rajesh > > > > > > Juniper Business Use Only > > *From:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> > > *Sent:* Monday, July 19, 2021 7:17 PM > *To:* Rajesh M <mraj...@juniper.net>; Rajesh M < > mrajesh=40juniper....@dmarc.ietf.org>; Ketan Talaulikar (ketant) < > ket...@cisco.com>; gdawra.i...@gmail.com; Clarence Filsfils (cfilsfil) < > cfils...@cisco.com>; rob...@raszuk.net; bruno.decra...@orange.com > *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde <shrad...@juniper.net>; > bess@ietf.org; Srihari Sangli <ssan...@juniper.net> > *Subject:* Re: SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > *[External Email. Be cautious of content]* > > > > 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 <mraj...@juniper.net> > *Date: *Monday, July 19, 2021 at 3:24 PM > *To: *Rajesh M <mrajesh=40juniper....@dmarc.ietf.org>, Ketan Talaulikar > (ketant) <ket...@cisco.com>, gdawra.i...@gmail.com <gdawra.i...@gmail.com>, > Clarence Filsfils (cfilsfil) <cfils...@cisco.com>, rob...@raszuk.net < > rob...@raszuk.net>, bruno.decra...@orange.com <bruno.decra...@orange.com>, > Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> > *Cc: *spr...@ietf.org <spr...@ietf.org>, b...@ans.net <b...@ans.net>, > Shraddha Hegde <shrad...@juniper.net>, bess@ietf.org <bess@ietf.org>, > Srihari Sangli <ssan...@juniper.net> > *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 <spring-boun...@ietf.org> *On Behalf Of *Rajesh M > *Sent:* Thursday, July 15, 2021 4:36 PM > *To:* Ketan Talaulikar (ketant) <ket...@cisco.com>; gdawra.i...@gmail.com; > Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; rob...@raszuk.net; > bruno.decra...@orange.com; jorge.raba...@nokia.com > *Cc:* spr...@ietf.org; b...@ans.net; Shraddha Hegde <shrad...@juniper.net>; > bess@ietf.org > *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 > _______________________________________________ > spring mailing list > spr...@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
