Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments
draft-ietf-trill-aa-multi-attach-06

I've already had an exchange with an author about these comments, and he's resolving them very much to my satisfaction.  Thanks!

-- Section 4.1 --

   It's
   RECOMMENDED that the receiving edge RBridge disable the data plane
   MAC learning from TRILL Data packet decapsulation within those
   advertised Data Labels for the originating RBridge unless the
   receiving RBridge also supports Option A. However, alternative
   implementations MAY be used to produce the same expected behavior.

A minor point, because I think people will properly understand this, but the "SHOULD do X but MAY do Y" construction is a misuse of 2119 language -- the MAY contradicts the SHOULD, because "MAY" says that doing Y is entirely optional.  In this case, I think the best fix is to remove the 2119 language from the second part, making the last sentence, "Alternative implementations that produce the same expected behavior are acceptable," which leaves the initial RECOMMENDED in force.

-- Section 5.3.1 --

   If the output of the selection
   function points to the port attached to the receiving RBridge itself
   (i.e., the packet should be egressed out of this node), it MUST
   egress this packet for that AAE group.

What is the antecedent to "it"?  It looks like it's "the output of the selection function", but I think it's supposed to refer to "the receiving RBridge"; is that right?  If so, I suggest making that clear:

NEW
   If the output of the selection
   function points to the port attached to the receiving RBridge itself
   (i.e., the packet should be egressed out of this node), the receiving
   RBridge MUST egress this packet for that AAE group.
END

   (It is output or not as specified in
   [RFC6325] updated by [RFC7172] for ports that lead to non-AAE links.)

I can't parse this, and have no idea what it means; can you please rephrase?

-- Section 5.3.2 --

   When a multi-destination frame originated from an LAALP is ingressed
   by an RBridge of an AAE group, distributed to the TRILL network and
   then received by another RBridge in the same AAE group, it is
   important that this RBridge does not egress this frame back to this
   LAALP.

In the last phrase, what is "this RBridge"?  There are two RBridges mentioned.  I think you mean "it is important that the second RBridge does not egress the frame back to the originating LAALP."

   Customer may need hosts within
   these overlapped VLANs to communicate with each other.

I tried a few ways to interpret this before settling on the one I think you mean.  First, it needs to say either "Customers" or "A customer", and it's not clear which.  Second, it's not clear whether you want customers or hosts to communicate.  I think this is what you mean; is it?:

NEW
   A customer may require that hosts within
   these overlapped VLANs communicate with each other.
END

-- Section 5.5 --

   In doing this, the forwarding paths
   need not be limited to the least cost Equal Cost Multiple Paths from
   the ingress RBridge to the AAE RBridges.

This reads confusingly, because it doesn't make sense to have a least cost entry from among ECMPs.  I gather that what you mean to say is that the ECMP comprises a set of equal-cost paths, and that set represents the least cost choice.  Let's see if we can find a way to word that which doesn't sound confusing.  Is it even necessary to mention ECMPs here, when the term isn't used elsewhere in the document?  Might this work just as well?:

NEW
   In doing this, the forwarding paths
   need not be limited to the least cost path selection from
   the ingress RBridge to the AAE RBridges.
END

-- Section 5.6 --

In the first sentence, "option A" should have "Option" capitalized, to be consistent with other uses of "Option A".  Similarly for "option B" in the second paragraph.

-- Section 8.2 --
I'm not making this a DISCUSS, but... it would be useful to have some guidance for the designated expert.  What should she be considering in deciding whether to approve a registration request?  I presume the expert review is to make sure the 62 remaining bits aren't expended frivolously, so what guidance can you give about when it's appropriate to say "no"?

-- Section 8.3 --
I strongly suggest that you not duplicate the whole table here, but only show the entries you're adding.  And the section title should probably have a hyphen in "Active-Active".

Also, the registry names aren't right; they're called "Interested VLANs Flag Bits" and "Interested Labels Flag Bits": http://www.iana.org/assignments/trill-parameters#interested-labels-flags

A few minor comments (no show stoppers):

