Skip to main content

Early Review of draft-ietf-idr-ls-trill-01
review-ietf-idr-ls-trill-01-rtgdir-early-callon-2016-06-22-00

Request Review of draft-ietf-idr-ls-trill
Requested revision No specific revision (document currently at 05)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-06-22
Requested 2016-06-06
Authors Donald E. Eastlake 3rd , Hao Weiguo , Yizhou Li , Sujay Gupta , Muhammad Durrani
I-D last updated 2016-06-22
Completed reviews Rtgdir Early review of -01 by Ross Callon (diff)
Assignment Reviewer Ross Callon
State Completed
Request Early review on draft-ietf-idr-ls-trill by Routing Area Directorate Assigned
Reviewed revision 01 (document currently at 05)
Result Has nits
Completed 2016-06-22
review-ietf-idr-ls-trill-01-rtgdir-early-callon-2016-06-22-00

I have been selected as the QA reviewer for draft-ietf-idr-ls-trill-01.txt. For
more information about the Routing Directorate, please see

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Summary:



I think that this draft is straightforward and well written. I have only a
couple of questions and some very minor nits.



I can see situations in which putting TRILL information into BGP may make
sense, particularly in the case of providing TRILL information to a SDN
controller as pointed out in the draft. Due to the close relationship of this
draft to the work in TRILL I have CC’d the TRILL working group on this review
and I assume that the TRILL working group will similarly be informed when the
document goes to WGLC.





Questions:



Section 1, second to last paragraph states:



   If ESADI (End Station Address Distribution Information) protocol

   [RFC7357] is used for control plane MAC learning in each data center,

   BGP LS also can be used for MAC address reachability information

   synchronization across multiple TRILL domains.  End-to-end unicast

   forwarding paths can be calculated based on the synchronized

   information.



Would this be limited to the case where routes are computed by SDN controllers?
I am thinking that if instead the MAC reachability from one data center is
passed via BGP and fed back into TRILL in a different data center then this
would lead to significant issues which have not been discussed in this document.





Section 5 (security considerations) states:



   Procedures and protocol extensions defined in this document do not

   affect the BGP security model.  See [RFC6952] for details.



I am not a TRILL expert and therefore might not fully understand all cases in
which TRILL is used. I am however wondering if there are TRILL-specific issues
in that the TRILL information must only be passed to TRILL capable devices. I
am also wondering whether there is any valid use of “TRILL in BGP” other than
passing TRILL information to SDN controllers. Passing TRILL information from
one TRILL domain to another TRILL domain and then redistributing the
information back into normal TRILL packets seems like a bad idea at first
glance. I am wondering if this section should say something like “this protocol
MUST be used ONLY for passing TRILL information from TRILL devices to SDN
controllers, and for passing TRILL information between SDN controllers.





Very minor nits:



Section 2 defines the RFC2119 terms and abbreviations used in this document in
the same section with no subsections. I think that it is more normal to have a
subsection for RFC 2119 terms and a different subsection for abbreviations used
in this document.



Section 3, first paragraph, last sentence: “…multicast group address, and 
etc.” should be “…multicast group address, etc.”.



Section 3.1, “iS-IS” should be “IS-IS”.



Section 4, second paragraph, I thought that it was a bit odd for a document to
reference itself, as in “An implementation of this specification[idr-ls-trill],
MUST do…”. Would this be a bit less awkward as: “Any implementation of the
protocol in this specification (ie that distributes TRILL Link-State
information using BGP), MUST do…”.





That is all that I found in a couple of readings of this document,

Thanks, Ross