Document: draft-ietf-l2vpn-vpls-bgp-05 Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Sunday 9/25/2005 7:55 AM CST Telechat Date: Thursday 9/29/2005 Summary: Technically this is almost ready for PS. I have one possible issue relating to the appropriateness of the use of a private allocation SAFI number in a standards track document. In terms of comprehensibility for the the future there are a number of areas which I feel it is really important to improve by adding a couple of sentences of explanation as to the purpose and motivation, firstly of the document as a whole and then to a couple of subsections -it almost feels as if the document is trying to avoid saying that VPLS is about extending e****net. There are also a few editorial nits. Review: -------- Technically the document appears to be very well written My major concern is that the purpose and motivation both of the whole document and some individaul parts needs to be spelt out up front. Substantive: s3.2.2: Is it appropriate to use a 'private' category SAFI identifier here? Clarifications of purpose/motivation needed: Abstract/Intro/General: A reader with no previous experience of the l2vpn wg coming to this document will potentially be confused by the generic words used in the title, abstract and introduction which may lead them to expect this document to be concerned with more generic l2 services than is apparently the case. I had to go back through the framework document to the l2vpn charter to find that the VPLS service is specifically intended for extending Ethernet LANs. It would greatly reduce confusion if this was made clear up front. Then it is more obvious why ss3.4.x talk only about 'carrying Ethernet traffic' etc., and s4 talks only about Ethernet frames. s3: particularly s3.2.1 and s3.3, para 1: A paragraph on the motivation for the use of VBO, VBS, LB would help (presumably to do with partition and allocation of the label space). Some brief advice on allocation strategy would help both implementors and users. s3.1.2: What is the point of the statement "A more generic autodiscovery mechanism is described in [8]."? Is the reader being pointed to this for general review of autodiscovery mechanisms? Is this an alternative mechanism? If so how could it be used? Or is this just to indicate that the mechanism used is a particular implementation or specialization of that in [8]? 3.4 introduction: It would be helpful to make a general statement that the various solutions constrain the inter-AS infrastructure in different ways - as it stands the various statements are confusing - leading to reactions like my next comment... s3.4.1: Why does this suddenly mention Ethernet specifically (probably because of the first clarification point above, but..)? I would have thought that the Inter-AS link has to be able to carry Ethernet frames but does it have to be Ethernet? s3.4.2: The first sentence of the last para ought to be placed much earlier in the section: as it stands the talk of label swapping comes before this statement and is confusing. s3.4.3: appears to require inter-AS MPLS (talk of LSPs between PE1 and PE2) but this is not stated explicitly (as compared with 3.4.1 and 3.4.2) Editorial: global: Need to decide between 'fully-meshed' and 'fully meshed'. s1, para 1: s/glues/glues together/ s1, next to last para: acronym PE is not defined until s2 s1: It may be a bit pedantic but LAN is not expanded. s2.1: SP is not expanded. s2.2, s4.2.3: s/full-meshed/fully-meshed/ s2.2: The statement that PEs are fully(-)meshed is duplicated (para 1 and para 3). s3.4.1: There ought to be a reference for the Spanning Tree protocol. s6: The term 'P router' (which comes from [9], I think) is used without any introduction: It should probably be introduced in s2.1. Tail: Yakov's email address is same as Kireeti's!