Re: [Idr] Tsvart early review of draft-ietf-idr-bgp-car-05
Susan Hares <shares@ndzh.com> Wed, 17 January 2024 00:24 UTC
Return-Path: <shares@ndzh.com>
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 836BBC15171B; Tue, 16 Jan 2024 16:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 qM3tnoSZL3jl; Tue, 16 Jan 2024 16:24:24 -0800 (PST)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2063.outbound.protection.outlook.com [40.107.223.63]) (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 82C24C15155A; Tue, 16 Jan 2024 16:24:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UxaEt929ypmWrqzQs3wbhEfJ8yfth2Ij7IU62P0FFkAGpxi2GTKbhiiTp9ULPeOt7QCcWW4ZOE4oeB8b1b9E6/axIBpZVfz+p5Z08QNODJ36KqH/vOj3bITYDwmys1ZZtlehHsZU7JltPRSjLZO8ohZHTNGAiwFNDSOAqIn2m7ozmJn2jANgBFOOyB77/Ji+JGp25GNkBG1UOKtHOlWvDJthI+8E++t71IOkllHR4rKaL8PLCtUfY7Plv/1YIRnzmmjPp4uU2UAe+pxzXxboorGq5H6Wsol2jVS/qERLjM/+X7p9D6nYKNzqhbIFaF/3071CaiiyBIu3kYbL4Ijtbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=Y8b6PqyG7626CrMmyFo9EFAIUVYmjlho31NmtGm1yqQ=; b=R2LhydbCnWR75Z/wi1c1DLt24K34KYHQ/T4KNnKfEPmeIcfcdYed9TusqjLrmJXs5OajQEd76yjRT9xDSaUxe7+mtsnOM/5Vb3hCk1FgDb7WO3OYXeWgW7U3uwPYhk0lcOn8ILVQz8kGB6h7UKLH9lkH7qeOexjKBfOt/Rylgm49IHVGB+FiCtIRb0xhposs81z7H3O1134gjbOsm3Rpd7VTcPrXuQU0L4TPRC0gBJq93+JrB4XNzYgCoh/WaUmaCP3ZPov8YA1iVluhdp+LtTuQfnA2wAzu8BW5Nzhh0fwBgGJJVY0tpXsRokByYpkb+8RtAZBEVgic9SZAZXvtVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 104.47.70.101) smtp.rcpttodomain=ietf.org smtp.mailfrom=ndzh.com; dmarc=bestguesspass action=none header.from=ndzh.com; dkim=none (message not signed); arc=none (0)
Received: from BN0PR04CA0105.namprd04.prod.outlook.com (2603:10b6:408:ec::20) by CH3PR08MB9307.namprd08.prod.outlook.com (2603:10b6:610:1c3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.18; Wed, 17 Jan 2024 00:24:18 +0000
Received: from BN8NAM12FT042.eop-nam12.prod.protection.outlook.com (2603:10b6:408:ec:cafe::2) by BN0PR04CA0105.outlook.office365.com (2603:10b6:408:ec::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.23 via Frontend Transport; Wed, 17 Jan 2024 00:24:18 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 104.47.70.101) smtp.mailfrom=ndzh.com; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=ndzh.com;
Received-SPF: Pass (protection.outlook.com: domain of ndzh.com designates 104.47.70.101 as permitted sender) receiver=protection.outlook.com; client-ip=104.47.70.101; helo=NAM10-BN7-obe.outbound.protection.outlook.com; pr=C
Received: from obx-outbound.inkyphishfence.com (3.132.208.199) by BN8NAM12FT042.mail.protection.outlook.com (10.13.182.89) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7202.15 via Frontend Transport; Wed, 17 Jan 2024 00:24:18 +0000
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by obx-inbound.inkyphishfence.com (Postfix) with ESMTPS id 862AC104451; Wed, 17 Jan 2024 00:24:17 +0000 (UTC)
Received: from DM6PR08MB4857.namprd08.prod.outlook.com (2603:10b6:5:44::25) by DS0PR08MB8654.namprd08.prod.outlook.com (2603:10b6:8:158::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.17; Wed, 17 Jan 2024 00:24:14 +0000
Received: from DM6PR08MB4857.namprd08.prod.outlook.com ([fe80::572a:654:1f3a:59b4]) by DM6PR08MB4857.namprd08.prod.outlook.com ([fe80::572a:654:1f3a:59b4%6]) with mapi id 15.20.7202.020; Wed, 17 Jan 2024 00:24:13 +0000
From: Susan Hares <shares@ndzh.com>
To: Brian Trammell <ietf@trammell.ch>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-idr-bgp-car.all@ietf.org" <draft-ietf-idr-bgp-car.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Tsvart early review of draft-ietf-idr-bgp-car-05
Thread-Index: AQHaSFUI6HiXQuTB20ejF12ieldZBrDdDYKw
Date: Wed, 17 Jan 2024 00:24:13 +0000
Message-ID: <DM6PR08MB48579467108BC89DE0901BA9B3722@DM6PR08MB4857.namprd08.prod.outlook.com>
References: <170539329098.25883.11062658925031540635@ietfa.amsl.com>
In-Reply-To: <170539329098.25883.11062658925031540635@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-traffictypediagnostic: DM6PR08MB4857:EE_|DS0PR08MB8654:EE_|BN8NAM12FT042:EE_|CH3PR08MB9307:EE_
X-MS-Office365-Filtering-Correlation-Id: ba98c5fd-0600-4506-db96-08dc16f2a4cf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: NmmG9mtwm71/qtIbNRYMRbnCGaBI8+p5V13uQDEatjUcwg7tXE6r7usEE5vX/VJgpVTogwP0Hdz4cx3H/pWERlRgb+waXxRolHI1vIOf9CH2B5YvguSQSge4vn7XUWJikcNyDrGUJZ/js5ZNnFtcARCcVoeeSezApJI5KlxkUu8i4AzbTzdFqZP4gjAQlXDSIYnc4YfEOEoKKZ75hwGNKdkvM9Byv3PJMJ1DB7wGMfKipm/H7ibK5fH6HyxRxdlZ0FHfQHbwjoKYxYMmOXjPvs1IEIRBBJWfP9rqBkJizBP4hvwHnxo+8qbz5qy4MkHeeYNBtI4xBTyQ+6Aj86RSiT9sclGyKTeI1JFkLVC0JJt9jwhRDyQ80KDTURjrIZTriRUO4ZY1yCI5mqES2BM2dBBwzrhXuLxIgadd5kU/1uOVttLeN/kMfhxdXL17C5NwTKN3vny1lTZ8Q7Sg7KBJ4f3Qc6ebC+QlUGpS2Bg85wR36X+ybrTp3z+AMsv6inJqUZ0hWrgzALlrJCbyF6V+66cEpKkA1aOzHcGNwLiyLDwOV2Qs7+/KYCk0Uh/8uB/7f0fZbSRXV1IRMwdtzbPbmVO/VJgchZDj7j5VZekLzyUd4vIJXvI/7JKFiFV23rsga39GyeB+PACkP/C+5sZMTHPAixUS0dkaQFPUb2g615HtxYG6aLnSbvWtmv69nCPLBRGNixKifROWp9+bvAAxRw==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB4857.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39830400003)(346002)(366004)(376002)(396003)(136003)(230473577357003)(230373577357003)(230273577357003)(230173577357003)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(478600001)(33656002)(8936002)(8676002)(5660300002)(76116006)(64756008)(66446008)(66556008)(66946007)(2906002)(66476007)(26005)(66574015)(71200400001)(110136005)(83380400001)(86362001)(54906003)(316002)(41300700001)(9686003)(6506007)(53546011)(38100700002)(7696005)(122000001)(4326008)(55016003)(52536014)(38070700009)(166002); DIR:OUT; SFP:1101;
Content-Type: multipart/alternative; boundary="_000_DM6PR08MB48579467108BC89DE0901BA9B3722DM6PR08MB4857namp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR08MB8654
X-Inky-Outbound-Processed: True
X-EOPAttributedMessage: 0
X-MS-Exchange-SkipListedInternetSender: ip=[104.47.70.101]; domain=NAM10-BN7-obe.outbound.protection.outlook.com
X-MS-Exchange-ExternalOriginalInternetSender: ip=[104.47.70.101]; domain=NAM10-BN7-obe.outbound.protection.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN8NAM12FT042.eop-nam12.prod.protection.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs: 77bbfae5-fbc1-4275-2b0a-08dc16f2a239
X-IPW-GroupMember: False
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: CO0tWtxyTORuf05TuEyeLMlpTg56SHZXoHqym/8oha6VK4snk1VbTE5xtx2lGtV5DG6hLHITaW3jyCXQo06iEjrkbUKnEzJimHXKxLA5du3EHbBhkP60UvjWx+29hj17dPVUe31fcL4P+8Q2Kfd6sQIL/LPym4zhYJObo9cj/MQDVBUNDZ9IoBIsAaeK+pa0Pw5Hx5xxONghMVwbofbcRIStSw0W2eQUL+i7IM7zpnbtasr0FE5V3HGyGn1Cfk0wkiuWPumgsBDsx+6IvKWgJP7Fcwzag7M6eKKNW1dMeKC47ktnudmKKsnsuFMe5ovrrXk6NdLWukaCQ5PLk58DAckKv9UB2Zx0Kyrv5hXsHSxx+zGcjrX89KFl/scOnjK0xtsiOCvZeXDJWi6chSDST1u/FnCwHsgiG77TXvD95+lb025myKFnaMBh+ZtU3PEfU4O12K1WWDIloGqjZpm/dN4EvwRAk+dFKNkjOIlQi+Lj9kwQkK+sU/oGCbGmkfXMAbnkOK3wDQKSC0bKxgRMOkjaKiDCP+6XdKI7HdN9MDGj+9Ba/cFuoDacovU0klEYkO8PUSNpiDDox0fKJ/M2nwxrx10JivzekTvVaXP+hW8Rjv0upty5F2qdXtYdZA7RjFf3lIi6BbKxj+GV/hbi9OZeiCecoOnmQgRJL/i9cOlXwaBmrxbzbfoIW4fe4LW+/Tu/xSpSmcXlhkosJKJy2uBzkYt/8HRW5drg+YdG/eH/8WjgyNXTuR1riFZrNeJWafTv9HEiqEr+1JSnP6bM0ie8McE11m2CriLj9j90wEoa2Kgs8/1hiTRmaJ6WLh6mY1bWnC+t8Fm8hqy3CrEwndVh2NtUtS5uuLXv74eWN7Qkp8qjwHzQyLxKeqRwhpYZ6eXOs8yJ1HBzDW6OxoaHRKqfMmvkeB7ps9VWDcPfTy1sc0E6q6pRQNojlL48drko
X-Forefront-Antispam-Report: CIP:3.132.208.199; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:NAM10-BN7-obe.outbound.protection.outlook.com; PTR:mail-bn7nam10lp2101.outbound.protection.outlook.com; CAT:NONE; SFS:(13230031)(39830400003)(376002)(346002)(136003)(396003)(230473577357003)(230173577357003)(230373577357003)(230273577357003)(230922051799003)(186009)(451199024)(1800799012)(64100799003)(82310400011)(46966006)(36840700001)(478600001)(26005)(7636003)(7696005)(6506007)(66574015)(336012)(53546011)(9686003)(86362001)(5660300002)(36860700001)(32850700003)(156005)(83380400001)(47076005)(30864003)(4326008)(2906002)(41300700001)(52536014)(110136005)(70206006)(8676002)(54906003)(316002)(8936002)(70586007)(33656002)(55016003)(40480700001); DIR:OUT; SFP:1101;
X-OriginatorOrg: ndzh.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2024 00:24:18.2125 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ba98c5fd-0600-4506-db96-08dc16f2a4cf
X-MS-Exchange-CrossTenant-Id: d6c573f1-34ce-4e5a-8411-94cc752db3e5
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d6c573f1-34ce-4e5a-8411-94cc752db3e5; Ip=[3.132.208.199]; Helo=[obx-outbound.inkyphishfence.com]
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT042.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR08MB9307
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DBSoQV-ztqLyaZjv7ATMVoJJEaw>
Subject: Re: [Idr] Tsvart early review of draft-ietf-idr-bgp-car-05
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 00:24:28 -0000
Brian: Thank you for your careful review on the architecture. What is necessary for transport to understand is the attempt for the network to provide a "smarter" traffic forwarding through the network based on Intent. What we needed was tips from Transport Review was: 1. Whether the document was clear - 2. What it might want or expect from a "smarter" (intent) network. I appreciate your comments on where the document is unclear. As the shepherd, I will work with the authors to refine the document. If you have any comments on what transport might want or expected from a "smarter" (intent) network flow. Below I provide you with a few comments that may help other TSV reviewers. Sue Hares ======== A few comments Your comments on, O (N**2) mapping for Color domains where a color domain is limited by configuration. The color domain can be limited by configuration as: 1. an IGP domains within a single AS, or 2. a group of ASes. The color mappings may map via configuration (Color blue in AS-1 = Color green AS-2 = low delay) [Per sections 2.5 and 2.8]. Or the color mappings may use an Extended BGP community (LCM) (section 2.10) This proposal suggests the following two variant of routes 1. Color + NLRI + optional TLVs 2. NLRI + BGP communities Attaching BGP communities (normal, extended, large, and wide) is not new. The mechanisms for handling color aware routing are. Color aware routing attempts to group traffic entering networks by Intent. The "head end" routers steer traffic into forwarding paths. The traffic can either be "user traffic" (service traffic) or transport pathway (groups of service traffic). Spring has been working on a draft to set requirements [draft-hr-spring-intentaware-routing-using color], but discussion abounds. Just for your reference, RFC9315 (IRTF) provides some background on Intent Routing. Let me go through 3 terms from RFC9315 in case this might help you refine some of your comments. * Intent routing - is a high level operational goal of traffic forwarding - at the level of network services to pass "Transport" level traffic [ * Policy Routing - defines specific polices within routing or forwarding. * Service model - is a high level data model From: Brian Trammell via Datatracker <noreply@ietf.org> Sent: Tuesday, January 16, 2024 3:22 AM To: tsv-art@ietf.org Cc: draft-ietf-idr-bgp-car.all@ietf.org; idr@ietf.org Subject: Tsvart early review of draft-ietf-idr-bgp-car-05 Reviewer: Brian Trammell Review result: On the Right Track tl;dr: okay for TSV, because it's orthogonal to transport concerns as long as the colors aren't defined, or assumed to be definable across do External (noreply@ietf.org<mailto:noreply@ietf.org>) Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzBlMTYxNGVkNzMxOGUwNTM0MTkyZTE0NzljMTEyOWZmLzE3MDUzOTMyOTcuMQ==#key=9e4654bacd8ef00b9b5949573cade586> FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813> GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky> Reviewer: Brian Trammell Review result: On the Right Track tl;dr: okay for TSV, because it's orthogonal to transport concerns as long as the colors aren't defined, or assumed to be definable across domains. I have concerns about the document's scope, though, or rather how it's framed. See inside for details. Note: I've reviewed this document with two hats: - as TSVART reviewer looking specifically for issues in the interaction between the routing architecture and layer 4. - as someone interested in path-aware networking evaluating CAR + SR as a related technology in a slightly different paradigm. Brian's standard RTG disclaimer: I have specifically *not* evaluated this document for consistency with the idioms of BGP or IDR; I assume the IDR working group has done that. Routing area terminology is mostly disjoint from higher-layer terminology (case in point: "transport"), and the documents I review from the routing area consistently assume a fairly deep grounding in the idioms of that community, so it's entirely possible that I'm missing things in this review, because this document is not written in a language in which I have any proficiency at all. That is a separate issue, but not one I expect the authors of this document to solve. :) I'll reply with my second hat first, because the main architectural issue with respect to path awareness presented by this document is the basis of any concern I'd have as a transport reviewer. And I'll start with the positive: yay! Though the assumptions made in the application of SR to interdomain deployments and those made in path-aware networking space (which relaxes assumptions about who owns the endpoints, and explicitly foresees path information, here "color" information, exposed up the stack) are a bit different, this looks like a thoroughly workable technology for realizing path-aware interdomain networking between routers, which admittedly has a much easier deployment and operational model, being mostly congruent with the Way Things Are Done today (see RFC 9217 sections 2.7-2.8). That said, I started off deeply confused about how this is actually supposed to work in an interdomain context. The document starts out in section 1.1 by pointing out that "color" is a uint32_t (bonus points to any router vendor that *actually* parses this as an RGBA value and shows it to the network engineer as such!) mapped to some intent, defined in RFC 9256. "Color" isn't actually defined in RFC 9256, except as a uint32_t associated with some intent, so I was left with some confusion about how a color value actually selects some queueing strategy or other treatment that would be application-, transport-, or network-engineering relevant. I then stumbled across "Color Domain", which is practically going to be more or less coterminous with an administrative domain. In other words, this document talks about mechanism, leaving policy to local preference and/or future work. Section 2.8 makes this clear by assuming (in language that, apropos of nothing, reads somewhat like marketing to me) that "[t]he BGP CAR solution seemlessly supports this rare scenario" (that a CAR route crosses color domain boundaries), by... requiring color-rewriting gateways. :( In other words, the deployment of CAR in an interdomain environment relies either on: (1) An O(n^2) provider-pair mapping of color domains translated at each gateway between domains. (2) A set of color domains larger than an administrative domain through which a set of operators agree on some values for color (I believe, without much evidence as I don't follow the space, that a similar thing is already happening with communities centered around certain IXPs); (2a) probably with an emergence of the structuring of the color numberspace so that interdomain translations can ignore the less/more significant bits and concentrate on a lingua-franca "mask" that mostly means the same thing in most places. This seems to be at odds to me with the language in section 11, which assumes cross-domain color coordination isn't all that important because color is scoped to IP prefix, and therefore lack of color remapping doesn't lead to availability issues. "Adding this feature where it isn't supported across a domain boundary doesn't break routing", while being minimally acceptable for the deployability of the protocol, also isn't particularly ambitious. To be clear, this is all perfectly fine. Leaving this document as a specification of mechanism (the easy part IMO) and leave the specification of policy (the hard part IMO) to be either future standardization work, or to emerge from collections of operators that realize value from this feature and want it to work across a peering point, leading to a de-facto standard (if at all), is a reasonable plan for protocol transition (see RFC8170). But, editorially, I'd rather see some language in the abstract/introduction that makes it clear that this is the intent, because as I read the abstract, the document promises something it's only delivering the easy half of. With my transport (RTG folk: this means "layer 4") hat on, since it's the *semantics* of the treatments specified by the colors allowed to be attached to routes by BGP CAR that are evaluable from a TSV standpoint, the details of how these colors are defined and implemented determine whether a given deployment of BGP CAR is problematic or unproblematic for the transport protocols, this document is both fine and not fine from a transport standpoint. I suppose as long as networks don't, for example, define colors specifically for gratuitous violations of RFC 8085 (and why would they?), this document is OK for transport.
- [Idr] Tsvart early review of draft-ietf-idr-bgp-c… Brian Trammell via Datatracker
- Re: [Idr] Tsvart early review of draft-ietf-idr-b… Susan Hares
- Re: [Idr] Tsvart early review of draft-ietf-idr-b… Brian Trammell (IETF)