Subject: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

From: Russ Housley <[email-masked]>
Date: Thu, 27 Aug 2015 17:59:00 -0400

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

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

---

From: Mingui Zhang <[email-masked]>
Date: Mon, 31 Aug 2015 03:54:55 +0000

Hi Russ,

Thanks for the comments. Please see the in-lines below.

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, August 28, 2015 5:59 AM
> To: [email-masked]
> 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>.
> 
> "(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".

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

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

[MZ] Yes, this is clear. Will be incorporated. 

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

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

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 31 Aug 2015 16:20:34 -0400

> that can help avoid these inconsistencies?

Interesting.  In the trill draft I recently reviewed for secdir (draft-ietf-trill-aa-multi-attach) it makes a similar statement that VLAN membership had to be consistent across all ports on all RBridges in a LAALP.  In that draft, the consistency meant the VLANs could be left out of the protocol packet.

  All enabled VLANs MUST be consistent on all ports connected to an
  LAALP. So the enabled VLANs need not be included in the AA-LAALP-
  GROUP-RBRIDGES TRILL APPsub-TLV. They can be locally obtained from
  the port attached to that LAALP.

I wondered if the LAALP was responsible for ensuring the consistency.  If it is left to the operator configuration, that’s tough.  Turns out there’s a dynamic VLAN registration protocol (VRP), but I could not discover that it is doing a consistency check.

If the draft you are looking at implies inconsistency is a possibility, then it must be that neither the LAALP or VRP ensures the consistency.

—Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 31 Aug 2015 19:07:40 -0400

> [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 inc…

I just replied to Russ’s message before I read your response.

The draft language is just as Russ said.

   It is important 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.

Following this, there is a paragraph fully describing an inconsistent configuration.

If it is not possible for inconsistencies to occur, then why are you mentioning them?  Why give an explicit example of an inconsistent VLAN configuration?

You say "if the consistence cannot be maintained, it is not qualified as a LAALP”.  But the example shows a configuration case where inconsistency happens.  Does that mean it is not an LAALP?  Does the spec for LAALP ensure consistency (and if so, why mention inconsistencies and provide examples)? Does anything in TRILL detect the absence of consistency?

—Sandy

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 1 Sep 2015 02:15:58 +0000

Hi Sandy,

> I just replied to Russ's message before I read your response.
> 

[MZ] That's OK :)

> Following this, there is a paragraph fully describing an inconsistent

[MZ] Yes, that paragraph further explains the possible consequences of inconsistency. 

> 
> If it is not possible for inconsistencies to occur, then why are you mentioning
> them?  Why give an explicit example of an inconsistent VLAN configuration?

[MZ] This is to explain why consistency becomes a requirement for LAALP implementations that are connected to TRILL edge. Implementations that cannot fulfill this requirement should not be used to connect to TRILL edge. IOW, it is not qualified as an LAALP as defined in TRILL. You can also refer to the second 'c)' of Section 2.1 [RFC7379]. 

> 
> You say "if the consistence cannot be maintained, it is not qualified as a LAALP".
> But the example shows a configuration case where inconsistency happens.

[MZ] As explained above.

> Does that mean it is not an LAALP?  

[MZ] No, it's not an LAALP as TRILL defined and required. 

> Does the spec for LAALP ensure
> consistency (and if so, why mention inconsistencies and provide examples)?

[MZ] There are several proprietary link aggregation techniques in the industry. It's possible that some of them does not meet this requirement. So the requirement is a criteria for choosing LAALP implementations. I think this is easy for operators. 
It's possible that operators want to do manual configuration. In that case, the consistency requirement still holds. 

> Does anything in TRILL detect the absence of consistency?

[MZ] I think the detection of inconsistency is out the scope of TRILL. However, it's natural that an edge RBridge device implements both TRILL and LAALP. This device can detect the consistence by using LAALP.

Thanks,
Mingui

> -Sandy

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 31 Aug 2015 23:11:18 -0400

Hi Sandra,

> Interesting.  In the trill draft I recently reviewed for secdir (draft-ietf-trill-aa-multi-attach) it makes a similar statement that VLAN membership had to be consistent across all ports on all RBr…

Did you see my response to your secdir review which I send 3 days ago?

> If the draft you are looking at implies inconsistency is a possibility, then it must be that neither the LAALP or VRP ensures the consistency.

As per my previous response to you, as far as I know all existing
LAALPs are proprietary MC-LAG implementations and how they maintain
consistent VLAN enablement on the TRILL switch LAALP ports is out of
scope for the TRILL protocol.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]