Subject: [Gen-art] RE: review of draft-ietf-l2tpext-pwe3-ethernet-07.txt

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Wed, 5 Jul 2006 18:12:08 -0700

Mark, Francis,

Please see response inline, I believe I addressed
all issues.  Please check a look at the updated 
version attached.

thanx,
Alice

> -----Original Message-----
> From: Mark Townsley (townsley)
> Sent: Friday, 30 June, 2006 8:18
> To: Francis Dupont
> Cc: [email-masked]; [email-masked]; [email-masked]; Maria A. 
> Dos Santos (mariados); Jari Arkko
> Subject: Re: review of draft-ietf-l2tpext-pwe3-ethernet-07.txt
> 
> 
> Thanks for the review, Francis. I agree that the document is in need 
> of another revision. Alice, do you have the source and can you take on

> addressing these comments?
> 
> Please see inline. I suggest some text for some of the comments, and 
> have one or two questions as well.
> 
> Thanks,
> 
> - Mark
> 
> Francis Dupont wrote:
> > I am the assigned Gen-ART reviewer for this I-D.
> > For background on Gen-ART, please see the FAQ at 
> > <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> >
> > Please resolve these comments along with any other Last
> Call comments
> > you may receive.
> >
> > Summary: not ready
> >
> > The document has a real problem with its style: it is very
> unpleasant
> > to read. Unfortunately this is not something the RFC editor
> can fix...
> >
> > Detailed comments/suggestions:
> >  - Abstract: This document describes transport -> the transport?

ok

> >  - 1.1: remove trailing "." of PE definition

ok

> >  - 1.1: I suggest to introduce here the L2TPv3 messages as
> >    imported abbreviations in the logical (i.e., not alpha) order.

ok

> >  - 1.2 (NSP function): Ethernet packets -> Ethernet frames

ok

> >  - 1.2: as VLAN tags are in some further cases 802.1q tags,
> >    I propose to cite 802.1Q the first time and use "VLAN" everywhere
> >    at the exception of 802.1Q specific places.

ok

> >  - 2.2 c): must -> MUST?

ok

> >   
> >  - 2.3.2: to indicate the Ethernet interface -> plural
> without "the"?

ok

> >  - 3.2: may -> MAY?

ok

> >   
> Agree with all of the above, including RFC2119 language suggestions.
> >  - (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.
> >   
> 
> I agree that this is confusing, and I believe it was text 
> that was asked for during AD review ;-)
> 
> How about changing this text:
> 
>    As a result, the pseudowire endpoints SHOULD support
>    Fragmentation and Reassembly procedures specified in Section 5 of
>    [L2TPFRAG] or section 4.1.4 of [RFC3931] when the Ethernet 
> payload is
>    IPv4.  Only one of these methods SHOULD be used for a 
> given Ethernet
>    PW.
> 
> to:
> 
>    This is not specific only to Ethernet over L2TPv3, and the 
> base L2TPv3 specification 
>    [RFC3931] provides general recommendations with respect to 
> fragmentation
>    and reassembly in section 4.1.4. "PWE3 Fragmentation and 
> Reassembly" [L2TPFRAG] 
>    expounds on this topic further, including a fragmentation 
> and reassembly 
>    mechanism within L2TP itself in the event that no other 
> option is available. 
>    Implementations MUST follow these guidelines with respect 
> to Fragmentation
>    and reassembly.
> 
> (Note that I use "MUST" above, but [L2TPFRAG] doesn't mandate 
> the L2TP-specific fragmentation and reassembly method. It 
> allows for IP fragmentation and reassembly as well)

ok

> 
> 
> >  - 4: please introduce the AC abbrev

ok

> >  - 4: the 802.1Q tag -> a VLAN tag

ok

> >  - 4: preamble or FCS -> preamble and FCS

ok

> >  - 4: IPSec -> IPsec (cf RFC 4301 introduction)

ok

> >  - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't 
> parse this statement
> >   
> How about:
> 
> "While architecturally [RFC3985] outside the scope of the L2TPv3 PW 
> itself, if VLAN tags are present, the NSP may rewrite VLAN tags on 
> ingress or egress from the PW (see section 3.1)."

ok

> 
> >  - 4: there is no TOS octet or QoS field in the IP header 
> (look at RFC 2474?)
> >   
> No doubt. We need to at a minimum change this to "ToS bits"and strike 
> "IP QoS field" - the paragraph should perhaps simply be rewritten to 
> refer to DSCP only.

ok

> >  - 4: 802.1Q CS and ... -> too many "and" (note that here 
> 802.1Q is the
> >    right term)

ok

> >  5: should -> SHOULD ??
> >   
> I'm not entirely convinced that this is a SHOULD given that it isn't 
> really a protocol mechanism that we are defining here, but a 
> deployment 
> recommendation.

stay as is

> >  9.1 L2TPFRAG: missing I-D name 
> (draft-ietf-pwe3-fragmentation-10.txt?)
> >   
> Yes, that's it.

ok

> > Regards
> >   
> Many thanks for the careful review. You caught many mistakes.
> 
> - Mark
> > [email-masked]
> >
> >   
> 
> 
_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Mark Townsley <[email-masked]>
Date: Thu, 06 Jul 2006 09:57:32 -0500

Thanks, Alice. There are additional comments from other IESG members 
that we need to address:

*Brian Carpenter:*
*Discuss:*

 >  - 2.2 c): must -> MUST?

...

 >  - 3.2: may -> MAY?

...

 >    (fragmentation/reassemble recommendation) because it is a layer 
violation
 >    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.