-- section 4.1, first paragraph:  "However, alternative implementations MAY be used to produce the same expected behavior."

Does this talk about same “behavior”  of an RBridge (as in the observable one-the-wire bits are identical) or same “results” for the system (as in the receiving RBridge does not flip-flop)? If the former, it probably should not be normative.

-- section 5.3.2:
This section defines a sub-tlv, and related behavior. That probably doesn’t belong in the design goals analysis section. (I predict that many readers will skip section 5 entirely). Please consider moving this under section 4.

Also, can you cite something for the "well-known 'split horizon' technique"?

-- section 7:
This draft defines new data elements. It seem likely that nothing in those new elements add security considerations beyond those in the cited specs. But it would be helpful to explicitly state that.

-- 8.3:
Are you for specific flag values (16 and 4 respectively), rather than allowing IANA to assign the values as needed? Also, it seems odd to recreate the entire flag registries in a spec that merely adds new flags. The registry will change over time; this runs the risk of a reader assuming the contents listed here are current at any point in the future.  (But I see that other TRILL specs have done the same.)

Editorial Comments and Nits:

-- Abstract:
Please expand TRILL on first mention in the abstract.

-- section 1, first paragraph:
Please expand TRILL on first mention in the body, too.

-- 4.1, first paragraph:
"... in MAC learned from the TRILL...": Missing article
s/It's/It is
"A promising way..." : “promising” in this context seems to imply the option is likely, but not certain to work. Is that the intent?
s/So the receiving edge.../The receiving edge...

-- 4.1, 2nd paragraph:
Sentence 1 is a little confusing. I assume the intent is to say that this draft allocates the reserved flags, and the flags are used to advertise the data labels? As it is, it sounds like the act of allocation advertises the data labels.
In sentence two, should "this flag" be "these flags"?

-- 4.1, paragraph 3: "...it MUST be advertised..."
I assume this means that the originating RBridge MUST advertise it? (Please consider active voice for 2119 requirements. )

-- 5:
Consider “This section explores how this specification meets the major design goals of AAE”

I was also surprised there were no additions for this capability to the security considerations and will follow along to responses on Stephen's question on the same topic.

Thanks.

Just one question. In this text:

5.3.2. No Echo (Split Horizon)

   When a multi-destination frame originated from an LAALP is ingressed
   by an RBridge of an AAE group, distributed to the TRILL network and
   then received by another RBridge in the same AAE group, it is
   important that this RBridge does not egress this frame back to this
   LAALP. Otherwise, it will cause a forwarding loop (echo). The well
   known 'split horizon' technique is used to eliminate the echo issue.
   
Is there a canonical (or semi-canonical) reference for split horizon that you could provide here? A pointer to Appendix A would help, but that's more of a description of how to do split horizon than a description of what split horizon is.

I see that Ben also asked for this ...

- abstract: "Thus, remote edge RBridges are required to keep
multiple locations of one MAC address in one Data Label." I
find that very hard to read and don't understand what it's
telling me. Even if these terms are terms-of-art for trill, it'd
be worth being less opaque in the abstract. I have the same
problem with the intro. I think if you tried to be specific
about whose MAC address you mean (a host attached to RBridges
in the AAE) and also explained (or avoided) the term "Data
Label" here that'd help.

- 5.1: for how long is a remote RBridge "required to adhere"?
(Sorry if that's clear in 4.1, in which case I missed it.)

- 5.3.2: "well-known split horizon technique" just screams for
a reference. Please add one, which is presumably easy to do as
this is well-known:-)

- security considerations: I'm surprised there's nothing new
here. Did someone do the analysis to check? (Sorry for doubting
you but security considerations sections like this that only
consist of references are often an indicator that nobody did
take a real look;-) One possible example (not sure if it
works): if I can fake an ESADI message then I could pretend to
be the RBridge in the AAE that has least cost and so lots of
traffic would be sent to me, instead of the real RBridges in
the AAE.  Compared to the situation without this specification,
that might mean a more effective attack. Now I'm not really
sure if that's true or not (I'm sure you'll tell me) but my
question is whether or not those kinds of thing were considered
already.