Early Review of draft-ietf-trill-directory-assisted-encap-02
review-ietf-trill-directory-assisted-encap-02-rtgdir-early-niven-jenkins-2016-05-20-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-trill-directory-assisted-encap-02-rtgdir-early-niven-jenkins-2016-05-20

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.

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.

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?

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.


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?

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.

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?

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?

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?

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?

Regards
Ben