[bess] Revision of draft-ietf-bess-bgp-sdwan-usage and response to Gunter's comments

Linda Dunbar <linda.dunbar@futurewei.com> Mon, 09 December 2024 20:40 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22329C151540 for <bess@ietfa.amsl.com>; Mon, 9 Dec 2024 12:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level:
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 yE7_0lPYhSRd for <bess@ietfa.amsl.com>; Mon, 9 Dec 2024 12:40:17 -0800 (PST)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2116.outbound.protection.outlook.com [40.107.223.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6EFC14F736 for <bess@ietf.org>; Mon, 9 Dec 2024 12:40:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=txZufMoWYXAqCKpXe3imbFqpRuX03n/RUGimhBarcX8R7yRpIfbIweyQebWy+lE87rkYpoCbdXmvgq5lYx0EHJUpHzBE8lo1Su+k20v2ZwYrYjkvZKgxhHNmWvs3Iex72XaMXFI0DNGti95p3g/1p7qX6dC2w6mjJQnd70dAVkbM1D48dRPcY3s4fY12QdirjLJKO9Vv1PrCtupD3lBHEywQkcU023C1jJI4lmnxlp8bQPnMAQtGwIxjMn/Xu+xiWm3cGaHPZiXP24lJcZWZ/3rVDYbrruJjr+KYT79Fsm7dnqNa+FztvOxoGP943RNtg6TTOoAJlGjmuq3cR6TQCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hGPlfZBc4/NlzN4PrYPK/EuL5R/7KTQ0IBWrpOnxkAo=; b=vAd+xsAiuU0T9m4VONUFb0ysYpOzqrzamCvFx3d+8nKXgnYiGyKznJLCvIFGfcaT1sZNybp8+sBuyWxKxAgRsPhX3jiLigTLtSste4wHOvLA0Lb+qYrwMogzV93cgLT5B1s5YCdR6D+meURdosKlwl2AFv/e0YyXFGN2+RH3eZadxdC4HOJ8MG21D9ZrMrUSaHL7J7pcDdAQ/fyY63SPm0Ls/6mo3A9zCRlH7koAsxnk4dH4XTW3DfR1bBLzLlDmWTlK86++k4mz6jURoqMKegI0+5oSHeyDAmMW5GIKGevnOxiaVYW7/f+YkFoTD0zjH5fEk3u/JZEhgkuQ4M5UPg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hGPlfZBc4/NlzN4PrYPK/EuL5R/7KTQ0IBWrpOnxkAo=; b=fohSu1R6CYFmoPik/YOKS8YFoiyBT+25ynNFcqRNB6+VOLQG2l/JnxoGvlixPGgmkCwUV6yBDBMf7cS0eFZ5Kc/pXrhsvbX1j/wOw3XLYPsC5bq/4mc0JTn4TDH0puTO06D596htlVf37atbAANdFX5UbZyqB6Lg5/szn5gQvtk=
Received: from CO1PR13MB4920.namprd13.prod.outlook.com (2603:10b6:303:f7::17) by DS7PR13MB4637.namprd13.prod.outlook.com (2603:10b6:5:3a9::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8230.18; Mon, 9 Dec 2024 20:40:07 +0000
Received: from CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::4021:909f:bb6c:72a6]) by CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::4021:909f:bb6c:72a6%7]) with mapi id 15.20.8230.010; Mon, 9 Dec 2024 20:40:06 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Revision of draft-ietf-bess-bgp-sdwan-usage and response to Gunter's comments
Thread-Index: AQHbSnqInNQhFOVTfESfNOaTMeWhTA==
Date: Mon, 09 Dec 2024 20:40:06 +0000
Message-ID: <CO1PR13MB49208E90FBBE1B1250A9F180853C2@CO1PR13MB4920.namprd13.prod.outlook.com>
References: <AS1PR07MB85890808B717954BCDEC9F18E00E2@AS1PR07MB8589.eurprd07.prod.outlook.com> <CO1PR13MB4920115021EC97142F59CB81851B2@CO1PR13MB4920.namprd13.prod.outlook.com> <CO1PR13MB49201B80B3E70F34597C1464851A2@CO1PR13MB4920.namprd13.prod.outlook.com> <AS1PR07MB858970FA0BE140C0D8D937B5E0192@AS1PR07MB8589.eurprd07.prod.outlook.com> <CO1PR13MB49207EBA9B06988C7175296785322@CO1PR13MB4920.namprd13.prod.outlook.com>
In-Reply-To: <CO1PR13MB49207EBA9B06988C7175296785322@CO1PR13MB4920.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR13MB4920:EE_|DS7PR13MB4637:EE_
x-ms-office365-filtering-correlation-id: a2268649-46d3-4fdd-7a61-08dd1891aa95
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|8096899003|38070700018;
x-microsoft-antispam-message-info: dimbsKR46iQEUkqz1MQ+74n/qrwffzSzul9L81FcKXznhlobd2u4besId/YLAH7nQ9QjE6juW00DsReyGf0TMUjUcUjm+Nio9fTIZrQ1PixkBDjivGbyb5Zrls4/T/l1Hgx0HWq9MRL0gJtOg82Fx8o/3tnA1cFvW0zCnjwR1ehRVaPHpXEVRzqyYnhV3rfxMzt7XMCu6WJQIAMXFWdl3tfYOAkRmp8WLtBjh2Q83TUve71R3D1GpeR+yOzdAzrKDu5uX2nIxKhtLLrWNoOMiw2fUyOAgkTG52mASHVoEzJBD/93GRP+VlZxUYapWWNXwWHnB9WITCw2iHADASIY2RFmwE6OPnIRepHQuEvVNqvotx/eYpMDxTvLjRTCLXqIUhCCsmIn2cqkMJD99X1Rl2EzQlOKvXaEyYilEg1T8U7gn63T2kLBQ6AuSEEPi6yA9SV4XzZKhtf5I+rn9I+GeRhqNeEdK5M8DlneWUya+54Ss6bd4PSTZlzqk8e73Ja0CuXF+ldy1pIECuEx2q9DiFvzyR4eu7EGLUvyyihFDqN8xnrcvK4hRHmgjsQnBi3Hn92vrhECUx7aGI1D6fQpaLj1fnjHObMLXeGX40uLVDIa3zk6gmRH/m/emLU70k9SbU2qIIiDqD5VQ1K2zaSmKNvJvnw/lgqaR3OCSDfk1zysiYRwEXKc04mRik9VowFJ23t5wn/58SHajgn4wkXTb4otMhTGcAy40JnUHFKQ7xnRnuzacEIq2XOCSH1qKJh8L4k/dfR/XyuUIzJrGqpxDTn1rWwTkcRQMfz7+mbCns9mlTEktLUt/o9ZSWCi8pkDVhrrECYWrCncwtQQSTVFGrqCsf0unae7xmC8w8Ak3Ug5fPCroEY+oD1v4ygwGezzZ7WpYC0Q0q4efqQzbXmz/8RZpvfkBHuP3nqBVP0p9GGe2VENg9OzzALqpg8bUzkpmOqvdtfx92j3yX1Aidqy9eJ0TAwly1IBsUGGEkhHK7POTqQu4ic0Cq5yKq1ZAKnwkzJLDyMRsogkfxuGxJ62yn+z1O2ea3tzuohVO8x1LwBVOaMqaI5+7zGHM6XchcQN3Xm86D+k+ud9q6smoafIB65LQ4M5bVo8sTAmL9/zgMKE/zBE/6W/EhSrbgoNwa/JTk07dEr9oJKOYxlvPAy2/2KutPbTaJjroKCA8+dIZZLfHU/2ue+/3kxpNM9LcsTJOE5mF+48BVMr/3k1vhAJfWRN4rsfZJzee8rygwiurc8xyQglS8YWW3UX+vfWDHoK36iR0oDn0itfmqlZDOxp6v3Eycqei/nvEfbclTTxh/f8yKmnIzsiMocwC45MoHBaAS4jOnqD/MnhPowOmOPQ0o8HPVxDKiuSrkmek59qUM0=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR13MB4920.namprd13.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(8096899003)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: tDvPjU+U6y4LORdsxv8ZvTb3Ad7PXkLDQ9VqDI2LWLSgNP72tAb1FKCDa0LRfDD1bn9qO03R9fHAhfbYqjEmVx76K0d2RVH7lolO09G9fDVoXKkl4UZa73/879bxtBeANT+MMvp/UTgYG5SD11KV7dohUqdmw/buHyPSerjgYE2N/plC/pytNRaafP9Q6LK8Oe7HDMMCOdIx/XwWFEomccQ/ZahxrqISkcLn+x51YGvdfkoxqUTRDMhAuKRKYOXbYrbN2ZvRcm5Wde5qqptROSh5oC/XQ/bKzKCq5P3tll1dr48g5Y8S8byFDiV2MojEa5hdL4o5RRESYi87buRnT/9sDblBwZ88AyQL80tLQj0KrxXjvzmmWeAsEdTNk2Bypjm6Ba/eidx1sykkK5xOyBJyhf9mgWif302Wpe2eCd5gQav5H23KQBm2so1zIlTN5QyTs2a4KE5De7gDz92lP2Kbri5X02QHuYCzIKXNvEPrOQ2lHK/9f5HijrJmXE6iG+ywKu0Gnoacuz9iSQogj4JYiZnMdN5ZGuVIbLXUqbqFuJ4hvLyuUzEjdpNqQwwvEUl05djRYeWnIBEQpc1SXUc1gwihOSiGsFtpKegM65sDL7G3I2yQdPh+q8u971casPPIH66NjPydW3t4CTV5k13zqHsHkDrE0yfq/oSF4M6h5o62zfKpCNJoNTS5dJg86CPGsQ0lSnpdlPEzvmJ7ufX79bW027Gj71fcFiM4r3JjHPpMbUQpsKarPEAYfSRw8Ta1+Rxh2C96vmKJUVUkhFktxwzfsBe202R6kxDZ29KNOK7dm4oGarwrQNAt/XL5HPE4vOy7IQL9gGnvObygIkN8CKckjfTl0m/hKdUGWYhGFmfBcqK30mQQoLPTQGe5Y1T8kDjXCMxdie+SHNvumRvVSVVVXC1rJKNTyR10fFEMcV7+f5WQIgtnEr/6h8HTYujEMWhrFZgxYJbRUj3lxRKAx+j1g/sPPvKXlsjolzcKq5nurzZjXgMr8VlI/HPedi+WN5kdxShKDTu/tref095wo1E1ktagxPdpH/Q2QyR9fXF9+W8sD+w2XS+dJVQLEjGDGw3qlDkKul2rrHzcH+qEzAc2oAz8CoVxRfTZCAkbn3kpKEKJ5UP5KuJb3rUzmjFnJYgXblBi4O5m2/6ZrGCAVG+jxfUUMpbVLTRr0sJN6HK+dxZ8ncWxbQDTdG5BxKawq7P69Lc/2MJcfaQVt4BOWbLx7wjF+xwImluMhyJ2sEwf4xb577hYKiqVSsR6kLxvLZBe+zPVxp8tY51W7GiVcOEe47ZJ0c691VOudPgUWQA+dlAuIj43wX7vsq7fWsbwUU8nYdwXOdqb9Spj6fpKFCfrRcjUIaherXKNCLfVm92qcWqv3lTu4UPWpBVi7VfBanZD52AGkuozzoBdoeZB84cWpQQxsL03M3cZfHOrJUvhVH84U/M1MLkRQJoVSb/XzzF3MB35MA6WiZZ+/0QshP0b5qRgQxLw8XYyDoBg64TzxtP6XIIV2f7Dhfr8yfMFhU6ogrL6a96weCO5BtjX6sEqODSCQ0HupbSAaY0UcfCCy7nf4TLD9ySUDxoJ
Content-Type: multipart/alternative; boundary="_000_CO1PR13MB49208E90FBBE1B1250A9F180853C2CO1PR13MB4920namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB4920.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2268649-46d3-4fdd-7a61-08dd1891aa95
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2024 20:40:06.7361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HUEAPKL7QBcEUvObrB8MqMPVvlOd5CinVVdSsi4IJc+MrN7coXKVdrGm83n2ZVDJMbMBYIMilmo5yrxlBH3Yww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR13MB4637
Message-ID-Hash: 7KHXM3NKQF63I3ZXKK3X2GFG7KQ66TVM
X-Message-ID-Hash: 7KHXM3NKQF63I3ZXKK3X2GFG7KQ66TVM
X-MailFrom: linda.dunbar@futurewei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Revision of draft-ietf-bess-bgp-sdwan-usage and response to Gunter's comments
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/4Aqe7EqBIODDwbPsQF0324OKBlE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Gunter,

