Subject: [Gen-art] Gen-art Review: draft-ietf-l2vpn-vpls-ldp-07

From: Elwyn Davies <[email-masked]>
Date: Mon, 26 Sep 2005 19:01:25 +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-ldp-07.txt
Intended Status: Proposed Standard
Shepherding AD: Mark Townsley
Review Trigger: IESG Telechat 29/9/05

Summary:
This document is probably nearly ready for Proposed Standard.  There are a 
number of minor issues (barely more than editorial) plus some editorial nits 
that ought to be fixed.  The reason that I say 'probably' is because l2vpn is 
submitting two different ways to do VPLS service (this document using LDP and 
draft-ietf-l2vpn-vpls-bgp-05 using BGP).  There are significant areas relating 
to technical issues within the service that are discussed in one document rather 
than the other.  In general this document is more comprehensive and may 
therefore be deemed to be closer to readiness, but I am slightly surprised that 
there is not consistency of treatment across the two documents.

Review:

Generally thsi document is well written although I found some later parts rather 
high level (ss10 and 11) and 'hand wavy'.  I don't think this is a problem in 
general.  There are a number of minor issues and editorial nits that need 
fixing.  I also noted a number of inconsistencies of coverage between this 
document and the corresponding BGP based document 
(draft-ietf-l2vpn-vpls-bgp-05).  In general this document had the much broader 
coverage.  Assuming this is what the wg and authors intended this is good.

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.

Semi-substantive:

s6.1.1: AGI contains a name:  are there any constraints on the encoding of this 
name?

s6.1.1: I can't find the field 'VC info length' in PWE3-CTRL.  Is PW info length 
intended?

s6.1.1: Should mention that Sub-TLV type numbers for the Interface Parameters 
are defined in [IANA].  I think the Requested VLAN ID is specific to this document.

ss6.1.1/10: The acronym MTU is overloaded ('standard' usage in s6.1.1, unuusual 
usage in s10)

s6.1.1: Requested VLAN ID: I think this is specific to this document (it isn't 
in PWE3-CTRL).  Hence the size and encoding of the VLAN ID should be specified 
here.  Also there is no mention of the VLAN ID in s6.1 contrary to what is said 
here.

s6.2.1: Length: Should specify that it is in octets.

s6.2.2: Should validate that length is a multiple of 6 octets.

s16: should refer to RFC3036 (LDP) registry in which MAC List TLV type is to be 
registered.  Also the name is inconsistent with 6.2 (MAC TLV vs MAC List TLV)

s18: The terminology used in this section is not consistent with PWE3-CTRL (VC 
vs PW).

Editorial:
general: Figures don't have titles or numbers.

Abstract: Refs in abstract are frowned on.  2nd para should probably explicitly 
mention LDP instead of refing pwe3 control protocol.

s4: Contains many unexpanded acronyms.  Also some terminology definitions would 
be useful with a ref for PE/CE etc terminology.

s4 (Fig 1): Boxes with C1 are CE's for consistency with PE boxes - put C1 
outside boxes.

s4.4: Reference needed for STP.

s6.1.1: A section ref for PWE3-CTRL would help.

s6.2: Should clarify that Address Withdraw is an LDP message and the MAC List 
TLV is an LDP TLV.

s6.2: s/in consideration/affected/

s6.2.2: title should refer to MAC List TLV (not MAC TLV)

s7.2: Unexpanded acronym MSTP.

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