Subject: [Gen-art] Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt

From: "Maria A. Dos Santos \(mariados\)" <[email-masked]>
Date: Fri, 4 Aug 2006 12:03:03 -0700

Hi all,
 
The following is the consolidated list of all the LC comments and
responses
by different people.  I highlighted the responses and what/how will be
replaced.
This has been reviewed by Ignacio Goyret once already and I already 
incorporated his last batch of editorial change requests in the attached
version 8 of the draft.
 
There is still one comment from Cullen Jennings which is not resolved
yet, but no response from Cullen yet.  Do others want to advice on how
to handle this comment?
 
regards,
Alice
 
------------------------------------------------------------------------
-------------------------------------

###
Comments raised by Francis Dupont, with additional comments/
responses inserted by Brian Carpenter, Mark Townsley and 
Ignacio Goyret.
 
 - Abstract: This document describes transport -> the transport?
 
Fixed
 
 - 1.1: remove trailing "." of PE definition
 
Fixed
 
 - 1.1: I suggest to introduce here the L2TPv3 messages as
   imported abbreviations in the logical (i.e., not alpha) order.
 
Added section 1.2 to introduce the l2tp message types
 
 - 1.2 (NSP function): Ethernet packets -> Ethernet frames
 
Fixed
 
 - 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.
 
Inserted elaboration for terms such as "Ethernet" and "VLAN" in 
Introduction section.
 
 - 2.2 c): must -> MUST?
 
Fixed
 
 - 2.3.2: to indicate the Ethernet interface -> plural without "the"?
 
Fixed
 
 - 3.2: may -> MAY?
 
Fixed
 
 - (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.
 
Replacement suggested by Mark Townsley.
 
   "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."
 
has been changed 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.

 - 4: please introduce the AC abbrev
 
Fixed
 
 - 4: the 802.1Q tag -> a VLAN tag
 
Fixed
 
 - 4: preamble or FCS -> preamble and FCS
 
Fixed
 
 - 4: IPSec -> IPsec (cf RFC 4301 introduction)
 
Fixed
 
 - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't parse this
statement

Replacement proposed by Mark Townsley:
 
  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)."
 
Replacement proposed by Brian Carpenter:
 
  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).
 
Mark's suggestion is incorporated into draft.

 - 4: there is no TOS octet or QoS field in the IP header (look at RFC
2474?)

Mark Townsley:
 
  > 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.

Exchanges between Brian and Ignacio:
 
  >>>[BC] Indeed, there is no "for example" about it; there only the
DSCP.
  >> 
  >> 
  >> RFC2474 specifically refers to that byte as "the TOS octet" (eg,
see 
  >> the second to last paragraph on the abstract, page 2).
  >> 
  >> How about eliminating the parenthesized "for example, according to
DSCP"?
  >> Would that be sufficient?
  >
  >Well, it is called the TOS octet in IPv4 and the Traffic Class octet
in
  >IPv6 - the only phrase that applies to both is DSCP. So either you
have 
  >to put "TOS or Traffic Class octet" or refer to 2474, I think.

Changed reference to "DS field" and added reference to RFC2474.

 - 4: 802.1Q CS and ... -> too many "and" (note that here 802.1Q is the
   right term)
 
Fixed
 
 5: should -> SHOULD ??
 
>From Mark:
 
  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.
 
So this stays unchanged.

 9.1 L2TPFRAG: missing I-D name (draft-ietf-pwe3-fragmentation-10.txt?)
 
Fixed

########################################################################
###
*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?)
 
Confirmed by Stewart Bryant and Mark Townsley that the PWE3 congestion
work 
would be general and applicable to both L2TP and 
MPLS based Pseudowires.

########################################################################
###
*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.
 
>From what I understand, the draft is inline with the current state of
congestion
control for emulation technologies, and PWE3 WG is currently conducting 
further study on the topic.  Once we get the result of that, this draft
and all other pwe drafts (both l2tp and mpls) will leverage from that
mechanism.  So at this point, the goal of the "Congestion Control"
section 
in this draft is only to emphasize the possibility of congestion and
provide
some general best-effort recovery mechanisms.  Would it be better if I
emphasize
the goal?
 
I am not sure what general default threshold is appropriate given that
the threshold will
vary according to network size and average traffic load of individual
network.  That's why
it is left undefined and left to administrator to experiment.
 
   The section titled "Applicability Statement" gives me no idea where
this 
   is applicable and where it is not.
 
Would you mind elaborating what information are you expecting here?
 
########################################################################
###
*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.
 
  Elaboration for the term "Ethernet" and "VLAN" suggested by 
  Ignacio Goyret and has been inserted into Introduction section:
 
  " The term "Ethernet" in this draft is used with the intention to
   include all such protocols that are reasonably similar in their
   packet format to IEEE 802.3, including variants or extensions which
   may or may not necessarily be sanctioned by IEEE (including such
   things as jumbo frames, etc).  The term "VLAN" in this draft is used
   with the intention to include all virtual LAN tagging protocols such
   as IEEE 802.1Q, 802.1ad, etc."
 
_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Aug 2006 17:16:35 -0700

My apologies - I did not realize there was text for me in this email  
till I got the ping today :-) More inline ...

On Aug 4, 2006, at 12:03 PM, Maria A. Dos Santos ((mariados)) wrote:

> ###################################################################### 
> #####
> *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
> From what I understand, the draft is inline with the current state  
> of congestion
> in this draft is only to emphasize the possibility of congestion  
> and provide
> some general best-effort recovery mechanisms.  Would it be better  
> if I emphasize
> the goal?

I'd have no problem with something along the lines of:

This specification offers no congestion control and is not TCP  
friendly <add ref to where TCP Friendly is define>. Future works,  
such as <insert non normative reference that will not block your  
document>, may extend this to provide congestion control.

>
> I am not sure what general default threshold is appropriate given  
> that the threshold will
> vary according to network size and average traffic load of  
> individual network.  That's why

Hmm - I know something about networks and I have no idea how I would  
set up the parameters such that they would work and not mess up other  
protocols on the same network. I understand that how you might want  
the parameters on a satellite link, vs a corporate switched LAN, to  
be somewhat different. I view the problem with selecting numbers here  
is that no matter what you pick, it is clear many people will  
disagree with it and there will be cases where it does not work. That  
is typically a sign that algorithm might be less than ideal  
regardless of the parameters. However, if we are agreed that for  
practical deployments and implementation, we expect that PWE will not  
have automated congestion control, then I have no real problem with  
the text you have here and we can just ignore trying to figure out if  
this provides enough advice that anyone will be able to get something  
that works.

>
>    The section titled "Applicability Statement" gives me no idea  
> where this

I might have this wrong but talking to people I get the idea that the  
expectation is that this protocol will be used across the public  
internet  as well as private networks and will be used for many  
things including forming virtual network connection between remote  
offices for enterprises.