We have revised the  draft-ietf-bess-bgp-sdwan-usage  to address your comments & feedback:   https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/
Initially,  we intended to merge the content from the draft-ietf-bess-bgp-sdwan-usage  to the  https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/ . However, based on the early Directorate reviews of draft-ietf-idr-sdwan-edge-discovery, it was recommended to maintain separate documents for the use cases and requirements, as well as an overview of the pros and cons of using BGP to control SD-WAN. This document is particularly valuable given the limited prior work on SD-WAN within the IETF.

Here are the responses to your comments:

Comment 1: WGLC and Document Purpose
"The draft has undergone substantial updates, and the technologies it discusses have evolved substantially during this process. As a first step, it would be prudent to establish consensus on the proposed changes through a new Working Group Last Call (WGLC). This will ensure that the document is thoroughly reviewed and represents the rough consensus and that it has the full support of the Working Group as the BESS solution for the specified problem space."

Response: We agree that conducting a new WGLC is an important step to validate the substantial updates and ensure rough consensus. The updated draft incorporates feedback received and reflects the evolution of SD-WAN technologies. The proposed use of BGP as the control plane and IPsec as the data plane aligns with the stated objectives and demonstrates practical applicability for managing SD-WAN overlay networks. The WGLC will provide an opportunity to confirm the Working Group's support for this solution as the BESS-endorsed approach.
________________________________________
Comment 2: Ambiguous Purpose
"Another question to raise during WGLC is about the recurring issue noted during IESG review about the ambiguous purpose of the document. The draft broadly suggests the possibility of utilizing BGP for the control plane and IPsec for the data plane. The necessity of an RFC to establish this practice is questionable."

