[Idr] AD review of draft-ietf-idr-bgp-ct-33
John Scudder <jgs@juniper.net> Fri, 17 January 2025 17:05 UTC
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A21C1D52E2; Fri, 17 Jan 2025 09:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_HTML_ATTACH=0.01, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="QQq89O4L"; dkim=neutral reason="invalid (public key: not available)" header.d=juniper.net header.b="LiC3jhms"
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 srHJ7isAbn_o; Fri, 17 Jan 2025 09:05:10 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3C156C1D8D71; Fri, 17 Jan 2025 09:05:07 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50HES79D022756; Fri, 17 Jan 2025 09:05:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-type:date:from:message-id:mime-version:subject:to; s= PPS1017; bh=/7MVM71nznQySYbRgAYKvTCDwv5sX0/b6qQVKDjybNg=; b=QQq8 9O4LTMMb1YO6UdhDrqXxExaSNWXaqaGR4wlFEFxMJWm42h83k/v0qyaopFi3kEXH Tt8XvcEyaZuC9U9JFptm0g73854q2KoqbywoxMYheLISgFfpFmyi2gOLpvLrDhJ1 TLxQmIJbi4TStOwbYrc4B4hlxlH1t8oj1SAV7z+3oHufrxlufSAiMSoub7ID3EwQ 9bY7P6sQcz7YQ1bj6VMOEg67vaCCar/4fYZkuLE6JKsJ+gD6PABcxxALo43Rw1o9 JzUFb1clNp33L1GYspE+AIx4qLunEdjSKM6pKdDqUmwnzpYh9pEF6GgBBo+yA8ui /9nXDatB83UYKOVhJg==
Received: from bl0pr05cu006.outbound.protection.outlook.com (mail-BL0PR05CU006.outbound1701.protection.outlook.com [40.93.2.8]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 447dpasgxx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2025 09:05:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ign+EGUrHaxVDAB0c+xgdVK7yelHLTmgdxu/afmSWpN8oV25elqPKNWDG5/DhCMzBlSV6/VqeOIylkzafHkDilCOkOnplgZbX/n48P2ih2kfP8MKqS/sER7A+1Ao78Ild3sPCfuzKgcpUMKQfHpCP/zXbLxtI6vU19pW7VnQJfZVlPiXhrGp1/85qRTEXQLhm2LqOyynsDRUywJXkYTilN+n6ZnFFenCpemDpmv7nUcok++CCnb0hTOLcl4rXZwkD0VYt09pjRN8PEl4al2qcLqMGYwl2qgQPTCTVMnYXuGSHkQssgSS7JfEMXD0GkBkvZozqfI6WB7vF3Ubf1aebg==
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=/7MVM71nznQySYbRgAYKvTCDwv5sX0/b6qQVKDjybNg=; b=QQDD9T0mW3OX8R0bn50i9hq9zkSndm1crSO6BkGgothFp77pn30jpxRYCcSy1Mcuf6vu30tZ3iwa0qth4BRMxwohWUtdRXTG1vwcF6F6ovADHeqqzyCYIzQM0+sC6WUfihDAs/GBD2GIgnjEDyxXCfI4paoeep/MIprJfWpfHdDncMsqCYLrZ1t3ZfeDmuEMr00M/MugRX0r03e2l1tpKKsOMgkhulnl7D3QjI5IKdGaibfC8XznzNbYLJ2An1/P0odpAsGT7I4y6tykEYG6eVo+J+iF5wmu9U50z2jUKs3XN5cExW/mElpJ7+EcQ2noO/LeCgzLUD9l4jMMoLD/9w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/7MVM71nznQySYbRgAYKvTCDwv5sX0/b6qQVKDjybNg=; b=LiC3jhmsYlBPCDd0fWgIdBPnMhtD+KVQHY8sBBfYkB+GhwlCKBuZe2JZ00M9LgQ+wnbZNddJzzVOgg5xiTAkIemxqku4+dLAY7ebkYJZTnRdep4fl3WmGRHxwbUURA0Wh3PX0biXUGTgDtIwGmtr0CKTxG/tIjSMaYOlkXbUpeI=
Received: from CH3PR05MB10361.namprd05.prod.outlook.com (2603:10b6:610:1a6::5) by PH0PR05MB8189.namprd05.prod.outlook.com (2603:10b6:510:b4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.11; Fri, 17 Jan 2025 17:05:00 +0000
Received: from CH3PR05MB10361.namprd05.prod.outlook.com ([fe80::3c5a:17b8:179b:e30a]) by CH3PR05MB10361.namprd05.prod.outlook.com ([fe80::3c5a:17b8:179b:e30a%3]) with mapi id 15.20.8356.014; Fri, 17 Jan 2025 17:04:59 +0000
From: John Scudder <jgs@juniper.net>
To: "draft-ietf-idr-bgp-ct@ietf.org" <draft-ietf-idr-bgp-ct@ietf.org>
Thread-Topic: AD review of draft-ietf-idr-bgp-ct-33
Thread-Index: AQHbaQHwg89Cbogf40ebXZV28nSTHQ==
Date: Fri, 17 Jan 2025 17:04:59 +0000
Message-ID: <D2DBFEB1-2A49-4990-8BB4-C773F5EC195C@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3776.700.51)
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH3PR05MB10361:EE_|PH0PR05MB8189:EE_
x-ms-office365-filtering-correlation-id: a4685c57-ac63-46f6-dbc9-08dd37191373
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info: 9XLF7GbAIZW3rC7owWy/TDXu37/zWi4VfcYKUOsmwQay6hLQKcZO0vFhO4/imgHCqBGzWkQYS3Zp3HwI+t90TkYYxV1PGjdPCH+arxx3gd9MPkBA1Yf9kjbfaoPXQBji7JqbJVsIO3jkEw/molH2AvTHL8BAkbZQ4SLXOOpukaGbI388Bf7INsQwghgBq7TrjAxw6x1POgdHorVBFvRTP0Mz3tozvD8HqP0CxcKOir2PKgmHrDNM5UxOttkN1Zonqf2SOiiu0vOfh0wlbFKIvZYdzYJvtz94BQvfnFrlUcz1JWQrm2moTjONcjEJw9TqrxjBLZke1zp63AtTjQHQ/WSz3DbpgL38MmHRUyeiAXPjt9ja4ZZQuxonbZdc5mWl6ezHJKLTAEEiqXi/qJfKHCGaJ1Gxa1sQfzTwjuLSk8creNswuvEqVwHoJHLDKrgzCGYOV1gmjFZ3VhAkq9DGszGMoaAVBIy5feu7UfzfEjvB2gJdM05cd7vaCxrVNI7Rkt4Mnl2imjgiPK9rEULd/byW986y709Ag3lUwRrrvBNbtsOgtzlBdUiKijWHV5D0Hn0xPdelm13CTHXoZHVgoY0PAhJOcU8fgBqQ/gagS6zMh3wS0/k75BvqaiTZUf3wnTnOtD8bcTATA5/F4+uiXl/xevJeI6iEu3ogTSkP8BJapahxV4bBKHEO5OAKZB4JUgbI9T9RNohzqhBhqCbIRC7btDKRvEIFEsP34x7MDeV4bGXwzQy9KsYhk/vH5T4QarH1JARAOJYYQE89XNvfGpJgtiy6QpdZYEFnB3+sypBKlqVUbCkOFBAv36ihGAtNxnEx20sqp5U7UHtoxRHLo67c/ssuNTDBNnWIdWXXy74mpWM4BHJnCDdaMgLLMCOtE0DH8YkGinUMm9Bin4T4mbX856nlSjyBBil9R46d32962wcIGykLdwV27fHFq2f0dWcLgSmFB8vgQC8zpUVTajcE0N3ScyQNJg5aHyHF88brDwm5aLCkVZSjKQW4zACevesbZ9jEWoE/hBem6ymiBinAqQB5D+KzTBP7TaLouNlaMLwpy795XFhz6e77LPPiWUtEMwtdYVEilDHFRYquCXGItBLRABOzYP8aIFTJ+Rz+LDIT6WLaJJcmClRk4PuZnLhEHK2YGHE9N02gDNkqLHLhzdjSzDJivtXOxWfmg+wENbX4r6HmI6ksQenV0uN6KN4X/H3SDLUZWJ+vn95T1hCh+cfM2ICCFPfcAYmkuLSzAtAu8QbKkHbnUqEJfkH4/FPxYJuAXGCHXkbH3aLdumCUnP047ln4YJacVCTukrCjF0tltS2JsYVmA7p0GYIaqCDtiZIc5GL+D7m5wNCphw==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR05MB10361.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: NeoPJB0P1+T5AmE/HPqwecbFgb2F/EtqPmTAclFAlEpfkEUoylMFacP/LCt5Fcbz8a1MkdkPi+Xz6yRIIN6Xv9mE2tfIu4JBosw4mRZ32++ESyChi9Qoo1CRAtDFYxenGMwWWpwGhSLGMS10St1UQN3lHNPAWopgDs/ug+QTaNNF9eo5ZjVXwTjucU4YYtU86JxmFYPvpDhO9yZjhR6zaK7Yz7YEtUQDHD+cyhb+A4DYyZsImIvkZ8pJmeuB5K2Obri3whHjCGfdcpiL8VipgqriKsKb72V0EdIjmt6URdcQpX+iRaxaW5YlrI6vxrZjlOWCsnquhC3YuA0gIy5g1Sm4fxZVV4dieRQsOQTQ0P6Q6BpqQtd0QU6jB2Ipy+9PVtyPKF1vajnYWdmWo/qAP5pQ0CbvbxSo1FDuKT2Be9r18EA3UGv4BoadWNsoP9I7OkGCgweGZphvMwnymLvm1rQsUmH1sQtOEwCOyInHYyS8E2ppzD+KlvwEvQ3ZYj7hmV2iPouL3k9fQNS+gMVShxwaKYIEjoRboLAsvhkneJWMgEOb0wdgwXaCTf+neU0mLCIVTTHFbYGYutDIlVlJGpuqv/LlqvpNHqvPoJwB5T70Xf4QemYLqJjTqR5VhTZ6WyMOWauKzjGOGVWWZx1TTx0Q/ByT4f/PRBhAJ0DYAJLbIqwxUnpu7dHDQc+J2RyDI2hLGu5ULoM/eXFO9qnF5ln17x18LQUtwtRVYnD+QWFqj3/tVgsML87wGGJbyRoNZkAgK3Xxk2XikktetEZyRztSgjOg+RncxH8jV7Tml3SkZMVT2CBQfmyZQ2bEXkx8ruuL/pxXdgwy8Nc5GKyVHbB05LhUEBM81RIBfKbZs9hzsc32PWA1YT4vFziGlmWGU4y1/Irl0qrUVCGdj1zVM0LXuc24UlbqyZDv/rY88AfSTtrDgxv6JmKJa0vhEqhYrPG0/s8urWdl7DZS35VfMtF5jXieub4Qic9GTQ/tlvil1BFWVzuuXDS8oCrOZn3hhez9P6s4xv7FHTAv/7XYy5r2B/Svkxr+aC7fmBoTroi/NYOZiVcuXHT9r9Vn4eXYXuU3X+wb5TCskyaSXSBy3ZTNIvRzHpvCjxc9fhIFVeclL99hPVFwGaSAZy+Jj059InL9731RlnmP+aOdi6aZQXxygwTtKQ2sH8B1MSHf63fIYwiNddNK6cTfTK2Kjv9/UDJ22FbnBXtK5+YztoEZ1sSAEocfL5q7f5EBgz6dFbgo32u+3yN5sa62pnK+4g9mjSBZNo+hDWblv/udlZqOMdNq6l5dV1BxjRLZxJz13ok6P+uTkT1XYMe319lzpjRnMi3FsaNN78hVhO+WvZxJ5NEgFZsAl+kCM0RuIGsmw5gCNHwZzq9zJxqJetakbzP8QvUTcZKt9X5bvjkuo9qk4C/wJOJ3I17NVn9GKGe9ztqgCt3RYrt5pTyTtocZu6D0CdrBzV0hYwpsp1aqnZUWYSAZi7312CkOS07Lv9SR1y6sIsVjdPjMw4cArgLyFXXc+mckyGuvja0jK7B7U7BF2vv2FKX87wFrXbbh1Bufe7h/D6nb5n+QYsPndDFoI90R
Content-Type: multipart/mixed; boundary="_003_D2DBFEB12A4949908BB4C773F5EC195Cjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH3PR05MB10361.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4685c57-ac63-46f6-dbc9-08dd37191373
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2025 17:04:59.6035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RjehQuRXUEtMY3KRsKqsiHicCZ8Ytw7de/cLBBCWP1hNYflQ4+8ChxGG89ZSyYnk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8189
X-Proofpoint-GUID: NVMtu0nKsrx2pZab3HMIx9SUucqlIuvT
X-Proofpoint-ORIG-GUID: NVMtu0nKsrx2pZab3HMIx9SUucqlIuvT
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-17_06,2025-01-16_01,2024-11-22_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501170134
Message-ID-Hash: C3ZMUQX2SQUIXKRG35XQCMRIVSI2YIJA
X-Message-ID-Hash: C3ZMUQX2SQUIXKRG35XQCMRIVSI2YIJA
X-MailFrom: jgs@juniper.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] AD review of draft-ietf-idr-bgp-ct-33
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZSergNshZc35pV6NSpE9XLzUJvE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
Hi Authors, WG, Thanks for your patience as I completed this challenging but rewarding review. I apologize for not using GitHub for my input; I judged it more important to get the review to you without any further delay by following my usual workflow, than to do it in the best format. I’ll try to do better in the future. That having been said, I’ve supplied my questions and comments in the form of an edited copy of the draft. Minor editorial suggestions I’ve made in place without further comment, more substantive questions and comments are done in-line and prefixed with “jgs:”. You can use your favorite diff tool to review them; I’ve attached the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply. Thanks, —John --- draft-ietf-idr-bgp-ct-33.txt 2025-01-16 19:59:12 +++ draft-ietf-idr-bgp-ct-33-jgs-edits.txt 2025-01-17 11:52:00 @@ -30,8 +30,10 @@ that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages RFC - 4364 procedures and follows RFC 8277 NLRI encoding is defined to - advertise underlay routes with its identified class. This new + 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)" + procedures and follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") + NLRI encoding is defined to enable each advertised underlay route to be + identified by its class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. Requirements Language @@ -244,12 +246,27 @@ paths honoring that desired intent. The constructs and procedures defined in this document apply - homogeneously to intra-AS as well as inter-AS (a.k.a. multi-AS) + to intra-AS as well as inter-AS (a.k.a. multi-AS) Option A, Option B and Option C (Section 10, [RFC4364]) style deployments in provider networks. ++-- +jgs: I suggested deleting "homogeneously" since I couldn't figure +out what work it was doing. You could leave it as I've put it, or +perhaps you wanted something like "equally". But I think it's OK +as shown. ++-- Provider networks that are deployed using such styles provision intra-domain transport tunnels between a pair of endpoints, typically ++-- +jgs: I think it would be useful to state someplace early on what +"transport" means in the context of this document, since it will +also be reviewed by people who think "transport" means UDP, TCP, +and QUIC. This goes double for "transport layer" which is more +commonly understood to mean OSI reference model layer 4. That one +at least, I think should go in the Terminology section, I'll add +a stub. ++-- a service node or a border node, that service traffic use to traverse that domain. These tunnels are signaled using various tunneling protocols depending on the forwarding architecture used in the @@ -272,7 +289,7 @@ and the network needs to have constructs able to enact the customer's intent. The network constructs defined in this document are used to classify and group these intra-domain tunnels based on various - characteristics, like TE characeteristics (e.g., low latency), into + characteristics, like TE characteristics (e.g., low latency), into identifiable classes that can pass "intent-aware" traffic. These @@ -282,7 +299,7 @@ Internet-Draft BGP Classful Transport Planes April 2024 - constructs enable services to express their desired intent on using + constructs enable services to express their intent to use one or more identifiable classes, and mechanisms to selectively map traffic onto "intent-aware" tunnels for these classes. @@ -293,10 +310,42 @@ [Intent-Routing-Color] describes various use cases and applications of the procedures described in this document. + + [Appendix C] provides an outline of the design philosophy behind this + specification. In particular, readers who are already familiar with + one or more BGP VPN technologies may want to review this appendix + before reading the main body of the specification. ++-- +jgs: Up to you whether to include the above (or something like it) but +it sure would have helped my review to have done it in that order... and +I already had the outline from before, I just needed a refresher. I can +only imagine it would be even more helpful to a reviewer getting their +first exposure. ++-- 2. Terminology ++-- +jgs: In general I tend to dislike the heavy use of acronyms/initialisms +where terms could be spelled out instead; it tends to create an +unnecessary barrier to entry for those who aren't part of the "in group" +while not (as far as I can tell) helping those who are part of the "in +group". However to change that in this document would be a large effort +for probably modest gains, so instead I've just suggested adding a few +missing terms to the glossary. +However, please feel free to take on the challenge of reducing use of +abbreviations instead, if you wish. ++-- + ABR: Area Border Router ++-- +jgs: I was surprised to encounter ABR in the BGP context. I was only +aware of it being a term of art in the IGPs. Since BGP doesn't have +"areas" as a defined construct, if you are going to use this term I +think it would be helpful to say some more words about what precisely +you intend by it. Or of course, cite a definition if there's already +one in another relevant document. ++-- AFI: Address Family Identifier @@ -327,6 +376,8 @@ eSN: Egress Service Node FEC: Forwarding Equivalence Class + + FRR: XXX fill me in XXX iSN: Ingress Service Node @@ -338,8 +389,8 @@ Internet-Draft BGP Classful Transport Planes April 2024 - LPM: Longest Prefix Match - + L-ISIS: XXX fill me in, see also comment on B.2.2 XXX + LSP: Label Switched Path MNH: BGP MultiNexthop attribute @@ -351,16 +402,29 @@ PE: Provider Edge PHP: Penultimate Hop Pop + + PIC: XXX fill me in XXX PNH: Protocol Next Hop address carried in a BGP Update message RD: Route Distinguisher + ++-- +jgs: You use "RD:EP" several time. I think it might be helpful to supply +a definition, even if it's "intuitively obvious" to reviewers who are +already expert in L3VPN technology. ++-- RSVP-TE: Resource Reservation Protocol - Traffic Engineering RT: Route Target extended community RTC: Route Target Constrain ++-- +jgs: I see you're not citing RFCs for any of these. When I was reviewing +it seemed to me a cite for RTC wouldn't go amiss, but if you want to keep +it consistent that's OK. ++-- SAFI: Subsequent Address Family Identifier @@ -381,7 +445,9 @@ TC-BE: Best Effort Transport Class TE: Traffic Engineering - + + TEA: Tunnel Encapsulation Attribute, attribute type code 23. + TRDB: Transport Route Database UHP: Ultimate Hop Pop @@ -399,9 +465,9 @@ 2.1. Definitions and Notations BGP Community Carrying Attribute (CCA) : A BGP attribute that carries - community. Examples of BGP CCA are: Communities (attr code 8), - Extended Communities (attr code 16), IPv6 Address Specific Extended - Community (attr code 25), Large community (attr code 32). + community. Examples of BGP CCA are: COMMUNITIES (attribute code 8), + EXTENDED COMMUNITIES (attribute code 16), IPv6 Address Specific Extended + Community (attribute code 25), LARGE_COMMUNITY (attribute code 32). color:0:100 : This notation denotes a Color extended community as defined in RFC 9012 with the Flags field set to 0 and the color field @@ -415,10 +481,10 @@ including things like import policy application, resolution scheme selection and next hop resolution. - Intent: A set of operational goals (that a network should meet) and - outcomes (that a network is supposed to deliver) defined in a - declarative manner without specifying how to achieve or implement - them, as defined in Section 2 of [RFC9315]. + Intent: As defined in Section 2 of [RFC9315], "A set of operational + goals (that a network should meet) and outcomes (that a network is + supposed to deliver) defined in a declarative manner without + specifying how to achieve or implement them." Mapping Community: Any BGP CCA (e.g., Community, Extended Community) on an overlay route that maps to a Resolution Scheme. For example, @@ -430,6 +496,8 @@ Service Family: A BGP address family used for advertising routes for destinations in "data traffic". For example, AFI/SAFIs 1/1 or 1/128. + Transport, Transport Layer: XXX fill me in XXX + Transport Family: A BGP address family used for advertising tunnels, which are in turn used by service routes for resolution. For example, AFI/SAFIs 1/4 or 1/76. @@ -458,6 +526,11 @@ deploying a chosen set of technologies and hardware. Enhancements and upgrades to such network deployments protect return on investment, and should consider continuity of service. ++-- +jgs: maybe you've chosen to put this out of alphabetical order because +of proximity to the def'n of greenfield network, but noting in case it +was an accident. ++-- Greenfield network: A new network deployment which can make choice of new technology or hardware as needed, with fewer constraints than @@ -465,7 +538,14 @@ Transport Class: A construct to group transport tunnels offering similar SLA. ++-- +jgs: "Similar" is a likely trigger for reviewers to ask you to please be +specific about the kinds of similarity. Possibly you just need to +provide a forward reference to Section 4.1. +See also my next comment. ++-- + Transport Class RT: A Route Target Extended Community used to identify a specific Transport Class. @@ -543,6 +623,19 @@ The "Transport Class" (Section 4) construct to group underlay tunnels with sufficiently similar TE characteristics. ++-- +jgs: Again, don't leave this to the reader to infer (or guess). Either +remove the "similar" stuff, or qualify it. The "remove" option would +look like, + + The "Transport Class" (Section 4) construct to group underlay + tunnels. + +Which I think is actually sufficient, but ¯\_(ツ)_/¯ + +Alternatively, maybe a forward reference to Section 4.1 would do the +trick. ++-- The "Resolution Scheme" (Section 5) construct for overlay routes with Mapping Community to resolve next hop reachability from @@ -589,6 +682,16 @@ The BGP CT address family carries transport prefixes across tunnel domain boundaries, which is parallel to BGP LU (AFI/SAFIs 1/4 or 2/4). It disseminates "Transport Class" information for the ++-- +jgs: above, I don't get what you mean by the first sentence, in +particularly "which is parallel" part. Would it be correct to break this +into two sentences? Like: + + The BGP CT address family carries transport prefixes across tunnel + domain boundaries. Its design and operation are analogous to BGP LU + (AFI/SAFIs 1/4 or 2/4). ++-- + transport prefixes across the participating domains while avoiding the need of per-transport class loopback. This is not possible with BGP LU without using per-color loopback. This makes the end-to-end @@ -597,11 +700,11 @@ In Figure 1, BGP CT routes are originated at BN11 in AS1 with next hop "self" towards BN21 in AS2 to extend available RSVP-TE tunnels for Transport Class 100 and 200 in AS1. BN21 propagates these routes - with next hop "self" onto PE21, which resolves the BGP CT routes over + with next hop "self" to PE21, which resolves the BGP CT routes over SRTE tunnels belonging to same transport class. - Overlay routes carry sufficient indication of the desired Transport - Classes using a BGP community which assumes the role of as a "Mapping + Overlay routes carry an indication of the desired Transport + Classes using a BGP community which assumes the role of a "Mapping Community". A Resolution Scheme is identified by its "Mapping Community", where its configuration can either be auto-generated based on TC ID or done manually. @@ -648,11 +751,19 @@ similar SLA within the administrative domain of a provider network or closely coordinated provider networks. - A Transport Class is uniquely identified on a box by a 32-bit + A Transport Class is uniquely identified by a 32-bit "Transport Class ID", that is assigned by the operator. The operator consistently provisions a Transport Class on participating nodes (SNs and BNs) in a domain with its unique Transport Class ID. ++-- +jgs: First, "on a box" is too colloquial, "on a router" would be better. +But more importantly, I think you can delete "on a box" and not replace +it with anything. Isn't it true that it has to be identical throughout +the AS? In fact, the second sentence says that. So I've proposed the +deletion. ++-- + A Transport Class is also configured with RD and import/export RT attributes. Creation of a Transport Class instantiates its corresponding TRDB and Resolution Schemes on that node. @@ -692,6 +803,9 @@ Tunnels (RSVP-TE, SR-TE) that share resources in the network based on Shared Risk Link Groups defined by TE policy. ++-- +jgs: I don't understand the one above. ++-- Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the network based on RSVP-TE ERO, SR-TE policy or BGP policy. @@ -719,7 +833,9 @@ route in the desired Transport Class. When the tunnel route is received via [SRTE] with "Color:Endpoint" as - the NLRI that encodes the Transport Class as an integer 'Color', the + the NLRI that encodes the Transport Class as an integer 'Color' + in its Policy Color field, + the 'Color' is mapped to a Transport Class during the import processing. The SRTE tunnel route for this 'Endpoint' is installed in the @@ -735,6 +851,12 @@ label. The MPLS swap route thus installed for the new label will pop the label and forward the decapsulated traffic into the path determined by the SRTE route for further encapsulation. ++-- +jgs: You've made [SRTE] an informative reference. Based on the above +paragraph, I think it has to be a normative reference. The above +paragraph specifies procedure, and it can't be understood without +reference to the SRTE document. ++-- [PCEP-SRPOLICY] extends Path Computation Element Communication Protocol (PCEP) to signal attributes of an SR Policy which include @@ -756,6 +878,15 @@ Tunnel endpoint addresses (EP) in a TRDB belong to the "Provider Namespace" representing the core transport region. ++-- +jgs: you talk about "provider namespace" a few times but without ever +defining it. I presume it's the bottom turtle ;-) in the virtualization +stack, i.e. it represents real, non-virtualized addresses. (Well at +least notionally, from the provider's point of view.) I wonder if you +can say this more explicitly, i.e. it's the base of the virtualization +hierarchy. Equally, "the core transport region" doesn't have any well- +defined meaning. ++-- An implementation may realize the TRDB as a "Routing Table" referred in Section 9.1.2.1 of RFC4271 (https://www.rfc-editor.org/rfc/ @@ -765,6 +896,10 @@ adhering to the procedures defined in this document. The tunnel routes in a TRDB require no footprint in the forwarding plane unless they are used to resolve a next hop. ++-- +jgs: would it be correct to change "require no footprint" to "need not +be installed"? ++-- SNs or BNs originate routes for the "Classful Transport" address family from the TRDB. These routes have "RD:Endpoint" in the NLRI, @@ -826,8 +961,8 @@ The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs [RFC4364] and the Constrained Route Distribution mechanisms specified - in Route Target Constrain [RFC4684] are applied using Route Target - extendend community. These mechanisms are applied to BGP CT routes + in Route Target Constrain [RFC4684] are applied using the Route Target + extended community. These mechanisms are applied to BGP CT routes (AFI/SAFI: 1/76 or 2/76) using "Transport Class Route Target Extended community". @@ -847,12 +982,29 @@ Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). An RTC route is generated for each Route Target imported by locally provisioned Transport Classes. ++-- +jgs: if you really want to impose normative constraints on RTC +implementations, then I think you should add the Updates: header +for RFC 4684. You will also need to add something like the following +to your Abstract: "This document updates RFC 4684 by requiring that +its procedures be applied in the new context described herein." +But this seems awfully aspirational. We all know you can't go and +force old RTC implementations into compliance. Do you really mean +something like "implements RTC as well as this specification"? If you +made that change you could skip the Updates: business. ++-- + Further, when processing RT membership NLRIs received from external BGP peers, it is necessary to consider multiple EBGP paths for a given RTC prefix for building the outbound route filter, and not just the best path. An implementation MAY provide configuration to control how many EBGP RTC paths are considered. ++-- +jgs: again, the paragraph above skates pretty close to updating RFC +4684, but you could avoid that if you scope it to apply only to the +NLRI defined in the present spec. ++-- The Transport Class Route Target Extended community is carried on BGP CT family routes and is used to associate them with appropriate TRDBs @@ -879,10 +1031,14 @@ or an ordered set of TRDBs. An overlay route is associated with a resolution scheme during import processing, based on Mapping Community on the route. ++-- +jgs: The final clause above needs some kind of edit. Maybe "... based +on the Mapping Community in the route." ++-- Resolution Schemes enable a BGP speaker to resolve next hop reachability for overlay routes over the appropriate underlay tunnels - within the scope of the TRDBs. Longest Prefix Match (LPM) of the + within the scope of the TRDBs. Longest Prefix Match of the next hop is performed within the identified TRDB. An implementation may provide an option for the overlay route to @@ -919,7 +1075,7 @@ BGP Community Carrying Attribute (e.g. Community or Extended Community) may play this role, besides the other roles it may already be playing. For example, the Transport Class Route Target Extended - Community plays both roles of being a Route Target as well as a + Community plays a dual role, being a Route Target as well as a Mapping Community. Operator provisioning ensures that the ingress and egress SNs agree @@ -937,6 +1093,10 @@ The order of communities on an overlay route does not affect the determining of Mapping community in effect. ++-- +jgs: I'm confused. The sentence above appears to completely conflict +with the sentence below. ++-- The first community on the overlay route that matches a Mapping Community of a locally configured Resolution Scheme is considered the @@ -956,18 +1116,16 @@ If more than one distinct Mapping Communities on an overlay route map to distinct Resolution Schemes with dissimilar Intents at a receiving - node, it is considered a configuration error. Operators should avoid - such configuration errors when attaching mapping communities on - overlay routes. + node, it is considered a configuration error. It should be noted that the Mapping Community role does not require applying Route Target Constrain procedures specified in RFC 4684. 6. BGP Classful Transport Family - The BGP Classful Transport (BGP CT) family will use the existing + The BGP Classful Transport (BGP CT) family uses the existing Address Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76 - "Classful Transport" that will applies to both IPv4 and IPv6 AFIs. + "Classful Transport" that applies to both IPv4 and IPv6 AFIs. The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol Extensions capability described in Section 8 of [RFC4760] to be able @@ -996,15 +1154,26 @@ the Multiple Labels Capability as described in Section 2.1 of [RFC8277] - Attributes on a Classful Transport route include the Transport Class + Mandatory attributes of a Classful Transport route include the Transport Class Route Target extended community, which is used to associate the route - with the correct TRDBs on SNs and BNs in the network and either an + with the correct TRDBs on SNs and BNs in the network, and either an IPv4 or an IPv6 next hop. ++-- +jgs: I added "mandatory". That's right, isn't it? These have to be +included? +Also, the word "attributes" is a little unfortunate since the NH isn't +a path attribute, and since we're talking about BGP the reader might +automatically think "attribute" means PA. Our field has a bad habit of +overloading all the synonyms we might use, e.g. "trait", "characteristic", +etc. Still, please consider whether something can be done to make this +less ambiguous. ++-- + Vairavakkalai & VenkataraExpires 27 October 2024 [Page 18] Internet-Draft BGP Classful Transport Planes April 2024 @@ -1098,7 +1267,22 @@ service prefixes with a space complexity of O(1M). The "per prefix" label allocation scheme localizes routing churn during topology changes. ++-- +jgs: two things to flag about the above: +1. "typically" --> "typically (at time of writing)" + +2. I know we tend to colloquially abuse O() to mean "more or less" but + https://en.wikipedia.org/wiki/Big_O_notation will remind you that + O(1k) == O(100k) == O(1m) ... they're all constant. If you want + to be colloquial that's fine but then try to avoid the use of formal + language, e.g. perhaps something like, + +"... typically with a number of routes in the hundreds of thousands or +less, without affecting SAFI 128 service prefixes which may represent +millions of routes, at time of writing." ++-- + Service routes continue to be carried in their existing AFI/SAFIs without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128), EVPN (AFI/SAFI: 25/70 ), VPLS (AFI/SAFI: 25/65), Internet (AFI/SAFI: @@ -1106,11 +1290,11 @@ 1/76 or 2/76) transport routes. A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different - readvertisement path of the transport family routes in a network than - the service route readvertisement path. Service routes (Inet-VPN + distribution path of the transport family routes in a network than + the service route distribution path. Service routes (Inet-VPN SAFI 128) are exchanged over an EBGP multihop session between ASes with next hop unchanged; whereas Classful Transport routes (SAFI 76) - are readvertised over EBGP single hop sessions with "next hop self" + are advertised over EBGP single-hop sessions with "next hop self" rewrite over inter-AS links. @@ -1122,7 +1306,7 @@ Internet-Draft BGP Classful Transport Planes April 2024 - The BGP CT SAFI 76 for AFI 1 and 2 is similar in vein to BGP LU SAFI + The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP LU SAFI 4, in that it carries transport prefixes. The only difference is that it also carries in a Route Target an indication of which Transport Class the transport prefix belongs to, and uses the RD to @@ -1254,9 +1438,13 @@ also installs an MPLS route for that label that swaps the incoming label with the label received from the downstream BGP speaker (or pops the incoming label if the label received from the downstream - BGP speaker was Implicit-NULL). It then pushes received traffic + BGP speaker was Implicit-NULL). The MPLS route then pushes received traffic to the transport tunnel or direct interface that the Classful Transport route's PNH resolved over. ++-- +jgs: I suggested a change to clarify what is meant by "it". If I got the +referent of "it" wrong, let's discuss. ++-- The label SHOULD be allocated with "per-prefix" label allocation semantics. The IP prefix in the TRDB context (Transport-Class, @@ -1421,7 +1609,15 @@ BGP CT routes to the Forwarding Information Base (FIB), to provide reachability for control plane peering towards endpoints in other domains. ++-- +jgs: I found the preceding paragraph a little startling. In general, +are BGP CT routes not installed in a forwarding information base? Are +you drawing a distinction between *a* FIB (which might be a VRF) and +*the* FIB, i.e. the "normal" IP forwarding table? +In any case a few more words around this might have helped me. ++-- + 7.10. Interaction with BGP Attributes Specifying Next Hop Address and Color @@ -1434,6 +1630,14 @@ exist in multiple places on the same route, and a precedence order needs to be established to determine which Transport Class the route's next hop should resolve over. This document suggests the ++-- +jgs: Is it just a suggestion though? It seems not to be (see "expected" +in the final paragraph). + +Perhaps "specifies", and if what you're trying to capture is that +the order could be changed by configuration, say something to that +effect. ++-- following order of precedence, more specific scoping of Color preferred to less specific scoping: @@ -1476,7 +1680,15 @@ BGP CT architecture to achieve Flow based forwarding with SLAs. 7.12. Applicability to IPv6 ++-- +jgs: I found it a little surprising/lacking in symmetry to have this +section without a corresponding "Applicability to IPv4" section. I +expect you might get a similar remark from the INT ADs. +You might consider adding a prefatory paragraph stating why it makes +sense to do it this way. (Or not. I don't insist.) ++-- + This section describes applicability of BGP CT to IPv6 at various layers. BGP CT procedures apply equally to an IPv6 enabled Intra-AS or Inter-AS Option A, B, C network. @@ -1517,6 +1729,11 @@ 7.13. SRv6 Support This section describes how BGP CT family (AFI/SAFI 2/76) may be used ++-- +jgs: "this section describes". No, it doesn't, or if so it only does so +by reference. I think you can fix this by deleting "This section describes +how"; after that change, the section stands. ++-- to set up inter-domain tunnels of a certain Transport Class, when using Segment Routing over IPv6 (SRv6) data plane on the inter-AS links or as an intra-AS tunneling mechanism. @@ -1524,6 +1741,10 @@ Details of SRv6 Endpoint behaviors used by BGP CT and the procedures are specified in a separate document [BGP-CT-SRv6], along with illustration. As noted in this document, BGP CT route update for ++-- +jgs: does "this document" refer to BGP-CT-SRv6? If so, change it to +"that document" or even "BGP-CT-SRv6". ++-- SRv6 includes a BGP attribute containing SRv6 SID information (e.g. Prefix SID [RFC9252]) with Transposition scheme disabled. @@ -1550,6 +1771,12 @@ endpoints like loopback addresses. The range 203.0.113.0/24 is used to represent service route prefixes advertised in AFI/SAFIs: 1/1 or 1/128. ++-- +jgs: You will probably get (non-blocking) complaints from one of the INT +ADs about use of IPv4 instead of IPv6 for examples. You could consider +adding a sentence or two acknowledging that the examples could also have +been done using IPv6 ranges (although they weren't). ++-- 8.1. Reference Topology @@ -1740,6 +1967,10 @@ ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs ASBR21, ASBR22 in neighboring AS. They negotiate BGP CT family with ++-- +jgs: The referent of "they" above is unclear. Do you mean ASBR21, ASBR22? +Probably better to spell it out instead of using the pronoun. ++-- RR27 in region 2, which reflects BGP CT routes to ABR23, ABR24. ABR23, ABR24 negotiate BGP CT family with Ingress node PE25 in region 1. BGP LU family is also negotiated on these sessions alongside BGP @@ -1748,6 +1979,11 @@ PE11 is provisioned to originate BGP CT route with Gold SLA to endpoint PE11. This route is sent with NLRI RD prefix ++-- +jgs: I find the first sentence of this paragraph ambiguous/unclear. +Do you mean "PE11 is provisioned to originate a BGP CT route for an +address of PE11, with Gold SLA"? ++-- 192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11 and a route target extended community transport-target:0:100. Label B-L0 can either be Implicit Null (Label 3) or an Ultimate Hop Pop (UHP) @@ -1772,7 +2008,8 @@ In the Bronze plane, BGP CT route with Bronze SLA to endpoint PE11 is originated by PE11 with a NLRI containing RD prefix - 192.0.2.11:200:192.0.2.11, and appropriate label. The RD allows both + 192.0.2.11:200:192.0.2.11, and appropriate label. The use of distinct + RDs for Gold and Bronze allows both Gold and Bronze advertisements to traverse path selection pinchpoints without any path hiding at RRs or ASBRs. And route target extended community transport-target:0:200 lets the route resolve over Bronze @@ -1795,6 +2032,10 @@ B-L1, B-L2 and forward to ASBR13, ASBR14 respectively. RR27 ++-- +jgs: It might be worth pointing out something like "(this is an ECMP +route)". ++-- readvertises this BGP CT route to ABR23, ABR24 with label and next hop unchanged. @@ -1924,6 +2165,10 @@ at ASBR22 without the failure event propagated in the BGP CT network. In this case, ingress node PE25 will not know there was a failure, and traffic restoration will be independent of prefix scale (PIC). ++-- +jgs: I suggested glossing PIC although since you only use it 2x, you could +also just move the inline expansion you do later, to this location. ++-- 8.4.3. Absorbing Failure of Primary Path: Fallback to Best Effort Tunnels @@ -1999,7 +2244,16 @@ (Color), and not BGP next hop; BGP CT routes will not be advertised into domains with PEs that don't import its transport class. ++-- +jgs: Two things about the final clause above: +1. Isn't this true only if RTC is in use? + +2. In any case it's wrong as written, should be "a BGP CT route will only +be advertised into a domain with at least one PE that imports its transport +class" -- right? ++-- + The transport-target:0:<TC> is the new type of route target (Transport Class RT) defined in this document. It is carried in BGP extended community attribute (BGP attribute code 16). @@ -2031,14 +2285,28 @@ <eSN>:<TC>. The ingress SN may learn the eSN values either by configuration, or it may discover them from the BGP next hop field in the BGP VPN service routes received from eSN. A BGP ingress SN - receiving a BGP service route with next hop of eSN generates a + receiving a BGP service route with next hop of eSN and origin + autonomous system "Origin ASN" generates a RTC/Extended-RTC route for Route Target prefix <Origin ++-- +jgs: what is Extended-RTC?!? ++-- ASN>:<eSN>/[80|176] in order to learn BGP CT transport routes to reach eSN. This allows constrained distribution of the transport routes to the PNHs actually required by iSN. When the path of route propagation of BGP CT routes is the same as the RTC routes, a BN would learn the RTC routes advertised by ++-- +jgs: when RTC is in use, the path of propagation WILL be the same, right? +So is the first clause just a weird way of saying that? I think it is +not the most direct way to say it, if so. Perhaps something like, "When +RTC is in use as described here, BGP CT routes will be constrained to +follow the same path of propagation as the RTC routes. Therefore, a BN +would..." + +Or am I mistaken? ++-- ingress SNs and propagate further. This will allow constraining distribution of BGP CT routes for a PNH to only the necessary BNs in the network, closer to the egress SN. @@ -2062,23 +2330,17 @@ 9.3. Limiting The Visibility Scope of PE Loopback as PNHs It may be even more desirable to limit the number of PNHs that are - globally visible in the network. This is possible using mechanism - described in Appendix D. - - - - - -Vairavakkalai & VenkataraExpires 27 October 2024 [Page 37] - -Internet-Draft BGP Classful Transport Planes April 2024 - - - Such that advertisement of PE loopback addresses as next-hop in + globally visible in the network. This is possible using the mechanism + described in Appendix D, such that advertisement of PE loopback + addresses as next-hop in BGP service routes is confined to the region they belong to. An anycast IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts the SNs in a region from other regions in the network. ++-- +jgs: If the edit above is wrong, please help me understand what you do +intend. ++-- This provides much greater advantage in terms of scaling, convergence and security. Changes to implement this feature are @@ -2544,6 +2806,9 @@ To facilitate this mapping, every SN/BN in all AS provisioning required transport classes, viz. 100, 101 and 102. SN and BN in AS1 ++-- +jgs: I don't understand the sentence above. ++-- and AS3 are provisioned with customized resolution schemes that resolve routes with transport-target:0:101 or transport-target:0:102 strictly over color 100 TRDB. @@ -2972,8 +3237,9 @@ 13.1. New BGP SAFI - IANA is requested to assign a new BGP SAFI code for "Classful - Transport". Value 76. + IANA has assigned a BGP SAFI code for "Classful + Transport". Value 76. IANA is requested to update + the reference to this document. Registry Group: Subsequent Address Family Identifiers (SAFI) Parameters @@ -2994,7 +3260,7 @@ 13.2. New Format for BGP Extended Community - IANA is requested to assign a new Format type (Type high = 0xa) of + IANA has assigned a Format type (Type high = 0xa) of Extended Community EXT-COMM [RFC4360] for Transport Class from the following registries: @@ -3002,7 +3268,9 @@ the "BGP Non-Transitive Extended Community Types" registry. - Please assign the same low-order six bits for both allocations. + Please the same low-order six bits have been assigned for both allocations. + + IANA is requested to update the references to this document. This document uses this new Format with subtype 0x2 (route target), as a transitive extended community. The Route Target thus formed is @@ -3012,9 +3280,9 @@ 0x2 (route target) is called the "Non-Transitive Transport Class route target extended community". - Taking reference of [RFC7153] , following requests are made: + Taking reference of [RFC7153] , the following assignments have been made: -13.2.1. Existing Registries to be Modified +13.2.1. Existing Registries 13.2.1.1. Registries for the "Type" Field @@ -3127,7 +3395,7 @@ 13.3. MPLS OAM Code Points - The following two code points are sought for Target FEC Stack sub- + The following two code points have been assigned for Target FEC Stack sub- TLVs: @@ -3152,9 +3420,27 @@ 31744 IPv4 BGP Classful Transport 31745 IPv6 BGP Classful Transport + IANA is requested to update + the references to this document. 13.4. Transport Class ID ++-- +jgs: I don't understand why we need this "registry". AFAICT once +published it will be a read-only artifact: 0 is already assigned, +and all the rest of the code points are off limits. + +To look at a recent example, consider the MASQUE Context ID, +https://www.rfc-editor.org/rfc/rfc9298.html#name-context-identifiers +This has similar properties (0 has a special meaning, the rest of the +2^62 values are dynamically allocated). It seems to me you're better +off following that pattern and not proposing a read-only registry, +which seems like a poor use of IANA resources. + +If there's a rationale for making this a "registry" please let me +know it. ++-- + This document reserves the Transport class ID value 0 to represent "Best Effort Transport Class ID". This is used in the 'Transport Class ID' field of Transport Route Target extended community that @@ -3269,6 +3555,12 @@ diversions. Furthermore, as long as the filtering and appropriate configuration mechanisms discussed previously are applied diligently, risk of the diversion of the traffic is eliminated. ++-- +jgs: It's awfully daring to say a "risk ... is eliminated", especially when +the "elimination" is through the hard crunchy exterior, completely trusted +interior security model. I would suggest deleting the "furthermore" sentence +which is likely to draw fire and doesn't seem needed. ++-- 15. References @@ -3451,7 +3743,17 @@ Hegde, Ed., "Intent-aware Routing using Color", 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-hr- spring-intentaware-routing-using-color-03#section-6.3.2>. ++--- +jgs: why the link to a specific section? that's unusual in a reference. +I guess if you really to want to reference that particular section, +you should cite it as "Intent-aware Routing using Color", Section 6.3.2. +But better just to link to the top level. +I do see you refer to that specific section a couple places in the body text, +but elsewhere you refer to the overall doc without section. So better to +just cite the doc. ++--- + [MNH] Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 17 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf- idr-multinexthop-attribute-00>. @@ -3514,7 +3816,12 @@ Routing Policies in BGP", 23 October 2023, <https://tools.ietf.org/html/draft-ietf-idr-segment- routing-te-policy-26>. ++-- +jgs: this is the wrong reference, you want draft-ietf-idr-sr-policy-safi-10 +Also, please make this normative. ++-- + [TEAS-NS] Farrel, Ed. and Drake, Ed., "A Framework for IETF Network Slices", 14 September 2023, <https://www.ietf.org/archive/id/draft-ietf-teas-ietf- @@ -3531,6 +3838,11 @@ A.1. Signaling Intent over PE-CE Attachment Circuit ++-- +jgs: Why do we need this appendix when we already have Section 11.5, +"Use of DSCP"? If it's just a vehicle for referencing MNH, couldn't you +do that from S. 11.5 and dispense with this appendix? ++-- It may be desirable to allow a CE device to indicate in the data packet it sends what treatment it desires (the Intent) when the @@ -3655,8 +3967,11 @@ CE31 advertises a route for example prefix 203.0.113.31 with next hop self to PE12. CE31 can attach a Mapping Community Color:0:100 on - this route, to indicate its request for Gold SLA. Or, PE11 can + this route, to indicate its request for Gold SLA. Or, PE12 can attach the same using locally configured policies. ++-- +jgs: I changed PE11 to PE12 above. Right? ++-- Consider, CE31 is getting VPN service from PE12. The RD:203.0.113.31 route is readvertised in AFI/SAFI 1/128 by PE12 with next hop self @@ -3712,6 +4027,10 @@ AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And LDP tunnels for best effort traffic. AS2 uses SRTE intra-domain tunnels between ASBR21 and PE21, and L-ISIS for best effort tunnels. ++-- +jgs: since I have no idea what L-ISIS is, I suggested in my earlier comments +that you gloss it. Possibly it also needs a reference? ++-- The networks have two Transport classes: Gold with Transport Class ID 100, Bronze with Transport Class ID 200. These transport classes are @@ -3775,12 +4094,21 @@ community Color:0:100, pointing to ASBR21_to_PE21_gold tunnel. This route is readvertised by ASBR21 on BGP session inside VRF with - next hop self. EBGP session peering on interface address. ASBR21 + next hop self. ++-- +jgs: I don't know what you mean by "BGP session inside VRF". ++-- + EBGP session peering on interface address. ++-- +jgs: That's a sentence fragment; I don't know what you mean by it so +I can't propose a rewrite. ++-- + ASBR21 acts like a CE to ASBR11, and the previously mentioned process repeats in AS1, until the route reaches PE11 and resolves over PE11_to_ASBR11_gold RSVP TE tunnel. - Traffic traverses as IP packet on the following legs: CE31-PE11, + Traffic traverses as unlabeled IP packets on the following legs: CE31-PE11, ASBR11-ASBR21, PE21-CE41. And uses MPLS forwarding inside AS1, AS2 core. @@ -3879,6 +4207,10 @@ ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them, and readvertise L3VPN routes with next hop self, allocating new labels. EBGP session peering on interface address. ++-- +jgs: That's a sentence fragment; I don't know what you mean by it so +I can't propose a rewrite. ++-- CE41 advertises a route for example prefix 203.0.113.41 with next hop self to PE22 VRF. CE41 can attach a Mapping Community Color:0:100 on @@ -3984,6 +4316,13 @@ existing deployments. Overloading RFC 8277 NLRI MPLS Label field with information related to non MPLS data plane leads to backward compatibility issues. ++-- +jgs: I generally think this appendix is very useful in providing a +conceptual framework for the reader to understand your design. However, +the final paragraph appears to be a leftover from the working group +debate, and seems out of place in the present document. I suggest +deleting it. ++-- C.1. Update packing considerations @@ -4006,7 +4345,15 @@ Tests were conducted with 1.9 million BGP CT route scale (387K endpoints in 5 transport classes). Initial convergence time for all - cases was less than 2 minutes, This experiment proves that carrying + cases was less than 2 minutes. This experiment proves that carrying ++-- +jgs: So... 2 minutes is good I guess? Say so, e.g. "which compares +favorably with __some baseline information__". + +The basic issue here is that this is an archival document. While it +may be obvious today that 2 minutes is good, the state of the art will +be different later. So the more context you can provide the better. ++-- transport class information as an attribute keeps BGP convergence within acceptable range. Details of the experiment and test results are available in BGP CT Update packing Test Results
- [Idr] AD review of draft-ietf-idr-bgp-ct-33 John Scudder
- [Idr] Re: AD review of draft-ietf-idr-bgp-ct-33 Kaliraj Vairavakkalai
- [Idr] Re: AD review of draft-ietf-idr-bgp-ct-33 John Scudder
- [Idr] Re: AD review of draft-ietf-idr-bgp-ct-33 Kaliraj Vairavakkalai
- [Idr] Re: AD review of draft-ietf-idr-bgp-ct-33 Kaliraj Vairavakkalai