Subject: [Gen-art] Gen-art Review: draft-ietf-l2vpn-vpls-bgp-05

From: Elwyn Davies <[email-masked]>
Date: Sun, 25 Sep 2005 13:55:21 +0100

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Document: draft-ietf-l2vpn-vpls-bgp-05.txt
Intended Status: Proposed Standard
Shepherding AD: Mark Townsley
Review Trigger: IESG Telechat 29/9/05

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!

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 26 Sep 2005 10:29:04 -0700 (PDT)

> outside the GenART group are being copied.

Thanks for taking the time to review this document!

> number in a standards track document.

Let me respond first to the SAFI value issue, as requested by Brian.
I'll address the rest of the issues in a separate email.

As stated in the IANA registry for SAFIs:

| AFI - Subsequence Address Family Identifier per [RFC2858]
|
| (last updated 15 February 2005)
|
| As specified in this document, the MPL_REACH_NLRI and
| MP_UNREACH_NLRI attributes contain the Subsequence Address Family
| Identifier (SAFI) field. The SAFI name space is defined in Section
| 9.  The IANA will maintain and register values for the SAFI
| namespace as follows.  SAFI value 0 is reserved.  SAFI values 1, 2,
| and 3 are assigned in this document.  SAFI values 4 through 63 are
| to be assigned by IANA using the "IETF Consensus" policy defined in
| RFC2434.  SAFI values 64 through 127 are to be assigned by IANA,
| using the "First Come First Served" policy defined in RFC2434.  SAFI
| values 128 through 255 are for "private use", and values in this
| range are not to be assigned by IANA.

So, the SAFI value of 65 is *not* private use, but rather first-come-
first-served; and there is precedence in the use of FCFS for PS
allocations.  (You may be confusing this doc with rfc2547bis, which
*does* request a Private Use value for their SAFI [128], and argues
that extensive deployment justifies the request.)

As to the "delicate dependency" with draft-ietf-l3vpn-bgpvpn-auto, it
can be addressed by moving the statement to whichever document reaches
IANA later.  It isn't completely clear which of the two documents will
progress to the IANA allocation stage first, since Mark as shepherding
AD has requested that the BGP VPLS document wait for the LDP VPLS
document so that both progress together.

Kireeti.
-------

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 26 Sep 2005 19:20:13 +0100

That's OK then, I guess.

I have updated my review accordingly.  However, you will also find that 
I have added  a bit about some inconsistencies as regards technical 
issue coverage between the BGP and the LDP versions of VPLS setup.  The 
LDP document covers a number of issues that the BGP one doesn't notably 
MAC address againg and scalability.  It may be that this has been 
discussed in the wg - if so please let me know, but it seemed somewhat 
asymmetrical.

Regards,
OK