Response: The purpose of the document is to define a standardized approach to using BGP for the control plane in SD-WAN overlay networks, enabling scalability, flexibility, and interoperability. While the BGP for control and IPsec for data plane is not new, this document formalizes their application in SD-WAN scenarios, addressing challenges such as constrained propagation, peer authentication, and hybrid underlay integration. This standardization ensures consistent implementation and reduces the risk of fragmentation in deployments.
________________________________________
Comment 3: Clarification on "Revising" RFCs
"The following is stated: 'This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012).' It is unclear to me what 'revising' means in the context of RFCs."

Response: The use of "revising" refers to updating the mechanisms described in the obsoleted RFC for IPsec L3VPN to align with the newer capabilities of Tunnel Encapsulation as defined in RFC9012. This draft builds upon prior work by adapting it to current standards and practices, ensuring it remains relevant to modern SD-WAN deployments.

________________________________________
Comment 4: Scope of BESS WG
"The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane."


Response: The draft focuses on enabling L3 VPN services over hybrid underlay paths, aligning with the BESS charter, which states:
1.            "The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP."
2.            "Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience."
By proposing mechanisms for managing SD-WAN overlays using BGP, the draft remains within the scope of defining and extending network services based on BGP.
________________________________________
Comment 5: Ambiguity of the Charter Scope
"If the draft discusses topics beyond this specified list, they should be considered outside the scope of the BESS Working Group. While there may be topics closely related to those on the list, as you've identified, addressing these would require a rechartering of the BESS Working Group."

