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

From: The IESG <[email-masked]>
Date: Tue, 04 Jan 2011 07:34:54 -0800

The IESG has received a request from the IS-IS for IP Internets WG (isis) 
to consider the following document:

- 'IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging '
   <draft-ietf-isis-ieee-aq-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2011-01-18. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-isis-ieee-aq-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20343&rfc_flag=0

Please note that this document makes normative reference to ISO/IEC 10589:2002

No IPR declarations have been submitted directly on this I-D.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Jan 2011 15:11:14 +0200 (EET)

>   <draft-ietf-isis-ieee-aq-03.txt> as a Proposed Standard
...
> 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.