Hi Eric, On Thu, Mar 8, 2018 at 9:05 AM, Eric Rescorla <e...@rtfm.com> wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-trill-multi-topology-05: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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?
All TRILL implementations support VLANs. See TRILL Base Protocol specification RFC 6325. Fine grained labels were added in RFC 7172. There are actually two levels: (1) FGL safe, which means it can transit fine grained labels but cannot ingress or egress them, and (2) full FGL support which can also ingress/egress to/from fine grained labeled TRILL Data packets. It is really desirable to have RBridges be FGL safe so you can have, say, a TRILL campus with an island or two of fully FGL capable RBridges and not have to worry that data packets they produce will get tossed if they happen to hit an older RBridge. And it's pretty easy to be FGL safe, you just have to not explicitly check in the inner label and drop the frame if it isn't an ordinary VLAN. When Multi-Topology was added, it could have been independent of FGL so you have a lattice of capabilities but the decision was made to have a sequence instead to avoid starting on a combinatorial explosion of combinations of options, simplify testing, etc. So its VL < FGL < MT with each implying support of the previous. > (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? If you haven't heard from then, then you haven't established adjacency with them (see adjacency establishment mechanism in RFC 7177) and you will therefore ignore data packets from them and will not attempt to send data packets to them. The process of adjacency establishment includes learning about MT support in the exchanged Hellos. > V - The version number of the MT label. This document specifies > version zero. > What do I do if I receive an unknown version? I think if the label has a non-zero version, it would not be understood by an RBridge that implements this draft and the packet must be dropped. Any other behavior seems unsafe. This should probably be explicitly stated. > + 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 OK > 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" OK. 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
