Early Review of draft-ietf-trill-channel-tunnel-07

Request Review of draft-ietf-trill-channel-tunnel
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-04-28
Requested 2016-04-13
Authors Donald Eastlake, Mohammed Umair, Yizhou Li
Draft last updated 2016-04-28
Completed reviews Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -10 by Peter Yee (diff)
Secdir Early review of -07 by Yaron Sheffer (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Early review of -07 by Ron Bonica (diff)
Rtgdir Early review of -07 by Jonathan Hardwick (diff)
Assignment Reviewer Jonathan Hardwick 
State Completed
Review review-ietf-trill-channel-tunnel-07-rtgdir-early-hardwick-2016-04-28
Reviewed rev. 07 (document currently at 11)
Review result Not Ready
Review completed: 2016-04-28




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, and sometimes on special request.
 The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​



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.


Best regards




Document: draft-ietf-trill-channel-tunnel

Reviewer: Jon Hardwick

Review Date: 28 April 2016

Intended Status: Standards Track




I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.




The draft is overall well written and the specification is quite easy to understand, but I found some of the terminology and rationale to be confusing.  I would prefer to see this clarified before the document is published as RFC.  Note
 that this is the first TRILL document I’ve reviewed, so my context comes largely from mailing list searches and the shepherd’s report.



Major Comments

The motivations for this draft are quite obscure from the perspective of the outsider


 which makes it hard for me to evaluate the proposed mechanism.


I think the problems that the draft solves should be more clearly spelled out.  From the introduction:


   This document updates [RFC7178] and specifies extensions to RBridge

   Channel that provide two additional facilities as follows:


      (1) A standard method to tunnel a variety of payload types by

          encapsulating them in an RBridge Channel message.


      (2) A method to provide security facilities for RBridge Channel



I think that number (1) requires more explanation because the RBridge channel already provides a standard method for a variety of payload types to be transmitted without needing the current draft.  What tunnelling capability is this draft


A significant amount of text in the draft discusses number (2), which secures the channel payload, presumably to cover cases where the payload has no in-built security mechanism.  This appears to be the major purpose of the draft.  The
 draft achieves number (2) by adding a security shim header between the RBridge channel header and the payload.  One consideration in doing this is to remain backwards compatible with RFC 7178, and it looks like the working group has decided to achieve backwards
 compatibility by defining a new RBridge channel protocol type called “channel tunnel” – where this effectively means the RBridge channel payload contains an additional security shim which in turn contains an identifier that determines the real payload protocol


I find the term “channel tunnel” misleading, as the draft does not appear to add any additional tunnelling capability above and beyond the tunnelling that can already be done using RFC 7178.  The draft actually describes an RBridge channel
 with enhanced security, so a term like “secure channel” would make more sense to me than “channel tunnel”.



Minor Comments

Section 3.1 – “Any particular use of the Null Payload should specify what VLAN or priority should be used when relevant.” – is unclear and no context for this statement is given.  Should be used by what and for what purpose?


Section 4.3 feels like a corollary to section 4.5 and so may be better placed as a subsection of 4.5.


Section 4.6 “The PType indicates the nature of the application_data.” - is potentially open to misinterpretation.  At face value it sounds like you are leaking some potentially sensitive information about the “nature” of the encrypted payload. 
 I think all you are actually saying is that it indicates whether the payload is an Ethertype, an Ethernet frame etc.  Suggest instead “In this case, the PType value in the RBridge Channel Tunnel Protocol Specific Data applies to the decrypted application_data.”


Section 5.2 “with a payload type (PType) indicating a nested RBridge Channel message” – strictly all the PType can indicate is that the payload is Ethertyped; on its own it cannot indicate a nested RBridge Chanel message.  Suggest “and
 it contains a nested RBridge Chanel message”.


Section 6.2

“Section xxx of [RFC 7178]” should be “Section 3.2 of [RFC 7178]”.

Don’t you also need a new IANA registry for the “Rbridge Channel Error Subcodes” listed in table 5.2?




Section 3.2

“as describe in” -> “as described in”


Section 4

“not to met” -> “not to meet”



 paragraph – this sentence is quite long and hard to parse.


Section 4.2 & Section 5.1

“As show in” - > “As shown in”


Section 4.3

“The use Derived Material” -> “The use of the Derived Material”

Does Derived Material really need to be capitalised in this section?


Section 4.5

“can reasonable be” -> “can reasonably be”


Section 4.6

“minimum MTU Sz” -> “minimum MTU size”

“Actual application_data sent with Channel Tunnel” -> “Actual application_data sent within the Channel Tunnel”

Why do you say “application_data” not “application data”?


Appendix Z should presumably be removed prior to IETF last call.