Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

[Gyan Mishra <[e-mail]>]

Chiming in on SR-MPLS and SRv6 feature parity discussion.

SRv6 and SR-MPLS serve as future MPLS replacement options for operators.
The architecture of both technologies are completely different as to how
they  operate.

>From a timeline historical perspective we had atm and frame relay followed
by MPLS and now            SR-MPLS and final end state SRv6

Both SR-MPLS and SRv6 replace the outermost header for SRv6 is now an IPv6
outer header encapsulation and with SR-MPLS it’s reuses the same topmost 4
byte label in the label stack that sits between the L2 and L3 header.


SR-MPLS reused the MPLS forwarding plane and is an IPv4 LFIB label binding
forwarding plane for the node SID FEC destination.

Both SR-MPLS and SRv6 eliminate state from each node along a service chain
path and all state created on demand and maintained by the ingress source
PE origin point within the SR domain.

SRv6 uses an IPv6 forwarding plane and requires all nodes in the SRv6
domain to be SRv6 aware.  SRv6 for L3 VPN migration has a concept called
“best effort” L3 VPN where the egress PE signals the L3 VPN services SID
directly to the ingress PE thus not requiring intermediate P routers to be
SRv6 aware.

SR-MPLS reuses the MPLS data plane so requires it to be intact even when
ldp is removed from the core.
Due to MPLS forwarding plane remaining intact this does incur additional
Opex.

SRv6 eliminates the need for MPLS data plane since it used IPv6 data plane
for transport.

Both SRV6 and SR-MPLS both have the same node SID which is the egress PE
FEC destination for binding.  Both SRv6 and SR-MPLS have a prefix SID which
is the connected interfaces on each SR node that is adversed into the IGP.

How they differ vastly in how traffic steering is accomplished.

SR-MPLS utilizes the adj-sid for SR-TE ERO explicit path traffic steering.
SR-TE policy is required for label stacking and cSPF constraint based
dynamic path only has one adj-sid label where explicit path had an adj-sid
per hop.

Both SR-MPLS and SRv6 can have centralized controller based model,
distributed model or hybrid for control plane SID istantiation.

SRv6 can provide traffic steering natively by the source node without
requiring extra TE policy as with SR-MPLS requires SR-TE for dynamic cSPF
or explicit paths.

Both SR-MPLS and SRv6 provide 50ms fast reroute link and node protection
pre-programmed backup path to the merge point PQ space node via TI-LFA.


SRv6 utilizes SRv6 programming End.x for xconnext processing and End.T for
traffic for hop by hop traffic steering.

Both SRV6 and SR-MPLS require SR IGP & BGP extensions for centralized
distributed and hybrid control planes to distribute SID TLVs.

Both SR-MPLS and SRv6 have IGP topology algorithm per service chain to
provide latency or bandwidth or other constraint based cSPF algorithm.

Each SR node along the path for both SR-MPLS and SRv6 per SR IGP extensions
has the option to use strict SPF using  traffic steering policy or use
default SPF algorithm.

SR-MPLS requires Binding SID at Ingress PE with SR-TE policy.

SRv6 only requires binding SID for inter domain stitching of service chains
steered between domains.

Both SR-MPLS and SRv6 inter as options a b c ab that exist today with MPLS
can be reused with SR-MPLS.  With SRV6 the options can all be used in a
slightly modified fashion with MPLS forwarding removed since their is not a
MPLS dataplane. The vpnv4 vpnv6 peering for opt b remains the same between
ASBRs and opt C between the RRs with next-hop-unchanged.  Opt A is
identical since it’s a back to back VRF PE-CE and opt AB hybrid as well
remains the same excluding MPLS forwarding.

There are similarities as far as the BGP overlay services for customer L3
VPNs as all the features BGP AFI/SAFI vpnv4 vpnv6 IPv4 IPv6 & MVPN can be
reused over both SRv6 and SR-MPLS. Also Next Gen L2 vpn services EVPN can
be reused over SRv6 and SR-MPLS.

For operators that have been using MPLS for decades SR-MPLS is an easy
migration option.  This allows for elimination of MPLS ldp state and as
Robert mentioned Opex savings.

I think the eventual direction of all operators will be to migrate to
SR-MPLS and then down the road migrate to SRv6 as a separate phase once the
core is dual stacked.

