IETF Logo Mail Archive

Re: [spring] SRv6 compression

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 27 July 2021 12:18 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787143A2241 for <spring@ietfa.amsl.com>; Tue, 27 Jul 2021 05:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, 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 NjYiFKzqKQsB for <spring@ietfa.amsl.com>; Tue, 27 Jul 2021 05:18:12 -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 CF4AE3A246B for <spring@ietf.org>; Tue, 27 Jul 2021 05:17:45 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GYwVS4433z6L9p4 for <spring@ietf.org>; Tue, 27 Jul 2021 20:05:52 +0800 (CST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 27 Jul 2021 14:17:41 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 27 Jul 2021 15:17:41 +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; Tue, 27 Jul 2021 15:17:41 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: SRv6 compression
Thread-Index: AQHXgrWMI74G9jgvu0u2ICteTuLwOKtWg6KCgAAfNCCAABkzQA==
Date: Tue, 27 Jul 2021 12:17:41 +0000
Message-ID: <efc36ae33b4a4d809afca2bb3e6dec29@huawei.com>
References: <AM0PR07MB44978A05B5BFCD3A0A79FD2D83E99@AM0PR07MB4497.eurprd07.prod.outlook.com> <BY3PR08MB706058AA99ADC757AA717982F7E99@BY3PR08MB7060.namprd08.prod.outlook.com> <AM8PR07MB80447B49177B2BE290BD4EC7FDE99@AM8PR07MB8044.eurprd07.prod.outlook.com>
In-Reply-To: <AM8PR07MB80447B49177B2BE290BD4EC7FDE99@AM8PR07MB8044.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.205.209]
Content-Type: multipart/alternative; boundary="_000_efc36ae33b4a4d809afca2bb3e6dec29huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/P0RkjlZy2apDuOe0v1TKIivVa38>
Subject: Re: [spring] SRv6 compression
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 12:18:18 -0000

Hi,
IMHO: Standardized solution for the same problem (more optimal data plane for SR in IPv6 infrastructure) should be one.
VPLS has lost a lot of market to L3VPN because VPLS had LDP and BGP flavors.
Many vendors have implemented only one, customers did not want vendor lock.
The primary goal of IETF is interoperability that would be broken if many solutions would be standardized.
Eduard
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sales, Bernard (Nokia - BE/Antwerp)
Sent: Tuesday, July 27, 2021 1:47 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; spring@ietf.org
Subject: Re: [spring] SRv6 compression

Hello,

Knowing the importance of compressed SID for SRv6, it is imperative for the industry to have a single standardized solution. In this context, it would be wise for the IETF to leverage on what has been previously achieved by other WGs facing a similar situation, e.g. NV03 when selecting the GENEVE solution.

Many Thanks,

-- Brd

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Tuesday, July 27, 2021 10:54 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] SRv6 compression

I agree with Wim's statement that the precedent in NVO3 *could* apply here too: pick one solution as Standard's track RFC, and once it is done, the others might be documented as Informational RFCs if they have implementations.

That would help the industry to move forward.

Thanks.
Jorge


From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>
Date: Tuesday, July 27, 2021 at 9:11 AM
To: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and analysis to compress an SRv6 SID list, I would recommend we pick 1 solution similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc) given this has to be implemented in HW..

I hope we can conclude on this asap and move forward on this topic

v2.23.0 | Report a Bug | By Email