I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-vpls-bridge-interop-02.txt
Reviewer: Elwyn Davies
Review Date: 19 November 2007
IETF LC End Date: 9 November 2007
Summary:
If I understand correctly, this document 'standardizes' the RFC 4464 s2.2
bridge model selection (it chooses #2) and bridge module functionality that
will ensure a VPLS network will interoperate with an IEEE 802.1ad bridged
provider network. It doesn't say this explicitly but it would make the whole
thing a good deal more comprehensible if it did (and probably shorten the
abstract).
Aside from a goodly number of editorial fixes that are needed, there are two major and a number of minor issues that I identified. The major issues in my view are related: Firstly, given that at least part of this document has to be implemented to achieve the specified interoperability, should this be standards track? Secondly, given the mandatory nature of the 'requirement', is it reasonable to specify that it must be possible to detect when the mesh of PWs is no longer a full mesh, and then not offer a scalable engineering solution (s4.3)? Overall I felt that the discussion of 'solutions' was less crisp than it might have been and left me worrying that implementers might not be sure what they were supposed to do, leading to potential interoperability problems.
Comments:
Overall: The document says what it is doing (specifying some things that need
to be implemented in a VPLS network to make it interoperable with IEEE 802.1ad
bridged provider networks) but doesn't say up front how this fits into the VPLS
framework. If my (somewhat limited) understanding is right - this isn't my
field - , the reason we have this document is to 'standardize' the RFC 4664
model selection (#2) and bridge module functionality that is needed to ensure
that an IETF VPLS will interoperate, per s2.2 of RFC 4664. If I am right, I
think it would be good to say this right at the beginning (and it would provide
a better abstract!) As it is, it sort of sneaks out when we reach s3.
If my view is correct, I feel there is a valid argument that this document
should be standards track rather than Informational. The VPLS standards will
not fulfill the aims without at least the mandatory adaptations documented here
(last para in s1). Of course one issue with making this a standard is that
some of the requirements may not have (scalable) solutions (see comment on s4.3
below).
s2 (page 4):
An ESI (either for a point-to-point or multipoint connectivity) is
associated with a forwarding path within the service provider’s
network and that is different from an Ethernet Class of Service
(CoS) which is associated with the frame Quality-of-Service
treatment by each node along the path defined by the ESI.
I don't understand 'and that is different from' here. The two halves of the
sentence appear to be addressing incomparable things (the whole instance vs. a
characteristic of the instance/network).
s2 (page 4): The term 'filtering database' appears suddenly here. Where will
the reader find a definition of this term? I think I understand what is going
on but it would be useful to point to where the term is defined.
s4.1 (Note-2): What is a 'feature server'?
s4.1 (below the table):
If a PE uses an S-VLAN tag for a given ESI (either by adding an S-
VLAN tag to customer traffic or by replacing a C-VLAN tag with a S-
VLAN tag), then the frame format and EtherType for S-VLAN shall
adhere to [P802.1ad].
This appears to be a 'requirement' on framne format rather than a discussion of the service mapping. Does it deserve a separate sub-section? This might also contain the text from the second half of the next to the last para of s4.1.
s4.2, next to last para:
Therefore, the peering requirement can be generalized such that the
media-independent protocols (RSTP/MSTP, CFM, etc) that require
peering are for VLAN-based or VLAN-bundling Attachment Circuits.
I am not sure how this generalization follows from the argument in the previous
discussion. There is discussion of types of attachment circuit, type of media
and protocols used and I cannot immediately see how the discussion brings us to
this statement.
s4., para 1: 'The effect... should be well known.' By whom? I think that actually the following sentences describe the consequences, so this statement is unnecessary/confusing. If the following sentences are not adequate or the effects are deemed not to be obvious then a reference would be the best option.
s4.3: The statement that the scalability of partial mesh detection has not been
solved might be seen as a show stopper for this proposal! I am not clear how
this meshes with the statement in the following paragraph that 802.1ag
procedure will 'do (at least some of) the job'. This seems to be a mandatory
requirement for which it is not clear that a solution exists.
s4.4, para 2: 'described in Section 7'; Of what document? Not this one but
probably [IGMP-SNOOP] = RFC 4541.
s4.4, para 3: Does there need to be a reference to define what an MDT is?
RFC 2119 language: The document is Informational - there appears to be exactly
one instance of SHOULD (s4.4, about 16 lines down page 12). I suspect that
this could be eliminated since it is actually advisory and the following
sentence suggests that using the proposal may be inappropriate in some
circumstances.
Editorial:
General: The document contains in excess of 40 non-ASCII characters (mainly
non-ASCII single and double quotation marks) - idnits will tell you where.
General: The document is infested with large numbers of undefined acronyms.
General: There are a significant number of definite and indefinite articles missing, e.g., (Abstract) s/then IPLS solution/then an IPLS solution/, s/Majority/The majority/, s/addressed in IEEE 801.1ad/addressed in the IEEE 801.1ad/ (I will send a marked up file to the authors separately with my suggestions for additional articles and notes of the undefined acronyms).
General: Cross references to figures and sections should be consistent and in
the usual form (e.g., Section 3, Figure 2).
Abstract: The Abstract is probably overlong (17 lines which exceeds the normal
guideline of 10 lines), contains references and also a number of unexpanded
acronyms (VPLS, IPLS, CE, maybe IEEE).
s4.1: The table should get a caption and a number (through which it can be
referenced in the text).
s5.1: 'Such network topologies are designed to protect against the failure or
removal of network components with the customer network...' s/with/from/
probably.
s9: References to where the security discussions for VPLS and H-VPLS need to be
given.
References:
IGMP-SNOOP is now RFC 4541
Eth-OAM and MFA-Ether need pointers to the Internet Draft file
____________
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf