Hi Ben, Thanks for your review. It appears that is was not responded to in a timely fashion. Apologies on behalf of the authors.
(Your review was of the -02 version. The current version is -05.) On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins <b...@niven-jenkins.co.uk> wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > > Document: draft-ietf-trill-directory-assisted-encap-02.txt > Reviewer: Ben Niven-Jenkins > Review Date: 21 April 2016 > Intended Status: Proposed Standard > > Summary: > I have significant concerns about this document and recommend that > the Routing ADs discuss these issues further with the authors. Hopefully the changes made between the version -02 you reviewed and the current -05 have made some improvements and, based on your comments and WG LC comments, further improvements can be made. > Comments: > Overall this is not the easiest document to read although some of > that might be due to my lack of background in TRILL and its > terminology. > > Major Issues: > > 1) The document has an Intended Status of Proposed Standard, however > it does not contain any RFC2119 keywords and does not seem to make > any normative statements about required behaviour which I would have > expected in a Proposed Standard. Well, in version -05 there is at least one keyword instance. Furthermore, I don't know that such keywords need to always be used when an implementation requirement level is being specified. That said, we could see if additional RFC 2119 keywords are warranted. > 2) Section 4: If I understand correctly the TRILL-EN spoofs the > Ingress RBridge edge node's nickname in the source address field of > the TRILL header. Is this likely to introduce problems? E.g. if > RBridges will accept & forward frames that have their own source > address in, does it perpetuate routing loops or present security > considerations that the document should discuss? TRILL goes to great lengths to avoid loops and has a hop count in the TRILL header so that, should there be a transient loop, a TRILL packet in that loop (i.e., an encapsulated frame) will be discarded. In the potentially more dangerous case of multi-destination packets, as compared with known unicast, where copies could multiply due to forks in the distribution tree, a Reverse Path Forwarding Check is used to discard packets that appear to be on the wrong link or when there is disagreement about the distribution tree. Security Considerations should probably say more on this. > Section 8 on Security Considerations also looks very light on > text. If you are allowing TRILL-ENs to spoof RBridge source > addresses (which I think you are, see comment above) I think you > should have a discussion about that somewhere in the document. I agree that some further discussion is needed in the Security Considerations section. > Minor Issues: > > 1) Section 3. I am not sure what Figure 2 is trying to convey and it > is not referred to by the main text. Is it required? Figure 2 is intended to show the header of a pre-encapsulated frame going from a TRILL-EN to an edge TRILL switch. If it is retained in the draft, there should be clarifying text that references it. > 2) Section 3 says: > > Editor's note: [Directory] has defined Push and Pull methods for edge > RBridges to get directory mapping information. The Pull Model is > relative simple for TRILL-EN to implement (see Section 9). Pushing > Directory information requires some reliable flooding mechanism, like > the one used by IS-IS, between the edge RBridge and the TRILL > encapsulating node. > > which gives me the impression the authors prefer pull and discourage > push as it would require something extra like IS-IS. That note no longer exists in the draft. Also the "[Directory]" draft referred to has been issued as RFC 8171 and the draft should be updated to reflect that. > However, Section 4 says > > The TRILL-EN learns this nickname by listening > to the TRILL IS-IS Hellos from the Ingress RBridge. > > which makes me think if the TRILL-EN is running IS-IS for hellos, is > pushing the directory such an obstacle? That text refers to snooping on IS-IS messages, not running IS-IS. There are problems with using IS-IS, designed for communication between routers (Intermediate Systems) and the end station implementing pre-encapsulation as described in this draft. At first throught, you might want is an extension of ES-IS but the Memorandum of Understanding between the IETF and ISO/IEC only covers IS-IS, not ES-IS. So TRILL has specified a "TRILL ES-IS" in Section 5 of RFC 8171. However, even then, push uses ESADI [RFC7357], which involves encapsulation and VLAN/FGL scoping and which would need to be extended for end stations so push is out of scope for this document. > Is whether the directory is pulled or pushed something this document > needs to discuss at all? If it does need to discuss push vs pull, > should the document be stronger and make a clearer recommendation on > which method should be used (or implemented by default) to aid with > interoperability? The reasons for using push or pull or some sort of hybrid are discussed in RFC 8171. The -05 version of the Directory Assisted TRILL Encapsulation document only covers pull. > 3) Section 5.1 states > > setting TRILL boundary at aggregation > switches that have many virtualized servers attached can limit the > number of RBridge nodes in a TRILL domain, but introduce the issues > of very large MAC&VLAN<->RBridgeEdge mapping table to be maintained > by RBridge edge nodes and the necessity of enforcing AF ports. > > Allowing Non-RBridge nodes to pre-encapsulate data frames with TRILL > header makes it possible to have a TRILL domain with a reasonable > number of RBridge nodes in a large data center. All the TRILL-ENs > attached to one RBridge are represented by one TRILL nickname, which > can avoid the Nickname exhaustion problem. > > As I understand it TRILL-ENs pre-encapsulate packets that they send, > but when receiving packets the RBridge attached to the TRILL-EN > decapsulates the TRILL packet and forwards it to the TRILL-EN > “natively” (without TRILL encapsulation), as stated in section 3: > > When a TRILL frame arrives at an RBridge whose nickname matches with > the destination nickname in the TRILL header of the frame, the > processing is exactly same as normal, i.e. as specified in [RFC6325] > the RBridge decapsulates the received TRILL frame and forwards the > decapsulated frame to the target attached to its edge ports. > > Therefore all the RBridges still need to maintain a very large > "MAC&VLAN<->RBridgeEdge mapping table”? If that is the case, what > advantage does this approach give over the “base case” of setting > TRILL boundary at aggregation switches? With pre-encapsulation, although edge RBridges need to learn local MAC addresses so they can de-capsulate, they do not need to learn the typically much larger number of remote MAC address because they do not need to encapsulate. This should be explained more clearly. > 4) Section 7 on Manageability Considerations only states that in > order for the solution to work requires the availability of a > directory service, which seems a bit redundant when the entire > document is about "Directory Assisted TRILL Encapsulation”. Is this > section required? I agree that the Manageability Considerations section should have some material added concerning configuration or be dropped. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > Regards > Ben _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
