[trill] Eric Rescorla's No Objection on draft-ietf-trill-directory-assisted-encap-10: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-directory-assisted-encap-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/



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

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?