IETF Logo Mail Archive

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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 11 August 2021 07:33 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7C3A07A1 for <ipv6@ietfa.amsl.com>; Wed, 11 Aug 2021 00:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkf8f8LIoI02 for <ipv6@ietfa.amsl.com>; Wed, 11 Aug 2021 00:33:15 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F243A079A for <ipv6@ietf.org>; Wed, 11 Aug 2021 00:33:14 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gl1k95z0Rz6D8mb; Wed, 11 Aug 2021 15:32:33 +0800 (CST)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 11 Aug 2021 09:33:09 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 11 Aug 2021 10:33:09 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Wed, 11 Aug 2021 10:33:09 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: Driver for SRV6 [Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?]
Thread-Topic: Driver for SRV6 [Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?]
Thread-Index: AQHXjjpJxL29aH4b8kKyZI7dZxi2JKttrwkAgAA597A=
Date: Wed, 11 Aug 2021 07:33:09 +0000
Message-ID: <0cfb93ae53bc4e6887f2452e63fa511f@huawei.com>
References: <CALZ3u+aP=v_1=w1xqfEKof7Cc6Ba3pwOYV3O=0b=NxS4hRWhiA@mail.gmail.com> <YRBdZrKV+MrrhUCG@mit.edu> <CALZ3u+aBdE3Bw3_ry+CuV4tS016c4mWewJFpr0aCbBnwj70Vzg@mail.gmail.com> <a3833e04-c123-ef52-95f9-cae80a1390e7@foobar.org> <CAMm+LwiAbiK618+kY9JTLr7_mQd-E5TKyNsGqOLrGQoLzjJo=A@mail.gmail.com> <CALZ3u+bLVUZf1fTHQvAVzOnToiPcsXEyTNt56hNAXz4=-G5-6w@mail.gmail.com> <CAHw9_i+k9x1g3bcst6rHcXpesEVwnPtV6DzsFAxi8dC6CRMZPw@mail.gmail.com> <CALx6S346mqNaE+s1DH7S7RutTpzfrC5oX1No5Jb72sTvVQjtpQ@mail.gmail.com> <CAHw9_i+ELJS_xqcEHM4raq+f=PZ5yw1ptfG3a6VypZmWTo11-A@mail.gmail.com> <CAOj+MMGzWq1OrwBQW_Mz4gB+z9wJSdQnFCkTmWiHi_Tm3ty47g@mail.gmail.com> <YRHx4c8/nOh5aXN1@mit.edu> <CABNhwV1HdSrzHDLhuSMaWY+9UaHnFYaYo75fN3+JMgMnf+Pnhw@mail.gmail.com> <6d714802-f8e2-1454-15b7-378bd8674d5f@gmail.com> <CABNhwV0-djO=wL5yJ8GZFXG75Hxmctp9vk05W6kmrj74zAfA=g@mail.gmail.com>
In-Reply-To: <CABNhwV0-djO=wL5yJ8GZFXG75Hxmctp9vk05W6kmrj74zAfA=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.193.100]
Content-Type: multipart/alternative; boundary="_000_0cfb93ae53bc4e6887f2452e63fa511fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2vvz0Ds3lfSzcSQ3rgT8CM_p-z0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2021 07:33:22 -0000

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.
Ed/
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gyan Mishra
Sent: Wednesday, August 11, 2021 10:03 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
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 <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> 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://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347

v2.23.0 | Report a Bug | By Email