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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]