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

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

trill mailing list

Reply via email to