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

From: Ron Bonica <[email-masked]>
Date: Wed, 1 Jan 2020 20:01:20 +0000

Robert,

A first attempt to answer the question follows.....

Generally speaking there is feature parity between SR-MPLS and SRv6. For example:

  *   Both can steer a packet through an SR path
  *   Both support flexalgo
  *   Both support fast reroute using TI-LFA
  *   Both can support service instructions

In terms of feature functionality, I can see only one difference between SR-MPLS and SRv6. That is, in SR-MPLS, the SR path is encoded in an MPLS label stack and the MPLS label stack is popped away at each segment endpoint. By contrast, in SRv6, the SR path is encoded in an SRH and the SRH is retained until it reaches the SR egress node. So, the SR egress node, in some case, can construct a reverse path from information contained in the SRH.

The difference between SR-MPLS and SRv6 isn't so much about feature functionality as it is about where each can be deployed. For example:

  *   SR-MPLS is applicable only in MPLS-capable networks
  *   SRv6 is applicable only in IPv6-capable networks
  *   SR-MPLS is applicable in networks where some SR paths contain a large number of segments. For example, if an SR-path contains 8 segments, it could be represented by an MPLS label stack that contains eight entries (i.e., 32-bytes, total).
  *   SRv6 is not applicable in networks where some SR paths contain a large number of segments. For example, if an SR-path contains 8 segments, it would be unreasonable to represent it with an SRH that contains 7 SIDS (i.e., 120 bytes, total).

Note......

Robert, in your previous email, you suggest SRv6 has a scaling advantage over SR-MPLS in networks where the SR domain spans any of the following:

  *   Two ISIS levels
  *   Two OSPF area
  *   Two Autonomous systems

Can you help with this section? In SR-MPLS, I am not sure that every node SID needs to be leak across boundaries. Only those of ABRs and ASBRs. Am I missing something?

                                                                            Ron

Juniper Business Use Only
From: Ron Bonica
Sent: Monday, December 30, 2019 11:35 AM
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Robert,

I just realized that you are a contributor. So, I will take that as an invitation to contribute my two cents.

Please stand by. It will take an hour or two to craft a well-considered response and it may not be ready before I shut down for the holiday.

                                                                                Happy New Year,
                                                                                   Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 30, 2019 8:41 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

I beg your pardon, but what are you trying to say?

Isn't this a WG document now and *any* WG member is fully entitled to comment on any question asked or point being raised ? Leave alone formal document contributor.

Are you saying that answers from those listed on top of the draft carries more weight ? Is this some new IETF process you are trying to define here ?

Once document transitions to WG doc status authors who own src are becoming just editors with the obligation to incorporate WG suggested changes which got approved via rough consensus as judged by chairs. Are you questioning that too ?

Thx,
R.

On Mon, Dec 30, 2019 at 1:19 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

We should probably let the authors decide if that is part of the answer to my question.

                                                                             Ron

Juniper Business Use Only

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 1 Jan 2020 22:06:55 +0100

Hi Ron,

Three observations:

A)

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.

Yes many legacy hardware will have issues to handle such processing, but
one can hope that this will be smooth evolution where new hardware will
replace incapable units. Those customers who will see a need to deploy such
functionality will likely choose proper devices.

While P routers usually will not need such capabilities edge routers may do
... really soon :).

B)

Your claim and calculations that just say for TE over 8 segments with SRv6
you will need to burn 120 bytes does not consider uSID proposal. I would
call it a bit unfair.

C)

> Only those of ABRs and ASBRs. Am I missing something?

Yes you are. Think that I want to simply remove LDP and happen to use
option C across N ASes. Today with LDP and option C I need to handle 1000s
of PEs FECs as top label in my VPN packets is remote PE. So with SR-MPLS I
need all of those 1000s of PEs to be seen flat all over my domains or
areas.

I realize that you may recommend to add SR stack to closest ABR/ASBR ...
then another label to an other ABR/ASBR while looks cool on ppt in reality
this is operationally broken idea.

When such ABR/ASBR fails I need to fall over to a backup one with local
repair at its PHP. When each such label is different this does not work any
more ... I need to go to src PE to adjust the packets.

Then you may say I may use anycast MPLS SID ... well that also looks nice
on ppt only. Hint: not all ABRs/ASBRs lead to the same end networks.

So now please imagine the burden and amount of OPEX required only to keep
MPLS transport on its life support ... for no good reason as compared with
IP transport and basic IP longest match routing.

Best,
R.

