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

Sandra Murphy <sandy@tislabs.com> Mon, 31 August 2015 23:08 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785441B6B27; Mon, 31 Aug 2015 16:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmH_W63cmVBe; Mon, 31 Aug 2015 16:08:03 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7D61B6B25; Mon, 31 Aug 2015 16:08:02 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1C44328B0041; Mon, 31 Aug 2015 19:08:01 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 008BC1F8035; Mon, 31 Aug 2015 19:08:00 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_40E35704-AB3A-4E82-A9F7-C8D1953A3BD6"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <4552F0907735844E9204A62BBDD325E7871A2CFE@nkgeml512-mbx.china.huawei.com>
Date: Mon, 31 Aug 2015 19:07:40 -0400
Message-Id: <B96ADDA3-73A8-404B-A75F-9C6F9BB2E9D7@tislabs.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com> <4552F0907735844E9204A62BBDD325E7871A2CFE@nkgeml512-mbx.china.huawei.com>
To: Mingui Zhang <zhangmingui@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/vQbWfFLIuiuoweK5jot9aa5LKy0>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>, "draft-ietf-trill-pseudonode-nickname.all@ietf.org" <draft-ietf-trill-pseudonode-nickname.all@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 23:08:04 -0000

On Aug 30, 2015, at 11:54 PM, Mingui Zhang <zhangmingui@huawei.com> wrote:

> Hi Russ,
> 
> 
>> 
>> (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.
> 

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