RE: RtgDir Early review: draft-ietf-rtgwg-atn-bgp-12.txt

[Mach Chen <[e-mail]>]

Great, thanks for considering my comments!

Best regards,
Mach

> -----Original Message-----
> From: Templin (US), Fred L [mailto:[e-mail]]
> Sent: Tuesday, February 8, 2022 12:26 AM
> To: Mach Chen <[e-mail]>; Mach Chen
> <mach.chen=[e-mail]>; rtgwg-chairs
> <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: Monday, February 07, 2022 2:01 AM
> > To: Templin (US), Fred L <[e-mail]>; Mach Chen
> > <mach.chen=[e-mail]>; rtgwg-chairs <rtgwg-
> > [e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail]] On Behalf Of Templin
> > > (US), Fred L
> > > Sent: Tuesday, February 1, 2022 1:44 AM
> > > To: Mach Chen <mach.chen=[e-mail]>;
> rtgwg-chairs
> > > <[e-mail]>; [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > 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:[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?
> >
> > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/rtgwg