Subject: draft-ietf-pwe3-fragmentation-07.txt - LAST CALL

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Nov 2004 14:21:05 +0000

This is the start of two week last call for
draft-ietf-pwe3-fragmentation-07.txt.

Last call will end Tuesday 7th December 2004

Stewart

-------- Original Message --------
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-07.txt
Date: Fri, 19 Nov 2004 15:18:30 -0500
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge 
Working Group of the IETF.

	Title		: PWE3 Fragmentation and Reassembly
	Author(s)	: A. Malis, M. Townsley
	Filename	: draft-ietf-pwe3-fragmentation-07.txt
	Pages		: 14
	Date		: 2004-11-19
	
This document defines a generalized method of performing
fragmentation for use by PWE3 protocols and services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-07.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-fragmentation-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-fragmentation-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------------------------------------------------------------------
CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
-------------------------------------------------------------------------
In order to maintain computing infrastructure integrity, Cisco Systems
Enterprise Messaging Services and InfoSec teams have set a mail policy
disallowing executable attachments in email.

This message contained an executable attachment type that is prohibited
by this policy. The attachment has been removed from this message and
copied to quarantine by our systems. It will be held in quarantine for
seven days in the event that the content needs to be retrieved.

Please be aware many viruses attempt to look like legitimate email or
notifications from anti-virus systems. We will clearly mark a seperation
between our notifications and the original email as follows:

   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"

For further reference information about viruses and email antivirus
efforts within Cisco, please visit:

http://wwwin.cisco.com/it/ems/services/antiviral

If your concern isn't addressed by the information in this notification
or the above web page, you may open a support request:

http://wwwin.cisco.com/support/

Select "Messaging", "Email-Related", "Mail Routing"

Please include in the text of your case the following information:

* Full headers of the message. Documentation on displaying the full
headers is available at this URL:

http://wwwin.cisco.com/support/library/faqs/solution002471.html

* This unique quarantine identifier: iAJLCLX7011421

If the matter is urgent, you may follow up by calling one of the below
referenced numbers. Please make every effort to provide the above
requested information via the support web tool prior to calling as it
will greatly aid the resolution of your issue.

Americas:
1 408 526 8888

Asiapac
+61 2 8446 8888

EMEA
+31 20 485 4888

Japan
+81 3 5549 6888

US (Toll Free)
1| 800| 888| 8187| (ext.68888)

Thank you for your cooperation,

Enterprise Messaging Services
Cisco Systems, Inc

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Nov 2004 20:11:58 -0000

Hi,

> Last call will end Tuesday 7th December 2004

Some minor comments (nits).
Apologies for not having followed the evolution of this draft in detail.

Adrian
===
The expansion of acronyms at first usage seems patchy.
- PWE3 is used in the abstract and title and should probably be expanded in both those
places
- PWE3, PSN and PDU in section 2
- CE and PE in section 3

Section 4
    use fragmentation MUST be provisioned in the sender.
s/provisioned/configured/

Section 5.1
    Deployments MUST avoid a situation which relies upon a combination
    of IP and PW fragmentation and reassembly on the same node. Such
I don't believe you can specify this as a MUST in a protocol spec. The best you can do is
"SHOULD" and probably you ought to use "should".

Section 5.4.2
    MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2,
    is the maximum size in octets of a reassembled frame, including any
    PW framing, but not including the L2TP encapsulation or L2-specific
    sublayer. Presence of this AVP signifies the ability to receive PW
    fragments and reassemble them. Packet fragments MUST NOT be sent to
    an implementation which has not received this value from its peer
    in a control message.
Hopefully the confusion is just mine!
Do you mean...
    Packet fragments MUST NOT be sent *by*
    an implementation which has not received this value from its peer
    in a control message.
If you do actually mean what you say then some re-wording to stress this might be helpful.

Section 7
    This document does not define any new values for IANA to maintain.
Looks like the subsequent text defines new values for IANA to maintain?