Hi Russ,
Thanks for the comments. Please see the in-lines below.
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
Sent: Friday, August 28, 2015 5:59 AM
To: draft-ietf-trill-pseudonode-nickname(_dot_)all(_at_)ietf(_dot_)org
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