Last Call Review of draft-ietf-trill-pseudonode-nickname-05

Request Review of draft-ietf-trill-pseudonode-nickname
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-01
Requested 2015-08-20
Authors Hongjun Zhai, Tissa Senevirathne, Radia Perlman, Mingui Zhang, Li Yizhou
Draft last updated 2015-08-27
Completed reviews Genart Last Call review of -05 by Russ Housley (diff)
Genart Last Call review of -06 by Russ Housley (diff)
Secdir Last Call review of -05 by Carl Wallace (diff)
Opsdir Last Call review of -05 by Linda Dunbar (diff)
Rtgdir Early review of -05 by Russ White (diff)
Assignment Reviewer Russ Housley 
State Completed
Review review-ietf-trill-pseudonode-nickname-05-genart-lc-housley-2015-08-27
Reviewed rev. 05 (document currently at 07)
Review result Almost Ready
Review completed: 2015-08-27


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

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

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.