Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

On Mon, Mar 5, 2018 at 4:34 PM, Alvaro Retana <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]