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) < [email protected]> wrote: > That is great. Thank you. > > > > Mustapha. > > > > *From:* Ketan Talaulikar (ketant) <[email protected]> > *Sent:* Friday, July 23, 2021 11:08 AM > *To:* Aissaoui, Mustapha (Nokia - CA/Ottawa) <[email protected]> > *Cc:* [email protected]; Shraddha Hegde <[email protected]>; > [email protected]; [email protected] > *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) < > [email protected]> > *Sent:* 23 July 2021 19:20 > *To:* Ketan Talaulikar (ketant) <[email protected]>; Rajesh M < > [email protected]>; Rajesh M <[email protected]>; Rabadan, Jorge > (Nokia - US/Mountain View) <[email protected]>; > [email protected]; Clarence Filsfils (cfilsfil) <[email protected]>; > [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; Srihari Sangli <[email protected]>; > Shraddha Hegde <[email protected]>; [email protected] > *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 <[email protected]> *On Behalf Of *Ketan Talaulikar > (ketant) > *Sent:* Thursday, July 22, 2021 3:43 AM > *To:* Rajesh M <[email protected]>; Rajesh M < > [email protected]>; Rabadan, Jorge (Nokia - > US/Mountain View) <[email protected]>; [email protected]; > Clarence Filsfils (cfilsfil) <[email protected]>; [email protected]; > [email protected] > *Cc:* [email protected]; [email protected]; Srihari Sangli <[email protected]>; > Shraddha Hegde <[email protected]>; [email protected] > *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 <[email protected]> > *Sent:* 22 July 2021 12:09 > *To:* Rajesh M <[email protected]>; Rabadan, Jorge > (Nokia - US/Mountain View) <[email protected]>; Ketan Talaulikar > (ketant) <[email protected]>; [email protected]; Clarence Filsfils > (cfilsfil) <[email protected]>; [email protected]; > [email protected] > *Cc:* [email protected]; [email protected]; Shraddha Hegde <[email protected]>; > [email protected]; Srihari Sangli <[email protected]> > *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 <[email protected]> > *Sent:* Monday, July 19, 2021 7:28 PM > *To:* Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]>; > Rajesh M <[email protected]>; Ketan Talaulikar (ketant) < > [email protected]>; [email protected]; Clarence Filsfils (cfilsfil) < > [email protected]>; [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; Shraddha Hegde <[email protected]>; > [email protected]; Srihari Sangli <[email protected]> > *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) <[email protected]> > > *Sent:* Monday, July 19, 2021 7:17 PM > *To:* Rajesh M <[email protected]>; Rajesh M < > [email protected]>; Ketan Talaulikar (ketant) < > [email protected]>; [email protected]; Clarence Filsfils (cfilsfil) < > [email protected]>; [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; Shraddha Hegde <[email protected]>; > [email protected]; Srihari Sangli <[email protected]> > *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 <[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 > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