Response: The draft is firmly within the current scope of the BESS Working Group, as it does not introduce new services outside the charter but optimizes existing BGP-based solutions for SD-WAN overlays. Any further expansion beyond this focus would indeed necessitate rechartering, but this draft remains aligned with the Working Group's core competencies.
________________________________________
Proposed Actions
1.            Conduct a new Working Group Last Call (WGLC) to validate updates and secure consensus.
2.            Clarify the document's purpose and its alignment with the BESS charter during the WGLC.
3.            Ensure explicit wording in the draft to reflect its intent, emphasizing standardization and practical application in SD-WAN scenarios.

These updates have been integrated into the revision.

Thank you,

Linda
From: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
Sent: Wednesday, May 1, 2024 9:39 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: draft-ietf-bess-bgp-sdwan-usage@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-usage@ietf.org>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; 'rtg-ads@ietf.org' <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: RE: Can we have a call to chat if the revision resolved AD's DISCUSS comments? Re: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time

Hi Linda,

Thank you for the update. The draft has undergone substantial updates, and the technologies it discusses
has evolved substancial during this process. As a first step, it would be prudent to establish consensus
on the proposed changes through a new Working Group Last Call (WGLC). This will ensure that the document
is thoroughly reviewed and represents the rough consensus, and that it has the full support of the Working
Group as the BESS solution for the specified problem space. Another question to raise during WGLC is about
the recurring issue noted during IESG review about the ambiguous purpose of the document. The draft-ietf-bess-bgp-sdwan-usage
broadly suggests the possibility of utilizing BGP for the control plane and IPSec for the data plane. The necessity
of an RFC to establish this practice is questionable.

