Re: [spring] SRv6 compression

Ville Hallivuori <vph@iki.fi> Tue, 03 August 2021 13:50 UTC

Return-Path: <vph@iki.fi>
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 63BB93A2496 for <spring@ietfa.amsl.com>; Tue, 3 Aug 2021 06:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 ic3gy9SXMTzR for <spring@ietfa.amsl.com>; Tue, 3 Aug 2021 06:50:23 -0700 (PDT)
Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1C83A2494 for <spring@ietf.org>; Tue, 3 Aug 2021 06:50:23 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 76F091AC10D6 for <spring@ietf.org>; Tue, 3 Aug 2021 09:50:19 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Tue, 03 Aug 2021 09:50:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jJbhqh yl5Aw7f2mKGelBAq/oY3DnPZD5BpSFsOLBJKg=; b=cM7OacpV7tP2q8xFxrp41t ztq2R56s5WpUUkySnopjK8pTykz3273ModN9YmazIYvaZJpxOOaezeoRvtavOSEO iVKLYJ7ykBRjyrkWHnr5LGghgVzdyhb/mGIyMF7rl3g34DSExHXIasDl7Yf2vqat OLeaHc7gi6mLqJbTE87qvKTrDnIjvQ9DKLhNC3LKh9hLOGTUZGirEgnjtNNrX6Kb UhVY8UdiUJCiHBiNTrH4Yqt0ckkScZo/jAS0tQQs5Saw8qUWlvJMr5xaczlG1PIU 5dBWdz6RLy52fRtFPmIt+OZuh66JkJYHztn4V67RfceMs8Gfgg4kK+GAJqxCWV9g ==
X-ME-Sender: <xms:mkkJYRDBxRp5empFRUnmX_xOjI60t-KWpW9cha9_OHmvfVzsO1HHlA> <xme:mkkJYfivXTRG-qsx271k1RD9EsFGmrUOaG5FaK4kImhtLMBt1c91n-xzxzcRQFJwe 4AUAL3pyqLLbrw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieeggdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdggihhllhgvucfjrghllhhivhhuohhrihdfuceovhhphhes ihhkihdrfhhiqeenucggtffrrghtthgvrhhnpedtgefgteegjeehieeigfettddtvdfhke evkeejueeuieehfeelteeitdetledtfeenucffohhmrghinhepihgvthhfrdhorhhgpdhv vghrihiiohhnrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepvhhphhesihhkihdrfhhi
X-ME-Proxy: <xmx:mkkJYckU_be5KI-1uCB0KA8BAhBVy1yCF4NDUzJiLoy175zhyyCNKw> <xmx:mkkJYbzbnXP3zjwT8_1T7fh_yX3QUXzTxZRDU7au_q-JjnuZkBXS1g> <xmx:mkkJYWQ7NeM7kFGKQXAeVg3vxEmYGXVpQiBfNHCAmjja7jgd1tWZJw> <xmx:m0kJYdc9B6rnHwiHyyi5EUBlgBsryfHHTDl8VzKDmLeYyfoMOU5OBV_0Z-U>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4EB6F4E00B3; Tue, 3 Aug 2021 09:50:18 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-548-g3a0b1fef7b-fm-20210802.001-g3a0b1fef
Mime-Version: 1.0
Message-Id: <b30b68d6-16e3-4d60-9ae2-317210c43ec3@www.fastmail.com>
In-Reply-To: <861DFD97-44DD-439F-A367-04E0653E4847@bell.ca>
References: <AM0PR07MB44978A05B5BFCD3A0A79FD2D83E99@AM0PR07MB4497.eurprd07.prod.outlook.com> <BY3PR08MB706058AA99ADC757AA717982F7E99@BY3PR08MB7060.namprd08.prod.outlook.com> <DM6PR08MB6027A0F55D0146ECDA8C8923E4E99@DM6PR08MB6027.namprd08.prod.outlook.com> <CABNhwV0DYH8xO_9T2HiKj_6rc3gh6c2PWFdP5XPjDma_yktPCg@mail.gmail.com> <CAG=3OHePBc6XebbgHdEkj9Si54B3CPFrV1sePuMbr6t9dciW8w@mail.gmail.com> <861DFD97-44DD-439F-A367-04E0653E4847@bell.ca>
Date: Tue, 03 Aug 2021 16:48:59 +0300
From: "Ville Hallivuori" <vph@iki.fi>
To: spring@ietf.org
Content-Type: multipart/alternative; boundary=e392eea3ab5b4940be21c32c2680173c
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/blISsT6SdnozEMf0_YcqzdDMhes>
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, 03 Aug 2021 13:50:29 -0000

