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

Sandra Murphy <> Mon, 31 August 2015 20:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 145AC1B4C6C; Mon, 31 Aug 2015 13:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fuQ3gDKJOH8e; Mon, 31 Aug 2015 13:20:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3B5A1B5D0B; Mon, 31 Aug 2015 13:20:48 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 42D4F28B0041; Mon, 31 Aug 2015 16:20:48 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain []) by (Postfix) with ESMTP id 223121F8051; Mon, 31 Aug 2015 16:20:48 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1C9E37A0-7ABD-4CF4-9A43-665DC4CC5F5D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5
From: Sandra Murphy <>
In-Reply-To: <>
Date: Mon, 31 Aug 2015 16:20:34 -0400
Message-Id: <>
References: <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: IETF Gen-ART <>, IETF <>,, Sandra Murphy <>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2015 20:20:51 -0000

On Aug 27, 2015, at 5:59 PM, Russ Housley <> wrote:

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

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.