Subject: [bess] MPLS to SRv6 migration (in relation to bess-srv6-services)

From: Eduard Metz <[email-masked]>
Date: Fri, 13 Mar 2020 12:18:19 +0100

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 14:55:43 -0400

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 <[email-masked]> wrote:

> For instance the case where egress PE supports both MPLS and SRv6
> dataplane and ingress PE supports MPLS only.
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 15:05:06 -0400

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 <[email-masked]> wrote:

> My understanding is that with BE L3 vpn all nodes including the ingress
> and egress PE are not SRv6 capable
>
> 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
> 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
>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 14 Mar 2020 15:12:42 -0400

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 <[email-masked]> wrote:

> Please explain both modes in the context of which nodes if any need to
> SRv6 capable for either to work.
>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347