Hi Eric,

On Wed, Mar 7, 2018 at 11:41 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-10: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Alvaro's DISCUSS and Kathleen's comment
>
> I also think it would be useful to emphasize the need for some security on the
> links between the egress and ingress nodes, although presumably that's a
> standard TRILL consideration.

Sure. The links between TRILL nodes can be a variety of technologies.
So security on on the links depends on the link technology and is
discussed in the RFC covering TRILL over that link technology.

> Finally
>       nodes. Such spoofing cannot cause looping traffic because TRILL has a
>      hop count in the TRILL header [RFC6325] so that, should there be a
>       loop, a TRILL packet caught in that loop (i.e., an encapsulated
>       frame) will be discarded.
>
> Is it in fact the case that it cannot cause looping or merely that the loop is
> contained by the hop count? Perhaps this is just a terminology issue and in
> routing loop just means infinite loop?

Should probably say "...persistently looping traffic...".

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

Reply via email to