I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-trill-pseudonode-nickname-05 Reviewer: Russ Housley Review Date: 2015-08-24 IETF LC End Date: 2015-09-01 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: (1) In section 5.2, the document provides this formula: "(System IDj | LAALPi) mod k". In my first reading, I missed the overloading of "LAALPi", and I think it would be more clear to say "(System IDj | LAALP IDi) mod k". If this is accepted, the description becomes simple: "... and the LAALP IDi is the LAALP ID for LAALPi". (2) Also, in Section 5.2, Step 1, I think the intended sort order depends on all of the LAALP IDi values being represented with the same number of bits. Since Section 9.1 provides a variable length field to carry a LAALP ID value, I assume that they are not always the same length. Is a step needed to encode the LAALP ID to a consistent length? (3) In Section 11, we learn that the VLAN membership of all the RBridge ports in an LAALP MUST be the same. Any inconsistencies in VLAN membership may result in packet loss or non-shortest paths. Is there anything that can be added to the Security Considerations that can help avoid these inconsistencies? Minor Concerns: (1) In section 1, we learn that there is more than one way to handle nicknames: ... A member RBridge of such a group uses a pseudo-nickname, instead of its own nickname, as the ingress RBridge nickname when ingressing frames received on attached LAALP links. Other methods are possible; for example the specification in this document and the specification in [MultiAttach] could be simultaneously deployed for different AAE groups in the same campus. Both of these specifications are Internet-Drafts in the TRILL WG. Given this situation, I was expecting some discussion about how an implementer was expected to choose and any consequences on interoperability that result from that choice. (2) I found the last sentence of Section 2 confusing. I am suggesting a rewording to see if I figured it out. If I did not figure it out properly, then the sentence really does need to be reworked. Under the assumption that the default learning is enabled at edge RBridges, MAC flip-flopping can be solved by using a Virtual RBridge together with its pseudo-nickname. This document specifies a way to do so. (3) In Section 5.1, it says: This document uses the approach proposed in [CMT] to fix the RPF check violation issue. Please refer to [CMT] for more details of the approach. An alternative solution is proposed in [CentralReplicate]. Is the alternate solution compatible or incompatible with this document? I am not sure from this paragraph; please add a few words to be clear. Other Comments: The document uses "RPF Check" and "RPF check". Please pick one. In Section 4.1: s/RB3 announces {LAALP1, LAALP2, LAALP3, LAALP}/ /RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}/ In Section 16.1: s/trill-frc7180bis/trill-rfc7180bis/ In Section 5.1: s/a distribution tree Tx/a distribution tree/ -- The Tx is not referenced later, so it is not needed here In Section 5.1: s/Coordinated Multicast Trees (CMT)/ /Coordinated Multicast Trees (CMT) [CMT]/ In Section 5.3: s/The idea of this check is to check the/ /The idea of this check is to determine the/ In section 11: s/It is important that the VLAN membership of all/ /The VLAN membership of all/ Process Observation: This document contains a normative references to draft-ietf-trill-cmt and draft-ietf-trill-rfc7180bis, both of which have been submitted to the IESG for publication. An updated I-D is needed for draft-ietf-trill-cmt to progress. If this document is approved now, it was wait in the RFC Editor queue for missing references.