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

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