Gen-art review of draft-ietf-l2vpn-vpls-bridge-interop-02.txt

[Elwyn Davies <elwynd at dial.pipex.com>]

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.org
https://www1.ietf.org/mailman/listinfo/ietf