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. 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? 4. Section 3, s/each s-ASBRs/each s-ASBR 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. 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. 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. 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? Best regards, Mach _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
