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

From: Elwyn Davies <[email-masked]>
Date: Mon, 26 Sep 2005 19:14:16 +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 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.

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.

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)

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

- 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

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

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

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 13:26:39 -0700 (PDT)

Thanks for the updated review.

On Mon, 26 Sep 2005, Elwyn Davies wrote:

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

Okay.  I agree with most of the comments, so I'll rev the document
with those and send you and updated version.  Below, I'll discuss some
of the comments that may need further elaboration.

> and s4 talks only about Ethernet frames.

Okay.

> strategy would help both implementors and users.

Okay.

> the mechanism used is a particular implementation or specialization of

The first: a general review of autodiscovery.  I'll make that clear.

> PE2) but this is not stated explicitly (as compared with 3.4.1 and 3.4.2)

Okay.  Will tweak wording.

> - LDP talks about MAC address aging but BGP doesn't

(1) Some background:  both the BGP and LDP specs are about the control
plane -- signaling and (in the case of BGP) auto-discovery.  The data
plane is identical.  Thus, MAC address learning, aging, the treatment
of .1p bits, multicast/broadcast, etc. is *identical* in both schemes.

There was once talk of a common "data plane" document that captured
these aspects in a single document.  Ideally, this should have been
done; however, there was not enough incentive or enthusiasm to follow
through.  Also, the data plane part mostly just says "this works just
like Ethernet bridging."

Thus, whether one should talk about MAC aging or not is judgment call.
If you say that VPLS learning is similar to MAC learning, then it
follows that aging works similarly.  I suppose it doesn't hurt to say
so, though.  Similarly for multicast, or the treatment of .1p bits.

At this stage, it would be a fair amount of work to separate the
control and data plane descriptions.  The easy way out is to try to
keep the material as much in sync as possible.  (Thanks for your help
in this.)

> to PWE3-ETH and doesn't mention the encapsulation in PWE3-CTRL

Historical.  All encaps were originally in PWE3-CTRL, then they got
broken out.  Will fix.

> - LDP talks about treatment of multicast (s4) by e.g. using broadcast etc which

See (1)

> relevance.  LDP hardly mentions scaling.

Actually, I would really like the LDP document to talk about scaling!
The LDP doc acknowledges a control plane scaling issue, and proposes
H-VPLS as a solution.  However, H-VPLS has serious implications on the
scaling of the data plane, which is not mentioned at all.

BGP has long since addressed the control plane scaling issue (with
Route Reflectors and/or BGP confederations).  I'll be happy to mention
that.

> necessary? or is equivalent to the stuff regarding the P bit in s4.1 of BGP

Again, see (1).  This really orthogonal to how VPLS is signaled, or
the specifics of forwarding Ethernet frames in a VPLS.  However, I'll
do my best to make the data plane aspects the same between the two docs.

> - BGP: Does this support 802.1p bits as is claimed for LDP - 802.1p is not

In LDP, the only mention I found is:

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

Did I miss something?

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

The two "full meshes" are at different levels -- all PEs are fully
meshed with *tunnels* and all PEs in a given VPLS are fully meshed
with *PWs*.  I'll clarify.

> any introduction: It should probably be introduced in s2.1.

Thanks, I'll fix these.

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

Good catch!  Cut-and-paste error when migrating from nroff to xml.

Kireeti.
-------

---

From: Mark Townsley <[email-masked]>
Date: Tue, 27 Sep 2005 17:51:03 +0200

Kireeti,

Sounds like you are going to rev the document with somewhat substantive 
changes based on the gen-art review. As such, I'm defering this document 
from this week's telechat. I will put it back on as soon as I see a -06. 
Note that I am going to be on paternity leave for a few weeks starting 
sometime between now and Oct 28 - if you can get the document revved 
before next Wednesday (and the baby hasn't been born yet) I will ask for 
it to be added to the next telechat (Oct 11).

Thanks,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 27 Sep 2005 17:52:55 +0200

In previous email:

s/Oct 11/Oct 13

Thanks,

- Mark