Re: [bmwg] Feedback on the IPv6 and MPLS SR drafts - to consolidate or not?

Carsten Rossenhoevel <cross@eantc.de> Tue, 08 August 2023 14:39 UTC

Return-Path: <cross@eantc.de>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2A8C151075 for <bmwg@ietfa.amsl.com>; Tue, 8 Aug 2023 07:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBLGkOWoIwsi for <bmwg@ietfa.amsl.com>; Tue, 8 Aug 2023 07:39:21 -0700 (PDT)
Received: from exchange.eantc.de (exchange.eantc.de [89.27.172.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E38BC151984 for <bmwg@ietf.org>; Tue, 8 Aug 2023 07:39:20 -0700 (PDT)
Received: from Exchange.nest.eantc.de (192.168.100.7) by Exchange.nest.eantc.de (192.168.100.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.42; Tue, 8 Aug 2023 16:39:18 +0200
Received: from Exchange.nest.eantc.de ([192.168.100.7]) by Exchange.nest.eantc.de ([192.168.100.7]) with mapi id 15.02.0986.042; Tue, 8 Aug 2023 16:39:18 +0200
From: Carsten Rossenhoevel <cross@eantc.de>
To: Boris Khasanov <bhassanov@yandex-team.ru>, "sbanks@encrypted.net" <sbanks@encrypted.net>, "bmwg@ietf.org" <bmwg@ietf.org>
Thread-Topic: [bmwg] Feedback on the IPv6 and MPLS SR drafts - to consolidate or not?
Thread-Index: AQHZyWAoyMVVGn6s106VlxcLUk1oHq/gMNmAgAAzosA=
Date: Tue, 08 Aug 2023 14:39:18 +0000
Message-ID: <7b8b7db274204f5f9fd55c27b5cc81c9@eantc.de>
References: <e96d1651-f6e3-37de-bf1d-9232983dbb8e@hit.bme.hu> <46FA6F0C-D40B-4867-8840-8C46461A7661@encrypted.net> <52441691495650@mail.yandex-team.ru>
In-Reply-To: <52441691495650@mail.yandex-team.ru>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.121.2]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0304_01D9CA16.DF60E1E0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/k6eZbmCK0dbPBKsaeifWPVCuZsk>
Subject: Re: [bmwg] Feedback on the IPv6 and MPLS SR drafts - to consolidate or not?
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2023 14:39:23 -0000

Hi Boris, Eduard, All,

 

The two documents are both at version 6 right now.  A text comparison shows the following differences – see table below.

The documents naturally use “SR-MPLS” vs. “SRv6”, respectively; for example in “SR-MPLS Forwarding” vs. “SRv6 Forwarding”.  Such formal differences are not documented below.

 

The two documents are to 95 % identical.  Based on today’s status, I really do not see the point of standardizing them separately.  Could one of the authors explain how the two documents will develop and which sections will remain nearly identical in the future?

 

Best regards, Carsten 

 


 

SR-MPLS

SRv6


Section 1: Introduction

Explaining SR-MPLS / SRv6 technology background with identical structure of text


Section 2: SR Forwarding

Introducing SR-MPLS way of working

Introducing SRv6 way of working, identical text structure and covered areas


Section 3: Test Methodology

3.1 Baseline – see right side for comparison

3.2 Describing Label distribution support in SR-MPLS

3.3 Describing SR-MPLS frame sizing

3.4 Baseline – see right side for comparison

3.5 Identical

3.6 Identical

3.7 Identical

3.1 Identical, with one sentence being partially different, instead of “MPLS labels” it’s written “Functions of the last SID (called ‘behavior’ in [RFC8986])”.

3.1 Added paragraph about optional SRH testing. 

3.2 Describing locator and endpoint behaviors in SRv6; mandating comparable routing requirements

3.3 Describing SRv6 frame sizing, otherwise identical

3.4 Identical, just references to IPv4 removed and unclear suggestion for locator block sizes added.

3.5 Identical

3.6 Identical

3.7 Identical


Section 4: Reporting Format

Baseline – see right side for comparison

Substituted “MPLS Label Stack” with “SRH”

Added point “Behavior (H.Encaps, ...) and Flavor (PSP, USP, USD) used for tests.” (no additional details). 


Section 5: Benchmarking Tests

Test cases identical, with detailed descriptions slightly adapted for technology differences


5.1.1        Throughput for SR-MPLS Push

5.1.1 Throughput of a Source Node


5.1.2     Throughput for SR-MPLS NEXT

5.1.2        Throughput of a transit Segment Endpoint Node


5.1.3        Throughput for SR-MPLS CONTINUE

5.1.4        Throughput of a Segment Endpoint Node with decapsulation


5.1.4 (not provided)

5.1.4 Throughput of a Transit Node 


5.2 identical

5.2 identical, only difference “many SIDS are possible” vs. “many SIDs are OPTIONAL”


5.3 identical


5.4 identical


5.5 identical


5.6 identical


Section 6: Security Considerations

Identical


Section 7: IANA Considerations

Identical


Section 8: Acknowledgements

Identical


Section 9: References

Mostly identical, just different RFCs referenced for SR-MPLS/SRv6, and for IPv4/IPv6


Authors’ Addresses

Identical Authors

 

 

 

 

 

From: bmwg <bmwg-bounces@ietf.org> On Behalf Of Boris Khasanov
Sent: Tuesday, 8 August 2023 14:19
To: sbanks@encrypted.net; bmwg@ietf.org
Subject: Re: [bmwg] Feedback on the IPv6 and MPLS SR drafts - to consolidate or not?

 

Hi Sarah and all,

Interesting discussion indeed.

Although there is a point that both SR-MPLS and SRv6 are finally SR (RFC 8402) I doubt that there is a need to consolidate both drafts into the common one.

I just want to repeat my arguments from the IETF-117 discussion.

The development and implementation phases for SRv6 and SR-MPLS are quite different as we know. SRv6 have things which are absent in SR-MPLS (i.e. SRH)  and which are also still under hot discussions (i.e. SRH compression) vs. more mature/stable SR-MPLS.

So progress/pace  of standardization and development for both of them is different too.

If we will consolidate both drafts we lose the flexibility for adding new testing items into SRv6 part (at least make it harder) and at the same time make SR-MPLS methodology dependable from SRv6 one.

 

>From customer side, IMO, (I would like to pay your attention that SRv6 can be used  not only in carriers networks but in DC/DCI too f.e.) it is not a big difference to search and check just one Segment Routing benchmarking methodology RFC (draft) vs. two separate (SR-MPLS and SRv6)  ones depending on particular situation.  The latter looks even easier: those who need SR-MPLS will read SR-MPLS one without need to go through SRv6 part  inside or vice verse.

 

SY,

Boris

 

 

07.08.2023, 21:51, "sbanks@encrypted.net <mailto:sbanks@encrypted.net> " <sbanks@encrypted.net <mailto:sbanks@encrypted.net> >:

Good afternoon BMWG,
        At IETF 117 in San Francisco, we had a discussion around whether or not to consolidate the IPv6 and MPLS SR drafts - they’re currently separate. We, as a group, took an action to continue that conversation on the list, prior to calling for the adoption of either 1 (consolidated) or both drafts. To that end, I’d like to ask BMWG for their opinions here. Gabor has already weighed in (thank you Gabor!). What say the rest of us?

Thank you,

Sarah
BMWG Co-Chair
_______________________________________________
bmwg mailing list
bmwg@ietf.org <mailto:bmwg@ietf.org> 
https://www.ietf.org/mailman/listinfo/bmwg