The following is stated: "This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012)"
It is unclear to me what "revising" means in the context of RFCs?

RFCs can undergo various status changes as they evolve or become outdated. Here are the main actions that can happen with an RFC:

  *   Updated: An RFC can be updated by a subsequent RFC. This means that new information or modifications have been added to the original document to reflect current technology or standards.
  *   Obsoleted: An RFC becomes obsoleted when a newer RFC replaces it. The new RFC provides either revised information or entirely new standards that supersede those in the older RFC.
  *   Historic: An RFC can be moved to "Historic" status when it is deemed to no longer be relevant for current use. This status is used for documents that were once useful or applicable but are no longer considered suitable for any current practical application.
  *   Errata: After an RFC is published, errors may be found within the document. Errata are filed to document these errors and their corrections. This does not change the RFC itself, but provides official recognition of the error and its recommended correction.
  *   Standardization: RFCs can also go through different levels of standardization, such as "Proposed Standard," "Draft Standard," and "Internet Standard." This categorization indicates the level of maturity and stability of the protocol or specification described in the RFC.

These status changes help manage the lifecycle of Internet standards and ensure that they remain up-to-date and relevant to the current technological environment. I am not aware of what is revising of RFCs.

Discussion about the BESS WG scope: The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane.

[Linda] The draft is about enabling L3 VPN services over hybrid underlay paths/links. The proposed work should be within the BESS charter based on the following bullets of the BESS charter:
"The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP."
"The working group may work on:
Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience."

This statement was taken out of context. John made an earlier comment about this:
https://mailarchive.ietf.org/arch/msg/bess/RdI2h98N8IJC_7mR5j8pPnq7Iuk/

In the charter the text below is also found:

""The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP. In
particular, the working group will work on the following services: ...."

In summary, the list outlines the services covered under BESS's charter. If the draft discusses topics beyond this
specified list, they should be considered outside the scope of the BESS Working Group. While there may
be topics closely related to those on the list, as you've identified, addressing these would require a
rechartering of the BESS Working Group.

"The working group may work on:

*Mechanisms to support BGP-enabled services in the presence of multi-
homing of Customer Edge (CE) devices to multiple Provider Edge (PE)
devices to provide load-balancing and resilience.

*Auto-discovery of sites that participate in the BGP-enabled service., beyond the list for which BESS is responsible, is ..etc etc..."

I'll work with the BESS chairs to update the BESS charter to add more explicit focus upon BESS core competences.

G/


From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Tuesday, April 30, 2024 7:09 AM
To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
Cc: draft-ietf-bess-bgp-sdwan-usage@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-usage@ietf.org>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>
Subject: Can we have a call to chat if the revision resolved AD's DISCUSS comments? Re: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Gunter,

The revised document (draft-ietf-bess-bgp-sdwan-usage-23)  should have fixed the technical issues pointed by John Scudder. Please see our resolutions to John on the technical issues he raised (mainly about removing the obsolete tunnel type "IPsec", removing the RFC4684 Constrained Route Distribution to address the SD-WAN security model, and the Security Consideration update).


As for  the questions to the BESS WG community, please see below for our response.

Can we have a phone chat with you to discuss if there are other pending issues and what we can do to move the draft forward?

Thank you,