Hello,

I would strongly prefer a single solution. While I am not particular on which of the solutions is selected, DT does make compelling argument for CSID.

I work for a vendor and would hate to have to implement multiple different header compression schemes. Especially if it comes out of limited microcode resources. While IETF has a long history of having two competing solutions (LDP/RSVP-TE, OSPF/ISIS), having competing options in forwarding plane is even less desirable than it is on the control plane.

Thanks for the DT for their excellent work.

BR,
Ville Hallivuori

On Sat, 31 Jul 2021, at 00:06, Voyer, Daniel wrote:
> I agree as well – DT spent a year to come up with an analysis and now have a conclusion. In my view, we are ready to move with a single standard solution. This will unlock the vendors community to adopt an SRv6 compression standard and allow operators to move forward.
>  
> At the end of the analysis document, CSID seems to be the clear winner.
>  
> Thanks
> dan
>  
> *From: *spring <spring-bounces@ietf.org> on behalf of Eduard Metz <etmetz@gmail.com>
> *Date: *Friday, July 30, 2021 at 7:24 AM
> *To: *Gyan Mishra <hayabusagsm@gmail.com>
> *Cc: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>om>, "Aissaoui, Mustapha (Nokia - CA/Ottawa)" <mustapha.aissaoui@nokia.com>om>, "spring@ietf.org" <spring@ietf.org>rg>, Wim Henderickx <wim.henderickx@nokia.com>
> *Subject: *[EXT]Re: [spring] SRv6 compression
>  
> Agree.
> The DT has done a great job in the analysis. 
>  
> Moving forward with a single, standards track solution is preferred/required for interoperable SRv6 implementations.
>  
> cheers,
>   Eduard
>  
>  
> On Tue, Jul 27, 2021 at 6:09 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>  
>> For all operators around the world looking at deployment of SRv6 compression and being in a  holding pattern waiting for SRv6 compression to be standardized by the IETF.  
>>  
>> Given the ubiquitous importance of SRV6 compression and MSD issues with long strict SR-TE explicit route object,  it is critical for interoperability for all steering use cases that exist today: enterprise, internet, private, access network - 5G wireless xHaul, mobile core, wireline, MBB, FBB. 
>>  
>> We as a WG need a single standardized solution for SRv6 compression for interoperability to work and all vendors marching to the same sheet of music.  
>>  
>> I agree that the NVO3 - GENEVE is a solid precedence path forward to take and for Spring WG to come to consensus and standardize on one solution and progress the other solutions as informational if implementations already exist.
>>  
>> Kind Regards 
>>  
>> Gyan 
>> Verizon Inc
>>  
>> On Tue, Jul 27, 2021 at 10:12 AM Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com> wrote:
>>> Same here. We want a single standard method of SID compression to allow the WG to focus on finalizing it and get vendors hardware implementations updated.
>>>  
>>> Regards,
>>> Mustapha.
>>>  
>>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Rabadan, Jorge (Nokia - US/Mountain View)
>>> *Sent:* Tuesday, July 27, 2021 4:54 AM
>>> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>om>; 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> on behalf of Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>
>>> *Date: *Tuesday, July 27, 2021 at 9:11 AM
>>> *To: *spring@ietf.org <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 
>>>  
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>> 
>> --
 <http://www.verizon.com/>
>> 
>> *Gyan Mishra*
>> 
>> *Network Solutions Architect *
>> 
>> *Email gyan.s.mishra@verizon.com*
>> 
>> *M 301 502-1347*
>> 
>>  
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>