[Gen-art] Re: review of draft-ietf-l2tpext-pwe3-ethernet-07.txt
Mark Townsley <townsley@cisco.com> Thu, 06 July 2006 20:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fya92-00027t-Lq; Thu, 06 Jul 2006 16:08:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fya92-00027a-38 for gen-art@ietf.org; Thu, 06 Jul 2006 16:08:16 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyVVj-0000Sr-Fu for gen-art@ietf.org; Thu, 06 Jul 2006 11:11:23 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyVIe-00073q-E3 for gen-art@ietf.org; Thu, 06 Jul 2006 10:57:54 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 07:57:49 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="31322032:sNHT62123908"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66EvnAo026754; Thu, 6 Jul 2006 10:57:49 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66EvdRO011247; Thu, 6 Jul 2006 10:57:49 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 10:57:48 -0400
Received: from [192.168.2.10] ([10.82.217.115]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 10:57:47 -0400
Message-ID: <44AD24DC.1020704@cisco.com>
Date: Thu, 06 Jul 2006 09:57:32 -0500
From: Mark Townsley <townsley@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: "Maria A. Dos Santos (mariados)" <mariados@cisco.com>
References: <F370ADC0040A424E8AB27D2BCEE35D0C024D781B@xmb-sjc-222.amer.cisco.com>
In-Reply-To: <F370ADC0040A424E8AB27D2BCEE35D0C024D781B@xmb-sjc-222.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Jul 2006 14:57:47.0608 (UTC) FILETIME=[8B576D80:01C6A10C]
DKIM-Signature: a=rsa-sha1; q=dns; l=5005; t=1152197869; x=1153061869; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20<townsley@cisco.com> |Subject:Re=3A=20review=20of=20draft-ietf-l2tpext-pwe3-ethernet-07.txt |To:=22Maria=20A.=20Dos=20Santos=20(mariados)=22=20<mariados@cisco.com>; X=v=3Dcisco.com=3B=20h=3DxaeahymOkxNw8da9yaH7AyKe6L4=3D; b=DVp54cIb5pkKOLdwDYlYSGpDG8sSXlR/gDHp7IOSyPkEQuZp28BCVTZHR4RHjG/yTo0QbJfU uKmTbChuaSQGo17KRCH3iAuamdBhRVSyQQN+s0240i+nnBkOswJvcZcl;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: gen-art@ietf.org, Jari Arkko <jari.arkko@piuha.net>, rahul@juniper.net
Subject: [Gen-art] Re: review of draft-ietf-l2tpext-pwe3-ethernet-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
Thanks, Alice. There are additional comments from other IESG members that we need to address: *Brian Carpenter:* *Discuss:* *[2006-07-03]* Points from Gen-ART review by Francis Dupont: > - 2.2 c): must -> MUST? ... > - 3.2: may -> MAY? ... > - (technical) 3.3: I am not convinced at all by the very last part > (fragmentation/reassemble recommendation) because it is a layer violation > and the goal (manage the issue at only one place as explain in > L2TPFRAG section 5.1) is not explained. ... > - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't parse this statement [BC] I think I can, but the sentence is very hard to understand. For clarity, shouldn't it be something like The VLAN tags of an Ethernet VLAN PW may be rewritten by NSP at the egress LCCE, which is outside the scope of this document (see Section 3.1). > - 4: there is no TOS octet or QoS field in the IP header (look at RFC 2474?) [BC] Indeed, there is no "for example" about it; there only the DSCP. > 5: should -> SHOULD ?? *Comment:* *[2006-07-03]* See editorial issues in Gen-ART review: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-l2tpext-pwe3-ethernet-07-dupont.txt *Lars Eggert:* *Discuss:* *[2006-06-30]* Section 5., paragraph 3: > LCCEs SHOULD monitor for congestion (by using explicit congestion > notification, or by measuring packet loss) in order to ensure that > the service using the Ethernet or Ethernet VLAN PW may be maintained. > When severe congestion is detected (for example when enabling > Sequencing and detecting that the packet loss is higher than a > threshold) the Ethernet or Ethernet VLAN PW SHOULD be halted by > tearing down the L2TP session via a CDN message. The PW may be > restarted by manual intervention, or by automatic means after an > appropriate waiting time. Note that the thresholds and time periods > for shutdown and possible automatic recovery need to be carefully > configured. This is necessary to avoid loss of service due to > temporary congestion, and to prevent oscillation between the > congested and halted states. RFC3985 also says: "Where congestion is avoided by shutting down a PW, a suitable mechanism must be provided to prevent it from immediately returning to service and causing a series of congestion pulses." I don't see such a mechanism in this draft, only the above acknowledgment of the issue and the recommendation of careful configuration. (This is identical to the DISCUSS I have raised against draft-ietf-pwe3-atm-encap. As far as I know, PWE3 is working on an approach for addressing this. This document, however, belongs to a different WG, so I'm not sure if any resolution that PWE3 comes up with would apply to this document as well. I'd hope that it would - can the authors/ADs confirm?) *Cullen Jennings:* *Discuss:* *[2006-07-05]* I may not understand the congestion control technique but it looks like it says, "in case of congestion, pull the plug". I don't believe anyone will implement this congestion control suggestions - and if they do, I don't believe the resulting systems will be usable - they will be impossible to manage not to mention the incredible DOS opportunities. No advice on the threshold is provided. I think this needs to be updated to either be clear no congestion control is provided. The section titled "Applicability Statement" gives me no idea where this is applicable and where it is not. *Dan Romascanu:* *Discuss:* *[2006-07-03]* I made the following two comments during the IESG LC. The comments were not addressed: 1. The I-D speaks about 'Ethernet' but does not provide any reference. What version of the Ethernet standard is targeted here? The latest approved version of the Ethernet standard is IEEE Std 802.3-2005, but the IEEE 802.3 WG also has in works an extension of the frame size as IEEE 802.3as. One cannot talk about Ethernet PDU and MTU without a proper reference. 2. The I-D speaks about 'Ethernet VLAN'. Strictly speaking there is no such thing, Virtual LANs are being defined by IEEE 802.1 and not only for Ethernet. However accepting terminology license based on the de-facto reality that most if not all VLANs run over Ethernet, there still is a need to specify if the document refers to IEEE 802.1Q VLANs (one 12-bit tag) or IEEE 802.1ad which accommodate multiple tags and introduce the concepts of Customer VLAN and Service VLAN. Maybe the VLANs referred in this I-D are transparent to the type of VLANs that are being connected, but even so there should be text explaining this. Maria A. Dos Santos (mariados) wrote: > Mark, Francis, > > Please see response inline, I believe I addressed > all issues. Please check a look at the updated > version attached. > > thanx, > Alice > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] review of draft-ietf-l2tpext-pwe3-ether… Francis Dupont
- [Gen-art] review of draft-ietf-l2tpext-pwe3-ether… Francis Dupont
- Re: [Gen-art] review of draft-ietf-l2tpext-pwe3-e… Brian E Carpenter
- [Gen-art] Re: review of draft-ietf-l2tpext-pwe3-e… Mark Townsley
- [Gen-art] RE: review of draft-ietf-l2tpext-pwe3-e… Maria A. Dos Santos (mariados)
- [Gen-art] RE: review of draft-ietf-l2tpext-pwe3-e… Maria A. Dos Santos (mariados)
- [Gen-art] Re: review of draft-ietf-l2tpext-pwe3-e… Mark Townsley