Sorry for so many questions. This may belong in rtgwg - are their plans for SRv6 to support SR-TE.
My understanding is that with SRv6 with all nodes SRv6 capable that with prefix sid specifies for End behavior you have the ECMP & UCMP capability but then the vpn coloring capabilities as well as other capabilities you don’t get without SR-TE. If it’s true that SR-TE will not be added to SRv6 then that makes SR-MPLS more attractive then SRv6. Gyan On Sat, Mar 14, 2020 at 3:05 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > > > BESS authors of services draft, > > A follow on question. > > My understanding is there are two modes. > > a. BE services mode where SRH is not present - brown field or migration > scenario > > b. SLA services mode - steering mode where SRH is present -green field > scenario > > > Please explain both modes in the context of which nodes if any need to > SRv6 capable for either to work. > > Also is there a difference between SRv6 capable and SRv6 aware nodes. > > Kind of reminds me of Graceful restart capability exchange with helper > router being the GR aware router and the restart router being GR capable > router. > > Does that concept apply to SRv6 in the brown field mixed environment. > > Kind regards > > Gyan > > On Sat, Mar 14, 2020 at 2:55 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > >> >> Eduard >> >> I have some similar questions related to BE L3 VPN >> >> Dear BESS authors of SRv6 services draft Q&A: >> >> My understanding is that with BE L3 vpn all nodes including the ingress >> and egress PE are not SRv6 capable >> >> However, If the egress PE is brown field in an MPLS IPv4 enabled core and >> not SRv6 capable and let’s say the ingress PE is SRv6 capable, how does the >> egress PE signal for SRv6 services sid with the BGP overlay services route >> with corresponding RT for VRF to be instantiation. The egress PE is not >> SRv6 capable so would not be able to signal for the SRv6 services SID with >> the L3 vpn BGP overlay. I did notice that in that verbiage in the first >> sentence it is saying simultaneous SRv6 and MPLS. Is that true and if so >> then it’s more like MPLS and SRv6 data planes are active simultaneously >> which does not make sense either. >> >> In the introduction verbiage on BE VPN is confusing >> >> To provide SRv6 service with best-effort connectivity, the egress PE >> signals an SRv6 Service SID with the BGP overlay service route. The >> ingress PE encapsulates the payload in an outer IPv6 header where the >> destination address is the SRv6 Service SID provided by the egress >> PE. The underlay between the PEs only need to support plain IPv6 >> forwarding [RFC2460 <https://tools.ietf.org/html/rfc2460>]. >> >> >> Section 3 BGP based L3 vpn over IPv6 >> >> If the BGP speaker supports MPLS based L3VPN services simultaneously, >> it MAY also populate a valid Label value in the service route NLRI >> encoding, and allow the BGP ingress PE to decide which encapsulation >> to use. If the BGP speaker does not support MPLS based L3VPN >> services the Label value in any service route NLRI encoding MUST be >> set to Implicit NULL [RFC3032 <https://tools.ietf.org/html/rfc3032>]. >> >> At an ingress PE, BGP installs the received prefix in the correct RIB >> table, recursing via an SR Policy leveraging the received SRv6 >> Service SID. >> >> Assuming best-effort connectivity to the egress PE, the SR policy has >> a path with a SID list made up of a single SID - the SRv6 Service SID >> received with the related BGP route update. >> >> However, when the received route is colored with an extended color >> commmunity 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6 >> Policy (C, N) associated with SID list <S1,S2, S3> [I-D.filsfils- >> spring-segment-routing-policy], then the effective SR Policy is <S1, >> S2, S3, SRv6-Service-SID>. >> >> >> In this section for BE services this is where source node Ingres PE is >> SRv6 capable and egress PE is not and in that case the egress PE services >> SID would not be signaled with BGP overlay and the source node would >> instantiation of the path would happen on the source node independently of >> egress node signaling- and I guess in the case PSP mode would need to be >> enabled to remove the SRH header prior to the egress PE final destination. >> >> I started reading through this draft to help with my questions on >> interoperability with MPLS and SR-MPLS and brown field deployments where >> all nodes have a mix of capabilities. >> >> https://tools.ietf.org/html/draft-agrawal-spring-srv6-mpls-interworking-02 >> >> This draft talks about stitching domains together that SRv6 domain with >> MPLS or SR-MPLS domains. >> >> Can you use the same concept of advertising the prefix sid with intra >> domain with AFI 2 SAFI 1 from the egress PE to ingress PE to signal the >> egress PE for SRv6 instantiation of a BE SRv6 path with capable or non SRv6 >> capable source node. >> >> Also with MPLS and SR-MPLS we have a bottom of stack service label so the >> label stacks are similar as far as bottom of stack service label which >> helps with that interoperability. However with SRv6 there is not any >> bottom of stack service label since the egress PE signals via services sid >> with bgp overlay to egress PE for instantiation of L3 vpn services. So >> since SRv6 does not have a bottom of stack service label, I can see how >> having an overlay of MPLS and SRv6 operating simultaneously may not be >> possible, but I think this capability would really be helpful for brown >> field deployments. >> >> 3.2 >> <https://tools.ietf.org/html/draft-agrawal-spring-srv6-mpls-interworking-02#section-3.2>. >> Stitching heterogenous domains usin BGP inter domain routing >> >> For providing services across domains, edge node locators need to be >> reachable. >> >> -Locators are advertised by edge nodes in the BGP ipv6 unicast >> address family (AFI=2,Safi=1) to border nodes. These locators are >> also advertised in its local IGP domain. >> >> -On border nodes these prefixes are like any IPv6 global prefixes. >> These will be advertised in BGP IPv6 LU[AFI=2/SAFI=4] session using >> >> >> On Fri, Mar 13, 2020 at 7:18 AM Eduard Metz <etm...@gmail.com> wrote: >> >>> Hi, >>> >>> How is the migration from MPLS to SRv6 dataplane foreseen in relation to >>> bess-srv6-services? >>> For instance the case where egress PE supports both MPLS and SRv6 >>> dataplane and ingress PE supports MPLS only. >>> Would the egress PE advertise two routes in this case (with different >>> RD)? >>> >>> cheers, >>> Eduard >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mis...@verizon.com >> >> >> >> -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mis...@verizon.com > > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mis...@verizon.com
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
