Elwyn,
Thanks for your detailed comments. We have updated the draft according to
your comments,
and have answered some of your questions (see below). The new version of the
draft will be
posted next week after the Vancouver IETF.
Thanks,
Marc
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.
As a general comment, wherever the BGP draft does not address specific
Ethernet issues that
are addressed in the LDP draft, BGP authors can borrow the corresponding
paragraphs.
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
The encapsulation of Ethernet over PWE is defined in PWE3-ETH not 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.
The LDP draft specifies how a VPLS service can scale by using hierarchical
constructs.
- 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?
The PWE3-CTRL draft specifies the AGI and the LDP draft does not impose any
restrictions.
s6.1.1: I can't find the field 'VC info length' in PWE3-CTRL. Is PW info
length intended?
Fixed
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.
Fixed. Added ref to PWE3-ETH.
ss6.1.1/10: The acronym MTU is overloaded ('standard' usage in s6.1.1,
unuusual usage in s10)
Fixed.
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.
It is defined in [PWE-ETH].
s6.2.1: Length: Should specify that it is in octets.
Fixed.
s6.2.2: Should validate that length is a multiple of 6 octets.
Fixed.
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)
Fixed.
s18: The terminology used in this section is not consistent with PWE3-CTRL
(VC vs PW).
Fixed.
Editorial:
general: Figures don't have titles or numbers.
Fixed.
Abstract: Refs in abstract are frowned on. 2nd para should probably
explicitly mention LDP instead of refing pwe3 control protocol.
Fixed.
s4: Contains many unexpanded acronyms. Also some terminology definitions
would be useful with a ref for PE/CE etc terminology.
We have added a terminology section to the draft.
s4 (Fig 1): Boxes with C1 are CE's for consistency with PE boxes - put C1
outside boxes.
Fixed.
s4.4: Reference needed for STP.
Fixed.
s6.1.1: A section ref for PWE3-CTRL would help.
A reference to PWE3-CTRL is defined in sections 6.1 and 6.1.1.
Is there any other reference needed?
s6.2: Should clarify that Address Withdraw is an LDP message and the MAC
List TLV is an LDP TLV.
Fixed.
s6.2: s/in consideration/affected/
Fixed.
s6.2.2: title should refer to MAC List TLV (not MAC TLV)
Fixed.
s7.2: Unexpanded acronym MSTP.
Fixed.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
