Re: [Isis-wg] Last Call: draft-ietf-isis-ieee-aq (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging) to Proposed Standard

Pekka Savola <pekkas@netcore.fi> Fri, 07 January 2011 13:09 UTC

Return-Path: <pekkas@netcore.fi>
X-Original-To: isis-wg@core3.amsl.com
Delivered-To: isis-wg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007DC3A68BA; Fri, 7 Jan 2011 05:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.078
X-Spam-Level:
X-Spam-Status: No, score=-102.078 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, J_BACKHAIR_34=1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dejIqVvB9AOL; Fri, 7 Jan 2011 05:09:21 -0800 (PST)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id B701A3A68B9; Fri, 7 Jan 2011 05:09:20 -0800 (PST)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p07DBGFH020761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 15:11:17 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p07DBEut020758; Fri, 7 Jan 2011 15:11:16 +0200
Date: Fri, 07 Jan 2011 15:11:14 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
In-Reply-To: <20110104153454.23796.26316.idtracker@localhost>
Message-ID: <alpine.LRH.2.02.1101071509060.20267@netcore.fi>
References: <20110104153454.23796.26316.idtracker@localhost>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: clamav-milter 0.96.5 at otso.netcore.fi
X-Virus-Status: Clean
Cc: isis-chairs@tools.ietf.org, isis-wg@ietf.org, draft-ietf-isis-ieee-aq@tools.ietf.org
Subject: Re: [Isis-wg] Last Call: draft-ietf-isis-ieee-aq (IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging) to Proposed Standard
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 13:09:23 -0000

On Tue, 4 Jan 2011, The IESG wrote:
> - 'IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging '
>   <draft-ietf-isis-ieee-aq-03.txt> as a Proposed Standard
...
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-isis-ieee-aq-03.txt

This is an ops-dir review of draft-ietf-isis-ieee-aq-03.

The document provides an overview of IEEE 802.1aq (shortest path Ethernet
bridging using IS-IS) and specifically defines IS-IS codepoints for use.
802.1aq is orthogonal with TRILL wg solutions but both solve somewhat
similar issues, i.e. Ethernet network scaling and load balancing
optimizations.

Secure use of 802.1aq will probably require manual configuration of IS-IS
authentication in each device or IS-IS filtering in client ports.
The draft does not discuss interoperability with traditional Ethernet, i.e.,
how will this work in an environment where all the equipment does not
support it.

I find the document close to ready to publish after minor text improvements
and e.g. definiting how a newly allocated IANA codepoint TLV subspace is to
be managed by IANA.

Some more detailed comments below.

substantial
-----------

17. Security Considerations

    This document adds no additional security risks to IS-IS, nor does
    it provide any additional security for IS-IS.

.. while true, this is probably a bit weak. Given that the document included
a quite detailed description of 802.1aq (not just IS-IS extensions), some
brief summary would have been nice.

Some notes about this:
  - This protocol is apparently intended to be used in a zero-conf
    environment.  IS-IS authentication cannot be used without manual
    configuration. Hence a warning label would likely be useful.  For
    example, I suppose there is nothing to prevent a UNI port from
    participating in IS-IS and 802.1aq.

  - The increase of state due to broadcast/multicast is a new potential
    concern, but really not that much different from the current MAC address
    flooding issues.

  - One particular thing that comes to mind is intentional clash of SPVID
    values described in S 14.1. By claiming the highest Bridge Identifier, a
    bridge could deny all other bridges all service, right?


semi-editorial
--------------

    FDB            Filtering Information Base: {DA/VID}->{next hops}
...
4. 802.1aq Overview

    802.1aq utilizes 802.1Q based Ethernet bridging. The filtering
    database (FDB) is populated as a consequence of the forwarding
    computed from the IS-IS database.

.. is this a typo?  The established spell-out form of FDB is Forwarding
Database (storing MAC<->port mappings).  Is overloading it intentional?

4.7. Data Path SPBV Multicast


    C-DA multicast addresses may be advertised from SPBV UNI ports.
    These may be configured or learned through MMRP. The MMRP protocol

... there is no reference or spell-out in abbreviations for "MMRP". I
suppose youre referring to Multiple MAC registration protocol defined in
IEEE 802.1ak-2007.

18. IANA Considerations


    Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has
    already been assigned by IANA for the purpose of 802.1aq therefore
    no further action is required for this code point.

.. true but I suppose it wouldn't hurt to add a reference to this RFC there,
given that the defining RFC-to-be does not include any other reference other
than "802.1aq".

       The MT-Capability TLV is the only TLV requiring a new sub-registry.
    Type value 144 is requested with a starting sub-tlv value of 1.

.. as you're creating a new registry, I suppose you should also define the
registration policy for it?  Most IS-IS TLV codepoints appear to have
"Expert review", so maybe that would be appropriate here as well.

editorial
---------

Traditionally [references] are not appropriate in Abstract.

It is a bit strange to see an empty Introduction section :-). Most of
Introduction is provided in Overview (S 4) though.