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