Subject: [mpls] I-D ACTION:draft-ietf-mpls-rfc3036bis-01.txt

From: [email-masked]
Date: Mon, 22 Nov 2004 15:38:40 -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		: LDP Specification
	Author(s)	: L. Andersson, et al.
	Filename	: draft-ietf-mpls-rfc3036bis-01.txt
	Pages		: 162
	Date		: 2004-11-22
	
The architecture for Multi Protocol Label Switching (MPLS) is
   described in RFC 3031.  A fundamental concept in MPLS is that two
   Label Switching Routers (LSRs) must agree on the meaning of the
   labels used to forward traffic between and through them.  This common
   understanding is achieved by using a set of procedures, called a
   label distribution protocol, by which one LSR informs another of
   label bindings it has made.  This document defines a set of such
   procedures called LDP (for Label Distribution Protocol) by which LSRs
   distribute labels to support MPLS forwarding along normally routed
   paths.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rfc3036bis-01.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-rfc3036bis-01.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-rfc3036bis-01.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: Kireeti Kompella <[email-masked]>
Date: Wed, 24 Nov 2004 02:47:49 -0800 (PST)

Hi All,

> 	Filename	: draft-ietf-mpls-rfc3036bis-01.txt

Let me quote Thomas Narten on the use of "IETF consensus" (and to
avoid quoting out of context, I quote at length at the end; you can
look up the whole email on the ietf list):

Thomas said: 'As one of the authors of RFC 2434 "Guidelines for
Writing an IANA Considerations Section in RFCs", I have long regretted
defining the term "IETF Consensus" as it is in that document.'

I would *strongly* recommend against using "IETF consensus" in the
LDP-bis Draft Standard document.

Here's my take on the IANA considerations section:

a) The first range should be allocated as Standards Track.
   Furthermore, stuff like "Message types in this range are part of
   the LDP base protocol." should be removed -- those not defined in
   this document are clearly not part of the base protocol.

b) The Vendor-private space uses a vendor ID as administered by the
   IEEE.  This is sub-optimal.  There is a vendor ID (more accurately,
   enterprise ID, but just about every vendor has one) space
   administered by IANA; moreover, this is the ID of choice for other
   vendor-private spaces (cf. RFC 3936, and draft-kompella-ospf-iana-...)
   This was not my first choice, but rather the result of much
   discussion.  Given that, if no one is using the LDP vendor private
   space today (and those who are are willing to change their
   implementation), it would be better to standardize on a common
   notion of "vendor ID".

c) For the Experimental space, ideally one would cite RFC 3692 -- and
   recommend the procedures thereof.

d) There is no reason to exhaust the entire space at this stage.  For
   example, for the Message type space, one could use 0x0000 - 0x1fff
   for Standards Action, 0x3e00 to 0x3eff for Vendor private, and
   0x3f00 - 0x3fff for Experimental.  The rest can (and should, imo)
   be set aside, with the caveat that values from the reserved space
   cannot be allocated until there is a Standards Track or BCP RFC
   that defines the allocation policy for that range.  There is no
   danger of 8000 Standards Action code points being used up in a
   hurry, given the glacial pace of Standards Track RFCs.  On the
   other hand, the notions of Vendor Private and Experimental are
   fairly new, and who knows what other new types will come up that
   for which we might need an allocation range?

e) I would *strongly* recommend against having a First-Come-First-Served
   range for the FEC Type name space.  It is too small to frivolously
   waste, and FCFS is a dangerous policy [keep in mind 'teeth' and the
   (G)MPLS change process].

Kireeti.
-------

Date: Wed, 29 Jan 2003 20:20:26 -0500
From: Thomas Narten <[email-masked]>
To: RJ Atkinson <[email-masked]>
Cc: Bob Braden <[email-masked]>, [email-masked], [email-masked],
     [email-masked]
Subject: "IETF consensus"  in IANA considerations [was Re: Last Call:
    CR-LDP Extensions for ASON to Informational ]

RJ Atkinson <[email-masked]> writes:

> On Thursday, Jan 23, 2003, at 17:54 America/Montreal, Bob Braden wrote:
> > I interpret "IETF consensus" as meaning that at least a Last
> > Call was conducted.  To use any other interpretation seems to me to
> > be dishonest.  I guess I am agreeing with Kireeti.

> [IAB hat off]

> I agree with the above.  IESG approval is not identical to IETF
> consensus.  If it were, the IETF community would not be giving such
> vocal feedback about concerns with the IESG at the last 2 meetings
> and on the ietf-problems mailing list, IMHO.

As one of the authors of RFC 2434 "Guidelines for Writing an IANA
Considerations Section in RFCs", I have long regretted defining the
term "IETF Consensus" as it is in that document. 2434 says:

>       IETF Consensus - New values are assigned through the IETF
>            consensus process. Specifically, new assignments are made via
>            RFCs approved by the IESG. Typically, the IESG will seek
>            input on prospective assignments from appropriate persons
>            (e.g., a relevant Working Group if one exists).
>
>            Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
>            Family Identifiers [BGP4-EXT].

The intent of the above wording was to provide a way for documents to
request that IANA only assign code points when there exists a document
that gets published as an RFC. The wording above specifically does not
say "Standards Track" RFC and was intented to include informational
and experimental documents, whether from a WG or not. There is an
alternate definition - "Standards Action" - that can be cited if IANA
assignments are only to be made for Standards Track documents.

I think intent of the above definition is fine. But naming the term
"IETF Consensus" is obviously problematical and confusing, as there
are many Info and Experimental RFCs for which there is nothing close
to IETF consensus on, and no one would claim so.

So, let's be clear that in the context of most of the discussion on
this thread, folks seem to be applying their own definition of what
"IETF Consensus" means when in fact the 2434 definition is what should
be used, as is cited in the relevant IANA considerations section.

---

From: Eric Rosen <[email-masked]>
Date: Mon, 29 Nov 2004 12:16:54 -0500

Kireeti> Here's my take on the IANA considerations section: 

I really don't see why any changes need to be made to this section.  

Kireeti> I  would *strongly*  recommend against  having  a First-Come-First-
Kireeti> Served range for the FEC Type name space. 

I would even  more *strongly* object to any change  being made here.  (Well,
we could  make the experimental space  smaller and the FCFS  space larger, I
wouldn't object to that.) 

Moving from  PS to DS is  not supposed to be  an open door for  this kind of
mischief.