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?

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

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
>> ...
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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

Reply via email to