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

["Maria A. Dos Santos \(mariados\)" <[e-mail]>]

Dan,

thanx for the review, I can add the references.

alice
 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
> Sent: Sunday, 6 August, 2006 4:26
> To: Maria A. Dos Santos (mariados); [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]; Jari Arkko; Cullen Jennings 
> (fluffy); Mark Townsley (townsley)
> Subject: RE: Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt
> 
> I am happy with the text that addresses my DISCUSS, but I 
> suggest that IEEE 802.3, IEEE 802.1Q and IEEE802.1ad be 
> included as Normative References. 
>  
> Dan
>  
>  
>  
>  
> 
> 
> ________________________________
> 
> 	From: Maria A. Dos Santos (mariados) 
> [mailto:[e-mail]] 
> 	Sent: Friday, August 04, 2006 10:03 PM
> 	To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; Jari Arkko; 
> Cullen Jennings (fluffy); Mark Townsley (townsley); 
> Romascanu, Dan (Dan)
> 	Subject: Latest updates : 
> draft-ietf-l2tpext-pwe3-ethernet-08.txt
> 	
> 	
> 	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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art