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

From: Kireeti Kompella <[email-masked]>
Date: Wed, 28 Dec 2005 19:01:02 -0800

Hi Elwyn, All:

I've just posted an updated version of this draft, incorporating your comments.
I've gone over your comments below, and indicated the "fix" made.  The new
draft should be available shortly in the ID repository.

| 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 probably almost ready for PS.  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.  Having reviewed the draft defining the
| alternative way of setting up VPLS using LDP, there appear to be a
| number of areas where this document does not address technical
| issues that are covered by the LDP document.  In some cases these
| may not be relevant to this document, but I think that it ought
| to cover MAC address aging and scaling. Incidentally the LDP based
| document is much less reticent about VPLS being about extending
| Ethernet LANs.

The comment about "e****net" is well-taken; the abstract has been
updated to explicitly mention Ethernet, as well as some other sections.
Also, MAC learning is now explicitly mentioned in the first para of the
Intro.

Also, in the Data Plane section, there is a new section on aging,
and more detail on learning.

| 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 individual parts needs to be spelt out up front.  Also I am
| unsure as to whether some of the issues covered in the LDp based
| VPLS specification should be covered in this document as well.
| [The SAFI issue previously suggested has been cleared.]
|
|
| 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.

Hopefully, the updates to the Abstract and Intro cover this.

| 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.

All explained in much greater detail in the intro to section 3.2 Signaling.

| 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]?

The intention was a combination of the reasons you mentioned; but this
reference has now been removed, as it appears to have caused more
confusion than clarification.

| 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...

Done.

| 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?

Clarified in the intro to 3.4.

| 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.

Done.

| 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)

Done.

| Consistency between this document ('LDP') and draft-ietf-l2vpn-vpls-bgp-05 ('B
GP'):
| - LDP talks about MAC address aging but BGP doesn't

Fixed.  New section 4.2.2.

| - BGP recommends encapsulation via PWE3-CTRL whereas intro of LDP goes
| directly to PWE3-ETH and doesn't mention the encapsulation in PWE3-CTRL
|
| - LDP talks about treatment of multicast (s4) by e.g. using broadcast
| etc which is barely treated in BGP

Fixed.  New section 4.2.4.

| - Scaling issues: LDP discusses a number of hierarchical solution but BGP
| doesn't: LDP s7.1 talks about specialised encapsulations which may be of
| relevance.  LDP hardly mentions scaling.

Fixed (new section 3.6 on scaling BGP control plane).

| - Encapsulation: LDP s7.1 has a deal of discussion of 'service delimiting'
| encapsulation that is missing from BGP.. is this a drop off in BGP or not
| necessary? or is equivalent to the stuff regarding the P bit in s4.1 of BGP
|
| - LDP Qualified/Un-qualified learning: not clear if this is
| interesting/available in BGP
|
| - BGP: Does this support 802.1p bits as is claimed for LDP - 802.1p is not
| mentioned.

The three above issues (and multicast) are completely identical for
BGP and LDP; they relate to the VPLS data plane which is identical
whether the signaling is BGP or LDP.  (Side question: what exactly
are you referring to as "802.1p support" in the LDP spec?  The only
thing I see is, towards the end of section 8:

  The Ethernet VLAN PW provides a simple way to preserve customer
  802.1p bits.

In any case, I provided text for this, section 4.2.7.)

At one time, there was a suggestion that all discussion of the VPLS
data plane be removed from both drafts and moved to a common draft,
but this was overruled.  So, I'll do my best to keep the two as
similar as possible without overt plagiarism.

| Editorial:
| global: Need to decide between 'fully-meshed' and 'fully meshed'.

Done: "fully meshed"

| s1, para 1: s/glues/glues together/

Done.

| 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/

All done.

| s2.2: The statement that PEs are fully(-)meshed is duplicated (para 1
| and para 3).

Clarified the distinction between fully meshed *control* and *data*
planes.

| s3.4.1: There ought to be a reference for the Spanning Tree protocol.

Done.

| s6: The term 'P router' (which comes from [9], I think) is used without
| any introduction: It should probably be introduced in s2.1.

Done.

| Tail: Yakov's email address is same as Kireeti's!

That's an impressive catch!  Fixed.

Thanks again for the detailed read.

--
Kireeti
-------

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