Dan, thanx for the review, I can add the references.
alice > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:[EMAIL PROTECTED] > Sent: Sunday, 6 August, 2006 4:26 > To: Maria A. Dos Santos (mariados); [EMAIL PROTECTED]; > [email protected]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; 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:[EMAIL PROTECTED] > Sent: Friday, August 04, 2006 10:03 PM > To: [EMAIL PROTECTED]; [email protected]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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 [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
