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

["Templin (US), Fred L" <[e-mail]>]

Mach, thank you very much for this helpful pre-review and see below for follow-up:

Fred

> -----Original Message-----
> From: rtgwg [mailto:[e-mail]] On Behalf Of Mach Chen
> Sent: Friday, January 28, 2022 2:07 AM
> To: rtgwg-chairs <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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?

> 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."

> 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.

> 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?

> 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)."

> 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.

> Best regards,
> Mach
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg