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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