Linda
-----Original Message-----
From: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>
Sent: Thursday, April 18, 2024 6:41 AM
To: draft-ietf-bess-bgp-sdwan-usage@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-usage@ietf.org>
Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; 'rtg-ads@ietf.org' <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@ietf.org>>
Subject: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time

Hi Authors, All,

Please review the information regarding the return decision for draft-ietf-bess-bgp-sdwan-usage. There are unresolved foundational technical issues that require significant attention and a consensus within the working group. Consequently, allowing additional time for this draft within the Working Group will be beneficial. This approach will ensure the document is thoroughly vetted and refined before further IETF processing.

Questions to the BESS WG community:
================================

* A recurring issue noted during the IESG review concerns the ambiguous purpose of the document. The draft-ietf-bess-bgp-sdwan-usage broadly suggests the possibility of utilizing BGP for the control plane and IPSec for the data plane. The necessity of an RFC to establish this practice is questionable.
* The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane.

[Linda] The draft is about enabling L3 VPN services over hybrid underlay paths/links. The proposed work should be within the BESS charter based on the following bullets of the BESS charter:
"The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP."
"The working group may work on:
Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience."

This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012)

About draft-ietf-bess-bgp-sdwan-usage technology:
==========================================

* RFC5566, which is obsolete, is currently utilized as a foundational component within draft-ietf-bess-bgp-sdwan-usage. It is advisable that newly proposed RFCs should avoid incorporating obsolete technologies.

[Linda] The latest revision (-23) has removed the "IPsec" Tunnel Type. Instead, the revision-23 is using the SDWAN-Hybrid (=25) of the IANA assigned tunnel type (proposed by draft-ietf-idr-sdwan-edge-discovery)

* There appears to be a misuse of the Encapsulation Extended Community, as detailed in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FumBB5yfoC3mFMpIWIT2K8159Gos%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C77b549716fa04cca002108dc5fad23ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638490444441412343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lg8g5ZLBfBH88yiDsmozfkMvlMnG4MAwrA7gHHgXrt0%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/idr/umBB5yfoC3mFMpIWIT2K8159Gos/> .

[Linda] Revision -23 should have fixed this issue.

* The "Encapsulation Extended Community: TYPE = IPsec" does not exist, according to the IANA registry of BGP tunnel encapsulation types.
see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml%23tunnel-types&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C77b549716fa04cca002108dc5fad23ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638490444441422772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qwjteHie5GE97KmZRsCjTOe1J6L%2BGhQphU5YvkroRfA%3D&reserved=0<https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types>

[Linda] Revision -23 should have fixed this issue.

* Newly proposed RFCs should not assume the existence of unestablished code-points as if they were established; if a new tunnel type for IPsec Tunnel underlay paths is required, it must be formally defined prior to implementation.
[Linda] There is no unestablished code-points used in Revision -23.

* RFC 9012 includes mechanisms for selecting or preferring NLRIs using the Color Extended Community, which might interact with the draft-ietf-bess-bgp-sdwan-usage's TYPE = IPsec proposal.
[Linda] Revision -23 should have fixed this issue.

* The term "Policy" is used variably throughout several sections, possibly leading to confusion about its application to different objectives. Clarity could be improved by specifying the types of policy being discussed.
[Linda] Revision -23 should have fixed this issue.

* Section 3.1.5 mentions that "Route-Reflectors... has the policy governing communication among peers", suggesting existing knowledge of route destinations, thereby questioning the necessity of RFC 4684.
[Linda] Revision -23 should have fixed this issue, removed the reference RFC4684.

* The security architecture concerning BGP-based structures and tunnel signaling should be more thoroughly explored, particularly in Section 8, rather than being briefly mentioned in Section 3.1.5.
* Section 8 requires enhancements to adequately address the issues raised in Roman's discuss items.

[Linda] Section 8 has been updated in revision-23.

* The text in Sections 6.2.2, 6.3.2, and 8 mentions the need for "additional anti-DDoS mechanisms." This requires further specification of the expected mechanisms
[Linda] This is referring to VPN PE's WAN ports may not have Anti-DDoS enabled. But for PEs in SD-WAN network with WAN facing the Internet, Anti-DDoS feature needs to be enabled.

Linda