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

From: "Marc Lasserre" <[email-masked]>
Date: Tue, 8 Nov 2005 00:20:43 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art