Re: Driver for SRV6 [Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?]

[Gyan Mishra <[e-mail]>]

Hi Eduard & Stefano

You can do ECMP with multiple tunnels as each tunnel maps to a different
next hop with either static lsp strict path ERO and with loose path ERO,
and you can as well with dynamic LSP cSPF constraint based path you can as
well.  The key here is multiple tunnels are required for ECMP at least two
for 2 different paths 1-1 mapping between TE tunnel and path.

With SR both SR-MPLS and SRv6 with a single tunnel you can do ECMP.

There are many many differences between SR and RSVP-TE but I would say the
three  biggest game changers and the push for operators towards SR today
are as follows without getting too deep in the weeds:


1. Elimination of control plane state within the network / no LDP, RSVP-TE,
for E2E seamless MPLS BGP-LU can remain or BGP-LU can be removed as well.
Control plane label distribution is now pushed to SR IGP extension for
global prefix sid / node sid and local adjacency sid, as well as  Anycast
sid if used.

2. Per VRF/VPN mapping to traffic engineered SR-TE path as well as per
application micro and macro flow mapping to a SR-TE path.  With RSVP-TE the
mapping was done with next hop rewrite requiring  additional loopback per
VRF and static route per VRF to TE tunnel mapping - so does not scale well.

3.  Inter-as options a,b,c, ab do not scale as well and have their issues
related to security for option b and c and ab.  SR using SR-TE eliminates
the need for use of inter-as option as now SR-TE binding sid can be
utilized on the ASBR boundary for E2E SR-TE stitching. SR can still use
inter-as options that exist today and it’s up to the operators which
direction based on their design to use.

There is still a lot of development work being done with SR especially with
new SID types as well as for multicast which has gone a long way.

The one issue that has existed with SRv6 is MSD-Maximum SID depth and that
was reported update on Spring with progress made at IETF 111.

Overall with MSD the issues can be controlled with both SR-MPLS and SRv6
with centralized PCE controller based solution which is the recommend
deployment method.

Thanks

Gyan

On Wed, Aug 11, 2021 at 10:17 AM Vasilenko Eduard <
[e-mail]> wrote:

> Hi Stefano,
> It was possible in 2008 when I developed one really big network.
> But I am not sure was it a proprietary feature of the vendor or was it a
> standard. Looking that network has been upgraded later by Huawei - probably
> standard.
> It was a principal feature to split traffic between many tunnels (15)
> between the same <source, destination> PEs to have global load equalization
> on all links.
> Of course, hash was calculating only 5-tuple at that time, but hash could
> easily digest more fields now.
> Eduard
> -----Original Message-----
> From: Stefano Salsano [mailto:[e-mail]]
> Sent: Wednesday, August 11, 2021 1:53 PM
> To: Vasilenko Eduard <[e-mail]>; Gyan Mishra <
> [e-mail]>; Brian E Carpenter <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: Driver for SRV6 [Re: IPv6 Anycast has been killed by LINUX
> patch in 2016 - who cares?]
>
> Il 2021-08-11 09:33, Vasilenko Eduard ha scritto:
> > Then it may be generalized: any TE (including RSVP-TE) would benefit
> > from additional big and random seed (like “flow label”) to better
> > distribute the load between TEs.
> >
> > And then it is not a driver from one form of TE to another.
>
> Hi Ed,
>
> in my understanding, if you are using RSVP-TE to setup traffic engineered
> MPLS Label Switched Paths (aka hop-by-hop TE paths), then you cannot
> exploit L3 ECMP as you can easily do with SRv6 based TE
>
> so there are differences between one form of TE and another
>
> (but maybe I am not aware of more complex RSPV-TE solutions...)
>
> ciao
> Stefano
>
> >
> > Ed/
> >
> > *From:*ipv6 [mailto:[e-mail]] *On Behalf Of *Gyan Mishra
> > *Sent:* Wednesday, August 11, 2021 10:03 AM
> > *To:* Brian E Carpenter <[e-mail]>
> > *Cc:* 6man WG <[e-mail]>
> > *Subject:* Re: Driver for SRV6 [Re: IPv6 Anycast has been killed by
> > LINUX patch in 2016 - who cares?]
> >
> > Hi Brian
> >
> > SR is about path selection and steering, however an enhancement over
> > RSVP-TE is the ECMP capability at any node along the path.  As SR
> > utilizes ordered list of topological segments to build a steered path
> > selected via SR-TE policy either centralized controller based or
> > hybrid model, the path may consist of a prefix sid global label used
> > for loose hops that can take advantage of hop by hop ECMP steering or
> > an adjacency sid strict steering which can be ECMP with parallel paths
> > as well or Anycast sid for ECMP steering.  So the path can be a strict
> > hop by hop path with no ECMP which could be an ordered list of
> > adjacency SIDs with no parallel paths or it could be a ordered list of
> > prefix sid loose ECMP hops.
> >
> > So in the case of  a prefix SID or Anycast SID with loose hops, ECMP
> > forwarding path being instantiated, SRv6 can take advantage of RFC
> > 6437 flow label 50/50 uniform load balancing.
> >
> > Kind Regards
> >
> > Gyan
> >
> > On Tue, Aug 10, 2021 at 6:51 PM Brian E Carpenter
> > <[e-mail] <mailto:[e-mail]>>
> wrote:
> >
> >     Gyan,
> >
> >     (Cc's trimmed)
> >
> >     Can you explain this assertion please:
> >
> >      > IPv6 flow label RFC 6437 stateless uniform 50/50 load balancing
> >     is one business driver for operators to migrate to SRv6.
> >
> >     I thought SRV6 was about path selection for specific services, which
> >     is very different from any form of flow-based load balancing.
> >
> >     Regards
> >         Brian
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions Architect /
> >
> > /Email [e-mail] <mailto:[e-mail]>/
> >
> > /M 301 502-1347/
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
> --
> *******************************************************************
> Stefano Salsano
> Professore Associato
> Dipartimento Ingegneria Elettronica
> Universita' di Roma Tor Vergata
> Viale Politecnico, 1 - 00133 Roma - ITALY
>
> http://netgroup.uniroma2.it/Stefano_Salsano/
>
> E-mail  : [e-mail]
> Cell.   : [phone]
> Office  : (Tel.) [phone] (Fax.) [phone]
> *******************************************************************
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*