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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 08 August 2023 15:01 UTC

Return-Path: <vasilenko.eduard@huawei.com>
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 6F080C15198C for <bmwg@ietfa.amsl.com>; Tue, 8 Aug 2023 08:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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_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 OiA3YTeCDUPM for <bmwg@ietfa.amsl.com>; Tue, 8 Aug 2023 08:01:25 -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 9EF38C151989 for <bmwg@ietf.org>; Tue, 8 Aug 2023 08:01:11 -0700 (PDT)
Received: from mscpeml100002.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RKx8T25HNz6GCvw; Tue, 8 Aug 2023 22:56:09 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 8 Aug 2023 18:01:08 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2507.027; Tue, 8 Aug 2023 18:01:07 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Carsten Rossenhoevel <cross@eantc.de>, 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: AQHZyfKz1yrWHI6y20yxTeLs9LnMt6/gRggAgAA22jA=
Date: Tue, 08 Aug 2023 15:01:07 +0000
Message-ID: <8a45b8239a874997b556c3e0abd69fce@huawei.com>
References: <e96d1651-f6e3-37de-bf1d-9232983dbb8e@hit.bme.hu> <46FA6F0C-D40B-4867-8840-8C46461A7661@encrypted.net> <52441691495650@mail.yandex-team.ru> <7b8b7db274204f5f9fd55c27b5cc81c9@eantc.de>
In-Reply-To: <7b8b7db274204f5f9fd55c27b5cc81c9@eantc.de>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.242]
Content-Type: multipart/alternative; boundary="_000_8a45b8239a874997b556c3e0abd69fcehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/GfXB0EU7tyrgfUpWdruNgdRSIsU>
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 15:01:29 -0000

They are very similar indeed because heavily based on RFC 2544. I would say 80% commonality (and 60% with RFC 2544).
Looking at that point, it is a big temptation to merge.

But I was pointing out that different people would use it at different times.
Boris has pointed out that the life cycle may be different (an update may be needed at different times). SRv6 is indeed in development yet (Compact SRH is expected).

Ed/
From: bmwg [mailto:bmwg-bounces@ietf.org] On Behalf Of Carsten Rossenhoevel
Sent: Tuesday, August 8, 2023 5:39 PM
To: Boris Khasanov <bhassanov@yandex-team.ru>; sbanks@encrypted.net; bmwg@ietf.org
Subject: Re: [bmwg] Feedback on the IPv6 and MPLS SR drafts - to consolidate or not?

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<mailto:bmwg-bounces@ietf.org>> On Behalf Of Boris Khasanov
Sent: Tuesday, 8 August 2023 14:19
To: sbanks@encrypted.net<mailto:sbanks@encrypted.net>; bmwg@ietf.org<mailto: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