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? _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill