Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multi-topology-05: (with COMMENT)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Eric,
>
> On Thu, Mar 8, 2018 at 9:05 AM, Eric Rescorla <[e-mail]> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>