Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 07 February 2022 16:26 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC893A0DEA; Mon, 7 Feb 2022 08:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK4Z-AuoifU1; Mon, 7 Feb 2022 08:26:27 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 CF38C3A0D93; Mon, 7 Feb 2022 08:26:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 217GQMI1013890; Mon, 7 Feb 2022 11:26:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1644251185; bh=Lz8lkQywIRGOaBpMpKlxTFBJMD0vVklymchDxfGN5IM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=U1/UsubJU3mCpj86fXR680eO9iT1f+QD77gE3ZeXjbY6EEYQJqlp+UY8OIzY31Pmb oN4dBei/RyXoChSFoX7PukB/jwN1TgLF0rDmvdQ2srJKHWGRvXni9Nl8yzU34q8WqW KGOnwv+7X67evcJ6UBNOdNn0Q9fImIcPcxWCBWoyWdDiNfqoBjjsQT3jiOxQKyEzRe eVMtaBs2Py5AGc8UCOBeEE/mkTdrH/PZDOoAL/leciUmuAsexn5J8doTyNwa0iGNcB kYzaxpeFRURBUu/u3wqFYLhs9wkTKEwKJ8hZaDlABCoqTz1zycTeArzU+/xxf0nkWo 9O2XoSKHy+Sng==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 217GQENi013778 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 7 Feb 2022 11:26:15 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Mon, 7 Feb 2022 08:26:12 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2375.018; Mon, 7 Feb 2022 08:26:12 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Mach Chen <mach.chen@huawei.com>, Mach Chen <mach.chen=40huawei.com@dmarc.ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, "draft-ietf-rtgwg-atn-bgp.all@ietf.org" <draft-ietf-rtgwg-atn-bgp.all@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt
Thread-Index: AdgUGaclNnx9glFRQ9uqIS9oANN5iwCqU6YQAVDADeAADkoe4A==
Date: Mon, 07 Feb 2022 16:26:12 +0000
Message-ID: <3a38a33f776a4f789cfd7c47859a4cee@boeing.com>
References: <362122501e5e4135a870c9d4cf7b9f7d@huawei.com> <c4262281fa2e4e1cb474bc0caab13c84@boeing.com> <1db27e3a80b2470c8ba2d9b918fdad91@huawei.com>
In-Reply-To: <1db27e3a80b2470c8ba2d9b918fdad91@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 6EFA43EF2DDF490FE0590E92D77D62B24D959ACCA4455322FB33232D7F244D1B2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/fZEcVkfOHXazKHX4GOds_178gHw>
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 16:26:43 -0000
Mach, thanks for these clarifications; I am good with everything you said. One point however is that there may be cases when a c-ASBR has a default route or a shorter prefix that completely covers a (longer) MSP. I think the text you offered would be compatible with those cases. Regards - Fred > -----Original Message----- > From: Mach Chen [mailto:mach.chen@huawei.com] > Sent: Monday, February 07, 2022 2:01 AM > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Mach Chen <mach.chen=40huawei.com@dmarc.ietf.org>; rtgwg-chairs <rtgwg- > chairs@ietf.org>; draft-ietf-rtgwg-atn-bgp.all@ietf.org > Cc: rtg-dir@ietf.org; rtgwg@ietf.org > Subject: [EXTERNAL] RE: RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt > > EXT email: be mindful of links/attachments. > > > > Hi Fred, > > Some responses inline... > > > -----Original Message----- > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Templin (US), > > Fred L > > Sent: Tuesday, February 1, 2022 1:44 AM > > To: Mach Chen <mach.chen=40huawei.com@dmarc.ietf.org>; rtgwg-chairs > > <rtgwg-chairs@ietf.org>; draft-ietf-rtgwg-atn-bgp.all@ietf.org > > Cc: rtg-dir@ietf.org; rtgwg@ietf.org > > Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt > > > > Mach, thank you very much for this helpful pre-review and see below for > > follow-up: > > > > Fred > > > > > -----Original Message----- > > > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Mach Chen > > > Sent: Friday, January 28, 2022 2:07 AM > > > To: rtgwg-chairs <rtgwg-chairs@ietf.org>; > > > draft-ietf-rtgwg-atn-bgp.all@ietf.org > > > Cc: rtg-dir@ietf.org; rtgwg@ietf.org > > > Subject: RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt > > > > > > Hello > > > > > > I have been selected to do a routing directorate “early” review of this > > draft. > > > https://datatracker.ietf.org/doc/ draft-ietf-rtgwg-atn-bgp-12/ > > > > > > The routing directorate will, on request from the working group chair, > > > perform an “early” review of a draft before it is submitted for > > > publication to the IESG. The early review can be performed at any time > > during the draft’s lifetime as a working group document. The purpose of the > > early review depends on the stage that the document has reached. > > > > > > As this document is going to be in working group last call, my focus > > > for the review was to determine whether the document is ready to be > > published. Please consider my comments along with the other working group > > last call comments. > > > > > > For more information about the Routing Directorate, please see > > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > > > Document: draft-ietf-rtgwg-atn-bgp-12.txt > > > Reviewer: Mach Chen > > > Review Date: 2022/1/28 > > > Intended Status: Informational > > > > > > Summary: > > > > > > This document is basically ready for publication, but has nits that should be > > considered prior to being submitted to the IESG.. > > > > > > Comments: > > > > > > 1. Section 2, > > > "OAL Autonomous System", no places in this document refer to the term, > > if there is no use, it should be removed.. > > > > > > 2. Section 2, > > > Core Autonomous System > > > The "hub" autonomous system maintained by all c-ASBRs within > > the > > > same partition. > > > I have difficult to understand the above definition, need some > > > clarification text if the term is desired. BTW, I found that this term > > > is only used for definition of "OAL Autonomous System", given that "OAL > > Autonomous System" is not used in the document, the simplest solution is > > to remove this term as well. > > > > The terms "OAL AS", "Core AS" and "Stub AS" are used throughout the > > document and are needed to set the proper context. Would it help if I were > > to add the abbreviations (OAL AS, Core AS and Stub AS) to the respective "* > > Autonomous System" definitions? > > Yes, indeed. > > > > > > 3. Section 3, > > > "...The overlay does not > > > interact with the underlying INET BGP routing systems, and only a > > > small and unchanging set of MSPs are advertised externally instead of > > > the full dynamically changing set of MNPs." > > > > > > The front part says that there is no interaction with the underlying > > > INET BGP routing system, the second half say there may be some MSPs > > advertised between the two, seems it's self-contradictory? > > > > How does this sound for a rewrite: > > > > "...The ATN/IPS routing system interacts with underlying INET BGP routing > > systems only through the static advertisement of a small and unchanging set > > of MSPs instead of the full dynamically changing set of MNPs." > > Looks good to me. > > > > > > 4. Section 3, > > > s/each s-ASBRs/each s-ASBR > > > > Agreed. > > > > > 5. Section 3, > > > "Since the BGP instance does not > > > connect with any INET BGP routing systems, the ASNs assigned need > > not > > > be coordinated with IANA and can in fact coincide with values that > > > are assigned in other domains. The only requirement is that ASNs > > > must not be duplicated within the ATN/IPS routing system itself." > > > Why not just use the private ASNs? It will avoid potential conflicts with the > > Internet ASNs. > > > > Indeed. When this text was written, I was working under the limiting > > assumption that only 1023 16-bit AS numbers were reserved for private use > > which is far fewer than may be needed in some large deployments. > > But, I did not know about RFC6996 which reserves 94,967,295 32-bit AS > > numbers for private use which would seem to satisfy most deployments. > > So, the proposed resolution is to cite RFC6996 and recommend (but not > > mandate) private use 32-bit AS numbers. The reason to "not mandate" > > is that enormous deployments could theoretically exhaust even the 32-bit > > private AS number space. > > OK. > > > > > > 6. Section 3, para 5, > > > "Each c-ASBR configures a black-hole route for each of its MSPs. By > > > black-holing the MSPs, the c-ASBR will maintain forwarding table > > > entries only for the MNP-ULAs that are currently active, and packets > > > destined to all other MNP-ULAs will correctly incur ICMPv6 > > > Destination Unreachable messages [RFC4443] due to the black hole > > > route." > > > In my understanding, the black-hole route will cause the packets > > > (without matching a specific MNP-ULA) to be dropped silently, and no > > > ICMPv6 Destination Unreachable message will be incurred. Seems that the > > black-hole route does not satisfy your requirement. > > > > This may require a bit more explanation. The requirement is for a c-ASBR that > > lacks a MNP route matching a packet's destination address to drop the > > packet and return an ICMPv6 Destination Unreachable. However, if there > > were no black-hole MSP route, the packet could escape from the domain via > > a less-specific route (e.g., "default") where it might be again injected back > > into the overlay routing system and kicked back out by a default route ad > > infinitum. So, black-holing the MSPs seems to be necessary, but how to make > > the behavior of "drop and send ICMP" > > based on matching the MSP is the question. Any suggestions? > > Unless there are some scenarios that require the c-ASBR to install a default. In my understanding, the c-ASBR does not have to maintain any > default route, only the s-ASBR does. With this, the c-ASBR will drop the packet without matching a MNP and an ICMPv6 Destination > Unreachable will be generated accordingly. > > Or maybe: > "Each c-ASBR configures a black-hole route for each of its MSPs. By > black-holing the MSPs, the c-ASBR will maintain forwarding table > entries only for the MNP-ULAs that are currently active, and packets > destined to all other MNP-ULAs will silently be dropped due to the black hole route, and a corresponding log will be recorded for this > event." > > > > > 6. Section 4, para 6 > > > "The s-ASBR's stub AS therefore > > > consists of the set of all of its active Clients (i.e., the stub AS > > > is a logical construct and not a physical construct)." > > > From the BGP point of view, an AS is consisted of the routers that are > > > running BGP protocol, the Clients are actually outside the AS and not > > belong to the AS, unless the Clients or Proxy servers peer with the s-ASBR. > > > > OK, thanks for this. How does this look for a rewrite: > > > > "The s-ASBR's stub AS is therefore used only to advertise the set of MNPs of > > all its active Clients and not to peer with other BGP routers (i.e., the stub AS > > is a logical construct and not a physical one)." > > Maybe this? > "The s-ASBR's stub AS is therefore used only to advertise the set of MNPs of > all its active Clients and not to peer with other BGP routers, the stub AS is a logical construct and not a physical one." > > > > > > 7. Section 5, > > > In Figure 4/5, is the P/S a s-ASBR? If so, it's better to add some > > > text to make it clearer. If not, how does P/S-1 know a packet should be sent > > directly to P/S-2 instead to s-ASBR1? > > > > Yes, all P/S's are also s-ASBRs and serve a subset of the Clients in the system. > > However, each Client 'A' that uses P/S 'B' as its s-ASBR could also have links > > that connect through P/S's 'C', 'D', 'E', etc. Then, from the perspective of 'A', > > only 'B' is the s-ASBR and all others are simple P/S's which coordinate with > > the s-ASBR on 'A's behalf. > > > > The name "Proxy/Server" is intentionally chosen to show this duality of > > function - the "P/S" in some instances acts as a simple Proxy and in other > > instances acts as a Server (i.e., as a s-ASBR). > > > > I will see if I can add some text throughout the document that would make > > this point clearer. > > Great! > > Best regards, > Mach > > > > > Best regards, > > > Mach > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg
- [RTG-DIR] RtgDir Early review: draft-ietf-rtgwg-a… Mach Chen
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtg… Templin (US), Fred L
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtg… Mach Chen
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtg… Templin (US), Fred L
- Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtg… Mach Chen