Great, thanks for considering my comments! Best regards, Mach
> -----Original Message----- > From: Templin (US), Fred L [mailto:[email protected]] > Sent: Tuesday, February 8, 2022 12:26 AM > To: Mach Chen <[email protected]>; Mach Chen > <[email protected]>; rtgwg-chairs > <[email protected]>; [email protected] > Cc: [email protected]; [email protected] > Subject: RE: RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt > > 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:[email protected]] > > Sent: Monday, February 07, 2022 2:01 AM > > To: Templin (US), Fred L <[email protected]>; Mach Chen > > <[email protected]>; rtgwg-chairs <rtgwg- > > [email protected]>; [email protected] > > Cc: [email protected]; [email protected] > > 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:[email protected]] On Behalf Of Templin > > > (US), Fred L > > > Sent: Tuesday, February 1, 2022 1:44 AM > > > To: Mach Chen <[email protected]>; > rtgwg-chairs > > > <[email protected]>; [email protected] > > > Cc: [email protected]; [email protected] > > > 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:[email protected]] On Behalf Of Mach Chen > > > > Sent: Friday, January 28, 2022 2:07 AM > > > > To: rtgwg-chairs <[email protected]>; > > > > [email protected] > > > > Cc: [email protected]; [email protected] > > > > 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
