Subject: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt

From: [email-masked]
Date: Thu, 30 Aug 2001 07:14:16 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IPNGLS - IP Next Generation Label Switching
	Author(s)	: V. Roesler et al.
	Filename	: draft-roesler-ipngwg-ipngls-00.txt
	Pages		: 17
	Date		: 29-Aug-01
	
This document proposes the forwarding of IPv6 packets using label
switching techniques, with the same advantages of the Multiprotocol
Label Switching (MPLS) architecture. The document proposes the
mapping of all MPLS header fields into the IPv6 header, raising
several advantages like the simplicity of the model, the decrease of
overhead, and others. This mapping was called IP Next Generation
Label Switching, or just IPngLS, and can work concurrently with
MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets
are forwarded with MPLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt

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-roesler-ipngwg-ipngls-00.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-roesler-ipngwg-ipngls-00.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.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2001 13:26:02 -0500

I think this is a terrible idea for several reasons.

1) MPLS is not a global solution - if it survives at all in the long
term, it will be limited to the core of large networks - and there is
therefore no real reason to drag its complex mechanisms up into the
simple IP layer. In particular we have IP-in-IP tunnel mechanisms,
so the complex extension header replacing the S bit is unnecessary.

2) If MPLS has one major virtue, it is the "MP" for Multi-Protocol. 
This aspect is lost in the proposal.

3) Using the field currently called "flow label" to carry a swappable 
MPLS-style label defeats the alternative use of this field as an end-to-end 
field for QOS. The argument currently raging shows that the WG has no
consensus about this field, but there has been very little support for
an MPLS-like use. Indeed this was one of the options rejected at the
beginning of IPv6, when the CATNIP proposal was rejected. Some people
will tell you that is why MPLS was invented in the first place.

4) The blind mapping of the 3 bit "EXP" field into the traffic class field
makes no sense. In fact, as far as the EXP field has any meaning, it
is a compressed version of the traffic class field; writing this compressed
version back into the original field is useless.

   Brian

> http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Aug 2001 12:25:18 +0300 (EEST)

> so the complex extension header replacing the S bit is unnecessary.

I agree.

The whole draft (and some say, MPLS itself, but let's not start a fight
here) appears to be built very heavily on the assumption that MPLS is
_the_ answer to IPv4 VPN, TE, etc. needs.

Instead of looking into how these could be done better, natively in IPv6
(there's one 20 bits under discussion right now..:), it's assumed that
MPLS infrastructure is still the answer, is required for these to be
accomplished, and needs to be more tightly integrated with IPv6.

MPLS may or may not be useful with IPv6, but I think at this point keeping
MPLS transparent wrt IP header is definitely the right way to go.  At this
point, it's important to have a standard for transporting IPv6 in MPLS
networks, nothing else.

One particular point:

---
   Some advantages of IPngLS, i.e. the integration of MPLS and IPv6,
   are:

    1. Descrease of complexity: It eliminates an extra header in the
       system. In fact, there is no reason to use a new header if the
       original one can fulfill all the tasks.
---

I'm sure there are a lot of ways one can revise IP headers to make MPLS
implementation less complex, but that doesn't mean the overall complexity
(or IP header complexity, which way more important) is decreased...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords