Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge
draft-ietf-trill-active-active-connection-prob-07

I have no objection to the publication of this document, but here are
some points you may want to discuss with your document shepherd and 
responsible AD.

---

   CE - As in [CMT], Classic Ethernet device (end station or bridge).
   The device can be either physical or virtual equipment.

1. [CMT] has "Classical Ethernet device"
2. I am aware of World Acronym Depletion (WAD) [5513], but do you think
   it is advisable to use "CE" when that abbreviation has such a well-
   known meaning that shows on figures in a way that is highly similar 
   to the positioning of your CE on your figures?

---

As a problem statement, I feel you are dodging an issue when you write

   LAALP is usually a proprietary facility whose implementation varies
   by vendor. So, to be sure the LAALP operations successfully across a
   group of edge RBridges, those edge RBridges will almost always have
   to be from the same vendor. In order to have a common understanding
   of active-active connection scenarios, the assumptions in Section 2.1
   are made about the characteristics of the LAALP and edge group of
   RBridges.

and 

   Other than the applicable characteristics above, the internals of an
   LAALP are out of scope for TRILL.  

Shouldn't you actually be raising this as a missing component in the
toolset? A standardised LAALP would increase the flexibility and utility
of TRILL in a multi-vendor environment. Your document could briefly 
explain how initial deployments will be proprietary, describe the
limitations, state that a standardised LAALP would be beneficial, and
briefly outline what such a protocol might look like (presumably built
on MC-LAG) and how it needs to differ from existing offerings.

You already have lots of this material, but it seems you are actively 
discouraging work on this topic. I can see that this might be out of
scope for the current TRILL charter, and whether someone comes along
later to address the requirements is for the future, but you seem to be
pushing a deployment scenario where a CE can only be attached to an 
edge RBridge from the same vendor.

---

I find section 5 disappointing! Although (of course) solution-specific
security issues can only be documented in the solution documents, I
should think that the active-active model introduces some interesting
security issues. If the new function/architecture genuinely introduces 
no issues or security associations, then that is fine: I am just
surprised by the fact.

---

It would be nice, IMHO, if this document also described the 
manageability requirements to support active-active. Are there changes
to OAM? How does one find out which edge RBridge is carrying which flow?
What needs to be configured/inspected at the CE and the edge RBridge?

I second Adrian's point, the same one made in the SecDir review.  While individual solutions may have specific security concerns or risks, I would think that there are some risks that would broadly apply to ant solution that should be described here and perhaps even setting security requirements for any solution that follows.

https://www.ietf.org/mail-archive/web/secdir/current/msg04939.html

What Kathleen said.