On Wed, Jan 1, 2020 at 9:01 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> A first attempt to answer the question follows…..
>
>
>
>    - Both can steer a packet through an SR path
>    - Both support flexalgo
>    - Both support fast reroute using TI-LFA
>    - Both can support service instructions
>
>
>
> In terms of feature functionality, I can see only one difference between
> SR-MPLS and SRv6. That is, in SR-MPLS, the SR path is encoded in an MPLS
> label stack and the MPLS label stack is popped away at each segment
> endpoint. By contrast, in SRv6, the SR path is encoded in an SRH and the
> SRH is retained until it reaches the SR egress node. So, the SR egress
> node, in some case, can construct a reverse path from information contained
> in the SRH.
>
>
>
> The difference between SR-MPLS and SRv6 isn’t so much about feature
> functionality as it is about where each can be deployed. For example:
>
>
>
>    - SR-MPLS is applicable only in MPLS-capable networks
>    - SRv6 is applicable only in IPv6-capable networks
>    - SR-MPLS is applicable in networks where some SR paths contain a
>    large number of segments. For example, if an SR-path contains 8 segments,
>    it could be represented by an MPLS label stack that contains eight entries
>    (i.e., 32-bytes, total).
>    - SRv6 is not applicable in networks where some SR paths contain a
>    large number of segments. For example, if an SR-path contains 8 segments,
>    it would be unreasonable to represent it with an SRH that contains 7 SIDS
>    (i.e., 120 bytes, total).
>
>
>
>
>
> Note……
>
>
>
> Robert, in your previous email, you suggest SRv6 has a scaling advantage
> over SR-MPLS in networks where the SR domain spans any of the following:
>
>
>
>    - Two ISIS levels
>    - Two OSPF area
>    - Two Autonomous systems
>
>
>
> Can you help with this section? In SR-MPLS, I am not sure that every node
> SID needs to be leak across boundaries. Only those of ABRs and ASBRs. Am I
> missing something?
>
>
>
>
>                                                                             Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Ron Bonica
> *Sent:* Monday, December 30, 2019 11:35 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* RE: [spring] draft-ietf-spring-srv6-network-programming:
> Relative advantages of SRv6
>
>
>
> Robert,
>
>
>
> Please stand by. It will take an hour or two to craft a well-considered
> response and it may not be ready before I shut down for the holiday.
>
>
>
>
> Happy New Year,
>
>
> Ron
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, December 30, 2019 8:41 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> *Subject:* Re: [spring] draft-ietf-spring-srv6-network-programming:
> Relative advantages of SRv6
>
>
>
> Ron,
>
>
>
> Isn't this a WG document now and *any* WG member is fully entitled to
> comment on any question asked or point being raised ? Leave alone formal
> document contributor.
>
>
>
> Are you saying that answers from those listed on top of the draft carries
> more weight ? Is this some new IETF process you are trying to define here ?
>
>
>
> Once document transitions to WG doc status authors who own src are
> becoming just editors with the obligation to incorporate WG suggested
> changes which got approved via rough consensus as judged by chairs. Are you
> questioning that too ?
>
>
>
> Thx,
> R.
>
>
>
> On Mon, Dec 30, 2019 at 1:19 PM Ron Bonica <[email-masked]> wrote:
>
> Robert,
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Jan 2020 11:17:08 +1100

> 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?

> While P routers usually will not need such capabilities edge routers may
> do ... really soon :).
>
> B)
>
> Then you may say I may use anycast MPLS SID .... well that also looks nice
>> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 2 Jan 2020 02:00:08 +0100

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.

> Can you elaborate on this further, or provide some links to descriptions
> of these use cases?
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 2 Jan 2020 21:47:01 +0000

Hi Robert,

Three responses:

A)

What prevents SR-MPLS from evolving along the same path as SRv6?

B)

The uSID proposal introduces its own set of deployment issues, which have been discussed in depth on this list as well as on 6man.

C)

Could you be a little more specific about the failure scenario? In your model, who advertises SR-MPLS anycast SIDs to whom?

                                                                  Happy New Year,
                                                                           Ron

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, January 1, 2020 4:07 PM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Hi Ron,

Three observations:

A)

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.

Yes many legacy hardware will have issues to handle such processing, but one can hope that this will be smooth evolution where new hardware will replace incapable units. Those customers who will see a need to deploy such functionality will likely choose proper devices.

While P routers usually will not need such capabilities edge routers may do ... really soon :).

B)

Your claim and calculations that just say for TE over 8 segments with SRv6 you will need to burn 120 bytes does not consider uSID proposal. I would call it a bit unfair.

C)

> Only those of ABRs and ASBRs. Am I missing something?

Yes you are. Think that I want to simply remove LDP and happen to use option C across N ASes. Today with LDP and option C I need to handle 1000s of PEs FECs as top label in my VPN packets is remote PE. So with SR-MPLS I need all of those 1000s of PEs to be seen flat all over my domains or areas.

I realize that you may recommend to add SR stack to closest ABR/ASBR ... then another label to an other ABR/ASBR while looks cool on ppt in reality this is operationally broken idea.

When such ABR/ASBR fails I need to fall over to a backup one with local repair at its PHP. When each such label is different this does not work any more ... I need to go to src PE to adjust the packets.

Then you may say I may use anycast MPLS SID ... well that also looks nice on ppt only. Hint: not all ABRs/ASBRs lead to the same end networks.

So now please imagine the burden and amount of OPEX required only to keep MPLS transport on its life support ... for no good reason as compared with IP transport and basic IP longest match routing.

Best,
R.

On Wed, Jan 1, 2020 at 9:01 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Note......

  *   Two ISIS levels
  *   Two OSPF area
  *   Two Autonomous systems

                                                                            Ron

To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>

Robert,

                                                                                Happy New Year,
                                                                                   Ron

Ron,

Thx,
R.

                                                                             Ron

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 Jan 2020 02:18:12 -0500

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

>> 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?
>>
>
>
>
>
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

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