Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-07.txt

From: [email-masked]
Date: Thu, 15 Dec 2005 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Operations and Management Requirements for 
                          Multi-Protocol Label Switched Networks
	Author(s)	: T. Nadeau, et al.
	Filename	: draft-ietf-mpls-oam-requirements-07.txt
	Pages		: 16
	Date		: 2005-12-15
	
This document specifies Operations and Management requirements 
   for Multi-Protocol Label Switching, as well as for applications 
   of Multi-Protocol Label Switching such as pseudo-wire voice and 
   virtual private network services. These requirements 
   have been gathered from network operators who have extensive 
   experience deploying Multi-Protocol Label Switching networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-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-mpls-oam-requirements-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-mpls-oam-requirements-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.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Mon, 19 Dec 2005 15:45:40 -0000

Authors,
Cc Colleagues,

I made several comments on the -06 version of this draft to the MPLS
mailing list on 22nd July 2005.  I believe some, but not all, of my
original comments have been addressed (at least in part).

So, I list below some follow-up comments:

(1) In the introduction the document refers to "requirements for user
and data plane operations and management", however the term "user plane"
is never used in the rest of the document.  So I would suggest removing
the term user plane from the introduction, unless the intention is to
emphasise that user plane == data plane in which case I think this
intention needs to be made more explicit.

(2) Section 4.1 refers to "customer traffic" and Section 4.4 refers to
"user traffic".  Is customer traffic synonymous with user traffic, in
which case I would suggest that the document standardises on one term.

3) Throughout the document, I am not sure that the use of customer is
consistent or its meaning clear - It would appear that sometimes what is
meant is an actual customer of a service provider and at other times
what is meant is the client layer of the MPLS (server) layer, in which
case I would comment that this client layer does not necessarily belong
to a "customer".  A definition of what is meant by customer in the
terminology section would help, but I would also suggest replacing
customer with a term such as client or client layer in those cases where
what you are discussing is not necessarily owned by a customer in a
business relationship sense (e.g. a SP may use a label stack to help
scaling/aggregation, but the same SP owns the client & server MPLS
layers, so who is the customer?).

4) Section 4.5, insofar-as => insofar as (According to The Columbia
Guide to Standard American English)

Thanks
Ben

--
Ben Niven-Jenkins
Networking Specialist, BT Exact
  
E-mail: [email-masked]
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

---

From: [email-masked]
Date: Mon, 19 Dec 2005 17:26:07 -0000

[email-masked] <> wrote:
> Authors,
> Cc Colleagues,
> 
> I made several comments on the -06 version of this draft to
> the MPLS mailing list on 22nd July 2005.  I believe some, but
> not all, of my original comments have been addressed (at least in
> part). 
> 

One further comment.  The abstract talks of "applications of
Multi-Protocol Label Switching such as pseudo-wire voice and virtual
private network services.".  I am not sure what is meant by pseudo-wire
voice and can find no reference to it anywhere and
draft-ietf-pwe3-iana-allocation-15 does not list a voice type.  It
should be clarified what is meant by pseudo-wire voice.

Thanks
Ben