Skip to main content

Early Review of draft-ietf-rtgwg-atn-bgp-12
review-ietf-rtgwg-atn-bgp-12-intdir-early-thaler-2022-01-31-00

Request Review of draft-ietf-rtgwg-atn-bgp-12
Requested revision 12 (document currently at 26)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2022-02-11
Requested 2022-01-13
Requested by Yingzhen Qu
Authors Fred Templin , Greg Saccone , Gaurav Dawra , Acee Lindem , Victor Moreno
I-D last updated 2022-01-31
Completed reviews Secdir Early review of -12 by Russ Housley (diff)
Intdir Early review of -12 by Dave Thaler (diff)
Opsdir Early review of -12 by Gyan Mishra (diff)
Rtgdir Early review of -12 by Mach Chen (diff)
Tsvart Early review of -13 by Michael Tüxen (diff)
Comments
The document is ready for WG last call in RTGWG. The chairs would really appreciate broader review of the document. Thanks!
Assignment Reviewer Dave Thaler
State Completed
Request Early review on draft-ietf-rtgwg-atn-bgp by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/mJtL9OD5lLohfk_bUPfJFJf1LvQ
Reviewed revision 12 (document currently at 26)
Result On the Right Track
Completed 2022-01-31
review-ietf-rtgwg-atn-bgp-12-intdir-early-thaler-2022-01-31-00
I am an assigned INT directorate reviewer for draft-ietf-rtgwg-atn-bgp-12.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

This was a requested "early review" so not surprisingly needs some additional
work before being done.

Technical Issues:
1) Section 3 explains that ASNs need not be coordinated with IANA since they're
used in a separate BGP routing instance, but they still have to be unique
within the ATN/IPS routing system.   However, no explanation is provided about
how to ensure such uniqueness.   Who coordinates them then, to ensure that are
unique?   In my view, this has to be solved before the document could be used.
2) Page 13 mentions that selection of a network-based s-ASBR could be done via
any of several mechanisms, but there are no references provided and it seems
that those mechanisms would require a specification as interoperability would
be required. 3) Top of page 14 talks about "registering" addresses, but I
couldn't tell what protocol it was referring to or where such addresses would
be registered.  Clarify. 4) AERO and OMNI are listed as informative references
but are used in text as if they are normative, not merely examples.   That is,
as phrased the document seems to only be useful in an AERO/OMNI context.  Is it
really specific to those or could other things (maybe RFC 5213 or whatever
else) be used instead?  If the intent is to keep them as informative
references, then either they should be used only as examples or they should be
moved to be normative references.  Of course normative references from an IETF
document to (currently) non-IETF drafts would be something that the RTGWG may
want to carefully consider.

Editorial comments:
* Page 4 would be a lot easier to understand if there were a high level
topology diagram there. * See
https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-ietf-rtgwg-atn-bgp-12-DthalerReview.pdf
for full review with above, and other editorial, comments in context.