Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item
Dimitri.Papadimitriou@alcatel-lucent.be Sun, 04 February 2007 23:17 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqbd-000448-HN; Sun, 04 Feb 2007 18:17:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqbc-00043j-NV for tsvwg@ietf.org; Sun, 04 Feb 2007 18:17:08 -0500
Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDqbb-0001rG-4l for tsvwg@ietf.org; Sun, 04 Feb 2007 18:17:08 -0500
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l14NHBL2016913; Mon, 5 Feb 2007 00:17:11 +0100
In-Reply-To: <E7B52802-241E-49FF-8091-69F88090E1A3@cisco.com>
To: Bruce Davie <bdavie@cisco.com>
Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OFDC77220F.BF8A387F-ONC1257278.007C4D96-C1257278.007FE786@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel-lucent.be
Date: Mon, 05 Feb 2007 00:17:03 +0100
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 02/05/2007 00:17:04, Serialize complete at 02/05/2007 00:17:04
Content-Type: text/plain; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org
Bruce Davie <bdavie@cisco.com> 26/01/2007 14:38 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: tsvwg@ietf.org Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item On Jan 25, 2007, at 7:07 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > lars - > > i am more generally questioning cost/perf. gain & value for 3 > major reasons (they would deserve imho further discussion - or > at least further proof of evidence) > > o) if it is to come up with a forwarding paradigm that becomes > equivalent to IP probably we should then start questioning the > need for MPLS itself (in part. in the present case focusing on > intra-domain operations where i always thought that data-traffic > and resource-oriented perf. objectives were taken into account > for edge-to-edge MPLS path provisioning) I think the need for MPLS is to support capabilities like VPNs and constraint-based routing. Giving MPLS the ability to support Diffserv (as was done in RFC3240) did not take away the need for VPNs or constraint-based routing. It simply enabled an operator to deploy MPLS to gain the extra capabilities of MPLS, without giving up the ability to do Diffserv. The same reasoning applies here: we want to allow an operator to deploy MPLS for the purposes of VPNs, TE, etc., without forcing him to give up the ability to do ECN. Of course, an operator who has no interest in ECN can leave this functionality disabled, just as RFC3270 functionality can be disabled for those operators who don't care for it. In short, adding more capabilities to MPLS does not negate the advantages that MPLS brings. [dp] that's not the point, you assume that CN is needed hence MPLS we should incorporate, my point is if the TE mechanisms and the related operations to MPLS-TE are not enough, then, one should question their real value and why not just stay w/ the pure-IP only techniques that are already delivering the goodies required, indeed, this comes very close to the argument that MPLS is simply becoming useless > o) MPLS paradigm assumed "intelligence@edges" we progressively > enter into a mode where intermediate LSRs will become (see end > of section 3) progressively require/result again more selective > processing of traffic > I'm not at all convinced that view is universally held. The task of assigning packets to FECs is indeed done at the edges, but I don't believe there is a grand principle that says MPLS core devices must do nothing other than forward packets based on the label. In fact, as one of the people who designed the MPLS shim header, I can say that the reason for reserving the 3 "EXP" bits was to allow for queueing treatment to be applied to packets independent of the label. That is exactly what both RFC3270 and this mpls-ecn draft do with those bits. [dp] i don't think i stated that label value independent queuing shall not be possible on intermediate nodes, the question is why is there a value to put more functionality on these nodes ? what i see is that we are lacking proven arguments in that direction > o) initial MPLS-ECN based its reasoning on expectations from > experience - quoting: > > "We believe the benefits from ECN of better overall performance > for a wide range of applications because of reduced packet loss > (especially those using non-TCP transports) and reduced queueing > delay is sufficiently significant. Furthermore, there seems to > be no reasons for LSRs to lack this capability as it becomes > available in other (non-label switched) IP routers." > > it would have been interesting to sustain the reasoning with > more tangible proofs - with the underlying question are we here > waiting for this doc. to make such experiment possible ? It is certainly true that ECN has yet to be proven to be universally useful. That is one reason why the draft goes to some lengths to specify this as optional behavior. But I can't see what bad thing will happen if TSVWG starts working on an MPLS ECN draft now. If proven utility is the standard that we have to reach before embarking on a working group draft, then a lot of work at the IETF should be stopped now. [dp] the point is to come at least with one good thing shared by the whole community - unique reason to put a functionality present at a higher level down the stack - Bruce > > much thanks, > - d. > > > > > > > <lars.eggert@nokia.com> > 18/01/2007 11:49 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: tsvwg@ietf.org > Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a > TSVWG > item > > > < Attachment smime.p7s removed > > > > Dimitri, > >> discussion was led on the list mid november - no real >> conclusion or action where derived from the concerns >> expressed at that time > > thanks for pointing out that this draft was also discussed elsewhere! > > As for your specific points: > >>> 1. CN marking in the EXP bits of the MPLS header falls imho under > the >>> MPLS change process that states for an optional problem statement > and >>> a mandatory prior requirements statement I-D to commit for any >>> specific change or extension to MPLS >>> >>> see section 2.1.1 and 4.2 of >>> > <http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls- > change-06 > .txt> > > The process described in that document isn't official procedure > yet, and > has raised significant concern in parts of the IESG. IMO it is > unlikely > to proceed without major changes. Hence, it's questionable that we > should apply it here and now. > >> [dp] the same section 7 mentions >> >> "[RFC3168] does not give any reasons against conveying CE information >> from the inner header to the outer in the "full functionality" >> mode." >> >> nor the other way around - which leaves the point open for ECN itself >> -> the issue i am raising is that in absence of evidence current the >> processing should be left per RFC3168 and not inline with the >> expected >> PCN needs (even if it does not affect the former) > > I'm not quite sure I understand your point - are you saying that the > benefits of ECN for MPLS are unclear? > > Thanks, > Lars > -- > NEW EMAIL: lars.eggert@nokia.com > NEW MOBILE: +358 50 48 24461 > NEW JABBER: lars.eggert@googlemail.com > > > > <smime.p7s>
- [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Magnus Westerlund
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Francois Le Faucheur IMAP
- [Tsvwg] Re: [mpls] Making draft-davie-ecn-mpls a … Dimitri.Papadimitriou
- Re: [mpls] [Fwd: [Tsvwg] Making draft-davie-ecn-m… Magnus Westerlund
- RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… philip.eardley
- Re: [mpls] [Fwd: [Tsvwg] Making draft-davie-ecn-m… Bruce Davie
- Re: [Tsvwg] Re: [mpls] Making draft-davie-ecn-mpl… Bruce Davie
- Re: [Tsvwg] Re: [mpls] Making draft-davie-ecn-mpl… Dimitri.Papadimitriou
- RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Anna Charny (acharny)
- Re: [mpls] [Fwd: [Tsvwg] Making draft-davie-ecn-m… Adrian Farrel
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… lars.eggert
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Dimitri.Papadimitriou
- RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… lars.eggert
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Bob Briscoe
- RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Dimitri.Papadimitriou
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Bruce Davie
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Lars Eggert
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Dimitri.Papadimitriou
- Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG i… Bob Briscoe