Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
draft-ietf-trill-multi-topology-06

The extensions defined in this document are "an optional TRILL switch capability".  To me, that indicates that the base TRILL specifications rfc6325 and rfc7177 (in this case) are not affected: an RBridge is TRILL-compliant as long as it implements what rfc6325 specifies (without these optional extensions).  I would then like to see the formal "Updates" tags removed.

[The publication of this document is not the place to argue about the meaning of "Updates", so I'll defer to what the Responsible AD decides.]

Review in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3642

A diagram in the introduction would have helped me.


            Grained Label [RFC7172]. By implication, an "FGL TRILL
            switch" does not support MT.
You are using MT before expansion here. But I actually don't understand why it does not. Can you explain?



            implication, a "VL RBridge" or "VL TRILL switch" does not
            support FGL or MT.
My same question here as above. Why can't a VL TRILL switch support MT?



   (1) all TRILL switch ports on the link advertise topology T support
       in their Hellos and
   (2) if any TRILL switch port on the link requires explicit TRILL Data
Probably stupid question but how do you know that there aren't TRILL switches that you haven't heard from yet that don't support T?



     V -  The version number of the MT label. This document specifies
         version zero.
What do I do if I receive an unknown version?



         +  There may be non-zero topologies with no multi-destination
            traffic or, as descried in [RFC5120], even topologies with
            no traffic at all. For example, if only known destination
Nit: described



            topology, there would be no need for a distribution tree for
            topology T.  For this reasons, a Number of Trees to Compute
            of zero in the Trees sub-TLV for the TRILL switch holding
Nit: "reason"