Hi Russ, Thanks for the comments. Please see the in-lines below. > -----Original Message----- > From: Russ Housley [mailto:housley@xxxxxxxxxxxx] > Sent: Friday, August 28, 2015 5:59 AM > To: draft-ietf-trill-pseudonode-nickname.all@xxxxxxxx > Cc: IETF; IETF Gen-ART > Subject: Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05 > > 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 > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > 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". [MZ] This will be incorporated for easy reading. > > (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? [MZ] The sort is done in the per-LAALP base. It's not necessary to make the LAALP ID to a constant length. Besides, the 'mod' function always returns a value in [0, k-1] whatever the length of LAALP ID is. > > (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? > [MZ] The LAALP is REQUIED to keep the consistence. That is to say, if the consistence cannot be maintained, it is not qualified as a LAALP. What TRILL switches can do is that ports connected to inconsistent LAALPs MUST be disabled. This requirement can be added. > > 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. [MZ] Yes, there was a Capability TLV in [MultiAttach] to handle the interoperability. Explicit consequences can be explained here. > > (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. [MZ] Yes, this is clear. Will be incorporated. > > (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. > [MZ] Currently, it is not compatible. In the text, the [CentralReplicate] mentions because it is an alternative of RPF rather than the whole Active-Active mechanism. You know, RPF issue is a sub-issue of Active-Active. I think the last sentence should be removed to avoid confusion. > > 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/ [MZ] Above replacement will be executed. Thanks. > > > 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. Thanks, Mingui