Hi Alvaro, A -11 version of the draft-ietf-trill-smart-endnodes draft has been posted. Could you look at it to see if it resolves your Discuss?
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Wed, Mar 7, 2018 at 2:56 PM, Donald Eastlake <d3e...@gmail.com> wrote: > Hi Alvaro, > > On Mon, Mar 5, 2018 at 4:34 PM, Alvaro Retana <aretana.i...@gmail.com> wrote: >> Alvaro Retana has entered the following ballot position for >> draft-ietf-trill-smart-endnodes-10: Discuss >> >> ... >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This document feels tightly coupled with >> draft-ietf-trill-directory-assisted-encap, even though there are no >> cross-references. If I understand the mechanisms correctly, a Smart Endnode >> (discussed in this draft) can then do directory assisted encapsulation >> (described in draft-ietf-trill-directory-assisted-encap). In fact, the >> encapsulation/decapsulation seems to be the main motivation in defining a >> Smart >> Endnode. > > There are similarities, but I'm not sure I would say that > draft-ietf-trill-directory-assisted-encap and > draft-ietf-trill-smart-endnodes are "tightly coupled". > > trill-directory-assisted-encap is the best you can do with no changes > to RBridges as specified in the TRILL Base Protocol [RFC6325]. Special > end stations can do the encapsulation but edge RBridges always do the > decapsuation. > > trill-smart-endnodes requires additional mechanisms in the edge > RBridges to shake hands with the smart endnode, recognize when a > destination MAC is being handled by the smart endnode and just forward > it without decapslation, etc. As a result, this also support smart > endnodes that are fine grained label aware. > >> I think then that this document also falls short in the exploration of >> potential issues, so I am also balloting DISCUSS. The same cases that I >> pointed at for draft-ietf-trill-directory-assisted-encap [1] are applicable >> here -- with the added caveat that the Smart Endnode, in general, has other >> sources of information (learning, etc.), which means that there are >> potentially >> more doors to close. > > OK, similar security consideration text improvements can presumably be > made to this draft. > >> The Multi-homing Scenario (Section 6) adds some complexity to the ability to >> check whether the Ingress RBridge is set correctly in the encapsulation. It >> would be nice to explore this case a little further and highlight the issues >> as >> the topologies get more complex. >> >> As I wrote in [1], I don't think that there are easy mitigations for these >> issues, but at least mentioning them so that operators are aware of the risk >> would be enough to clear this DISCUSS. Given that the authors partially >> overlap, it may be a good idea to solve the issue in this document (which is >> the general case) and then just have the other one point this way. >> >> [1] >> https://mailarchive.ietf.org/arch/msg/trill/xZvEj_9FtSgHSp4DnKCVxr670gc/?qid=1e5a9496ac80237a3f7cc6aeea09d24d > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e...@gmail.com _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
