IMO we could add to the draft a statement that implementation MUST/SHOULD support fallback to any available forwarding plane. But I am not sure if this will not turn out against some implementations which may have problem with that.
Order of such fallback is a policy/cfg decision. Likewise before considering any forwarding plane use a data plane reachability to the endpoint must be validated/tested - that should go without saying but as we know there are implementations which only rely on a control plane which is proven in action to be a rather poor method. There are number of reasons where presence in RIB/inet does is not the same as data plane reachability . Thx, Robert. On Thu, Jul 22, 2021 at 12:41 PM Ketan Talaulikar (ketant) <[email protected]> wrote: > Hi Salih, > > > > The preference for steering over SR Policy applies to both SR-MPLS and > SRv6. So we are covered from that perspective. > > > > I get the impression that this email discussion thread about “fallback” is > about when sending over a non-SR Policy based steering mechanism. That too, > I get the impression is that it is specifically about the scenario where > there might not be a reachability via IGP FlexAlgo for the egress PE’s > Locator from which the SRv6 service SID is allocated from. > > > > To me (and few other WG members), an alternate path or tunnel mechanism to > reach the egress PE is something that is deployment specific and can be > implemented via various mechanisms. While Shraddha has proposed a mechanism > for this, I’ve also described a new other ways – there will be more. While > the draft currently does not discuss this, it does not preclude any of > these mechanisms either. > > > > The draft is currently done with WGLC and is in our AD (Martin’s) Q for > his review. The question for the WG is if we do really need to clarify > something about this “FlexAlgo fallback” case and if so, come up with some > proposed text. IMHO details of such fallback mechanisms are outside the > scope of this document and we can say so if that helps. > > > > Thanks, > > Ketan > > > > *From:* Salih K A <[email protected]> > *Sent:* 22 July 2021 15:35 > *To:* Ketan Talaulikar (ketant) <[email protected]>; Rajesh M < > [email protected]> > *Cc:* [email protected]; [email protected]; > [email protected] > *Subject:* Re: [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > Thanks, Ketan. > > > > This indicates a preference for steering over SR Policy while using color > extended community. > > Then specify color only bits etc modes for specifying fallbacks if > required. Currently it doesn’t talk about flex (but mention mostly IGP path > to the next-hop N) and hence it need not necessarily pick SRv6 flex algo > paths. > > > > Are we suggesting only if some indication comes the fallback will happen > to flex algo? OR can we define an order like: > > SRv6 policy (using BGP NH) > > SRv6 Flex (using SRv6 Service SID) > > > > and a mention of local policy which can override if required. > > > > Regards, > > Salih > > *From: *"Ketan Talaulikar (ketant)" <[email protected]> > *Date: *Thursday, July 22, 2021 at 2:25 PM > *To: *Salih K A <[email protected]>, Rajesh M <[email protected]> > *Cc: *"[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *RE: [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > *[External Email. Be cautious of content]* > > > > Hi Salih, > > > > Could you please check the following regarding the choice/fallback when > using SR Policy based steering? > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.4 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.4__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMOUxwCSPQ$> > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13#section-8.8 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-13*section-8.8__;Iw!!NEt6yMaO-gk!TYCZx62Jhc5xQg9DaeTZQM8PD_jYpavDX9bwo69wEp_Rycrt39LGrMMv4_vtIA$> > > > > Thanks, > > Ketan > > > > *From:* Salih K A <[email protected]> > *Sent:* 22 July 2021 14:02 > *To:* Ketan Talaulikar (ketant) <[email protected]>; > Rajesh M <[email protected]> > *Cc:* [email protected]; [email protected]; > [email protected] > *Subject:* Re: [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > Hi Ketan, > > > > 1 clarification query: > > > > With flex algo and SRTE policies, service routes can carry color extended > communities. > > Now for the ingress, how to decide whether to resolve over SRv6 Service > SID (to choose flex algo) OR over BGP Protocol next hop (to choose SRTE)? > > In a domain both can be present & operators may want fallbacks as well if > one is not available. So, I think it’s better to clarify that to avoid > ambiguity. > > > > Thanks, > Salih > > *From: *spring <[email protected]> on behalf of "Ketan Talaulikar > (ketant)" <[email protected]> > *Date: *Thursday, July 22, 2021 at 1:19 PM > *To: *Rajesh M <[email protected]> > *Cc: *"[email protected]" < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [spring] SRv6 BGP based Overlay Services > (draft-ietf-bess-srv6-services-07) > > > > *[External Email. Be cautious of content]* > > > > Resending with individual email addressed trimmed > > > > *From:* Ketan Talaulikar (ketant) > *Sent:* 22 July 2021 13:13 > *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]; Shraddha Hegde <[email protected]>; > [email protected]; Srihari Sangli <[email protected]> > *Subject:* RE: 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 >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
