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

[Vasilenko Eduard <[e-mail]>]

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]
*******************************************************************