One way to think of the evolution is eventually as the operators migrate
their core to support dual stack since ldp supports both IPv4 and IPv6 ;
that would be a stepping stone to prep to migrate from SR-MPLS to SRV6.

For Green and Brown field deployments SRv6 is an attractive option for
operators.

One major use case and driver for SRv6 is that since it uses the IPv6
data-plane and for best effort L3 vpn ONLY  the PEs are required to be SRV6
aware.  This has tremendous benefit as the SRV6 can be used as a ubiquitous
use case Swiss Army knife over the internet between carriers as well as
within enterprises independent of the traditional MPLS only replacement.


Happy New Year!!

Gyan

On Wed, Jan 1, 2020 at 8:00 PM Robert Raszuk <[e-mail]> wrote:

> Hi Mark,
>
> I am the last one who would recommend you more state and more intelligence
> or even new mapping into the network. Networks should just be dumb and
> should be just able to forward IPv4 and IPv6 with proper QoS treatment.
>
> All "extra functionality" is about the edges and service processing nodes.
> Hint: take a look at Terastream architecture.
>
> /* Disclaimer: Yes there is overlap of SRv6 in that respect with NSH - but
> allow me not to get into this battle field here. I think both will continue
> for a while fwd. */
>
> For use case - There is a lot of them which I can see very useful. And
> since some of them can be commercial value naturally are not to be
> discussed in public. But I will illustrate just one ... Imagine today a
> network connecting to some services it offers customers. Those can be IPv4
> RFC1918 or IPv6 customers. Well if you do not want to turn each IPv4
> customer into separate VPN you need to NAT (some of them may be coming with
> the same address space to you). NAT has its own set of issues .. so one
> alternative would be to encapsulate all of them into SRv6 and add into SRH
> sufficient info about customer ID, function required, etc ... such that
> your service can be accomplished. I can not see how to do that with
> SR-MPLS.
>
> I think your statement about fit into IPv6 architecture is coming from a
> completely different perspective. Pls keep in mind that I am using IPv6 as
> an encapsulation so my edge is the actual v6 host just taking a v6 payload.
> Not also that those fancy service processing mentioned above Terastream
> dpes are also all (at least originally) done by x86 IPv6 service nodes. In
> IPv6 terminology those are real v6 hosts.
>
> Ron started this thread trying to prove that SRv6 services can all be done
> with SR-MPLS so why do we need SRv6 in the first place. While I am sure
> bashing MPLS transport would be fun let's move it to some other forum and
> form.
>
> For networks already running MPLS transport and are really happy with it
> SR-MPLS can provide few real benefits - one getting rid of LDP. By all
> means great move. For those who in addition to some VPN support would also
> like to enable some SR-MPLS for TE .. again very simple and incremental
> change. Those folks should not hesitate and go for it.
>
> But those who like to enable more services on their networks, those who
> have extra spare capacity to accommodate SRv6 encap overhead, and those who
> can think outside of their vendor manual - will likely see a benefit to
> consider SRv6.
>
> Btw I do think that EH addition to IPv4 is a good thing and SRv4 should be
> defined and also progressed in SPRING.
>
> Yes I just barely scratched the surface of the questions you posted. But
> again I would like to highlight that the main decision of choice of SR-MPLS
> vs SRv6 or maybe even SRv4 (one day) would be mainly dependent on given
> network's transport protocol and service needs.
>
> Best regards,
> Robert.
>
>
>
>> I am afraid feature or capability parity between SRv6 and SR-MPLS is far
>>> from equal. Sure if you consider just TE or VPN applications one could draw
>>> such a conclusion. However where I see SRv6 evolving is actually into very
>>> flexible operator defined embedded functions with dynamic arguments.
>>>
>>
>> Can you elaborate on this further, or provide some links to descriptions
>> of these use cases?
>>
>> This sounds a bit like an "intelligent network" vision.
>>
>> That doesn't fit IPv6's architecture, prohibits encryption, and makes
>> scaling harder. There's a reason that the smart and complex functions are
>> done in hosts at the edge, and the network does dumb forwarding, and that
>> is it's much easier to scale.
>>
>> Does it also mean that SR-MPLS shouldn't be used, or at least its
>> possibly severe SR limitations should be called out in SR-MPLS specs?
>>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant