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

From: Eric Rescorla <[email-masked]>
Date: Thu, 08 Mar 2018 06:05:06 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-multi-topology-05: 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-multi-topology/

----------------------------------------------------------------------
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?

   (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"

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 8 Mar 2018 12:03:03 -0500

Hi Eric,

On Thu, Mar 8, 2018 at 9:05 AM, Eric Rescorla <[email-masked]> wrote:
> ...

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.

> 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.

> 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.

>             no traffic at all. For example, if only known destination

OK

>             of zero in the Trees sub-TLV for the TRILL switch holding

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Mar 2018 09:07:01 -0800

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