Thanks. I think it might help to just expand a bit of your above explanation about FGL into the doc, if that's not too much trouble.
-ekr On Thu, Mar 8, 2018 at 9:03 AM, Donald Eastlake <d3e...@gmail.com> wrote: > 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
