Re: [RTG-DIR] [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Ben Niven-Jenkins <[e-mail]>]

Hi Donald,

Sorry I missed the earlier emails.

I’ll read the latest draft and respond properly next week.

Ben

> On 10 Jan 2018, at 20:05, Donald Eastlake <[e-mail]> wrote:
> 
> Hi Ben,
> 
> As far as I know, you never responded to the email below or to the subsequent email to you from Sue Hares asking you to check if the current version (-06) of this draft resolves your RTGDIR review comments.
> 
> I realize there was a lot of earlier delay on the part of the TRILL WG but, please, can you repond on this now?
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail] <mailto:[e-mail]>
> On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake <[e-mail] <mailto:[e-mail]>> wrote:
> 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
> <[e-mail] <mailto:[e-mail]>> 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 <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   [phone] <tel:%2B1-508-333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail] <mailto:[e-mail]>
> 
> > Regards
> > Ben