Re: [RTG-DIR] RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt

Mach Chen <mach.chen@huawei.com> Mon, 07 February 2022 10:01 UTC

Return-Path: <mach.chen@huawei.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 798573A0C69; Mon, 7 Feb 2022 02:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 bxi1O8IwBt2O; Mon, 7 Feb 2022 02:01:33 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4B23A0C66; Mon, 7 Feb 2022 02:01:33 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JshQH0N9sz67vYh; Mon, 7 Feb 2022 17:57:27 +0800 (CST)
Received: from dggpemm500001.china.huawei.com (7.185.36.107) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 11:01:28 +0100
Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 18:01:26 +0800
Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2308.021; Mon, 7 Feb 2022 18:01:26 +0800
From: Mach Chen <mach.chen@huawei.com>
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" <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: AdgUGaclNnx9glFRQ9uqIS9oANN5iwCqU6YQAVDADeA=
Date: Mon, 07 Feb 2022 10:01:26 +0000
Message-ID: <1db27e3a80b2470c8ba2d9b918fdad91@huawei.com>
References: <362122501e5e4135a870c9d4cf7b9f7d@huawei.com> <c4262281fa2e4e1cb474bc0caab13c84@boeing.com>
In-Reply-To: <c4262281fa2e4e1cb474bc0caab13c84@boeing.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.110.46.250]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/jCzDIohBnMAbp4xo9CyFikc4xbs>
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 10:01:39 -0000

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