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

[Mach Chen <[e-mail]>]

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