From owner-mpls@UU.NET  Sat Jun  1 00:50:10 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12523
	for <mpls-archive@lists.ietf.org>; Sat, 1 Jun 2002 00:50:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrhz09431;
	Sat, 1 Jun 2002 04:49:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrhz22727
	for mpls-outgoing; Sat, 1 Jun 2002 04:49:26 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrhz22718
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Jun 2002 04:49:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrhz02807
	for <mpls@UU.NET>; Sat, 1 Jun 2002 04:48:57 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrhz00830
	for <mpls@UU.NET>; Sat, 1 Jun 2002 04:48:57 GMT
Received: from ganymede.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns01.or.intel.com [134.134.248.3])
	id QQmrhz00786
	for <mpls@UU.NET>; Sat, 1 Jun 2002 04:48:56 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g514mtI05038
	for <mpls@UU.NET>; Sat, 1 Jun 2002 04:48:55 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002053121571703990
 for <mpls@UU.NET>; Fri, 31 May 2002 21:57:17 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <LRCHQFVV>; Fri, 31 May 2002 21:48:55 -0700
Message-ID: <AA5ED351DFA4D5118A2C00508B68BB7E08645A60@orsmsx109.jf.intel.com>
From: "Bakshi, Sanjay" <sanjay.bakshi@intel.com>
To: mpls@UU.NET
Cc: "Gunturi, Ravi" <ravi.gunturi@intel.com>
Subject: MPLS deployment!!!
Date: Fri, 31 May 2002 21:48:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello...
I have couple of questions regarding the mpls deployment:-

1. Are nested MPLS domains commonly deployed?  
   What is the known largest number of nested MPLS domains? 
 
2. In the MPLS networks installed today what is the 
   typical number of LSPs installed per port? 

thanks,
-sanjay


From owner-mpls@UU.NET  Sat Jun  1 02:47:54 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22087
	for <mpls-archive@lists.ietf.org>; Sat, 1 Jun 2002 02:47:53 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrih16703
	for <mpls-archive@lists.ietf.org>; Sat, 1 Jun 2002 06:48:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrih11383;
	Sat, 1 Jun 2002 06:46:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrih15030
	for mpls-outgoing; Sat, 1 Jun 2002 06:45:29 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrih15021
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Jun 2002 06:45:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrih05808
	for <mpls@uu.net>; Sat, 1 Jun 2002 06:45:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrih07959
	for <mpls@uu.net>; Sat, 1 Jun 2002 06:45:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrih07931
	for <mpls@uu.net>; Sat, 1 Jun 2002 06:45:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA15449 for <mpls@uu.net>; Sat, 1 Jun 2002 02:45:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA07881 for mpls@uu.net; Sat, 1 Jun 2002 02:45:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrig14672
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Jun 2002 06:44:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrig02889
	for <mpls@UU.NET>; Sat, 1 Jun 2002 06:44:09 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrig04763
	for <mpls@UU.NET>; Sat, 1 Jun 2002 06:44:09 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmrig04732
	for <mpls@UU.NET>; Sat, 1 Jun 2002 06:44:08 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id CAA05475;
	Sat, 1 Jun 2002 02:43:32 -0400 (EDT)
Date: Sat, 1 Jun 2002 02:43:32 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: jh@lohi.eng.song.fi
cc: raszuk@cisco.com, Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Giles Heron'" <giles@packetexchange.net>,
        "'Yakov Rekhter'" <yakov@juniper.net>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question
In-Reply-To: <15608.25116.357196.935015@harjus.eng.song.fi>
Message-ID: <Pine.GSO.4.44.0206010239420.27347-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca>
 <3CF7CCFE.5B2B506@cisco.com> <15607.53115.949443.940734@harjus.eng.song.fi>
 <3CF7D03C.E85EAD36@cisco.com> <15607.53639.336830.395925@harjus.eng.song.fi>
 <Pine.GSO.4.44.0205312308520.27248-100000@asimha-u10.cisco.com>
 <15608.25116.357196.935015@harjus.eng.song.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sat, 1 Jun 2002 jh@lohi.eng.song.fi wrote:

>:Ajay Simha writes:
>:
>: > For instance I did
>: > not see anyone mention things like QoS transparency that MPLS can
>: > achieve.
>:
>:diffserv is a much simpler and more scalable way to achieve qos than
>:mpls.  if you want to use mpls for qoq, you need to start playing atm
>:style vc came with p-to-p subscriber resource reservations.  and if you
>:want to really do it properly, like some atm switches from cisco did,
>:you need to implement per lsp queueing in your routers.  this is 2002
>:and i don't want to go back to 1995.
>:
>: > Sure you can monkey around with IP to make IP have
>: > everything that MPLS has. May be even a fixed length tag and call it
>: > something else :).
>:
>:i don't have any reason to start mimicking mpls with ip.
>:
>: > Why do it when this extension already exists as an IETF based
>: > standards where folks like us can debate issues and come up with
>: > solutions that are acceptable to most?
>:
>:because mpls is another control plane with all the complexity that comes
>:with it.  check this out:
>:
>:harjus:/home/ftp/internet-drafts% ls *mpls* | wc
>:    146     146    5619

You are abosultely right that there are way too many drafts. I guess all this
inovation as has come about because of MPLS. I'm not saying that MPLS is be
all end all. Don't you agree if folks tried to put frame relay or ethernet on
IP we would also have a burst of new ideas in the form of drafts?

-ajay


>:
>:-- juha
>:

-- 



From owner-mpls@UU.NET  Sun Jun  2 11:41:41 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16019
	for <mpls-archive@lists.ietf.org>; Sun, 2 Jun 2002 11:41:40 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrni19348
	for <mpls-archive@lists.ietf.org>; Sun, 2 Jun 2002 15:41:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrni15245;
	Sun, 2 Jun 2002 15:40:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrni16209
	for mpls-outgoing; Sun, 2 Jun 2002 15:40:17 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrni16204
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Jun 2002 15:40:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrni26102
	for <mpls@uu.net>; Sun, 2 Jun 2002 15:40:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrni07852
	for <mpls@uu.net>; Sun, 2 Jun 2002 15:40:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03985 for <mpls@uu.net>; Sun, 2 Jun 2002 11:40:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14651 for mpls@uu.net; Sun, 2 Jun 2002 11:40:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrni16181
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Jun 2002 15:39:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrni15791
	for <mpls@UU.NET>; Sun, 2 Jun 2002 15:33:47 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrni29798
	for <mpls@UU.NET>; Sun, 2 Jun 2002 15:33:47 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA03883; Sun, 2 Jun 2002 11:33:45 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02213; Sun, 2 Jun 2002 11:33:44 -0400 (EDT)
Date: Sun, 2 Jun 2002 11:33:44 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Vijay Bollapragada'" <vbollapr@cisco.com>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question
Message-ID: <20020602113344.B1292@eosborne-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03653@nt-exch-yow.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03653@nt-exch-yow.pmc-sierra.bc.ca>; from Shahram_Davari@pmc-sierra.com on Fri, May 31, 2002 at 11:41:35AM -0700
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, May 31, 2002 at 11:41:35AM -0700, Shahram Davari wrote:
> Vijay,
> 
> I know all this. The question was: 
> 
> "Why use LDP instead of IP?". 
> 
> If you have an answer please provide.

(coming back from vacation)
Another answer that I haven't seen here is the ability to do cell-mode
MPLS with ATM.  That's one of the original MPLS applications, and LDP
certainly helps with that.




eric

> 
> -Shahram
> 
> > -----Original Message-----
> > From: Vijay Bollapragada [mailto:vbollapr@cisco.com]
> > Sent: Friday, May 31, 2002 2:34 PM
> > To: Shahram Davari
> > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> > Subject: RE: Basic LDP Question
> > 
> > 
> > On Fri, 31 May 2002, Shahram Davari wrote:
> > 
> > > Vijay,
> > 
> > > But LDP does not give you the TE ability. So why use LDP?
> > 
> > Agreed, that LDP does not give the ability to do TE, I only 
> > said use MPLS
> > in the core, not necassarily LDP :-) but in any case, Here is 
> > what 2547
> > draft says about using LDP for the top label..
> > 
> > Section 4.3.2
> > 
> > "All that matters for the VPN architecture is that some label switched
> > path between the router and its BGP next hop exists.  
> > However, to ensure
> > interoperability  among systems which implement this VPN architecture,
> > all such systems must support LDP [MPLS-LDP]."
> > 
> > Of course, once could use many other mechanisms to get the vpn_labeled
> > packet from one edge PE to another edge PE, Interoperability 
> > is the key
> > here.
> > 
> > Thanks,
> > Vijay
> > 
> > 
> > 
> > > 
> > > > -----Original Message-----
> > > > From: Vijay Bollapragada [mailto:vbollapr@cisco.com]
> > > > Sent: Friday, May 31, 2002 2:06 PM
> > > > To: Shahram Davari
> > > > Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> > > > Subject: Re: Basic LDP Question
> > > > 
> > > > 
> > > > In the 2547 case, typically u have 2 labels, the vpn_label 
> > > > (bottom label)
> > > > and the top label is the label to get the packet to the far 
> > > > end PE, Now,
> > > > LDP is used for this top label.
> > > > 
> > > > I think u are questioning why use LDP for this bottom_label 
> > > > and why not
> > > > simply encapsulate the MPLS packet in IP to get the packet to 
> > > > the next_hop
> > > > PE. If this is your Q, You are absolutely correct and 
> > this is what the
> > > > following draft talks about
> > > > 
> > > > http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-gre-ip
> > > > -2547-01.txt
> > > > 
> > > > IMHO, this is certainly do-able but MPLS in the core give us 
> > > > the ability
> > > > to do things like Traffic Enginnering
> > > 
> > > 
> > > -Shahram
> > > 
> > >  which are quite a challenge over
> > > > pure IP.
> > > > 
> > > > Thanks,
> > > > Vijay
> > > > 
> > > > 
> > > > 
> > > > On Fri, 31 May 2002, Shahram Davari wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > What problem a mp2p LDP-based MPLS network is trying to 
> > > > solve (like the one used in RFC2547) that can't be done with 
> > > > pure IP forwarding?
> > > > > 
> > > > > Note: Don't tell me fast forwarding, because we can do fast 
> > > > IP lookup as well.
> > > > > 
> > > > > Yours,
> > > > > Shahram
> > > > > 
> > > > > 
> > > > 
> > > 
> > 



From owner-mpls@UU.NET  Sun Jun  2 18:38:57 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19952
	for <mpls-archive@lists.ietf.org>; Sun, 2 Jun 2002 18:38:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrok22856;
	Sun, 2 Jun 2002 22:37:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrok20820
	for mpls-outgoing; Sun, 2 Jun 2002 22:37:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrok20815
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Jun 2002 22:37:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrok04016
	for <mpls@uu.net>; Sun, 2 Jun 2002 22:36:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrok17524
	for <mpls@uu.net>; Sun, 2 Jun 2002 22:36:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA11264 for <mpls@uu.net>; Sun, 2 Jun 2002 18:36:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA24488 for mpls@uu.net; Sun, 2 Jun 2002 18:36:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrok20598
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 2 Jun 2002 22:35:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrok02329
	for <mpls@UU.NET>; Sun, 2 Jun 2002 22:33:35 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmrok14310
	for <mpls@UU.NET>; Sun, 2 Jun 2002 22:33:34 GMT
Received: (qmail 24366 invoked by uid 104); 2 Jun 2002 22:33:23 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.426619 secs); 02 Jun 2002 22:33:23 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 2 Jun 2002 22:33:22 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g52MXAw03623;
	Sun, 2 Jun 2002 15:33:10 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4KKYJ>; Sun, 2 Jun 2002 15:33:14 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03662@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Ajay Simha'" <asimha@cisco.com>, jh@lohi.eng.song.fi
Cc: raszuk@cisco.com, "'Giles Heron'" <giles@packetexchange.net>,
        "'Yakov Rekhter'" <yakov@juniper.net>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
Date: Sun, 2 Jun 2002 15:33:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Ajay,

> -----Original Message-----
> From: Ajay Simha [mailto:asimha@cisco.com]
> Sent: Friday, May 31, 2002 11:15 PM
> To: jh@lohi.eng.song.fi
> Cc: raszuk@cisco.com; Shahram Davari; 'Giles Heron'; 'Yakov Rekhter';
> 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> Subject: Re: Basic LDP Question
> 
> 
> On Fri, 31 May 2002 jh@lohi.eng.song.fi wrote:
> 
> The point is MPLS effectively decouples the forwarding 
> portion from the
> routing.

LDP does not decouple routing from forwarding.


-Shahram 



From owner-mpls@UU.NET  Mon Jun  3 05:20:09 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06735
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 05:20:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqb01245;
	Mon, 3 Jun 2002 09:19:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqb11135
	for mpls-outgoing; Mon, 3 Jun 2002 09:19:19 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqb11130
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 09:19:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrqb03397
	for <mpls@uu.net>; Mon, 3 Jun 2002 09:18:04 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqb23368
	for <mpls@uu.net>; Mon, 3 Jun 2002 09:18:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA28485 for <mpls@uu.net>; Mon, 3 Jun 2002 05:18:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA26527 for mpls@uu.net; Mon, 3 Jun 2002 05:18:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrqb11077
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 09:17:19 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrqa01662
	for <mpls@UU.NET>; Mon, 3 Jun 2002 09:14:43 GMT
Received: from auemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQmrqa24549
	for <mpls@UU.NET>; Mon, 3 Jun 2002 09:14:43 GMT
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g539EeY28370
	for <mpls@UU.NET>; Mon, 3 Jun 2002 05:14:41 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA06332; Mon, 3 Jun 2002 11:14:39 +0200 (MET DST)
Cc: Sudheer Dharanikota <sudheer@nayna.com>, Zhi-Wei Lin <zwlin@lucent.com>,
        Suresh Katukam <skatukam@cisco.com>,
        "R. Muralidharan" <r.muralidharan@ossi.co.in>,
        "Bernstein, Greg" <GregB@ciena.com>,
        "'Manoj Agiwal'" <ManojA@netbrahma.com>,
        "'Ccamp (E-mail)" <ccamp@ops.ietf.org>,
        "mpls@UU. NET (E-mail)" <mpls@UU.NET>
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA06173; Mon, 3 Jun 2002 11:14:24 +0200 (MET DST)
Message-ID: <3CFB336F.807CA33A@lucent.com>
Date: Mon, 03 Jun 2002 11:14:23 +0200
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: v.sharma@ieee.org
Original-CC: Sudheer Dharanikota <sudheer@nayna.com>, Zhi-Wei Lin <zwlin@lucent.com>,
        Suresh Katukam <skatukam@cisco.com>,
        "R. Muralidharan" <r.muralidharan@ossi.co.in>,
        "Bernstein, Greg" <GregB@ciena.com>,
        "'Manoj Agiwal'" <ManojA@netbrahma.com>,
        "'Ccamp (E-mail)" <ccamp@ops.ietf.org>,
        "mpls@UU. NET (E-mail)" <mpls@UU.NET>
Subject: Re: Sonet Ring provisioning
References: <MMECLKMDFPCEJFECIBCMEEIACMAA.v.sharma@ieee.org>
Content-Type: multipart/mixed;
 boundary="------------315C0C790378FFCA7E5E0DA5"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.
--------------315C0C790378FFCA7E5E0DA5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vishal,

The answer to this issue is layer networking. I.e. the HOVC layer network sees
the MS SPring protected ring as a set of HOVC fabrics and (1, 2 or 3 types of)
interconnecting HOVC links. 
The HOVC fabrics have a restriction; there is no time slot interchange possible
between the two main links. I.e. the link connection in those two links must
have the same number.

The HOVC control plane selects in which type of HOVC link (protected,
unprotected, preemptable) the new connection has to be created, and then routes
this connection through the HOVC fabrics and links.

The MS SPring [BLSR] control function within the ring network elements (if
supported) will have to populate the ring nodes with the appropriate further
information to run the ring, but this is outside the HOVC control plane's view.

>From a HOVC control plane, this is almost a trivial issue... only constraint is
no "time slot interchange" on ring HOVC links.

Regards,

Maarten

Vishal Sharma wrote:
> 
> Sudheer,
> 
> While I agree that representing nodes/domains/rings etc. is an important
> problem, I think there are two issues being mixed below.
> 
> One is the problem of the initial configuration of the UPSR/BLSR ring,
> which is clearly (today) an NMS/EMS operation.

And may be supported by MSn control plane in the future...

> 
> The other is of dynamically setting up trails on the ring. It is this
> latter problem that falls under the purview of an automated control
> plane, and is the one being discussed. This will involve the control plane,
> and the issue there, as Suresh pointed out, is how does one deal with
> mixed mesh-ring networks, similar, for example, to the topology drawn by
> Nik Langrind.
> 
> In that case, I don't think the GMPLS specifications are complete enough
> to enable one to accomplish path setup. There are several issues
> there, including the difficulty of deciding exactly the process by
> which path setup on rings will be handled, and how the various items
> that Zhi outlined in an earlier email (ring/span switching supported?,
> extra traffic supported? etc.) will be handled.

GMPLS is quite complete; only item is if it can handle the "no time slot
interchange" case. The rest is taken care of in setting up the HOVC layer
network topology... i.e. you must use GMPLS in a layered networking manner...

> 
> I see the issue of representation as somewhat tied to how one does
> path setup above. That will dictate how the rings and their nodes/links
> should be represented in the routing protocols, and how path computation
> will take them into account.
> 
> Some of these issues were discussed by us in a draft a while back
> http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx
> t
> 
> -Vishal
> 
> > -----Original Message-----
> > From: Sudheer Dharanikota [mailto:sudheer@nayna.com]
> > Sent: Friday, May 31, 2002 10:32 AM
> > To: v.sharma@ieee.org
> > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;
> > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)
> > Subject: Re: Sonet Ring provisioning
> >
> >
> > Hi All:
> >
> > This is very interesting discussion.
> >
> > Some of the people on this discussion list already looked
> > at some of these issues. Please refer to draft-many-ccamp-srg-01.txt
> > for more information.
> >
> > Here is my opinion:
> >
> > Transport networks provide their own protection mechanisms such
> > as the rings under discussion. As others pointed out it makes good
> > sense to use them for faster restoration times. These rings may
> > be created through NMS/EMS - this is not a concern to the control
> > plane.
> >
> > The real problem is how to represent this ring topology in the control
> > plane for the path computation. Well one proposal as mentioned by
> > Zhi was to represent by a logical node with node capability being
> > "highly protected node" (inheriting the property of the ring). Another
> > way to see this, as mentioned in the srg draft is to represent by
> > point-to-multi point links with the exit points to the ring as the
> > terminating points of the links and define the same "highly protected"
> > property on the links (unlike on the node). Now that we have the
> > links and link property we can use it in the path computation.
> > Once path is computed it is the nodes, which are on the ring and
> > participate in the control plane, to make a connection between
> > the end points. Please refer to the above draft or
> > http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf
> >
> > - sudheer
> >
> >
> >
> > Vishal Sharma wrote:
> >
> > > Zhi and all,
> > >
> > > Great discussion! I'm glad we're finally discussing some of these
> > > issues, and highlighting that mix inherent ring protection with
> > > the control domain mechanisms is non-trivial.
> > >
> > > Comments in-line.
> > >
> > > -Vishal
> > >
> > > > -----Original Message-----
> > > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > > > Behalf Of Zhi-Wei Lin
> > > > Sent: Thursday, May 30, 2002 11:54 AM
> > > > To: Suresh Katukam
> > > > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail);
> > > > mpls@UU. NET (E-mail)
> > > > Subject: Re: Sonet Ring provisioning
> > > >
> > > >
> > > > Hi Suresh,
> > > >
> > > > Yes agree this is very complex if you try to create too much
> > > > dependencies between control plane and transport plane protection
> > > > interactions. That is why my simplistic approach:
> > > >
> > > >     * Control plane sees the entire ring as offering "highly
> > available"
> > > >       connections
> > > >     * Control plane sets up a single connection across this ring
> > > >       "sub-network" (if you think this about this, the entire ring can
> > > >       actually be treated by a control plane controller as a
> > single node
> > > >       where the BLSR ring nodes may be thought of as
> > aggregate ports on
> > > >       the single node)
> > > >     * The ring sub-network, by virtue of providing the protection and
> > > >       knowing *exactly* how protection is provided can set up the
> > > >       protection channel automatically (but control plane
> > need not know
> > > >       this as it is irrelevant to the control plane -- it
> > only needs to
> > > >       know that the single connection is protected)
> > >
> > > What mechanism will the ring use to setup the internal
> > protection channel?
> > >
> > > Will it require EMS/NMS intervention, as proposed on this
> > thread earlier,
> > > or will there be another sequence of control plane messages (initiated
> > > internal to the ring) to set this path up. The latter would be
> > prefereable
> > > if the objective is to have fully-automated path setup (otherwise, we
> > > have EMS/NMS intervention for the ring), but it does complicate the
> > > control plane protocols (since a new sequence of setup steps may
> > > have to be initiated internal to each ring on the path of the end-to-end
> > > circuit/trail that is being setup.
> > >
> > > -Vishal
> > >
> > > >
--------------315C0C790378FFCA7E5E0DA5
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------315C0C790378FFCA7E5E0DA5--



From owner-mpls@UU.NET  Mon Jun  3 06:33:27 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07550
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 06:33:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqg10285;
	Mon, 3 Jun 2002 10:32:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqg08339
	for mpls-outgoing; Mon, 3 Jun 2002 10:31:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrqg08334
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 10:31:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqf23251
	for <mpls@UU.NET>; Mon, 3 Jun 2002 10:29:36 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqf08819
	for <mpls@UU.NET>; Mon, 3 Jun 2002 10:29:36 GMT
Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmrqf08794
	for <mpls@UU.NET>; Mon, 3 Jun 2002 10:29:35 GMT
Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19)
	id <MA6H05BJ>; Mon, 3 Jun 2002 11:29:47 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
To: asimha@cisco.com
Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Mon, 3 Jun 2002 11:26:06 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ajay,  Let me take you back to the point of Shahram's orginal
question.....which in essence, if I have understood it correctly, was 'what
problem/application is LDP solving/addressing that cannot be done either (i)
using IP directly or (ii) ER LSPs?'.....and which must also take a wider
pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
directly).

Please also see below.   Regards, Neil

Ajay Simha wrote 01 June 2002 04:15
 
> The point is MPLS effectively decouples the forwarding 
> portion from the
> routing.
NH=> Well I agree, this is vital and it's what is needed.  And it's
something we in Telco-land have known/used for years, ie decoupling of the
traffic carrying data-plane and its control-plane (both its own data-plane,
where appropriate, and its routing and signalling protocols).  But LDP does
nothing more than instantiate labels per hop that are locked to the IGP.
That is (i) they take the same SPF routes as the IGP would use for IP
fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
is not a required behaviour for applications where LSPs are long-holding
and/or must not be affected by ad hoc routing changes or failures of routing
protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
then one has to introduce 'layer violations' to make it work a bit better,
eg Load-balancing using IP-level hashing......its hard to take seriously
anyone claiming this is MPLS label forwarding when one has to look at the
client/IP level (which it may not always be, ie XoverMPLS) to make
switching/forwarding decisions.

> This makes MPLS a service enabler.
NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
against a VPN service, the behaviour noted above is not what is needed.  Now
take the fact that QoS (a pkt forwarding attribute) and survivability (an
LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
defined/measured (independent of other VPNs) and look what LDP does to
that.....it mangles then both so they can't be decoupled, and now VPN
QoS/survivability behaviour is no longer independent on a per VPN basis.
Again this is not the required behaviour for VPNs.

> For instance I 
> did not see anyone
> mention things like QoS transparency that MPLS can achieve.
NH=> How can you claim this in view of the above observations?  Further, on
what basis are you discussing QoS?  That is, unless you can automatically
fault-manage MPLS I fail to see how anyone has any basis on which to discuss
QoS with any conviction......you have to define availability 1st, since QoS
metrics *only* have relevance to the up-state, and availability is dependent
of having defects defined.  So where are the defects defined and where is
availability defined?....once you can point at these then we can
meaningfully discuss QoS, but not before.
 
> Sure you can
> monkey around with IP to make IP have everything that MPLS 
> has.
NH=> No, you have to monkey around with LDP (eg load-balancing) because it
does not provide sufficient decoupling from IP behaviour as I noted above.

> May be even a
> fixed length tag and call it something else :).
> 
> Why do it when this extension already exists as an IETF based 
> standards where
> folks like us can debate issues and come up with solutions 
> that are acceptable
> to most?
NH=> I have no problems with people defining solution's for a restricted
perspective of the problem-space if that is all they need/want from MPLS,
just so long as they don't try to stop others defining solutions which have
a more general application.  I have a strong sense that some people want to
do this....and therein lies the real problem IMO. 
> 
> -ajay
> 
> 
> >:Robert Raszuk writes:
> >:
> >: > Currently deployed hardware & software.
> >:
> >:your current router hardware can't do many other things either, like
> >:learning mac addresses.  so when you re-spin it, you could 
> also consider
> >:adding real support for ip tunneling for those who don't like the
> >:complexity of mpls control plane.
> >:
> >:-- juha
> >:
> 
> -- 
> 


From owner-mpls@UU.NET  Mon Jun  3 07:48:24 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08752
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 07:48:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrql14391;
	Mon, 3 Jun 2002 11:47:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrql06443
	for mpls-outgoing; Mon, 3 Jun 2002 11:47:30 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrql06437
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 11:47:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrql20616
	for <mpls@uu.net>; Mon, 3 Jun 2002 11:46:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrql04227
	for <mpls@uu.net>; Mon, 3 Jun 2002 11:46:14 GMT
Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.113.11.114])
	id QQmrql04189
	for <mpls@uu.net>; Mon, 3 Jun 2002 11:46:13 GMT
Received: from [80.253.97.67] (helo=gizpad.packetexchange.net)
	by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian))
	id 17EqHf-0002S9-00; Mon, 03 Jun 2002 12:45:59 +0100
Subject: RE: Basic LDP Question
From: Giles Heron <giles@packetexchange.net>
To: neil.2.harrison@bt.com
Cc: asimha@cisco.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 03 Jun 2002 12:46:08 +0000
Message-Id: <1023108368.1185.54.camel@gizpad>
Mime-Version: 1.0
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Mon, 2002-06-03 at 10:26, neil.2.harrison@bt.com wrote:
> Ajay,  Let me take you back to the point of Shahram's orginal
> question.....which in essence, if I have understood it correctly, was 'what
> problem/application is LDP solving/addressing that cannot be done either (i)
> using IP directly or (ii) ER LSPs?'.....and which must also take a wider
> pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
> directly).
> 
> Please also see below.   Regards, Neil
> 
> Ajay Simha wrote 01 June 2002 04:15
>  
> > The point is MPLS effectively decouples the forwarding 
> > portion from the
> > routing.
> NH=> Well I agree, this is vital and it's what is needed.  And it's
> something we in Telco-land have known/used for years, ie decoupling of the
> traffic carrying data-plane and its control-plane (both its own data-plane,
> where appropriate, and its routing and signalling protocols).  But LDP does
> nothing more than instantiate labels per hop that are locked to the IGP.
> That is (i) they take the same SPF routes as the IGP would use for IP
> fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
> is not a required behaviour for applications where LSPs are long-holding
> and/or must not be affected by ad hoc routing changes or failures of routing
> protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
> then one has to introduce 'layer violations' to make it work a bit better,
> eg Load-balancing using IP-level hashing......its hard to take seriously
> anyone claiming this is MPLS label forwarding when one has to look at the
> client/IP level (which it may not always be, ie XoverMPLS) to make
> switching/forwarding decisions.
[rest snipped]

not at all.

The decision as to what set of outbound interfaces to use to forward the
packet is made entirely using MPLS.

The decision as to how to hash traffic over that set of outbound
interfaces may be made entirely using MPLS (e.g. by using the next label
in the stack - if present), or may be made using information from the
next protocol layer.  Note that load balancing is an entirely local and
value-added behaviour.

Note also that load balancing using information from the next protocol
layer is a common technique in clns networks.  Many "layer 3" Ethernet
switches support IP-based load-balancing when switching traffic at
"layer 2".

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================



From owner-mpls@UU.NET  Mon Jun  3 09:56:03 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13623
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 09:56:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqt10558;
	Mon, 3 Jun 2002 13:55:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqt01243
	for mpls-outgoing; Mon, 3 Jun 2002 13:55:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqt01234
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 13:55:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqt22281
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:55:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqt02922
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:55:11 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqt02897
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:55:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07548 for <mpls@uu.net>; Mon, 3 Jun 2002 09:55:11 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24588 for mpls@uu.net; Mon, 3 Jun 2002 09:55:11 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrid19557
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Jun 2002 05:57:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrid00514
	for <mpls@uu.net>; Sat, 1 Jun 2002 05:56:47 GMT
From: jh@lohi.eng.song.fi
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrid27242
	for <mpls@uu.net>; Sat, 1 Jun 2002 05:56:47 GMT
Received: from lohi.eng.song.fi by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: lohi.eng.song.fi [195.10.149.18])
	id QQmrid27201
	for <mpls@uu.net>; Sat, 1 Jun 2002 05:56:46 GMT
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 17E1sa-0007jL-00; Sat, 01 Jun 2002 08:56:44 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15608.25116.357196.935015@harjus.eng.song.fi>
Date: Sat, 1 Jun 2002 08:56:44 +0300
To: Ajay Simha <asimha@cisco.com>
Cc: raszuk@cisco.com, Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        "'Giles Heron'" <giles@packetexchange.net>,
        "'Yakov Rekhter'" <yakov@juniper.net>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question
In-Reply-To: <Pine.GSO.4.44.0205312308520.27248-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03655@nt-exch-yow.pmc-sierra.bc.ca>
	<3CF7CCFE.5B2B506@cisco.com>
	<15607.53115.949443.940734@harjus.eng.song.fi>
	<3CF7D03C.E85EAD36@cisco.com>
	<15607.53639.336830.395925@harjus.eng.song.fi>
	<Pine.GSO.4.44.0205312308520.27248-100000@asimha-u10.cisco.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ajay Simha writes:

 > For instance I did
 > not see anyone mention things like QoS transparency that MPLS can
 > achieve. 

diffserv is a much simpler and more scalable way to achieve qos than
mpls.  if you want to use mpls for qoq, you need to start playing atm
style vc came with p-to-p subscriber resource reservations.  and if you
want to really do it properly, like some atm switches from cisco did,
you need to implement per lsp queueing in your routers.  this is 2002
and i don't want to go back to 1995.

 > Sure you can monkey around with IP to make IP have
 > everything that MPLS has. May be even a fixed length tag and call it
 > something else :).

i don't have any reason to start mimicking mpls with ip.

 > Why do it when this extension already exists as an IETF based
 > standards where folks like us can debate issues and come up with
 > solutions that are acceptable to most?

because mpls is another control plane with all the complexity that comes
with it.  check this out:

harjus:/home/ftp/internet-drafts% ls *mpls* | wc
    146     146    5619

-- juha



From owner-mpls@UU.NET  Mon Jun  3 09:57:28 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13836
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 09:57:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqt12320;
	Mon, 3 Jun 2002 13:56:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqt01401
	for mpls-outgoing; Mon, 3 Jun 2002 13:56:13 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrqt01341
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 13:56:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqt21906
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:54:55 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqt02110
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:54:55 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqt02086
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:54:55 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07526 for <mpls@uu.net>; Mon, 3 Jun 2002 09:54:54 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24483 for mpls@uu.net; Mon, 3 Jun 2002 09:54:54 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrgy10107
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 May 2002 22:13:03 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrgy04453
	for <mpls@UU.NET>; Fri, 31 May 2002 22:11:46 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrgy09109
	for <mpls@UU.NET>; Fri, 31 May 2002 22:11:46 GMT
Received: from wibble4 by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns252.timetra.com [63.104.212.252])
	id QQmrgy09082
	for <mpls@UU.NET>; Fri, 31 May 2002 22:11:46 GMT
Received: from wibble4 ([127.0.0.1]) by wibble4 with Microsoft SMTPSVC(6.0.2600.1);
	 Fri, 31 May 2002 15:11:40 -0700
From: "Nick Tingle" <nick@timetra.com>
To: <jh@lohi.eng.song.fi>, "Vijay Bollapragada" <vbollapr@cisco.com>
Cc: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
Date: Fri, 31 May 2002 15:11:40 -0700
Message-ID: <PCEPIONLABIDNPDBFGJLAEBEEGAA.nick@timetra.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <15607.51805.590210.478203@harjus.eng.song.fi>
X-OriginalArrivalTime: 31 May 2002 22:11:40.0681 (UTC) FILETIME=[23DF5F90:01C208F0]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I believe another concern with VPNs over IP vs. MPLS is packets leaking out of
the provider network, due to, e.g. transient routing problems. Presumably this
can also be fixed with filtering.

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> jh@lohi.eng.song.fi
> Sent: Friday, May 31, 2002 12:09 PM
> To: Vijay Bollapragada
> Cc: Shahram Davari; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> Subject: RE: Basic LDP Question
>
>
> packet spoofing is quite easy to prevent by a single access list at
> ingress to other providers that drops a packet if its source address
> belongs to the network that is used for the loopback interfaces that
> terminate the ip tunnels at the pes.
>
> what comes to subscriber links, we, and any reasonable service provider,
> of course always check that the source addresses belong to the
> subscribers.
>
> -- juha
>
>



From owner-mpls@UU.NET  Mon Jun  3 09:58:48 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13896
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 09:58:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqt13320;
	Mon, 3 Jun 2002 13:57:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqt01461
	for mpls-outgoing; Mon, 3 Jun 2002 13:56:42 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrqt01445
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 13:56:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqt13041
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:56:13 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqt05852
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:56:12 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqt05829
	for <mpls@uu.net>; Mon, 3 Jun 2002 13:56:12 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07607 for <mpls@uu.net>; Mon, 3 Jun 2002 09:56:12 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24689 for mpls@uu.net; Mon, 3 Jun 2002 09:56:12 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrpt18264
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 07:17:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrpt04686
	for <mpls@UU.NET>; Mon, 3 Jun 2002 07:17:44 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrpt00891
	for <mpls@UU.NET>; Mon, 3 Jun 2002 07:17:43 GMT
Received: from columbia.dt.net by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [194.37.90.50])
	id QQmrpt00833
	for <mpls@UU.NET>; Mon, 3 Jun 2002 07:17:42 GMT
Received: from 172.24.0.1 by columbia.dt.net (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 09:17:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: Basic LDP Question
Date: Mon, 3 Jun 2002 09:17:28 +0200
Message-ID: <2630A4DED1498448A41ADBD0D89186E15913E3@challenger.dt.net>
Thread-Topic: Basic LDP Question
Thread-Index: AcIIy9Dcal+FfqyHRtyeP/V5ya9tWgCAuWqQ
From: "Stiedl, Alexander" <Alexander.Stiedl@datentechnik.com>
To: "Groen, Helmut" <Helmut.Groen@datentechnik.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13896



Yakov Rekhter wrote:
>>1.  Efficient encapsulation of VPN traffic
>>2.  Ability to run VPN on current hardware
>>
>>There are probably other reasons as well...
> 
> One of the "other reasons" is straightforward protection against
packet 
> spoofing.

More straightforward than an IP firewall?

Lars
-- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute



From owner-mpls@UU.NET  Mon Jun  3 10:08:37 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14359
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 10:08:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqu25110;
	Mon, 3 Jun 2002 14:04:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqu13883
	for mpls-outgoing; Mon, 3 Jun 2002 14:04:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqu13874
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:04:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqu16177
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:04:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqu29884
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:04:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqu29871
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:04:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA08207 for <mpls@uu.net>; Mon, 3 Jun 2002 10:04:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA27282 for mpls@uu.net; Mon, 3 Jun 2002 10:04:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqu13819
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:03:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqu13745
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:01:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqu22011
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:01:14 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqu21987
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:01:13 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07966; Mon, 3 Jun 2002 10:01:12 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA04233; Mon, 3 Jun 2002 10:01:11 -0400 (EDT)
Date: Mon, 3 Jun 2002 10:01:11 -0400
From: Eric Osborne <eosborne@cisco.com>
To: neil.2.harrison@bt.com
Cc: asimha@cisco.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question
Message-ID: <20020603100111.G3433@eosborne-u10.cisco.com>
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>; from neil.2.harrison@bt.com on Mon, Jun 03, 2002 at 11:26:06AM +0100
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Jun 03, 2002 at 11:26:06AM +0100, neil.2.harrison@bt.com wrote:
> Ajay,  Let me take you back to the point of Shahram's orginal
> question.....which in essence, if I have understood it correctly, was 'what
> problem/application is LDP solving/addressing that cannot be done either (i)
> using IP directly or (ii) ER LSPs?'.....and which must also take a wider
> pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
> directly).


LDP lets you easily integrate IP and ATM; call it cell mode, call it
LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
marketing-speak and which are standardized).  It's not immediately
clear to me how you could do that with IP while using the existing ATM
switch hardware and with only a control-plane upgrade.

Perhaps I've missed something, but I've not seen a response to my last
email that pointed this out, so until someone demonstrates otherwise,
I'm going to keep pointing it out. :)

LDP is also being used as the signalling protocol for p2p services, a
la the Martini draft.  IP alone can't easily do this, as you need not
only a label to transport across the IGP, but also a service label so
that the edge can demux to the proper l2 circuit.  You could do
something involving destination protocol type/port as a demux header,
but that'd be non-trivial forwarding hardware.



eric



> 
> Please also see below.   Regards, Neil
> 
> Ajay Simha wrote 01 June 2002 04:15
>  
> > The point is MPLS effectively decouples the forwarding 
> > portion from the
> > routing.
> NH=> Well I agree, this is vital and it's what is needed.  And it's
> something we in Telco-land have known/used for years, ie decoupling of the
> traffic carrying data-plane and its control-plane (both its own data-plane,
> where appropriate, and its routing and signalling protocols).  But LDP does
> nothing more than instantiate labels per hop that are locked to the IGP.
> That is (i) they take the same SPF routes as the IGP would use for IP
> fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
> is not a required behaviour for applications where LSPs are long-holding
> and/or must not be affected by ad hoc routing changes or failures of routing
> protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
> then one has to introduce 'layer violations' to make it work a bit better,
> eg Load-balancing using IP-level hashing......its hard to take seriously
> anyone claiming this is MPLS label forwarding when one has to look at the
> client/IP level (which it may not always be, ie XoverMPLS) to make
> switching/forwarding decisions.
> 
> > This makes MPLS a service enabler.
> NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
> against a VPN service, the behaviour noted above is not what is needed.  Now
> take the fact that QoS (a pkt forwarding attribute) and survivability (an
> LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
> defined/measured (independent of other VPNs) and look what LDP does to
> that.....it mangles then both so they can't be decoupled, and now VPN
> QoS/survivability behaviour is no longer independent on a per VPN basis.
> Again this is not the required behaviour for VPNs.
> 
> > For instance I 
> > did not see anyone
> > mention things like QoS transparency that MPLS can achieve.
> NH=> How can you claim this in view of the above observations?  Further, on
> what basis are you discussing QoS?  That is, unless you can automatically
> fault-manage MPLS I fail to see how anyone has any basis on which to discuss
> QoS with any conviction......you have to define availability 1st, since QoS
> metrics *only* have relevance to the up-state, and availability is dependent
> of having defects defined.  So where are the defects defined and where is
> availability defined?....once you can point at these then we can
> meaningfully discuss QoS, but not before.
>  
> > Sure you can
> > monkey around with IP to make IP have everything that MPLS 
> > has.
> NH=> No, you have to monkey around with LDP (eg load-balancing) because it
> does not provide sufficient decoupling from IP behaviour as I noted above.
> 
> > May be even a
> > fixed length tag and call it something else :).
> > 
> > Why do it when this extension already exists as an IETF based 
> > standards where
> > folks like us can debate issues and come up with solutions 
> > that are acceptable
> > to most?
> NH=> I have no problems with people defining solution's for a restricted
> perspective of the problem-space if that is all they need/want from MPLS,
> just so long as they don't try to stop others defining solutions which have
> a more general application.  I have a strong sense that some people want to
> do this....and therein lies the real problem IMO. 
> > 
> > -ajay
> > 
> > 
> > >:Robert Raszuk writes:
> > >:
> > >: > Currently deployed hardware & software.
> > >:
> > >:your current router hardware can't do many other things either, like
> > >:learning mac addresses.  so when you re-spin it, you could 
> > also consider
> > >:adding real support for ip tunneling for those who don't like the
> > >:complexity of mpls control plane.
> > >:
> > >:-- juha
> > >:
> > 
> > -- 
> > 



From owner-mpls@UU.NET  Mon Jun  3 10:28:47 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15288
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 10:28:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqv05863;
	Mon, 3 Jun 2002 14:28:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqv26437
	for mpls-outgoing; Mon, 3 Jun 2002 14:28:02 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqv26430
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:27:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqv28172
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:27:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqv05433
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:27:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqv05415
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:27:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09771 for <mpls@uu.net>; Mon, 3 Jun 2002 10:27:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00623 for mpls@uu.net; Mon, 3 Jun 2002 10:27:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrqv26295
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:26:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrqv03653
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:23:23 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmrqv21852
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:23:22 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA08306;
	Mon, 3 Jun 2002 10:23:20 -0400 (EDT)
Date: Mon, 3 Jun 2002 10:23:20 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: neil.2.harrison@bt.com
cc: mpls@UU.NET, <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
Message-ID: <Pine.GSO.4.44.0206031020041.28616-100000@asimha-u10.cisco.com>
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 3 Jun 2002 neil.2.harrison@bt.com wrote:

>:Ajay,  Let me take you back to the point of Shahram's orginal
>:question.....which in essence, if I have understood it correctly, was 'what
>:problem/application is LDP solving/addressing that cannot be done either (i)
>:using IP directly or (ii) ER LSPs?'.....and which must also take a wider
>:pro/con analysis of the implications of using LDP-LSPs vs ER-LSPs (or IP
>:directly).
>:
>:Please also see below.   Regards, Neil
>:
>:Ajay Simha wrote 01 June 2002 04:15
>:
>:> The point is MPLS effectively decouples the forwarding
>:> portion from the
>:> routing.
>:NH=> Well I agree, this is vital and it's what is needed.  And it's
>:something we in Telco-land have known/used for years, ie decoupling of the
>:traffic carrying data-plane and its control-plane (both its own data-plane,
>:where appropriate, and its routing and signalling protocols).  But LDP does
>:nothing more than instantiate labels per hop that are locked to the IGP.
>:That is (i) they take the same SPF routes as the IGP would use for IP
>:fowarding and (ii) the LSPs change as the IGP changes.  I would argue this
>:is not a required behaviour for applications where LSPs are long-holding
>:and/or must not be affected by ad hoc routing changes or failures of routing
>:protocols (eg VPNs).  Further, because LDP is so tightly coupled to the IGP
>:then one has to introduce 'layer violations' to make it work a bit better,
>:eg Load-balancing using IP-level hashing......its hard to take seriously
>:anyone claiming this is MPLS label forwarding when one has to look at the
>:client/IP level (which it may not always be, ie XoverMPLS) to make
>:switching/forwarding decisions.
>:
>:> This makes MPLS a service enabler.
>:NH=> I don't agree that *LDP* makes MPLS a 'service-enabler'.  Considered
>:against a VPN service, the behaviour noted above is not what is needed.  Now
>:take the fact that QoS (a pkt forwarding attribute) and survivability (an
>:LSP attribute) need decoupling so that per VPN QoS/availability SLAs can be
>:defined/measured (independent of other VPNs) and look what LDP does to
>:that.....it mangles then both so they can't be decoupled, and now VPN
>:QoS/survivability behaviour is no longer independent on a per VPN basis.
>:Again this is not the required behaviour for VPNs.

I'll have to disagree here. Let us take L3VPNs for instance. If you run LDP,
you can add PEs dynamically without having to go an creat some tunnel between
this PE and all other PEs. If you use IP for this every time you have a new PE
you'll have to create end to end tunnels so that the mid-points don't drop the
packet because they have no earthly idea how  this private address on the
packet should be routed.

-ajay

>:
>:> For instance I
>:> did not see anyone
>:> mention things like QoS transparency that MPLS can achieve.
>:NH=> How can you claim this in view of the above observations?  Further, on
>:what basis are you discussing QoS?  That is, unless you can automatically
>:fault-manage MPLS I fail to see how anyone has any basis on which to discuss
>:QoS with any conviction......you have to define availability 1st, since QoS
>:metrics *only* have relevance to the up-state, and availability is dependent
>:of having defects defined.  So where are the defects defined and where is
>:availability defined?....once you can point at these then we can
>:meaningfully discuss QoS, but not before.
>:
>:> Sure you can
>:> monkey around with IP to make IP have everything that MPLS
>:> has.
>:NH=> No, you have to monkey around with LDP (eg load-balancing) because it
>:does not provide sufficient decoupling from IP behaviour as I noted above.
>:
>:> May be even a
>:> fixed length tag and call it something else :).
>:>
>:> Why do it when this extension already exists as an IETF based
>:> standards where
>:> folks like us can debate issues and come up with solutions
>:> that are acceptable
>:> to most?
>:NH=> I have no problems with people defining solution's for a restricted
>:perspective of the problem-space if that is all they need/want from MPLS,
>:just so long as they don't try to stop others defining solutions which have
>:a more general application.  I have a strong sense that some people want to
>:do this....and therein lies the real problem IMO.
>:>
>:> -ajay
>:>
>:>
>:> >:Robert Raszuk writes:
>:> >:
>:> >: > Currently deployed hardware & software.
>:> >:
>:> >:your current router hardware can't do many other things either, like
>:> >:learning mac addresses.  so when you re-spin it, you could
>:> also consider
>:> >:adding real support for ip tunneling for those who don't like the
>:> >:complexity of mpls control plane.
>:> >:
>:> >:-- juha
>:> >:
>:>
>:> --
>:>
>:

-- 



From owner-mpls@UU.NET  Mon Jun  3 10:29:50 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15323
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 10:29:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqv29913;
	Mon, 3 Jun 2002 14:29:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqv26463
	for mpls-outgoing; Mon, 3 Jun 2002 14:28:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqv26452
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:28:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqv00947
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:28:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqv08559
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:28:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqv08542
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:28:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09827 for <mpls@uu.net>; Mon, 3 Jun 2002 10:28:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00731 for mpls@uu.net; Mon, 3 Jun 2002 10:28:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqv26415
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:27:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrqv21428
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:24:52 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmrqv29665
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:24:52 GMT
Received: (qmail 16358 invoked by uid 104); 3 Jun 2002 14:24:51 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.4936 secs); 03 Jun 2002 14:24:51 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 3 Jun 2002 14:24:50 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g53EOlw28482;
	Mon, 3 Jun 2002 07:24:47 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4KPKJ>; Mon, 3 Jun 2002 07:24:51 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Osborne'" <eosborne@cisco.com>, neil.2.harrison@bt.com
Cc: asimha@cisco.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Mon, 3 Jun 2002 07:24:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

> -----Original Message-----
> From: Eric Osborne [mailto:eosborne@cisco.com]
> Sent: Monday, June 03, 2002 10:01 AM
> To: neil.2.harrison@bt.com
> Cc: asimha@cisco.com; mpls@UU.NET; ppvpn@ppvpn.francetelecom.com
> Subject: Re: Basic LDP Question
> 
> 
> On Mon, Jun 03, 2002 at 11:26:06AM +0100, 
> neil.2.harrison@bt.com wrote:
> > Ajay,  Let me take you back to the point of Shahram's orginal
> > question.....which in essence, if I have understood it 
> correctly, was 'what
> > problem/application is LDP solving/addressing that cannot 
> be done either (i)
> > using IP directly or (ii) ER LSPs?'.....and which must also 
> take a wider
> > pro/con analysis of the implications of using LDP-LSPs vs 
> ER-LSPs (or IP
> > directly).
> 
> 
> LDP lets you easily integrate IP and ATM; call it cell mode, call it
> LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> marketing-speak and which are standardized).  It's not immediately
> clear to me how you could do that with IP while using the existing ATM
> switch hardware and with only a control-plane upgrade.
> 
> Perhaps I've missed something, but I've not seen a response to my last
> email that pointed this out, so until someone demonstrates otherwise,
> I'm going to keep pointing it out. :)

You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?

> 
> LDP is also being used as the signaling protocol for p2p services, a
> la the Martini draft.  IP alone can't easily do this, as you need not
> only a label to transport across the IGP, but also a service label so
> that the edge can demux to the proper l2 circuit.  You could do
> something involving destination protocol type/port as a demux header,
> but that'd be non-trivial forwarding hardware.

The remote peering mode of LDP is useful, but you could use BGP or even RSVP-TE/CR-LDP too with the same scalability level. The question was regarding the mp2p mode of LDP not the p2p remote peering.

-Shahram

> 
> 
> 
> eric
> 
> 
> 
> > 
> > Please also see below.   Regards, Neil
> > 
> > Ajay Simha wrote 01 June 2002 04:15
> >  
> > > The point is MPLS effectively decouples the forwarding 
> > > portion from the
> > > routing.
> > NH=> Well I agree, this is vital and it's what is needed.  And it's
> > something we in Telco-land have known/used for years, ie 
> decoupling of the
> > traffic carrying data-plane and its control-plane (both its 
> own data-plane,
> > where appropriate, and its routing and signalling 
> protocols).  But LDP does
> > nothing more than instantiate labels per hop that are 
> locked to the IGP.
> > That is (i) they take the same SPF routes as the IGP would 
> use for IP
> > fowarding and (ii) the LSPs change as the IGP changes.  I 
> would argue this
> > is not a required behaviour for applications where LSPs are 
> long-holding
> > and/or must not be affected by ad hoc routing changes or 
> failures of routing
> > protocols (eg VPNs).  Further, because LDP is so tightly 
> coupled to the IGP
> > then one has to introduce 'layer violations' to make it 
> work a bit better,
> > eg Load-balancing using IP-level hashing......its hard to 
> take seriously
> > anyone claiming this is MPLS label forwarding when one has 
> to look at the
> > client/IP level (which it may not always be, ie XoverMPLS) to make
> > switching/forwarding decisions.
> > 
> > > This makes MPLS a service enabler.
> > NH=> I don't agree that *LDP* makes MPLS a 
> 'service-enabler'.  Considered
> > against a VPN service, the behaviour noted above is not 
> what is needed.  Now
> > take the fact that QoS (a pkt forwarding attribute) and 
> survivability (an
> > LSP attribute) need decoupling so that per VPN 
> QoS/availability SLAs can be
> > defined/measured (independent of other VPNs) and look what 
> LDP does to
> > that.....it mangles then both so they can't be decoupled, 
> and now VPN
> > QoS/survivability behaviour is no longer independent on a 
> per VPN basis.
> > Again this is not the required behaviour for VPNs.
> > 
> > > For instance I 
> > > did not see anyone
> > > mention things like QoS transparency that MPLS can achieve.
> > NH=> How can you claim this in view of the above 
> observations?  Further, on
> > what basis are you discussing QoS?  That is, unless you can 
> automatically
> > fault-manage MPLS I fail to see how anyone has any basis on 
> which to discuss
> > QoS with any conviction......you have to define 
> availability 1st, since QoS
> > metrics *only* have relevance to the up-state, and 
> availability is dependent
> > of having defects defined.  So where are the defects 
> defined and where is
> > availability defined?....once you can point at these then we can
> > meaningfully discuss QoS, but not before.
> >  
> > > Sure you can
> > > monkey around with IP to make IP have everything that MPLS 
> > > has.
> > NH=> No, you have to monkey around with LDP (eg 
> load-balancing) because it
> > does not provide sufficient decoupling from IP behaviour as 
> I noted above.
> > 
> > > May be even a
> > > fixed length tag and call it something else :).
> > > 
> > > Why do it when this extension already exists as an IETF based 
> > > standards where
> > > folks like us can debate issues and come up with solutions 
> > > that are acceptable
> > > to most?
> > NH=> I have no problems with people defining solution's for 
> a restricted
> > perspective of the problem-space if that is all they 
> need/want from MPLS,
> > just so long as they don't try to stop others defining 
> solutions which have
> > a more general application.  I have a strong sense that 
> some people want to
> > do this....and therein lies the real problem IMO. 
> > > 
> > > -ajay
> > > 
> > > 
> > > >:Robert Raszuk writes:
> > > >:
> > > >: > Currently deployed hardware & software.
> > > >:
> > > >:your current router hardware can't do many other things 
> either, like
> > > >:learning mac addresses.  so when you re-spin it, you could 
> > > also consider
> > > >:adding real support for ip tunneling for those who 
> don't like the
> > > >:complexity of mpls control plane.
> > > >:
> > > >:-- juha
> > > >:
> > > 
> > > -- 
> > > 
> 



From owner-mpls@UU.NET  Mon Jun  3 10:42:46 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15937
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 10:42:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqw20113;
	Mon, 3 Jun 2002 14:38:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqw27482
	for mpls-outgoing; Mon, 3 Jun 2002 14:37:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqw27472
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:37:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqw25466
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:36:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqw02785
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:36:06 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqw02698
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:36:05 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10819 for <mpls@uu.net>; Mon, 3 Jun 2002 10:36:04 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03196 for mpls@uu.net; Mon, 3 Jun 2002 10:36:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqw27169
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:35:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrqw12240
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:34:44 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmrqw09595
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:34:43 GMT
Received: (qmail 19827 invoked by uid 104); 3 Jun 2002 14:34:43 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.479899 secs); 03 Jun 2002 14:34:43 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 3 Jun 2002 14:34:42 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g53EYdw05809;
	Mon, 3 Jun 2002 07:34:39 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4KP3N>; Mon, 3 Jun 2002 07:34:42 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03666@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Ajay Simha'" <asimha@cisco.com>, neil.2.harrison@bt.com
Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Mon, 3 Jun 2002 07:34:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Ajay,


> -----Original Message-----
> From: Ajay Simha [mailto:asimha@cisco.com]
> Sent: Monday, June 03, 2002 10:23 AM
> To: neil.2.harrison@bt.com
> Cc: mpls@UU.NET; ppvpn@ppvpn.francetelecom.com
> Subject: RE: Basic LDP Question
> 
> 
> On Mon, 3 Jun 2002 neil.2.harrison@bt.com wrote:
> 
> >:Ajay,  Let me take you back to the point of Shahram's orginal
> >:question.....which in essence, if I have understood it 
> correctly, was 'what
> >:problem/application is LDP solving/addressing that cannot 
> be done either (i)
> >:using IP directly or (ii) ER LSPs?'.....and which must also 
> take a wider
> >:pro/con analysis of the implications of using LDP-LSPs vs 
> ER-LSPs (or IP
> >:directly).
> >:
> >:Please also see below.   Regards, Neil
> >:
> >:Ajay Simha wrote 01 June 2002 04:15
> >:
> >:> The point is MPLS effectively decouples the forwarding
> >:> portion from the
> >:> routing.
> >:NH=> Well I agree, this is vital and it's what is needed.  And it's
> >:something we in Telco-land have known/used for years, ie 
> decoupling of the
> >:traffic carrying data-plane and its control-plane (both its 
> own data-plane,
> >:where appropriate, and its routing and signalling 
> protocols).  But LDP does
> >:nothing more than instantiate labels per hop that are 
> locked to the IGP.
> >:That is (i) they take the same SPF routes as the IGP would 
> use for IP
> >:fowarding and (ii) the LSPs change as the IGP changes.  I 
> would argue this
> >:is not a required behaviour for applications where LSPs are 
> long-holding
> >:and/or must not be affected by ad hoc routing changes or 
> failures of routing
> >:protocols (eg VPNs).  Further, because LDP is so tightly 
> coupled to the IGP
> >:then one has to introduce 'layer violations' to make it 
> work a bit better,
> >:eg Load-balancing using IP-level hashing......its hard to 
> take seriously
> >:anyone claiming this is MPLS label forwarding when one has 
> to look at the
> >:client/IP level (which it may not always be, ie XoverMPLS) to make
> >:switching/forwarding decisions.
> >:
> >:> This makes MPLS a service enabler.
> >:NH=> I don't agree that *LDP* makes MPLS a 
> 'service-enabler'.  Considered
> >:against a VPN service, the behaviour noted above is not 
> what is needed.  Now
> >:take the fact that QoS (a pkt forwarding attribute) and 
> survivability (an
> >:LSP attribute) need decoupling so that per VPN 
> QoS/availability SLAs can be
> >:defined/measured (independent of other VPNs) and look what 
> LDP does to
> >:that.....it mangles then both so they can't be decoupled, 
> and now VPN
> >:QoS/survivability behaviour is no longer independent on a 
> per VPN basis.
> >:Again this is not the required behaviour for VPNs.
> 
> I'll have to disagree here. Let us take L3VPNs for instance. 
> If you run LDP,
> you can add PEs dynamically without having to go an creat 
> some tunnel between
> this PE and all other PEs. If you use IP for this every time 
> you have a new PE
> you'll have to create end to end tunnels so that the 
> mid-points don't drop the
> packet because they have no earthly idea how  this private 
> address on the
> packet should be routed.


I think you have misunderstood the point. What I/Neil were suggesting was
keeping the inner label and using IP header instead of the top MPLS
label. There is no tunnel to be created (IP is cnls) and PEs can be added dynamically.

-Shahram

> 
> -ajay
> 
> >:
> >:> For instance I
> >:> did not see anyone
> >:> mention things like QoS transparency that MPLS can achieve.
> >:NH=> How can you claim this in view of the above 
> observations?  Further, on
> >:what basis are you discussing QoS?  That is, unless you can 
> automatically
> >:fault-manage MPLS I fail to see how anyone has any basis on 
> which to discuss
> >:QoS with any conviction......you have to define 
> availability 1st, since QoS
> >:metrics *only* have relevance to the up-state, and 
> availability is dependent
> >:of having defects defined.  So where are the defects 
> defined and where is
> >:availability defined?....once you can point at these then we can
> >:meaningfully discuss QoS, but not before.
> >:
> >:> Sure you can
> >:> monkey around with IP to make IP have everything that MPLS
> >:> has.
> >:NH=> No, you have to monkey around with LDP (eg 
> load-balancing) because it
> >:does not provide sufficient decoupling from IP behaviour as 
> I noted above.
> >:
> >:> May be even a
> >:> fixed length tag and call it something else :).
> >:>
> >:> Why do it when this extension already exists as an IETF based
> >:> standards where
> >:> folks like us can debate issues and come up with solutions
> >:> that are acceptable
> >:> to most?
> >:NH=> I have no problems with people defining solution's for 
> a restricted
> >:perspective of the problem-space if that is all they 
> need/want from MPLS,
> >:just so long as they don't try to stop others defining 
> solutions which have
> >:a more general application.  I have a strong sense that 
> some people want to
> >:do this....and therein lies the real problem IMO.
> >:>
> >:> -ajay
> >:>
> >:>
> >:> >:Robert Raszuk writes:
> >:> >:
> >:> >: > Currently deployed hardware & software.
> >:> >:
> >:> >:your current router hardware can't do many other things 
> either, like
> >:> >:learning mac addresses.  so when you re-spin it, you could
> >:> also consider
> >:> >:adding real support for ip tunneling for those who 
> don't like the
> >:> >:complexity of mpls control plane.
> >:> >:
> >:> >:-- juha
> >:> >:
> >:>
> >:> --
> >:>
> >:
> 
> -- 
> 
> 



From owner-mpls@UU.NET  Mon Jun  3 10:53:51 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16415
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 10:53:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqx05911;
	Mon, 3 Jun 2002 14:53:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqx29173
	for mpls-outgoing; Mon, 3 Jun 2002 14:53:12 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqx29168
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:53:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqx25457
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:50:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqx13027
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:50:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqx13001
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:50:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA12885 for <mpls@uu.net>; Mon, 3 Jun 2002 10:50:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05870 for mpls@uu.net; Mon, 3 Jun 2002 10:50:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqx28878
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:49:14 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqx29609
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:47:29 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqx05655
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:47:28 GMT
Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQmrqx05628
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:47:28 GMT
Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g53El8uF027548;
	Mon, 3 Jun 2002 07:47:08 -0700 (PDT)
Received: from cisco.com (ams-rraszuk2-vpn5.cisco.com [10.61.160.14])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AFB39416;
	Mon, 3 Jun 2002 07:48:08 -0700 (PDT)
Message-ID: <3CFB8173.14AFB80A@cisco.com>
Date: Mon, 03 Jun 2002 16:47:15 +0200
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'Ajay Simha'" <asimha@cisco.com>, neil.2.harrison@bt.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question
References: <4B6D09F3B826D411A67300D0B706EFDEB03666@nt-exch-yow.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Let me clarify this one a bit:

> Shahram:
> I think you have misunderstood the point. What I/Neil were suggesting was
> keeping the inner label and using IP header instead of the top MPLS
> label. There is no tunnel to be created (IP is cnls) and PEs can be added dynamically.

This extra IP header you are adding in the front of the inner MPLS label
is an "ip tunnel" ;-).

> Ajay:

> > If you run LDP,
> > you can add PEs dynamically without having to go an creat
> > some tunnel between
> > this PE and all other PEs. If you use IP for this every time
> > you have a new PE
> > you'll have to create end to end tunnels so that the
> > mid-points don't drop the
> > packet because they have no earthly idea how  this private
> > address on the
> > packet should be routed.

The same dynamic way can be done here as well. There is no need to set
anything manually so this extra header Shahram is refering to can be
dynamically infered from information present already on PEs.

R.



From owner-mpls@UU.NET  Mon Jun  3 11:00:16 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16674
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 11:00:15 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqx14872;
	Mon, 3 Jun 2002 14:59:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqx29826
	for mpls-outgoing; Mon, 3 Jun 2002 14:59:32 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrqx29821
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:59:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqx21407
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:59:06 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqx10249
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:59:05 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqx10235
	for <mpls@uu.net>; Mon, 3 Jun 2002 14:59:05 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14040 for <mpls@uu.net>; Mon, 3 Jun 2002 10:59:05 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07565 for mpls@uu.net; Mon, 3 Jun 2002 10:59:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqx29766
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 14:58:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqx00576
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:56:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqx00045
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:56:00 GMT
Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQmrqx29856
	for <mpls@UU.NET>; Mon, 3 Jun 2002 14:55:57 GMT
Received: (qmail 17835 invoked by uid 104); 3 Jun 2002 14:55:51 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.466592 secs); 03 Jun 2002 14:55:51 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 3 Jun 2002 14:55:50 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g53Etlw16868;
	Mon, 3 Jun 2002 07:55:47 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4KPYQ>; Mon, 3 Jun 2002 07:55:51 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03668@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'raszuk@cisco.com'" <raszuk@cisco.com>
Cc: "'Ajay Simha'" <asimha@cisco.com>, neil.2.harrison@bt.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Mon, 3 Jun 2002 07:55:42 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Robert,

> This extra IP header you are adding in the front of the inner 
> MPLS label
> is an "ip tunnel" ;-).

Yes, I know it is called "IP tunnel". The point was that this
so called "IP tunnel" does not need to be created in advance.


-Shahram 



From owner-mpls@UU.NET  Mon Jun  3 11:09:55 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17466
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 11:09:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqy06065;
	Mon, 3 Jun 2002 15:09:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqy21933
	for mpls-outgoing; Mon, 3 Jun 2002 15:09:25 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrqy21922
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:09:12 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqy01629
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:08:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqy06637
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:08:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqy06612
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:08:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA15357 for <mpls@uu.net>; Mon, 3 Jun 2002 11:08:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09846 for mpls@uu.net; Mon, 3 Jun 2002 11:08:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqy11993
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:03:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrqy06324
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:02:23 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmrqy19165
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:02:22 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA09610;
	Mon, 3 Jun 2002 11:02:07 -0400 (EDT)
Date: Mon, 3 Jun 2002 11:02:07 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'raszuk@cisco.com'" <raszuk@cisco.com>, <neil.2.harrison@bt.com>,
        <mpls@UU.NET>, <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03668@nt-exch-yow.pmc-sierra.bc.ca>
Message-ID: <Pine.GSO.4.44.0206031100460.28616-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03668@nt-exch-yow.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 3 Jun 2002, Shahram Davari wrote:

>SD:Robert,
>SD:
>SD:> This extra IP header you are adding in the front of the inner
>SD:> MPLS label
>SD:> is an "ip tunnel" ;-).
>SD:
>SD:Yes, I know it is called "IP tunnel". The point was that this
>SD:so called "IP tunnel" does not need to be created in advance.

Advance to what? I don't understand, surely you are not suggesting we do it in
the forwarding plane. Could you please elaborate here?

Thanks,

-ajay
>SD:
>SD:
>SD:-Shahram
>SD:

-- 



From owner-mpls@UU.NET  Mon Jun  3 11:17:36 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18171
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 11:17:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqz16986;
	Mon, 3 Jun 2002 15:17:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqz23849
	for mpls-outgoing; Mon, 3 Jun 2002 15:16:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrqz23792
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:16:12 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqy14865
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:13:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqy21083
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:13:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqy21078
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:13:04 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA15740 for <mpls@uu.net>; Mon, 3 Jun 2002 11:13:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA10730 for mpls@uu.net; Mon, 3 Jun 2002 11:13:03 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrqy22847
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:11:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrqy22358
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:11:47 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQmrqy09367
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:11:46 GMT
Received: (qmail 23781 invoked by uid 104); 3 Jun 2002 15:11:46 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.520084 secs); 03 Jun 2002 15:11:46 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 3 Jun 2002 15:11:45 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g53FBgw06491;
	Mon, 3 Jun 2002 08:11:42 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4KQAN>; Mon, 3 Jun 2002 08:11:46 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03669@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Ajay Simha'" <asimha@cisco.com>
Cc: "'raszuk@cisco.com'" <raszuk@cisco.com>, neil.2.harrison@bt.com,
        mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Mon, 3 Jun 2002 08:11:36 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Ajay,


> >SD:Yes, I know it is called "IP tunnel". The point was that this
> >SD:so called "IP tunnel" does not need to be created in advance.
> 
> Advance to what? I don't understand, surely you are not 
> suggesting we do it in
> the forwarding plane. Could you please elaborate here?
> 

Advance to sending any packet. This is the normal IP forwarding.
Just stick an IP header on top of the packet, with the IP destination address of the PE on the other side of the network (BGP next hop),  and just forward
this IP packet to the IGP next hop.

I don't understand your concern !

-Shahram



From owner-mpls@UU.NET  Mon Jun  3 11:24:02 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18779
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 11:24:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrqz27923;
	Mon, 3 Jun 2002 15:23:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrqz24389
	for mpls-outgoing; Mon, 3 Jun 2002 15:23:29 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrqz24382
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:23:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrqz28369
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:22:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrqz17048
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:22:17 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrqz17029
	for <mpls@uu.net>; Mon, 3 Jun 2002 15:22:16 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA16341 for <mpls@uu.net>; Mon, 3 Jun 2002 11:22:16 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA12811 for mpls@uu.net; Mon, 3 Jun 2002 11:22:16 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrqz24194
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 15:21:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmrqz14363
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:21:21 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmrqz15303
	for <mpls@UU.NET>; Mon, 3 Jun 2002 15:21:21 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA10320;
	Mon, 3 Jun 2002 11:21:15 -0400 (EDT)
Date: Mon, 3 Jun 2002 11:21:15 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'raszuk@cisco.com'" <raszuk@cisco.com>, <neil.2.harrison@bt.com>,
        <mpls@UU.NET>, <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03669@nt-exch-yow.pmc-sierra.bc.ca>
Message-ID: <Pine.GSO.4.44.0206031121040.28616-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03669@nt-exch-yow.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 3 Jun 2002, Shahram Davari wrote:

>SD:Ajay,
>SD:
>SD:
>SD:> >SD:Yes, I know it is called "IP tunnel". The point was that this
>SD:> >SD:so called "IP tunnel" does not need to be created in advance.
>SD:>
>SD:> Advance to what? I don't understand, surely you are not
>SD:> suggesting we do it in
>SD:> the forwarding plane. Could you please elaborate here?
>SD:>
>SD:
>SD:Advance to sending any packet. This is the normal IP forwarding.
>SD:Just stick an IP header on top of the packet, with the IP destination address of the PE on the other side of the network (BGP next hop),  and just forward
>SD:this IP packet to the IGP next hop.
>SD:
>SD:I don't understand your concern !

Sorry you are right that should be ok.

-ajay
>SD:
>SD:-Shahram
>SD:

-- 



From owner-mpls@UU.NET  Mon Jun  3 14:26:30 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26389
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 14:26:30 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrrl01983
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 18:26:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrrl24956;
	Mon, 3 Jun 2002 18:23:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrrl14325
	for mpls-outgoing; Mon, 3 Jun 2002 18:23:38 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrrl14320
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 18:23:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrrl18560
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:23:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrrl22677
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:23:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrrl22656
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:23:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA29727 for <mpls@uu.net>; Mon, 3 Jun 2002 14:23:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01259 for mpls@uu.net; Mon, 3 Jun 2002 14:23:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrrl14261
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 18:21:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrrl20894
	for <mpls@UU.NET>; Mon, 3 Jun 2002 18:20:35 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrrl14051
	for <mpls@UU.NET>; Mon, 3 Jun 2002 18:20:35 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrrl14026
	for <mpls@UU.NET>; Mon, 3 Jun 2002 18:20:34 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA29485; Mon, 3 Jun 2002 14:20:31 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04643; Mon, 3 Jun 2002 14:20:31 -0400 (EDT)
Date: Mon, 3 Jun 2002 14:20:31 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Eric Osborne'" <eosborne@cisco.com>, neil.2.harrison@bt.com,
        asimha@cisco.com, mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question
Message-ID: <20020603142031.Q3433@eosborne-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca>; from Shahram_Davari@pmc-sierra.com on Mon, Jun 03, 2002 at 07:24:47AM -0700
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk


> > LDP lets you easily integrate IP and ATM; call it cell mode, call it
> > LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> > marketing-speak and which are standardized).  It's not immediately
> > clear to me how you could do that with IP while using the existing ATM
> > switch hardware and with only a control-plane upgrade.
> > 
> > Perhaps I've missed something, but I've not seen a response to my last
> > email that pointed this out, so until someone demonstrates otherwise,
> > I'm going to keep pointing it out. :)
> 
> You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
> since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
> fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
> vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?
> 

I'll have to defer on the ability of available HW to do vc-merge,
since ATM is not my strong point.  I know some vendors have HW that
does it.

Without VC merge, you could use RSVP or LDP.  But even with VC merge,
you could use RSVP between directly connected neighbors on every link
and you wouldn't need LDP there, either.

> > 
> > LDP is also being used as the signaling protocol for p2p services, a
> > la the Martini draft.  IP alone can't easily do this, as you need not
> > only a label to transport across the IGP, but also a service label so
> > that the edge can demux to the proper l2 circuit.  You could do
> > something involving destination protocol type/port as a demux header,
> > but that'd be non-trivial forwarding hardware.
> 
> The remote peering mode of LDP is useful, but you could use BGP or even RSVP-TE/CR-LDP too with the same scalability level. The question was regarding the mp2p mode of LDP not the p2p remote peering.
> 

I don't think RSVP is appropriate for service label signalling in this
case.

Sure, one could use BGP, but there's all sorts of things to consider
there, too.  We could use BGP between every pair of directly connected
neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
BGP and LDP are different.

Why are you trying to get rid of LDP?  It certainly seems like
that...:)



eric

> -Shahram
> 
> > 
> > 
> > 
> > eric
> > 
> > 
> > 
> > > 
> > > Please also see below.   Regards, Neil
> > > 
> > > Ajay Simha wrote 01 June 2002 04:15
> > >  
> > > > The point is MPLS effectively decouples the forwarding 
> > > > portion from the
> > > > routing.
> > > NH=> Well I agree, this is vital and it's what is needed.  And it's
> > > something we in Telco-land have known/used for years, ie 
> > decoupling of the
> > > traffic carrying data-plane and its control-plane (both its 
> > own data-plane,
> > > where appropriate, and its routing and signalling 
> > protocols).  But LDP does
> > > nothing more than instantiate labels per hop that are 
> > locked to the IGP.
> > > That is (i) they take the same SPF routes as the IGP would 
> > use for IP
> > > fowarding and (ii) the LSPs change as the IGP changes.  I 
> > would argue this
> > > is not a required behaviour for applications where LSPs are 
> > long-holding
> > > and/or must not be affected by ad hoc routing changes or 
> > failures of routing
> > > protocols (eg VPNs).  Further, because LDP is so tightly 
> > coupled to the IGP
> > > then one has to introduce 'layer violations' to make it 
> > work a bit better,
> > > eg Load-balancing using IP-level hashing......its hard to 
> > take seriously
> > > anyone claiming this is MPLS label forwarding when one has 
> > to look at the
> > > client/IP level (which it may not always be, ie XoverMPLS) to make
> > > switching/forwarding decisions.
> > > 
> > > > This makes MPLS a service enabler.
> > > NH=> I don't agree that *LDP* makes MPLS a 
> > 'service-enabler'.  Considered
> > > against a VPN service, the behaviour noted above is not 
> > what is needed.  Now
> > > take the fact that QoS (a pkt forwarding attribute) and 
> > survivability (an
> > > LSP attribute) need decoupling so that per VPN 
> > QoS/availability SLAs can be
> > > defined/measured (independent of other VPNs) and look what 
> > LDP does to
> > > that.....it mangles then both so they can't be decoupled, 
> > and now VPN
> > > QoS/survivability behaviour is no longer independent on a 
> > per VPN basis.
> > > Again this is not the required behaviour for VPNs.
> > > 
> > > > For instance I 
> > > > did not see anyone
> > > > mention things like QoS transparency that MPLS can achieve.
> > > NH=> How can you claim this in view of the above 
> > observations?  Further, on
> > > what basis are you discussing QoS?  That is, unless you can 
> > automatically
> > > fault-manage MPLS I fail to see how anyone has any basis on 
> > which to discuss
> > > QoS with any conviction......you have to define 
> > availability 1st, since QoS
> > > metrics *only* have relevance to the up-state, and 
> > availability is dependent
> > > of having defects defined.  So where are the defects 
> > defined and where is
> > > availability defined?....once you can point at these then we can
> > > meaningfully discuss QoS, but not before.
> > >  
> > > > Sure you can
> > > > monkey around with IP to make IP have everything that MPLS 
> > > > has.
> > > NH=> No, you have to monkey around with LDP (eg 
> > load-balancing) because it
> > > does not provide sufficient decoupling from IP behaviour as 
> > I noted above.
> > > 
> > > > May be even a
> > > > fixed length tag and call it something else :).
> > > > 
> > > > Why do it when this extension already exists as an IETF based 
> > > > standards where
> > > > folks like us can debate issues and come up with solutions 
> > > > that are acceptable
> > > > to most?
> > > NH=> I have no problems with people defining solution's for 
> > a restricted
> > > perspective of the problem-space if that is all they 
> > need/want from MPLS,
> > > just so long as they don't try to stop others defining 
> > solutions which have
> > > a more general application.  I have a strong sense that 
> > some people want to
> > > do this....and therein lies the real problem IMO. 
> > > > 
> > > > -ajay
> > > > 
> > > > 
> > > > >:Robert Raszuk writes:
> > > > >:
> > > > >: > Currently deployed hardware & software.
> > > > >:
> > > > >:your current router hardware can't do many other things 
> > either, like
> > > > >:learning mac addresses.  so when you re-spin it, you could 
> > > > also consider
> > > > >:adding real support for ip tunneling for those who 
> > don't like the
> > > > >:complexity of mpls control plane.
> > > > >:
> > > > >:-- juha
> > > > >:
> > > > 
> > > > -- 
> > > > 
> > 



From owner-mpls@UU.NET  Mon Jun  3 14:52:52 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27437
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 14:52:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrrn26114;
	Mon, 3 Jun 2002 18:52:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrrn16937
	for mpls-outgoing; Mon, 3 Jun 2002 18:51:58 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrrn16932
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 18:51:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrrn26887
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:51:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrrn18636
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:51:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrrn18616
	for <mpls@uu.net>; Mon, 3 Jun 2002 18:51:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02085 for <mpls@uu.net>; Mon, 3 Jun 2002 14:51:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04989 for mpls@uu.net; Mon, 3 Jun 2002 14:51:03 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrrn16856
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 18:50:09 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrrn21938
	for <mpls@UU.NET>; Mon, 3 Jun 2002 18:49:42 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmrrn21676
	for <mpls@UU.NET>; Mon, 3 Jun 2002 18:49:42 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA18098;
	Mon, 3 Jun 2002 14:49:37 -0400 (EDT)
Date: Mon, 3 Jun 2002 14:49:37 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: Eric Osborne <eosborne@cisco.com>
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, <neil.2.harrison@bt.com>,
        <mpls@UU.NET>, <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question
In-Reply-To: <20020603142031.Q3433@eosborne-u10.cisco.com>
Message-ID: <Pine.GSO.4.44.0206031448400.28616-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca>
 <20020603142031.Q3433@eosborne-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 3 Jun 2002, Eric Osborne wrote:

>EO:
>EO:> > LDP lets you easily integrate IP and ATM; call it cell mode, call it
>EO:> > LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
>EO:> > marketing-speak and which are standardized).  It's not immediately
>EO:> > clear to me how you could do that with IP while using the existing ATM
>EO:> > switch hardware and with only a control-plane upgrade.
>EO:> >
>EO:> > Perhaps I've missed something, but I've not seen a response to my last
>EO:> > email that pointed this out, so until someone demonstrates otherwise,
>EO:> > I'm going to keep pointing it out. :)
>EO:>
>EO:> You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
>EO:> since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
>EO:> fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
>EO:> vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?
>EO:>
>EO:
>EO:I'll have to defer on the ability of available HW to do vc-merge,
>EO:since ATM is not my strong point.  I know some vendors have HW that
>EO:does it.

Actually VC merge is not a must if the LSR request seperate labels - one per
request it gets from the upstream neighbor.

-ajay
>EO:
>EO:Without VC merge, you could use RSVP or LDP.  But even with VC merge,
>EO:you could use RSVP between directly connected neighbors on every link
>EO:and you wouldn't need LDP there, either.
>EO:
>EO:> >
>EO:> > LDP is also being used as the signaling protocol for p2p services, a
>EO:> > la the Martini draft.  IP alone can't easily do this, as you need not
>EO:> > only a label to transport across the IGP, but also a service label so
>EO:> > that the edge can demux to the proper l2 circuit.  You could do
>EO:> > something involving destination protocol type/port as a demux header,
>EO:> > but that'd be non-trivial forwarding hardware.
>EO:>
>EO:> The remote peering mode of LDP is useful, but you could use BGP or even RSVP-TE/CR-LDP too with the same scalability level. The question was regarding the mp2p mode of LDP not the p2p remote peering.
>EO:>
>EO:
>EO:I don't think RSVP is appropriate for service label signalling in this
>EO:case.
>EO:
>EO:Sure, one could use BGP, but there's all sorts of things to consider
>EO:there, too.  We could use BGP between every pair of directly connected
>EO:neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
>EO:BGP and LDP are different.
>EO:
>EO:Why are you trying to get rid of LDP?  It certainly seems like
>EO:that...:)
>EO:
>EO:
>EO:
>EO:eric
>EO:
>EO:> -Shahram
>EO:>
>EO:> >
>EO:> >
>EO:> >
>EO:> > eric
>EO:> >
>EO:> >
>EO:> >
>EO:> > >
>EO:> > > Please also see below.   Regards, Neil
>EO:> > >
>EO:> > > Ajay Simha wrote 01 June 2002 04:15
>EO:> > >
>EO:> > > > The point is MPLS effectively decouples the forwarding
>EO:> > > > portion from the
>EO:> > > > routing.
>EO:> > > NH=> Well I agree, this is vital and it's what is needed.  And it's
>EO:> > > something we in Telco-land have known/used for years, ie
>EO:> > decoupling of the
>EO:> > > traffic carrying data-plane and its control-plane (both its
>EO:> > own data-plane,
>EO:> > > where appropriate, and its routing and signalling
>EO:> > protocols).  But LDP does
>EO:> > > nothing more than instantiate labels per hop that are
>EO:> > locked to the IGP.
>EO:> > > That is (i) they take the same SPF routes as the IGP would
>EO:> > use for IP
>EO:> > > fowarding and (ii) the LSPs change as the IGP changes.  I
>EO:> > would argue this
>EO:> > > is not a required behaviour for applications where LSPs are
>EO:> > long-holding
>EO:> > > and/or must not be affected by ad hoc routing changes or
>EO:> > failures of routing
>EO:> > > protocols (eg VPNs).  Further, because LDP is so tightly
>EO:> > coupled to the IGP
>EO:> > > then one has to introduce 'layer violations' to make it
>EO:> > work a bit better,
>EO:> > > eg Load-balancing using IP-level hashing......its hard to
>EO:> > take seriously
>EO:> > > anyone claiming this is MPLS label forwarding when one has
>EO:> > to look at the
>EO:> > > client/IP level (which it may not always be, ie XoverMPLS) to make
>EO:> > > switching/forwarding decisions.
>EO:> > >
>EO:> > > > This makes MPLS a service enabler.
>EO:> > > NH=> I don't agree that *LDP* makes MPLS a
>EO:> > 'service-enabler'.  Considered
>EO:> > > against a VPN service, the behaviour noted above is not
>EO:> > what is needed.  Now
>EO:> > > take the fact that QoS (a pkt forwarding attribute) and
>EO:> > survivability (an
>EO:> > > LSP attribute) need decoupling so that per VPN
>EO:> > QoS/availability SLAs can be
>EO:> > > defined/measured (independent of other VPNs) and look what
>EO:> > LDP does to
>EO:> > > that.....it mangles then both so they can't be decoupled,
>EO:> > and now VPN
>EO:> > > QoS/survivability behaviour is no longer independent on a
>EO:> > per VPN basis.
>EO:> > > Again this is not the required behaviour for VPNs.
>EO:> > >
>EO:> > > > For instance I
>EO:> > > > did not see anyone
>EO:> > > > mention things like QoS transparency that MPLS can achieve.
>EO:> > > NH=> How can you claim this in view of the above
>EO:> > observations?  Further, on
>EO:> > > what basis are you discussing QoS?  That is, unless you can
>EO:> > automatically
>EO:> > > fault-manage MPLS I fail to see how anyone has any basis on
>EO:> > which to discuss
>EO:> > > QoS with any conviction......you have to define
>EO:> > availability 1st, since QoS
>EO:> > > metrics *only* have relevance to the up-state, and
>EO:> > availability is dependent
>EO:> > > of having defects defined.  So where are the defects
>EO:> > defined and where is
>EO:> > > availability defined?....once you can point at these then we can
>EO:> > > meaningfully discuss QoS, but not before.
>EO:> > >
>EO:> > > > Sure you can
>EO:> > > > monkey around with IP to make IP have everything that MPLS
>EO:> > > > has.
>EO:> > > NH=> No, you have to monkey around with LDP (eg
>EO:> > load-balancing) because it
>EO:> > > does not provide sufficient decoupling from IP behaviour as
>EO:> > I noted above.
>EO:> > >
>EO:> > > > May be even a
>EO:> > > > fixed length tag and call it something else :).
>EO:> > > >
>EO:> > > > Why do it when this extension already exists as an IETF based
>EO:> > > > standards where
>EO:> > > > folks like us can debate issues and come up with solutions
>EO:> > > > that are acceptable
>EO:> > > > to most?
>EO:> > > NH=> I have no problems with people defining solution's for
>EO:> > a restricted
>EO:> > > perspective of the problem-space if that is all they
>EO:> > need/want from MPLS,
>EO:> > > just so long as they don't try to stop others defining
>EO:> > solutions which have
>EO:> > > a more general application.  I have a strong sense that
>EO:> > some people want to
>EO:> > > do this....and therein lies the real problem IMO.
>EO:> > > >
>EO:> > > > -ajay
>EO:> > > >
>EO:> > > >
>EO:> > > > >:Robert Raszuk writes:
>EO:> > > > >:
>EO:> > > > >: > Currently deployed hardware & software.
>EO:> > > > >:
>EO:> > > > >:your current router hardware can't do many other things
>EO:> > either, like
>EO:> > > > >:learning mac addresses.  so when you re-spin it, you could
>EO:> > > > also consider
>EO:> > > > >:adding real support for ip tunneling for those who
>EO:> > don't like the
>EO:> > > > >:complexity of mpls control plane.
>EO:> > > > >:
>EO:> > > > >:-- juha
>EO:> > > > >:
>EO:> > > >
>EO:> > > > --
>EO:> > > >
>EO:> >
>EO:

-- 



From owner-mpls@UU.NET  Mon Jun  3 17:41:01 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02129
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 17:41:00 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrry16230
	for <mpls-archive@lists.ietf.org>; Mon, 3 Jun 2002 21:41:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrry10209;
	Mon, 3 Jun 2002 21:39:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrry07737
	for mpls-outgoing; Mon, 3 Jun 2002 21:38:51 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmrry07728
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 21:38:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrry13530
	for <mpls@uu.net>; Mon, 3 Jun 2002 21:38:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrry06835
	for <mpls@uu.net>; Mon, 3 Jun 2002 21:38:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrry06811
	for <mpls@uu.net>; Mon, 3 Jun 2002 21:38:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15484 for <mpls@uu.net>; Mon, 3 Jun 2002 17:38:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21452 for mpls@uu.net; Mon, 3 Jun 2002 17:38:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrry07681
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 3 Jun 2002 21:37:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrry11324
	for <mpls@UU.NET>; Mon, 3 Jun 2002 21:35:27 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrry28937
	for <mpls@UU.NET>; Mon, 3 Jun 2002 21:35:26 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrry28925
	for <mpls@UU.NET>; Mon, 3 Jun 2002 21:35:26 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15323; Mon, 3 Jun 2002 17:35:24 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA04909; Mon, 3 Jun 2002 17:35:24 -0400 (EDT)
Date: Mon, 3 Jun 2002 17:35:24 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Ajay Simha <asimha@cisco.com>
Cc: Eric Osborne <eosborne@cisco.com>,
        Shahram Davari <Shahram_Davari@pmc-sierra.com>, neil.2.harrison@bt.com,
        mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question
Message-ID: <20020603173524.W3433@eosborne-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca> <20020603142031.Q3433@eosborne-u10.cisco.com> <Pine.GSO.4.44.0206031448400.28616-100000@asimha-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.44.0206031448400.28616-100000@asimha-u10.cisco.com>; from asimha@cisco.com on Mon, Jun 03, 2002 at 02:49:37PM -0400
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Jun 03, 2002 at 02:49:37PM -0400, Ajay Simha wrote:
> On Mon, 3 Jun 2002, Eric Osborne wrote:
> 
> >EO:
> >EO:> > LDP lets you easily integrate IP and ATM; call it cell mode, call it
> >EO:> > LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> >EO:> > marketing-speak and which are standardized).  It's not immediately
> >EO:> > clear to me how you could do that with IP while using the existing ATM
> >EO:> > switch hardware and with only a control-plane upgrade.
> >EO:> >
> >EO:> > Perhaps I've missed something, but I've not seen a response to my last
> >EO:> > email that pointed this out, so until someone demonstrates otherwise,
> >EO:> > I'm going to keep pointing it out. :)
> >EO:>
> >EO:> You are absolutely right. IP forwarding can't be used for ATM-LSRs. But
> >EO:> since most ATM hardware can't do VC-merge, you can't use LDP in a mp2p
> >EO:> fashion on ATM-LSRs. Therefore there is no scalability advantage in using LDP
> >EO:> vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE, instead of CR-LDP or RSVP-TE?
> >EO:>
> >EO:
> >EO:I'll have to defer on the ability of available HW to do vc-merge,
> >EO:since ATM is not my strong point.  I know some vendors have HW that
> >EO:does it.
> 
> Actually VC merge is not a must if the LSR request seperate labels - one per
> request it gets from the upstream neighbor.

Right, but then Sharam's got a point; if you're not merging, LDP and
RSVP look a lot alike.



eric

> 
> -ajay
> >EO:
> >EO:Without VC merge, you could use RSVP or LDP.  But even with VC merge,
> >EO:you could use RSVP between directly connected neighbors on every link
> >EO:and you wouldn't need LDP there, either.
> >EO:
> >EO:> >
> >EO:> > LDP is also being used as the signaling protocol for p2p services, a
> >EO:> > la the Martini draft.  IP alone can't easily do this, as you need not
> >EO:> > only a label to transport across the IGP, but also a service label so
> >EO:> > that the edge can demux to the proper l2 circuit.  You could do
> >EO:> > something involving destination protocol type/port as a demux header,
> >EO:> > but that'd be non-trivial forwarding hardware.
> >EO:>
> >EO:> The remote peering mode of LDP is useful, but you could use BGP or even RSVP-TE/CR-LDP too with the same scalability level. The question was regarding the mp2p mode of LDP not the p2p remote peering.
> >EO:>
> >EO:
> >EO:I don't think RSVP is appropriate for service label signalling in this
> >EO:case.
> >EO:
> >EO:Sure, one could use BGP, but there's all sorts of things to consider
> >EO:there, too.  We could use BGP between every pair of directly connected
> >EO:neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
> >EO:BGP and LDP are different.
> >EO:
> >EO:Why are you trying to get rid of LDP?  It certainly seems like
> >EO:that...:)
> >EO:
> >EO:
> >EO:
> >EO:eric
> >EO:
> >EO:> -Shahram
> >EO:>
> >EO:> >
> >EO:> >
> >EO:> >
> >EO:> > eric
> >EO:> >
> >EO:> >
> >EO:> >
> >EO:> > >
> >EO:> > > Please also see below.   Regards, Neil
> >EO:> > >
> >EO:> > > Ajay Simha wrote 01 June 2002 04:15
> >EO:> > >
> >EO:> > > > The point is MPLS effectively decouples the forwarding
> >EO:> > > > portion from the
> >EO:> > > > routing.
> >EO:> > > NH=> Well I agree, this is vital and it's what is needed.  And it's
> >EO:> > > something we in Telco-land have known/used for years, ie
> >EO:> > decoupling of the
> >EO:> > > traffic carrying data-plane and its control-plane (both its
> >EO:> > own data-plane,
> >EO:> > > where appropriate, and its routing and signalling
> >EO:> > protocols).  But LDP does
> >EO:> > > nothing more than instantiate labels per hop that are
> >EO:> > locked to the IGP.
> >EO:> > > That is (i) they take the same SPF routes as the IGP would
> >EO:> > use for IP
> >EO:> > > fowarding and (ii) the LSPs change as the IGP changes.  I
> >EO:> > would argue this
> >EO:> > > is not a required behaviour for applications where LSPs are
> >EO:> > long-holding
> >EO:> > > and/or must not be affected by ad hoc routing changes or
> >EO:> > failures of routing
> >EO:> > > protocols (eg VPNs).  Further, because LDP is so tightly
> >EO:> > coupled to the IGP
> >EO:> > > then one has to introduce 'layer violations' to make it
> >EO:> > work a bit better,
> >EO:> > > eg Load-balancing using IP-level hashing......its hard to
> >EO:> > take seriously
> >EO:> > > anyone claiming this is MPLS label forwarding when one has
> >EO:> > to look at the
> >EO:> > > client/IP level (which it may not always be, ie XoverMPLS) to make
> >EO:> > > switching/forwarding decisions.
> >EO:> > >
> >EO:> > > > This makes MPLS a service enabler.
> >EO:> > > NH=> I don't agree that *LDP* makes MPLS a
> >EO:> > 'service-enabler'.  Considered
> >EO:> > > against a VPN service, the behaviour noted above is not
> >EO:> > what is needed.  Now
> >EO:> > > take the fact that QoS (a pkt forwarding attribute) and
> >EO:> > survivability (an
> >EO:> > > LSP attribute) need decoupling so that per VPN
> >EO:> > QoS/availability SLAs can be
> >EO:> > > defined/measured (independent of other VPNs) and look what
> >EO:> > LDP does to
> >EO:> > > that.....it mangles then both so they can't be decoupled,
> >EO:> > and now VPN
> >EO:> > > QoS/survivability behaviour is no longer independent on a
> >EO:> > per VPN basis.
> >EO:> > > Again this is not the required behaviour for VPNs.
> >EO:> > >
> >EO:> > > > For instance I
> >EO:> > > > did not see anyone
> >EO:> > > > mention things like QoS transparency that MPLS can achieve.
> >EO:> > > NH=> How can you claim this in view of the above
> >EO:> > observations?  Further, on
> >EO:> > > what basis are you discussing QoS?  That is, unless you can
> >EO:> > automatically
> >EO:> > > fault-manage MPLS I fail to see how anyone has any basis on
> >EO:> > which to discuss
> >EO:> > > QoS with any conviction......you have to define
> >EO:> > availability 1st, since QoS
> >EO:> > > metrics *only* have relevance to the up-state, and
> >EO:> > availability is dependent
> >EO:> > > of having defects defined.  So where are the defects
> >EO:> > defined and where is
> >EO:> > > availability defined?....once you can point at these then we can
> >EO:> > > meaningfully discuss QoS, but not before.
> >EO:> > >
> >EO:> > > > Sure you can
> >EO:> > > > monkey around with IP to make IP have everything that MPLS
> >EO:> > > > has.
> >EO:> > > NH=> No, you have to monkey around with LDP (eg
> >EO:> > load-balancing) because it
> >EO:> > > does not provide sufficient decoupling from IP behaviour as
> >EO:> > I noted above.
> >EO:> > >
> >EO:> > > > May be even a
> >EO:> > > > fixed length tag and call it something else :).
> >EO:> > > >
> >EO:> > > > Why do it when this extension already exists as an IETF based
> >EO:> > > > standards where
> >EO:> > > > folks like us can debate issues and come up with solutions
> >EO:> > > > that are acceptable
> >EO:> > > > to most?
> >EO:> > > NH=> I have no problems with people defining solution's for
> >EO:> > a restricted
> >EO:> > > perspective of the problem-space if that is all they
> >EO:> > need/want from MPLS,
> >EO:> > > just so long as they don't try to stop others defining
> >EO:> > solutions which have
> >EO:> > > a more general application.  I have a strong sense that
> >EO:> > some people want to
> >EO:> > > do this....and therein lies the real problem IMO.
> >EO:> > > >
> >EO:> > > > -ajay
> >EO:> > > >
> >EO:> > > >
> >EO:> > > > >:Robert Raszuk writes:
> >EO:> > > > >:
> >EO:> > > > >: > Currently deployed hardware & software.
> >EO:> > > > >:
> >EO:> > > > >:your current router hardware can't do many other things
> >EO:> > either, like
> >EO:> > > > >:learning mac addresses.  so when you re-spin it, you could
> >EO:> > > > also consider
> >EO:> > > > >:adding real support for ip tunneling for those who
> >EO:> > don't like the
> >EO:> > > > >:complexity of mpls control plane.
> >EO:> > > > >:
> >EO:> > > > >:-- juha
> >EO:> > > > >:
> >EO:> > > >
> >EO:> > > > --
> >EO:> > > >
> >EO:> >
> >EO:
> 
> -- 



From owner-mpls@UU.NET  Tue Jun  4 01:39:32 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10611
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 01:39:31 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrte05745
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 05:39:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrte03422;
	Tue, 4 Jun 2002 05:39:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrte10195
	for mpls-outgoing; Tue, 4 Jun 2002 05:38:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrte10188
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 05:38:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrte08764
	for <mpls@UU.NET>; Tue, 4 Jun 2002 05:38:31 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrte02572
	for <mpls@UU.NET>; Tue, 4 Jun 2002 05:38:31 GMT
Received: from sccrmhc03.attbi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sccrmhc03.attbi.com [204.127.202.63])
	id QQmrte02553
	for <mpls@UU.NET>; Tue, 4 Jun 2002 05:38:31 GMT
Received: from ericpc ([12.249.71.254]) by sccrmhc03.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020604053830.GLSF20219.sccrmhc03.attbi.com@ericpc>
          for <mpls@UU.NET>; Tue, 4 Jun 2002 05:38:30 +0000
Message-ID: <003501c20b9a$dfe52240$6600a8c0@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: <mpls@UU.NET>
Subject: lambda on demand between clusters
Date: Tue, 4 Jun 2002 00:38:52 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

If we have two computer clusters connected by an optical mesh and we want to
implement lambda on demand between these two clusters, assuming the optical
mesh is GMPLS capable, what kind of software is needed in the client side?
Do I need to implement RSVP-TE or CR-LDP in the controlling agent on both
computer clusters?  How can I make sure the reserved path is only used by
the two clusters or even by an networked application running on the two
clusters exclusively?  Sorry for the newbie question.  Any comment is
appreciated!

Eric He



From owner-mpls@UU.NET  Tue Jun  4 03:47:18 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20605
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 03:47:17 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrtn18893
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 07:47:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrtn14920;
	Tue, 4 Jun 2002 07:45:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrtn03729
	for mpls-outgoing; Tue, 4 Jun 2002 07:45:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrtn03724
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 07:45:14 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrtn26743
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:45:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrtn14297
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:45:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrtn14284
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:45:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA09136 for <mpls@uu.net>; Tue, 4 Jun 2002 03:45:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA19369 for mpls@uu.net; Tue, 4 Jun 2002 03:45:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrtm03416
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 07:44:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrtm26783
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:43:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrtm13004
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:43:29 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQmrtm12992
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:43:28 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <LXGTW2AX>; Tue, 4 Jun 2002 13:27:50 +0530
Message-ID: <55E277B99171E041ABF5F4B1C6DDCA061ACFF9@HARITHA>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: Eric Osborne <eosborne@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Basic LDP Question
Date: Tue, 4 Jun 2002 13:15:23 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

what about the advantages of using the peer model facilitated by MPLS to get
IP across ATM/FR networks with best effort( no traff engg.) for which the
unsolicited mode of LDP is more useful ?

Vijay

-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Tuesday, June 04, 2002 3:05 AM
To: Ajay Simha
Cc: Eric Osborne; Shahram Davari; neil.2.harrison@bt.com; mpls@UU.NET;
ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question


On Mon, Jun 03, 2002 at 02:49:37PM -0400, Ajay Simha wrote:
> On Mon, 3 Jun 2002, Eric Osborne wrote:
> 
> >EO:
> >EO:> > LDP lets you easily integrate IP and ATM; call it cell mode, call
it
> >EO:> > LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> >EO:> > marketing-speak and which are standardized).  It's not immediately
> >EO:> > clear to me how you could do that with IP while using the existing
ATM
> >EO:> > switch hardware and with only a control-plane upgrade.
> >EO:> >
> >EO:> > Perhaps I've missed something, but I've not seen a response to my
last
> >EO:> > email that pointed this out, so until someone demonstrates
otherwise,
> >EO:> > I'm going to keep pointing it out. :)
> >EO:>
> >EO:> You are absolutely right. IP forwarding can't be used for ATM-LSRs.
But
> >EO:> since most ATM hardware can't do VC-merge, you can't use LDP in a
mp2p
> >EO:> fashion on ATM-LSRs. Therefore there is no scalability advantage in
using LDP
> >EO:> vs. RSVP-TE or CR-LDP. So why use LDP which can't even do TE,
instead of CR-LDP or RSVP-TE?
> >EO:>
> >EO:
> >EO:I'll have to defer on the ability of available HW to do vc-merge,
> >EO:since ATM is not my strong point.  I know some vendors have HW that
> >EO:does it.
> 
> Actually VC merge is not a must if the LSR request seperate labels - one
per
> request it gets from the upstream neighbor.

Right, but then Sharam's got a point; if you're not merging, LDP and
RSVP look a lot alike.



eric

> 
> -ajay
> >EO:
> >EO:Without VC merge, you could use RSVP or LDP.  But even with VC merge,
> >EO:you could use RSVP between directly connected neighbors on every link
> >EO:and you wouldn't need LDP there, either.
> >EO:
> >EO:> >
> >EO:> > LDP is also being used as the signaling protocol for p2p services,
a
> >EO:> > la the Martini draft.  IP alone can't easily do this, as you need
not
> >EO:> > only a label to transport across the IGP, but also a service label
so
> >EO:> > that the edge can demux to the proper l2 circuit.  You could do
> >EO:> > something involving destination protocol type/port as a demux
header,
> >EO:> > but that'd be non-trivial forwarding hardware.
> >EO:>
> >EO:> The remote peering mode of LDP is useful, but you could use BGP or
even RSVP-TE/CR-LDP too with the same scalability level. The question was
regarding the mp2p mode of LDP not the p2p remote peering.
> >EO:>
> >EO:
> >EO:I don't think RSVP is appropriate for service label signalling in this
> >EO:case.
> >EO:
> >EO:Sure, one could use BGP, but there's all sorts of things to consider
> >EO:there, too.  We could use BGP between every pair of directly connected
> >EO:neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
> >EO:BGP and LDP are different.
> >EO:
> >EO:Why are you trying to get rid of LDP?  It certainly seems like
> >EO:that...:)
> >EO:
> >EO:
> >EO:
> >EO:eric
> >EO:
> >EO:> -Shahram
> >EO:>
> >EO:> >
> >EO:> >
> >EO:> >
> >EO:> > eric
> >EO:> >
> >EO:> >
> >EO:> >
> >EO:> > >
> >EO:> > > Please also see below.   Regards, Neil
> >EO:> > >
> >EO:> > > Ajay Simha wrote 01 June 2002 04:15
> >EO:> > >
> >EO:> > > > The point is MPLS effectively decouples the forwarding
> >EO:> > > > portion from the
> >EO:> > > > routing.
> >EO:> > > NH=> Well I agree, this is vital and it's what is needed.  And
it's
> >EO:> > > something we in Telco-land have known/used for years, ie
> >EO:> > decoupling of the
> >EO:> > > traffic carrying data-plane and its control-plane (both its
> >EO:> > own data-plane,
> >EO:> > > where appropriate, and its routing and signalling
> >EO:> > protocols).  But LDP does
> >EO:> > > nothing more than instantiate labels per hop that are
> >EO:> > locked to the IGP.
> >EO:> > > That is (i) they take the same SPF routes as the IGP would
> >EO:> > use for IP
> >EO:> > > fowarding and (ii) the LSPs change as the IGP changes.  I
> >EO:> > would argue this
> >EO:> > > is not a required behaviour for applications where LSPs are
> >EO:> > long-holding
> >EO:> > > and/or must not be affected by ad hoc routing changes or
> >EO:> > failures of routing
> >EO:> > > protocols (eg VPNs).  Further, because LDP is so tightly
> >EO:> > coupled to the IGP
> >EO:> > > then one has to introduce 'layer violations' to make it
> >EO:> > work a bit better,
> >EO:> > > eg Load-balancing using IP-level hashing......its hard to
> >EO:> > take seriously
> >EO:> > > anyone claiming this is MPLS label forwarding when one has
> >EO:> > to look at the
> >EO:> > > client/IP level (which it may not always be, ie XoverMPLS) to
make
> >EO:> > > switching/forwarding decisions.
> >EO:> > >
> >EO:> > > > This makes MPLS a service enabler.
> >EO:> > > NH=> I don't agree that *LDP* makes MPLS a
> >EO:> > 'service-enabler'.  Considered
> >EO:> > > against a VPN service, the behaviour noted above is not
> >EO:> > what is needed.  Now
> >EO:> > > take the fact that QoS (a pkt forwarding attribute) and
> >EO:> > survivability (an
> >EO:> > > LSP attribute) need decoupling so that per VPN
> >EO:> > QoS/availability SLAs can be
> >EO:> > > defined/measured (independent of other VPNs) and look what
> >EO:> > LDP does to
> >EO:> > > that.....it mangles then both so they can't be decoupled,
> >EO:> > and now VPN
> >EO:> > > QoS/survivability behaviour is no longer independent on a
> >EO:> > per VPN basis.
> >EO:> > > Again this is not the required behaviour for VPNs.
> >EO:> > >
> >EO:> > > > For instance I
> >EO:> > > > did not see anyone
> >EO:> > > > mention things like QoS transparency that MPLS can achieve.
> >EO:> > > NH=> How can you claim this in view of the above
> >EO:> > observations?  Further, on
> >EO:> > > what basis are you discussing QoS?  That is, unless you can
> >EO:> > automatically
> >EO:> > > fault-manage MPLS I fail to see how anyone has any basis on
> >EO:> > which to discuss
> >EO:> > > QoS with any conviction......you have to define
> >EO:> > availability 1st, since QoS
> >EO:> > > metrics *only* have relevance to the up-state, and
> >EO:> > availability is dependent
> >EO:> > > of having defects defined.  So where are the defects
> >EO:> > defined and where is
> >EO:> > > availability defined?....once you can point at these then we can
> >EO:> > > meaningfully discuss QoS, but not before.
> >EO:> > >
> >EO:> > > > Sure you can
> >EO:> > > > monkey around with IP to make IP have everything that MPLS
> >EO:> > > > has.
> >EO:> > > NH=> No, you have to monkey around with LDP (eg
> >EO:> > load-balancing) because it
> >EO:> > > does not provide sufficient decoupling from IP behaviour as
> >EO:> > I noted above.
> >EO:> > >
> >EO:> > > > May be even a
> >EO:> > > > fixed length tag and call it something else :).
> >EO:> > > >
> >EO:> > > > Why do it when this extension already exists as an IETF based
> >EO:> > > > standards where
> >EO:> > > > folks like us can debate issues and come up with solutions
> >EO:> > > > that are acceptable
> >EO:> > > > to most?
> >EO:> > > NH=> I have no problems with people defining solution's for
> >EO:> > a restricted
> >EO:> > > perspective of the problem-space if that is all they
> >EO:> > need/want from MPLS,
> >EO:> > > just so long as they don't try to stop others defining
> >EO:> > solutions which have
> >EO:> > > a more general application.  I have a strong sense that
> >EO:> > some people want to
> >EO:> > > do this....and therein lies the real problem IMO.
> >EO:> > > >
> >EO:> > > > -ajay
> >EO:> > > >
> >EO:> > > >
> >EO:> > > > >:Robert Raszuk writes:
> >EO:> > > > >:
> >EO:> > > > >: > Currently deployed hardware & software.
> >EO:> > > > >:
> >EO:> > > > >:your current router hardware can't do many other things
> >EO:> > either, like
> >EO:> > > > >:learning mac addresses.  so when you re-spin it, you could
> >EO:> > > > also consider
> >EO:> > > > >:adding real support for ip tunneling for those who
> >EO:> > don't like the
> >EO:> > > > >:complexity of mpls control plane.
> >EO:> > > > >:
> >EO:> > > > >:-- juha
> >EO:> > > > >:
> >EO:> > > >
> >EO:> > > > --
> >EO:> > > >
> >EO:> >
> >EO:
> 
> -- 



From owner-mpls@UU.NET  Tue Jun  4 03:48:38 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20625
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 03:48:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrtn18253;
	Tue, 4 Jun 2002 07:48:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrtn03981
	for mpls-outgoing; Tue, 4 Jun 2002 07:47:20 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmrtn03972
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 07:47:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrtn00341
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:46:36 GMT
Received: from psg.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: psg.com [147.28.0.62])
	id QQmrtn17667
	for <mpls@uu.net>; Tue, 4 Jun 2002 07:46:36 GMT
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224])
	by psg.com with esmtp (Exim 3.36 #1)
	id 17F91X-000Hat-00; Tue, 04 Jun 2002 00:46:35 -0700
Date: Tue, 4 Jun 2002 00:46:12 -0700
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <1788259458.20020604004612@psg.com>
To: mpls@UU.NET
CC: jh@telia.fi
Subject: Re: wg last call on draft-heinanen-inarp-uni-01.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Juha:

Please find below some comments/questions I have on this draft:

1. The document seems to assume the NBMA model, i.e.,
   a set of LSPs is abstracted as a LIS, independent from
   the IP/MPLS domain which LSPs are established through.
   I think this should be spelled out.
   
2. How are the ARP messages encapsulated in case of MPLS LSPs,
   especially considering their (LSPs') uni-protocol nature?

3. What value is used for the Hardware type field in
   case of MPLS?

4. How are the *ha fields encoded? Any implications for
   the case of interface-specific label space?

5. What happens if a request or a reply gets dropped?
   How often should the request be retransmitted?

6. The scalability section needs more work, I think.

   It is not enough to say that transmission of the request should
   be randomly delayed unless you specify the time range. Otherwise
   we can have a situation where a node is brought up or gets connected
   to the cloud and every remote node sends exactly one request
   within a short period of time, but due to the total number of
   remote nodes we still have O(n^2) messages (requests +
   replies)? You also need to make sure that even in the situation
   where the requesters do not behave properly (or are malice) and
   you receive a lot of requests back to back, reply generation is
   still controlled...

-- 
Alex




From owner-mpls@UU.NET  Tue Jun  4 10:57:27 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01502
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 10:57:27 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrup05471
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 14:57:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrup01134;
	Tue, 4 Jun 2002 14:55:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrup10866
	for mpls-outgoing; Tue, 4 Jun 2002 14:55:19 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrup10848
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 14:55:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrup29081
	for <mpls@uu.net>; Tue, 4 Jun 2002 14:53:52 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrup12977
	for <mpls@uu.net>; Tue, 4 Jun 2002 14:53:51 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQmrup12963
	for <mpls@uu.net>; Tue, 4 Jun 2002 14:53:50 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0002611876@fsnt.future.futsoft.com> for <mpls@uu.net>;
 Tue, 04 Jun 2002 20:44:27 +0530
Received: from suryam (suryam.future.futsoft.com [10.6.2.43])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g54ErMt02648
	for <mpls@uu.net>; Tue, 4 Jun 2002 20:23:23 +0530
Reply-To: <suryam@future.futsoft.com>
From: "M.N.V.Suryanarayana" <suryam@future.futsoft.com>
To: <mpls@UU.NET>
Subject: Doubts regarding FA-LSP
Date: Tue, 4 Jun 2002 20:28:12 +0530
Message-Id: <003901c20bd8$40480b60$2b02060a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

In case of FA-LSP, the head-end LSR originates a TE LSA corresponding
to FA. Should the tail-end LSR also originate a TE LSA corresponding
to the FA? If so, how does the tail-end LSR knows that the LSP is
a FA-LSP in case of dynamically established FA-LSPs?

In section 7.2 of draft-ietf-mpls-lsp-hierarchy-05.txt, the following
statement
is not very clear.

"The LSR does this by looking up the interface
switching capabilities of the previous hop and
the next hop in its IGP database, and comparing
them using the relation defined in   Section 7.2"

From Section 6.1, I understood that the LSR should compare the
near end ISC and far end ISC of the outgoing DC and if near end
ISC is < far end ISC then the LSR is an edge LSR. Does the above
statement imply the same.

Thanks & Regds,
Surya




***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************


From owner-mpls@UU.NET  Tue Jun  4 12:28:42 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04917
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 12:28:42 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmruv14351
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 16:28:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmruv11204;
	Tue, 4 Jun 2002 16:27:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmruv01912
	for mpls-outgoing; Tue, 4 Jun 2002 16:26:47 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmruv01907
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 16:26:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmruv01912
	for <mpls@uu.net>; Tue, 4 Jun 2002 16:26:04 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmruv10120
	for <mpls@uu.net>; Tue, 4 Jun 2002 16:26:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmruv10107
	for <mpls@uu.net>; Tue, 4 Jun 2002 16:26:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA04334 for <mpls@uu.net>; Tue, 4 Jun 2002 12:26:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11415 for mpls@uu.net; Tue, 4 Jun 2002 12:26:03 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmruv01711
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 16:25:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmruv15542
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:24:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmruv14216
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:24:32 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmruv14193
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:24:32 GMT
Received: (qmail 16232 invoked by uid 104); 4 Jun 2002 16:24:26 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4205. . Clean. Processed in 0.491257 secs); 04 Jun 2002 16:24:26 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 4 Jun 2002 16:24:25 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g54GOIw20386;
	Tue, 4 Jun 2002 09:24:18 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4LG2M>; Tue, 4 Jun 2002 09:24:20 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03677@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Yakov Rekhter'" <yakov@juniper.net>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'"
	 <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question 
Date: Tue, 4 Jun 2002 09:24:19 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Yakov,

Thanks for the reference. I read the mentioned draft.
However, I am not convinced that MPLS provides simpler protection
against packet spoofing than IP in VPN environment.

To mitigate against packet spoofing and accessing core routers in 
MPLS/BGP-VPN network (with MPLS core), the draft mentions 2 methods:

1) Not accepting the labeled packets from CE
2) Using VRF table, which  effectively confines the access of a VPN 
user to the same VPN and (if applicable) to Public Internet.

Both these bullets apply equally to MPLS/BGP VPN (with IP core).
Effectively in both cases the VRF table is acting the filter/firewall.

Could you please clarify why do you think that MPLS core has simpler
packet spoofing capability than IP core?

Thanks,
-Shahram

 

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Friday, May 31, 2002 2:04 PM
> To: Shahram Davari
> Cc: Giles Heron; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> Subject: Re: Basic LDP Question 
> 
> 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > > Sent: Friday, May 31, 2002 1:41 PM
> > > To: Giles Heron
> > > Cc: Shahram Davari; 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> > > Subject: Re: Basic LDP Question 
> > > 
> > > 
> > > Giles,
> > > 
> > > > 1.  Efficient encapsulation of VPN traffic
> > > > 2.  Ability to run VPN on current hardware
> > > > 
> > > > There are probably other reasons as well...
> > > 
> > > One of the "other reasons" is straightforward protection 
> > > against packet 
> > > spoofing.
> > 
> > How? 
> 
> read draft-behringer-mpls-security-01.txt
> 
> > in IP also you can do ACL.
> 
> yes, but it has its own cost/complexity.
> 
> Yakov.
> 



From owner-mpls@UU.NET  Tue Jun  4 12:31:45 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05006
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 12:31:44 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmruw24396
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 16:32:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmruw22308;
	Tue, 4 Jun 2002 16:31:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmruw02210
	for mpls-outgoing; Tue, 4 Jun 2002 16:31:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmruw02164
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 16:30:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmruw12299
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:30:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmruw20809
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:30:16 GMT
Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQmruw20795
	for <mpls@UU.NET>; Tue, 4 Jun 2002 16:30:15 GMT
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g54GUDm98487;
	Tue, 4 Jun 2002 09:30:13 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200206041630.g54GUDm98487@merlot.juniper.net>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Yakov Rekhter'" <yakov@juniper.net>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question 
In-Reply-To: Your message of "Tue, 04 Jun 2002 09:24:19 PDT."
             <4B6D09F3B826D411A67300D0B706EFDEB03677@nt-exch-yow.pmc-sierra.bc.ca> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <81218.1023208213.1@juniper.net>
Date: Tue, 04 Jun 2002 09:30:13 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

> Thanks for the reference. I read the mentioned draft.
> However, I am not convinced that MPLS provides simpler protection
> against packet spoofing than IP in VPN environment.
> 
> To mitigate against packet spoofing and accessing core routers in 
> MPLS/BGP-VPN network (with MPLS core), the draft mentions 2 methods:
> 
> 1) Not accepting the labeled packets from CE
> 2) Using VRF table, which  effectively confines the access of a VPN 
> user to the same VPN and (if applicable) to Public Internet.
> 
> Both these bullets apply equally to MPLS/BGP VPN (with IP core).
> Effectively in both cases the VRF table is acting the filter/firewall.
> 
> Could you please clarify why do you think that MPLS core has simpler
> packet spoofing capability than IP core?

for further clarifications you may look at section 8.9
of "MPLS: Technology and Applications" (by Bruce Davie and myself).

Yakov.


From owner-mpls@UU.NET  Tue Jun  4 14:49:35 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10389
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 14:49:35 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvf13451
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 18:49:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrvf11928;
	Tue, 4 Jun 2002 18:49:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrvf26460
	for mpls-outgoing; Tue, 4 Jun 2002 18:48:54 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrvf26403
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 18:48:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrvf25151
	for <mpls@UU.NET>; Tue, 4 Jun 2002 18:48:21 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvf10999
	for <mpls@UU.NET>; Tue, 4 Jun 2002 18:48:20 GMT
Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmrvf10991
	for <mpls@UU.NET>; Tue, 4 Jun 2002 18:48:20 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <MAQCN4RR>; Tue, 4 Jun 2002 19:48:34 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABE27@mbddmknt01.hc.bt.com>
To: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com
Cc: mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Tue, 4 Jun 2002 19:48:13 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Please see below, regards Neil.

Eric Osborne wrote 03 June 2002 19:21
<snipped>
> > The remote peering mode of LDP is useful, but you could use 
> BGP or even RSVP-TE/CR-LDP too with the same scalability 
> level. The question was regarding the mp2p mode of LDP not 
> the p2p remote peering.
> > 
> 
> I don't think RSVP is appropriate for service label signalling in this
> case.
NH=> Agree
> 
> Sure, one could use BGP, but there's all sorts of things to consider
> there, too.  We could use BGP between every pair of directly connected
> neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
> BGP and LDP are different.
NH=> Agree
> 
> Why are you trying to get rid of LDP?  It certainly seems like
> that...:)
NH=> Can't get rid of it....its already here.  We have to live with it.
What I think we are trying to find out is whether there is any strong reason
to use LDP in the core of a network when used to create mp2p constructs.
Remote peering of LDP is useful for certain application such as what you
described in PWE3 VC label distribution. But the general application of mp2p
LDP used in the core of networks creates lots of management problems that
don't exist in IP. 

The following is a comparison between LDP-MPLS (mp2p core) and IP, based on
the comments seen so far:

LDP-MPLS:
- Need another control-plane protocol (i.e., LDP signalling) on top of IP
control-plane (routing only)
- Packets could be mis-routed to wrong destination now because of LDP
failures. Therefore needs an LSP maintenance tool (such as LSP-ping) to run
continuously to detect defects (operators need automatic defect detection
and handling, waiting for a customer complaint is simply not good enough).
- Prevents spoofing

IP:

- Needs only IP control-plane (rouing only)
- Packets can't be mis-routed to wrong destination (except in rare cases)
due to use of IP addressing which is network unique rather than just
hop/node unique
- Is subject to spoofing, therefore needs filtering at the edge
- Requires 16 bytes more header per packet in VPN applications

So the question is which one is better to choose:
-	LDP software on all routers + periodic connectivity test, or
-	Filtering IP addresses (ACL) at the edge + 16 bytes more
header/packet for VPN
 
Note that doing a connectivity test on a constantly moving target (LDP-based
LSPs) is very difficult.
<snipped to end NH>


From owner-mpls@UU.NET  Tue Jun  4 15:09:41 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10967
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 15:09:41 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvg22683
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 19:10:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrvg20386;
	Tue, 4 Jun 2002 19:09:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrvg18422
	for mpls-outgoing; Tue, 4 Jun 2002 19:08:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrvg18413
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 19:08:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrvg00567
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:08:23 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvg06533
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:08:23 GMT
Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50])
	id QQmrvg06527
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:08:23 GMT
Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 4 Jun 2002 15:08:22 -0400
Message-ID: <3CFD1026.5DF7F30D@tropicnetworks.com>
Date: Tue, 04 Jun 2002 15:08:22 -0400
From: Nabil Seddigh <nseddigh@tropicnetworks.com>
Organization: Tropic Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'" <ppvpn@ppvpn.francetelecom.com>
Subject: Re: Basic LDP Question
References: <4B6D09F3B826D411A67300D0B706EFDEB03647@nt-exch-yow.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Jun 2002 19:08:22.0353 (UTC) FILETIME=[3202B410:01C20BFB]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Discussion regarding spoofing, header overhead, hw availability etc 
all appear to be ancillary arguments made in hindsight.

It seems to me that LDP's emergence a number of years ago could be
attributed primarily to the need for alternatives to the 
longest prefix match route lookup. The latter was typically 
software-based and relatively "slow". This doesn't appear to be
as much of a concern anymore - at least this is what the chip 
& NP vendors would have us believe :) 

Best,
Nabil Seddigh


> 
> Hi,
> 
> What problem a mp2p LDP-based MPLS network is trying to solve (like the one used in RFC2547) that can't be done with pure IP forwarding?
> 
> Note: Don't tell me fast forwarding, because we can do fast IP lookup as well.
> 
> Yours,
> Shahram


From owner-mpls@UU.NET  Tue Jun  4 15:42:03 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12070
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 15:42:02 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvi11016
	for <mpls-archive@lists.ietf.org>; Tue, 4 Jun 2002 19:42:28 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrvi08161;
	Tue, 4 Jun 2002 19:41:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrvi22358
	for mpls-outgoing; Tue, 4 Jun 2002 19:40:58 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmrvi22353
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 4 Jun 2002 19:40:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrvi04297
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:40:53 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrvi07871
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:40:53 GMT
Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQmrvi07862
	for <mpls@uu.net>; Tue, 4 Jun 2002 19:40:52 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g54Jeod23211;
	Tue, 4 Jun 2002 15:40:50 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          TUE, 4 Jun 2002 15:37:37 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <L7HN0T93>; Tue, 4 Jun 2002 15:37:37 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56016849EE@newman.tenornet.com>
From: "Shah, Himanshu" <hshah@tenornetworks.com>
To: "'Nabil Seddigh'" <nseddigh@tropicnetworks.com>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ppvpn@ppvpn.francetelecom.com'"
	 <ppvpn@ppvpn.francetelecom.com>
Subject: RE: Basic LDP Question
Date: Tue, 4 Jun 2002 15:37:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

sorry if somebody has already mentioned the following point.
I have not read all the emails on this thread.

If IP over IP is used instead of MPLS tunnels, doesn't it
rule out the retrofitted L2 switches (ATM/FR switches) as P devices?

/himanshu

> -----Original Message-----
> From: Nabil Seddigh [mailto:nseddigh@tropicnetworks.com]
> Sent: Tuesday, June 04, 2002 3:08 PM
> To: Shahram Davari
> Cc: 'mpls@uu.net'; 'ppvpn@ppvpn.francetelecom.com'
> Subject: Re: Basic LDP Question
> 
> 
> 
> Discussion regarding spoofing, header overhead, hw availability etc 
> all appear to be ancillary arguments made in hindsight.
> 
> It seems to me that LDP's emergence a number of years ago could be
> attributed primarily to the need for alternatives to the 
> longest prefix match route lookup. The latter was typically 
> software-based and relatively "slow". This doesn't appear to be
> as much of a concern anymore - at least this is what the chip 
> & NP vendors would have us believe :) 
> 
> Best,
> Nabil Seddigh
> 
> 
> > 
> > Hi,
> > 
> > What problem a mp2p LDP-based MPLS network is trying to 
> solve (like the one used in RFC2547) that can't be done with 
> pure IP forwarding?
> > 
> > Note: Don't tell me fast forwarding, because we can do fast 
> IP lookup as well.
> > 
> > Yours,
> > Shahram
> 
> 


From owner-mpls@UU.NET  Wed Jun  5 07:40:32 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26304
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 07:40:32 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrxu24246
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 11:41:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmrxu14728;
	Wed, 5 Jun 2002 11:36:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmrxu24039
	for mpls-outgoing; Wed, 5 Jun 2002 11:36:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrxu24034
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Jun 2002 11:36:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmrxu21614
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:35:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrxu13755
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:35:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmrxu13749
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:35:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA29454 for <mpls@uu.net>; Wed, 5 Jun 2002 07:35:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04158 for mpls@uu.net; Wed, 5 Jun 2002 07:35:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmrxu23813
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Jun 2002 11:34:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmrxu19524
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:34:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmrxu10406
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:34:24 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmrxu10374
	for <mpls@uu.net>; Wed, 5 Jun 2002 11:34:20 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26227;
	Wed, 5 Jun 2002 07:33:49 -0400 (EDT)
Message-Id: <200206051133.HAA26227@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-te-feed-04.txt
Date: Wed, 05 Jun 2002 07:33:49 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Improving Topology Data Base Accuracy with LSP 
                          Feedback in CR-LDP
	Author(s)	: P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki
	Filename	: draft-ietf-mpls-te-feed-04.txt
	Pages		: 12
	Date		: 04-Jun-02
	
One key component of traffic engineering is a concept known as 
constraint based routing. In constraint based routing a topology 
database is maintained on all participating nodes. This database 
contains a complete list of all the links in the network that 
participate in traffic engineering and for each of these links a set 
of constraints, which those links can meet. Bandwidth, for example, 
is one essential constraint. Since the bandwidth available changes 
as new LSPs are established and terminated the topology database 
will develop inconsistencies with respect to the real network. It is 
not possible to increase the flooding rates arbitrarily to keep the 
database discrepancies from growing. A new mechanism is proposed 
whereby a source node can learn about the successes or failures of 
its path selections by receiving feedback from the paths it is 
attempting. This information is most valuable in failure scenarious 
but is benificial during other path setup functions as well. This 
fed-back information can be incorporated into subsequent route 
computations, which greatly improves the accuracy of the overall 
routing solution by significantly reducing the database 
discrepancies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-te-feed-04.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-te-feed-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020604130740.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-te-feed-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-te-feed-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020604130740.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Jun  5 11:16:04 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03203
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 11:16:04 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmryj16755
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 15:16:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmryj15534;
	Wed, 5 Jun 2002 15:16:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmryj09926
	for mpls-outgoing; Wed, 5 Jun 2002 15:15:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmryj09921
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Jun 2002 15:15:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmryj17929
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:15:30 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmryj15093
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:15:29 GMT
Received: from bgslc03.tbg.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.tbg.com [63.99.125.3] (may be forged))
	id QQmryj15083
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:15:25 GMT
Received: by host3.tbg.com with Internet Mail Service (5.5.2653.19)
	id <L96RZZ9B>; Wed, 5 Jun 2002 09:08:10 -0600
Message-ID: <53BBA8839E91D51194D200902728944ED63B77@host3.tbg.com>
From: Irwin Lazar <ILazar@burtongroup.com>
Cc: "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: MPLScon Fall 2002 - Call for Presentations
Date: Wed, 5 Jun 2002 09:08:05 -0600 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20CA2.CB4CD2C0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20CA2.CB4CD2C0
Content-Type: text/plain;
	charset="iso-8859-1"

This is a reminder that the Call for Presentations for MPLScon Fall 2002 is
now available.  Presentation submissions are due July 1st.  The conference
takes place October 7-10 in Denver, CO.
 
For a copy of the call for presentations including submission instructions,
please visit:
http://www.mplscon.com/speaker/submit_pres.html
<http://www.mplscon.com/speaker/submit_pres.html> 
 
Please contact me at ilazar@mplscon.com <mailto:ilazar@mplscon.com>  if you
have any questions.
 
Thanks,
irwin

------_=_NextPart_001_01C20CA2.CB4CD2C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2716.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=670201115-05062002><FONT face=Arial size=2>This is a reminder 
that the Call for Presentations for MPLScon Fall 2002 is now available.&nbsp; 
Presentation submissions are due July 1st.&nbsp; The conference takes place 
October 7-10 in Denver, CO.</FONT></SPAN></DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial size=2>For a copy of the 
call for presentations including submission instructions, please 
visit:</FONT></SPAN></DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial size=2><A 
href="http://www.mplscon.com/speaker/submit_pres.html">http://www.mplscon.com/speaker/submit_pres.html</A></FONT></SPAN></DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial size=2>Please contact me at 
<A href="mailto:ilazar@mplscon.com">ilazar@mplscon.com</A> if you have any 
questions.</FONT></SPAN></DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=670201115-05062002><FONT face=Arial 
size=2>irwin</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C20CA2.CB4CD2C0--


From owner-mpls@UU.NET  Wed Jun  5 11:41:24 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03981
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 11:41:23 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmryk20067
	for <mpls-archive@lists.ietf.org>; Wed, 5 Jun 2002 15:41:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmryk16987;
	Wed, 5 Jun 2002 15:40:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmryk13221
	for mpls-outgoing; Wed, 5 Jun 2002 15:40:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmryk13216
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 5 Jun 2002 15:40:07 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmryk23864
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:38:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmryk15731
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:38:24 GMT
Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.113.11.114])
	id QQmryk15721
	for <mpls@uu.net>; Wed, 5 Jun 2002 15:38:24 GMT
Received: from [80.253.97.67] (helo=gizpad.packetexchange.net)
	by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian))
	id 17FcrI-00087A-00; Wed, 05 Jun 2002 16:38:00 +0100
Subject: RE: Basic LDP Question
From: Giles Heron <giles@packetexchange.net>
To: neil.2.harrison@bt.com
Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0514BABE27@mbddmknt01.hc.bt.com>
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE27@mbddmknt01.hc.bt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 05 Jun 2002 16:38:07 +0000
Message-Id: <1023295088.3106.315.camel@gizpad>
Mime-Version: 1.0
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Tue, 2002-06-04 at 18:48, neil.2.harrison@bt.com wrote:
> Please see below, regards Neil.
> 
> Eric Osborne wrote 03 June 2002 19:21
> <snipped>
> > > The remote peering mode of LDP is useful, but you could use 
> > BGP or even RSVP-TE/CR-LDP too with the same scalability 
> > level. The question was regarding the mp2p mode of LDP not 
> > the p2p remote peering.
> > > 
> > 
> > I don't think RSVP is appropriate for service label signalling in this
> > case.
> NH=> Agree
> > 
> > Sure, one could use BGP, but there's all sorts of things to consider
> > there, too.  We could use BGP between every pair of directly connected
> > neighbors (a la rfc3107) and not use LDP there, either.  But we don't;
> > BGP and LDP are different.
> NH=> Agree
> > 
> > Why are you trying to get rid of LDP?  It certainly seems like
> > that...:)
> NH=> Can't get rid of it....its already here.  We have to live with it.
> What I think we are trying to find out is whether there is any strong reason
> to use LDP in the core of a network when used to create mp2p constructs.
> Remote peering of LDP is useful for certain application such as what you
> described in PWE3 VC label distribution. But the general application of mp2p
> LDP used in the core of networks creates lots of management problems that
> don't exist in IP. 

not sure I'd agree with that.

> The following is a comparison between LDP-MPLS (mp2p core) and IP, based on
> the comments seen so far:
> 
> LDP-MPLS:
> - Need another control-plane protocol (i.e., LDP signalling) on top of IP
> control-plane (routing only)
> - Packets could be mis-routed to wrong destination now because of LDP
> failures. Therefore needs an LSP maintenance tool (such as LSP-ping) to run
> continuously to detect defects (operators need automatic defect detection
> and handling, waiting for a customer complaint is simply not good enough).
> - Prevents spoofing

- VPN over MPLS can be implemented with current hardware.

> IP:
> 
> - Needs only IP control-plane (rouing only)
> - Packets can't be mis-routed to wrong destination (except in rare cases)
> due to use of IP addressing which is network unique rather than just
> hop/node unique

but mis-routing is a rare case even in MPLS networks.  You say you need
to be able to test for this.

but you say that there is no need to test for rarer cases.

I think we need some way to quantify how rare these cases (FIB
corruption and FIB corruption where the egress interface is null or is
an interface that will result in traffic being forwarded back to the
router with the corrupted entry) are?  It is non-obvious to me that the
first needs detection whilst the second doesn't.

> - Is subject to spoofing, therefore needs filtering at the edge
> - Requires 16 bytes more header per packet in VPN applications
> 
> So the question is which one is better to choose:
> -	LDP software on all routers + periodic connectivity test, or
> -	Filtering IP addresses (ACL) at the edge + 16 bytes more
> header/packet for VPN

or option 3 - LDP software on all routers and no connectivity test. 
That's what the majority of SPs run today AFAIK.

> Note that doing a connectivity test on a constantly moving target (LDP-based
> LSPs) is very difficult.

I'm not convinced that is the case.  As long as the LSRs can inject
packets into LSPs with source and destination IDs in the packet then I
think you should get a reasonable CV for those LSPs?

And in fact there is no reason why LDP-based LSPs should move any more
than ER LSPs.  The routing only changes when the topology changes, after
all?

Giles

> <snipped to end NH>
> 
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================



From owner-mpls@UU.NET  Thu Jun  6 02:09:43 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29276
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 02:09:43 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsaq25907
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 06:10:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsaq23945;
	Thu, 6 Jun 2002 06:09:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsaq22891
	for mpls-outgoing; Thu, 6 Jun 2002 06:08:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsaq22884
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 06:08:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsaq22102
	for <mpls@UU.NET>; Thu, 6 Jun 2002 06:08:30 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsaq27482
	for <mpls@UU.NET>; Thu, 6 Jun 2002 06:08:30 GMT
Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQmsaq27471
	for <mpls@UU.NET>; Thu, 6 Jun 2002 06:08:29 GMT
Received: from utfors.se ([172.20.0.77]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GX9TA900.NFM;
          Thu, 6 Jun 2002 08:13:21 +0200 
Message-ID: <3CFEFC6B.3070103@utfors.se>
Date: Thu, 06 Jun 2002 08:08:43 +0200
From: Loa Andersson <loa.andersson@utfors.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Loa Andersson <loa.andersson@utfors.se>
CC: mpls@UU.NET, sob@harvard.edu, bwijnen@lucent.com, swallow@cisco.com
Subject: wg last call on draft-heinanen-inarp-uni-01.txt - ended
References: <c4b9f19d.f19dc4b9@tomp.smb.utfors.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

The MPLS WG last call on


           Inverse ARP over Unidirectional Virtual Circuits


                    <draft-heinanen-inarp-uni-01.txt>
has ended.


/Loa and George
-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se



From owner-mpls@UU.NET  Thu Jun  6 04:47:42 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02395
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 04:47:42 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbb10286
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 08:48:09 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsbb08659;
	Thu, 6 Jun 2002 08:47:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsbb19866
	for mpls-outgoing; Thu, 6 Jun 2002 08:46:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsbb19857
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 08:46:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsbb20460
	for <mpls@UU.NET>; Thu, 6 Jun 2002 08:45:14 GMT
From: neil.2.harrison@bt.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbb20162
	for <mpls@UU.NET>; Thu, 6 Jun 2002 08:45:14 GMT
Received: from cbibipnt02.HC.BT.COM by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmsbb20154
	for <mpls@UU.NET>; Thu, 6 Jun 2002 08:45:13 GMT
Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <MCBGLDLA>; Thu, 6 Jun 2002 09:29:58 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABE34@mbddmknt01.hc.bt.com>
To: giles@packetexchange.net
Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Thu, 6 Jun 2002 09:29:41 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Giles,  please see below, regards, Neil

Giles Heron wrote 05 June 2002 17:38

<sniped>
> > > Why are you trying to get rid of LDP?  It certainly seems like
> > > that...:)
> > NH=> Can't get rid of it....its already here.  We have to 
> live with it.
> > What I think we are trying to find out is whether there is 
> any strong reason
> > to use LDP in the core of a network when used to create 
> mp2p constructs.
> > Remote peering of LDP is useful for certain application 
> such as what you
> > described in PWE3 VC label distribution. But the general 
> application of mp2p
> > LDP used in the core of networks creates lots of management 
> problems that
> > don't exist in IP. 
> 
> not sure I'd agree with that.
NH=> Well, I have thought long and hard about this, discussed it with lots
of people and sat down with the Ops guys here listening to their tales of
woe......its just a fact seen in practice, and its even relatively simple to
figure out anyway from the architecture as I have have tried to explain many
times now.

<snipped>
> 
> but mis-routing is a rare case even in MPLS networks.  You 
> say you need
> to be able to test for this.
NH=> Things break in many ways....we have plenty of evidence of this to say
its not so rare.  However, its only needs to happen once with some very
important customer to get bad press.  In any case, I think is a pretty
obvious requirement (or it should be) to have some form of check in the
data-plane that confirms that source X is truly connected to sink Y.  This
is not asking for the Earth....it's simply common-sense.
> 
> but you say that there is no need to test for rarer cases.
NH=> Not sure what you mean by this Giles.
<snipped>

> > So the question is which one is better to choose:
> > -	LDP software on all routers + periodic connectivity test, or
> > -	Filtering IP addresses (ACL) at the edge + 16 bytes more
> > header/packet for VPN
> 
> or option 3 - LDP software on all routers and no connectivity test. 
> That's what the majority of SPs run today AFAIK.
NH=> Yes I know.....this is what we were given so far and that is what we
are having to live with.
> 
> > Note that doing a connectivity test on a constantly moving 
> target (LDP-based
> > LSPs) is very difficult.
> 
> I'm not convinced that is the case.  As long as the LSRs can inject
> packets into LSPs with source and destination IDs in the packet then I
> think you should get a reasonable CV for those LSPs?
NH=> Yes you can do this.  Problem is the CVs build-up as the LSP is
considered closer and closer to its root.  You could scale this linearly (ie
1 cv/s on all mp2p segments) if CV/TTSI is consolidated at merge
points......but then this breaks the MPLS arch IMO by having to look at the
label stack to spot CV pkts.  The intention was to make CV transparent to
core LSRs, ie only relevant/seen at source/sink points.  However, since
LDP/mp2p constructs track the IGP and do SPF, then load balancing has to be
used to get around the traffic/topology sensitivities this creates.  Now you
could argue this too breaks the MPLS arch because you now have to perform a
hash function on the pkts.....so perhaps CV consolidation is only the same?
However, given all the other problems mp2p constructs create perhaps the
most pragamtic way to deal with them is:
-	note that for both L2 and L3 VPNs there is a single p2p hop above
the mp2p entity and run CV on that
-	this now detects any problems both at this level and below
-	if problems detected and no L1 indications of failure, then this
tells one to get out some other ad hoc tools (like some form of trace/ping
funcions) and start touble-shooting the mp2p entities.
At least now we would be aware of the problems before the customer (current
case) and could start to offer consistent SLAs.
> 
> And in fact there is no reason why LDP-based LSPs should move any more
> than ER LSPs.  The routing only changes when the topology 
> changes, after
> all?
NH=> You have to differentiate private and public services.  In the case of
VPNs their topologies are invariably long-holding, and once established you
don't actually to want them moving about at all (except under failures of
the *data-plane* where you would use prot-sw).  Ideally they should be
decoupled from ad hoc routing changes and protected from a
misbehaving/faulty control-plane (either routing or signalling).


From owner-mpls@UU.NET  Thu Jun  6 06:14:22 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04490
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 06:14:22 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbg05979
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 10:14:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsbg03976;
	Thu, 6 Jun 2002 10:13:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsbg09829
	for mpls-outgoing; Thu, 6 Jun 2002 10:13:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsbg09822
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 10:13:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsbg20443
	for <mpls@UU.NET>; Thu, 6 Jun 2002 10:13:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbg02029
	for <mpls@UU.NET>; Thu, 6 Jun 2002 10:13:15 GMT
Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmsbg02024
	for <mpls@UU.NET>; Thu, 6 Jun 2002 10:13:14 GMT
Received: from cbibipnt05.hc.bt.com ([147.149.196.177]) by cbibipnt02.HC.BT.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.89)
	id MCBGLQTR; Thu, 6 Jun 2002 11:13:24 +0100
Received: FROM celiborn.ip-engineering.bt.com BY cbibipnt05.hc.bt.com ; Thu Jun 06 11:13:18 2002 +0100
Received: from celiborn.galadriel.bt.co.uk ([132.146.100.200] helo=ip-engineering.bt.com)
	by celiborn.ip-engineering.bt.com with esmtp (Exim 4.04)
	id 17FuGS-0004zb-00; Thu, 06 Jun 2002 11:13:08 +0100
X-Mailer: exmh version 2.0.3 9/28/98
To: Giles Heron <giles@packetexchange.net>
cc: neil.2.harrison@bt.com, eosborne@cisco.com, Shahram_Davari@pmc-sierra.com,
        mpls@UU.NET, ppvpn@ppvpn.francetelecom.com
Subject: Re: Basic LDP Question 
In-reply-to: Your message of "05 Jun 2002 16:38:07 -0000."
             <1023295088.3106.315.camel@gizpad> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 06 Jun 2002 11:13:08 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Message-Id: <E17FuGS-0004zb-00@celiborn.ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> but mis-routing is a rare case even in MPLS networks.  You say you need
> to be able to test for this.
> 
> but you say that there is no need to test for rarer cases.
> 
> I think we need some way to quantify how rare these cases (FIB
> corruption and FIB corruption where the egress interface is null or is
> an interface that will result in traffic being forwarded back to the
> router with the corrupted entry) are?  It is non-obvious to me that the
> first needs detection whilst the second doesn't.

The issue is not to do with the frequency of the fault but the impact of the 
fault:

In case where we use IP in IP tunnels if there is a forwarding error then the 
tunnel packets will normally go into a routing loop so the VPN IP packets do 
not get delivered to the wrong customer so there is no security problem.

In the case of MPLS if there is a forwarding error the VPN IP packets can get 
delivered to the wrong customer so there is a security problem.

So for IP VPNs using IP in IP tunnels we can live without detection of 
mis-routing (although a tunnel livelness indicator would still be useful).
But for IP VPNs using MPLS we need something to detect mis-routing.

Peter.



From owner-mpls@UU.NET  Thu Jun  6 10:40:10 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16239
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 10:40:10 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbx29023
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 14:15:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsbw26434;
	Thu, 6 Jun 2002 14:14:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsbw27437
	for mpls-outgoing; Thu, 6 Jun 2002 14:13:52 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsbw27430
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 14:13:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsbw10032
	for <mpls@uu.net>; Thu, 6 Jun 2002 14:13:40 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsbw27757
	for <mpls@uu.net>; Thu, 6 Jun 2002 14:13:39 GMT
Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.113.11.114])
	id QQmsbw27750
	for <mpls@uu.net>; Thu, 6 Jun 2002 14:13:39 GMT
Received: from [80.253.97.67] (helo=gizpad.packetexchange.net)
	by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian))
	id 17Fy0w-0002ui-00; Thu, 06 Jun 2002 15:13:22 +0100
Subject: RE: Basic LDP Question
From: Giles Heron <giles@packetexchange.net>
To: neil.2.harrison@bt.com
Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
In-Reply-To: <B9571FDEBD3DD21181E500606DD5EE0514BABE34@mbddmknt01.hc.bt.com>
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE34@mbddmknt01.hc.bt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 06 Jun 2002 15:13:29 +0000
Message-Id: <1023376409.1610.111.camel@gizpad>
Mime-Version: 1.0
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

On Thu, 2002-06-06 at 08:29, neil.2.harrison@bt.com wrote:
> Giles,  please see below, regards, Neil
> 
> Giles Heron wrote 05 June 2002 17:38
> 
> <sniped>
> > > > Why are you trying to get rid of LDP?  It certainly seems like
> > > > that...:)
> > > NH=> Can't get rid of it....its already here.  We have to 
> > live with it.
> > > What I think we are trying to find out is whether there is 
> > any strong reason
> > > to use LDP in the core of a network when used to create 
> > mp2p constructs.
> > > Remote peering of LDP is useful for certain application 
> > such as what you
> > > described in PWE3 VC label distribution. But the general 
> > application of mp2p
> > > LDP used in the core of networks creates lots of management 
> > problems that
> > > don't exist in IP. 
> > 
> > not sure I'd agree with that.
> NH=> Well, I have thought long and hard about this, discussed it with lots
> of people and sat down with the Ops guys here listening to their tales of
> woe......its just a fact seen in practice, and its even relatively simple to
> figure out anyway from the architecture as I have have tried to explain many
> times now.

I think we have to agree to disagree on this, and to be careful to
present our views as such rather than as statements of fact?

> <snipped>
> > 
> > but mis-routing is a rare case even in MPLS networks.  You 
> > say you need
> > to be able to test for this.
> NH=> Things break in many ways....we have plenty of evidence of this to say
> its not so rare.  However, its only needs to happen once with some very
> important customer to get bad press.  In any case, I think is a pretty
> obvious requirement (or it should be) to have some form of check in the
> data-plane that confirms that source X is truly connected to sink Y.  This
> is not asking for the Earth....it's simply common-sense.
> > 
> > but you say that there is no need to test for rarer cases.
> NH=> Not sure what you mean by this Giles.
> <snipped>

I mean that mis-routing in MPLS is rare (I know you differ on this - but
I guess it depends on your definition of rare).

misrouting in IP is presumably rarer (as it requires a loop or a route
to /dev/null).

But I take Peter's argument that the risk in MPLS is mis-delivery
whereas with IP you would generally only see packets being dropped
(though there are probably pathological cases which would cause
mis-delivery in IP such as a router delivering packets locally instead
of to an outbound interface).

> > > So the question is which one is better to choose:
> > > -	LDP software on all routers + periodic connectivity test, or
> > > -	Filtering IP addresses (ACL) at the edge + 16 bytes more
> > > header/packet for VPN
> > 
> > or option 3 - LDP software on all routers and no connectivity test. 
> > That's what the majority of SPs run today AFAIK.
> NH=> Yes I know.....this is what we were given so far and that is what we
> are having to live with.
> > 
> > > Note that doing a connectivity test on a constantly moving 
> > target (LDP-based
> > > LSPs) is very difficult.
> > 
> > I'm not convinced that is the case.  As long as the LSRs can inject
> > packets into LSPs with source and destination IDs in the packet then I
> > think you should get a reasonable CV for those LSPs?
> NH=> Yes you can do this.  Problem is the CVs build-up as the LSP is
> considered closer and closer to its root.  You could scale this linearly (ie
> 1 cv/s on all mp2p segments) if CV/TTSI is consolidated at merge
> points......but then this breaks the MPLS arch IMO by having to look at the
> label stack to spot CV pkts.  The intention was to make CV transparent to
> core LSRs, ie only relevant/seen at source/sink points.  However, since
> LDP/mp2p constructs track the IGP and do SPF, then load balancing has to be
> used to get around the traffic/topology sensitivities this creates.  Now you
> could argue this too breaks the MPLS arch because you now have to perform a
> hash function on the pkts.....so perhaps CV consolidation is only the same?
> However, given all the other problems mp2p constructs create perhaps the
> most pragamtic way to deal with them is:

I'm not convinced that you need to "merge" the CVs.  If the frequency is
relatively low you can just allow them all through to the sink which can
check that it gets packets from all PEs to which it has a label mapping
learned with LDP?  Remember that if each PE sends the same frequency of
packets into each LSP this will create the same number of CV packets at
the sink as would a mesh of TE tunnels.

But yes, hashing is an issue.  I don't think we have an adequate
solution for this yet :(  The problem is that without knowing a-priori
what the hashing algorithm in your network is you have no way to know if
you have hit all possible hashed paths.

Which is one of the reasons why I would advocate testing using
client-layer tools, or in their absence external probes which can inject
real traffic into the network (the other reason is that errors may occur
in the adaptation function at the edges rather than in the core, and
MPLS OAM will fail to catch these - in fact I have seen more of these
events than MPLS FIB errors, probably because most of the processing
complexity is at the edge?)

> -	note that for both L2 and L3 VPNs there is a single p2p hop above
> the mp2p entity and run CV on that

I don't think this is true with L3 VPNs.  They merge at the VPN level,
don't they? (using mBGP a 2547 PE will likely advertise the same VPN
label to all peers for a given prefix?)

also for some flavours of L2VPN the same may be true.  For VPLS you
advertise a distinct label to each peer PE (to facilitate MAC learning),
but for "IPLS" the same label will most likely be advertised to each PE
(work on this is in progress...)

In general anything that relies on mBGP is likely to advertise the same
label to all peer PEs (as the labels are "broadcast" through the RR
infrastructure).  Whereas anything that relies on tLDP is likely to
advertise a distinct label to each peer PE - though of course there is
nothing (other than breaking the client protocol) to stop a PE
advertising the same label to multiple PEs over different tLDP sessions.

> -	this now detects any problems both at this level and below
> -	if problems detected and no L1 indications of failure, then this
> tells one to get out some other ad hoc tools (like some form of trace/ping
> funcions) and start touble-shooting the mp2p entities.
> At least now we would be aware of the problems before the customer (current
> case) and could start to offer consistent SLAs.
> > 
> > And in fact there is no reason why LDP-based LSPs should move any more
> > than ER LSPs.  The routing only changes when the topology 
> > changes, after
> > all?
> NH=> You have to differentiate private and public services.  In the case of
> VPNs their topologies are invariably long-holding, and once established you
> don't actually to want them moving about at all (except under failures of
> the *data-plane* where you would use prot-sw).  Ideally they should be
> decoupled from ad hoc routing changes and protected from a
> misbehaving/faulty control-plane (either routing or signalling).

But VPNs don't really have anything to do with this?  The mp2p labels in
the core are generally used to carry all services (i.e. they provide box
to box connectivity for all traffic, not service by service
connectivity).  On this basis they will hold until re-routing occurs in
the core?

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================



From owner-mpls@UU.NET  Thu Jun  6 12:38:38 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19815
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 12:38:38 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscg25622
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 16:39:04 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscg20304;
	Thu, 6 Jun 2002 16:36:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscg22946
	for mpls-outgoing; Thu, 6 Jun 2002 16:36:27 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmscg22941
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 16:36:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmscg09574
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:34:47 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscg18794
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:34:47 GMT
Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmscg18788
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:34:47 GMT
Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19)
	id <MM6AHVFG>; Thu, 6 Jun 2002 17:34:52 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABE46@mbddmknt01.hc.bt.com>
To: giles@packetexchange.net
Cc: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com, mpls@UU.NET,
        ppvpn@ppvpn.francetelecom.com
Subject: RE: Basic LDP Question
Date: Thu, 6 Jun 2002 17:34:41 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks Giles.....some good points in your full response.  Few minor remarks
below on snipped extract below.

regards, Neil

Giles Heron wrote 06 June 2002 16:13
<snipped>

> I'm not convinced that you need to "merge" the CVs.  If the 
> frequency is
> relatively low you can just allow them all through to the 
> sink which can
> check that it gets packets from all PEs to which it has a 
> label mapping
> learned with LDP?  Remember that if each PE sends the same 
> frequency of
> packets into each LSP this will create the same number of CV 
> packets at
> the sink as would a mesh of TE tunnels.
NH=> This is indeed 1 possibility.  However, changing the frequency of CV
generation is not without implications wrt defect entry/exit criteria.
There are 4 directions to consider wrt  connectivity defects: p2p=>p2p,
p2p=>mp2p, mp2p=>p2p and mp2p=>mp2p.  The more variability on CV rate the
more complex this gets.  Taking just 1 example of 1 particular
direction......suppose 1 LSP had a CV rate of 1/min and another 1/s.  If the
1/min CV LSP was mismerging into the 1/s CV LSP, starting at some point T,
then we would get a cycle of:
-	declare dMismerge after T+3s
-	clear dMismerge after T+6s
-	declare dMismerge after T+63s
-	etc
Further, mismerge from mp2p closer to root than leaf would generate higher
'bad' CV rate....so this would be yet another variable.
So changing CV rate is a possibility, but it would need to be done in a
consistent way across all LSPs IMO and there would still be difficulties
with mp2p depending on from which point on the mp2p tree the leaking was
occurring.
> 
> But yes, hashing is an issue.  I don't think we have an adequate
> solution for this yet :(  The problem is that without knowing a-priori
> what the hashing algorithm in your network is you have no way 
> to know if
> you have hit all possible hashed paths.
NH=> Agreed.  Architecturally the effect of hashing is doing something like:
terminate the LSPs, go up the stack, make a decision of forwarding direction
and then come back down the stack to new LSPs.  So its like have inv-muxing
subnetworks......and each of these trails ought to monitored in its own
right (since they too may malfunction independently).
> 
> Which is one of the reasons why I would advocate testing using
> client-layer tools, or in their absence external probes which 
> can inject
> real traffic into the network (the other reason is that 
> errors may occur
> in the adaptation function at the edges rather than in the core, and
> MPLS OAM will fail to catch these - in fact I have seen more of these
> events than MPLS FIB errors, probably because most of the processing
> complexity is at the edge?)
NH=> I agree problems are certainly not restricted to faulty LSPs.  But one
of the things to bear in mind here is that we want the flexibility to use
the same LSPs constructs for a whole range of client layer signals and
applications....so we need some method of fault-management that is
common/simple to MPLS alone.  But I agree, we also need higher level tools
specific to the actual protocol carried (esp if it has no fault-management
of its own defined).
> 
> > -	note that for both L2 and L3 VPNs there is a single p2p 
> hop above
> > the mp2p entity and run CV on that
> 
> I don't think this is true with L3 VPNs.  They merge at the VPN level,
> don't they? (using mBGP a 2547 PE will likely advertise the same VPN
> label to all peers for a given prefix?)
NH=> Yes this is quite true.  But they are subtley different IMO.  In mp2p
there really is traffic merging post a given P LSR with a common label.  In
the top-level LSPs its more of a "converge" at the PE rather than a merge,
ie there is no subsequent common label at the LSP level.  So I think it
ought to be possible to have a simple CV flow on these.  Now how that would
get configured is a different question.
<snipped>


From owner-mpls@UU.NET  Thu Jun  6 12:40:07 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19855
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 12:40:07 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscg24609
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 16:40:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscg21987;
	Thu, 6 Jun 2002 16:39:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscg23072
	for mpls-outgoing; Thu, 6 Jun 2002 16:39:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmscg23061
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 16:39:01 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmscg26132
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:38:38 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscg07464
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:38:27 GMT
Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQmscg07380
	for <mpls@UU.NET>; Thu, 6 Jun 2002 16:38:17 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA25116
	for <mpls@UU.NET>; Thu, 6 Jun 2002 12:32:54 -0400 (EDT)
Subject: rsvpte ip address of the node  ----routerid, or interface address?
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF3EB991C4.F2FB6A72-ON85256BD0.005A644F@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 6 Jun 2002 12:32:50 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 06/06/2002 12:32:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

I have question for the rsvpte.

In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address ---- the
IP address of the node in which the error was detected.

Here the IP address of the node is the router id or interface IP address?

 For instance the intermediate lsr all the interfaces connected to the
router belong to that node.

Thanks in an advance.

Julia



From owner-mpls@UU.NET  Thu Jun  6 18:57:53 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05903
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 18:57:52 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscx27469
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:52:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscx24627;
	Thu, 6 Jun 2002 20:50:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscx12466
	for mpls-outgoing; Thu, 6 Jun 2002 20:50:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmscx12459
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:50:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmscx17794
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:50:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscx24130
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:50:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmscx24113
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:50:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21280 for <mpls@uu.net>; Thu, 6 Jun 2002 16:50:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA21766 for mpls@uu.net; Thu, 6 Jun 2002 16:50:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmscx12414
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:49:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmscx11941
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:48:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscx23216
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:48:30 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: london2.cisco.com [64.103.110.74])
	id QQmscx23210
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:48:30 GMT
Received: from JGUICHARW2K (ch2-dhcp134-149.cisco.com [161.44.134.149])
	by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA24149;
	Thu, 6 Jun 2002 21:48:26 +0100 (BST)
From: "Jim Guichard" <jguichar@cisco.com>
To: "Vach Kompella" <vkompella@timetra.com>, "Mpls-wg" <mpls@UU.NET>
Subject: RE: Hello adjacency creation
Date: Thu, 6 Jun 2002 16:45:36 -0400
Message-ID: <GBEOKAHINPNKJKNAELODIEFOCNAA.jguichar@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <FNEFIPCNJKDDONJGBCNECEFBDBAA.vkompella@timetra.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



> >-----Original Message-----
> >From: Vach Kompella [mailto:vkompella@timetra.com]
> >Sent: Thursday, June 06, 2002 4:33 PM
> >To: Jim Guichard; Mpls-wg
> >Subject: RE: Hello adjacency creation
> >
> >
> >Thanks for the response.  One thing I want to clarify about the
> >principle of my
> >initial question: in lieu of any other information (e.g.,
> >policies, new TLVs or
> >vendor-specific TLVs for identifying the nature of FECs to be
> >disseminated),
> >what SHOULD the behavior be?

do you mean what do I think the behavior should be ? or what the behavior
should be based on what the RFC says ?

> >
> >-Vach
> >
> >> -----Original Message-----
> >> From: Jim Guichard [mailto:jguichar@cisco.com]
> >> Sent: Thursday, June 06, 2002 1:22 PM
> >> To: Vach Kompella; Mpls-wg
> >> Subject: RE: Hello adjacency creation
> >>
> >>
> >> Hi Vach,
> >>
> >> > >
> >> > >Also, the existence of a targeted adjacency is typically for VC
> >> > >label exchange
> >> > >or for tunneled next hop resolution, whereas link adjacency is
> >> > >typically used
> >> > >for LSPs following the IGP.
> >>
> >> there is nothing to stop targeted LDP being used to maintain the LDP
> >> topology should a link failure occur.
> >
> >Agreed, but is this the default (expected) behavior?

a targeted LDP session will only be established if specifically configured
so the default behavior is no targeted session. If a targeted session is
configured then the default behavior is to send hello's across the adjacency
and maintain the LDP session should the link between the two LSRs fail (and
an alternate path be available).

> >
> >>
> >> > >
> >> > >Does one exchange VC labels over a session over which link
> >> > >adjacency only has
> >> > >been set up?  That seems silly.  E.g., A and B exchange VC
> >labels over a
> >> > >targeted session, but X and B have a (link) adjacency and an LDP
> >> > >session.  You
> >> > >wouldn't want B and X to exchange labels for martini VCs.
> >>
> >> perhaps not, but they will as there is nothing in LDP to tell
> >the peer which
> >> types of labels you want to receive.
> >
> >But we do want to limit this distribution of unnecessary FECs, don't we?

imo I would say so

> >
> >>
> >> > >
> >> > >   -----         -----          -----
> >> > >   | A |---------| X |----------| B |
> >> > >   -----         -----          -----
> >> > >
> >> > >Finally, in the upper configuration, if A and B only have a
> >> > >targeted adjacency,
> >> > >then shouldn't B avoid sending address FECs to A which doesn't
> >> > >really care for
> >> > >them?
> >>
> >> imo yes, but currently B will send everything to A unless you filter.
> >
> >Again, I'm asking if it is reasonable to impose some reasonable limits.
> >

It would seem reasonable to only exchange the label space that is relevant
to the adjacent peer, but this is my opinion and not what the RFC says.

> >>
> >> > >
> >> > >Since I couldn't find this behavior described in the RFCs, I
> >> > >propose a default
> >> > >behavior for adjacency creation and scoping of FEC
> >signaling so that:
> >
> >> > >2. if only a link adjacency is established between a pair of
> >> > >LSRs, then address
> >> > >FECs SHOULD be exchanged over the concomitant session, and
> >no other FECs
> >> > >3. if only a targeted adjacency is established between a pair of
> >> > >LSRs, then
> >> > >non-address FECs SHOULD be exchanged over the session, and
> >no other FECs
> >>
> >> you cannot do this as it will break certain traffic
> >engineering scenarios -
> >> you may want to exchange address FECs.
> >
> >So make the TE scenarios driven by directives (either signaled
> >or configured).

I am not sure what you mean - if you have a TE tunnel in the core of the
network and you have to maintain an LSP between two edge devices then you
must run LDP on the TE tunnel so that the packets can be corrected switched
when exiting the tunnel - my point was that you cannot dictate that targeted
LDP carries non-address FECs only. Jim

> >
> >>
> >> > >4. if both adjacencies are set up, then all known FECs SHOULD be
> >> > >exchanged
> >> > >
> >> > >Similarly, when adjacencies are torn down:
> >> > >1. if no link adjacency exists, then all address FECs
> >should be withdrawn
> >> > >2. if no targeted adjacency exists, then all non-address
> >FECs should be
> >> > >withdrawn
> >> > >
> >> > >Does this make sense?
> >>
> >> yes and no :) I think that the way to deal with this is to add
> >some kind of
> >> signaling during session setup so that two LSRs can indicate
> >which type of
> >> FECs they wish to exchange .. Jim
> >
> >My point exactly.  If we define a baseline behavior that we don't have to
> >signal, then we can add optional signaling to extend the
> >signaling behavior over
> >the session.



From owner-mpls@UU.NET  Thu Jun  6 18:58:24 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06104
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 18:58:24 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdc19242
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 22:12:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsdc17992;
	Thu, 6 Jun 2002 22:11:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsdc02718
	for mpls-outgoing; Thu, 6 Jun 2002 22:11:39 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsdc02713
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 22:11:36 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsdc23608
	for <mpls@uu.net>; Thu, 6 Jun 2002 22:11:00 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdc00049
	for <mpls@uu.net>; Thu, 6 Jun 2002 22:11:00 GMT
Received: from mail.iPolicyNet.COM by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.policyone.com [63.199.81.149])
	id QQmsdc00041
	for <mpls@uu.net>; Thu, 6 Jun 2002 22:10:59 GMT
Received: from ca-mail01.CA.iPolicyNet.COM (CA-Mail01.CA.iPolicyNet.COM [199.172.181.4])
	by mail.iPolicyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16862
	for <mpls@uu.net>; Thu, 6 Jun 2002 14:54:41 -0700 (PDT)
Received: by CA-Mail01.CA.iPolicyNet.COM with Internet Mail Service (5.5.2653.19)
	id <LY27PV4A>; Thu, 6 Jun 2002 15:08:55 -0700
Message-ID: <C1352E2D7153D411B83000508BD6924779F3F1@CA-Mail01.CA.iPolicyNet.COM>
From: "Nakum, Vimal" <vnakum@iPolicyNet.COM>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: SONET APS Question
Date: Thu, 6 Jun 2002 15:08:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20DA6.B91182E0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20DA6.B91182E0
Content-Type: text/plain;
	charset="ISO-8859-1"


> Hi,
> 
> In SONET standards, it is mentioned that K1/K2 bytes carry APS Protocol
> bytes on protection line when signal degrade happens on working line.
> Suppose after some times, working line becomes up. Now, when signal
> degrade happens on protection line, how link switches back to working line
> ? Does working line carries K1/K2 bytes, indicating switchover to working
> line  or  both ends assume that now transfer will be on working line ?
> 
> Thanks,
> 
> Vimal Nakum

------_=_NextPart_001_01C20DA6.B91182E0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SONET APS Question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In SONET standards, it is mentioned =
that K1/K2 bytes carry APS Protocol bytes on protection line when =
signal degrade happens on working line. Suppose after some times, =
working line becomes up. Now, when signal degrade happens on protection =
line, how link switches back to working line ? Does working line =
carries K1/K2 bytes, indicating switchover to working line&nbsp; =
or&nbsp; both ends assume that now transfer will be on working line =
?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Vimal Nakum</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C20DA6.B91182E0--


From owner-mpls@UU.NET  Thu Jun  6 18:59:08 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06353
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 18:59:08 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscv17650
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:18:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscv16054;
	Thu, 6 Jun 2002 20:18:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscv09762
	for mpls-outgoing; Thu, 6 Jun 2002 20:17:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmscv09757
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:17:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmscv00232
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:16:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscv15033
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:16:03 GMT
Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQmscv15026
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:16:03 GMT
Received: from u43.redback.com (u43.redback.com [155.53.8.143])
	by prattle.redback.com (Postfix) with ESMTP
	id 3B13739B5B1; Thu,  6 Jun 2002 13:16:02 -0700 (PDT)
Received: (from rahul@localhost)
	by u43.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id NAA05699;
	Thu, 6 Jun 2002 13:16:02 -0700 (PDT)
Date: Thu, 6 Jun 2002 13:16:02 -0700
From: Rahul Aggarwal <rahul@redback.com>
To: Vach Kompella <vkompella@timetra.com>
Cc: Mpls-wg <mpls@UU.NET>
Subject: Re: Hello adjacency creation
Message-ID: <20020606131602.E3367@u43.redback.com>
References: <FNEFIPCNJKDDONJGBCNEAEFADBAA.vkompella@timetra.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <FNEFIPCNJKDDONJGBCNEAEFADBAA.vkompella@timetra.com>; from vkompella@timetra.com on Thu, Jun 06, 2002 at 12:47:48PM -0700
Sender: owner-mpls@UU.NET
Precedence: bulk

The announcement of prefix FECs or VC FECs to a particular peer
is really driven by the information that the peer is interested in :

a) For prefix FECs, typically the existance of a LDP link level
hello adjancency with a peer implies that prefix FECs are to be
exchanged with that peer. However for certain reasons one may
explictly configure a targeted adjancency with a peer to exchange
prefix FECs. Eg : When a LDP session is being tunnelled.

b) For VC FECs, if a VC (Pseudo wire) is configured to a 
particular peer all that should matter is whether there is an 
adjacency to that peer. For directly connected LSRs this could well
be a link level adjacency. 

IMO this would be the driving factor of prefix FEC /VC FEC announcements.

Some more comments inline :

On Thu, Jun 06, 2002 at 12:47:48PM -0700, Vach Kompella wrote:
> Suppose there are two adjacent LSRs A and B which try to set up both regular
> link-level LDP, as well as targeted LDP.
> 
>    -----         -----
>    | A |---------| B |
>    -----         -----
> 
> Only a single LDP session/TCP connection is established, but are two hello
> adjacencies set up?  Having only a single one would mean that if the interface
> was brought down, the session would terminate.

Two hello adjancencies should be set up as per rfc3036.

> 
> Also, the existence of a targeted adjacency is typically for VC label exchange
> or for tunneled next hop resolution, whereas link adjacency is typically used
> for LSPs following the IGP.
> 
> Does one exchange VC labels over a session over which link adjacency only has
> been set up?  That seems silly.  E.g., A and B exchange VC labels over a
> targeted session, but X and B have a (link) adjacency and an LDP session.  You
> wouldn't want B and X to exchange labels for martini VCs.

For directly connected LSRs if someone wants to do this, I don't see why it 
should be disallowed. For exchanging Martini labels one should only be 
interested in seeing if there is a peering session with the peer in question.

> 
>    -----         -----          -----
>    | A |---------| X |----------| B |
>    -----         -----          -----
> 
> Finally, in the upper configuration, if A and B only have a targeted adjacency,
> then shouldn't B avoid sending address FECs to A which doesn't really care for
> them?

Only if A and B are not explicitly configured to exchange prefix FECs over the
targeted session.

> 
> Since I couldn't find this behavior described in the RFCs, I propose a default
> behavior for adjacency creation and scoping of FEC signaling so that:
> 1. parallel hello adjacencies are set up, even though only one session is used
> to exchange labels, when both link and targeted adjacencies are requested
> 2. if only a link adjacency is established between a pair of LSRs, then address
> FECs SHOULD be exchanged over the concomitant session, and no other FECs

> 3. if only a targeted adjacency is established between a pair of LSRs, then
> non-address FECs SHOULD be exchanged over the session, and no other FECs

This doesn't sound right. One may be exchaning prefix FECs over a targeted 
session when a LDP session is being tunnelled for some reason.

> 4. if both adjacencies are set up, then all known FECs SHOULD be exchanged
> 
> Similarly, when adjacencies are torn down:
> 1. if no link adjacency exists, then all address FECs should be withdrawn
> 2. if no targeted adjacency exists, then all non-address FECs should be
> withdrawn
> 
> Does this make sense?  I have run across some behavior that doesn't quite follow
> these rules, so if others are operating on other rules of behavior, could we
> have some discussion on how to resolve this?  Thanks.
> 
> -Vach
> 


From owner-mpls@UU.NET  Thu Jun  6 19:26:16 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13202
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 19:26:16 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscw03768
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:36:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscw01027;
	Thu, 6 Jun 2002 20:35:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscw11006
	for mpls-outgoing; Thu, 6 Jun 2002 20:34:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmscw10972
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:34:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmscw27277
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:33:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscw08418
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:33:58 GMT
Received: from mail.timetra.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.timetra.com [63.104.212.2])
	id QQmscw08413
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:33:58 GMT
Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 6 Jun 2002 13:33:26 -0700
From: "Vach Kompella" <vkompella@timetra.com>
To: "Jim Guichard" <jguichar@cisco.com>, "Mpls-wg" <mpls@UU.NET>
Subject: RE: Hello adjacency creation
Date: Thu, 6 Jun 2002 13:33:27 -0700
Message-ID: <FNEFIPCNJKDDONJGBCNECEFBDBAA.vkompella@timetra.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <GBEOKAHINPNKJKNAELODIEFMCNAA.jguichar@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 06 Jun 2002 20:33:26.0572 (UTC) FILETIME=[693036C0:01C20D99]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks for the response.  One thing I want to clarify about the principle of my
initial question: in lieu of any other information (e.g., policies, new TLVs or
vendor-specific TLVs for identifying the nature of FECs to be disseminated),
what SHOULD the behavior be?

-Vach

> -----Original Message-----
> From: Jim Guichard [mailto:jguichar@cisco.com]
> Sent: Thursday, June 06, 2002 1:22 PM
> To: Vach Kompella; Mpls-wg
> Subject: RE: Hello adjacency creation
>
>
> Hi Vach,
>
> > >
> > >Also, the existence of a targeted adjacency is typically for VC
> > >label exchange
> > >or for tunneled next hop resolution, whereas link adjacency is
> > >typically used
> > >for LSPs following the IGP.
>
> there is nothing to stop targeted LDP being used to maintain the LDP
> topology should a link failure occur.

Agreed, but is this the default (expected) behavior?

>
> > >
> > >Does one exchange VC labels over a session over which link
> > >adjacency only has
> > >been set up?  That seems silly.  E.g., A and B exchange VC labels over a
> > >targeted session, but X and B have a (link) adjacency and an LDP
> > >session.  You
> > >wouldn't want B and X to exchange labels for martini VCs.
>
> perhaps not, but they will as there is nothing in LDP to tell the peer which
> types of labels you want to receive.

But we do want to limit this distribution of unnecessary FECs, don't we?

>
> > >
> > >   -----         -----          -----
> > >   | A |---------| X |----------| B |
> > >   -----         -----          -----
> > >
> > >Finally, in the upper configuration, if A and B only have a
> > >targeted adjacency,
> > >then shouldn't B avoid sending address FECs to A which doesn't
> > >really care for
> > >them?
>
> imo yes, but currently B will send everything to A unless you filter.

Again, I'm asking if it is reasonable to impose some reasonable limits.

>
> > >
> > >Since I couldn't find this behavior described in the RFCs, I
> > >propose a default
> > >behavior for adjacency creation and scoping of FEC signaling so that:

> > >2. if only a link adjacency is established between a pair of
> > >LSRs, then address
> > >FECs SHOULD be exchanged over the concomitant session, and no other FECs
> > >3. if only a targeted adjacency is established between a pair of
> > >LSRs, then
> > >non-address FECs SHOULD be exchanged over the session, and no other FECs
>
> you cannot do this as it will break certain traffic engineering scenarios -
> you may want to exchange address FECs.

So make the TE scenarios driven by directives (either signaled or configured).

>
> > >4. if both adjacencies are set up, then all known FECs SHOULD be
> > >exchanged
> > >
> > >Similarly, when adjacencies are torn down:
> > >1. if no link adjacency exists, then all address FECs should be withdrawn
> > >2. if no targeted adjacency exists, then all non-address FECs should be
> > >withdrawn
> > >
> > >Does this make sense?
>
> yes and no :) I think that the way to deal with this is to add some kind of
> signaling during session setup so that two LSRs can indicate which type of
> FECs they wish to exchange .. Jim

My point exactly.  If we define a baseline behavior that we don't have to
signal, then we can add optional signaling to extend the signaling behavior over
the session.



From owner-mpls@UU.NET  Thu Jun  6 19:31:46 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14226
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 19:31:46 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscx23786
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:56:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscx19812;
	Thu, 6 Jun 2002 20:54:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscx12673
	for mpls-outgoing; Thu, 6 Jun 2002 20:53:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmscx12657
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:53:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmscx25161
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:53:20 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscx19213
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:53:19 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQmscx19208
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:53:19 GMT
Received: from u43.redback.com (u43.redback.com [155.53.8.143])
	by prattle.redback.com (Postfix) with ESMTP
	id 5CA13F2C49; Thu,  6 Jun 2002 13:53:18 -0700 (PDT)
Received: (from rahul@localhost)
	by u43.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id NAA08606;
	Thu, 6 Jun 2002 13:53:18 -0700 (PDT)
Date: Thu, 6 Jun 2002 13:53:18 -0700
From: Rahul Aggarwal <rahul@redback.com>
To: Jim Guichard <jguichar@cisco.com>
Cc: Vach Kompella <vkompella@timetra.com>, Mpls-wg <mpls@UU.NET>
Subject: Re: Hello adjacency creation
Message-ID: <20020606135318.H3367@u43.redback.com>
References: <FNEFIPCNJKDDONJGBCNEAEFADBAA.vkompella@timetra.com> <GBEOKAHINPNKJKNAELODIEFMCNAA.jguichar@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <GBEOKAHINPNKJKNAELODIEFMCNAA.jguichar@cisco.com>; from jguichar@cisco.com on Thu, Jun 06, 2002 at 04:22:21PM -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Jim/Vach,

[snipped]

> 
> yes and no :) I think that the way to deal with this is to add some kind of
> signaling during session setup so that two LSRs can indicate which type of
> FECs they wish to exchange .. Jim

I am not sure if this is needed to solve this case. A targeted adjacency
is used to send either VC FECs (if a pseudo wire is configured to a peer)
or for tunneling a regular LDP session (eg. for TE). Both these cases
are driven by some configuration. By default prefix FECs should not be
exchanged over a targeted session.

As far as exchanging VC FECs over a link adjancency is concerned, if two
peers are directly connected, I don't see a problem with this. Else ofcourse
one needs a targeted adjancency.

On the other hand I do agree that exchanging a session capability can be 
useful.

> 
>   I have run across some behavior that
> > >doesn't quite follow
> > >these rules, so if others are operating on other rules of
> > >behavior, could we
> > >have some discussion on how to resolve this?  Thanks.
> > >
> > >-Vach
> 


From owner-mpls@UU.NET  Thu Jun  6 19:34:30 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14880
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 19:34:30 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscv01157
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:29:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmscv28880;
	Thu, 6 Jun 2002 20:28:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmscv10490
	for mpls-outgoing; Thu, 6 Jun 2002 20:27:56 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmscv10485
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:27:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmscv10217
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:27:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscv09444
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:27:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmscv09439
	for <mpls@uu.net>; Thu, 6 Jun 2002 20:27:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA19761 for <mpls@uu.net>; Thu, 6 Jun 2002 16:27:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA18454 for mpls@uu.net; Thu, 6 Jun 2002 16:27:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmscv10258
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 20:25:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmscv06880
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:25:16 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmscv08145
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:25:16 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: london2.cisco.com [64.103.110.74])
	id QQmscv08131
	for <mpls@UU.NET>; Thu, 6 Jun 2002 20:25:15 GMT
Received: from JGUICHARW2K (ch2-dhcp134-149.cisco.com [161.44.134.149])
	by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA23198;
	Thu, 6 Jun 2002 21:25:12 +0100 (BST)
From: "Jim Guichard" <jguichar@cisco.com>
To: "Vach Kompella" <vkompella@timetra.com>, "Mpls-wg" <mpls@UU.NET>
Subject: RE: Hello adjacency creation
Date: Thu, 6 Jun 2002 16:22:21 -0400
Message-ID: <GBEOKAHINPNKJKNAELODIEFMCNAA.jguichar@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <FNEFIPCNJKDDONJGBCNEAEFADBAA.vkompella@timetra.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Vach,

> >-----Original Message-----
> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vach
> >Kompella
> >Sent: Thursday, June 06, 2002 3:48 PM
> >To: Mpls-wg
> >Subject: Hello adjacency creation
> >
> >
> >Suppose there are two adjacent LSRs A and B which try to set up
> >both regular
> >link-level LDP, as well as targeted LDP.
> >
> >   -----         -----
> >   | A |---------| B |
> >   -----         -----
> >
> >Only a single LDP session/TCP connection is established,

this is correct.

 but are
> >two hello
> >adjacencies set up?

yes - hello's will be sent across each adjacency.

  Having only a single one would mean that if
> >the interface
> >was brought down, the session would terminate.

right, and therefore we want to maintain targeted LDP so that we can prevent
the removal of all the label space.

> >
> >Also, the existence of a targeted adjacency is typically for VC
> >label exchange
> >or for tunneled next hop resolution, whereas link adjacency is
> >typically used
> >for LSPs following the IGP.

there is nothing to stop targeted LDP being used to maintain the LDP
topology should a link failure occur.

> >
> >Does one exchange VC labels over a session over which link
> >adjacency only has
> >been set up?  That seems silly.  E.g., A and B exchange VC labels over a
> >targeted session, but X and B have a (link) adjacency and an LDP
> >session.  You
> >wouldn't want B and X to exchange labels for martini VCs.

perhaps not, but they will as there is nothing in LDP to tell the peer which
types of labels you want to receive.

> >
> >   -----         -----          -----
> >   | A |---------| X |----------| B |
> >   -----         -----          -----
> >
> >Finally, in the upper configuration, if A and B only have a
> >targeted adjacency,
> >then shouldn't B avoid sending address FECs to A which doesn't
> >really care for
> >them?

imo yes, but currently B will send everything to A unless you filter.

> >
> >Since I couldn't find this behavior described in the RFCs, I
> >propose a default
> >behavior for adjacency creation and scoping of FEC signaling so that:
> >1. parallel hello adjacencies are set up, even though only one
> >session is used
> >to exchange labels, when both link and targeted adjacencies are requested

this is the case today.

> >2. if only a link adjacency is established between a pair of
> >LSRs, then address
> >FECs SHOULD be exchanged over the concomitant session, and no other FECs
> >3. if only a targeted adjacency is established between a pair of
> >LSRs, then
> >non-address FECs SHOULD be exchanged over the session, and no other FECs

you cannot do this as it will break certain traffic engineering scenarios -
you may want to exchange address FECs.

> >4. if both adjacencies are set up, then all known FECs SHOULD be
> >exchanged
> >
> >Similarly, when adjacencies are torn down:
> >1. if no link adjacency exists, then all address FECs should be withdrawn
> >2. if no targeted adjacency exists, then all non-address FECs should be
> >withdrawn
> >
> >Does this make sense?

yes and no :) I think that the way to deal with this is to add some kind of
signaling during session setup so that two LSRs can indicate which type of
FECs they wish to exchange .. Jim

  I have run across some behavior that
> >doesn't quite follow
> >these rules, so if others are operating on other rules of
> >behavior, could we
> >have some discussion on how to resolve this?  Thanks.
> >
> >-Vach



From owner-mpls@UU.NET  Thu Jun  6 20:08:01 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18540
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:08:01 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdk15759
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 00:08:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsdk14513;
	Fri, 7 Jun 2002 00:08:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsdk24521
	for mpls-outgoing; Fri, 7 Jun 2002 00:07:50 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsdk24511
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Jun 2002 00:07:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsdk29091
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:06:38 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdk13782
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:06:38 GMT
Received: from ottawa02.lanterncom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.191.227.35])
	id QQmsdk13776
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:06:38 GMT
Received: by OTTAWA02 with Internet Mail Service (5.5.2655.55)
	id <K8QCQXPY>; Thu, 6 Jun 2002 20:11:56 -0400
Message-ID: <4BAC766A2FCDD4119C5E00E018021DE981EA80@OTTAWA02>
From: Gary Tam <gtam@lanterncom.com>
To: "'Nakum, Vimal'" <vnakum@iPolicyNet.COM>, "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: SONET APS Question
Date: Thu, 6 Jun 2002 20:11:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20DB7.EEC88490"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20DB7.EEC88490
Content-Type: text/plain;
	charset="iso-8859-1"

This is an MPLS issue and should be not concerned with this forum. 
 
To answer your question, first of all, the K1/K2 is capsulated on the STS-1
Line Overhead. So 
both the working and protection paths will receive K1/K2 in normal
condition. Secondary, 
it is up to the protection scheme and mode to decide whether to revert back
to the working 
line or not when the working line becomes healthy again. If it is revertive
and working path state
changes from fail to ok, traffic will be switched back to the working path
after a wait-to-restore 
period.  If it is non-revertive, of course it will not.  So if the working
is healthy, traffic is on 
the protection path and and the protection path is faulty, traffic will
switch back to the working 
path for sure. 

-----Original Message-----
From: Nakum, Vimal [mailto:vnakum@iPolicyNet.COM]
Sent: Thursday, June 06, 2002 6:09 PM
To: 'mpls@uu.net'
Subject: SONET APS Question




Hi, 

In SONET standards, it is mentioned that K1/K2 bytes carry APS Protocol
bytes on protection line when signal degrade happens on working line.
Suppose after some times, working line becomes up. Now, when signal degrade
happens on protection line, how link switches back to working line ? Does
working line carries K1/K2 bytes, indicating switchover to working line  or
both ends assume that now transfer will be on working line ?

Thanks, 

Vimal Nakum 


------_=_NextPart_001_01C20DB7.EEC88490
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>SONET APS Question</TITLE>

<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>This 
is an MPLS issue and should be not concerned with this forum. 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>To 
answer your question, </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>first of all, the K1/K2 is capsulated on the STS-1 Line 
Overhead. So </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>both 
the working and </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>protection paths will receive K1/K2 in normal 
condition. Secondary, </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>it is 
up to the </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>protection </SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=335355123-06062002>scheme and mode to decide whether to 
revert back to the working </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>line 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>or not when </SPAN></FONT><FONT color=#0000ff 
face=Arial size=2><SPAN class=335355123-06062002>the working line 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>becomes healthy again. If it is revertive and working 
path state</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>changes from fail to ok, </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>traffic will be 
switched</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002> back&nbsp;to the working path&nbsp;after a 
wait-to-restore&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>period.&nbsp; If it is non-revertive, of course it will 
not.&nbsp; So if the working is healthy, traffic is on </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>the 
protection path and and the </SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=335355123-06062002>protection path </SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>is 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=335355123-06062002>faulty, traffic</SPAN></FONT><FONT color=#0000ff 
face=Arial size=2><SPAN class=335355123-06062002> will switch back to the 
working </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>path 
for sure. </SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Nakum, Vimal 
  [mailto:vnakum@iPolicyNet.COM]<BR><B>Sent:</B> Thursday, June 06, 2002 6:09 
  PM<BR><B>To:</B> 'mpls@uu.net'<BR><B>Subject:</B> SONET APS 
  Question<BR><BR></DIV></FONT><BR>
  <P><FONT face=Arial size=2>Hi,</FONT> </P>
  <P><FONT face=Arial size=2>In SONET standards, it is mentioned that K1/K2 
  bytes carry APS Protocol bytes on protection line when signal degrade happens 
  on working line. Suppose after some times, working line becomes up. Now, when 
  signal degrade happens on protection line, how link switches back to working 
  line ? Does working line carries K1/K2 bytes, indicating switchover to working 
  line&nbsp; or&nbsp; both ends assume that now transfer will be on working line 
  ?</FONT></P>
  <P><FONT face=Arial size=2>Thanks,</FONT> </P>
  <P><FONT face=Arial size=2>Vimal Nakum</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C20DB7.EEC88490--


From owner-mpls@UU.NET  Thu Jun  6 20:13:40 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18916
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 20:13:40 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdk24123
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 00:14:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsdk22517;
	Fri, 7 Jun 2002 00:13:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsdk25687
	for mpls-outgoing; Fri, 7 Jun 2002 00:13:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsdk25682
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Jun 2002 00:13:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsdk01078
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:13:02 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsdk04118
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:13:01 GMT
Received: from mail.iPolicyNet.COM by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.policyone.com [63.199.81.149])
	id QQmsdk04112
	for <mpls@UU.NET>; Fri, 7 Jun 2002 00:13:01 GMT
Received: from ca-mail01.CA.iPolicyNet.COM (CA-Mail01.CA.iPolicyNet.COM [199.172.181.4])
	by mail.iPolicyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17427;
	Thu, 6 Jun 2002 16:56:44 -0700 (PDT)
Received: by CA-Mail01.CA.iPolicyNet.COM with Internet Mail Service (5.5.2653.19)
	id <LY27PVXN>; Thu, 6 Jun 2002 17:10:56 -0700
Message-ID: <C1352E2D7153D411B83000508BD6924779F3F2@CA-Mail01.CA.iPolicyNet.COM>
From: "Nakum, Vimal" <vnakum@iPolicyNet.COM>
To: "'Gary Tam'" <gtam@lanterncom.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: SONET APS Question
Date: Thu, 6 Jun 2002 17:10:50 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20DB7.C7B947E0"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20DB7.C7B947E0
Content-Type: text/plain;
	charset="ISO-8859-1"

Sorry for the trouble.
 
Thanks for the answer.
 
Vimal Nakum

-----Original Message-----
From: Gary Tam [mailto:gtam@lanterncom.com]
Sent: Thursday, June 06, 2002 6:12 PM
To: 'Nakum, Vimal'; 'mpls@uu.net'
Subject: RE: SONET APS Question


This is an MPLS issue and should be not concerned with this forum. 
 
To answer your question, first of all, the K1/K2 is capsulated on the STS-1
Line Overhead. So 
both the working and protection paths will receive K1/K2 in normal
condition. Secondary, 
it is up to the protection scheme and mode to decide whether to revert back
to the working 
line or not when the working line becomes healthy again. If it is revertive
and working path state
changes from fail to ok, traffic will be switched back to the working path
after a wait-to-restore 
period.  If it is non-revertive, of course it will not.  So if the working
is healthy, traffic is on 
the protection path and and the protection path is faulty, traffic will
switch back to the working 
path for sure. 

-----Original Message-----
From: Nakum, Vimal [mailto:vnakum@iPolicyNet.COM]
Sent: Thursday, June 06, 2002 6:09 PM
To: 'mpls@uu.net'
Subject: SONET APS Question




Hi, 

In SONET standards, it is mentioned that K1/K2 bytes carry APS Protocol
bytes on protection line when signal degrade happens on working line.
Suppose after some times, working line becomes up. Now, when signal degrade
happens on protection line, how link switches back to working line ? Does
working line carries K1/K2 bytes, indicating switchover to working line  or
both ends assume that now transfer will be on working line ?

Thanks, 

Vimal Nakum 


------_=_NextPart_001_01C20DB7.C7B947E0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>SONET APS Question</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=096541923-06062002>Sorry 
for the trouble.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=096541923-06062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=096541923-06062002>Thanks 
for the answer.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=096541923-06062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=096541923-06062002>Vimal 
Nakum</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Tam 
  [mailto:gtam@lanterncom.com]<BR><B>Sent:</B> Thursday, June 06, 2002 6:12 
  PM<BR><B>To:</B> 'Nakum, Vimal'; 'mpls@uu.net'<BR><B>Subject:</B> RE: SONET 
  APS Question<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>This 
  is an MPLS issue and should be not concerned with this forum. 
  </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>To 
  answer your question, </SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=335355123-06062002>first of all, the K1/K2 is capsulated on 
  the STS-1 Line Overhead. So </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>both 
  the working and </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>protection paths will receive K1/K2 in normal 
  condition. Secondary, </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>it 
  is up to the </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>protection </SPAN></FONT><FONT color=#0000ff 
  face=Arial size=2><SPAN class=335355123-06062002>scheme and mode to decide 
  whether to revert back to the working </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>line 
  </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>or not when </SPAN></FONT><FONT color=#0000ff 
  face=Arial size=2><SPAN class=335355123-06062002>the working line 
  </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>becomes healthy again. If it is revertive and working 
  path state</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>changes from fail to ok, </SPAN></FONT><FONT 
  color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>traffic will be 
  switched</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002> back&nbsp;to the working path&nbsp;after a 
  wait-to-restore&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>period.&nbsp; If it is non-revertive, of course it 
  will not.&nbsp; So if the working is healthy, traffic is on 
  </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>the 
  protection path and and the </SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=335355123-06062002>protection path </SPAN></FONT><FONT 
  color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>is 
  </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=335355123-06062002>faulty, traffic</SPAN></FONT><FONT color=#0000ff 
  face=Arial size=2><SPAN class=335355123-06062002> will switch back to the 
  working </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=335355123-06062002>path 
  for sure. </SPAN></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Nakum, Vimal 
    [mailto:vnakum@iPolicyNet.COM]<BR><B>Sent:</B> Thursday, June 06, 2002 6:09 
    PM<BR><B>To:</B> 'mpls@uu.net'<BR><B>Subject:</B> SONET APS 
    Question<BR><BR></DIV></FONT><BR>
    <P><FONT face=Arial size=2>Hi,</FONT> </P>
    <P><FONT face=Arial size=2>In SONET standards, it is mentioned that K1/K2 
    bytes carry APS Protocol bytes on protection line when signal degrade 
    happens on working line. Suppose after some times, working line becomes up. 
    Now, when signal degrade happens on protection line, how link switches back 
    to working line ? Does working line carries K1/K2 bytes, indicating 
    switchover to working line&nbsp; or&nbsp; both ends assume that now transfer 
    will be on working line ?</FONT></P>
    <P><FONT face=Arial size=2>Thanks,</FONT> </P>
    <P><FONT face=Arial size=2>Vimal Nakum</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C20DB7.C7B947E0--


From owner-mpls@UU.NET  Thu Jun  6 21:43:05 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23867
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 21:43:00 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsct06639
	for <mpls-archive@lists.ietf.org>; Thu, 6 Jun 2002 19:50:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsct04439;
	Thu, 6 Jun 2002 19:49:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsct15449
	for mpls-outgoing; Thu, 6 Jun 2002 19:49:14 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmsct15444
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 6 Jun 2002 19:49:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsct09474
	for <mpls@uu.net>; Thu, 6 Jun 2002 19:48:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsct03272
	for <mpls@uu.net>; Thu, 6 Jun 2002 19:48:20 GMT
Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.timetra.com [63.104.212.2])
	id QQmsct03261
	for <mpls@uu.net>; Thu, 6 Jun 2002 19:48:19 GMT
Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 6 Jun 2002 12:47:48 -0700
From: "Vach Kompella" <vkompella@timetra.com>
To: "Mpls-wg" <mpls@UU.NET>
Subject: Hello adjacency creation
Date: Thu, 6 Jun 2002 12:47:48 -0700
Message-ID: <FNEFIPCNJKDDONJGBCNEAEFADBAA.vkompella@timetra.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 06 Jun 2002 19:47:48.0464 (UTC) FILETIME=[09261700:01C20D93]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Suppose there are two adjacent LSRs A and B which try to set up both regular
link-level LDP, as well as targeted LDP.

   -----         -----
   | A |---------| B |
   -----         -----

Only a single LDP session/TCP connection is established, but are two hello
adjacencies set up?  Having only a single one would mean that if the interface
was brought down, the session would terminate.

Also, the existence of a targeted adjacency is typically for VC label exchange
or for tunneled next hop resolution, whereas link adjacency is typically used
for LSPs following the IGP.

Does one exchange VC labels over a session over which link adjacency only has
been set up?  That seems silly.  E.g., A and B exchange VC labels over a
targeted session, but X and B have a (link) adjacency and an LDP session.  You
wouldn't want B and X to exchange labels for martini VCs.

   -----         -----          -----
   | A |---------| X |----------| B |
   -----         -----          -----

Finally, in the upper configuration, if A and B only have a targeted adjacency,
then shouldn't B avoid sending address FECs to A which doesn't really care for
them?

Since I couldn't find this behavior described in the RFCs, I propose a default
behavior for adjacency creation and scoping of FEC signaling so that:
1. parallel hello adjacencies are set up, even though only one session is used
to exchange labels, when both link and targeted adjacencies are requested
2. if only a link adjacency is established between a pair of LSRs, then address
FECs SHOULD be exchanged over the concomitant session, and no other FECs
3. if only a targeted adjacency is established between a pair of LSRs, then
non-address FECs SHOULD be exchanged over the session, and no other FECs
4. if both adjacencies are set up, then all known FECs SHOULD be exchanged

Similarly, when adjacencies are torn down:
1. if no link adjacency exists, then all address FECs should be withdrawn
2. if no targeted adjacency exists, then all non-address FECs should be
withdrawn

Does this make sense?  I have run across some behavior that doesn't quite follow
these rules, so if others are operating on other rules of behavior, could we
have some discussion on how to resolve this?  Thanks.

-Vach



From owner-mpls@UU.NET  Fri Jun  7 00:17:14 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04147
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 00:17:13 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmseb10905
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 04:17:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmseb09722;
	Fri, 7 Jun 2002 04:17:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmseb12452
	for mpls-outgoing; Fri, 7 Jun 2002 04:16:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmseb12447
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Jun 2002 04:16:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmseb27249
	for <mpls@UU.NET>; Fri, 7 Jun 2002 04:15:32 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmseb07598
	for <mpls@UU.NET>; Fri, 7 Jun 2002 04:15:32 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQmseb07558
	for <mpls@UU.NET>; Fri, 7 Jun 2002 04:15:17 GMT
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g574FFe22586
	for <mpls@UU.NET>; Fri, 7 Jun 2002 09:45:16 +0530 (IST)
Received: from ecexch.wipsys.soft.net ([164.164.27.59]) by
          ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GXBIH301.X7V; Fri, 7 Jun 2002 09:45:04 +0530 
Received: from EC1NOR5142 ([192.168.53.62]) by ecexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id G42WKC9X; Fri, 7 Jun 2002 09:49:01 +0530
From: "Sivaram Namakal Balakrishnan" <sivaram.balakrishnan@wipro.com>
To: "'Nakum Vimal'" <vnakum@iPolicyNet.COM>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: SONET APS Question
Date: Fri, 7 Jun 2002 09:48:01 +0530
Organization: Wipro Technologies
Message-ID: <007001c20dda$5015e900$3e35a8c0@ec1nor5142>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-e51733b8-76f8-11d6-ba7c-006067005148"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <C1352E2D7153D411B83000508BD6924779F3F1@CA-Mail01.CA.iPolicyNet.COM>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-e51733b8-76f8-11d6-ba7c-006067005148
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0071_01C20E08.69CE2500"

------=_NextPart_000_0071_01C20E08.69CE2500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There are two things to be noted here.

=20

Traffic in a 1+1 fashion =96 that is a non-revertive protection =
switching.

or Traffic in 1:1 fashion =96 that is revertive protection switching.

=20

In the first case, K1/K2 byte in protection fiber indicates and performs
a traffic switch. Since traffic is not expected to be reverted here, it
stays in the protection fiber. A manual switch is performed to revert
the traffic.

=20

In the second case, a timer mechanism is built into the system. This is
normally called =93Wait to restore=94. In most of the cases this period =
is
user configurable. So when the traffic stabilizes in the working fiber,
the configured period has to be passed (say for example 5 minutes.) and
then the traffic switches back to the working fiber. This is referred to
as automatic reverting of traffic.

=20

So there is nothing like K1/K2 bytes in working fiber.

Sivaram Balakrishnan
WIPRO Technologies
WIPRO ~ NORTEL LAB
OPTera Management Framework & Solutions Verification
* +91-80-8520408 x3315      ESN 877-8523
* email: sivaram.balakrishnan@wipro.com=20
72, Electronic City, Hosur Road, Bangalore 561 229=20

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Nakum,
Vimal
Sent: Friday, June 07, 2002 3:39 AM
To: 'mpls@uu.net'
Subject: SONET APS Question

=20

=20

Hi,=20

In SONET standards, it is mentioned that K1/K2 bytes carry APS Protocol
bytes on protection line when signal degrade happens on working line.
Suppose after some times, working line becomes up. Now, when signal
degrade happens on protection line, how link switches back to working
line ? Does working line carries K1/K2 bytes, indicating switchover to
working line  or  both ends assume that now transfer will be on working
line ?

Thanks,=20

Vimal Nakum=20


------=_NextPart_000_0071_01C20E08.69CE2500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title>SONET APS Question</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:t;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
p.section1, li.section1, div.section1
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are two things to be noted =
here.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Traffic in a 1+1 fashion &#8211; =
that is a
non-revertive protection switching.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>or Traffic in 1:1 fashion &#8211; =
that is
revertive protection switching.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the first case, K1/K2 byte in
protection fiber indicates and performs a traffic switch. Since traffic =
is not
expected to be reverted here, it stays in the protection fiber. A manual =
switch
is performed to revert the traffic.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the second case, a timer =
mechanism is
built into the system. This is normally called &#8220;Wait to =
restore&#8221;.
In most of the cases this period is user configurable. So when the =
traffic stabilizes
in the working fiber, the configured period has to be passed (say for =
example 5
minutes.) and then the traffic switches back to the working fiber. This =
is
referred to as automatic reverting of traffic.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So there is nothing like K1/K2 =
bytes in
working fiber.</span></font></p>

<div>

<p class=3Dsection1><font size=3D1 color=3Dgreen face=3DArial><span =
style=3D'font-size:
9.0pt;font-family:Arial;color:green'>Sivaram =
Balakrishnan</span></font><font
size=3D1 color=3Dgreen face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;
color:green'><br>
</span></font><font size=3D1 color=3Dnavy face=3DArial><span =
style=3D'font-size:8.0pt;
font-family:Arial;color:navy'>WIPRO Technologies<br>
WIPRO ~ NORTEL LAB<br>
OPTera&nbsp;Management Framework &amp; Solutions Verification<br>
</span></font><font size=3D1 color=3Dnavy face=3DWingdings><span =
style=3D'font-size:
8.0pt;font-family:Wingdings;color:navy'>(</span></font><font size=3D1 =
color=3Dnavy><span
style=3D'font-size:8.0pt;color:navy'> </span></font><font size=3D1 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;color:navy'>+91-80-8520408
x3315&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ESN 877-8523</span></font><font =
size=3D1
color=3Dnavy face=3DTahoma><span =
style=3D'font-size:8.0pt;font-family:Tahoma;
color:navy'><br>
</span></font><font size=3D1 color=3Dnavy face=3DWingdings><span =
style=3D'font-size:
8.0pt;font-family:Wingdings;color:navy'>+</span></font><font size=3D1 =
color=3Dnavy><span
style=3D'font-size:8.0pt;color:navy'> </span></font><font size=3D1 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;color:navy'>email: <a
href=3D"mailto:sivaram.balakrishnan@wipro.com">sivaram.balakrishnan@wipro=
.com</a>
<br>
72, </span></font><font size=3D1 color=3Dnavy face=3DArial><span =
style=3D'font-size:
  8.0pt;font-family:Arial;color:navy'>Electronic</span></font><font =
size=3D1
 color=3Dnavy face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;
 color:navy'> </span></font><font size=3D1 color=3Dnavy =
face=3DArial><span
  =
style=3D'font-size:8.0pt;font-family:Arial;color:navy'>City</span></font>=
<font
size=3D1 color=3Dnavy face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;
color:navy'>, </span></font><font size=3D1 color=3Dnavy =
face=3DArial><span
  style=3D'font-size:8.0pt;font-family:Arial;color:navy'>Hosur =
Road</span></font><font
 size=3D1 color=3Dnavy face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;
 color:navy'>, </span></font><font size=3D1 color=3Dnavy =
face=3DArial><span
  =
style=3D'font-size:8.0pt;font-family:Arial;color:navy'>Bangalore</span></=
font><font
size=3D1 color=3Dnavy face=3DArial><span =
style=3D'font-size:8.0pt;font-family:Arial;
color:navy'> 561 229</span></font><font size=3D1 color=3Dnavy =
face=3Dt><span
style=3D'font-size:8.0pt;font-family:t;color:navy'> </span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> owner-mpls@UU.NET
[mailto:owner-mpls@UU.NET] <b><span style=3D'font-weight:bold'>On Behalf =
Of </span></b>Nakum,
Vimal<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, June 07, =
2002 3:39
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'mpls@uu.net'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> SONET APS =
Question</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi,</span></font> </p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>In SONET standards, it is mentioned that K1/K2 =
bytes
carry APS Protocol bytes on protection line when signal degrade happens =
on
working line. Suppose after some times, working line becomes up. Now, =
when
signal degrade happens on protection line, how link switches back to =
working
line ? Does working line carries K1/K2 bytes, indicating switchover to =
working
line&nbsp; or&nbsp; both ends assume that now transfer will be on =
working line
?</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Thanks,</span></font> </p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Vimal Nakum</span></font> </p>

</div>

</body>

</html>

------=_NextPart_000_0071_01C20E08.69CE2500--


------=_NextPartTM-000-e51733b8-76f8-11d6-ba7c-006067005148--



From owner-mpls@UU.NET  Fri Jun  7 10:32:54 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28288
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 10:32:54 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsfq28952
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 14:33:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsfq25775;
	Fri, 7 Jun 2002 14:31:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsfq08650
	for mpls-outgoing; Fri, 7 Jun 2002 14:31:37 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsfq08645
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Jun 2002 14:31:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsfq18160
	for <mpls@UU.NET>; Fri, 7 Jun 2002 14:30:32 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsfq24558
	for <mpls@UU.NET>; Fri, 7 Jun 2002 14:30:32 GMT
Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQmsfq24548
	for <mpls@UU.NET>; Fri, 7 Jun 2002 14:30:32 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g57EUTd27163;
	Fri, 7 Jun 2002 10:30:29 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          FRI, 7 Jun 2002 10:27:10 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <L7HN05N3>; Fri, 7 Jun 2002 10:27:09 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B5391@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Rahul Aggarwal'" <rahul@redback.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Hello adjacency creation
Date: Fri, 7 Jun 2002 10:27:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

  There is no way to configure targeted adjacency only for VC fecs.

I do agree that negotiating a session capability can be useful.

Regards,
Kishore

-----Original Message-----
From: Rahul Aggarwal [mailto:rahul@redback.com]
Sent: Thursday, June 06, 2002 9:16 PM
To: Vach Kompella
Cc: Mpls-wg
Subject: Re: Hello adjacency creation


The announcement of prefix FECs or VC FECs to a particular peer
is really driven by the information that the peer is interested in :

a) For prefix FECs, typically the existance of a LDP link level
hello adjancency with a peer implies that prefix FECs are to be
exchanged with that peer. However for certain reasons one may
explictly configure a targeted adjancency with a peer to exchange
prefix FECs. Eg : When a LDP session is being tunnelled.

b) For VC FECs, if a VC (Pseudo wire) is configured to a 
particular peer all that should matter is whether there is an 
adjacency to that peer. For directly connected LSRs this could well
be a link level adjacency. 

IMO this would be the driving factor of prefix FEC /VC FEC announcements.

Some more comments inline :

On Thu, Jun 06, 2002 at 12:47:48PM -0700, Vach Kompella wrote:
> Suppose there are two adjacent LSRs A and B which try to set up both
regular
> link-level LDP, as well as targeted LDP.
> 
>    -----         -----
>    | A |---------| B |
>    -----         -----
> 
> Only a single LDP session/TCP connection is established, but are two hello
> adjacencies set up?  Having only a single one would mean that if the
interface
> was brought down, the session would terminate.

Two hello adjancencies should be set up as per rfc3036.

> 
> Also, the existence of a targeted adjacency is typically for VC label
exchange
> or for tunneled next hop resolution, whereas link adjacency is typically
used
> for LSPs following the IGP.
> 
> Does one exchange VC labels over a session over which link adjacency only
has
> been set up?  That seems silly.  E.g., A and B exchange VC labels over a
> targeted session, but X and B have a (link) adjacency and an LDP session.
You
> wouldn't want B and X to exchange labels for martini VCs.

For directly connected LSRs if someone wants to do this, I don't see why it 
should be disallowed. For exchanging Martini labels one should only be 
interested in seeing if there is a peering session with the peer in
question.

> 
>    -----         -----          -----
>    | A |---------| X |----------| B |
>    -----         -----          -----
> 
> Finally, in the upper configuration, if A and B only have a targeted
adjacency,
> then shouldn't B avoid sending address FECs to A which doesn't really care
for
> them?

Only if A and B are not explicitly configured to exchange prefix FECs over
the
targeted session.

> 
> Since I couldn't find this behavior described in the RFCs, I propose a
default
> behavior for adjacency creation and scoping of FEC signaling so that:
> 1. parallel hello adjacencies are set up, even though only one session is
used
> to exchange labels, when both link and targeted adjacencies are requested
> 2. if only a link adjacency is established between a pair of LSRs, then
address
> FECs SHOULD be exchanged over the concomitant session, and no other FECs

> 3. if only a targeted adjacency is established between a pair of LSRs,
then
> non-address FECs SHOULD be exchanged over the session, and no other FECs

This doesn't sound right. One may be exchaning prefix FECs over a targeted 
session when a LDP session is being tunnelled for some reason.

> 4. if both adjacencies are set up, then all known FECs SHOULD be exchanged
> 
> Similarly, when adjacencies are torn down:
> 1. if no link adjacency exists, then all address FECs should be withdrawn
> 2. if no targeted adjacency exists, then all non-address FECs should be
> withdrawn
> 
> Does this make sense?  I have run across some behavior that doesn't quite
follow
> these rules, so if others are operating on other rules of behavior, could
we
> have some discussion on how to resolve this?  Thanks.
> 
> -Vach
> 


From owner-mpls@UU.NET  Fri Jun  7 15:49:18 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10625
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 15:49:17 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsgl12753
	for <mpls-archive@lists.ietf.org>; Fri, 7 Jun 2002 19:49:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsgl10353;
	Fri, 7 Jun 2002 19:48:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsgl28080
	for mpls-outgoing; Fri, 7 Jun 2002 19:48:18 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsgl28075
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 7 Jun 2002 19:48:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsgl05259
	for <mpls@UU.NET>; Fri, 7 Jun 2002 19:47:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsgl18269
	for <mpls@UU.NET>; Fri, 7 Jun 2002 19:47:29 GMT
Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail2.lucent.com [192.11.223.163])
	id QQmsgl18260
	for <mpls@UU.NET>; Fri, 7 Jun 2002 19:47:29 GMT
Received: from ihmail.ih.lucent.com (h135-185-56-8.lucent.com [135.185.56.8])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g57JlRg08784;
	Fri, 7 Jun 2002 15:47:27 -0400 (EDT)
Received: from lucent.com (sjtrowbridge-1.dr.lucent.com [135.4.20.23]) by ihmail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA00784; Fri, 7 Jun 2002 14:47:25 -0500 (CDT)
Message-ID: <3D010DCC.A11A19F2@lucent.com>
Date: Fri, 07 Jun 2002 13:47:25 -0600
From: Stephen Trowbridge <sjtrowbridge@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Nakum, Vimal" <vnakum@iPolicyNet.COM>
CC: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: SONET APS Question
References: <C1352E2D7153D411B83000508BD6924779F3F1@CA-Mail01.CA.iPolicyNet.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vimal,
Actually, while K1/K2 MAY be carried on both Working and Protection,
for SONET and (normal ETSI style) SDH, the control of protection
switching occurs according to K1/K2 carried on the Protection section.
If protection is no good, there is no point in trying to switch
from working to protection.

The exception is the (Japanese style) 1+1 bi-directional optimized
flavor that you find in Annex B of ITU-T Rec. G.841. Here, we label
one section as Primary and the other as Secondary, carrying the APS
bytes on the Secondary section (similar starting condition to normal
SONET or SDH). However, after a switch occurs and the fault cause
clears, instead of reverting back to restore service to the primary
section, the sections are renamed so that the newly active section
(previously called Secondary) is now called Primary and vice-versa.
At this point, APS bytes are recieved from the other section. In
this flavor of linear switching, APS bytes are always transmitted
on both sections, but received from whichever section is Secondary
at the moment.

Regards,
Steve Trowbridge

> "Nakum, Vimal" wrote:
> 
> Hi,
> 
> In SONET standards, it is mentioned that K1/K2 bytes carry APS Protocol bytes on protection line when signal degrade happens on working line. Suppose after some times, working line becomes up. Now,
> when signal degrade happens on protection line, how link switches back to working line ? Does working line carries K1/K2 bytes, indicating switchover to working line  or  both ends assume that now
> transfer will be on working line ?
> 
> Thanks,
> 
> Vimal Nakum


From owner-mpls@UU.NET  Mon Jun 10 02:16:23 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23484
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 02:16:23 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmspl27013
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 06:16:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmspl26536;
	Mon, 10 Jun 2002 06:16:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmspl24570
	for mpls-outgoing; Mon, 10 Jun 2002 06:15:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmspl24563
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 06:15:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmspl10978
	for <mpls@UU.NET>; Mon, 10 Jun 2002 06:15:15 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmspl25459
	for <mpls@UU.NET>; Mon, 10 Jun 2002 06:15:15 GMT
Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQmspl25448
	for <mpls@UU.NET>; Mon, 10 Jun 2002 06:15:14 GMT
Received: from utfors.se ([172.20.0.77]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GXH89K00.5OD;
          Mon, 10 Jun 2002 08:20:08 +0200 
Message-ID: <3D044403.6080704@utfors.se>
Date: Mon, 10 Jun 2002 08:15:31 +0200
From: Loa Andersson <loa.andersson@utfors.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mpls wg <mpls@UU.NET>
CC: George Swallow <swallow@cisco.com>, Scott Bradner <sob@harvard.edu>
Subject: time to set the mpls agenda for Yokohama
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

All,

the MPLS meeting in Yokohama is (preliminary) planned for
Thursday morning.

If you would like time on the agenda in Yokohama please send
request to George and me.  Include the name and title of you ID and an
estimate of how much time you would need.

Thanks,

George & Loa


-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se



From owner-mpls@UU.NET  Mon Jun 10 10:59:01 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07263
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 10:59:01 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqt04791
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 14:59:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsqt01269;
	Mon, 10 Jun 2002 14:57:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsqt01165
	for mpls-outgoing; Mon, 10 Jun 2002 14:57:42 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsqt01160
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 14:57:40 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsqt26330
	for <mpls@UU.NET>; Mon, 10 Jun 2002 14:56:49 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqt15930
	for <mpls@UU.NET>; Mon, 10 Jun 2002 14:56:49 GMT
Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQmsqt15922
	for <mpls@UU.NET>; Mon, 10 Jun 2002 14:56:48 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA05203
	for <mpls@UU.NET>; Mon, 10 Jun 2002 10:55:52 -0400 (EDT)
Subject: Can someone answer my question?
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFD6DE97A3.D1BFBD20-ON85256BD4.0051EF4A@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 10 Jun 2002 10:55:52 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 06/10/2002 10:55:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have question for the rsvpte.

In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address ---- the
IP address of the node in which the error was detected.

Here the IP address of the node is the router id or interface IP address?

 For instance the intermediate lsr all the interfaces connected to the
router belong to that node.

Thanks in an advance.

Julia




From owner-mpls@UU.NET  Mon Jun 10 11:13:11 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07770
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 11:13:10 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqu21434
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 15:13:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsqu14203;
	Mon, 10 Jun 2002 15:10:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsqu23304
	for mpls-outgoing; Mon, 10 Jun 2002 15:09:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmsqu23284
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 15:09:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsqu06328
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:07:59 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqu09205
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:07:59 GMT
Received: from excalibur.santera.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: exchange.santera.com [4.22.157.11])
	id QQmsqu09196
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:07:58 GMT
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C21090.98D14D34"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: Need a Structural Change in MPLS-TE-MIB
Date: Mon, 10 Jun 2002 10:07:54 -0500
Message-ID: <CD110021698980419241042CF576B8F201764896@EXCALIBUR.santera.com>
X-MS-Has-Attach: yes
Thread-Topic: Need a Structural Change in MPLS-TE-MIB
Thread-Index: AcIQkJfct4tzXtSTRDe5aT/uvlUDww==
From: "Zhu, Rupert" <rupert.zhu@santera.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C21090.98D14D34
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

The current structure of MPLS-TE-MIB intermix two distinct
object classes, "logical tunnel" and "tunnel instance", in
a big MIB table.  This "combo" design causes some problem.

A cleaner design is to split the 37-column, monolithic
"mplsTunnelTable" into two smaller tables, each
modeling exactly one object class.  This would solve the
issues related to MPLS-TE-MIB and MPLS-FTN-MIB.

The proposal is attached.

Regards,


Rupert Zhu

System Engineering
Santera Systems Inc
972-461-6383

------_=_NextPart_001_01C21090.98D14D34
Content-Type: application/msword;
	name="MPLSTE_MIB_Modify.doc"
Content-Description: MPLSTE_MIB_Modify.doc
Content-Disposition: attachment;
	filename="MPLSTE_MIB_Modify.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANgAAAAAAAAAA
EAAAOAAAAAEAAAD+////AAAAADUAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA8BgAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAKSYAADd8AAA3fAAA8BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAFwWAAAAAAAAXBYAAFwW
AAAAAAAAXBYAAAAAAABcFgAAAAAAAFwWAAAAAAAAXBYAABQAAAAAAAAAAAAAAHAWAAAAAAAANhwA
AAAAAAA2HAAAAAAAADYcAAAAAAAANhwAAAwAAABCHAAAHAAAAHAWAAAAAAAAUx0AAHYBAABqHAAA
AAAAAGocAAAAAAAAahwAAAAAAABqHAAAAAAAAGocAAAAAAAAahwAAAAAAABqHAAAAAAAAGocAAAA
AAAA0hwAAAIAAADUHAAAAAAAANQcAAAAAAAA1BwAAAAAAADUHAAAAAAAANQcAAAAAAAA1BwAACQA
AADJHgAAIAIAAOkgAAB+AAAA+BwAABUAAAAAAAAAAAAAAAAAAAAAAAAAXBYAAAAAAABqHAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABqHAAAAAAAAGocAAAAAAAAahwAAAAAAABqHAAAAAAAAPgcAAAAAAAA
lhwAAAAAAABcFgAAAAAAAFwWAAAAAAAAahwAAAAAAAAAAAAAAAAAAGocAAAAAAAADR0AABYAAACW
HAAAAAAAAJYcAAAAAAAAlhwAAAAAAABqHAAAFgAAAFwWAAAAAAAAahwAAAAAAABcFgAAAAAAAGoc
AAAAAAAA0hwAAAAAAAAAAAAAAAAAAJYcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAahwAAAAAAADSHAAAAAAAAJYcAAA8AAAAlhwAAAAAAAAAAAAA
AAAAANIcAAAAAAAAXBYAAAAAAABcFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0hwAAAAAAABqHAAAAAAAAF4cAAAMAAAAwEUX70QO
wgFwFgAAxgUAADYcAAAAAAAAgBwAABYAAADSHAAAAAAAAAAAAAAAAAAA0hwAAAAAAAAjHQAAMAAA
AFMdAAAAAAAA0hwAAAAAAABnIQAAAAAAAJYcAAAAAAAAZyEAAAAAAADSHAAAAAAAAJYcAAAAAAAA
cBYAAAAAAABwFgAAAAAAAFwWAAAAAAAAXBYAAAAAAABcFgAAAAAAAFwWAAAAAAAAAgDZAAAADUEg
U3RydWN0dXJhbCBDaGFuZ2UgaW4gTVBMUy1URS1NSUINDVJ1cGVydCBaaHUNU2FudGVyYSBTeXN0
ZW1zIEluYy4NDUNvbnRlbnRzIA0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDW8gIEJhY2tn
cm91bmQgDW8gIFRoZSBJc3N1ZSBpbiBNUExTLVRFLU1JQiANbyAgVGhlIElzc3VlIGluIE1QTFMt
RlROLU1JQiANbyAgUmVjb21tZW5kYXRpb24gDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAN
DUFic3RyYWN0IA1UaGlzIHNob3J0IG1lbW8gYW5hbHl6ZXMgaXNzdWVzIGluIE1QTFMtVEUtTUlC
IGFuZCBNUExTLUZUTi1NSUIgZGVzaWduIGFuZCByZWNvbW1lbmRzIGEgc3RydWN0dXJhbCBtb2Rp
ZmljYXRpb24uIA1CYWNrZ3JvdW5kIA1UaGUgY29uY2VwdCBvZiAidHJhZmZpYyB0cnVuayIgYW5k
ICJwYXRoIiAoTFNQKSBhcmUgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGluIGEgbnVtYmVyIG9mIElF
VEYgUkZDIGRvY3VtZW50cy4gIEluIHBhcnRpY3VsYXIsIHRoZSBmb2xsb3dpbmcgZXhjZXJwdCBp
cyBmcm9tIFJTVlAtVEUgc3BlYyBbUkZDMzIwOV0uIA0iVGhlIExTUHMgY3JlYXRlZCB3aXRoIFJT
VlAgY2FuIGJlIHVzZWQgdG8gY2FycnkgdGhlICJUcmFmZmljIFRydW5rcyIgZGVzY3JpYmVkIGlu
IFtSRkMyNzAyXS4gIFRoZSBMU1Agd2hpY2ggY2FycmllcyBhIHRyYWZmaWMgdHJ1bmsgYW5kIGEg
dHJhZmZpYyB0cnVuayBhcmUgZGlzdGluY3QgdGhvdWdoIGNsb3NlbHkgcmVsYXRlZCBjb25jZXB0
cy4iIA0iRm9yIGV4YW1wbGUsIHR3byBMU1BzIGJldHdlZW4gdGhlIHNhbWUgc291cmNlIGFuZCBk
ZXN0aW5hdGlvbiBjb3VsZCBiZSBsb2FkIHNoYXJlZCB0byBjYXJyeSBhIHNpbmdsZSB0cmFmZmlj
IHRydW5rLiIgDSJDb252ZXJzZWx5IHNldmVyYWwgdHJhZmZpYyB0cnVua3MgY291bGQgYmUgY2Fy
cmllZCBpbiB0aGUgc2FtZSBMU1AgaWYsIGZvciBpbnN0YW5jZSwgdGhlIExTUCB3ZXJlIGNhcGFi
bGUgb2YgY2Fycnlpbmcgc2V2ZXJhbCBzZXJ2aWNlIGNsYXNzZXMuICBUaGUgYXBwbGljYWJpbGl0
eSBvZiB0aGVzZSBleHRlbnNpb25zIGlzIGRpc2N1c3NlZCBmdXJ0aGVyIGluIFtSRkMzMjEwXS4i
IA1Db21iaW5pbmcgdGhlIGRpc2N1c3Npb25zIGluIFJGQzI3MDIgKE1QTFMgVEUpLCBSRkMzMjA5
IGFuZCBSRkMzMjEwIChSU1ZQLVRFKSwgd2UgY2FuIHNlZSB0aGF0ICJ0cmFmZmljIHRydW5rIiBh
bmQgInBhdGgiIChMU1ApIGFyZSB0d28gZGlzdGluY3QgY29uY2VwdHMuICBUaGUgZm9ybWVyIGlz
IGFuIGFic3RyYWN0IGxvZ2ljYWwgZW50aXR5IHdoaWxlIHRoZSBsYXR0ZXIgaXMgdGhlIHVuZGVy
bHlpbmcgY29uY3JldGUgZW50aXR5LiAgQSBzaW5nbGUgInRyYWZmaWMgdHJ1bmsiIG1heSBjb3Jy
ZXNwb25kIHRvIGEgZ3JvdXAgb2YgInBhdGhzIiB2aWEgbG9hZCBzaGFyaW5nLCBiYWNrdXAgcHJv
dGVjdGlvbiBvciBvdGhlciBzY2hlbWVzLiANVGhlIGRpc3RpbmN0aW9uIG9mICJ0cmFmZmljIHRy
dW5rIiBmcm9tIHRoZSB1bmRlcmx5aW5nIHBhdGgocykgcmVwcmVzZW50cyBhIGxldmVsIG9mIGlu
ZGlyZWN0aW9uLiANVGhlIElzc3VlIGluIE1QTFMtVEUtTUlCIA1UaGUgZGlzY3Vzc2lvbiBpcyBi
YXNlZCBvbiB0aGUgbW9zdCByZWNlbnQgaW50ZXJuZXQgZHJhZnRzIA0gICAgICBkcmFmdC1pZXRm
LW1wbHMtZnRuLW1pYi0wNC50eHQgICAgICAgTVBMUy1GVE4tTUlCIA0gICAgICBkcmFmdC1pZXRm
LW1wbHMtdGUtbWliLTA4LnR4dCAgICAgICAgTVBMUy1URS1NSUIgDQ1JbiBNUExTLVRFLU1JQiwg
dGhlIGxvZ2ljYWwgZW50aXR5ICJ0cmFmZmljIHRydW5rIiBpcyBtb2RlbGVkIGFzICJsb2dpY2Fs
IHR1bm5lbCIgd2hpbGUgdGhlIHVuZGVybHlpbmcgInBhdGgiIGVudGl0eSBpcyBtb2RlbGVkIGFz
ICJ0dW5uZWwgaW5zdGFuY2UiLiAgVGhpcyBtYWtlcyBnb29kIGRpc3RpbmN0aW9uLiANVW5mb3J0
dW5hdGVseSwgdGhlc2UgdHdvIGRpc3RpbmN0IGVudGl0eSBjbGFzc2VzIGFyZSBpbnRlcnR3aW5l
ZCBpbnRvIGEgc2luZ2xlIE1JQiB0YWJsZSAobXBsc1R1bm5lbFRhYmxlKS4gIFRoaXMgY2F1c2Vz
IGZvbGxvd2luZyBwcm9ibGVtcy4gDUEuCUFtYmlndWl0eSBvZiBQcm9wZXJ0aWVzIA1UaGUgbXBs
c1R1bm5lbFRhYmxlIGhhcyBhcyBtYW55IGFzIDM3IGNvbHVtbnMuICBTb21lIG9mIHRoZW0gcmVw
cmVzZW50IHByb3BlcnRpZXMgb2YgImxvZ2ljYWwgdHVubmVsIiBlbnRpdHkgd2hpbGUgb3RoZXJz
IGFyZSBwcm9wZXJ0aWVzIG9mIHVuZGVybHlpbmcgInR1bm5lbCBpbnN0YW5jZSIgZW50aXR5LiBU
aGVyZSBpcyBubyBjbGVhciBkaXN0aW5jdGlvbiBvZiB0aGVzZSB0d28gY2F0ZWdvcmllcyB3aGVu
IGludGVybWl4aW5nIHRoZW0gaW4gdGhlIHNhbWUgdGFibGUuIA1CLglEdXBsaWNhdGlvbiBvZiBJ
bmZvcm1hdGlvbiANQSAibG9naWNhbCB0dW5uZWwiIGNvcnJlc3BvbmRzIHRvIGEgZ3JvdXAgb2Yg
InR1bm5lbCBpbnN0YW5jZXMiLiBGb3IgYWxsICJ0dW5uZWwgaW5zdGFuY2VzIiBpbiBvbmUgInR1
bm5lbCBpbnN0YW5jZSBncm91cCIsIHRoZWlyICJsb2dpY2FsIHR1bm5lbCIgYXR0cmlidXRlcyAo
aS5lLiwgdGFibGUgZmllbGRzKSBtdXN0IGhhdmUgaWRlbnRpY2FsIHZhbHVlLiAgRm9yIGV4YW1w
bGUsIA0gICAgICAgICBtcGxzVHVubmVsSW5kZXggDSAgICAgICAgIG1wbHNUdW5uZWxJbmdyZXNz
TFNSSWQgDSAgICAgICAgIG1wbHNUdW5uZWxFZ3Jlc3NMU1JJZCANICAgICAgICAgbXBsc1R1bm5l
bElzSWYgDSAgICAgICAgIG1wbHNUdW5uZWxJZkluZGV4IA0gICAgICAgICBtcGxzVHVubmVsUHJp
bWFyeUluc3RhbmNlIA0gICAgICAgICBtcGxzVHVubmVsUm9sZSANDVRoZXJlZm9yZSwgdGhlc2Ug
ZmllbGRzIG11c3QgYmUgZHVwbGljYXRlZCBhY3Jvc3MgYWxsIHJvd3MgYmVsb25naW5nIHRvIHRo
ZSBzYW1lICJ0dW5uZWwgaW5zdGFuY2UgZ3JvdXAiLiAoQSB2aW9sYXRpb24gb2YgcmVsYXRpb25h
bCBkYXRhIG1vZGVsIHByaW5jaXBsZXMuKSBGdXJ0aGVybW9yZSwgaWYgbmV0d29yayBhZG1pbmlz
dHJhdG9yIGFjY2lkZW50YWxseSBwdXQgZGlmZmVyZW50IHZhbHVlcyB0byB0d28gcm93cyBiZWxv
bmdpbmcgdG8gdGhlIHNhbWUgaW5zdGFuY2UgZ3JvdXAsIE1JQiBpbnRlZ3JpdHkgd291bGQgYmUg
Y29tcHJvbWlzZWQuIA1UaGUgSXNzdWUgaW4gTVBMUy1GVE4tTUlCIA1BLglGVE4gTWFwcGluZyBT
aG91bGQgQmUgQmFzZWQgb24gIkxvZ2ljYWwgVHVubmVsIiANSW4gTVBMUy1GVE4tTUlCLCB0aGUg
RkVDIGlzIGN1cnJlbnRseSBtYXBwZWQgdG8gYSAidHVubmVsIGluc3RhbmNlIiBpbnN0ZWFkIG9m
ICJsb2dpY2FsIHR1bm5lbCIsIGVmZmVjdGl2ZWx5IG5haWxpbmcgYW4gRkVDIHRvIGFuIGluZGl2
aWR1YWwgInR1bm5lbCBpbnN0YW5jZSIuICBUaGlzIGRlZmVhdHMgdGhlIHdob2xlIGNvbmNlcHQg
b2YgImxvZ2ljYWwgdHVubmVsIiBvciAidHJhZmZpYyB0cnVuayIuIA0gICAgICAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANICAgICAg
KEVYQ0VSUFQgRlJPTSBDVVJSRU5UIE1QTFMtRlROLU1JQikgDSAgICAgIG1wbHNGVE5BY3Rpb25Q
b2ludGVyIE9CSkVDVC1UWVBFIA0gICAgICAgICBTWU5UQVggICAgICAgICAgICAgUm93UG9pbnRl
ciANICAgICAgICAgREVTQ1JJUFRJT04gDSAgICAgICAgICAgICAiSWYgbXBsc0ZUTkFjdGlvblR5
cGUgaXMgcmVkaXJlY3RMc3AoMiksIHRoZW4gdGhpcyANICAgICAgICAgICAgICBvYmplY3QgaW5k
aWNhdGVzIHRoZSBpbnN0YW5jZSBvZiBtcGxzWENFbnRyeSBmb3IgdGhlIA0gICAgICAgICAgICAg
IExTUCB0byByZWRpcmVjdCBtYXRjaGluZyBwYWNrZXRzIHRvLiBJZiANICAgICAgICAgICAgICBt
cGxzRlROQWN0aW9uVHlwZSBpcyByZWRpcmVjdFR1bm5lbCgzKSwgdGhlbiB0aGlzIA0gICAgICAg
ICAgICAgIG9iamVjdCBpbmRpY2F0ZXMgdGhlIGluc3RhbmNlIG9mIG1wbHNUdW5uZWxFbnRyeSBm
b3IgDSAgICAgICAgICAgICAgdGhlIE1QTFMgdHVubmVsIHRvIHJlZGlyZWN0IG1hdGNoaW5nIHBh
Y2tldHMgdG8uIA0gICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLSANDUFzIG1lbnRpb25lZCBlYXJsaWVyLCBhICJsb2dpY2FsIHR1
bm5lbCIgaXMgYW4gYWJzdHJhY3Rpb24gb2YgYSBncm91cCBvZiB0dW5uZWwgaW5zdGFuY2VzLiAg
VGFraW5nIGFkdmFudGFnZSBvZiB0aGlzIGxldmVsIG9mIGluZGlyZWN0aW9uLCB3ZSBzaG91bGQg
aGF2ZSBGRUMtdG8tTkhMRkUgbWFwcGluZyBlc3RhYmxpc2hlZCBpbiB0aGUgbG9naWNhbCBsYXll
ciAoYmFzZWQgb24gImxvZ2ljYWwgdHVubmVscyIpLiAgTG9hZCBzaGFyaW5nLCBwYXRoIHNlbGVj
dGlvbiBhbmQgZmFpbC1vdmVyIHNjaGVtZXMgc2hvdWxkIGJlIGhpZGRlbiBpbiB0aGUgdW5kZXJs
eWluZyBwYXRoIChMU1ApIGxheWVyIChiYXNlZCBvbiAidHVubmVsIGluc3RhbmNlcyIpLiAgU3Vj
aCBzY2hlbWVzIHNob3VsZCBiZSB0cmFuc3BhcmVudCB0byBGVE4gbWFwcGluZy4gDUdpdmVuIHRo
YXQgY3VycmVudGx5ICJsb2dpY2FsIHR1bm5lbCIgZW50aXR5IGNsYXNzIGFuZCAidHVubmVsIGlu
c3RhbmNlIiBlbnRpdHkgY2xhc3MgYXJlIGludGVydHdpbmVkIGluIHRoZSBzYW1lIE1JQiB0YWJs
ZSwgdGhlcmUgaXMgbm8gd2F5IHRvIG1ha2UgRkVDIG1hcCB0byAibG9naWNhbCB0dW5uZWwiLiAg
KFRoaXMgbWlnaHQgZXhwbGFpbiB3aHkgIkZUTkFjdGlvblBvaW50ZXIiIGlzIG1hZGUgdG8gcG9p
bnQgdG8gYSAidHVubmVsIGluc3RhbmNlIiBpbiBjdXJyZW50IE1JQiBkZWZpbml0aW9uLikgDVJl
Y29tbWVuZGF0aW9uIA1UaGUgaXNzdWVzIGluIE1QTFMtVEUtTUlCIGFuZCBNUExTLUZUTi1NSUIg
YXJlIHJlYWxseSBkdWUgdG8gYSBzdHJ1Y3R1cmFsIHByb2JsZW0gb2YgbXBsc1R1bm5lbFRhYmxl
LiAgV2UgY2FuIHJlc29sdmUgdGhlc2UgaXNzdWVzIGJ5IHNwbGl0aW5nIHRoZSBiaWcsIG1vbm9s
aXRoaWMgIm1wbHNUdW5uZWxUYWJsZSIgaW50byB0d28gc21hbGxlciB0YWJsZXMsIGVhY2ggbW9k
ZWxpbmcgZXhhY3RseSBvbmUgZW50aXR5IGNsYXNzLiANICAgICAgICAgbXBsc0xvZ2ljYWxUdW5u
ZWxUYWJsZSANICAgICAgICAgbXBsc1R1bm5lbEluc3RhbmNlVGFibGUgDQ1UaGVuIG1vZGlmeSBt
cGxzRlROQWN0aW9uUG9pbnRlciBkZWZpbml0aW9uIHRvIG1ha2UgaXQgcG9pbnRpbmcgdG8gYSBy
b3cgaW4gdGhlIGZpcnN0IHRhYmxlLiAgTm90ZSB0aGF0IGEgcm93IGluIHRoZSBmaXJzdCB0YWJs
ZSBtYXkgY29ycmVzcG9uZCB0byBtdWx0aXBsZSByb3dzIGluIHRoZSBzZWNvbmQgdGFibGUuIA0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAAAkBAAARQQA
AOcEAADoBAAA2QoAANoKAAATDwAAFA8AACAUAAAhFAAAOBgAADkYAADwGAAA9Ovk39bf1t/W39bf
1t8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAARQioAT0oAAFFKAABwaAAAAP8JQioAcGgAAAD/DDUIgUIqAHBoAAAA/wAQ
NQiBQioAQ0ogAHBoAAAA/wAVQioAT0oAAFFKAABeSgAAcGgAAAD/AA4ABAAAAQQAACQEAAAlBAAA
MAQAAEUEAABGBAAAUAQAAG0EAAB8BAAAmQQAALcEAADKBAAA5wQAAOgEAADyBAAAZAUAAHAFAAAk
BgAA7QYAAGQHAABACAAArwkAABIKAAAsCgAAaAoAAPoAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA
8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAO0AAAAA
AAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAA
AAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAN4A
AAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAA
AAAAAAAA2QAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAA
AN4AAAAAAAAAAAAAAAAAAAAAAAAELwASZBgBAAAABDAAEmQYAQAAAAQSABJkGAEAAAAEGAASZBgB
AAAABBsAEmTwAAAAAAcRAAMkARJkGAEAAGEkAQAEEQASZBgBAAAAGQAEAADwGAAA/QAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEBaAoAAKEKAADZCgAA2goAAI8L
AAAdDAAAOQwAAEoNAABpDQAARg4AAGAOAACBDgAAoQ4AALoOAADWDgAA+g4AABMPAAAUDwAAUBAA
AGsQAACfEAAAiBEAAMsRAAD2EQAAHhIAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAA
AAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOIAAAAAAAAAAAAA
AADZAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA
AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD1AAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA
4gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEgASZBgBAAAACDcAEYSY/hJkGAEAAGCEmP4ABC8AEmQYAQAAAAg4ABGEmP4SZBgB
AABghJj+AAQwABJkGAEAAAAEGAASZBgBAAAABBsAEmTwAAAAABgeEgAARhIAAFwSAACdEgAA4RIA
ABgTAABZEwAAnRMAAN0TAAAgFAAAIRQAAMsVAADuFgAA/hYAAPUXAAAWGAAAOBgAADkYAADwGAAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOYA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADmAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwABJkGAEAAAAEEgAS
ZBgBAAAABC8AEmQYAQAAAAQYABJkGAEAAAAEGwASZPAAAAAAEicAETABHFABAB+w0C8gsOA9IbCg
BSKwoAUjkKAFJJCgBSWwAAAMkGgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAA9AAoAAQBpAA8AAwAAAAAAAAAA
ADgAAEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRI
CQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBh
AGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAKgBYQKIA8QAqAAwACABFAG0AcABoAGEA
cwBpAHMAAAAKADYIgUNKGABdCIE8AP5P8v8BATwADAARAEUAcQB1AGEAdABpAG8AbgBWAGEAcgBp
AGEAYgBsAGUAcwAAAAoANgiBQ0oYAF0IgWAA/k/x/xIBYAAEAAQAQgBvAGQAeQAAABIAEQAUpMgA
MSQANyQAOCQASCQANABCKgFDShgAT0oDAFFKAwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNI
CQR0SAkEdQgBcgD+T/H/IgFyAAQACABCAG8AbABkAEIAbwBkAHkAAAAWABIAE6TIABSkyAAxJAA3
JAA4JABIJAA6ADUIgUIqAUNKGABPSgMAUUoDAFwIgV5KAwBfSAEEYUoYAG1IAARuSAAEcGgAAAAA
c0gJBHRICQR1CAF4AP4P8f8yAXgABAAIAEIAdQBsAGwAZQB0AGUAZAAAACIAEwANxgUAAdACAA+E
0AIUpMgAMSQANyQAOCQASCQAXoTQAjQAQioBQ0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5I
AARwaAAAAABzSAkEdEgJBHUIAXoA/g/x/0IBegAEAAkAQgB1AGwAbABlAHQAZQBkADIAAAAiABQA
DcYFAAE4BAAPhDgEFKTIADEkADckADgkAEgkAF6EOAQ0AEIqAUNKGABPSgMAUUoDAF5KAwBfSAEE
YUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAF6AP4P8f9SAXoABAAJAEIAdQBsAGwAZQB0AGUA
ZAAzAAAAIgAVAA3GBQABoAUAD4SgBRSkyAAxJAA3JAA4JABIJABehKAFNABCKgFDShgAT0oDAFFK
AwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBagD+D/H/YgFqAAQACABDAGUA
bABsAEIAbwBkAHkAAAAUABYAAyQBMSQANyQAOCQASCQAYSQBNABCKgFDShgAT0oDAFFKAwBeSgMA
X0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBdgD+D/H/cgF2AAQACwBDAGUAbABsAEgA
ZQBhAGQAaQBuAGcAAAAUABcAAyQBMSQANyQAOCQASCQAYSQBOgA1CIFCKgFDShgAT0oDAFFKAwBc
CIFeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBfgD+T/H/ggF+AAQACwBDAG8A
dQByAGkAZQByAEIAbwBkAHkAAAAlABgADcYUAAagBUAL4BCAFiAcwCEAAAAAAAAxJAA3JAA4JABI
JAAAMABCKgFDShgAT0oEAFFKBABfSAEEYUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAF6AP4P
8f+SAXoABAANAEMAbwB1AHIAaQBlAHIAQgBvAGQAeQAxADAAAAAlABkADcYUAAagBUAL4BCAFiAc
wCEAAAAAAAAxJAA3JAA4JABIJAAAKABCKgFPSgQAUUoEAF9IAQRtSAAEbkgABHBoAAAAAHNICQR0
SAkEdQgBggD+D/H/ogGCAAQADQBDAG8AdQByAGkAZQByAEIAbwBkAHkAMQAxAAAAJQAaAA3GFAAG
oAVAC+AQgBYgHMAhAAAAAAAAMSQANyQAOCQASCQAADAAQioBQ0oWAE9KBABRSgQAX0gBBGFKFgBt
SAAEbkgABHBoAAAAAHNICQR0SAkEdQgBhAD+T/H/sgGEAAQADwBDAG8AdQByAGkAZQByAEIAbwBs
AGQAQgBvAGQAeQAAACUAGwANxhQABqAFQAvgEIAWIBzAIQAAAAAAADEkADckADgkAEgkAAAuADUI
gUIqAU9KBABRSgQAXAiBX0gBBG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAF+AP4P8f/CAX4ABAAP
AEMAbwB1AHIAaQBlAHIASQBuAGQAZQBuAHQAZQBkAAAAHgAcAA3GBQAB0AIAD4TQAjEkADckADgk
AEgkAF6E0AIwAEIqAUNKGABPSgQAUUoEAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUI
AYAA/g/x/9IBgAAEABAAQwBvAHUAcgBpAGUAcgBJAG4AZABlAG4AdABlAGQAMgAAAB4AHQANxgUA
ATgEAA+EOAQxJAA3JAA4JABIJABehDgEMABCKgFDShgAT0oEAFFKBABfSAEEYUoYAG1IAARuSAAE
cGgAAAAAc0gJBHRICQR1CAGAAP4P8f/iAYAABAAQAEMAbwB1AHIAaQBlAHIASQBuAGQAZQBuAHQA
ZQBkADMAAAAeAB4ADcYFAAGgBQAPhKAFMSQANyQAOCQASCQAXoSgBTAAQioBQ0oYAE9KBABRSgQA
X0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBdgD+D/H/8gF2AAQACwBGAGkAZwB1AHIA
ZQBUAGkAdABsAGUAAAAUAB8AAyQBMSQANyQAOCQASCQAYSQBOgA1CIFCKgFDShgAT0oDAFFKAwBc
CIFeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBYAAgAAEAAgJgAAQABgBGAG8A
bwB0AGUAcgAAABkAIAANxggAAkgSkCQBAjEkADckADgkAEgkAAAoAEIqAUNKEABPSgMAUUoDAF5K
AwBhShAAbUgABG5IAARwaAAAAAB1CAF0AP4P8f8SAnQABAAIAEYAbwBvAHQAbgBvAHQAZQAAACYA
IQANxgUAAVgCAA6EaAEPhFgCMSQANyQAOCQASCQAXYRoAV6EWAIsAEIqAU9KBQBRSgUAXkoFAF9I
AQRtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBagAfAAEAIgJqAAQABgBIAGUAYQBkAGUAcgAAACMA
IgADJAMNxggAAkgSRCUBAhSkZAAxJAA3JAA4JABIJABhJAMAKABCKgFDShQAT0oDAFFKAwBeSgMA
YUoUAG1IAARuSAAEcGgAAAAAdQgBhgD+D/H/MgKGAAQACABIAGUAYQBkAGkAbgBnADEAAAApACMA
BiQBDcYFAAGsAgAPhBwCE6TwABSkLAExJAA3JAA4JABIJABehBwCADoANQiBQioBQ0oYAE9KAwBR
SgMAXAiBXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUIAXoA/g/x/0ICegAEAAgA
SABlAGEAZABpAG4AZwAyAAAAHQAkAAYkAQ3GBQABqAMAFKTIADEkADckADgkAEgkAAA6ADUIgUIq
AUNKGABPSgMAUUoDAFwIgV5KAwBfSAEEYUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAGKAP4P
8f9SAooABAAIAEgAZQBhAGQAaQBuAGcAMwAAAC0AJQAGJAENxgUAAYAEAA6E8AAPhFwIFKTIADEk
ADckADgkAEgkAF2E8ABehFwIADoANQiBQioBQ0oYAE9KAwBRSgMAXAiBXkoDAF9IAQRhShgAbUgA
BG5IAARwaAAAAABzSAkEdEgJBHUIAX4A/g/x/2ICfgAEAAgASABlAGEAZABpAG4AZwA0AAAAIQAm
AAYkAQ3GBQABWAUAE6R4ABSkyAAxJAA3JAA4JABIJAAAOgA1CIFCKgFDShgAT0oDAFFKAwBcCIFe
SgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBhgD+D/H/cgKGAAQACABIAGUAYQBk
AGkAbgBnADUAAAApACcABiQBDcYFAAHIBAAPhMgEE6R4ABSkyAAxJAA3JAA4JABIJABehMgEADoA
NQiBQioBQ0oYAE9KAwBRSgMAXAiBXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUI
AYYA/g/x/4IChgAEAAgASABlAGEAZABpAG4AZwA2AAAAKQAoAAYkAQ3GBQABoAUAD4SgBROkeAAU
pMgAMSQANyQAOCQASCQAXoSgBQA6ADUIgUIqAUNKGABPSgMAUUoDAFwIgV5KAwBfSAEEYUoYAG1I
AARuSAAEcGgAAAAAc0gJBHRICQR1CAGAAP4P8f+SAoAABAAIAEgAZQBhAGQAaQBuAGcANwAAACkA
KQAGJAENxgUAAcAGAA+ECAcTpHgAFKTIADEkADckADgkAEgkAF6ECAcANABCKgFDShgAT0oDAFFK
AwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBegD+D/H/ogJ6AAQADABIAGUA
YQBkAGkAbgBnAFIAdQBuAEkAbgAAABUAKgAGJAETpHgAMSQANyQAOCQASCQAADoANQiBQioBQ0oY
AE9KBQBRSgUAXAiBXkoFAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUIAXYA/g/x/7IC
dgAEAA0ASABlAGwAdgBlAHQAaQBjAGEAQgBvAGQAeQAAABYAKwANxgUAAaAFADEkADckADgkAEgk
ADQAQioBQ0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUIAYYA
/g/x/8IChgAEABEASABlAGwAdgBlAHQAaQBjAGEASQBuAGQAZQBuAHQAZQBkAAAAHgAsAA3GBQAB
0AIAD4TQAjEkADckADgkAEgkAF6E0AI0AEIqAUNKGABPSgMAUUoDAF5KAwBfSAEEYUoYAG1IAARu
SAAEcGgAAAAAc0gJBHRICQR1CAGIAP4P8f/SAogABAASAEgAZQBsAHYAZQB0AGkAYwBhAEkAbgBk
AGUAbgB0AGUAZAAyAAAAHgAtAA3GBQABOAQAD4Q4BDEkADckADgkAEgkAF6EOAQ0AEIqAUNKGABP
SgMAUUoDAF5KAwBfSAEEYUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAGIAP4P8f/iAogABAAS
AEgAZQBsAHYAZQB0AGkAYwBhAEkAbgBkAGUAbgB0AGUAZAAzAAAAHgAuAA3GBQABoAUAD4SgBTEk
ADckADgkAEgkAF6EoAU0AEIqAUNKGABPSgMAUUoDAF5KAwBfSAEEYUoYAG1IAARuSAAEcGgAAAAA
c0gJBHRICQR1CAF4AP5P8f/yAngABAAIAEkAbgBkAGUAbgB0AGUAZAAAACIALwANxgUAAVwNAA+E
0AIUpMgAMSQANyQAOCQASCQAXoTQAjQAQioBQ0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5I
AARwaAAAAABzSAkEdEgJBHUIAXoA/k/x/wIDegAEAAkASQBuAGQAZQBuAHQAZQBkADAAAAAiADAA
DcYFAAFoAQAPhGgBFKTIADEkADckADgkAEgkAF6EaAE0AEIqAUNKGABPSgMAUUoDAF5KAwBfSAEE
YUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAF6AP4P8f8SA3oABAAJAEkAbgBkAGUAbgB0AGUA
ZAAyAAAAIgAxAA3GBQABXA0AD4Q4BBSkyAAxJAA3JAA4JABIJABehDgENABCKgFDShgAT0oDAFFK
AwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBegD+D/H/IgN6AAQACQBJAG4A
ZABlAG4AdABlAGQAMwAAACIAMgANxgUAAaAFAA+EoAUUpMgAMSQANyQAOCQASCQAXoSgBTQAQioB
Q0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUIAXgA/g/x/zID
eAAEAAgATgB1AG0AYgBlAHIAZQBkAAAAIgAzAA3GBQAB0AIAD4TQAhSkyAAxJAA3JAA4JABIJABe
hNACNABCKgFDShgAT0oDAFFKAwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgB
egD+D/H/QgN6AAQACQBOAHUAbQBiAGUAcgBlAGQAMQAAACIANAANxgUAAdACAA+E0AIUpMgAMSQA
NyQAOCQASCQAXoTQAjQAQioBQ0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABz
SAkEdEgJBHUIAXoA/g/x/1IDegAEAAkATgB1AG0AYgBlAHIAZQBkADIAAAAiADUADcYFAAE4BAAP
hDgEFKTIADEkADckADgkAEgkAF6EOAQ0AEIqAUNKGABPSgMAUUoDAF5KAwBfSAEEYUoYAG1IAARu
SAAEcGgAAAAAc0gJBHRICQR1CAF+AP4P8f9iA34ABAALAE4AdQBtAGIAZQByAGUAZAAyAC0AMQAA
ACIANgANxgUAATgEAA+EOAQUpMgAMSQANyQAOCQASCQAXoQ4BDQAQioBQ0oYAE9KAwBRSgMAXkoD
AF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUIAXoA/k/x/3IDegAEAAkATgB1AG0AYgBl
AHIAZQBkAEEAAAAiADcADcYFAAHQAgAPhNACFKTIADEkADckADgkAEgkAF6E0AI0AEIqAUNKGABP
SgMAUUoDAF5KAwBfSAEEYUoYAG1IAARuSAAEcGgAAAAAc0gJBHRICQR1CAF+AP5P8f+CA34ABAAL
AE4AdQBtAGIAZQByAGUAZABBAC0AMQAAACIAOAANxgUAAdACAA+E0AIUpMgAMSQANyQAOCQASCQA
XoTQAjQAQioBQ0oYAE9KAwBRSgMAXkoDAF9IAQRhShgAbUgABG5IAARwaAAAAABzSAkEdEgJBHUI
AWYA/g/x/5IDZgAEAAcAcABnAGMAbwB1AG4AdAAAABIAOQAUpMgAMSQANyQAOCQASCQANABCKgFD
ShgAT0oDAFFKAwBeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNICQR0SAkEdQgBfgD+D/H/ogN+
AAQADQBUAGEAYgBsAGUARgBvAG8AdABuAG8AdABlAAAAJgA6AA3GBQABWAIADoRoAQ+EWAIxJAA3
JAA4JABIJABdhGgBXoRYAiwAQioBT0oFAFFKBQBeSgUAX0gBBG1IAARuSAAEcGgAAAAAc0gJBHRI
CQR1CAF0AP4P8f+yA3QABAAKAFQAYQBiAGwAZQBUAGkAdABsAGUAAAAUADsAAyQBMSQANyQAOCQA
SCQAYSQBOgA1CIFCKgFDShgAT0oDAFFKAwBcCIFeSgMAX0gBBGFKGABtSAAEbkgABHBoAAAAAHNI
CQR0SAkEdQgBagA+AAEAwgNqAAQABQBUAGkAdABsAGUAAAAfADwAAyQBBiQBE6R8ARSkyAAxJAA3
JAA4JABIJABhJAEALgA1CIFCKgFDSiwAT0oDAFFKAwBcCIFeSgMAYUosAG1IAARuSAAEcGgAAAAA
dQgBAAAAAPAUAAAFAAAmAAAAAP////8AAAAAAQAAACQAAAAlAAAAMAAAAEUAAABGAAAAUAAAAG0A
AAB8AAAAmQAAALcAAADKAAAA5wAAAOgAAADyAAAAZAEAAHABAAAkAgAA7QIAAGQDAABABAAArwUA
ABIGAAAsBgAAaAYAAKEGAADZBgAA2gYAAI8HAAAdCAAAOQgAAEoJAABpCQAARgoAAGAKAACBCgAA
oQoAALoKAADWCgAA+goAABMLAAAUCwAAUAwAAGsMAACfDAAAiA0AAMsNAAD2DQAAHg4AAEYOAABc
DgAAnQ4AAOEOAAAYDwAAWQ8AAJ0PAADdDwAAIBAAACEQAADLEQAA7hIAAP4SAAD1EwAAFhQAADgU
AAA5FAAA8hQAAJgAAAARMAAAAAAAAACAAAAAgJgAAAARMAAAAAAAAACAAAAAgJgAAAARMAAAAAAA
AACAAAAAgJgAAAARMAAAAAAAAACAAAAAgJgAAAARMAAAAAAAAACAAAAAgJgAAAARMAAAAAAAAACA
AAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAA
gJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgA
AAAbMAAAAAAAAACAAAAAgJgAAAAYMAAAAAAAAACAAAAAgJgAAAASMAAAAAAAAACAAAAAgJgAAAAw
MAAAAAAAAACAAAAAgJgAAAASMAAAAAAAAACAAAAAgJgAAAAwMAAAAAAAAACAAAAAgJgAAAAvMAAA
AAAAAACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAAwMAAAAAAA
AACAAAAAgJgAAAAwMAAAAAAAAACAAAAAgJgAAAASMAAAAAAAAACAAAAAgJgAAAAwMAAAAAAAAACA
AAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAYMAAAAAAAAACAAAAA
gJgAAAAwMAAAAAAAAACAAAAAgJgAAAAwMAAAAAAAAACAAAAAgJgAAAA4MAAAAAAAAACAAAAAgJgA
AAAvMAAAAAAAAACAAAAAgJgAAAA3MAAAAAAAAACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAAb
MAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAA
AAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAA
AACAAAAAgJgAAAAYMAAAAAAAAACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAASMAAAAAAAAACA
AAAAgJgAAAA4MAAAAAAAAACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAA
gJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgA
AAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAb
MAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAA
AAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAYMAAAAAAAAACAAAAAgJoAAAAvMAAAAAAA
AACAAAAAgJgAAAAvMAAAAAAAAACAAAAAgJgAAAASMAAAAAAAAACAAAAAgJgAAAAwMAAAAAAAAACA
AAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAbMAAAAAAAAACAAAAAgJgAAAAYMAAAAAAAAACAAAAA
gJgAAAAwMAAAAAAAAACAAAAAgAAEAADwGAAADgAAAAAEAABoCgAAHhIAAPAYAAAPAAAAEQAAABIA
AAAABAAA8BgAABAAAAAAAAAAcREAAHERAADyFAAABwAEAAcAAAAAABARAACXEQAA8hQAAAcABAAH
AP//AgAAAAQAcgB6AGgAdQAVAFUAOgBcAEQAXABTAEUAXABOAE0AXABNAFAATABTAFQARQAuAGQA
bwBjAP9AAYABAHERAABxEQAA5B3GAgEAAQBxEQAAAAAAAGsRAAAAAAAAAhAAAAAAAAAA8BQAAFAA
AAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAAC
AP//AAAAAP//AAACAP//AAAAAAYAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8B
AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA
AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAA
AIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOyaQAQAAAgsGBAICAgICBId6ACAAAACACAAA
AAAAAAD/AQAAAAAAAEgAZQBsAHYAZQB0AGkAYwBhAAAATzGQAQAIAAAAAAAAAAAAAAMAAAAAAAAA
AAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAAz
EpABAAACAgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzAAAAIgAGAAEA
iBgA8NACAABoAQAAAAB0K2ZmATtmpgAAAAADAAkAAAAHAwAAQxEAAAEACAAAAAQAAAAkAAAAAAAA
AAAAAAABAAEAAAABAAAAAAAAAMECAPAQAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAd4
AHgAgwASAAAAAAAAAAAAAAAAAAAAMhUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADKDEQDwEADfAwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAiAEEAIABTAHQAcgB1AGMAdAB1AHIA
YQBsACAAQwBoAGEAbgBnAGUAIABpAG4AIABNAFAATABTAC0AVABFAC0ATQBJAEIAAAAAAAAABABy
AHoAaAB1AAQAcgB6AGgAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuR
CAArJ7PZMAAAAIgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAADEAAAABAAAANAAAAAFAAAA4AAA
AAYAAADsAAAABwAAAPgAAAAIAAAADAEAAAkAAAAcAQAAEgAAACgBAAAKAAAARAEAAAwAAABQAQAA
DQAAAFwBAAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIAAACoAwAAHgAAACMAAABB
IFN0cnVjdHVyYWwgQ2hhbmdlIGluIE1QTFMtVEUtTUlCAHMeAAAAAQAAAAAgU3QeAAAABQAAAHJ6
aHUAdWN0HgAAAAEAAAAAemh1HgAAAAEAAAAAemh1HgAAAAsAAABOb3JtYWwuZG90AGweAAAABQAA
AHJ6aHUAbC5kHgAAAAIAAAAzAGh1HgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAIEAAAAAAdt1B
AQAAAEAAAAAASOUSwgzCAUAAAAAAbg3mRA7CAQMAAAABAAAAAwAAAAcDAAADAAAAQxEAAAMAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA
AAAgAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAkAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAA
AAsAAACwAAAAEAAAALgAAAATAAAAwAAAABYAAADIAAAADQAAANAAAAAMAAAA/wAAAAIAAACoAwAA
HgAAABYAAABTYW50ZXJhIFN5c3RlbXMsIEluYy4AYQADAAAAJAAAAAMAAAAIAAAAAwAAADIVAAAD
AAAAoAoJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAjAAAAQSBTdHJ1
Y3R1cmFsIENoYW5nZSBpbiBNUExTLVRFLU1JQgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4A
AAAPAAAAEAAAABEAAAASAAAAEwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAA
AB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAA/v///yYAAAAnAAAAKAAAACkAAAAqAAAA
KwAAACwAAAD+////LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAAP7////9////NwAAAP7////+
/////v//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAUxrv
RA7CATkAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAFAAAAGchAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKSYAAAAAAAAFAFMAdQBtAG0AYQBy
AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIA
AAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAAEAAAAAAA
AAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA
AAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAALQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAFMa70QOwgEAUxrvRA7CAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////8B
AP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoA
AABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

------_=_NextPart_001_01C21090.98D14D34--


From owner-mpls@UU.NET  Mon Jun 10 11:32:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08836
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 11:32:23 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqw05062
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 15:32:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsqw01496;
	Mon, 10 Jun 2002 15:30:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsqw25824
	for mpls-outgoing; Mon, 10 Jun 2002 15:30:36 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmsqw25819
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 15:30:27 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsqw10604
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:30:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqw00540
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:30:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmsqw00518
	for <mpls@uu.net>; Mon, 10 Jun 2002 15:30:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18758 for <mpls@uu.net>; Mon, 10 Jun 2002 11:30:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01012 for mpls@uu.net; Mon, 10 Jun 2002 11:30:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsqv25737
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 15:28:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsqv07208
	for <mpls@UU.NET>; Mon, 10 Jun 2002 15:28:27 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsqv00403
	for <mpls@UU.NET>; Mon, 10 Jun 2002 15:28:27 GMT
Received: from xover.netplane.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQmsqv00395
	for <mpls@UU.NET>; Mon, 10 Jun 2002 15:28:26 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <KG6F9TG8>; Mon, 10 Jun 2002 11:23:56 -0400
Message-ID: <076236BAE727D611943F00508BA0F9590B8844@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'Hong Liao'" <hliao@telcordia.com>, mpls@UU.NET
Subject: RE: Can someone answer my question?
Date: Mon, 10 Jun 2002 11:23:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

If you were doing OOB signalling in RSVP-TE, wouldn't this have to be the
router ID?

In draft-ietf-mpls-generalized-rsvp-te-07.txt, 8.2.1. IF_ID ERROR_SPEC
Objects:

      See [RFC2205] for a description of address, flags, error code and
      error value fields.  See [GMPLS-SIG] for a description of
      parameters and encoding of TLVs.n

In draft-ietf-mpls-generalized-signaling-08.txt, there is no mention of the
ERROR_SPEC at all.

It seems like it should be the interface IP address from the IF_ID
ERROR_SPEC nomenclature. Would OOB signalling be handled differently since
it works on router id?

Bill

-----Original Message-----
From: Hong Liao [mailto:hliao@telcordia.com]
Sent: Monday, June 10, 2002 10:56 AM
To: mpls@UU.NET
Subject: Can someone answer my question?


Hi,

I have question for the rsvpte.

In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address ---- the
IP address of the node in which the error was detected.

Here the IP address of the node is the router id or interface IP address?

 For instance the intermediate lsr all the interfaces connected to the
router belong to that node.

Thanks in an advance.

Julia



From owner-mpls@UU.NET  Mon Jun 10 12:33:59 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12026
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 12:33:59 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsra04185
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 16:34:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsra01168;
	Mon, 10 Jun 2002 16:33:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsra26769
	for mpls-outgoing; Mon, 10 Jun 2002 16:32:45 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsra26762
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 16:32:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsra19750
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsra00687
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from smtp1.opnet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.opnet.com [141.156.71.6])
	id QQmsra00678
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id <T5b666b688eac10010f39c@smtp1.opnet.com>;
 Mon, 10 Jun 2002 12:32:19 -0400
Message-Id: <5.1.0.14.2.20020610122952.0933c650@mail.opnet.com>
X-Sender: svenkatachalam@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Jun 2002 12:32:18 -0400
To: "Hong Liao" <hliao@telcordia.com>, mpls@UU.NET
From: "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
Subject: Re: Can someone answer my question?
In-Reply-To: <OFD6DE97A3.D1BFBD20-ON85256BD4.0051EF4A@cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 10:55 AM 6/10/2002 -0400, Hong Liao wrote:
>Hi,
>
>I have question for the rsvpte.
>
>In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address ---- the
>IP address of the node in which the error was detected.
>
>Here the IP address of the node is the router id or interface IP address?

It could be either the IP address of the interface or the loopback address
("router address") of the router, depending on the implementation.
You can't make the assumption that it is the interface address or that it
is the "router address".

Regards,
Senthil.

>  For instance the intermediate lsr all the interfaces connected to the
>router belong to that node.
>
>Thanks in an advance.
>
>Julia



From owner-mpls@UU.NET  Mon Jun 10 13:01:16 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13181
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 13:01:16 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrc02502
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 17:01:46 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrc29882;
	Mon, 10 Jun 2002 17:00:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrc01121
	for mpls-outgoing; Mon, 10 Jun 2002 17:00:16 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmsrc29991
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:00:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsrb26199
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:59:33 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrb21172
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:59:33 GMT
Received: from excalibur.santera.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: exchange.santera.com [4.22.157.11])
	id QQmsrb21152
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:59:33 GMT
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: Text Version: Need a Structural Change in MPLS-TE-MIB
Date: Mon, 10 Jun 2002 11:59:27 -0500
Message-ID: <CD110021698980419241042CF576B8F20176496C@EXCALIBUR.santera.com>
Thread-Topic: Text Version: Need a Structural Change in MPLS-TE-MIB
Thread-Index: AcIQoC2UbrEUgZXVS4mgYt6trXLTzQ==
From: "Zhu, Rupert" <rupert.zhu@santera.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA13181

OK, here is the plain text version of the proposal.
---------------------------------------------------


            A Structural Change in MPLS-TE-MIB


Contents
---------------------------
o  Background
o  The Issue in MPLS-TE-MIB
o  The Issue in MPLS-FTN-MIB
o  Recommendation
---------------------------


-- Abstract

   This short memo analyzes issues in MPLS-TE-MIB and MPLS-FTN-MIB design
   and recommends a structural modification.

-- Background

   The concept of "traffic trunk" and "path" (LSP) are discussed
   extensively in a number of IETF RFC documents.  In particular,
   the following excerpt is from RSVP-TE spec [RFC3209].

      "The LSPs created with RSVP can be used to carry the "Traffic
      Trunks" described in [RFC2702].  The LSP which carries a
      traffic trunk and a traffic trunk are distinct though closely
      related concepts."

      "For example, two LSPs between the same source and destination
      could be load shared to carry a single traffic trunk."

      "Conversely several traffic trunks could be carried in the same
      LSP if, for instance, the LSP were capable of carrying several
      service classes.  The applicability of these extensions is
      discussed further in [RFC3210]."

   Combining the discussions in RFC2702 (MPLS TE), RFC3209 and RFC3210
   (RSVP-TE), we can see that "traffic trunk" and "path" (LSP) are
   two distinct concepts.  The former is an abstract logical entity
   while the latter is the underlying concrete entity.  A single
   "traffic trunk" may correspond to a group of "paths" via
   load sharing, backup protection or other schemes.

   The distinction of "traffic trunk" from the underlying
   path(s) represents a level of indirection.


-- The Issue in MPLS-TE-MIB

   The discussion is based on the most recent internet drafts

      draft-ietf-mpls-ftn-mib-04.txt       MPLS-FTN-MIB
      draft-ietf-mpls-te-mib-08.txt        MPLS-TE-MIB

   In MPLS-TE-MIB, the logical entity "traffic trunk" is modeled
   as "logical tunnel" while the underlying "path" entity is modeled
   as "tunnel instance".  This makes good distinction.

   Unfortunately, these two distinct entity classes are intertwined
   into a single MIB table (mplsTunnelTable).  This causes following
   problems.

   -- Ambiguity of Properties

      The mplsTunnelTable has as many as 37 columns.  Some of them
      represent properties of "logical tunnel" entity while others
      are properties of underlying "tunnel instance" entity.
      There is no clear distinction of these two categories
      when intermixing them in the same table.

   -- Duplication of Information

      A "logical tunnel" corresponds to a group of "tunnel instances".
      For all "tunnel instances" in one "tunnel instance group",
      their "logical tunnel" attributes (i.e., table fields) must have
      identical value.  For example,

         mplsTunnelIndex
         mplsTunnelIngressLSRId
         mplsTunnelEgressLSRId
         mplsTunnelIsIf
         mplsTunnelIfIndex
         mplsTunnelPrimaryInstance
         mplsTunnelRole

      Therefore, these fields must be duplicated across all rows
      belonging to the same "tunnel instance group".
      (A violation of relational data model principles.)
      Furthermore, if network administrator accidentally put different
      values to two rows belonging to the same instance group,
      MIB integrity would be compromised.


-- The Issue in MPLS-FTN-MIB

   -- FTN Mapping Should Be Based on "Logical Tunnel"

      In MPLS-FTN-MIB, the FEC is currently mapped to a "tunnel instance"
      instead of "logical tunnel", effectively nailing an FEC to an
      individual "tunnel instance".  This defeats the whole concept
      of "logical tunnel" or "traffic trunk".

      -----------------------------------------------------------
      (EXCERPT FROM CURRENT MPLS-FTN-MIB)
      mplsFTNActionPointer OBJECT-TYPE
         SYNTAX             RowPointer
         DESCRIPTION
             "If mplsFTNActionType is redirectLsp(2), then this
              object indicates the instance of mplsXCEntry for the
              LSP to redirect matching packets to. If
              mplsFTNActionType is redirectTunnel(3), then this
              object indicates the instance of mplsTunnelEntry for
              the MPLS tunnel to redirect matching packets to.
      -----------------------------------------------------------

      As mentioned earlier, a "logical tunnel" is an abstraction of a
      group of tunnel instances.  Taking advantage of this level of
      indirection, we should have FEC-to-NHLFE mapping established in
      the logical layer (based on "logical tunnels").  Load sharing,
      path selection and fail-over schemes should be hidden in the
      underlying path layer (based on "tunnel instances").
      Such schemes should be transparent to FTN mapping.

      Given that currently "logical tunnel" entity class and "tunnel
      instance" entity class are intertwined in the same MIB table,
      there is no way to make FEC map to "logical tunnel".  (This
      might explain why "FTNActionPointer" is made to point to
      a "tunnel instance" in current MIB definition.)


-- Recommendation

   The issues in MPLS-TE-MIB and MPLS-FTN-MIB are really due to a
   structural problem of mplsTunnelTable.  We can resolve these issues
   by spliting the big, monolithic "mplsTunnelTable" into two
   smaller tables, each modeling exactly one entity class.

         mplsLogicalTunnelTable
         mplsTunnelInstanceTable

   Then modify mplsFTNActionPointer definition to make it pointing
   to a row in the first table.  Note that a row in the first table
   may correspond to multiple rows in the second table.



Rupert Zhu

System Engineering
Santera Systems Inc.
972-461-6383 (TX, USA)


From owner-mpls@UU.NET  Mon Jun 10 13:23:29 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14693
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 13:23:29 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd04406
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 17:23:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrd01637;
	Mon, 10 Jun 2002 17:22:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrd22947
	for mpls-outgoing; Mon, 10 Jun 2002 17:22:26 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsrd22942
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:22:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsrd13377
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd19405
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmsrd19398
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10694
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:21:17 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18589
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:21:17 -0400 (EDT)
Message-ID: <3D04E037.7F4737B@marconi.com>
Date: Mon, 10 Jun 2002 13:21:59 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Basic LDP Question
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com> <20020603100111.G3433@eosborne-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Osborne wrote:
> 
> LDP lets you easily integrate IP and ATM; call it cell mode, call it
> LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> marketing-speak and which are standardized).  It's not immediately
> clear to me how you could do that with IP while using the existing
> ATM switch hardware and with only a control-plane upgrade.

It can also be done with LANE or CLIP, but these protocols have much
more overhead and can't directly connect with non-ATM switches, since
they don't use an IP-based control plane.

-- David


From owner-mpls@UU.NET  Mon Jun 10 13:27:22 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14919
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 13:27:17 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd10126
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 17:27:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrd07512;
	Mon, 10 Jun 2002 17:26:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrd23263
	for mpls-outgoing; Mon, 10 Jun 2002 17:26:04 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsrd23251
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:26:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsrd21165
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:50 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd06192
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:48 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmsrd06077
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:44 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11009
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:24:42 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19431
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:24:43 -0400 (EDT)
Message-ID: <3D04E105.15A3D20@marconi.com>
Date: Mon, 10 Jun 2002 13:25:25 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Basic LDP Question
References: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca> <20020603142031.Q3433@eosborne-u10.cisco.com> <Pine.GSO.4.44.0206031448400.28616-100000@asimha-u10.cisco.com> <20020603173524.W3433@eosborne-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Osborne wrote:
>>
>> Actually VC merge is not a must if the LSR request seperate
>> labels - one per request it gets from the upstream neighbor.
> 
> Right, but then Sharam's got a point; if you're not merging, LDP
> and RSVP look a lot alike.

With the exception that LDP can create its LSPs based on the local
routing table, while RSVP can only create them in response to explicit
requests from ingress nodes.

There is little effective semantic difference between CR-LDP and RSVP,
however.

-- David


From owner-mpls@UU.NET  Mon Jun 10 13:38:27 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15562
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 13:38:27 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsre22675
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 17:38:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsre20072;
	Mon, 10 Jun 2002 17:37:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsre24169
	for mpls-outgoing; Mon, 10 Jun 2002 17:37:24 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmsre24164
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:37:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsre09522
	for <mpls@uu.net>; Mon, 10 Jun 2002 17:37:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsre19574
	for <mpls@uu.net>; Mon, 10 Jun 2002 17:37:13 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmsre19568
	for <mpls@uu.net>; Mon, 10 Jun 2002 17:37:13 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12568
	for <mpls@uu.net>; Mon, 10 Jun 2002 13:37:10 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22829
	for <mpls@uu.net>; Mon, 10 Jun 2002 13:37:11 -0400 (EDT)
Message-ID: <3D04E3F1.18A4A14D@marconi.com>
Date: Mon, 10 Jun 2002 13:37:53 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: rsvpte ip address of the node  ----routerid, or interface address?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address
> ---- the IP address of the node in which the error was detected.
> 
> Here the IP address of the node is the router id or interface IP
> address?
> 
> For instance the intermediate lsr all the interfaces connected to
> the router belong to that node.

Use whichever address you like.  The address is describing the node, not
a link, so any valid, routable address on that node (even an unrelated
interface address) is technically valid.

-- David


From owner-mpls@UU.NET  Mon Jun 10 18:37:44 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28370
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 18:37:43 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry29717
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 22:38:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsry27588;
	Mon, 10 Jun 2002 22:37:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsry10367
	for mpls-outgoing; Mon, 10 Jun 2002 22:36:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsry10357
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 22:36:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsry00281
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry27017
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from evl.uic.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: evl.evl.uic.edu [131.193.48.80])
	id QQmsry27002
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:32 GMT
Received: from ericpc (evl-79dhcp210.evl.uic.edu [131.193.79.210])
	by evl.uic.edu (8.9.3/8.9.3) with SMTP id RAA24232
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:36:23 -0500 (CDT)
Message-ID: <003801c210e0$0fd17860$d24fc183@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Microflow level QoS implemented by GMPLS
Date: Mon, 10 Jun 2002 17:36:40 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Integrated Service is used to implement end-to-end microflow level in
IP-based network.  But if we can create a host-to-host lightpath using
GMPLS, is Integrated Service still necessary to ensure end-to-end Quality of
Service? Any comments are more than welcome!

Eric He




From owner-mpls@UU.NET  Mon Jun 10 18:58:28 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28751
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 18:58:28 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrz17737
	for <mpls-archive@lists.ietf.org>; Mon, 10 Jun 2002 22:58:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrz14506;
	Mon, 10 Jun 2002 22:57:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrz12216
	for mpls-outgoing; Mon, 10 Jun 2002 22:56:49 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsrz12211
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 22:56:46 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsrz19856
	for <mpls@uu.net>; Mon, 10 Jun 2002 22:56:04 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrz23795
	for <mpls@uu.net>; Mon, 10 Jun 2002 22:56:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmsrz23786
	for <mpls@uu.net>; Mon, 10 Jun 2002 22:56:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA19209 for <mpls@uu.net>; Mon, 10 Jun 2002 18:56:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA16297 for mpls@uu.net; Mon, 10 Jun 2002 18:56:03 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsrz11998
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 22:55:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmsrz26845
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:54:58 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrz03731
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:54:58 GMT
Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQmsrz03727
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:54:57 GMT
Received: from FRED-W2K6.cisco.com ([10.25.10.242])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5AMsPPJ013811;
	Mon, 10 Jun 2002 15:54:25 -0700 (PDT)
Message-Id: <5.1.1.6.2.20020610154839.01a49378@mira-sjcm-4.cisco.com>
X-Sender: fred@mira-sjcm-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Mon, 10 Jun 2002 15:54:21 -0700
To: "Eric He" <eric@evl.uic.edu>
From: Fred Baker <fred@cisco.com>
Subject: Re: Microflow level QoS implemented by GMPLS
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <003801c210e0$0fd17860$d24fc183@evl.uic.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:36 PM 6/10/2002 -0700, Eric He wrote:
>Integrated Service is used to implement end-to-end microflow level in 
>IP-based network.  But if we can create a host-to-host lightpath using 
>GMPLS, is Integrated Service still necessary to ensure end-to-end Quality 
>of Service? Any comments are more than welcome!

if it's literally light, done with mirrors, there are no queues, and 
configuring queues is unnecessary. You still have the question of whether 
the amount of bandwidth used by the telephone traffic exceeds the amount 
permitted by policy, or if there is no policy, the amount of bandwidth 
available.

If it an OEO solution, you still have the distinct possibility of queues 
forming in the network, and there are questions there.

The lightpath will almost certainly be part of an end-to-end solution; at 
least my PC doesn't have a fiber output on the back, and the hotel room I 
stayed in a few nights ago lacked an optical connection. You also need to 
address the end to end solution even if the optical portion of it is solved.

In short, there is still no magic. You can massively overprovision so that 
there is no case in which traffic engineering is relevant; in such a case, 
your part of the network probably has no current requirement, either for 
QoS or for traffic engineering. If you don't, you have to think about the 
effects of your network on the applications using it.



From owner-mpls@UU.NET  Tue Jun 11 18:09:29 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14748
	for <mpls-archive@lists.ietf.org>; Tue, 11 Jun 2002 18:09:29 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvo06333
	for <mpls-archive@lists.ietf.org>; Tue, 11 Jun 2002 22:10:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsvo04489;
	Tue, 11 Jun 2002 22:09:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsvo06121
	for mpls-outgoing; Tue, 11 Jun 2002 22:08:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsvo06114
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Jun 2002 22:08:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsvo13571
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:08:40 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvo04215
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:08:40 GMT
Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50])
	id QQmsvo04202
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:08:40 GMT
Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 11 Jun 2002 18:08:24 -0400
Message-ID: <3D0674D7.C785E060@tropicnetworks.com>
Date: Tue, 11 Jun 2002 18:08:23 -0400
From: Nabil Seddigh <nseddigh@tropicnetworks.com>
Organization: Tropic Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Issues with draft-ietf-mpls-lsp-ping-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2002 22:08:24.0050 (UTC) FILETIME=[81371D20:01C21194]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



I finally got the chance to read the new version of the dataplane
liveliness draft after having last read v02 previously. I
had a few questions and suggestions:

1. Suggest finding a better name for this application than 
   "MPLS Ping". This is for two reasons. First, the app can 
   actually operate in both Ping and TraceRoute modes and
   2nd, vendors have icmp echo req and reply running over lsps
   and sometimes call that lsp ping which is easily confusable 
   with mpls ping. Maybe something like MPLS liveliness or
   another new term would solve this problem? 

2. Why not consider adding a reply mode of ICMP. 

3. Why not consider adding a reply mode of bi-directional lsp?
   i.e for the case of bi-dir lsps, why not try to return 
   the pkt on the bi-dir lsp. 

4. If implementing #3 above, suggest returning the labels
   in the reverse path of the bi-directional LSP.

5. Suggest changing section 3's packet format for the 
   echo request as follows:

   a) Include an additional 32 bit field called the "identifier 
      field" - this is the same as in ICMP ECHO REQUEST.
      This allows differentiation for the case of multiple
      processes. The source port is often used for this but
      this is only 16 bits while process ids in many OSs are 
      32bits. Having a separate clear identifier field 
      removes the ambiguity associated with this.
  
6. Section 5 is essentially the content of v02 of the draft.
   In that version there was a paragraph or two that 
   explained that there have been previously identified cases
   where the control plane of an LSP was up (ie PATH and RESV
   messages were continually refreshed) while packets on the 
   dataplane for that lsp went into a black-hole. It is for
   precisely this kind of scenario that section 5 is able
   to provide a solution. I think that such kind of content
   would be useful to include in this section again.

Best,
Nabil Seddigh
nseddigh@tropicnetworks.com


From owner-mpls@UU.NET  Tue Jun 11 18:40:08 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15423
	for <mpls-archive@lists.ietf.org>; Tue, 11 Jun 2002 18:40:08 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvq14224
	for <mpls-archive@lists.ietf.org>; Tue, 11 Jun 2002 22:40:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsvq09779;
	Tue, 11 Jun 2002 22:37:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsvq09269
	for mpls-outgoing; Tue, 11 Jun 2002 22:37:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsvq09262
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 11 Jun 2002 22:37:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsvq19021
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:36:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvq28749
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:36:42 GMT
Received: from mail5.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe5.southeast.rr.com [24.93.67.52])
	id QQmsvq28745
	for <mpls@uu.net>; Tue, 11 Jun 2002 22:36:42 GMT
Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC;
	 Tue, 11 Jun 2002 16:00:53 -0400
Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 10 Jun 2002 19:25:42 -0400
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AMe0tH025571
	for <jimpb@nc.rr.com>; Mon, 10 Jun 2002 18:40:00 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry03004
	for <jimpb@nc.rr.com>; Mon, 10 Jun 2002 22:39:33 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsry00497;
	Mon, 10 Jun 2002 22:38:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsry10367
	for mpls-outgoing; Mon, 10 Jun 2002 22:36:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsry10357
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 22:36:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsry00281
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry27017
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from evl.uic.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: evl.evl.uic.edu [131.193.48.80])
	id QQmsry27002
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:32 GMT
Received: from ericpc (evl-79dhcp210.evl.uic.edu [131.193.79.210])
	by evl.uic.edu (8.9.3/8.9.3) with SMTP id RAA24232
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:36:23 -0500 (CDT)
Message-ID: <003801c210e0$0fd17860$d24fc183@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Microflow level QoS implemented by GMPLS
Date: Mon, 10 Jun 2002 17:36:40 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Integrated Service is used to implement end-to-end microflow level in
IP-based network.  But if we can create a host-to-host lightpath using
GMPLS, is Integrated Service still necessary to ensure end-to-end Quality of
Service? Any comments are more than welcome!

Eric He



From owner-mpls@UU.NET  Tue Jun 11 20:12:02 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17252
	for <mpls-archive@lists.ietf.org>; Tue, 11 Jun 2002 20:12:02 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvw29447
	for <mpls-archive@lists.ietf.org>; Wed, 12 Jun 2002 00:12:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsvw26874;
	Wed, 12 Jun 2002 00:11:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsvw00314
	for mpls-outgoing; Wed, 12 Jun 2002 00:10:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsvw00201
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Jun 2002 00:10:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsvw06657
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:43 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvw26018
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:43 GMT
Received: from evl.uic.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: evl.evl.uic.edu [131.193.48.80])
	id QQmsvw26014
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:42 GMT
Received: from ericpc (evl-79dhcp210.evl.uic.edu [131.193.79.210])
	by evl.uic.edu (8.9.3/8.9.3) with SMTP id TAA18781;
	Tue, 11 Jun 2002 19:09:39 -0500 (CDT)
Message-ID: <007101c211b6$40160460$d24fc183@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: "Fred Baker" <fred@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
References: <5.1.1.6.2.20020610154839.01a49378@mira-sjcm-4.cisco.com>
Subject: Re: Microflow level QoS implemented by GMPLS
Date: Tue, 11 Jun 2002 19:09:56 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks a lot!  Helped me a lot!

Sorry for some maybe off-topic questions.
So the understanding is that Integrated Serivce is still necessary for
Microflow level QoS in even MPLambdaS enabled network.
(1) Is Integrated Service practical and easy to deploy in research network?
Is there any academic or industrial solution?  I did some research and seems
IntServ is kinda obsolete.  DiffServ is more scalable but in research
network with fewer users I think scalability is not a problem.
(2) Any research is undergoing on the interaction of Integrated Service and
GMPLS?

Thanks again!
Eric He
----- Original Message -----
From: "Fred Baker" <fred@cisco.com>
To: "Eric He" <eric@evl.uic.edu>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Sent: Monday, June 10, 2002 3:54 PM
Subject: Re: Microflow level QoS implemented by GMPLS


> At 05:36 PM 6/10/2002 -0700, Eric He wrote:
> >Integrated Service is used to implement end-to-end microflow level in
> >IP-based network.  But if we can create a host-to-host lightpath using
> >GMPLS, is Integrated Service still necessary to ensure end-to-end Quality
> >of Service? Any comments are more than welcome!
>
> if it's literally light, done with mirrors, there are no queues, and
> configuring queues is unnecessary. You still have the question of whether
> the amount of bandwidth used by the telephone traffic exceeds the amount
> permitted by policy, or if there is no policy, the amount of bandwidth
> available.
>
> If it an OEO solution, you still have the distinct possibility of queues
> forming in the network, and there are questions there.
>
> The lightpath will almost certainly be part of an end-to-end solution; at
> least my PC doesn't have a fiber output on the back, and the hotel room I
> stayed in a few nights ago lacked an optical connection. You also need to
> address the end to end solution even if the optical portion of it is
solved.
>
> In short, there is still no magic. You can massively overprovision so that
> there is no case in which traffic engineering is relevant; in such a case,
> your part of the network probably has no current requirement, either for
> QoS or for traffic engineering. If you don't, you have to think about the
> effects of your network on the applications using it.
>



From owner-mpls@UU.NET  Wed Jun 12 07:16:59 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23108
	for <mpls-archive@lists.ietf.org>; Wed, 12 Jun 2002 07:16:59 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsxp23949
	for <mpls-archive@lists.ietf.org>; Wed, 12 Jun 2002 11:17:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsxp23263;
	Wed, 12 Jun 2002 11:17:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsxp22876
	for mpls-outgoing; Wed, 12 Jun 2002 11:16:09 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsxp22833
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Jun 2002 11:16:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsxp19160
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:16:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsxp26114
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:16:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmsxp26105
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:16:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA24885 for <mpls@uu.net>; Wed, 12 Jun 2002 07:16:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA16855 for mpls@uu.net; Wed, 12 Jun 2002 07:16:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsxo22411
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Jun 2002 11:14:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsxo16469
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:14:33 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsxo01899
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:14:32 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmsxo01895
	for <mpls@uu.net>; Wed, 12 Jun 2002 11:14:32 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22943;
	Wed, 12 Jun 2002 07:13:57 -0400 (EDT)
Message-Id: <200206121113.HAA22943@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-02.txt
Date: Wed, 12 Jun 2002 07:13:56 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Multiprotocol Label Switching (MPLS) Management 
                          Overview
	Author(s)	: T. Nadeau, C. Srinivasan, A. Farrel
	Filename	: draft-ietf-mpls-mgmt-overview-02.txt
	Pages		: 22
	Date		: 11-Jun-02
	
An assortment of management Information Bases (MIBs) has
been developed to help model and manage the various aspects
of Multiprotocol Label Switching (MPLS) networks.  These
MIBs are defined in separate drafts and RFCs that focus on
the specific areas of responsibility of their MIBs.
This memo describes the management architecture for MPLS
and indicates the inter-relationships between the different
MIBs used for MPLS network management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mgmt-overview-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020611122844.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-mgmt-overview-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020611122844.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Jun 12 12:47:35 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04389
	for <mpls-archive@lists.ietf.org>; Wed, 12 Jun 2002 12:47:35 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsyl26450
	for <mpls-archive@lists.ietf.org>; Wed, 12 Jun 2002 16:47:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsyl23850;
	Wed, 12 Jun 2002 16:46:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsyl08589
	for mpls-outgoing; Wed, 12 Jun 2002 16:46:10 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmsyl08444
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Jun 2002 16:45:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsyl11168
	for <mpls@UU.NET>; Wed, 12 Jun 2002 16:45:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsyl10615
	for <mpls@UU.NET>; Wed, 12 Jun 2002 16:45:05 GMT
Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56])
	id QQmsyl10603
	for <mpls@UU.NET>; Wed, 12 Jun 2002 16:45:04 GMT
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CGisO01777;
	Wed, 12 Jun 2002 12:44:55 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBS7PG>; Wed, 12 Jun 2002 12:44:54 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3403AFD7D0@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Kireeti Kompella <kireeti@juniper.net>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: technical comments on LSP-ping-03
Date: Wed, 12 Jun 2002 12:44:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C21230.7A11672A"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21230.7A11672A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Kireeti:

Following up on LSP-PING discussion from March... 

Dave

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Friday, March 29, 2002 4:58 PM
> To: Shahram Davari
> Cc: 'mpls@uu.net'
> Subject: Re: technical comments on LSP-ping-03
> 
> 
> 
> Thanks David and Shahram for your comments.  This is very clearly
> a work in progress and yours (and others) input is very welcome.
> 
> Hopefully, in the next week or so, there will be another version of
> this draft.  Some of your questions have been (or will be) addressed,
> but probably not most.  I will reply to the rest of your comments in
> detail shortly.
> 
> Kireeti.
> 
> 

------_=_NextPart_001_01C21230.7A11672A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: technical comments on LSP-ping-03</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Kireeti:</FONT>
</P>

<P><FONT SIZE=2>Following up on LSP-PING discussion from March... </FONT>
</P>

<P><FONT SIZE=2>Dave</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Kireeti Kompella [<A HREF="mailto:kireeti@juniper.net">mailto:kireeti@juniper.net</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, March 29, 2002 4:58 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Shahram Davari</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'mpls@uu.net'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: technical comments on LSP-ping-03</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks David and Shahram for your comments.&nbsp; This is very clearly</FONT>
<BR><FONT SIZE=2>&gt; a work in progress and yours (and others) input is very welcome.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hopefully, in the next week or so, there will be another version of</FONT>
<BR><FONT SIZE=2>&gt; this draft.&nbsp; Some of your questions have been (or will be) addressed,</FONT>
<BR><FONT SIZE=2>&gt; but probably not most.&nbsp; I will reply to the rest of your comments in</FONT>
<BR><FONT SIZE=2>&gt; detail shortly.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Kireeti.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C21230.7A11672A--


From owner-mpls@UU.NET  Thu Jun 13 08:46:01 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09819
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 08:46:01 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbn18073
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 12:46:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbm12993;
	Thu, 13 Jun 2002 12:43:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbm27573
	for mpls-outgoing; Thu, 13 Jun 2002 12:43:03 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtbm27566
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 12:43:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtbm05980
	for <mpls@uu.net>; Thu, 13 Jun 2002 12:42:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbm12836
	for <mpls@uu.net>; Thu, 13 Jun 2002 12:42:53 GMT
Received: from mail7.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe7.southeast.rr.com [24.93.67.54])
	id QQmtbm12832
	for <mpls@uu.net>; Thu, 13 Jun 2002 12:42:53 GMT
Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC;
	 Thu, 13 Jun 2002 08:17:55 -0400
Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 10 Jun 2002 18:41:12 -0400
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AMfCtH029504
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 18:41:12 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry06769
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 22:41:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsry00149;
	Mon, 10 Jun 2002 22:38:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsry10367
	for mpls-outgoing; Mon, 10 Jun 2002 22:36:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmsry10357
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 22:36:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsry00281
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsry27017
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:33 GMT
Received: from evl.uic.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: evl.evl.uic.edu [131.193.48.80])
	id QQmsry27002
	for <mpls@UU.NET>; Mon, 10 Jun 2002 22:36:32 GMT
Received: from ericpc (evl-79dhcp210.evl.uic.edu [131.193.79.210])
	by evl.uic.edu (8.9.3/8.9.3) with SMTP id RAA24232
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:36:23 -0500 (CDT)
Message-ID: <003801c210e0$0fd17860$d24fc183@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Microflow level QoS implemented by GMPLS
Date: Mon, 10 Jun 2002 17:36:40 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Integrated Service is used to implement end-to-end microflow level in
IP-based network.  But if we can create a host-to-host lightpath using
GMPLS, is Integrated Service still necessary to ensure end-to-end Quality of
Service? Any comments are more than welcome!

Eric He



From owner-mpls@UU.NET  Thu Jun 13 09:31:07 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11416
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 09:31:06 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbq12089
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 13:31:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbq09850;
	Thu, 13 Jun 2002 13:30:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbq23771
	for mpls-outgoing; Thu, 13 Jun 2002 13:30:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtbq23764
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 13:30:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtbq00018
	for <mpls@uu.net>; Thu, 13 Jun 2002 13:30:01 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbq09180
	for <mpls@uu.net>; Thu, 13 Jun 2002 13:30:01 GMT
Received: from nausicaa.coritel.it by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [193.205.242.5])
	id QQmtbq09138
	for <mpls@uu.net>; Thu, 13 Jun 2002 13:30:00 GMT
Received: from confucio (socrate [141.137.43.17])
	by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id g5DDX1x28649
	for <mpls@uu.net>; Thu, 13 Jun 2002 15:33:01 +0200
Message-ID: <002f01c212de$053f2820$112b898d@confucio>
From: "Pietro Tou" <tou@coritel.it>
To: <mpls@UU.NET>
Subject: RSVP tear down from intermediate node
Date: Thu, 13 Jun 2002 15:26:22 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C212EE.AC9CF880"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Disposition-Notification-To: "Pietro Tou" <tou@coritel.it>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01C212EE.AC9CF880
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all
we have a question: how can we force RSVP to tear down an LSP from an=20
intermediate node?=20

We thought about triggering a Resv Err message from the intermediate =
node to=20
the destination node of the LPS to be torn down. In fact, Resv Error =
message=20
is used to notify preemption (according to RFC), but how can the message =
be sent? =20
Is there a way to make the "administrative preemption"?
RAPI calls seem to not cover this request, because all error messages =
seem to=20
be managed only internally in the RSVP daemon.

I hope someone can help!!
Pietro Tou

------=_NextPart_000_002C_01C212EE.AC9CF880
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Hi all<BR>we=20
have a question: how can we force RSVP to tear down an LSP from an=20
<BR>intermediate node? <BR><BR>We thought about triggering a Resv Err =
message=20
from the intermediate node to <BR>the destination node of the LPS to be =
torn=20
down. In fact, Resv Error message <BR>is used to notify preemption =
(according to=20
RFC), but how can the message be sent?&nbsp; <BR>Is there a way to make =
the=20
"administrative preemption"?<BR>RAPI calls seem to not cover this =
request,=20
because all error messages seem to <BR>be managed only internally in the =
RSVP=20
daemon.<BR><BR>I hope someone can help!!</FONT><BR>Pietro=20
Tou</FONT></DIV></BODY></HTML>

------=_NextPart_000_002C_01C212EE.AC9CF880--



From owner-mpls@UU.NET  Thu Jun 13 10:01:22 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12922
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 10:01:17 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbs02276
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 14:01:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbs29038;
	Thu, 13 Jun 2002 14:00:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbr26113
	for mpls-outgoing; Thu, 13 Jun 2002 13:59:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtbr26101
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 13:59:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtbr20943
	for <mpls@UU.NET>; Thu, 13 Jun 2002 13:59:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbr16163
	for <mpls@UU.NET>; Thu, 13 Jun 2002 13:59:11 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtbr16156
	for <mpls@UU.NET>; Thu, 13 Jun 2002 13:59:11 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07533
	for <mpls@UU.NET>; Thu, 13 Jun 2002 09:59:09 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05866
	for <mpls@UU.NET>; Thu, 13 Jun 2002 09:59:09 -0400 (EDT)
Message-ID: <3D08A525.6D290FAC@marconi.com>
Date: Thu, 13 Jun 2002 09:59:01 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP tear down from intermediate node
References: <002f01c212de$053f2820$112b898d@confucio>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pietro Tou wrote:
> 
> we have a question: how can we force RSVP to tear down an LSP from
> an intermediate node?

You can't.  It can send a PathErr to the ingress node.  Depending on the
kind of error you send, the ingress node should respond by tearing the
LSP.

> We thought about triggering a Resv Err message from the
> intermediate node to the destination node of the LPS to be torn
> down.

ResvErr won't help, because the egress node is not the node that must do
the actual tear.

> In fact, Resv Error message is used to notify preemption
> (according to RFC), but how can the message be sent?

ResvErr is used for many things.

And preemption should cause _both_ a PathErr and ResvErr to be
generated.

> Is there a way to make the "administrative preemption"?
> RAPI calls seem to not cover this request, because all error
> messages seem to be managed only internally in the RSVP daemon.

If there isn't an error code/value that describes exactly what you want,
pick one that comes close.  If you want to define a new one, write a
draft and submit it here for us to discuss.

-- David


From owner-mpls@UU.NET  Thu Jun 13 10:59:07 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16100
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 10:59:05 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbv20207
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 14:59:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbv17372;
	Thu, 13 Jun 2002 14:58:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbv23223
	for mpls-outgoing; Thu, 13 Jun 2002 14:57:41 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtbv23218
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 14:57:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtbv29021
	for <mpls@UU.NET>; Thu, 13 Jun 2002 14:56:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbv05875
	for <mpls@UU.NET>; Thu, 13 Jun 2002 14:56:14 GMT
Received: from albatross.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	id QQmtbv05865
	for <mpls@UU.NET>; Thu, 13 Jun 2002 14:56:13 GMT
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5DEuCmG028484;
	Thu, 13 Jun 2002 16:56:12 +0200 (MEST)
Received: from ESEALNT745.al.sw.ericsson.se ([153.88.251.5]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id M3JPHRG5; Thu, 13 Jun 2002 16:56:12 +0200
Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <M2RXLK39>; Thu, 13 Jun 2002 16:56:12 +0200
Message-ID: <7090FF16C5C81D4FB833E345EC203ABC1B8467@eitrmnt105.tei.ericsson.se>
X-Sybari-Trust: 9b094fef 2a03b045 174f49cf 00000138
From: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>
To: "'David Charlap'" <David.Charlap@marconi.com>, mpls@UU.NET
Subject: RE: RSVP tear down from intermediate node
Date: Thu, 13 Jun 2002 16:55:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16100

Hi David,
We agree with you about the possibility to use PathErr and PathTear to tear down a LSP, but our problem is different. We are using RAPI ver.5.2 and we'd like to know if it is possible to send from the RAPI to the daemon a request
for PathErr. By reading the draft it seems it is not allowed, is it rigth? 
Is there another way to force error messages to the daemon? 
Thanks
Paola, Pietro, Daniela

-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: giovedì 13 giugno 2002 15.59
To: mpls@UU.NET
Subject: Re: RSVP tear down from intermediate node


Pietro Tou wrote:
> 
> we have a question: how can we force RSVP to tear down an LSP from
> an intermediate node?

You can't.  It can send a PathErr to the ingress node.  Depending on the
kind of error you send, the ingress node should respond by tearing the
LSP.

> We thought about triggering a Resv Err message from the
> intermediate node to the destination node of the LPS to be torn
> down.

ResvErr won't help, because the egress node is not the node that must do
the actual tear.

> In fact, Resv Error message is used to notify preemption
> (according to RFC), but how can the message be sent?

ResvErr is used for many things.

And preemption should cause _both_ a PathErr and ResvErr to be
generated.

> Is there a way to make the "administrative preemption"?
> RAPI calls seem to not cover this request, because all error
> messages seem to be managed only internally in the RSVP daemon.

If there isn't an error code/value that describes exactly what you want,
pick one that comes close.  If you want to define a new one, write a
draft and submit it here for us to discuss.

-- David


From owner-mpls@UU.NET  Thu Jun 13 11:15:21 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16964
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 11:15:21 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbx06747
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 15:15:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbw04024;
	Thu, 13 Jun 2002 15:14:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbw16393
	for mpls-outgoing; Thu, 13 Jun 2002 15:13:57 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtbw16387
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 15:13:48 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtbw05873
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:12:24 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbw19743
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:12:24 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtbw19735
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:12:23 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15305
	for <mpls@UU.NET>; Thu, 13 Jun 2002 11:12:22 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26788
	for <mpls@UU.NET>; Thu, 13 Jun 2002 11:12:21 -0400 (EDT)
Message-ID: <3D08B64D.352B20C9@marconi.com>
Date: Thu, 13 Jun 2002 11:12:13 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP tear down from intermediate node
References: <7090FF16C5C81D4FB833E345EC203ABC1B8467@eitrmnt105.tei.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Paola Iovanna (ERI)" wrote:
> 
> We agree with you about the possibility to use PathErr and PathTear
> to tear down a LSP, but our problem is different. We are using RAPI
> ver.5.2 and we'd like to know if it is possible to send from the
> RAPI to the daemon a request for PathErr. By reading the draft it
> seems it is not allowed, is it rigth?
> Is there another way to force error messages to the daemon?

What daemon?  You're talking about an implementation, not the protocol.

No draft is ever going to say anything about specific implementations. 
I suggest you ask your stack vendor how to make the request.

-- David


From owner-mpls@UU.NET  Thu Jun 13 11:27:21 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17605
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 11:27:21 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbx27677
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 15:27:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtbx25737;
	Thu, 13 Jun 2002 15:26:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtbx17840
	for mpls-outgoing; Thu, 13 Jun 2002 15:26:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtbx17835
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 15:26:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtbx10472
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:24:51 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtbx24617
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:24:51 GMT
Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmtbx24589
	for <mpls@UU.NET>; Thu, 13 Jun 2002 15:24:45 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DFP3PJ019258;
	Thu, 13 Jun 2002 11:25:04 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com ([10.86.244.0])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABD78643;
	Thu, 13 Jun 2002 11:24:33 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020613112257.0248cb50@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 13 Jun 2002 11:24:32 -0400
To: Nabil Seddigh <nseddigh@tropicnetworks.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Issues with draft-ietf-mpls-lsp-ping-00.txt
Cc: mpls@UU.NET
In-Reply-To: <3D0674D7.C785E060@tropicnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:08 PM 6/11/2002 -0400, Nabil Seddigh wrote:


>I finally got the chance to read the new version of the dataplane
>liveliness draft after having last read v02 previously. I
>had a few questions and suggestions:
>
>1. Suggest finding a better name for this application than
>    "MPLS Ping". This is for two reasons. First, the app can
>    actually operate in both Ping and TraceRoute modes and
>    2nd, vendors have icmp echo req and reply running over lsps
>    and sometimes call that lsp ping which is easily confusable
>    with mpls ping. Maybe something like MPLS liveliness or
>    another new term would solve this problem?

         I personally like MPLS ping for the simple reason that intuitively
this is what it does and this is how people will use it. MPLS ping
just has the extra feature of traceroute.  I don't think that the ICMP
ping is an issue.

         --Tom

>2. Why not consider adding a reply mode of ICMP.
>
>3. Why not consider adding a reply mode of bi-directional lsp?
>    i.e for the case of bi-dir lsps, why not try to return
>    the pkt on the bi-dir lsp.
>
>4. If implementing #3 above, suggest returning the labels
>    in the reverse path of the bi-directional LSP.
>
>5. Suggest changing section 3's packet format for the
>    echo request as follows:
>
>    a) Include an additional 32 bit field called the "identifier
>       field" - this is the same as in ICMP ECHO REQUEST.
>       This allows differentiation for the case of multiple
>       processes. The source port is often used for this but
>       this is only 16 bits while process ids in many OSs are
>       32bits. Having a separate clear identifier field
>       removes the ambiguity associated with this.
>
>6. Section 5 is essentially the content of v02 of the draft.
>    In that version there was a paragraph or two that
>    explained that there have been previously identified cases
>    where the control plane of an LSP was up (ie PATH and RESV
>    messages were continually refreshed) while packets on the
>    dataplane for that lsp went into a black-hole. It is for
>    precisely this kind of scenario that section 5 is able
>    to provide a solution. I think that such kind of content
>    would be useful to include in this section again.
>
>Best,
>Nabil Seddigh
>nseddigh@tropicnetworks.com



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Thu Jun 13 15:14:54 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26787
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 15:14:53 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcn09533
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 19:15:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtcm07239;
	Thu, 13 Jun 2002 19:14:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtcm09264
	for mpls-outgoing; Thu, 13 Jun 2002 19:13:58 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtcm09191
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 19:13:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtcm21759
	for <mpls@UU.NET>; Thu, 13 Jun 2002 19:13:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcm06722
	for <mpls@UU.NET>; Thu, 13 Jun 2002 19:13:30 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQmtcm06716
	for <mpls@UU.NET>; Thu, 13 Jun 2002 19:13:29 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 13 Jun 2002 15:13:29 -0400
Message-ID: <01c801c2130e$66a8bec0$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: MPLS Management Overview
Date: Thu, 13 Jun 2002 15:13:28 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 13 Jun 2002 19:13:29.0349 (UTC) FILETIME=[66B65350:01C2130E]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
A new version of the MPLS Management Overview has been posted.  I didn't see a
notification to the mail exploder, but I may have been sleeping.

Main changes are an increase in detail and a description of the inter-relation
between MIB modules, and between MIB tables.

http://search.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-02.txt

Adrian





From owner-mpls@UU.NET  Thu Jun 13 16:24:36 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29216
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 16:24:36 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcr18605
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 20:25:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtcr16026;
	Thu, 13 Jun 2002 20:23:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtcr10373
	for mpls-outgoing; Thu, 13 Jun 2002 20:23:38 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtcr10364
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 20:23:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtcr10039
	for <mpls@UU.NET>; Thu, 13 Jun 2002 20:22:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcr02344
	for <mpls@UU.NET>; Thu, 13 Jun 2002 20:22:03 GMT
Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: exchange.santera.com [4.22.157.11])
	id QQmtcr02338
	for <mpls@UU.NET>; Thu, 13 Jun 2002 20:22:02 GMT
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: MPLS Management Overview
Date: Thu, 13 Jun 2002 15:22:01 -0500
Message-ID: <CD110021698980419241042CF576B8F2017CE177@EXCALIBUR.santera.com>
Thread-Topic: MPLS Management Overview
Thread-Index: AcITDwWLvjdQ12EAT+atswrlHmECjwACK8eg
From: "Zhu, Rupert" <rupert.zhu@santera.com>
To: "Adrian Farrel" <afarrel@movaz.com>, "mpls@uu.net" <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29216

Hi Adrian,

Thanks for the info. This overview document is quite helpful.

One point to raise, though. In comparing TE-MIB (by te-wg) and
MPLS-TE-MIB (by mpls-wg), the document failed to point out that
the TE-MIB is structured better than the MPLS-TE-MIB.

Take a look at TE-MIB's structure.

http://search.ietf.org/internet-drafts/draft-ietf-tewg-mib-02.txt

    Table Name                            # of Fields
    -------------------------------------------------
    teAdminGroupTable                         2
    teTunnelTable                            21
    tePathTable                              16
    tePathHopTable                            5
    -------------------------------------------------

The TE-MIB makes good distinction of "logical tunnel" from
underlying "path", and models the two distinct entity classes
with separate MIB tables.  In addition, the name of
"tePathHopTable" clearly indicates that "hop list" is a property
of "path" rather than "logical tunnel".  A very clean design.

In contrast, the current MPLS-TE-MIB lumps attributes of "logical
tunnel" together with attributes of underlying "path", and makes
a big, monolithic table ("mplsTunnelTable").  This approach is
problematic, IMHO.

Well, I do recognize the excellent achievement in putting together
the comprehensive MPLS-TE-MIB and appreciate the great effort by the
authors.  Just want to point out that it is not perfect, yet.

Regards,


Rupert Zhu

System Engineering
Santera Systems Inc.
972-461-6383 (TX, USA)


> -----Original Message-----
> From: Adrian Farrel [mailto:afarrel@movaz.com]
> Sent: Thursday, June 13, 2002 2:13 PM
> To: 'mpls@uu.net'
> Subject: MPLS Management Overview
> 
> 
> Hi,
> A new version of the MPLS Management Overview has been 
> posted.  I didn't see a
> notification to the mail exploder, but I may have been sleeping.
> 
> Main changes are an increase in detail and a description of 
> the inter-relation
> between MIB modules, and between MIB tables.
> 
> http://search.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-ov
erview-02.txt

Adrian





From owner-mpls@UU.NET  Thu Jun 13 17:55:09 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01797
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 17:55:09 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcx06322
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 21:55:35 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtcx03066;
	Thu, 13 Jun 2002 21:53:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtcx10067
	for mpls-outgoing; Thu, 13 Jun 2002 21:53:18 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtcx09959
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 21:53:05 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtcx22064
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:52:10 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcx16866
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:52:10 GMT
Received: from mail8.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe8.southeast.rr.com [24.93.67.55])
	id QQmtcx16857
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:52:09 GMT
Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC;
	 Thu, 13 Jun 2002 16:51:23 -0400
Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 10 Jun 2002 13:25:35 -0400
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AHPZIa026193
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 13:25:35 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd07625
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 17:25:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrd04098;
	Mon, 10 Jun 2002 17:23:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrd22947
	for mpls-outgoing; Mon, 10 Jun 2002 17:22:26 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsrd22942
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:22:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmsrd13377
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd19405
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmsrd19398
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:21:23 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10694
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:21:17 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18589
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:21:17 -0400 (EDT)
Message-ID: <3D04E037.7F4737B@marconi.com>
Date: Mon, 10 Jun 2002 13:21:59 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Basic LDP Question
References: <B9571FDEBD3DD21181E500606DD5EE0514BABE20@mbddmknt01.hc.bt.com> <20020603100111.G3433@eosborne-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Osborne wrote:
> 
> LDP lets you easily integrate IP and ATM; call it cell mode, call it
> LC_ATM, call it IP+ATM (I'm not sure which terms are cisco
> marketing-speak and which are standardized).  It's not immediately
> clear to me how you could do that with IP while using the existing
> ATM switch hardware and with only a control-plane upgrade.

It can also be done with LANE or CLIP, but these protocols have much
more overhead and can't directly connect with non-ATM switches, since
they don't use an IP-based control plane.

-- David


From owner-mpls@UU.NET  Thu Jun 13 18:02:54 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01985
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 18:02:54 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcy25055
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 22:03:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtcy21912;
	Thu, 13 Jun 2002 22:01:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtcy16328
	for mpls-outgoing; Thu, 13 Jun 2002 22:01:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtcy16277
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 13 Jun 2002 22:00:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtcx15687
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:59:43 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtcx22606
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:59:43 GMT
Received: from mail8.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe8.southeast.rr.com [24.93.67.55])
	id QQmtcx22596
	for <mpls@uu.net>; Thu, 13 Jun 2002 21:59:42 GMT
Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC;
	 Thu, 13 Jun 2002 16:55:43 -0400
Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail8.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 10 Jun 2002 13:29:46 -0400
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AHTkIa011418
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 13:29:46 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd13854
	for <pholz@nc.rr.com>; Mon, 10 Jun 2002 17:29:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsrd09816;
	Mon, 10 Jun 2002 17:27:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsrd23263
	for mpls-outgoing; Mon, 10 Jun 2002 17:26:04 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsrd23251
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 17:26:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsrd21165
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:50 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsrd06192
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:48 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmsrd06077
	for <mpls@UU.NET>; Mon, 10 Jun 2002 17:24:44 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11009
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:24:42 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19431
	for <mpls@UU.NET>; Mon, 10 Jun 2002 13:24:43 -0400 (EDT)
Message-ID: <3D04E105.15A3D20@marconi.com>
Date: Mon, 10 Jun 2002 13:25:25 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Basic LDP Question
References: <4B6D09F3B826D411A67300D0B706EFDEB03665@nt-exch-yow.pmc-sierra.bc.ca> <20020603142031.Q3433@eosborne-u10.cisco.com> <Pine.GSO.4.44.0206031448400.28616-100000@asimha-u10.cisco.com> <20020603173524.W3433@eosborne-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Osborne wrote:
>>
>> Actually VC merge is not a must if the LSR request seperate
>> labels - one per request it gets from the upstream neighbor.
> 
> Right, but then Sharam's got a point; if you're not merging, LDP
> and RSVP look a lot alike.

With the exception that LDP can create its LSPs based on the local
routing table, while RSVP can only create them in response to explicit
requests from ingress nodes.

There is little effective semantic difference between CR-LDP and RSVP,
however.

-- David


From owner-mpls@UU.NET  Thu Jun 13 21:35:04 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07209
	for <mpls-archive@lists.ietf.org>; Thu, 13 Jun 2002 21:35:03 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtdm14560
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 01:35:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtdm11792;
	Fri, 14 Jun 2002 01:34:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtdm01487
	for mpls-outgoing; Fri, 14 Jun 2002 01:33:39 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtdm01481
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 01:33:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtdm18678
	for <mpls@UU.NET>; Fri, 14 Jun 2002 01:33:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtdm11529
	for <mpls@UU.NET>; Fri, 14 Jun 2002 01:33:25 GMT
Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmtdm11525
	for <mpls@UU.NET>; Fri, 14 Jun 2002 01:33:25 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5E1XpMi000200;
	Thu, 13 Jun 2002 21:33:52 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (che-vpn1-19.cisco.com [10.86.240.19])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABD88509;
	Thu, 13 Jun 2002 21:33:20 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020613213230.01c36eb0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 13 Jun 2002 21:33:19 -0400
To: "Zhu, Rupert" <rupert.zhu@santera.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: MPLS Management Overview
Cc: "Adrian Farrel" <afarrel@movaz.com>, "mpls@uu.net" <mpls@UU.NET>
In-Reply-To: <CD110021698980419241042CF576B8F2017CE177@EXCALIBUR.santera
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



>Thanks for the info. This overview document is quite helpful.
>
>One point to raise, though. In comparing TE-MIB (by te-wg) and
>MPLS-TE-MIB (by mpls-wg), the document failed to point out that
>the TE-MIB is structured better than the MPLS-TE-MIB.


         Rupert, the point of the document IS NOT to
have a spitting match over which MIB you think is
better that which.  We had a nice one about a year and a half
ago. If you feel like doing such a comparison on your own
feel free.

         --Tom



>Take a look at TE-MIB's structure.
>
>http://search.ietf.org/internet-drafts/draft-ietf-tewg-mib-02.txt
>
>     Table Name                            # of Fields
>     -------------------------------------------------
>     teAdminGroupTable                         2
>     teTunnelTable                            21
>     tePathTable                              16
>     tePathHopTable                            5
>     -------------------------------------------------
>
>The TE-MIB makes good distinction of "logical tunnel" from
>underlying "path", and models the two distinct entity classes
>with separate MIB tables.  In addition, the name of
>"tePathHopTable" clearly indicates that "hop list" is a property
>of "path" rather than "logical tunnel".  A very clean design.
>
>In contrast, the current MPLS-TE-MIB lumps attributes of "logical
>tunnel" together with attributes of underlying "path", and makes
>a big, monolithic table ("mplsTunnelTable").  This approach is
>problematic, IMHO.
>
>Well, I do recognize the excellent achievement in putting together
>the comprehensive MPLS-TE-MIB and appreciate the great effort by the
>authors.  Just want to point out that it is not perfect, yet.
>
>Regards,
>
>
>Rupert Zhu
>
>System Engineering
>Santera Systems Inc.
>972-461-6383 (TX, USA)
>
>
> > -----Original Message-----
> > From: Adrian Farrel [mailto:afarrel@movaz.com]
> > Sent: Thursday, June 13, 2002 2:13 PM
> > To: 'mpls@uu.net'
> > Subject: MPLS Management Overview
> >
> >
> > Hi,
> > A new version of the MPLS Management Overview has been
> > posted.  I didn't see a
> > notification to the mail exploder, but I may have been sleeping.
> >
> > Main changes are an increase in detail and a description of
> > the inter-relation
> > between MIB modules, and between MIB tables.
> >
> > http://search.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-ov
>erview-02.txt
>
>Adrian



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Fri Jun 14 10:11:28 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00405
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 10:11:28 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfa11837
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 11:34:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtfa09256;
	Fri, 14 Jun 2002 11:33:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtfa26258
	for mpls-outgoing; Fri, 14 Jun 2002 11:33:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtfa26253
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 11:33:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtfa24922
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:33:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfa12948
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:33:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtfa12944
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:33:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA12946 for <mpls@uu.net>; Fri, 14 Jun 2002 07:33:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA01630 for mpls@uu.net; Fri, 14 Jun 2002 07:33:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtfa26193
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 11:32:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtfa27035
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:31:33 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfa12357
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:31:33 GMT
Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmtfa12353
	for <mpls@uu.net>; Fri, 14 Jun 2002 11:31:33 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24983;
	Fri, 14 Jun 2002 07:30:57 -0400 (EDT)
Message-Id: <200206141130.HAA24983@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-02.txt
Date: Fri, 14 Jun 2002 07:30:56 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Graceful Restart Mechanism for LDP
	Author(s)	: M. Leelanivas, Y. Rekhter, R. Aggarwal
	Filename	: draft-ietf-mpls-ldp-restart-02.txt
	Pages		: 10
	Date		: 13-Jun-02
	
This document describes a mechanism that helps to minimize the
negative effects on MPLS traffic caused by Label Switch Router's
(LSR's) control plane restart, and specifically by the restart of its
Label Distribution Protocol (LDP) component, on LSRs that are capable
of preserving the MPLS forwarding component across the restart.
The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during LDP
restart and those without (although the latter need to implement only
a subset of the mechanism described in this document).
The mechanism makes minimalistic assumptions on what has to be
preserved across restart - the mechanism assumes that only the actual
MPLS forwarding state has to be preserved; the mechanism does not
require any of the LDP-related state to be preserved across the
restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ldp-restart-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ldp-restart-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020613143544.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-restart-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-restart-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020613143544.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jun 14 11:14:41 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02869
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 11:14:40 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfp16761
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 15:15:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtfo15195;
	Fri, 14 Jun 2002 15:14:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtfo11441
	for mpls-outgoing; Fri, 14 Jun 2002 15:14:05 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtfo11436
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 15:14:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtfo04527
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:13:42 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfo19828
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:13:41 GMT
Received: from newman.nssi.telus.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: newman.nssi.telus.com [208.38.59.87])
	id QQmtfo19821
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:13:41 GMT
Received: (qmail 19750 invoked from network); 14 Jun 2002 15:13:40 -0000
Received: from unknown (HELO abmsg001.corp.ads) (142.178.12.151)
  by 142.178.52.235 with SMTP; 14 Jun 2002 15:13:40 -0000
Received: from 142.178.13.81 by abmsg001.corp.ads with ESMTP (Tumbleweed
 MMS SMTP Relay (MMS v4.7)); Fri, 14 Jun 2002 09:13:07 -0600
X-Server-Uuid: 62333db7-76d7-4c1e-8695-ae6a73d58b85
Received: by abmsg002.ent.agt.ab.ca with Internet Mail Service (
 5.5.2653.19) id <LD54VF2K>; Fri, 14 Jun 2002 09:12:17 -0600
Message-ID: <A393142ECB62D511B4C00001FA7E215F02B2113A@ex7.ent.agt.ab.ca>
From: "Rob Woollam" <Rob.Woollam@telus.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: status of kompella draft
Date: Fri, 14 Jun 2002 09:13:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1114D7891984601-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello all,

I'm wondering if someone can tell me the status of the kompella-mpls-l2vpn
draft.  The copy I have expired in May 2001 and covers ATM and FR.  Has this
draft been updated recently (to cover Ethernet) or is there another draft I
should be looking at?
Any direction would be greatly appreciated.
	
	Thanks,

		Rob.





From owner-mpls@UU.NET  Fri Jun 14 11:41:37 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03887
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 11:41:37 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfq10654
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 15:42:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtfq07403;
	Fri, 14 Jun 2002 15:40:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtfq13675
	for mpls-outgoing; Fri, 14 Jun 2002 15:40:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtfq13670
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 15:40:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtfq12843
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:40:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfq06912
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:40:13 GMT
Received: from mast-dc0-sm01.private.ntl.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mimesweeper.cableol.net [194.168.3.9])
	id QQmtfq06908
	for <mpls@uu.net>; Fri, 14 Jun 2002 15:40:13 GMT
Received: from mast-dc0-se03.private.ntl.com (unverified) by mast-dc0-sm01.private.ntl.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id <T5b7be7be6c0a86110b081@mast-dc0-sm01.private.ntl.com>;
 Fri, 14 Jun 2002 16:40:09 +0100
Received: by mast-dc0-se03.private.ntl.com with Internet Mail Service (5.5.2653.19)
	id <L885ZQJX>; Fri, 14 Jun 2002 16:40:08 +0100
Message-ID: <41C3D4E6AD88D411B47800508B620FE80301E923@mast-hk0-se03.private.ntl.com>
From: Justin Boon <Justin.Boon@ntl.com>
To: "'Rob Woollam'" <Rob.Woollam@telus.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: status of kompella draft
Date: Fri, 14 Jun 2002 16:40:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

You could try Martini:

http://www.ietf.org/internet-drafts/draft-martini-ethernet-encap-mpls-00.txt

If you search on Kompella's latest drafts @
http://www.rfc-editor.org/cgi-bin/idsearch.pl using 
the author search string.

Hope this helps somewhat

-----Original Message-----
From: Rob Woollam [mailto:Rob.Woollam@telus.com]
Sent: 14 June 2002 16:14
To: 'mpls@uu.net'
Subject: status of kompella draft


Hello all,

I'm wondering if someone can tell me the status of the kompella-mpls-l2vpn
draft.  The copy I have expired in May 2001 and covers ATM and FR.  Has this
draft been updated recently (to cover Ethernet) or is there another draft I
should be looking at?
Any direction would be greatly appreciated.
	
	Thanks,

		Rob.




The contents of this email and any attachments are sent for the personal attention
of the addressee(s) only and may be confidential.  If you are not the intended
addressee, any use, disclosure or copying of this email and any attachments is
unauthorised - please notify the sender by return and delete the message.  Any
representations or commitments expressed in this email are subject to contract. 
 
ntl Group Limited



From owner-mpls@UU.NET  Fri Jun 14 13:57:17 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08118
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 13:57:17 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfz03650
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 17:57:50 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtfz01828;
	Fri, 14 Jun 2002 17:56:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtfz08178
	for mpls-outgoing; Fri, 14 Jun 2002 17:56:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtfz08171
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 17:56:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtfz28059
	for <mpls@UU.NET>; Fri, 14 Jun 2002 17:55:58 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtfz01275
	for <mpls@UU.NET>; Fri, 14 Jun 2002 17:55:57 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtfz01269
	for <mpls@UU.NET>; Fri, 14 Jun 2002 17:55:57 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26963
	for <mpls@UU.NET>; Fri, 14 Jun 2002 13:55:54 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23101
	for <mpls@UU.NET>; Fri, 14 Jun 2002 13:55:55 -0400 (EDT)
Message-ID: <3D0A2E25.8B7EA431@marconi.com>
Date: Fri, 14 Jun 2002 13:55:50 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: status of kompella draft
References: <41C3D4E6AD88D411B47800508B620FE80301E923@mast-hk0-se03.private.ntl.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> I'm wondering if someone can tell me the status of the
> kompella-mpls-l2vpn draft.  The copy I have expired in May 2001
> and covers ATM and FR.  Has this draft been updated recently (to
> cover Ethernet) or is there another draft I should be looking at?
> Any direction would be greatly appreciated.

My local mirror of the draft repository says that
draft-kompella-mpls-l2vpn-03 has been replaced by
draft-kompella-ppvpn-l2vpn-00.

The latest version is draft-kompella-ppvpn-lp2vpn-01.txt, which expired
in May, 2002.

Note the name change - it has been moved to the PPVPN (Provider
Provisioned VPN) working group.  You may want to browse that working
group http://www.ietf.org/html.charters/ppvpn-charter.html to see if
Kompella's draft has been incorporated into any of the PPVPN working
group drafts.

-- David


From owner-mpls@UU.NET  Fri Jun 14 15:31:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12429
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 15:31:23 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtgg17713
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 19:31:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtgg14422;
	Fri, 14 Jun 2002 19:30:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtgg29391
	for mpls-outgoing; Fri, 14 Jun 2002 19:30:00 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtgf29384
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 14 Jun 2002 19:29:46 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtgf20021
	for <mpls@UU.NET>; Fri, 14 Jun 2002 19:29:25 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtgf14006
	for <mpls@UU.NET>; Fri, 14 Jun 2002 19:29:24 GMT
Received: from mail2.hd.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hdfdns02.hd.intel.com [192.52.58.11])
	id QQmtgf13995
	for <mpls@UU.NET>; Fri, 14 Jun 2002 19:29:23 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5EJTLq07485
	for <mpls@UU.NET>; Fri, 14 Jun 2002 19:29:21 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061412292308640
 ; Fri, 14 Jun 2002 12:29:23 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <M7D9495P>; Fri, 14 Jun 2002 12:29:15 -0700
Message-ID: <9678C2B4D848D41187450090276D1FAE0BC30200@fmsmsx32.fm.intel.com>
From: "Sharma, Prashant" <prashant_sharma@trillium.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Cc: "'eric.gray@sandburst.com'" <eric.gray@sandburst.com>
Subject: Basic LDP question...
Date: Fri, 14 Jun 2002 12:29:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

    I have one basic question in handling of label request message. LRq.2
states that "Is there next hop for FEC ?". My question is what should be the
LSR behavior when there is next hop for FEC (as per routing module) but
there is NO LDP session with the next hop node. 

   In such cases, should we consider ourself as EGRESS node and send Label
Mapping to upstream node (for both independent and ordered case)? Or we
should interpret this as a failure of LRq.2 and send Notification to the
upstream node (again for both independent and ordered case) ?

  Similarly, what should be LDP behavior when recognize new FEC procedure is
executed and there is NO LDP session with next hop node.
Should we consider ourself as EGRESS node (till the time session with next
hop is up)? Or we should consider ourself as "intermediate" node always, no
matter session with next hop is up or down?

  Thanks in advance.

Regards
Prashant.
  


From owner-mpls@UU.NET  Fri Jun 14 21:04:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20512
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 21:04:57 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthc11866
	for <mpls-archive@lists.ietf.org>; Sat, 15 Jun 2002 01:05:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmthc09624;
	Sat, 15 Jun 2002 01:04:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmthc21584
	for mpls-outgoing; Sat, 15 Jun 2002 01:04:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmthc21577
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Jun 2002 01:04:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmthc19188
	for <mpls@UU.NET>; Sat, 15 Jun 2002 01:02:57 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthc07435
	for <mpls@UU.NET>; Sat, 15 Jun 2002 01:02:56 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f3.law15.hotmail.com [64.4.23.3])
	id QQmthc07430
	for <mpls@UU.NET>; Sat, 15 Jun 2002 01:02:56 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 14 Jun 2002 18:02:55 -0700
Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP;
	Sat, 15 Jun 2002 01:02:55 GMT
X-Originating-IP: [12.234.67.129]
From: "Chetan Pinto" <chetanpinto@hotmail.com>
To: prashant_sharma@trillium.com, mpls@UU.NET
Cc: eric.gray@sandburst.com
Subject: Re: Basic LDP question...
Date: Fri, 14 Jun 2002 18:02:55 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F3dtMXFCJd8gOhhaqYO000273b6@hotmail.com>
X-OriginalArrivalTime: 15 Jun 2002 01:02:55.0622 (UTC) FILETIME=[61FF7260:01C21408]
Sender: owner-mpls@UU.NET
Precedence: bulk

>Hi All,
>
>     I have one basic question in handling of label request message. LRq.2
>states that "Is there next hop for FEC ?". My question is what should be 
>the
>LSR behavior when there is next hop for FEC (as per routing module) but
>there is NO LDP session with the next hop node.
>
>    In such cases, should we consider ourself as EGRESS node and send Label
>Mapping to upstream node (for both independent and ordered case)?

Yeah, the node should act as a Proxy-Egress

>Or we
>should interpret this as a failure of LRq.2 and send Notification to the
>upstream node (again for both independent and ordered case) ?

No

>   Similarly, what should be LDP behavior when recognize new FEC procedure 
>is
>executed and there is NO LDP session with next hop node.
>Should we consider ourself as EGRESS node (till the time session with next
>hop is up)? Or we should consider ourself as "intermediate" node always, no
>matter session with next hop is up or down?

Again act as a proxy-egress


>
>   Thanks in advance.
>
>Regards
>Prashant.
>


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From owner-mpls@UU.NET  Fri Jun 14 22:20:26 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21797
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 22:20:26 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthh19928
	for <mpls-archive@lists.ietf.org>; Sat, 15 Jun 2002 02:20:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmthh16795;
	Sat, 15 Jun 2002 02:19:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmthh27601
	for mpls-outgoing; Sat, 15 Jun 2002 02:18:51 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmthh27596
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Jun 2002 02:18:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmthh07214
	for <mpls@uu.net>; Sat, 15 Jun 2002 02:16:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthh14515
	for <mpls@uu.net>; Sat, 15 Jun 2002 02:16:16 GMT
Received: from mail6.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe6.southeast.rr.com [24.93.67.53])
	id QQmthh14511
	for <mpls@uu.net>; Sat, 15 Jun 2002 02:16:16 GMT
Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC;
	 Fri, 14 Jun 2002 22:13:55 -0400
Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Tue, 11 Jun 2002 20:14:34 -0400
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5C0EXbC023711
	for <pholz@nc.rr.com>; Tue, 11 Jun 2002 20:14:33 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvw03664
	for <pholz@nc.rr.com>; Wed, 12 Jun 2002 00:14:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsvw29338;
	Wed, 12 Jun 2002 00:12:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsvw00314
	for mpls-outgoing; Wed, 12 Jun 2002 00:10:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsvw00201
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 12 Jun 2002 00:10:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsvw06657
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:43 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsvw26018
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:43 GMT
Received: from evl.uic.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: evl.evl.uic.edu [131.193.48.80])
	id QQmsvw26014
	for <mpls@UU.NET>; Wed, 12 Jun 2002 00:09:42 GMT
Received: from ericpc (evl-79dhcp210.evl.uic.edu [131.193.79.210])
	by evl.uic.edu (8.9.3/8.9.3) with SMTP id TAA18781;
	Tue, 11 Jun 2002 19:09:39 -0500 (CDT)
Message-ID: <007101c211b6$40160460$d24fc183@evl.uic.edu>
From: "Eric He" <eric@evl.uic.edu>
To: "Fred Baker" <fred@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
References: <5.1.1.6.2.20020610154839.01a49378@mira-sjcm-4.cisco.com>
Subject: Re: Microflow level QoS implemented by GMPLS
Date: Tue, 11 Jun 2002 19:09:56 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks a lot!  Helped me a lot!

Sorry for some maybe off-topic questions.
So the understanding is that Integrated Serivce is still necessary for
Microflow level QoS in even MPLambdaS enabled network.
(1) Is Integrated Service practical and easy to deploy in research network?
Is there any academic or industrial solution?  I did some research and seems
IntServ is kinda obsolete.  DiffServ is more scalable but in research
network with fewer users I think scalability is not a problem.
(2) Any research is undergoing on the interaction of Integrated Service and
GMPLS?

Thanks again!
Eric He
----- Original Message -----
From: "Fred Baker" <fred@cisco.com>
To: "Eric He" <eric@evl.uic.edu>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Sent: Monday, June 10, 2002 3:54 PM
Subject: Re: Microflow level QoS implemented by GMPLS


> At 05:36 PM 6/10/2002 -0700, Eric He wrote:
> >Integrated Service is used to implement end-to-end microflow level in
> >IP-based network.  But if we can create a host-to-host lightpath using
> >GMPLS, is Integrated Service still necessary to ensure end-to-end Quality
> >of Service? Any comments are more than welcome!
>
> if it's literally light, done with mirrors, there are no queues, and
> configuring queues is unnecessary. You still have the question of whether
> the amount of bandwidth used by the telephone traffic exceeds the amount
> permitted by policy, or if there is no policy, the amount of bandwidth
> available.
>
> If it an OEO solution, you still have the distinct possibility of queues
> forming in the network, and there are questions there.
>
> The lightpath will almost certainly be part of an end-to-end solution; at
> least my PC doesn't have a fiber output on the back, and the hotel room I
> stayed in a few nights ago lacked an optical connection. You also need to
> address the end to end solution even if the optical portion of it is
solved.
>
> In short, there is still no magic. You can massively overprovision so that
> there is no case in which traffic engineering is relevant; in such a case,
> your part of the network probably has no current requirement, either for
> QoS or for traffic engineering. If you don't, you have to think about the
> effects of your network on the applications using it.
>


From owner-mpls@UU.NET  Fri Jun 14 23:14:34 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23161
	for <mpls-archive@lists.ietf.org>; Fri, 14 Jun 2002 23:14:34 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthl19954
	for <mpls-archive@lists.ietf.org>; Sat, 15 Jun 2002 03:15:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmthk16456;
	Sat, 15 Jun 2002 03:12:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmthk23600
	for mpls-outgoing; Sat, 15 Jun 2002 03:12:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmthk23593
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 15 Jun 2002 03:12:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmthk19146
	for <mpls@uu.net>; Sat, 15 Jun 2002 03:12:05 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmthk16126
	for <mpls@uu.net>; Sat, 15 Jun 2002 03:12:04 GMT
Received: from mail6.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fe6.southeast.rr.com [24.93.67.53])
	id QQmthk16122
	for <mpls@uu.net>; Sat, 15 Jun 2002 03:12:04 GMT
Received: from mail pickup service by mail6.nc.rr.com with Microsoft SMTPSVC;
	 Fri, 14 Jun 2002 23:09:45 -0400
Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail6.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.757.75);
	 Mon, 10 Jun 2002 12:34:58 -0400
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AGYvtH003822
	for <jimpb@nc.rr.com>; Mon, 10 Jun 2002 12:34:57 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsra04732
	for <jimpb@nc.rr.com>; Mon, 10 Jun 2002 16:34:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmsra03938;
	Mon, 10 Jun 2002 16:34:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmsra26769
	for mpls-outgoing; Mon, 10 Jun 2002 16:32:45 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmsra26762
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 10 Jun 2002 16:32:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmsra19750
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmsra00687
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from smtp1.opnet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.opnet.com [141.156.71.6])
	id QQmsra00678
	for <mpls@uu.net>; Mon, 10 Jun 2002 16:32:23 GMT
Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id <T5b666b688eac10010f39c@smtp1.opnet.com>;
 Mon, 10 Jun 2002 12:32:19 -0400
Message-Id: <5.1.0.14.2.20020610122952.0933c650@mail.opnet.com>
X-Sender: svenkatachalam@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Jun 2002 12:32:18 -0400
To: "Hong Liao" <hliao@telcordia.com>, mpls@UU.NET
From: "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
Subject: Re: Can someone answer my question?
In-Reply-To: <OFD6DE97A3.D1BFBD20-ON85256BD4.0051EF4A@cc.telcordia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 10:55 AM 6/10/2002 -0400, Hong Liao wrote:
>Hi,
>
>I have question for the rsvpte.
>
>In the rfc 2205,  in the ERROR_SPEC class, the Error Node Address ---- the
>IP address of the node in which the error was detected.
>
>Here the IP address of the node is the router id or interface IP address?

It could be either the IP address of the interface or the loopback address
("router address") of the router, depending on the implementation.
You can't make the assumption that it is the interface address or that it
is the "router address".

Regards,
Senthil.

>  For instance the intermediate lsr all the interfaces connected to the
>router belong to that node.
>
>Thanks in an advance.
>
>Julia


From owner-mpls@UU.NET  Sun Jun 16 09:18:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02434
	for <mpls-archive@lists.ietf.org>; Sun, 16 Jun 2002 09:18:22 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtmr09229
	for <mpls-archive@lists.ietf.org>; Sun, 16 Jun 2002 13:18:56 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtmr06873;
	Sun, 16 Jun 2002 13:17:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtmr24046
	for mpls-outgoing; Sun, 16 Jun 2002 13:17:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtmr24034
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Jun 2002 13:17:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtmr00658
	for <mpls@UU.NET>; Sun, 16 Jun 2002 13:16:35 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtmr00213
	for <mpls@UU.NET>; Sun, 16 Jun 2002 13:16:35 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQmtmr00209
	for <mpls@UU.NET>; Sun, 16 Jun 2002 13:16:33 GMT
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g5GDGVe23318
	for <mpls@UU.NET>; Sun, 16 Jun 2002 18:46:32 +0530 (IST)
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GXSVJD00.J30; Sun, 16 Jun 2002 18:46:25 +0530 
Received: from boochi.wipro.com ([10.117.3.144]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id SAA17218; Sun, 16 Jun 2002 18:46:30 +0530
Date: Sun, 16 Jun 2002 18:54:33 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.wipro.com>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: Chetan Pinto <chetanpinto@hotmail.com>
cc: <prashant_sharma@trillium.com>, <mpls@UU.NET>, <eric.gray@sandburst.com>
Subject: Re: Basic LDP question...
In-Reply-To: <F3dtMXFCJd8gOhhaqYO000273b6@hotmail.com>
Message-ID: <Pine.LNX.4.31.0206161808100.30391-100000@boochi.wipro.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id JAA02434

Hi,
  I have a point regarding the Proxy-Egress case. Just the point that you
don't have a session with the next hop peer shouldn't make you behave as a
proxy egress. You should also have a knowledge of your switch
capabilities (may be by means of some configuration), whether it can do
the IP forwarding or not. Also it may be necessary to know apriori for
what prefixes I can act as proxy-egress. This becomes more significant an
issue in case of CR-LDP where just like that you can't become a proxy
egress and terminate the Constrained paths which may not satisfy the
required service guaranties.

regards
Bhushana


On Fri, 14 Jun 2002, Chetan Pinto wrote:

> >Hi All,
> >
> >     I have one basic question in handling of label request message. LRq.2
> >states that "Is there next hop for FEC ?". My question is what should be
> >the
> >LSR behavior when there is next hop for FEC (as per routing module) but
> >there is NO LDP session with the next hop node.
> >
> >    In such cases, should we consider ourself as EGRESS node and send Label
> >Mapping to upstream node (for both independent and ordered case)?
>
> Yeah, the node should act as a Proxy-Egress
>
> >Or we
> >should interpret this as a failure of LRq.2 and send Notification to the
> >upstream node (again for both independent and ordered case) ?
>
> No
>
> >   Similarly, what should be LDP behavior when recognize new FEC procedure
> >is
> >executed and there is NO LDP session with next hop node.
> >Should we consider ourself as EGRESS node (till the time session with next
> >hop is up)? Or we should consider ourself as "intermediate" node always, no
> >matter session with next hop is up or down?
>
> Again act as a proxy-egress
>
>
> >
> >   Thanks in advance.
> >
> >Regards
> >Prashant.
> >
>
>
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>



From owner-mpls@UU.NET  Sun Jun 16 16:44:31 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07808
	for <mpls-archive@lists.ietf.org>; Sun, 16 Jun 2002 16:44:30 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtnv03695
	for <mpls-archive@lists.ietf.org>; Sun, 16 Jun 2002 20:45:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtnu00903;
	Sun, 16 Jun 2002 20:43:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtnu00025
	for mpls-outgoing; Sun, 16 Jun 2002 20:43:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtnu00011
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 16 Jun 2002 20:43:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtnu19036
	for <mpls@UU.NET>; Sun, 16 Jun 2002 20:43:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtnu06467
	for <mpls@UU.NET>; Sun, 16 Jun 2002 20:43:04 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f180.law15.hotmail.com [64.4.23.180])
	id QQmtnu06461
	for <mpls@UU.NET>; Sun, 16 Jun 2002 20:43:03 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 16 Jun 2002 13:43:02 -0700
Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP;
	Sun, 16 Jun 2002 20:43:02 GMT
X-Originating-IP: [12.234.67.129]
From: "Chetan Pinto" <chetanpinto@hotmail.com>
To: nagabhushana.ramaswamy@wipro.com
Cc: prashant_sharma@trillium.com, mpls@UU.NET, eric.gray@sandburst.com
Subject: Re: Basic LDP question...
Date: Sun, 16 Jun 2002 13:43:02 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F180iSnuQsKVVyghTGG000223d5@hotmail.com>
X-OriginalArrivalTime: 16 Jun 2002 20:43:02.0987 (UTC) FILETIME=[68E3A9B0:01C21576]
Sender: owner-mpls@UU.NET
Precedence: bulk

>Hi,
>   I have a point regarding the Proxy-Egress case. Just the point that you
>don't have a session with the next hop peer shouldn't make you behave as a
>proxy egress. You should also have a knowledge of your switch
>capabilities (may be by means of some configuration), whether it can do
>the IP forwarding or not. Also it may be necessary to know apriori for
>what prefixes I can act as proxy-egress.

Agreed that Proxy egressing should be configurable.
But why does the question "if the switch is capable of IP forwarding"
comes into picture. Isn't it a paradox? If the switch is sending
routing updates to the upstream routing peers , then it needs to take
care of the downstream traffic. Am I missing something(s) here?

>This becomes more significant an
>issue in case of CR-LDP where just like that you can't become a proxy
>egress and terminate the Constrained paths which may not satisfy the
>required service guaranties.

Implicit behaviour of CR-LSPs, but vanilla LSPs shouldn't have an issue

Thanks
chetan

>
>regards
>Bhushana
>
>
>On Fri, 14 Jun 2002, Chetan Pinto wrote:
>
> > >Hi All,
> > >
> > >     I have one basic question in handling of label request message. 
>LRq.2
> > >states that "Is there next hop for FEC ?". My question is what should 
>be
> > >the
> > >LSR behavior when there is next hop for FEC (as per routing module) but
> > >there is NO LDP session with the next hop node.
> > >
> > >    In such cases, should we consider ourself as EGRESS node and send 
>Label
> > >Mapping to upstream node (for both independent and ordered case)?
> >
> > Yeah, the node should act as a Proxy-Egress
> >
> > >Or we
> > >should interpret this as a failure of LRq.2 and send Notification to 
>the
> > >upstream node (again for both independent and ordered case) ?
> >
> > No
> >
> > >   Similarly, what should be LDP behavior when recognize new FEC 
>procedure
> > >is
> > >executed and there is NO LDP session with next hop node.
> > >Should we consider ourself as EGRESS node (till the time session with 
>next
> > >hop is up)? Or we should consider ourself as "intermediate" node 
>always, no
> > >matter session with next hop is up or down?
> >
> > Again act as a proxy-egress
> >
> >
> > >
> > >   Thanks in advance.
> > >
> > >Regards
> > >Prashant.
> > >
> >
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com
> >
> >


############################################################
Chetan Francis Pinto
Phone : Res : 408-244-1352
############################################################

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



From owner-mpls@UU.NET  Mon Jun 17 08:56:25 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29700
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 08:56:25 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqh17870
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 12:56:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqh14763;
	Mon, 17 Jun 2002 12:55:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqh04366
	for mpls-outgoing; Mon, 17 Jun 2002 12:55:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtqh04358
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 12:55:04 GMT
Received: from imr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqh29381
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 12:53:31 GMT
Received: from dgismtp03.wcomnet.com by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dgismtp03.wcomnet.com [166.38.58.143])
	id QQmtqh29368
	for <mpls@UU.NET>; Mon, 17 Jun 2002 12:53:31 GMT
Received: from CONVERSION-DAEMON.dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 id <0GXU00H01P1AX4@dgismtp03.wcomnet.com> for mpls@UU.NET; Mon,
 17 Jun 2002 12:53:31 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0GXU00I01P564L@dgismtp03.wcomnet.com> for mpls@UU.NET; Mon,
 17 Jun 2002 12:53:31 +0000 (GMT)
Received: from dmcdysan ([166.32.198.25])
 by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with SMTP id <0GXU00HB1P56EQ@dgismtp03.wcomnet.com>; Mon,
 17 Jun 2002 12:53:30 +0000 (GMT)
Date: Mon, 17 Jun 2002 08:55:37 -0400
From: Dave McDysan <dave.mcdysan@wcom.com>
Subject: Reminder - Call for Presentations for  MPLS 2002: Oct. 27-29,
 Washington D.C.
To: Ppvpn <ppvpn@ppvpn.francetelecom.com>, Ccamp <ccamp@ops.ietf.org>,
        Mpls <mpls@UU.NET>, Pwe3 <pwe3@ietf.org>
Message-id: <NBBBLDAKOPKFLNKDGDLGOEDLHFAA.dave.mcdysan@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Colleagues,

The MPLS 2002 Conference will be held in Washington D.C. from October 27
through October 29. See www.mpls2002.com for more information.

A group of industry experts on the Technical Program Committee is soliciting
presentation proposals for this conference. This note is a reminder that if
you wish to suggest a particular topic or a contribution please send a brief
proposal to the attention of the Technical Program Committee at
TPC@mpls2002.com by June 21, 2002. See above web site for more details.

The program committee is looking for original and unpublished work to
continue the tradition initiated by this conference in 1998 of covering
cutting edge topics. They are solicting presentations from both the vendor
and service provider community on new technologies and operational
experience.

Regards,

David E. McDysan
WorldCom



From owner-mpls@UU.NET  Mon Jun 17 09:12:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00802
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 09:12:58 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqi14581
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:13:29 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqi12798;
	Mon, 17 Jun 2002 13:12:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqi27707
	for mpls-outgoing; Mon, 17 Jun 2002 13:12:23 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtqi27694
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 13:12:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtqi19320
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:11:47 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqi15290
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:11:46 GMT
Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQmtqi15263
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:11:46 GMT
Received: from utfors.se ([195.58.105.105]) by
          tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP
          id GXUQ7U00.DHJ; Mon, 17 Jun 2002 15:16:42 +0200 
Message-ID: <3D0DE005.1010509@utfors.se>
Date: Mon, 17 Jun 2002 15:11:33 +0200
From: Loa Andersson <loa.andersson@utfors.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mpls wg <mpls@UU.NET>, George Swallow <swallow@cisco.com>,
        Scott Bradner <sob@harvard.edu>
Subject: reminder if you have asked for or will ask for an agenda slot in Yokohama
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

All,

just a short reminder to those who have or are requesting agenda
slots at the MPLS WG in Yokohama. Please consider this when you
prepare for the meeting.



         It is not the purpose of a WG session to have
         presentation of the content of a document. It
         is assumed that all attendees will have read the
         drafts in advance of the meeting.

         For documents that are work-in-progress, the
         presentation should cover issues resolved since
         the last draft followed by open issues and
         controversial topics with the intent to reach a
         resolution of said issues and topics.

         For new work items, the presentation should focus on
         what the problem is and why it is necessary for the
         work group to address it.  Further it should be either
         shown how it falls within the existing charter or why
         and how the charter should be extended to encompass it.
         The solution should only be sketched.

         The appropriate way of bringing new work to the working
         group is to send a draft to the mailing list and promoting
         discussion on the list. Slots on the agenda should be used
         to discuss outstanding topics that has not be solved on the
         mailing list.

         For new proposals addressing issues where
         work-in-progess the presentation should focus
         on the (perceived) short-fallings of the existing
         work and why those issues need to be addressed
         both in terms of why they are required and why they
         cannot be addressed in the existing work.
         the new work must be related to existing work (i.e.
         compatible, mutually exclusive, outright replacement).
         Finally, the new solution should be skechted,
         explaining how the solution overcomes those issues.
         The primary purpose of this last part is to allow commentary
         from the floor, it should not be orientented toward selling
         the idea.

         In all cases only a limited number of slides should be used.
         Speakers should budget their at least 25% of their time to
         allow for questions.

Loa and George

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se



From owner-mpls@UU.NET  Mon Jun 17 09:59:04 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03495
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 09:59:04 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtql16161
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:59:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtql15505;
	Mon, 17 Jun 2002 13:59:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtql02593
	for mpls-outgoing; Mon, 17 Jun 2002 13:59:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtql02543
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 13:59:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtql21124
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:58:40 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtql24081
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:58:40 GMT
Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQmtql24071
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:58:39 GMT
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5HDwZa05190;
	Mon, 17 Jun 2002 09:58:36 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYB4YXJ>; Mon, 17 Jun 2002 09:58:35 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3403BC591C@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Loa Andersson <loa.andersson@utfors.se>, mpls wg <mpls@UU.NET>,
        George Swallow <swallow@cisco.com>, Scott Bradner <sob@harvard.edu>
Subject: RE: reminder if you have asked for or will ask for an agenda slot
	 in Yokohama
Date: Mon, 17 Jun 2002 09:58:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C21607.11E199D8"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21607.11E199D8
Content-Type: text/plain;
	charset="iso-8859-1"

Loa:

I'd suggest keeping about 10 minutes aside for any liaison response from the
ITU-T on the OAM stuff.

rgds
Dave
 

------_=_NextPart_001_01C21607.11E199D8
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: reminder if you have asked for or will ask for an agenda slot in Yokohama</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Loa:</FONT>
</P>

<P><FONT SIZE=2>I'd suggest keeping about 10 minutes aside for any liaison response from the ITU-T on the OAM stuff.</FONT>
</P>

<P><FONT SIZE=2>rgds</FONT>
<BR><FONT SIZE=2>Dave</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C21607.11E199D8--


From owner-mpls@UU.NET  Mon Jun 17 10:12:11 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04236
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 10:12:11 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqm03637
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 14:12:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqm00411;
	Mon, 17 Jun 2002 14:11:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqm25185
	for mpls-outgoing; Mon, 17 Jun 2002 14:10:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtqm25093
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 14:10:17 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtqm16040
	for <mpls@uu.net>; Mon, 17 Jun 2002 14:09:26 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqm29493
	for <mpls@uu.net>; Mon, 17 Jun 2002 14:09:26 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtqm29483
	for <mpls@uu.net>; Mon, 17 Jun 2002 14:09:26 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA22175 for <mpls@uu.net>; Mon, 17 Jun 2002 10:09:25 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13560 for mpls@uu.net; Mon, 17 Jun 2002 10:09:25 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtqk29789
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 13:36:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtqk21338
	for <mpls@uu.net>; Mon, 17 Jun 2002 13:35:42 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqk12277
	for <mpls@uu.net>; Mon, 17 Jun 2002 13:35:41 GMT
Received: from mail.site.uottawa.ca by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142])
	id QQmtqk12261
	for <mpls@uu.net>; Mon, 17 Jun 2002 13:35:41 GMT
Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149])
	by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id JAA30965
	for <mpls@uu.net>; Mon, 17 Jun 2002 09:35:40 -0400 (EDT)
Message-ID: <000b01c21603$c2753790$955b7a89@bwwil28>
From: "Bin Zhou" <binzhou@site.uottawa.ca>
To: <mpls@UU.NET>
Subject: RSVP-TE:  How to use "Tunnel Sender Address"?
Date: Mon, 17 Jun 2002 09:34:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

In RFC3209, there are two similar fields:
1. Extended Tunnel ID in Session Object, and
2. IPv4 Tunnel Sender Address in Sender_template Object.

The meaning of these two fields are defined as in the following.
Extended Tunnel ID: Ingress IP address
IPv4 Tunnel Sender Address: IP address of sender node

I think that the ingress node of a tunnel is the same as the sender of the
tunnel. Is it right? If so, why define two field for the same purpose? How
to use the Tunnel Sender Address?

Thanks for your answer in advance.

Bin




From owner-mpls@UU.NET  Mon Jun 17 11:49:12 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08374
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 11:49:12 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqt13025
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 15:49:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqt11247;
	Mon, 17 Jun 2002 15:49:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqt25693
	for mpls-outgoing; Mon, 17 Jun 2002 15:48:47 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtqt25688
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 15:48:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtqt12557
	for <mpls@UU.NET>; Mon, 17 Jun 2002 15:48:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqt10431
	for <mpls@UU.NET>; Mon, 17 Jun 2002 15:48:17 GMT
Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50])
	id QQmtqt10422
	for <mpls@UU.NET>; Mon, 17 Jun 2002 15:48:17 GMT
Received: from tropicnetworks.com ([10.1.5.113]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Mon, 17 Jun 2002 11:48:11 -0400
Message-ID: <3D0E04BB.F37AAE52@tropicnetworks.com>
Date: Mon, 17 Jun 2002 11:48:11 -0400
From: Nabil Seddigh <nseddigh@tropicnetworks.com>
Organization: Tropic Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
CC: mpls@UU.NET
Subject: Re: Issues with draft-ietf-mpls-lsp-ping-00.txt
References: <4.3.2.7.2.20020613112257.0248cb50@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Jun 2002 15:48:11.0510 (UTC) FILETIME=[625C4160:01C21616]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Tom,

But the problem is that for a single box, you now have 
regular icmp ping (routed in the forward path), icmp ping
sent over an lsp and what you are terming mpls ping.
I have been in numerous meetings where the three terms are
easily confused. It seems easy enough to distinguish the
first two by just saying ping vs lsp ping. The distinction
between mpls ping and lsp ping is not so clear especially 
since it incorporates traceroute as well.

Aren't there others who have found this problem?

Nabil Seddigh


> >
> >1. Suggest finding a better name for this application than
> >    "MPLS Ping". This is for two reasons. First, the app can
> >    actually operate in both Ping and TraceRoute modes and
> >    2nd, vendors have icmp echo req and reply running over lsps
> >    and sometimes call that lsp ping which is easily confusable
> >    with mpls ping. Maybe something like MPLS liveliness or
> >    another new term would solve this problem?
> 
>          I personally like MPLS ping for the simple reason that intuitively
> this is what it does and this is how people will use it. MPLS ping
> just has the extra feature of traceroute.  I don't think that the ICMP
> ping is an issue.
> 
>          --Tom
>


From owner-mpls@UU.NET  Mon Jun 17 12:01:08 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08868
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 12:01:08 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqu08947
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 16:01:35 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqt05924;
	Mon, 17 Jun 2002 15:59:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqt26432
	for mpls-outgoing; Mon, 17 Jun 2002 15:59:26 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtqt26427
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 15:59:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtqt26826
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:58:04 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqt05075
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:58:04 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtqt05071
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:58:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29400 for <mpls@uu.net>; Mon, 17 Jun 2002 11:58:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA25573 for mpls@uu.net; Mon, 17 Jun 2002 11:58:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtqt26375
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 15:57:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtqt07678
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:57:11 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqt23743
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:57:11 GMT
Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQmtqt23737
	for <mpls@uu.net>; Mon, 17 Jun 2002 15:57:10 GMT
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5HFv9p29994
	for <mpls@uu.net>; Mon, 17 Jun 2002 11:57:09 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA06592; Mon, 17 Jun 2002 17:57:07 +0200 (MET DST)
To: <disman@dorothy.bmc.com>, <aaa-wg@merit.edu>, <rmonmib@ietf.org>,
        <policy@ietf.org>, <snmpv3@lists.tislabs.com>, <sming@ops.ietf.org>,
        <mpls@UU.NET>, <mobile-ip@sunroof.eng.sun.com>, <gsmp@ietf.org>,
        <diffserv@ietf.org>, <sip@ietf.org>, <mmusic@ietf.org>
Received: from ouranos by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA06555; Mon, 17 Jun 2002 17:56:49 +0200 (MET DST)
Message-ID: <01de01c21617$a602b790$9981cdd4@ouranos>
Reply-To: "Nikos A. Nikolaou" <nikolaou@lucent.com>
From: "Nikos A. Nikolaou" <nikolaou@lucent.com>
Original-To: <disman@dorothy.bmc.com>, <aaa-wg@merit.edu>, <rmonmib@ietf.org>,
        <policy@ietf.org>, <snmpv3@lists.tislabs.com>, <sming@ops.ietf.org>,
        <mpls@uu.net>, <mobile-ip@sunroof.eng.sun.com>, <gsmp@ietf.org>,
        <diffserv@ietf.org>, <sip@ietf.org>, <mmusic@ietf.org>
Subject: CFP: Special Issue in IEEE Network on Network Management
Date: Mon, 17 Jun 2002 18:57:04 +0300
Organization: Lucent Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

My apologies if you receive multiple copies of this.

A pdf version of this CFP will be available soon at
http://www.comsoc.org/pubs/net/ntwrk/special.html

Kind regards,
Nikos A. Nikolaou


-------------------------------------------------------------------------------
                        Call For Papers
                IEEE Network Magazine Special Issue on
    Network Management of Multi-service, Multimedia, IP-based Networks

Guest Editors

Dr. Nikolaos Nikolaou                   Dr. Theodore Zahariadis
Lucent Technologies                     Networking & Multimedia Systems
Bell Labs - AT, EMEA                    Ellemedia Technologies
Botterstraat 45                         Syggrou 223,
1270 AA, Huizen,                        171 21, Athens
The Netherlands                         Greece
Tel: +31 - 35 - 687 5302                Tel: +30 - 10 - 937 3097
Email: nikolaou@lucent.com              Email: zahariad@ellemedia.com

Prof. Joan Serrat                       Dr. Bharat Doshi
Telecommunication Engineering           Lucent Technologies
Universitat Politecnica de Catalunya    Bell Labs
Sor Eulalia d'Anzizu, s/n,              101 Crawfords Corner Rd,
08034, Barcelona,                       Holmdel, NJ  07733
Spain                                   USA
Tel: +34 - 93 - 401 6786                Tel: +1732 949 0823
Email: serrat@tsc.upc.es                Email: bdoshi@lucent.com


Objectives

During the last decade, innovations concerning optical networking technology, as
well as advances in digital compression and transmission over copper and cable
have dramatically increased the capabilities and the efficiency of existing and
imminent access-, metropolitan- and core-networks. A major breakthrough in
communications was the fast deployment of cellular systems. Currently, 3G
wireless systems, targeting the transmission of voice, video and high-speed
data, are already under preliminary deployment. Furthermore, researchers and
vendors are expressing a growing interest in 4G wireless systems that will
support even higher rates and cater for global roaming across multiple wireless
networks.

Meanwhile, based on the TCP/IP protocol suite, the Internet has evolved from a
research network, targeting a limited audience of academic and military users,
to a huge and commercially operated network. Next-generation IP technology has
the potential to prevail, both in the access and in the core, as we are moving
toward a worldwide, multi-service, multimedia and high-speed networking
environment. The explosion of IP-based multimedia applications led to an
exponential growth of IP traffic and initiated a number of research activities
that would allow efficient Quality of Service (QoS) support. Additionally, the
issue of security became more important and acquired considerable attention
owing to the proliferation of IP-based Virtual Private Networks (VPNs).

However, apart from efficient compression, sophisticated transmission schemes
and support for QoS, mobility and security, contemporary networking applications
require significant functionality for management operations, ensuring that the
underlining network is both available and capable of supporting the service
uninterruptedly. Configuration, performance and fault management over
heterogeneous underlying technologies and multi-layered networks, along with
end-to-end QoS, traffic management, service control platforms, billing and
mobility management are also crucial components of multi-service and high-speed
IP-based networks.

The goal of this special issue in IEEE Network Magazine is to present to the
magazine's audience (1) a comprehensive study of the design, performance and
deployment issues and solutions of end-to-end network management over
multi-domain, multi-technology, IP-based networks, and (2) a consolidated
insight into ongoing research, development and trials' evaluation of network
management technologies and platforms, broadening future research directions. To
achieve this goal, this special issue seeks for original papers with strong
tutorial and/or survey perspective that will consolidate and present the
leading-edge research prototype development, trials and early deployment and
performance studies in Network Management of multi-service, multimedia, IP-based
networks.


Topics

In particular, focused tutorial and survey contributions are solicited on (but
not restricted to) the following areas:
* End-to-end IP multimedia network and service management
* VoIP, IP Video, streaming, interactive video service management
* Provisioning of multimedia networks and services
* Wireless LAN and 3G/4G mobile multimedia network management
* Management of terminal and network mobility
* Inter-domain IP over WDM multimedia network management
* Network management models and architectures
* Management issues for billing and security for IP multimedia services
* Multi-domain, multi-point, multicast services management
* Policy-based management for multimedia services
* Performance and Fault Management of Multi-layered Networks
* QoS management
* Multimedia traffic management
* Active multimedia network management
* Middleware support for management


Manuscript Submission

Interested authors should submit an electronic version of the manuscript, in
either Postscript or PDF format, as an email attachment to one of the guest
editors.

Additional information including "Guidelines for authors" is available at the
IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html


Important Dates

Submission Deadline:            October 1, 2002
Notification of Acceptance:     December 21, 2002
Final Manuscript Due:           March 1, 2003
Publication Date:               May/June 2003
-------------------------------------------------------------------------------



From owner-mpls@UU.NET  Mon Jun 17 12:55:43 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11293
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 12:55:43 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqx16872
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 16:56:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqx12216;
	Mon, 17 Jun 2002 16:54:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqx22901
	for mpls-outgoing; Mon, 17 Jun 2002 16:53:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtqx22892
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 16:53:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtqx17731
	for <mpls@uu.net>; Mon, 17 Jun 2002 16:53:21 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqx02114
	for <mpls@uu.net>; Mon, 17 Jun 2002 16:53:21 GMT
Received: from smtp1.opnet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.opnet.com [141.156.71.6])
	id QQmtqx02109
	for <mpls@uu.net>; Mon, 17 Jun 2002 16:53:20 GMT
Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com
 (Content Technologies SMTPRS 4.2.10) with ESMTP id <T5b8a8af1c5ac10010f39c@smtp1.opnet.com>;
 Mon, 17 Jun 2002 12:53:05 -0400
Message-Id: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com>
X-Sender: svenkatachalam@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 17 Jun 2002 12:53:05 -0400
To: <mpls@UU.NET>, "Bin Zhou" <binzhou@site.uottawa.ca>
From: "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
In-Reply-To: <000b01c21603$c2753790$955b7a89@bwwil28>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:34 AM 6/17/2002 -0400, you wrote:
>Hi,
>
>In RFC3209, there are two similar fields:
>1. Extended Tunnel ID in Session Object, and
>2. IPv4 Tunnel Sender Address in Sender_template Object.
>
>The meaning of these two fields are defined as in the following.
>Extended Tunnel ID: Ingress IP address
>IPv4 Tunnel Sender Address: IP address of sender node
>
>I think that the ingress node of a tunnel is the same as the sender of the
>tunnel. Is it right?

Yes.

>If so, why define two field for the same purpose? How
>to use the Tunnel Sender Address?

Extended Tunnel ID was *ment* as an additional key to specify the tunnel/lsp
between two nodes. This is in addition to the (Src, Dst, Tunnel, LSP-id)
quadruple.

A popular way to fill this field is to use the src IP address of the LSP.
However, this behavior is not mandatory.

Regards,
Senthil.

>Thanks for your answer in advance.
>
>Bin



From owner-mpls@UU.NET  Mon Jun 17 13:11:50 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12012
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:11:49 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqy15595
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 17:12:25 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqy13596;
	Mon, 17 Jun 2002 17:11:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqy16133
	for mpls-outgoing; Mon, 17 Jun 2002 17:11:20 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtqy16128
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 17:11:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtqy09676
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:10:38 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqy09895
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:10:38 GMT
Received: from mail.site.uottawa.ca by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142])
	id QQmtqy09891
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:10:38 GMT
Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149])
	by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id NAA41956;
	Mon, 17 Jun 2002 13:10:36 -0400 (EDT)
Message-ID: <002d01c21621$c954e0b0$955b7a89@bwwil28>
From: "Bin Zhou" <binzhou@site.uottawa.ca>
To: <mpls@UU.NET>, "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
Date: Mon, 17 Jun 2002 13:09:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks. Senthil.

In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src can be
provided either by Extended Tunnel ID field or Tunnel Sender Address field.

Can I use one of the two fields as a FEC for a host address since there
isn't a FEC element in RSVP-TE?

BTW, I read that guys of fast reroute or route protection are redefining the
Tunnel Sender Address.

Regards,
Bin

> Extended Tunnel ID was *ment* as an additional key to specify the
tunnel/lsp
> between two nodes. This is in addition to the (Src, Dst, Tunnel, LSP-id)
> quadruple.
>
> A popular way to fill this field is to use the src IP address of the LSP.
> However, this behavior is not mandatory.
>
> Regards,
> Senthil.



From owner-mpls@UU.NET  Mon Jun 17 13:23:44 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12342
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:23:44 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqz01461
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 17:24:19 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqz28871;
	Mon, 17 Jun 2002 17:23:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqz17348
	for mpls-outgoing; Mon, 17 Jun 2002 17:23:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtqz17343
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 17:22:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtqz23176
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:22:44 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqz06905
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:22:44 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtqz06901
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:22:43 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04918
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:22:42 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21219
	for <mpls@UU.NET>; Mon, 17 Jun 2002 13:22:42 -0400 (EDT)
Message-ID: <3D0E1AE1.B74886DE@marconi.com>
Date: Mon, 17 Jun 2002 13:22:41 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <000b01c21603$c2753790$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:
> 
> In RFC3209, there are two similar fields:
> 1. Extended Tunnel ID in Session Object, and
> 2. IPv4 Tunnel Sender Address in Sender_template Object.
> 
> The meaning of these two fields are defined as in the following.
> Extended Tunnel ID: Ingress IP address
> IPv4 Tunnel Sender Address: IP address of sender node
> 
> I think that the ingress node of a tunnel is the same as the
> sender of the tunnel. Is it right? If so, why define two field
> for the same purpose? How to use the Tunnel Sender Address?

They are not necessarily the same.

The sender address in the SENDER_TEMPLATE and FILTER_SPEC objects
actually define the sender.

The extended tunnel ID is a discriminator in order to distinguish
between two sesstions that have the same egress address and have the
same tunnel ID.  Without it, there would have to be an additional
protocol to prevent two different ingress routers from choosing
identical tunnel IDs.

By convention, an address on the ingress router (any address) is chosen
to be the extended tunnel ID - this can guarantee uniqueness.  Any other
method of guaranteeing a unique extended tunnel ID is also valid,
however.

Note also that a zero value for extended tunnel ID is also valid - it is
used when an ingress node wants to allow other ingress nodes to share
its session.  When SE style reservations are used, this will allow LSPs
from different ingress nodes to share resources along common links.

Finally, it should be noted that the LSR MIB does _not_ distinguish
between sender address and extended tunnel ID.  In other words, the MIB
is not capable of describing every possible combination of sessions and
LSPs that RSVP-TE is capable of creating.

-- David


From owner-mpls@UU.NET  Mon Jun 17 13:35:54 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12870
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:35:54 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtra25933
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 17:36:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtra23102;
	Mon, 17 Jun 2002 17:34:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtra18183
	for mpls-outgoing; Mon, 17 Jun 2002 17:34:25 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtra18178
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 17:34:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtra28289
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:32:43 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtra19501
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:32:42 GMT
Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [65.223.109.2])
	id QQmtra19497
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:32:42 GMT
Received: from ipinfusion.com ([10.10.0.225])
	by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g5HHV3Q18038;
	Mon, 17 Jun 2002 10:31:03 -0700
Message-ID: <3D0E1CF1.F5A40123@ipinfusion.com>
Date: Mon, 17 Jun 2002 10:31:29 -0700
From: Yuan Gu <yuangu@ipinfusion.com>
Organization: IP Infusion Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bin Zhou <binzhou@site.uottawa.ca>
CC: mpls@UU.NET, "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:

> Thanks. Senthil.
>
> In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src can be
> provided either by Extended Tunnel ID field or Tunnel Sender Address field.
>
> Can I use one of the two fields as a FEC for a host address since there
> isn't a FEC element in RSVP-TE?

Bin:

Are you trying to send FEC information to intermediate/egress node? FEC is only
known by ingress node when packets need to be classified for LSPs. In
intermediate and egress node, the only way to identify the LSP tunnel in data
plane is LABEL.

Regards!
Yuan


>
>
> BTW, I read that guys of fast reroute or route protection are redefining the
> Tunnel Sender Address.
>
> Regards,
> Bin
>
> > Extended Tunnel ID was *ment* as an additional key to specify the
> tunnel/lsp
> > between two nodes. This is in addition to the (Src, Dst, Tunnel, LSP-id)
> > quadruple.
> >
> > A popular way to fill this field is to use the src IP address of the LSP.
> > However, this behavior is not mandatory.
> >
> > Regards,
> > Senthil.



From owner-mpls@UU.NET  Mon Jun 17 13:41:43 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13206
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:41:43 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqz10626
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 17:26:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtqz08553;
	Mon, 17 Jun 2002 17:26:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtqz17463
	for mpls-outgoing; Mon, 17 Jun 2002 17:25:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtqz17454
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 17:25:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtqz12745
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:25:07 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtqz03115
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:25:03 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtqz02284
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:24:40 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05089;
	Mon, 17 Jun 2002 13:24:35 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21843;
	Mon, 17 Jun 2002 13:24:36 -0400 (EDT)
Message-ID: <3D0E1B53.3EC23367@marconi.com>
Date: Mon, 17 Jun 2002 13:24:35 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: Bin Zhou <binzhou@site.uottawa.ca>
CC: mpls@UU.NET, "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:
> 
> In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src
> can be provided either by Extended Tunnel ID field or Tunnel Sender
> Address field.

No.  Only the tunnel sender address.

The extended tunnel ID does not have to be a valid IP address.  If you
assume it is, your code will not be compliant with the standard.

> Can I use one of the two fields as a FEC for a host address since
> there isn't a FEC element in RSVP-TE?

The entire concept of a FEC is alien to RSVP-TE.  I strongly recommend
that you do not try to shoehorn LDP concepts into RSVP.  It will only
lead to confusion and buggy code.

-- David


From owner-mpls@UU.NET  Mon Jun 17 13:50:55 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13836
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 13:50:55 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrb12024
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 17:51:19 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrb08116;
	Mon, 17 Jun 2002 17:49:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrb19569
	for mpls-outgoing; Mon, 17 Jun 2002 17:49:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtrb19562
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 17:49:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtrb15682
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:48:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrb26884
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:48:13 GMT
Received: from mail.site.uottawa.ca by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142])
	id QQmtrb26874
	for <mpls@UU.NET>; Mon, 17 Jun 2002 17:48:13 GMT
Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149])
	by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id NAA43707;
	Mon, 17 Jun 2002 13:48:04 -0400 (EDT)
Message-ID: <005e01c21627$052c9a60$955b7a89@bwwil28>
From: "Bin Zhou" <binzhou@site.uottawa.ca>
To: "David Charlap" <David.Charlap@marconi.com>
Cc: <mpls@UU.NET>, "Senthil K. Venkatachalam" <svenkatachalam@opnet.com>
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1B53.3EC23367@marconi.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
Date: Mon, 17 Jun 2002 13:47:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

But I really need to provide a host address in the PATH message.
How to avoid using the extended tunnel ID?
Otherwise, I want to define a new field, named Tunnel Client Address in the
Session object.

Regards,
Bin

> > In the quadruple (Src, Dst, Tunnel, LSP-id) you mentioned, the Src
> > can be provided either by Extended Tunnel ID field or Tunnel Sender
> > Address field.
>
> No.  Only the tunnel sender address.
>
> The extended tunnel ID does not have to be a valid IP address.  If you
> assume it is, your code will not be compliant with the standard.
>
> > Can I use one of the two fields as a FEC for a host address since
> > there isn't a FEC element in RSVP-TE?
>
> The entire concept of a FEC is alien to RSVP-TE.  I strongly recommend
> that you do not try to shoehorn LDP concepts into RSVP.  It will only
> lead to confusion and buggy code.
>
> -- David



From owner-mpls@UU.NET  Mon Jun 17 14:06:21 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14463
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 14:06:20 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrc26464
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 18:06:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrc23630;
	Mon, 17 Jun 2002 18:05:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrc08826
	for mpls-outgoing; Mon, 17 Jun 2002 18:05:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtrc07555
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 18:05:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtrc17876
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:03:52 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrc04647
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:03:52 GMT
Received: from mail.site.uottawa.ca by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142])
	id QQmtrc04638
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:03:52 GMT
Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149])
	by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id OAA44541;
	Mon, 17 Jun 2002 14:03:44 -0400 (EDT)
Message-ID: <007901c21629$34f69280$955b7a89@bwwil28>
From: "Bin Zhou" <binzhou@site.uottawa.ca>
To: "Yuan Gu" <yuangu@ipinfusion.com>
Cc: <mpls@UU.NET>
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1CF1.F5A40123@ipinfusion.com>
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
Date: Mon, 17 Jun 2002 14:02:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, Yuan

You ask a good question.
I think Tunnel ID is local in the daemon of the sender. We can use Tunnel ID
and Sender address to distinguish a tunnel. If I need to identify
application in my case, I need host address. The host address should be
informed to destination and intermediate node in my case. So what should I
do?

BTW, I like the maillist very much :)

Bin

> Bin:
>
> Are you trying to send FEC information to intermediate/egress node? FEC is
only
> known by ingress node when packets need to be classified for LSPs. In
> intermediate and egress node, the only way to identify the LSP tunnel in
data
> plane is LABEL.
>
> Regards!
> Yuan




From owner-mpls@UU.NET  Mon Jun 17 14:14:44 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14644
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 14:14:43 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd14202
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 18:15:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrc11458;
	Mon, 17 Jun 2002 18:14:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrc13241
	for mpls-outgoing; Mon, 17 Jun 2002 18:13:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtrc13236
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 18:13:35 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtrc15024
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:11:46 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrc08975
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:11:46 GMT
Received: from mail.site.uottawa.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142])
	id QQmtrc08969
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:11:45 GMT
Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149])
	by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id OAA44939;
	Mon, 17 Jun 2002 14:11:29 -0400 (EDT)
Message-ID: <008001c2162a$4a4c0a10$955b7a89@bwwil28>
From: "Bin Zhou" <binzhou@site.uottawa.ca>
To: <curtis@fictitious.org>
Cc: <mpls@UU.NET>
References: <200206171803.OAA85420@workhorse.fictitious.org>
Subject: Re: RSVP-TE: How to use "Tunnel Sender Address"? 
Date: Mon, 17 Jun 2002 14:10:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis,

I am trying to avoid proposing new field.
The best way to do so is learn the specification first.
Thanks for the help. 

Bin

> If you don't care about interoperability you can do anything you want.
> That assumes that you are implementing something rather than just
> commenting on what you think others should be implementing.
> 
> Maybe you are under the mistaken impression that standards precede
> implementation and therefore you can try to wedge something into an
> internet-draft and solely on that basis everyone will implement it?
> Absolutely not the case in the IETF (or elsewhere regarding anything
> Internet related since ITU, ISO, etc are largely ignored by the IP
> community except for their link layer work).
> 
> What is it that you are trying to accomplish?
> 
> Curtis




From owner-mpls@UU.NET  Mon Jun 17 14:22:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14911
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 14:22:57 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd16215
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 18:23:26 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrd12791;
	Mon, 17 Jun 2002 18:21:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrd14210
	for mpls-outgoing; Mon, 17 Jun 2002 18:21:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtrd14205
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 18:21:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtrd21892
	for <mpls@uu.net>; Mon, 17 Jun 2002 18:21:04 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd14914
	for <mpls@uu.net>; Mon, 17 Jun 2002 18:21:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtrd14905
	for <mpls@uu.net>; Mon, 17 Jun 2002 18:21:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09257 for <mpls@uu.net>; Mon, 17 Jun 2002 14:21:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA13741 for mpls@uu.net; Mon, 17 Jun 2002 14:21:03 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtrd14171
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 18:20:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtrd20582
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:20:23 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd21189
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:20:23 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.66.129.230])
	id QQmtrd21179
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:20:21 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA85964;
	Mon, 17 Jun 2002 14:20:14 -0400 (EDT)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200206171820.OAA85964@workhorse.fictitious.org>
To: "Bin Zhou" <binzhou@site.uottawa.ca>
cc: curtis@fictitious.org, mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: RSVP-TE: How to use "Tunnel Sender Address"? 
In-reply-to: Your message of "Mon, 17 Jun 2002 14:10:40 EDT."
             <008001c2162a$4a4c0a10$955b7a89@bwwil28> 
Date: Mon, 17 Jun 2002 14:20:14 -0400
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <008001c2162a$4a4c0a10$955b7a89@bwwil28>, "Bin Zhou" writes:
> Curtis,
> 
> I am trying to avoid proposing new field.
> The best way to do so is learn the specification first.
> Thanks for the help. 
> 
> Bin


If you are implementing, you should pay close attention to how
existing routers use the fields, not just what is strictly legal to
put in them.  An implementation that "conforms" to a spec but cannot
interoperate is very close to useless.  Users demand interoperability
with incumants in their network and stress conformance much less.

Curtis


> > If you don't care about interoperability you can do anything you want.
> > That assumes that you are implementing something rather than just
> > commenting on what you think others should be implementing.
> > 
> > Maybe you are under the mistaken impression that standards precede
> > implementation and therefore you can try to wedge something into an
> > internet-draft and solely on that basis everyone will implement it?
> > Absolutely not the case in the IETF (or elsewhere regarding anything
> > Internet related since ITU, ISO, etc are largely ignored by the IP
> > community except for their link layer work).
> > 
> > What is it that you are trying to accomplish?
> > 
> > Curtis



From owner-mpls@UU.NET  Mon Jun 17 14:28:23 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15112
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 14:28:22 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd27448
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 18:28:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrd18598;
	Mon, 17 Jun 2002 18:24:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrd14385
	for mpls-outgoing; Mon, 17 Jun 2002 18:24:03 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtrd14366
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 18:23:56 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtrd19083
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:23:49 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrd16929
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:23:47 GMT
Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [65.223.109.2])
	id QQmtrd14937
	for <mpls@UU.NET>; Mon, 17 Jun 2002 18:22:46 GMT
Received: from ipinfusion.com ([10.10.0.225])
	by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g5HILKQ19394;
	Mon, 17 Jun 2002 11:21:20 -0700
Message-ID: <3D0E28BB.4E49DEA6@ipinfusion.com>
Date: Mon, 17 Jun 2002 11:21:47 -0700
From: Yuan Gu <yuangu@ipinfusion.com>
Organization: IP Infusion Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bin Zhou <binzhou@site.uottawa.ca>
CC: mpls@UU.NET
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1CF1.F5A40123@ipinfusion.com> <007901c21629$34f69280$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:

> Hi, Yuan
>
> You ask a good question.
> I think Tunnel ID is local in the daemon of the sender. We can use Tunnel ID
> and Sender address to distinguish a tunnel. If I need to identify
> application in my case, I need host address. The host address should be
> informed to destination and intermediate node in my case. So what should I
> do?
>
> BTW, I like the maillist very much :)
>
> Bin

Bin:

But there is only one RSVP application in each node. Puting your host address
into "extended tunnel id" is allowed(but not mandatory! Other boxes receive it
may only consider it as an identifier of a tunnel rather than a host address.).

I can't figure out what's your exact problem from a few words above. But I feel
it's rather an implementation issue than protocol itself.

Regards!
Yuan

>
>
> > Bin:
> >
> > Are you trying to send FEC information to intermediate/egress node? FEC is
> only
> > known by ingress node when packets need to be classified for LSPs. In
> > intermediate and egress node, the only way to identify the LSP tunnel in
> data
> > plane is LABEL.
> >
> > Regards!
> > Yuan



From owner-mpls@UU.NET  Mon Jun 17 16:13:37 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18521
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 16:13:36 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrk23868
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 20:14:10 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrk21722;
	Mon, 17 Jun 2002 20:13:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrk07077
	for mpls-outgoing; Mon, 17 Jun 2002 20:12:52 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtrk07070
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 20:12:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtrk07482
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:10:32 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrk20514
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:10:32 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtrk20510
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:10:31 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA16840
	for <mpls@UU.NET>; Mon, 17 Jun 2002 16:10:29 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03851
	for <mpls@UU.NET>; Mon, 17 Jun 2002 16:10:29 -0400 (EDT)
Message-ID: <3D0E4233.36DC7B1A@marconi.com>
Date: Mon, 17 Jun 2002 16:10:27 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1CF1.F5A40123@ipinfusion.com> <007901c21629$34f69280$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:
> 
> You ask a good question.
> I think Tunnel ID is local in the daemon of the sender. We can use
> Tunnel ID and Sender address to distinguish a tunnel. If I need to
> identify application in my case, I need host address. The host
> address should be informed to destination and intermediate node in
> my case. So what should I do?

Tunnel ID is not a globally unique identifier in RSVP.  It is not the
same as the tunnel ID that LDP defines.

In RSVP, a _session_ must be defined by the triple {egress-address,
tunnel-id, extended-tunnel-id}.  A session is a _set_ of LSPs that all
share the same session information.  A single LSP is defined by the
combination of its session information and the double {sender-address,
LSP ID}.

If you treat {sender-address, tunnel-id} as a unique identifier (as it
is defined in LDP), then your code will break.

It is perfectly legal in RSVP-TE for one ingress router to use the same
tunnel ID for a thousand different sessions, if they all have different
egress addresses.

-- David


From owner-mpls@UU.NET  Mon Jun 17 16:28:02 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18950
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 16:28:01 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrl08464
	for <mpls-archive@lists.ietf.org>; Mon, 17 Jun 2002 20:28:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtrl05699;
	Mon, 17 Jun 2002 20:27:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtrl08536
	for mpls-outgoing; Mon, 17 Jun 2002 20:27:04 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmtrl08529
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 17 Jun 2002 20:26:53 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtrl17377
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:18:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtrl01112
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:18:25 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmtrl01107
	for <mpls@UU.NET>; Mon, 17 Jun 2002 20:18:25 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17424
	for <mpls@UU.NET>; Mon, 17 Jun 2002 16:18:22 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05398
	for <mpls@UU.NET>; Mon, 17 Jun 2002 16:18:24 -0400 (EDT)
Message-ID: <3D0E440F.6C0FA290@marconi.com>
Date: Mon, 17 Jun 2002 16:18:23 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE:  How to use "Tunnel Sender Address"?
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1B53.3EC23367@marconi.com> <005e01c21627$052c9a60$955b7a89@bwwil28>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bin Zhou wrote:
> 
> But I really need to provide a host address in the PATH message.
> How to avoid using the extended tunnel ID?
> Otherwise, I want to define a new field, named Tunnel Client
> Address in the
> Session object.

Your sender address is part of the SENDER_TEMPLATE object.  That's where
you should get it from.  That field has to be a valid IP address, and
should be an address that corresponds to the ingress router.

In a Resv message, this same address will be part of the FILTER_SPEC
object.

You can use a zero for extended tunnel ID, if you like, but you run the
very real risk of sharing your reservations with a completely unrelated
LSP if you do this.

It's really not a big deal to copy your sender address into the extended
tunnel ID as well.

What, exactly is the problem you're having?

If you believe that the sender address in the SENDER_TEMPLATE changes as
the Path message is propagated, you are wrong.  (If you don't believe
this, I apologize for jumping to conclusions, but I have seen people
with this mistaken impression.)  The SENDER_TEMPLATE is an invariant,
just like the SESSION object is.  The sender address contained within it
will always be the address that was assigned to it by the ingress node.

-- David


From owner-mpls@UU.NET  Tue Jun 18 07:37:36 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13337
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 07:37:36 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmttu14791
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 11:38:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmttu06497;
	Tue, 18 Jun 2002 11:34:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmttu17983
	for mpls-outgoing; Tue, 18 Jun 2002 11:33:55 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmttu17978
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 11:33:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmttu05227
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:31:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmttu05151
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:31:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmttu05135
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:31:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA21024 for <mpls@uu.net>; Tue, 18 Jun 2002 07:31:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA23395 for mpls@uu.net; Tue, 18 Jun 2002 07:31:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmttu17739
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 11:30:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmttt19526
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:27:48 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmttt22044
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:27:48 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmttt22005
	for <mpls@uu.net>; Tue, 18 Jun 2002 11:27:44 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12934;
	Tue, 18 Jun 2002 07:27:04 -0400 (EDT)
Message-Id: <200206181127.HAA12934@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ldp-ft-03.txt
Date: Tue, 18 Jun 2002 07:27:03 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Fault Tolerance for LDP and CR-LDP
	Author(s)	: A. Farrel, P. Brittain et al.
	Filename	: draft-ietf-mpls-ldp-ft-03.txt
	Pages		: 52
	Date		: 17-Jun-02
	
MPLS systems will be used in core networks where system
downtime must be kept to an absolute minimum.  Many MPLS
LSRs may, therefore, exploit Fault Tolerant (FT) hardware
or software to provide high availability of the core
networks.
The details of how FT is achieved for the various
components of an FT LSR, including LDP, CR-LDP, the
switching hardware and TCP, are implementation specific.
This document identifies issues in the CR-LDP
specification [2] and the LDP specification [4] that make
it difficult to implement an FT LSR using the current LDP
and CR-LDP protocols, and proposes enhancements to the
LDP specification to ease such FT LSR implementations.
The extensions described here are equally applicable to
CR-LDP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ldp-ft-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ldp-ft-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020617142703.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-ft-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ldp-ft-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020617142703.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jun 18 09:01:04 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15575
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 09:01:04 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtua24778
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 13:01:32 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtua22398;
	Tue, 18 Jun 2002 13:00:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtua17222
	for mpls-outgoing; Tue, 18 Jun 2002 13:00:03 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmtua17113
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 13:00:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmttz00805
	for <mpls@UU.NET>; Tue, 18 Jun 2002 12:58:09 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmttz00392
	for <mpls@UU.NET>; Tue, 18 Jun 2002 12:58:08 GMT
Received: from bambino.amt.ru by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: bambino.amt.ru [212.111.64.24])
	id QQmttz00380
	for <mpls@UU.NET>; Tue, 18 Jun 2002 12:58:07 GMT
Received: (from root@localhost)
	by bambino.amt.ru (8.11.6/8.11.6) id g5ICwSl09793
	for mpls@UU.NET.KAV; Tue, 18 Jun 2002 16:58:28 +0400
Received: from oleg (oleg-a.amt.ru [10.0.0.150])
	by bambino.amt.ru (8.11.6/8.11.6) with SMTP id g5ICwNU09785
	for <mpls@UU.NET>; Tue, 18 Jun 2002 16:58:28 +0400
Message-ID: <016b01c216c8$4f348ef0$9600000a@oleg>
Reply-To: "Oleg Allenov" <Allenov@amt.ru>
From: "Oleg Allenov" <Allenov@amt.ru>
To: <mpls@UU.NET>
References: <5.1.0.14.2.20020617123812.00ae60c0@mail.opnet.com> <002d01c21621$c954e0b0$955b7a89@bwwil28> <3D0E1B53.3EC23367@marconi.com> <005e01c21627$052c9a60$955b7a89@bwwil28> <3D0E440F.6C0FA290@marconi.com>
Subject: LSP encoding type 
Date: Tue, 18 Jun 2002 17:01:44 +0400
Organization: AMT Group
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

in draft-ietf-mpls-generalized-signaling-08.txt
section 3.1.1 when defining  LSP Encoding Type
why do we differentiate between 1 - Packet and 2 - Ethernet?
Does not generic packet label request covers ethernet and all the other
packet technologies?

Cheers,
oleg






From owner-mpls@UU.NET  Tue Jun 18 11:18:33 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22157
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 11:18:33 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtuj10384
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 15:19:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtuj07605;
	Tue, 18 Jun 2002 15:17:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtuj03154
	for mpls-outgoing; Tue, 18 Jun 2002 15:17:03 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtuj03097
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 15:16:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtuj13975
	for <mpls@uu.net>; Tue, 18 Jun 2002 15:15:28 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtuj21838
	for <mpls@uu.net>; Tue, 18 Jun 2002 15:15:28 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtuj21832
	for <mpls@uu.net>; Tue, 18 Jun 2002 15:15:27 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01509 for <mpls@uu.net>; Tue, 18 Jun 2002 11:15:27 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA16086 for mpls@uu.net; Tue, 18 Jun 2002 11:15:27 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtug08780
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 14:43:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmtug16087
	for <mpls@uu.net>; Tue, 18 Jun 2002 14:42:50 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtug25010
	for <mpls@uu.net>; Tue, 18 Jun 2002 14:42:49 GMT
Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQmtug24996
	for <mpls@uu.net>; Tue, 18 Jun 2002 14:42:48 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0002689384@fsnt.future.futsoft.com> for <mpls@uu.net>;
 Tue, 18 Jun 2002 20:34:11 +0530
Received: from venkattr (venkattr.future.futsoft.com [10.20.6.12])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g5IKEM627366
	for <mpls@uu.net>; Wed, 19 Jun 2002 01:44:22 +0530
Reply-To: <venkattr@future.futsoft.com>
From: "venkattr" <venkattr@future.futsoft.com>
To: <mpls@UU.NET>
Subject: Doubt regarding Explicit NULL label usage with PHP
Date: Tue, 18 Jun 2002 20:13:52 +0530
Message-Id: <000c01c216d6$920af800$0c06140a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,

One of the popular solutions proposed to maintain QoS information from the
penultimate hop to the Egress when PHP is implemented, is to insert an
EXPLICIT NULL label with the QoS information encoded into the EXP bits.  It
is here that I have a gap in my understanding.  The determination of QoS
behaviour to be applied to any MPLS packet depends not just on the EXP bits,
but also on the combination of Label + EXP for both Signalled E-LSPs and
L-LSPs.  The only exception is in the case of Pre-Configured E-LSPs when the
EXP bits by themselves are sufficient for the complete determination of the
QoS behaviour.  In that case, is the use of EXPLICIT NULL label with the EXP
bits encoded to convey QoS information between Penultimate Hop and Egress
restricted to Pre-Configured E-LSPs?

Any valuable inputs will be highly appreciated!

Thanks and regards,

-TRV

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************



From owner-mpls@UU.NET  Tue Jun 18 12:32:00 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25853
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 12:32:00 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtum10039
	for <mpls-archive@lists.ietf.org>; Tue, 18 Jun 2002 16:10:06 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtum07402;
	Tue, 18 Jun 2002 16:08:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtum29622
	for mpls-outgoing; Tue, 18 Jun 2002 16:08:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtum29504
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 16:08:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtum05363
	for <mpls@uu.net>; Tue, 18 Jun 2002 16:04:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtum22119
	for <mpls@uu.net>; Tue, 18 Jun 2002 16:04:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmtum22107
	for <mpls@uu.net>; Tue, 18 Jun 2002 16:04:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA04977 for <mpls@uu.net>; Tue, 18 Jun 2002 12:04:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA22006 for mpls@uu.net; Tue, 18 Jun 2002 12:04:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmtum19608
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 18 Jun 2002 16:03:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmtum15162
	for <mpls@UU.NET>; Tue, 18 Jun 2002 16:01:14 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtum06323
	for <mpls@UU.NET>; Tue, 18 Jun 2002 16:01:14 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQmtum06309
	for <mpls@UU.NET>; Tue, 18 Jun 2002 16:01:13 GMT
Received: (qmail 11211 invoked by uid 104); 18 Jun 2002 16:01:12 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4207. . Clean. Processed in 0.485113 secs); 18 Jun 2002 16:01:12 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 18 Jun 2002 16:01:12 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5IG1Bc15763;
	Tue, 18 Jun 2002 09:01:11 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4RM2C>; Tue, 18 Jun 2002 09:01:10 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB036CF@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'venkattr@future.futsoft.com'" <venkattr@future.futsoft.com>, mpls@UU.NET
Subject: RE: Doubt regarding Explicit NULL label usage with PHP
Date: Tue, 18 Jun 2002 09:01:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

In PHP case, the egress LSR distributes the Implicit Null label (3) to the
penultimate node, and that node just pops the top label and forwards it. 
There is no label insertion.

If we assume that the explicit null label has been inserted by ingress,
and there is another label above it, then your point is valid for the
uniform tunnel mode.

-Shahram

> -----Original Message-----
> From: venkattr [mailto:venkattr@future.futsoft.com]
> Sent: Tuesday, June 18, 2002 10:44 AM
> To: mpls@UU.NET
> Subject: Doubt regarding Explicit NULL label usage with PHP
> 
> 
> Hi All,
> 
> One of the popular solutions proposed to maintain QoS 
> information from the
> penultimate hop to the Egress when PHP is implemented, is to insert an
> EXPLICIT NULL label with the QoS information encoded into the 
> EXP bits.  It
> is here that I have a gap in my understanding.  The 
> determination of QoS
> behaviour to be applied to any MPLS packet depends not just 
> on the EXP bits,
> but also on the combination of Label + EXP for both Signalled 
> E-LSPs and
> L-LSPs.  The only exception is in the case of Pre-Configured 
> E-LSPs when the
> EXP bits by themselves are sufficient for the complete 
> determination of the
> QoS behaviour.  In that case, is the use of EXPLICIT NULL 
> label with the EXP
> bits encoded to convey QoS information between Penultimate 
> Hop and Egress
> restricted to Pre-Configured E-LSPs?
> 
> Any valuable inputs will be highly appreciated!
> 
> Thanks and regards,
> 
> -TRV
> 
> **************************************************************
> *************
> This message is proprietary to Future Software Limited (FSL) 
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information 
> and should not be circulated or used for any purpose other than for 
> what it is intended. 
> 
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message. 
> FSL accepts no responsibility for loss or damage arising from 
> the use of the information transmitted by this email including
> damage from virus.
> **************************************************************
> *************
> 



From owner-mpls@UU.NET  Wed Jun 19 17:16:13 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03733
	for <mpls-archive@lists.ietf.org>; Wed, 19 Jun 2002 17:16:13 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtyz27746
	for <mpls-archive@lists.ietf.org>; Wed, 19 Jun 2002 21:16:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmtyz27346;
	Wed, 19 Jun 2002 21:16:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmtyz12776
	for mpls-outgoing; Wed, 19 Jun 2002 21:15:51 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmtyz12770
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 19 Jun 2002 21:15:43 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmtyy12039
	for <mpls@UU.NET>; Wed, 19 Jun 2002 21:11:36 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmtyy21386
	for <mpls@UU.NET>; Wed, 19 Jun 2002 21:11:35 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQmtyy21382
	for <mpls@UU.NET>; Wed, 19 Jun 2002 21:11:35 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 17:11:19 -0400
Message-ID: <025901c217d5$db4e4d50$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: draft-ietf-mpls-ldp-ft-03.txt posted
Date: Wed, 19 Jun 2002 17:11:18 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 19 Jun 2002 21:11:19.0351 (UTC) FILETIME=[DB3D8470:01C217D5]
Sender: owner-mpls@UU.NET
Precedence: bulk

A new version of the LDP-FT draft has been posted.  I didn't see a message to
the WG.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-03.txt

The main changes in this draft are folding in the function of
draft-smith-ldp-restart-00.txt

This has been achieved without disrupting the previously existing function and
without requiring a disjoint set of procedures.

We have also added the selection control of draft-ietf-mpls-ldp-restart

For those with an eye to history: note that version 02 of the draft was pulled
back from IESG review to do this work.

Adrian
--
Adrian Farrel
Director Protocol Development
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com




From owner-mpls@UU.NET  Thu Jun 20 00:48:18 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10907
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 00:48:17 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuad23942
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 04:48:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuad22822;
	Thu, 20 Jun 2002 04:48:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuad20752
	for mpls-outgoing; Thu, 20 Jun 2002 04:48:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuad20740
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 04:48:10 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuad13902
	for <mpls@uu.net>; Thu, 20 Jun 2002 04:47:09 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuad01725
	for <mpls@uu.net>; Thu, 20 Jun 2002 04:47:09 GMT
Received: from web14402.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14402.mail.yahoo.com [216.136.174.59])
	id QQmuad01720
	for <mpls@uu.net>; Thu, 20 Jun 2002 04:47:08 GMT
Message-ID: <20020620044707.7076.qmail@web14402.mail.yahoo.com>
Received: from [203.159.0.10] by web14402.mail.yahoo.com via HTTP; Wed, 19 Jun 2002 21:47:07 PDT
Date: Wed, 19 Jun 2002 21:47:07 -0700 (PDT)
From: Hilbert Transform <hilbert_transform@yahoo.com>
Subject: patches for diffserv
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1913321903-1024548427=:6225"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-1913321903-1024548427=:6225
Content-Type: text/plain; charset=us-ascii


Hi

I am a silent listner of this mailing group. I just want to know where can I find the patches for "diffserv" and "MPLS" and also for "Diffserv in MPLS environment". I have tried the NS-2 website (contributed by Mr. Murphy), but the links are not working. Can anybody help me in this regard. 

Thanks in advance.

Jane 



---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--0-1913321903-1024548427=:6225
Content-Type: text/html; charset=us-ascii

<P>Hi</P>
<P>I am a silent listner of this mailing group. I just want to know where can I find the patches for "diffserv" and "MPLS" and also for "Diffserv in MPLS environment". I have tried the NS-2 website (contributed by Mr. Murphy), but the links are not working. Can anybody help me in this regard.&nbsp;</P>
<P>Thanks in advance.</P>
<P>Jane&nbsp;</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com/fc/en/spl">Sign-up for Video Highlights</a> of 2002 FIFA World Cup
--0-1913321903-1024548427=:6225--


From owner-mpls@UU.NET  Thu Jun 20 04:03:10 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21859
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 04:03:10 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuaq11636
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 08:03:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuaq09593;
	Thu, 20 Jun 2002 08:02:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuaq22466
	for mpls-outgoing; Thu, 20 Jun 2002 08:02:34 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuaq22345
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 08:02:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuaq20943
	for <mpls@UU.NET>; Thu, 20 Jun 2002 08:02:02 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuaq18431
	for <mpls@UU.NET>; Thu, 20 Jun 2002 08:02:02 GMT
Received: from tomp.smb.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQmuaq18408
	for <mpls@UU.NET>; Thu, 20 Jun 2002 08:02:01 GMT
Received: from utfors.se ([172.20.0.98]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GXZVVJ00.5WR;
          Thu, 20 Jun 2002 10:06:55 +0200 
Message-ID: <3D118BF3.5050903@utfors.se>
Date: Thu, 20 Jun 2002 10:01:55 +0200
From: Loa Andersson <loa.andersson@utfors.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mpls wg <mpls@UU.NET>
CC: Scott Bradner <sob@harvard.edu>, George Swallow <swallow@cisco.com>,
        Yakov Rekhter <yakov@juniper.net>, rahul@redback.com,
        manoj@juniper.net
Subject: wg last call draft-ietf-mpls-ldp-restart-02.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

This message initiates a two week WG last call on:

Graceful Restart Mechanism for LDP


       <draft-ietf-mpls-ldp-restart-02.txt>

Please send your comments to the mailing list.

This wg last call ends July 5, 2002 at 2400 GMT.

/Loa

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           loa.andersson@utfors.se
WWW             www.utfors.se



From owner-mpls@UU.NET  Thu Jun 20 11:43:44 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03701
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 11:43:41 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubt14139
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 15:19:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmubt12760;
	Thu, 20 Jun 2002 15:18:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmubt11520
	for mpls-outgoing; Thu, 20 Jun 2002 15:18:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmubt11515
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 15:18:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmubt16423
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:16:38 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubt14539
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:16:38 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQmubt14532
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:16:38 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 20 Jun 2002 11:16:37 -0400
Message-ID: <02a401c2186d$78ec5010$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Loa Andersson" <loa.andersson@utfors.se>, "mpls wg" <mpls@UU.NET>
Cc: "Scott Bradner" <sob@harvard.edu>, "George Swallow" <swallow@cisco.com>
References: <3D118BF3.5050903@utfors.se>
Subject: Re: wg last call draft-ietf-mpls-ldp-restart-02.txt
Date: Thu, 20 Jun 2002 11:16:37 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 20 Jun 2002 15:16:37.0855 (UTC) FILETIME=[78E4AEF0:01C2186D]
Sender: owner-mpls@UU.NET
Precedence: bulk

Since this draft has an explicit dependency on draft-ietf-mpls-ldp-ft-03.txt,
and since draft-ietf-mpls-ldp-ft-03.txt is also ready for last call, can I
suggest that the last calls proceed in parallel?

Thanks,
Adrian
----- Original Message -----
From: "Loa Andersson" <loa.andersson@utfors.se>
To: "mpls wg" <mpls@UU.NET>
Cc: "Scott Bradner" <sob@harvard.edu>; "George Swallow" <swallow@cisco.com>;
"Yakov Rekhter" <yakov@juniper.net>; <rahul@redback.com>; <manoj@juniper.net>
Sent: Thursday, June 20, 2002 4:01 AM
Subject: wg last call draft-ietf-mpls-ldp-restart-02.txt


> This message initiates a two week WG last call on:
>
> Graceful Restart Mechanism for LDP
>
>
>        <draft-ietf-mpls-ldp-restart-02.txt>
>
> Please send your comments to the mailing list.
>
> This wg last call ends July 5, 2002 at 2400 GMT.
>
> /Loa
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab (URAX)
> Utfors AB
> Råsundavägen 12
> Box 525, 169 29 Solna
> Office          +46 8 5270 2000
> Office direct   +46 8 5270 5038
> Mobile          +46 70 848 5038
> Email           loa.andersson@utfors.se
> WWW             www.utfors.se
>




From owner-mpls@UU.NET  Thu Jun 20 11:57:02 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04185
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 11:57:01 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubv28334
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 15:57:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmubv19355;
	Thu, 20 Jun 2002 15:52:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmubv14052
	for mpls-outgoing; Thu, 20 Jun 2002 15:52:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmubv14039
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 15:52:00 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmubv29195
	for <mpls@uu.net>; Thu, 20 Jun 2002 15:51:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubv11147
	for <mpls@uu.net>; Thu, 20 Jun 2002 15:51:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmubv11135
	for <mpls@uu.net>; Thu, 20 Jun 2002 15:51:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA22389 for <mpls@uu.net>; Thu, 20 Jun 2002 11:51:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA29002 for mpls@uu.net; Thu, 20 Jun 2002 11:51:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmubv13846
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 15:50:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmubv25168
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:49:42 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubv09723
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:49:42 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmubv09704
	for <mpls@UU.NET>; Thu, 20 Jun 2002 15:49:41 GMT
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA22288; Thu, 20 Jun 2002 11:49:35 -0400 (EDT)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA10759; Thu, 20 Jun 2002 11:49:35 -0400 (EDT)
Message-Id: <200206201549.LAA10759@bifocal.cisco.com>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: "Adrian Farrel" <afarrel@movaz.com>
cc: "Loa Andersson" <loa.andersson@utfors.se>, "mpls wg" <mpls@UU.NET>,
        "Scott Bradner" <sob@harvard.edu>,
        "George Swallow" <swallow@cisco.com>, swallow@cisco.com
Subject: Re: wg last call draft-ietf-mpls-ldp-restart-02.txt 
In-reply-to: Your message of "Thu, 20 Jun 2002 11:16:37 EDT."
             <02a401c2186d$78ec5010$681810ac@movaz.com> 
Date: Thu, 20 Jun 2002 11:49:35 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> Since this draft has an explicit dependency on draft-ietf-mpls-ldp-ft-03.txt,
> and since draft-ietf-mpls-ldp-ft-03.txt is also ready for last call, can I
> suggest that the last calls proceed in parallel?

Yes.  This officially begins a two week WG last call on:

    Fault Tolerance for LDP and CR-LDP

     <draft-ietf-mpls-ldp-ft-03.txt>

Please send your comments to the mailing list.

This wg last call ends July 5, 2002 at 2400 GMT.

George & Loa
==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824



From owner-mpls@UU.NET  Thu Jun 20 12:31:26 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05511
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 12:31:25 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuby17089
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 16:32:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuby14054;
	Thu, 20 Jun 2002 16:30:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuby09157
	for mpls-outgoing; Thu, 20 Jun 2002 16:30:28 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuby09147
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 16:30:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmubx25142
	for <mpls@UU.NET>; Thu, 20 Jun 2002 16:28:26 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmubx04870
	for <mpls@UU.NET>; Thu, 20 Jun 2002 16:28:26 GMT
Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQmubx04863
	for <mpls@UU.NET>; Thu, 20 Jun 2002 16:28:26 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA10782
	for <mpls@UU.NET>; Thu, 20 Jun 2002 12:25:13 -0400 (EDT)
Subject: RSVPTE question
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFCA0E68E9.C71A7BC7-ON85256BDE.0059AC9F@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 20 Jun 2002 12:25:11 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 06/20/2002 12:25:13 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I want to know which field in the path msg is the one which requests for
the bandwidth.  (Is the TBS?)

Thanks,
Julia




From owner-mpls@UU.NET  Thu Jun 20 13:48:38 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08086
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 13:48:34 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucd19957
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 17:49:11 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmucd17321;
	Thu, 20 Jun 2002 17:48:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmucd08510
	for mpls-outgoing; Thu, 20 Jun 2002 17:47:48 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmucd08502
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 17:47:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmucd15045
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:47:25 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucd18311
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:47:24 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmucd18305
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:47:24 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06262
	for <mpls@UU.NET>; Thu, 20 Jun 2002 13:47:22 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06707
	for <mpls@UU.NET>; Thu, 20 Jun 2002 13:47:22 -0400 (EDT)
Message-ID: <3D121534.5C7F3561@marconi.com>
Date: Thu, 20 Jun 2002 13:47:32 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE question
References: <OFCA0E68E9.C71A7BC7-ON85256BDE.0059AC9F@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> I want to know which field in the path msg is the one which
> requests for the bandwidth.  (Is the TBS?)

The SENDER_TSPEC

-- David


From owner-mpls@UU.NET  Thu Jun 20 14:01:15 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08586
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 14:01:15 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuce27988
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 18:01:54 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuce26205;
	Thu, 20 Jun 2002 18:01:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuce13762
	for mpls-outgoing; Thu, 20 Jun 2002 18:00:50 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuce13678
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 18:00:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuce07276
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:00:42 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuce25781
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:00:42 GMT
Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQmuce25726
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:00:34 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA28644;
	Thu, 20 Jun 2002 13:56:47 -0400 (EDT)
Subject: Re: RSVPTE question
To: David Charlap <David.Charlap@marconi.com>
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF0BFB1331.60195CF7-ON85256BDE.00627AAF@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 20 Jun 2002 13:56:40 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 06/20/2002 01:56:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


David,

I know it is SENDER_TSPEC, but is it Peak data rate or the token bucket
size?


Hong (Julia) Liao
ATM/Broadband Network Integration
Telcordia Technologies, Inc

Tel:  (973) 829-4570
Fax: (973) 829-5962


                                                                                                       
                    David Charlap                                                                      
                    <David.Charlap@ma        To:     mpls@UU.NET                                       
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                        
                                             Subject:     Re: RSVPTE question                          
                    06/20/02 01:47 PM                                                                  
                                                                                                       
                                                                                                       





Hong Liao wrote:
>
> I want to know which field in the path msg is the one which
> requests for the bandwidth.  (Is the TBS?)

The SENDER_TSPEC

-- David





From owner-mpls@UU.NET  Thu Jun 20 14:32:10 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09694
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 14:32:10 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucg17159
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 18:32:47 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmucg15363;
	Thu, 20 Jun 2002 18:31:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmucg04165
	for mpls-outgoing; Thu, 20 Jun 2002 18:31:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmucg04160
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 18:31:35 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmucf13480
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:23:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucf05897
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:23:24 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmucf05891
	for <mpls@UU.NET>; Thu, 20 Jun 2002 18:23:23 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08708
	for <mpls@UU.NET>; Thu, 20 Jun 2002 14:23:21 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13190
	for <mpls@UU.NET>; Thu, 20 Jun 2002 14:23:22 -0400 (EDT)
Message-ID: <3D121DA4.F206EABE@marconi.com>
Date: Thu, 20 Jun 2002 14:23:32 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE question
References: <OF0BFB1331.60195CF7-ON85256BDE.00627AAF@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> I know it is SENDER_TSPEC, but is it Peak data rate or the token
> bucket size?

It definitely won't be the token bucket size - that's used for
configuing queue sizes.

The IntServ RFCS explain the IntServ objects.  Three values together
define your QoS:

r - the data rate - this is the "bandwidth" if you only need one number

b - the bucket size - this is (roughly) the size of the queue for
buffering non-conformant packets.

p - the peak data rate - this is the maximum rate data may arrive.

The three together form the parameters for a "leaky bucket" type
queueing system.  I think it's similar to, but not identical to, ATM's
"double leaky bucket" algorithm, if that means anything to you.

-- David


From owner-mpls@UU.NET  Thu Jun 20 14:55:54 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10369
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 14:55:54 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuch16936
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 18:55:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuch14399;
	Thu, 20 Jun 2002 18:54:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuch06236
	for mpls-outgoing; Thu, 20 Jun 2002 18:54:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuch06231
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 18:54:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmuch05680
	for <mpls@uu.net>; Thu, 20 Jun 2002 18:53:49 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuch17797
	for <mpls@uu.net>; Thu, 20 Jun 2002 18:53:49 GMT
Received: from alpha2.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [65.125.55.125])
	id QQmuch17785
	for <mpls@uu.net>; Thu, 20 Jun 2002 18:53:49 GMT
Received: from mail3.tellium.com (mail3.tellium.com) by alpha2.tellium.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b9a6b680bc0a81810434@alpha2.tellium.com>;
 Thu, 20 Jun 2002 14:52:34 -0400
Received: by mail3.tellium.com with Internet Mail Service (5.5.2653.19)
	id <NDP2RSB7>; Thu, 20 Jun 2002 14:48:54 -0400
Message-ID: <05707214338CD5119BFF0040A5B170D3016AE865@mail3.tellium.com>
From: Vasanthi Thirumalai <Vasanthi@tellium.com>
To: "'Hong Liao'" <hliao@telcordia.com>, mpls@UU.NET
Subject: RE: RSVPTE question
Date: Thu, 20 Jun 2002 14:48:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Julia,
I responded once before on this issue and my feeling is that it is Peak data
rate. But someone on the list disagreed. I guess it also depends to a large
extent on the type of the system. For instance on an optical system, you may
have a choice of dicrete bandwdths to choose from - say OC-12, OC-48 or
OC-192. In such a case the peak data rate seems more appropriate.

-Vasanthi

-----Original Message-----
From: Hong Liao [mailto:hliao@telcordia.com]
Sent: Thursday, June 20, 2002 12:25 PM
To: mpls@UU.NET
Subject: RSVPTE question


Hi,

I want to know which field in the path msg is the one which requests for
the bandwidth.  (Is the TBS?)

Thanks,
Julia



From owner-mpls@UU.NET  Thu Jun 20 16:31:42 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12073
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 16:31:42 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuco08301
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 20:32:18 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuco06359;
	Thu, 20 Jun 2002 20:31:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuco28011
	for mpls-outgoing; Thu, 20 Jun 2002 20:31:08 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuco27968
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 20:31:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuco00504
	for <mpls@UU.NET>; Thu, 20 Jun 2002 20:30:18 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuco05710
	for <mpls@UU.NET>; Thu, 20 Jun 2002 20:30:18 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmuco05694
	for <mpls@UU.NET>; Thu, 20 Jun 2002 20:30:18 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17552
	for <mpls@UU.NET>; Thu, 20 Jun 2002 16:30:15 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09625
	for <mpls@UU.NET>; Thu, 20 Jun 2002 16:30:16 -0400 (EDT)
Message-ID: <3D123B63.FE89C956@marconi.com>
Date: Thu, 20 Jun 2002 16:30:27 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE question
References: <05707214338CD5119BFF0040A5B170D3016AE865@mail3.tellium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vasanthi Thirumalai wrote:
> 
> I responded once before on this issue and my feeling is that it is
> Peak data rate. But someone on the list disagreed. I guess it also
> depends to a large extent on the type of the system. For instance
> on an optical system, you may have a choice of dicrete bandwdths
> to choose from - say OC-12, OC-48 or OC-192. In such a case the
> peak data rate seems more appropriate.

If you're on a network where there is no room for fuzziness in your
request, then it's not a big deal to generate a TSPEC where r == p.

As I wrote in response to Julia's message, IntServ objects do not define
a single "bandwidth" parameter.  Instead, they define 3 (5 for
guaranteed service) parameters which are used to define a specific
queueing algorithm.

If your hardware does not support this queueing model, then the
parameters must be massaged to fit what your hardware does support. 
There is no generalized way to do this.  The "right thing" will depend
on what your hardware's queueing model is.

-- David


From owner-mpls@UU.NET  Thu Jun 20 17:17:00 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12750
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 17:17:00 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucr14203
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 21:17:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmucr12767;
	Thu, 20 Jun 2002 21:16:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmucr24417
	for mpls-outgoing; Thu, 20 Jun 2002 21:16:29 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmucr24410
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 21:16:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmucr25390
	for <mpls@uu.net>; Thu, 20 Jun 2002 21:16:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucr16128
	for <mpls@uu.net>; Thu, 20 Jun 2002 21:16:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmucr16116
	for <mpls@uu.net>; Thu, 20 Jun 2002 21:16:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14452 for <mpls@uu.net>; Thu, 20 Jun 2002 17:16:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA03695 for mpls@uu.net; Thu, 20 Jun 2002 17:16:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmucq23670
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 21:13:30 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmucq18026
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:13:28 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucq11104
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:13:27 GMT
Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQmucq11095
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:13:26 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA10240;
	Thu, 20 Jun 2002 17:13:22 -0400 (EDT)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200206202113.RAA10240@workhorse.fictitious.org>
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: RSVPTE question 
In-reply-to: Your message of "Thu, 20 Jun 2002 16:30:27 EDT."
             <3D123B63.FE89C956@marconi.com> 
Date: Thu, 20 Jun 2002 17:13:22 -0400
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3D123B63.FE89C956@marconi.com>, David Charlap writes:
> Vasanthi Thirumalai wrote:
> > 
> > I responded once before on this issue and my feeling is that it is
> > Peak data rate. But someone on the list disagreed. I guess it also
> > depends to a large extent on the type of the system. For instance
> > on an optical system, you may have a choice of dicrete bandwdths
> > to choose from - say OC-12, OC-48 or OC-192. In such a case the
> > peak data rate seems more appropriate.
> 
> If you're on a network where there is no room for fuzziness in your
> request, then it's not a big deal to generate a TSPEC where r == p.
> 
> As I wrote in response to Julia's message, IntServ objects do not define
> a single "bandwidth" parameter.  Instead, they define 3 (5 for
> guaranteed service) parameters which are used to define a specific
> queueing algorithm.
> 
> If your hardware does not support this queueing model, then the
> parameters must be massaged to fit what your hardware does support. 
> There is no generalized way to do this.  The "right thing" will depend
> on what your hardware's queueing model is.
> 
> -- David


David,

Today's routers use "r" as the value that is credited against
"reservable bandwidth" on an interface and ignore "p" and "b" but it
wouldn't hurt to set "p" to be the same as "r".

It is probably best to set the value for "b" to a very large value
even though it is ignored.  I don't know of anything that does not
ignore "p" and "b" so the discussion of what others put in it and what
is best to put in it hasn't come up in a while.  Maybe someone else
knows of equipment that doesn't ignore "p" and "b" when using RSVP-TE.

Curtis



From owner-mpls@UU.NET  Thu Jun 20 17:30:18 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13259
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 17:30:18 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucs04408
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 21:30:52 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmucr28771;
	Thu, 20 Jun 2002 21:28:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmucr25424
	for mpls-outgoing; Thu, 20 Jun 2002 21:28:08 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmucr25412
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 21:27:59 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmucr19366
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:27:47 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmucr09185
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:27:47 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmucr09172
	for <mpls@UU.NET>; Thu, 20 Jun 2002 21:27:46 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20509
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:27:44 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19723
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:27:45 -0400 (EDT)
Message-ID: <3D1248DB.AD8336FA@marconi.com>
Date: Thu, 20 Jun 2002 17:27:56 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE question
References: <200206202113.RAA10240@workhorse.fictitious.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Curtis Villamizar wrote:
> 
> Today's routers use "r" as the value that is credited against
> "reservable bandwidth" on an interface and ignore "p" and "b" but it
> wouldn't hurt to set "p" to be the same as "r".

That's fine if all you're using the TSPEC/FLOWSPEC for is bookkeeping.

If your router actually performs traffic shaping/policing, then you need
the remaining values to properly program your queues.

-- David


From owner-mpls@UU.NET  Thu Jun 20 20:46:05 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16894
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 20:46:05 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudf14718
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 00:46:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmude11657;
	Fri, 21 Jun 2002 00:44:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmude15900
	for mpls-outgoing; Fri, 21 Jun 2002 00:44:29 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmude15891
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 00:44:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmude23298
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:44:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmude15181
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:44:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmude15177
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:44:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA22179 for <mpls@uu.net>; Thu, 20 Jun 2002 20:44:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA24320 for mpls@uu.net; Thu, 20 Jun 2002 20:44:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmude15344
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 00:36:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmude09133
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:33:34 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmude03821
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:33:34 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f198.law10.hotmail.com [64.4.15.198])
	id QQmude03807
	for <mpls@uu.net>; Fri, 21 Jun 2002 00:33:33 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 20 Jun 2002 17:33:33 -0700
Received: from 198.242.58.71 by lw10fd.law10.hotmail.msn.com with HTTP;
	Fri, 21 Jun 2002 00:33:32 GMT
X-Originating-IP: [198.242.58.71]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: mpls@UU.NET
Subject: MPLS TE MIB Doubt
Date: Thu, 20 Jun 2002 17:33:32 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F198JXncnm5c4GnO9lT00006416@hotmail.com>
X-OriginalArrivalTime: 21 Jun 2002 00:33:33.0050 (UTC) FILETIME=[45E6CDA0:01C218BB]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        In MPLS-TE mib, it is written that the information necessary to
build entries within mplsTunelARHopTable is not provided by some MPLS
signaling protocols and therefore the implementation of this table is
optional. RSVP-TE has the RRO mechanism but CR-LDP don't have such kind of 
mechanism.

Does this mean that this table is not applicable to CR-LDP ?

Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From owner-mpls@UU.NET  Thu Jun 20 23:16:27 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20302
	for <mpls-archive@lists.ietf.org>; Thu, 20 Jun 2002 23:16:27 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudp06061
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 03:17:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmudo02465;
	Fri, 21 Jun 2002 03:14:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmudo04016
	for mpls-outgoing; Fri, 21 Jun 2002 03:14:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmudo04011
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 03:14:30 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmudo06125
	for <mpls@uu.net>; Fri, 21 Jun 2002 03:14:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudo07011
	for <mpls@uu.net>; Fri, 21 Jun 2002 03:14:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmudo07007
	for <mpls@uu.net>; Fri, 21 Jun 2002 03:14:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA27686 for <mpls@uu.net>; Thu, 20 Jun 2002 23:14:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA10698 for mpls@uu.net; Thu, 20 Jun 2002 23:14:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuca04885
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 20 Jun 2002 17:11:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuca07763
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:10:57 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuca11783
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:10:56 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmuca11759
	for <mpls@UU.NET>; Thu, 20 Jun 2002 17:10:55 GMT
Received: (qmail 13247 invoked by uid 104); 20 Jun 2002 17:10:55 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4208. . Clean. Processed in 0.431725 secs); 20 Jun 2002 17:10:55 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 20 Jun 2002 17:10:54 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5KHAsc08125;
	Thu, 20 Jun 2002 10:10:54 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4SVPX>; Thu, 20 Jun 2002 10:10:54 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB036DE@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Hong Liao'" <hliao@telcordia.com>, mpls@UU.NET
Subject: RE: RSVPTE question
Date: Thu, 20 Jun 2002 10:10:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

SENDER_TSPEC. Check RFC3270 section 5.6

-Shahram

> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Thursday, June 20, 2002 12:25 PM
> To: mpls@UU.NET
> Subject: RSVPTE question
> 
> 
> Hi,
> 
> I want to know which field in the path msg is the one which 
> requests for
> the bandwidth.  (Is the TBS?)
> 
> Thanks,
> Julia
> 
> 



From owner-mpls@UU.NET  Fri Jun 21 01:16:23 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22492
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 01:16:23 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudx01551
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 05:17:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmudx00718;
	Fri, 21 Jun 2002 05:16:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmudx27848
	for mpls-outgoing; Fri, 21 Jun 2002 05:15:11 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmudx27755
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 05:15:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmudw03084
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:14:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudw29103
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:14:51 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQmudw29097
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:14:50 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 21 Jun 2002 01:14:43 -0400
Message-ID: <003201c218e2$924eaba0$9e13588a@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "mpls wg" <mpls@UU.NET>, "Yakov Rekhter" <yakov@juniper.net>,
        <rahul@redback.com>, <manoj@juniper.net>
References: <3D118BF3.5050903@utfors.se>
Subject: Re: wg last call draft-ietf-mpls-ldp-restart-02.txt
Date: Fri, 21 Jun 2002 00:47:42 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C218BD.3FF324A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 21 Jun 2002 05:14:50.0575 (UTC) FILETIME=[91B0BDF0:01C218E2]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C218BD.3FF324A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I have some comments which are mainly requests for clarification to be =
added to the draft.  I'm sorry to raise them at this late stage, but =
better now than even later...

1. It would be nice if you made it clear up front that=20
   this draft applies only to DU.  Currently this is=20
   tucked away in para 3 of section 6.

2. In the first line of 6.1.1 could you say that "the
   Mapping message" is a "newly received Mapping message"?

3. It would be helpful to add some text to cover processing
   of other messages while an LSR is in the process of=20
   restarting: in particular Withdraw and Release.  Although
   this is pretty obvious, I believe you run the risk of
   failure to interop correctly unless you spell it out: viz.
   Withdraw should match in table, delete from table and=20
   send Withdraw upstream as required
   Release should match in table, if entry is stale should
   ignore, if entry is not stale should process according
   to normal Release procedures on local node.

4. It would be nice if you exposed that all Address messages
   need to be exchanged before the downstream node starts=20
   resending Mapping messages.  Section 6.1.1 is based on the
   assumption that these messages have been received.

5. Is it normal procedure to give suggested values for all
   timers in drafts?

6. Section 6 states that there is an assumption that IP
   forwarding state is preserved in parallel to MPLS=20
   forwarding state.  I looked hard for a reference to this
   in the text and only found the case of the restarting=20
   Egress LSR needing to look up the next hop of a FEC if
   it is also configured to generate a non-null, unique
   label for such a FEC.  Further this only applies if the
   FEC is of the type that has its next hop determined
   through the IP forwarding table.
   This seems much weaker than the statement in section 6.

As a general question, has anyone done any analysis of how long it would =
take to redistribute all of the addresses and labels on a router in a =
large network?  In other words, what is a reasonable bound for the =
Recovery Time?  (Note that the neighbors can't start re-using labels =
until the Recovery Time is complete.)

Hope this is of some help.
Regards,
Adrian

------=_NextPart_000_0003_01C218BD.3FF324A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I have some comments which are mainly =
requests=20
for clarification to be added to the draft.&nbsp; I'm sorry to raise =
them at=20
this late stage, but better now than even later...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>1. It would be nice if you made it =
clear up front=20
that </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;this draft applies =
only to=20
DU.&nbsp; Currently this is </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;tucked away in para =
3 of=20
section 6.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>2. In the first line of 6.1.1 could =
you say that=20
"the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; =
&nbsp;Mapping&nbsp;</FONT><FONT=20
face=3DCourier size=3D2>message" is a "newly received Mapping =
message"?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>3. It would be helpful to add some =
text to cover=20
processing</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;of other messages =
while an LSR=20
is in the process of </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; restarting:&nbsp;in =
particular=20
Withdraw and Release.&nbsp; Although</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; this is pretty obvious, =
I believe=20
you run the risk of</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; failure to interop =
correctly unless=20
you spell it out: viz.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Withdraw should match in =
table,=20
delete from table and </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; send Withdraw upstream =
as=20
required</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Release should match in =
table, if=20
entry is stale should</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; ignore, if entry is not =
stale should=20
process according</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; to normal Release =
procedures on=20
local node.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>4. It would be nice if you exposed =
that all=20
Address messages</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; need to be exchanged =
before the=20
downstream node starts </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; resending Mapping =
messages.&nbsp;=20
Section 6.1.1 is based on the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; assumption that these =
messages have=20
been received.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>5. Is it&nbsp;normal procedure to =
give suggested=20
values&nbsp;</FONT><FONT face=3DCourier size=3D2>for all</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; &nbsp;timers in =
drafts?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>6. Section 6 states that there is an =
assumption=20
that IP</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; forwarding state is =
preserved in=20
parallel to MPLS </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; forwarding state.&nbsp; =
I looked=20
hard for a reference to this</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; in the text and only =
found the case=20
of the restarting </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; Egress =
LSR&nbsp;</FONT><FONT=20
face=3DCourier size=3D2>needing to look up the next hop of a FEC =
if</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; it is&nbsp;also =
configured to=20
generate a non-null, unique</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; &nbsp;label for&nbsp;such a =
FEC.&nbsp;=20
Further this only applies if the</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; FEC is of the type that =
has its next=20
hop determined</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; through the IP =
forwarding=20
table.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This seems much weaker =
than the=20
statement in section 6.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>As a general question, has anyone =
done any=20
analysis of how long it would take to redistribute all of the addresses =
and=20
labels on a router in a large network?&nbsp; In other words, what is a=20
reasonable bound for the Recovery Time?&nbsp; (Note that the neighbors =
can't=20
start re-using labels until the Recovery Time is complete.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Hope this is of some =
help.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV></BODY></HTML>

------=_NextPart_000_0003_01C218BD.3FF324A0--



From owner-mpls@UU.NET  Fri Jun 21 01:55:30 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23204
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 01:55:29 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudz02713
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 05:56:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmudz00175;
	Fri, 21 Jun 2002 05:54:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmudz00648
	for mpls-outgoing; Fri, 21 Jun 2002 05:54:17 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmudz00643
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 05:54:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmudz07541
	for <mpls@uu.net>; Fri, 21 Jun 2002 05:54:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudz29780
	for <mpls@uu.net>; Fri, 21 Jun 2002 05:54:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmudz29776
	for <mpls@uu.net>; Fri, 21 Jun 2002 05:54:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA07374 for <mpls@uu.net>; Fri, 21 Jun 2002 01:54:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA28094 for mpls@uu.net; Fri, 21 Jun 2002 01:54:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmudz00609
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 05:53:12 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmudz03663
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:52:37 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmudz29351
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:52:37 GMT
Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: workhorse.fictitious.org [209.150.1.230])
	id QQmudz29347
	for <mpls@UU.NET>; Fri, 21 Jun 2002 05:52:36 GMT
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id BAA11845;
	Fri, 21 Jun 2002 01:52:27 -0400 (EDT)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200206210552.BAA11845@workhorse.fictitious.org>
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Reply-To: curtis@fictitious.org
Subject: Re: RSVPTE question 
In-reply-to: Your message of "Thu, 20 Jun 2002 17:27:56 EDT."
             <3D1248DB.AD8336FA@marconi.com> 
Date: Fri, 21 Jun 2002 01:52:27 -0400
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: owner-mpls@UU.NET
Precedence: bulk


In message <3D1248DB.AD8336FA@marconi.com>, David Charlap writes:
> Curtis Villamizar wrote:
> > 
> > Today's routers use "r" as the value that is credited against
> > "reservable bandwidth" on an interface and ignore "p" and "b" but it
> > wouldn't hurt to set "p" to be the same as "r".
> 
> That's fine if all you're using the TSPEC/FLOWSPEC for is bookkeeping.
> 
> If your router actually performs traffic shaping/policing, then you need
> the remaining values to properly program your queues.
> 
> -- David


David,

If interoperability with major router vendors isn't important, then go
ahead and fill in and use "p" and "b" and use them.

Besides, there are technical problem.  I don't think there is a way to
signal "your 'r' value was just fine but 'b' was too big for the
buffering I have left".  Even if there was, there is just reservable
bandwidth in the flooded information so LSP path selection would
involve trial and error.

Curtis



From owner-mpls@UU.NET  Fri Jun 21 07:41:36 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08504
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 07:41:35 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuew20679
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 11:42:15 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuew15710;
	Fri, 21 Jun 2002 11:40:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuew08436
	for mpls-outgoing; Fri, 21 Jun 2002 11:39:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmuew08429
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 11:39:42 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuew05455
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:39:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuew17993
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:39:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmuew17989
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:39:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA16582 for <mpls@uu.net>; Fri, 21 Jun 2002 07:39:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA01668 for mpls@uu.net; Fri, 21 Jun 2002 07:39:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuew08380
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 11:38:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuew20880
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:37:59 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuew14586
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:37:59 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmuew14582
	for <mpls@uu.net>; Fri, 21 Jun 2002 11:37:59 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08167;
	Fri, 21 Jun 2002 07:37:17 -0400 (EDT)
Message-Id: <200206211137.HAA08167@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-ttl-03.txt
Date: Fri, 21 Jun 2002 07:37:16 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Time to Live (TTL) Processing in MPLS Networks 
                          (Updates RFC 3032)
	Author(s)	: P. Agarwal, B. Akyol
	Filename	: draft-ietf-mpls-ttl-03.txt
	Pages		: 8
	Date		: 20-Jun-02
	
This document describes TTL processing in hierarchical MPLS 
networks. It updates rfc-3032 'MPLS Label Stack Encoding'. TTL 
processing in both pipe and uniform model hierarchical tunnels are 
specified with examples for both 'push' and 'pop' cases. The 
document also complements rfc-3270 'MPLS Support of Differentiated 
Services' and ties together the terminology introduced in that 
document with TTL processing in hierarchical MPLS networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-ttl-03.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ttl-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020620141740.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ttl-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mpls-ttl-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020620141740.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jun 21 14:17:14 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25586
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 14:17:12 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmufx27077
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 18:17:40 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmufx25190;
	Fri, 21 Jun 2002 18:16:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmufx12991
	for mpls-outgoing; Fri, 21 Jun 2002 18:16:32 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmufx12983
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 18:16:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmufx20410
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:15:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmufx01387
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:15:11 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmufx01340
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:15:09 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00479
	for <mpls@UU.NET>; Fri, 21 Jun 2002 14:15:06 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22094
	for <mpls@UU.NET>; Fri, 21 Jun 2002 14:15:06 -0400 (EDT)
Message-ID: <3D136D38.54C8D7FF@marconi.com>
Date: Fri, 21 Jun 2002 14:15:20 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: IETF MPLS list <mpls@UU.NET>
Subject: Apparent contradiction in RSVP-TE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

In RFC 3209, section 4.7.4 (Resource Affinity Procedures), what is the
correct PathErr message to send out if resource affinities don't match?

In the first paragraph, it says that it should be a "policy control
failure" error, but it doesn't specify what policy-control subcode
should be used for the error value.

In the second paragraph, it says that it should be "routing problem"
with a subcode of "no route available towards destination."

On page 49, after the definition for the three tests, it also says that
it should be "routing problem" with a subcode of "no route available
towards desination."

My question is: which of the two errors is correct?  And if both are
correct, under what circumstances should one be used instead of the
other?

And when "policy control failure" is used, what should tbe policy-error
subcode be?  RFC 2750 defines a list of subcodes, but none are
applicable to resource affinities, and RFC 3209 doesn't define any new
codes.

-- David


From owner-mpls@UU.NET  Fri Jun 21 15:26:50 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28569
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 15:26:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmufy07185;
	Fri, 21 Jun 2002 18:30:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmufx13995
	for mpls-outgoing; Fri, 21 Jun 2002 18:29:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmufx13990
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 18:29:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmufx11728
	for <mpls@uu.net>; Fri, 21 Jun 2002 18:29:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmufx04858
	for <mpls@uu.net>; Fri, 21 Jun 2002 18:29:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmufx04851
	for <mpls@uu.net>; Fri, 21 Jun 2002 18:29:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09327 for <mpls@uu.net>; Fri, 21 Jun 2002 14:29:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA12435 for mpls@uu.net; Fri, 21 Jun 2002 14:29:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmufx13946
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 18:28:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmufx18806
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:26:57 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmufx29284
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:26:56 GMT
Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQmufx29267
	for <mpls@UU.NET>; Fri, 21 Jun 2002 18:26:56 GMT
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5LIQtL2022347
	for <mpls@UU.NET>; Fri, 21 Jun 2002 11:26:55 -0700 (PDT)
Received: from cisco.com (dhcp-171-69-39-155.cisco.com [171.69.39.155])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ADF45107;
	Fri, 21 Jun 2002 11:27:03 -0700 (PDT)
Message-ID: <3D136FEF.9010001@cisco.com>
Date: Fri, 21 Jun 2002 11:26:55 -0700
From: Bora Akyol <bora@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: Re: I-D ACTION:draft-ietf-mpls-ttl-03.txt
References: <200206211137.HAA08167@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

FYI

This draft has some minor changes requested by the IESG that includes:

1) Now Standards track
2) Split the references into normative and informative.

And it has already passed last call.

Bora

Internet-Drafts@ietf.org wrote:

>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		: Time to Live (TTL) Processing in MPLS Networks 
>                          (Updates RFC 3032)
>	Author(s)	: P. Agarwal, B. Akyol
>	Filename	: draft-ietf-mpls-ttl-03.txt
>	Pages		: 8
>	Date		: 20-Jun-02
>	
>This document describes TTL processing in hierarchical MPLS 
>networks. It updates rfc-3032 'MPLS Label Stack Encoding'. TTL 
>processing in both pipe and uniform model hierarchical tunnels are 
>specified with examples for both 'push' and 'pop' cases. The 
>document also complements rfc-3270 'MPLS Support of Differentiated 
>Services' and ties together the terminology introduced in that 
>document with TTL processing in hierarchical MPLS networks.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-03.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-ttl-03.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:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-mpls-ttl-03.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 owner-mpls@UU.NET  Fri Jun 21 15:34:11 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28980
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 15:34:11 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugc27684
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 19:34:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugc25456;
	Fri, 21 Jun 2002 19:34:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugc11305
	for mpls-outgoing; Fri, 21 Jun 2002 19:33:36 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmugc11300
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 19:33:34 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmugc04346
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:33:33 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugc21730
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:33:32 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQmugc21708
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:33:32 GMT
Message-ID: <3D137F8A.5A57C9C4@sandburst.com>
Date: Fri, 21 Jun 2002 15:33:30 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
Cc: IETF MPLS list <mpls@UU.NET>
Subject: Re: Apparent contradiction in RSVP-TE
References: <3D136D38.54C8D7FF@marconi.com>
Content-Type: multipart/alternative;
 boundary="------------1A5C4EBA94CB5972C52EEB4E"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------1A5C4EBA94CB5972C52EEB4E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

    The simplest answer is that policy control failure is not used.
Why don't we try using that answer?  :-)

--
Eric Gray

You wrote:

> In RFC 3209, section 4.7.4 (Resource Affinity Procedures), what is the
> correct PathErr message to send out if resource affinities don't match?
>
> In the first paragraph, it says that it should be a "policy control
> failure" error, but it doesn't specify what policy-control subcode
> should be used for the error value.
>
> In the second paragraph, it says that it should be "routing problem"
> with a subcode of "no route available towards destination."
>
> On page 49, after the definition for the three tests, it also says that
> it should be "routing problem" with a subcode of "no route available
> towards desination."
>
> My question is: which of the two errors is correct?  And if both are
> correct, under what circumstances should one be used instead of the
> other?
>
> And when "policy control failure" is used, what should tbe policy-error
> subcode be?  RFC 2750 defines a list of subcodes, but none are
> applicable to resource affinities, and RFC 3209 doesn't define any new
> codes.
>
> -- David



--------------1A5C4EBA94CB5972C52EEB4E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David,
<p>&nbsp;&nbsp;&nbsp; The simplest answer is that policy control failure
is not used.
<br>Why don't we try using that answer?&nbsp; :-)
<p>--
<br>Eric Gray
<p>You wrote:
<blockquote TYPE=CITE>In RFC 3209, section 4.7.4 (Resource Affinity Procedures),
what is the
<br>correct PathErr message to send out if resource affinities don't match?
<p>In the first paragraph, it says that it should be a "policy control
<br>failure" error, but it doesn't specify what policy-control subcode
<br>should be used for the error value.
<p>In the second paragraph, it says that it should be "routing problem"
<br>with a subcode of "no route available towards destination."
<p>On page 49, after the definition for the three tests, it also says that
<br>it should be "routing problem" with a subcode of "no route available
<br>towards desination."
<p>My question is: which of the two errors is correct?&nbsp; And if both
are
<br>correct, under what circumstances should one be used instead of the
<br>other?
<p>And when "policy control failure" is used, what should tbe policy-error
<br>subcode be?&nbsp; RFC 2750 defines a list of subcodes, but none are
<br>applicable to resource affinities, and RFC 3209 doesn't define any
new
<br>codes.
<p>-- David</blockquote>

<pre></pre>
&nbsp;</html>

--------------1A5C4EBA94CB5972C52EEB4E--



From owner-mpls@UU.NET  Fri Jun 21 15:45:59 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29412
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 15:45:59 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugd14486
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 19:46:27 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugc07764;
	Fri, 21 Jun 2002 19:43:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugc12002
	for mpls-outgoing; Fri, 21 Jun 2002 19:43:12 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmugc11992
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 19:42:58 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmugc03193
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:42:07 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugc01601
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:42:06 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmugc01590
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:42:06 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06734
	for <mpls@UU.NET>; Fri, 21 Jun 2002 15:42:04 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07857
	for <mpls@UU.NET>; Fri, 21 Jun 2002 15:42:05 -0400 (EDT)
Message-ID: <3D13819B.8020003@marconi.com>
Date: Fri, 21 Jun 2002 15:42:19 -0400
From: David Charlap <david.charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: IETF MPLS list <mpls@UU.NET>
Subject: Re: Apparent contradiction in RSVP-TE
References: <3D136D38.54C8D7FF@marconi.com> <3D137F8A.5A57C9C4@sandburst.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric Gray wrote:
> David,
> 
>     The simplest answer is that policy control failure is not used.
> Why don't we try using that answer?  :-)

That was my gut feeling as well.  But I want to make sure the consensus 
of this group agrees as well.

-- David




From owner-mpls@UU.NET  Fri Jun 21 16:00:45 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29812
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 16:00:45 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuge03050
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 20:01:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugd27399;
	Fri, 21 Jun 2002 19:59:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugd13412
	for mpls-outgoing; Fri, 21 Jun 2002 19:58:53 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmugd13400
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 19:58:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmugd27303
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:58:24 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugd24238
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:58:23 GMT
Received: from riverstonenet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.riverstonenet.com [63.113.148.10])
	id QQmugd24234
	for <mpls@UU.NET>; Fri, 21 Jun 2002 19:58:23 GMT
Received: from cell.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago)
	id MAA19491; Fri, 21 Jun 2002 12:58:22 -0700 (PDT)
From: srikrish@riverstonenet.com (Srikrishna Venkataraman)
Received: (from srikrish@localhost)
	by cell.yagosys.com (8.8.8+Sun/8.8.8) id MAA12430
	for mpls@UU.NET; Fri, 21 Jun 2002 12:58:22 -0700 (PDT)
Date: Fri, 21 Jun 2002 12:58:22 -0700 (PDT)
Message-Id: <200206211958.MAA12430@cell.yagosys.com>
To: mpls@UU.NET
Subject: target ldp question:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: RrCsDicBPIt6t6eKwEFXAQ==
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

I have a configuration as shown below:

R1-----------R--------R2

There is an extended session between R1 & R2.
R2 learns of New routes from R1 through the middle
router.
Will R2 send out labels for the new routes to R1?


thanks


From owner-mpls@UU.NET  Fri Jun 21 16:25:40 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00422
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 16:25:36 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugf14684
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 20:26:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugf11076;
	Fri, 21 Jun 2002 20:24:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugf07464
	for mpls-outgoing; Fri, 21 Jun 2002 20:24:13 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmugf07454
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 20:24:12 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmugf06602
	for <mpls@UU.NET>; Fri, 21 Jun 2002 20:23:14 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugf10170
	for <mpls@UU.NET>; Fri, 21 Jun 2002 20:23:14 GMT
Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged))
	id QQmugf10161
	for <mpls@UU.NET>; Fri, 21 Jun 2002 20:23:13 GMT
Received: from jkarthik-pc.avici.com (jkarthik-pc.avici.com [10.2.22.72])
	by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g5LKN8n20436;
	Fri, 21 Jun 2002 16:23:08 -0400 (EDT)
Message-Id: <5.0.2.1.2.20020621161930.00af0310@mailhost.avici.com>
X-Sender: jkarthik@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 21 Jun 2002 16:26:13 -0400
To: srikrish@riverstonenet.com (Srikrishna Venkataraman), mpls@UU.NET
From: Jay Karthik <jkarthik@avici.com>
Subject: Re: target ldp question:
In-Reply-To: <200206211958.MAA12430@cell.yagosys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Yes, R2 will send out label mappings to R1, provided the method of label 
distribution is downstream unsolicited. (This is regardless of whether R1 
initially sends R2 the label mappings for the corresponding FECs)

Jay

At 12:58 PM 6/21/02 -0700, Srikrishna Venkataraman wrote:
>Hi
>
>I have a configuration as shown below:
>
>R1-----------R--------R2
>
>There is an extended session between R1 & R2.
>R2 learns of New routes from R1 through the middle
>router.
>Will R2 send out labels for the new routes to R1?
>
>
>thanks



From owner-mpls@UU.NET  Fri Jun 21 16:32:04 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00607
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 16:32:03 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugg29478
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 20:32:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugf15246;
	Fri, 21 Jun 2002 20:26:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugf07569
	for mpls-outgoing; Fri, 21 Jun 2002 20:25:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmugf07541
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 20:25:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmugf03086
	for <mpls@uu.net>; Fri, 21 Jun 2002 20:21:16 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugf24931
	for <mpls@uu.net>; Fri, 21 Jun 2002 20:21:16 GMT
Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57])
	id QQmugf24915
	for <mpls@uu.net>; Fri, 21 Jun 2002 20:21:15 GMT
Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LKLDv01788;
	Fri, 21 Jun 2002 16:21:13 -0400 (EDT)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id NFR0XM4M; Fri, 21 Jun 2002 16:21:13 -0400
Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id N12LGSHW; Fri, 21 Jun 2002 16:21:12 -0400
Message-ID: <3D138ABA.8D85B366@nortelnetworks.com>
Date: Fri, 21 Jun 2002 16:21:14 -0400
From: Rajesh Potti <rpotti@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
CC: tbates@cisco.com, yakov@cisco.com
Subject: Multiprotocol extensions to BGP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,

 What is the maximum  number of prefixes that can be included in the
MP_UNREACH_NLRI attribute of an update?  And how many prefixes
 can be send in the MP_REACH_NLRI attribute of a BGP update message?

 I looked at  RFC 2858 (Multiprotocol Extensions to BGP-4), but could
not see a limit specified.

Thanks,
Rajesh



From owner-mpls@UU.NET  Fri Jun 21 17:37:34 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02154
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 17:37:32 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugj11110
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 21:28:53 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugj07375;
	Fri, 21 Jun 2002 21:27:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugj04861
	for mpls-outgoing; Fri, 21 Jun 2002 21:27:00 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmugj04856
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 21:26:57 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmugj28711
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:26:44 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugj21603
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:26:44 GMT
Received: from web21006.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web21006.mail.yahoo.com [216.136.227.60])
	id QQmugj21595
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:26:43 GMT
Message-ID: <20020621212641.33651.qmail@web21006.mail.yahoo.com>
Received: from [204.192.44.242] by web21006.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 14:26:41 PDT
Date: Fri, 21 Jun 2002 14:26:41 -0700 (PDT)
From: Carlos Patriawan <carlos_mpls@yahoo.com>
Subject: Re: target ldp question:
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

The requirement for router("r" in below ase) between 2
targeted session peer is capable of mpls forwarding. 

Question: in the case where R2 as the egress for FEC x
and R2 assigns label 0 as label binding for fec x on
its session with R1 ;  now  If transit LSR 'r'
forward the mpls frame(w/ label 0) to R1, does it
violate the RFC since RFC says LSR has to pop mpls
frame w/ label 0 ?


carlos


----
Jay Karthik wrote:

   Yes, R2 will send out label mappings to R1,
provided the method of label
   distribution is downstream unsolicited. (This is
regardless of whether R1
   initially sends R2 the label mappings for the
corresponding FECs)

   Jay

   At 12:58 PM 6/21/02 -0700, Srikrishna Venkataraman
wrote:
   >Hi
   >
   >I have a configuration as shown below:
   >
   >R1-----------R--------R2
   >
   >There is an extended session between R1 & R2.
   >R2 learns of New routes from R1 through the middle
   >router.
   >Will R2 send out labels for the new routes to R1?
   >
   >
   >thanks

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-mpls@UU.NET  Fri Jun 21 17:45:33 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02240
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 17:45:32 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugl06769
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 21:45:59 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugl04763;
	Fri, 21 Jun 2002 21:45:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugk05982
	for mpls-outgoing; Fri, 21 Jun 2002 21:44:39 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmugk05977
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 21 Jun 2002 21:44:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmugk16274
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:44:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugk04195
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:44:23 GMT
Received: from presque.djinesys.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.211.218.216])
	id QQmugk04191
	for <mpls@uu.net>; Fri, 21 Jun 2002 21:44:23 GMT
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id g5LLiMV74159
	for mpls@uu.net; Fri, 21 Jun 2002 17:44:22 -0400 (EDT)
	(envelope-from mrr@mrichardson.nexthop.com)
Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g5LLiJ974152
	for <mpls@UU.NET>; Fri, 21 Jun 2002 17:44:19 -0400 (EDT)
	(envelope-from mrr@mrichardson.nexthop.com)
Received: (from mrr@localhost)
	by paradigm.nexthop.com (8.11.6/8.11.6) id g5LLiJU00705
	for mpls@UU.NET; Fri, 21 Jun 2002 17:44:19 -0400 (EDT)
Date: Fri, 21 Jun 2002 17:44:19 -0400
From: Mathew Richardson <mrr@nexthop.com>
To: mpls@UU.NET
Subject: Re: Multiprotocol extensions to BGP
Message-ID: <20020621174419.A322@nexthop.com>
References: <3D138ABA.8D85B366@nortelnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3D138ABA.8D85B366@nortelnetworks.com>; from rpotti@nortelnetworks.com on Fri, Jun 21, 2002 at 04:21:14PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-mpls@UU.NET
Precedence: bulk

> Rajesh Potti <rpotti@nortelnetworks.com> [Fri, Jun 21, 2002 at 04:21:14PM -0400]:
>
>Hi,
>
> What is the maximum  number of prefixes that can be included in the
>MP_UNREACH_NLRI attribute of an update?  And how many prefixes
> can be send in the MP_REACH_NLRI attribute of a BGP update message?
>
> I looked at  RFC 2858 (Multiprotocol Extensions to BGP-4), but could
>not see a limit specified.

<snip>

There is no explicit limit; however, the maximum size of a BGP Update
message is 4096 octets, so there _is_ a limite.  The exact number that
can be included will depend on the number of octets consumed by
other path attributes.

mrr


From owner-mpls@UU.NET  Fri Jun 21 20:49:59 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05491
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 20:49:58 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugx10378
	for <mpls-archive@lists.ietf.org>; Sat, 22 Jun 2002 00:50:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugx07685;
	Sat, 22 Jun 2002 00:49:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugx26369
	for mpls-outgoing; Sat, 22 Jun 2002 00:49:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmugx26358
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 22 Jun 2002 00:49:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmugx10597
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:48:55 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugx06640
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:48:54 GMT
Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f28.law15.hotmail.com [64.4.23.28])
	id QQmugx06612
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:48:53 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 21 Jun 2002 17:48:53 -0700
Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP;
	Sat, 22 Jun 2002 00:48:52 GMT
X-Originating-IP: [12.234.67.129]
From: "Chetan Pinto" <chetanpinto@hotmail.com>
To: mpls@UU.NET
Cc: chetanpinto@hotmail.com
Subject: Ships in the Night operation on ATM-LSRs
Date: Fri, 21 Jun 2002 17:48:52 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F28CRBHZXFZ0stgr3SU00001ad7@hotmail.com>
X-OriginalArrivalTime: 22 Jun 2002 00:48:53.0071 (UTC) FILETIME=[94B09DF0:01C21986]
Sender: owner-mpls@UU.NET
Precedence: bulk

There are ATM LSRs that support Ships in the Night operation
on ATM interfaces. Thus these ATM interfaces are also LC-ATM interfaces

The vpi/vci range on an ATM interface is shared between MPLS and other
applications and each application is aware of the range available to it.

The label [vpi/vci] range in case of LDP is
negotiated during the LDP initializaion phase between
two LDP peers on the ATM link connecting the two.

As far as the LDP session state machine is concerned
negotiation of parameters is restricted to the Initialization phase.

Considering a case wherein one of the ATM applications relinquishes
it's label range [i.e. the user no longer needs to use that
application]. The user then has a choice of lending the freed range
to another ATM application. When doing so, MPLS could also be one of
those candidate applications. At the same time it is assumed that a
similar action  is taking place on the other end of the ATM link.

Hence, LDP could get a larger share of the vpi/vci range than
it was previously using. This could solve the scarce label resources
[if any at that time] issue under this scenario.

But at the same time it is to be noted that the above mentioned
situation is encountered relatively rare or is it that there no user
bothered about such a scenario.

Is it worthwhile considering this case, as this might be a one time
migration scenario?
If not, this can be rested to oblivion

Else there are two cases of solving this.
In the first case, the LDP session between the two peers is shutdown
and they are re-configured so as to accomodate the increased vpi/vci
label range. This involves unnecessary disruption in already established
LSPs passing thro' the two peers. Albeit there is a solution proposed
that intends to maintain LSPs across LSR restarts

In the second solution, can we think of a new message "Re-init" message
that needs to be exchanged by the two peers periodically until
both of them ACK each others increased label range via a new Status code
added to the Notification message. This can then be applied generally
to newer negotiations without having to re-start the LDP session.

Obviously, a decrease in the label range allocated to MPLS cannot be taken
care of until those labels in the range removed from LDP have been released

Thanks
chetan

############################################################
Chetan Francis Pinto
Phone : Res : 408-244-1352
############################################################

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From owner-mpls@UU.NET  Fri Jun 21 22:53:30 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08069
	for <mpls-archive@lists.ietf.org>; Fri, 21 Jun 2002 22:53:29 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugw17338
	for <mpls-archive@lists.ietf.org>; Sat, 22 Jun 2002 00:30:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmugv14500;
	Sat, 22 Jun 2002 00:28:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmugv24530
	for mpls-outgoing; Sat, 22 Jun 2002 00:28:33 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmugv24525
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 22 Jun 2002 00:28:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmugv08896
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:28:10 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmugv13939
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:28:10 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f26.law15.hotmail.com [64.4.23.26])
	id QQmugv13931
	for <mpls@UU.NET>; Sat, 22 Jun 2002 00:28:09 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 21 Jun 2002 17:28:08 -0700
Received: from 12.234.67.129 by lw15fd.law15.hotmail.msn.com with HTTP;
	Sat, 22 Jun 2002 00:28:07 GMT
X-Originating-IP: [12.234.67.129]
From: "Chetan Pinto" <chetanpinto@hotmail.com>
To: carlos_mpls@yahoo.com, mpls@UU.NET
Subject: Re: target ldp question:
Date: Fri, 21 Jun 2002 17:28:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F26mz8Phg8VMb5UWgP100000673@hotmail.com>
X-OriginalArrivalTime: 22 Jun 2002 00:28:08.0796 (UTC) FILETIME=[AF0B51C0:01C21983]
Sender: owner-mpls@UU.NET
Precedence: bulk

>The requirement for router("r" in below ase) between 2
>targeted session peer is capable of mpls forwarding.
>
>Question: in the case where R2 as the egress for FEC x
>and R2 assigns label 0 as label binding for fec x on
>its session with R1 ;  now  If transit LSR 'r'
>forward the mpls frame(w/ label 0) to R1, does it
>violate the RFC since RFC says LSR has to pop mpls
>frame w/ label 0 ?

First of all R1 needs to forward the frame to 'r'.
I think this is what u meant [not the other way around]

At R1, there needs be a 2 level label stack for the LSP
corresponding to FEC x outgoing towards r
The bottom most is the one corresponding R2's label [value = 0]
The top most is the one corresponding to r's label [value = 'a']

When the MPLS packet reaches 'r', it replaces 'a' by
some label distributed by R2 [say 'b'] corresponding to FEC 'x'

'r' should never look at the bottom-most label in this case
as it does not understand it [at least in this case]

And the job of popping the label '0' is that of R2

If b is 3, 'r' should not send the top-most label
but pop the remains i.e. label = 0
Well there might be some discrepancy in here
Even though a label value of 0 is just to do IP forwarding,
does it make sense to do so even though R2 never distributed 0 to r?

chetan

>
>
>carlos
>
>
>----
>Jay Karthik wrote:
>
>    Yes, R2 will send out label mappings to R1,
>provided the method of label
>    distribution is downstream unsolicited. (This is
>regardless of whether R1
>    initially sends R2 the label mappings for the
>corresponding FECs)
>
>    Jay
>
>    At 12:58 PM 6/21/02 -0700, Srikrishna Venkataraman
>wrote:
>    >Hi
>    >
>    >I have a configuration as shown below:
>    >
>    >R1-----------R--------R2
>    >
>    >There is an extended session between R1 & R2.
>    >R2 learns of New routes from R1 through the middle
>    >router.
>    >Will R2 send out labels for the new routes to R1?
>    >
>    >
>    >thanks
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
>http://fifaworldcup.yahoo.com


############################################################
Chetan Francis Pinto
Phone : Res : 408-244-1352
############################################################

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From owner-mpls@UU.NET  Sun Jun 23 11:56:17 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29174
	for <mpls-archive@lists.ietf.org>; Sun, 23 Jun 2002 11:56:17 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmumx25087
	for <mpls-archive@lists.ietf.org>; Sun, 23 Jun 2002 15:56:55 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmumx23009;
	Sun, 23 Jun 2002 15:55:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmumx10310
	for mpls-outgoing; Sun, 23 Jun 2002 15:55:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmumx10305
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 23 Jun 2002 15:55:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmumx22493
	for <mpls@UU.NET>; Sun, 23 Jun 2002 15:55:19 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmumx08951
	for <mpls@UU.NET>; Sun, 23 Jun 2002 15:55:18 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQmumx08947
	for <mpls@UU.NET>; Sun, 23 Jun 2002 15:55:18 GMT
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g5NFt6m51131;
	Sun, 23 Jun 2002 08:55:06 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200206231555.g5NFt6m51131@merlot.juniper.net>
To: "Adrian Farrel" <afarrel@movaz.com>
cc: "mpls wg" <mpls@UU.NET>, "Yakov Rekhter" <yakov@juniper.net>,
        rahul@redback.com, manoj@juniper.net
Subject: Re: wg last call draft-ietf-mpls-ldp-restart-02.txt 
In-Reply-To: Your message of "Fri, 21 Jun 2002 00:47:42 EDT."
             <003201c218e2$924eaba0$9e13588a@movaz.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5419.1024847706.1@juniper.net>
Date: Sun, 23 Jun 2002 08:55:06 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Adrian,

> Hi,
> I have some comments which are mainly requests for clarification to be =
> added to the draft.  I'm sorry to raise them at this late stage, but =
> better now than even later...
> 
> 1. It would be nice if you made it clear up front that=20
>    this draft applies only to DU.  Currently this is=20
>    tucked away in para 3 of section 6.

Done (the text is moved to both the Abstract and the Movitation
sections.

> 2. In the first line of 6.1.1 could you say that "the
>    Mapping message" is a "newly received Mapping message"?

Done (as you suggested).

> 3. It would be helpful to add some text to cover processing
>    of other messages while an LSR is in the process of=20
>    restarting: in particular Withdraw and Release.  Although
>    this is pretty obvious, I believe you run the risk of
>    failure to interop correctly unless you spell it out: viz.
>    Withdraw should match in table, delete from table and=20
>    send Withdraw upstream as required
>    Release should match in table, if entry is stale should
>    ignore, if entry is not stale should process according
>    to normal Release procedures on local node.

please proposed the text, and I'll add it to the draft.

> 4. It would be nice if you exposed that all Address messages
>    need to be exchanged before the downstream node starts=20
>    resending Mapping messages.  Section 6.1.1 is based on the
>    assumption that these messages have been received.

please propose the text and I'll add it to the draft.

> 5. Is it normal procedure to give suggested values for all
>    timers in drafts?

not sure.

> 6. Section 6 states that there is an assumption that IP
>    forwarding state is preserved in parallel to MPLS=20
>    forwarding state.  I looked hard for a reference to this
>    in the text and only found the case of the restarting=20
>    Egress LSR needing to look up the next hop of a FEC if
>    it is also configured to generate a non-null, unique
>    label for such a FEC.  Further this only applies if the
>    FEC is of the type that has its next hop determined
>    through the IP forwarding table.
>    This seems much weaker than the statement in section 6.

I clarified this in Section 6.

> As a general question, has anyone done any analysis of how long it would =
> take to redistribute all of the addresses and labels on a router in a =
> large network?  In other words, what is a reasonable bound for the =
> Recovery Time?  (Note that the neighbors can't start re-using labels =
> until the Recovery Time is complete.)

Among other things, it depends on the processing power of the control plane.

Yakov.


From owner-mpls@UU.NET  Mon Jun 24 11:02:06 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10638
	for <mpls-archive@lists.ietf.org>; Mon, 24 Jun 2002 11:02:05 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuqm24140
	for <mpls-archive@lists.ietf.org>; Mon, 24 Jun 2002 15:02:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuqm20695;
	Mon, 24 Jun 2002 15:01:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuqm26763
	for mpls-outgoing; Mon, 24 Jun 2002 15:00:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuqm26748
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Jun 2002 15:00:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuqm20357
	for <mpls@UU.NET>; Mon, 24 Jun 2002 15:00:22 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuqm09688
	for <mpls@UU.NET>; Mon, 24 Jun 2002 15:00:22 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmuqm09684
	for <mpls@UU.NET>; Mon, 24 Jun 2002 15:00:22 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29144
	for <mpls@UU.NET>; Mon, 24 Jun 2002 11:00:20 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10724
	for <mpls@UU.NET>; Mon, 24 Jun 2002 11:00:20 -0400 (EDT)
Message-ID: <3D17341C.1020600@marconi.com>
Date: Mon, 24 Jun 2002 11:00:44 -0400
From: David Charlap <david.charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Ships in the Night operation on ATM-LSRs
References: <F28CRBHZXFZ0stgr3SU00001ad7@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Chetan Pinto wrote:
> There are ATM LSRs that support Ships in the Night operation
> on ATM interfaces. Thus these ATM interfaces are also LC-ATM interfaces
> 
> The vpi/vci range on an ATM interface is shared between MPLS and other
> applications and each application is aware of the range available to it.
> 
> The label [vpi/vci] range in case of LDP is
> negotiated during the LDP initializaion phase between
> two LDP peers on the ATM link connecting the two.
> 
> As far as the LDP session state machine is concerned
> negotiation of parameters is restricted to the Initialization phase.
> 
> Considering a case wherein one of the ATM applications relinquishes
> it's label range [i.e. the user no longer needs to use that
> application]. The user then has a choice of lending the freed range
> to another ATM application. When doing so, MPLS could also be one of
> those candidate applications. At the same time it is assumed that a
> similar action  is taking place on the other end of the ATM link.

This presumes that the label space is partitioned.  This isn't really a 
requirement.

Every MPLS protocol can advertise the full label range without fear of 
the two stepping on each other.  The neighbor router will always know 
what labels are in-use, since ATM labels (VCIDs) are always 
per-interface, so you won't ever see one label assigned to two protocols.

Label space partitioning for SIN is for administrative purposes, not 
technical ones.  Similarly for anybody who wants to partition the label 
space among several MPLS protocols.  Given this, it is unlikely that 
this space will re-partition very often.  If the overhead of 
repartitioning is unacceptible, I'd look at the LDP graceful restart 
draft (draft-ietf-mpls-ldp-restart-02.txt and consider using that to 
minimize the impact of restarting LDP, rather than changing LDP.

-- David



From owner-mpls@UU.NET  Mon Jun 24 11:27:03 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11903
	for <mpls-archive@lists.ietf.org>; Mon, 24 Jun 2002 11:27:03 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuqm14732
	for <mpls-archive@lists.ietf.org>; Mon, 24 Jun 2002 15:05:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuqm11614;
	Mon, 24 Jun 2002 15:04:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuqm05825
	for mpls-outgoing; Mon, 24 Jun 2002 15:03:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuqm05811
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Jun 2002 15:03:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuqm25760
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:02:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuqm10547
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:02:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmuqm10543
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:02:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA22295 for <mpls@uu.net>; Mon, 24 Jun 2002 11:02:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA18001 for mpls@uu.net; Mon, 24 Jun 2002 11:02:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuqm26720
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 24 Jun 2002 15:00:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmuqm20760
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:00:29 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuqm28539
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:00:29 GMT
Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmuqm28481
	for <mpls@uu.net>; Mon, 24 Jun 2002 15:00:23 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10494;
	Mon, 24 Jun 2002 10:59:38 -0400 (EDT)
Message-Id: <200206241459.KAA10494@ietf.org>
To: IETF-Announce:;
Cc: mpls@UU.NET
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: Time to Live (TTL) Processing in MPLS Networks 
	   (Updates RFC 3032) to Proposed Standard
Reply-to: iesg@ietf.org
Date: Mon, 24 Jun 2002 10:59:38 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk


The IESG has received a request from the Multiprotocol Label Switching 
Working Group to consider Time to Live (TTL) Processing in MPLS 
Networks (Updates RFC 3032) <draft-ietf-mpls-ttl-03.txt> as a Proposed 
Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by July 8, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ttl-03.txt





From owner-mpls@UU.NET  Tue Jun 25 06:55:05 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28808
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 06:55:05 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmutn03106
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 10:52:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmutn01654;
	Tue, 25 Jun 2002 10:52:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmutn16774
	for mpls-outgoing; Tue, 25 Jun 2002 10:51:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmutn16767
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Jun 2002 10:51:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmutn19413
	for <mpls@UU.NET>; Tue, 25 Jun 2002 10:51:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmutn01101
	for <mpls@UU.NET>; Tue, 25 Jun 2002 10:51:17 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQmutn01074
	for <mpls@UU.NET>; Tue, 25 Jun 2002 10:51:16 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <NF2H59Q3>; Tue, 25 Jun 2002 16:23:02 +0530
Message-ID: <55E277B99171E041ABF5F4B1C6DDCA062DD00C@HARITHA>
From: "Kannan S (Networking) - CTD, Chennai." <kannans@ctd.hcltech.com>
To: mpls@UU.NET
Subject: LSR MIB - XCEntry
Date: Tue, 25 Jun 2002 16:23:15 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Can somebody tell me what I am missing here ?

I was wondering if makes sense to have 
mplsInSegmentXCIndex object in MplsInSegmentEntry as read-create and
remove the <mplsInSegmentIfIndex, mplsInSegmentLabel> from the mplsXCEntry
INDEX.

I am asking this because, 
In multiple insegment entries cross connected with one outsegment entry
case, it works fine.
if we use multiple outsegment entries, we need to create multiple cross
connect entries with all possible combinations, also provide administrative
control to enable / disable each of the combinations. 
Isnt it good enough to say - these are the InSegments that belong to the
<LSP/Crossconnect Index>, and these are the <OutLabelStack +
OutSegmentEntry> (XCEntries) entries for the <LSP / Crossconnect Index> ...
and let the LSR use whatever mechanism to choose which of the <OutLabel +
OutSegmentEntry> entries to use.

I am trying to reason out the rationale behind the current design ..

Is it because administrative control (disable / enable) is required at
various combinations / preclude certain combinations of In and Out segment
entries ?

Or is it this way because it is more readable ?

I understand we wont be able to call it XC , if we made the change.
I also understand that I could internally maintain it anyway, as long as I
am able to provide the interface.


TIA,
Kans.


From owner-mpls@UU.NET  Tue Jun 25 07:08:26 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00024
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 07:08:26 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuto14757
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 11:09:08 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuto11288;
	Tue, 25 Jun 2002 11:07:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuto08923
	for mpls-outgoing; Tue, 25 Jun 2002 11:07:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmuto08918
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Jun 2002 11:07:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmuto15572
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:07:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuto27005
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:07:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmuto26999
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:07:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA25160 for <mpls@uu.net>; Tue, 25 Jun 2002 07:07:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA13478 for mpls@uu.net; Tue, 25 Jun 2002 07:07:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmuto08361
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Jun 2002 11:06:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmuto13795
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:06:12 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuto16777
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:06:12 GMT
Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmuto16768
	for <mpls@uu.net>; Tue, 25 Jun 2002 11:06:12 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29839;
	Tue, 25 Jun 2002 07:04:16 -0400 (EDT)
Message-Id: <200206251104.HAA29839@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-kuwahara-cl-tunneling-vpn-00.txt
Date: Tue, 25 Jun 2002 07:04:16 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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		: Scalable Connectionless Tunneling Architecture and 
                          Protocols for VPNs
	Author(s)	: T. Kuwahara et al.
	Filename	: draft-kuwahara-cl-tunneling-vpn-00.txt
	Pages		: 27
	Date		: 19-Jun-01
	
This document defines a connectionless tunneling architecture that is
applicable to provider provisioned virtual private networks (PPVPNs)
and specifies protocols for implementing it.  This architecture is
designed to facilitate scalable operation, load balancing, and high
reliability.  A prominent feature of it is to provide VPN tunnels
over a connectionless network.  Since a connectionless network can
provide full mesh connectivity without a connection establishing
procedure, the architecture enables scalable operation of a VPN more
efficiently than connection-oriented tunneling technologies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kuwahara-cl-tunneling-vpn-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-kuwahara-cl-tunneling-vpn-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kuwahara-cl-tunneling-vpn-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020624080821.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-kuwahara-cl-tunneling-vpn-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kuwahara-cl-tunneling-vpn-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020624080821.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jun 25 08:49:00 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03298
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 08:49:00 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmutv27122
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 12:49:36 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmutv24863;
	Tue, 25 Jun 2002 12:48:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmutv10122
	for mpls-outgoing; Tue, 25 Jun 2002 12:48:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmutv10113
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Jun 2002 12:48:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmutv28677
	for <mpls@UU.NET>; Tue, 25 Jun 2002 12:47:32 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmutv27365
	for <mpls@UU.NET>; Tue, 25 Jun 2002 12:47:32 GMT
Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmutv27355
	for <mpls@UU.NET>; Tue, 25 Jun 2002 12:47:32 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5PCk42g026609;
	Tue, 25 Jun 2002 08:46:04 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (kiellor.cisco.com [10.83.99.125])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF11326;
	Tue, 25 Jun 2002 08:45:32 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020625084056.01eccce8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Jun 2002 08:45:31 -0400
To: "Kannan S (Networking) - CTD, Chennai." <kannans@ctd.hcltech.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: LSR MIB - XCEntry
Cc: mpls@UU.NET
In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA062DD00C@HARITHA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



>Can somebody tell me what I am missing here ?
>
>I was wondering if makes sense to have
>mplsInSegmentXCIndex object in MplsInSegmentEntry as read-create and
>remove the <mplsInSegmentIfIndex, mplsInSegmentLabel> from the mplsXCEntry
>INDEX.
>
>I am asking this because,
>In multiple insegment entries cross connected with one outsegment entry
>case, it works fine.
>if we use multiple outsegment entries, we need to create multiple cross
>connect entries with all possible combinations, also provide administrative
>control to enable / disable each of the combinations.

         Not necessarily. Have you considered using the same
XCIndex, mplsInSegmentIfIndex, mplsInSegmentLabel, but a
different outSegmentIndex?

>Isnt it good enough to say - these are the InSegments that belong to the
><LSP/Crossconnect Index>, and these are the <OutLabelStack +
>OutSegmentEntry> (XCEntries) entries for the <LSP / Crossconnect Index> ...
>and let the LSR use whatever mechanism to choose which of the <OutLabel +
>OutSegmentEntry> entries to use.

         I think that the indexing I showed above will satisfy this. Just 
disable
the XCentry (or entries) whose XCindex = the one used to group all segments
together.

>I am trying to reason out the rationale behind the current design ..
>
>Is it because administrative control (disable / enable) is required at
>various combinations / preclude certain combinations of In and Out segment
>entries ?

         Admin control is given on the cross-connect because this
is what binds together (associates) the incoming label(s) with
the outgoing label(s).  If you have a multi-point to multi-point
LSP, you can quickly disable/enable it.

         --Tom


>Or is it this way because it is more readable ?
>
>I understand we wont be able to call it XC , if we made the change.
>I also understand that I could internally maintain it anyway, as long as I
>am able to provide the interface.
>
>
>TIA,
>Kans.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Tue Jun 25 17:22:20 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29419
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 17:22:20 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuuz11252
	for <mpls-archive@lists.ietf.org>; Tue, 25 Jun 2002 20:22:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuuz10362;
	Tue, 25 Jun 2002 20:22:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuuz15682
	for mpls-outgoing; Tue, 25 Jun 2002 20:21:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuuz15673
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 25 Jun 2002 20:21:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuuz24258
	for <mpls@uu.net>; Tue, 25 Jun 2002 20:20:12 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuuz09176
	for <mpls@uu.net>; Tue, 25 Jun 2002 20:20:11 GMT
Received: from excalibur.santera.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: exchange.santera.com [4.22.157.11])
	id QQmuuz09158
	for <mpls@uu.net>; Tue, 25 Jun 2002 20:20:11 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: MPLS-DS-TE-MIB?
Date: Tue, 25 Jun 2002 15:20:06 -0500
Message-ID: <CD110021698980419241042CF576B8F20188F136@EXCALIBUR.santera.com>
Thread-Topic: MPLS-DS-TE-MIB?
Thread-Index: AcIchbEWwt4hN+exQoGnM6vsx9NxzA==
From: "Zhu, Rupert" <rupert.zhu@santera.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA29419

Hi,

The July/2001 version of MPLS-DS-TE-MIB draft has expaired.
But I failed to find the current draft from IETF web site.
Does anyone know the status of this draft?

To the authors, there are two typos in July/2001 version.

1. In mplsDsTeIfMaxAddrUnresBw,  "Addr" really means "Aggr", I think.

2. The object MplsDsTeIfClassTypeEntry is defined twice.  Seems that the
   second occurrence should be "MplsDsTeLspEntry" instead.

Perhaps these can be corrected in the next revision.

Thanks!

-- Rupert


From owner-mpls@UU.NET  Wed Jun 26 06:05:38 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09447
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 06:05:38 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuwz24394
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 09:23:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuwz22090;
	Wed, 26 Jun 2002 09:22:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuwz00917
	for mpls-outgoing; Wed, 26 Jun 2002 09:21:50 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuwz00912
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Jun 2002 09:21:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuwz05989
	for <mpls@uu.net>; Wed, 26 Jun 2002 09:21:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuwz25500
	for <mpls@uu.net>; Wed, 26 Jun 2002 09:21:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmuwz25483
	for <mpls@uu.net>; Wed, 26 Jun 2002 09:21:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA09811 for <mpls@uu.net>; Wed, 26 Jun 2002 05:21:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA23162 for mpls@uu.net; Wed, 26 Jun 2002 05:21:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmuwz00756
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Jun 2002 09:20:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuwz21290
	for <mpls@UU.NET>; Wed, 26 Jun 2002 09:19:02 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuwz24357
	for <mpls@UU.NET>; Wed, 26 Jun 2002 09:19:02 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: europe.cisco.com [144.254.52.73])
	id QQmuwz24351
	for <mpls@UU.NET>; Wed, 26 Jun 2002 09:19:02 GMT
Received: from FLEFAUCH-W2K.cisco.com (dhcp-nic-val-26-85.cisco.com [64.103.26.85])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA06594;
	Wed, 26 Jun 2002 11:18:56 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20020626110918.01d35da0@europe.cisco.com>
X-Sender: flefauch@europe.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Jun 2002 11:16:16 +0200
To: "Zhu, Rupert" <rupert.zhu@santera.com>, Sanjaya.Choudhury@marconi.com,
        tnadeau@cisco.com
From: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: MPLS-DS-TE-MIB?
Cc: <mpls@UU.NET>
In-Reply-To: <CD110021698980419241042CF576B8F20188F136@EXCALIBUR.santera
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Rupert,
thanks for your comments.
Tom and Sanjaya were planning to lead the work to bring draft DS-TE-MIB in 
line with latest DS-TE protocol spec. I will defer to them for an update on 
that.
Francois


At 15:20 25/06/2002 -0500, Zhu, Rupert wrote:
>Hi,
>
>The July/2001 version of MPLS-DS-TE-MIB draft has expaired.
>But I failed to find the current draft from IETF web site.
>Does anyone know the status of this draft?
>
>To the authors, there are two typos in July/2001 version.
>
>1. In mplsDsTeIfMaxAddrUnresBw,  "Addr" really means "Aggr", I think.
>
>2. The object MplsDsTeIfClassTypeEntry is defined twice.  Seems that the
>    second occurrence should be "MplsDsTeLspEntry" instead.
>
>Perhaps these can be corrected in the next revision.
>
>Thanks!
>
>-- Rupert



From owner-mpls@UU.NET  Wed Jun 26 07:12:22 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12003
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 07:12:22 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxg10479
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 11:13:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuxg09107;
	Wed, 26 Jun 2002 11:12:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuxg23025
	for mpls-outgoing; Wed, 26 Jun 2002 11:11:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmuxg23010
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Jun 2002 11:11:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuxg24923
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:11:41 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxg08880
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:11:41 GMT
Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmuxg08876
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:11:41 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5QBC7It007026;
	Wed, 26 Jun 2002 07:12:08 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF27271;
	Wed, 26 Jun 2002 07:11:34 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020626071014.01dceb18@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Jun 2002 07:11:32 -0400
To: Francois Le Faucheur <flefauch@cisco.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: MPLS-DS-TE-MIB?
Cc: "Zhu, Rupert" <rupert.zhu@santera.com>, Sanjaya.Choudhury@marconi.com,
        <mpls@UU.NET>
In-Reply-To: <4.3.2.7.2.20020626110918.01d35da0@europe.cisco.com>
References: <CD110021698980419241042CF576B8F20188F136@EXCALIBUR.santera .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



>thanks for your comments.
>Tom and Sanjaya were planning to lead the work to bring draft DS-TE-MIB in 
>line with latest DS-TE protocol spec. I will defer to them for an update 
>on that.
>Francois

         Hi,

         Francois is correct that we are leading the MIB work, although it has
been delayed a bit as I have been swamped with other things. We will
certainly incorporate your comments.

         --Tom


>At 15:20 25/06/2002 -0500, Zhu, Rupert wrote:
>>Hi,
>>
>>The July/2001 version of MPLS-DS-TE-MIB draft has expaired.
>>But I failed to find the current draft from IETF web site.
>>Does anyone know the status of this draft?
>>
>>To the authors, there are two typos in July/2001 version.
>>
>>1. In mplsDsTeIfMaxAddrUnresBw,  "Addr" really means "Aggr", I think.
>>
>>2. The object MplsDsTeIfClassTypeEntry is defined twice.  Seems that the
>>    second occurrence should be "MplsDsTeLspEntry" instead.
>>
>>Perhaps these can be corrected in the next revision.
>>
>>Thanks!
>>
>>-- Rupert



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Wed Jun 26 07:19:51 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12219
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 07:19:50 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxh17848
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 11:20:30 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuxh15323;
	Wed, 26 Jun 2002 11:19:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuxh23959
	for mpls-outgoing; Wed, 26 Jun 2002 11:18:52 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmuxh23949
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Jun 2002 11:18:46 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuxh05725
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:18:28 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxh18806
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:18:27 GMT
Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmuxh18800
	for <mpls@UU.NET>; Wed, 26 Jun 2002 11:18:27 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5QBItT7007221;
	Wed, 26 Jun 2002 07:18:56 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF27296;
	Wed, 26 Jun 2002 07:18:22 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020626071629.01dc9220@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 26 Jun 2002 07:18:19 -0400
To: "Zhu, Rupert" <rupert.zhu@santera.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: MPLS-DS-TE-MIB?
Cc: <mpls@UU.NET>, <te-wg@ops.ietf.org>
In-Reply-To: <CD110021698980419241042CF576B8F20188F136@EXCALIBUR.santera
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         BTW, I failed to mention that we will be cutting a new, up-to-date
version of the DS-TE MIB draft in the near future (probably within
the month of July), so others on the mailing list please send us your 
comments/suggestions based on the latest DS-TE protocol draft.

         --Tom


>The July/2001 version of MPLS-DS-TE-MIB draft has expaired.
>But I failed to find the current draft from IETF web site.
>Does anyone know the status of this draft?
>
>To the authors, there are two typos in July/2001 version.
>
>1. In mplsDsTeIfMaxAddrUnresBw,  "Addr" really means "Aggr", I think.
>
>2. The object MplsDsTeIfClassTypeEntry is defined twice.  Seems that the
>    second occurrence should be "MplsDsTeLspEntry" instead.
>
>Perhaps these can be corrected in the next revision.
>
>Thanks!
>
>-- Rupert



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Wed Jun 26 11:02:30 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21895
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 11:02:29 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxw09206
	for <mpls-archive@lists.ietf.org>; Wed, 26 Jun 2002 15:03:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuxv00852;
	Wed, 26 Jun 2002 14:59:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuxv19324
	for mpls-outgoing; Wed, 26 Jun 2002 14:59:12 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuxv19317
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Jun 2002 14:59:11 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuxv28955
	for <mpls@UU.NET>; Wed, 26 Jun 2002 14:58:55 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuxv23047
	for <mpls@UU.NET>; Wed, 26 Jun 2002 14:58:55 GMT
Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	id QQmuxv23039
	for <mpls@UU.NET>; Wed, 26 Jun 2002 14:58:54 GMT
Message-ID: <EB5FFC72F183D411B38200062957342976ABE8@r2d2.axiowave.com>
From: Ling Li <lli@axiowave.com>
To: mpls@UU.NET
Cc: "'pingpan@juniper.net'" <pingpan@juniper.net>
Subject: question on the hop-limit constraint in One-to-one (detour) fast-
	reroute
Date: Wed, 26 Jun 2002 10:58:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

The hop-limit constraint is defined as follows in 
draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt:

Hop-limit

      The maximum number of extra hops the backup path is allowed
      to take, from current node (a PLR) to a MP, with PLR and MP
      excluded in counting.  For example, hop-limit of 0 means only
      direct links between PLR and MP can be considered.

I assume that the MP here refers to the MP where backup tunnels rejoin 
the path of the protected LSP, not the Detour Merge Point, which is defined
in the same document as:

MP - Merge Point. The LSR where one or more backup tunnels rejoin
          the path of the protected LSP, downstream of the potential
          failure. In the case of one-to-one backup, a Merge Point may
          also be an LSR where multiple detours converge and only one
          detour is signaled beyond that LSR; this type of merge point
          may be referred to as a Detour Merge Point.  A MP may also
          be a PLR. 

Seems to me that an assumption is made here that every node
on the downstream path of the protected LSP should/must be a MP. Otherwise
if some of the nodes are MP and some are not capable of merging LSPs, and a
PLR that computes a detour path has no knowledge of which one is a MP (this
info. is not flooded by ospf/is-is), how could the hop-limit constraint be
applied?

If the above assumption is valid, should the destination of the detour LSP
be
the MP, rather than the final destination of the protected LSP?


Any suggestions would be appreciated.

Thanks, 

Ling Li 

Axiowave Networks, Inc. 
200 Nickerson Road 
Marlborough, MA 01752 
======================== 



From owner-mpls@UU.NET  Thu Jun 27 00:25:16 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22406
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 00:25:15 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuzx28104
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 04:25:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmuzx26061;
	Thu, 27 Jun 2002 04:24:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmuzx25207
	for mpls-outgoing; Thu, 27 Jun 2002 04:24:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmuzx25202
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 04:24:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmuzx03965
	for <mpls@UU.NET>; Thu, 27 Jun 2002 04:24:20 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuzx17659
	for <mpls@UU.NET>; Thu, 27 Jun 2002 04:24:19 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQmuzx17644
	for <mpls@UU.NET>; Thu, 27 Jun 2002 04:24:19 GMT
Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 00:24:16 -0400
Message-ID: <002b01c21d92$81221380$0619588a@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Yakov Rekhter" <yakov@juniper.net>
Cc: "mpls wg" <mpls@UU.NET>, <rahul@redback.com>, <manoj@juniper.net>
References: <200206231555.g5NFt6m51131@merlot.juniper.net>
Subject: Re: wg last call draft-ietf-mpls-ldp-restart-02.txt 
Date: Thu, 27 Jun 2002 00:21:48 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 27 Jun 2002 04:24:18.0437 (UTC) FILETIME=[80DFB350:01C21D92]
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

> > 3. It would be helpful to add some text to cover processing
> >    of other messages while an LSR is in the process of=20
> >    restarting: in particular Withdraw and Release.  Although
> >    this is pretty obvious, I believe you run the risk of
> >    failure to interop correctly unless you spell it out: viz.
> >    Withdraw should match in table, delete from table and=20
> >    send Withdraw upstream as required
> >    Release should match in table, if entry is stale should
> >    ignore, if entry is not stale should process according
> >    to normal Release procedures on local node.
>
> please proposed the text, and I'll add it to the draft.

How about...

While an LSR is in the process of restarting it may also receive
other label management messages.  These SHOULD be handled
according to the following rules.

- A Label Withdraw should be matched against the table.  If a
  match is found, the entry should be deleted from the table and
  a Label Withdraw propagated upstream according to the
  protocol options in operation at the LSR.  If no match is found
  the Label Withdraw should be silently dropped.
- A Label Release should be matched against the table.  If no
  match is found, or a match is found and the entry is marked as
  stale the Label Release should be silently dropped.  If a match
  is made and the entry is not stale, processing should continue
  accoding to the normal Label Release procedures on the LSR.
- A Label Abort message should not match any entry in the table
  since the procedures in this draft apply to Downstream Unsolicited
  operation only.

> > 4. It would be nice if you exposed that all Address messages
> >    need to be exchanged before the downstream node starts=20
> >    resending Mapping messages.  Section 6.1.1 is based on the
> >    assumption that these messages have been received.
>
> please propose the text and I'll add it to the draft.

As described in section 6.1.1, if the label carried in a Label Mapping
message received during restart processing is not an Implicit NULL,
the LSR searches its MPLS forwarding table for an entry with the
outgoing label equal to the label carried in the message, and the
next hop equal to one of the addresses (next hops) received in one
of the Address messages from the peer.

In order that the address can be properly validated, the restarted
LSR must have an up-to-date list of addresses.  This could be
achieved by the restarting LSR saving previously received addresses
to non-volatile storage and retrieving them during restart, but this
does not protect against address changes while the restarted LSR
is off-line.

As a result it should be noted that the adjacent LSRs SHOULD all
re-send all of their current addresses to the restarted LSR as part of
session re-initialization and before re-sending any label-related
messages.  The restart timers described in this draft should be
factored to include this exchange of addresses.

Note that there is no need to parse the preserved MPLS forwarding
table for enries made invalid by the absence of an address on the
restarted session.  Such entries will still be stale when restart is
complete and will be discarded then.

> > 5. Is it normal procedure to give suggested values for all
> >    timers in drafts?
>
> not sure.

I believe it is.  I'm sure the WG chairs will comment.

Regards,
Adrian




From owner-mpls@UU.NET  Thu Jun 27 06:41:31 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09663
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 06:41:31 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw27572
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 10:42:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvaw26413;
	Thu, 27 Jun 2002 10:41:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvaw05384
	for mpls-outgoing; Thu, 27 Jun 2002 10:41:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvaw05286
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 10:41:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvaw14148
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw25936
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvaw25927
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA02915 for <mpls@uu.net>; Thu, 27 Jun 2002 06:41:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA20358 for mpls@uu.net; Thu, 27 Jun 2002 06:41:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvaw05178
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 10:39:48 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvaw16784
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:38 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw02653
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:38 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmvaw02649
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:38 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08972;
	Thu, 27 Jun 2002 06:38:41 -0400 (EDT)
Message-Id: <200206271038.GAA08972@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt
Date: Thu, 27 Jun 2002 06:38:41 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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


	Title		: Extended RSVP-TE for Multicast LSP Tunnels
	Author(s)	: S. Yasukawa et al.
	Filename	: draft-yasukawa-mpls-rsvp-multicast-00.txt
	Pages		: 39
	Date		: 26-Jun-02
	
Multicast technology will become increasingly important with the
dissemination of new applications such as contents delivery services
and video conferences, which require much more bandwidth and stricter
QoS than conventional applications. From the service providers'
perspective, traffic engineering (TE) functions will be needed to
handle the large amount of multicast traffic.
This document defines some protocol extensions to the existing RSVP-
TE[1] in order to establish a multicast label switched path (LSP).
The use of label switching routers (LSRs) with these protocol
extensions defined in this document allows service providers to offer
unicast and multicast multiprotocol label switching (MPLS) services
in the same service network.
This protocol assumes a variable LSP topology, e.g., point-to-
multipoint, multipoint-to-multipoint, topologies. This document
describes how to establish point-to-multipoint and multipoint-to-
multipoint LSPs as the most basic multicast topology. It defines two
ways of constructing a point-to-multipoint LSP: sender-initiated LSP
setup and leaf-initiated LSP setup. Each method has an LSP
modification function in order to adapt to dynamic changes in the LSP
tree topology.
This MPLS architecture[10] is very flexible and can be expanded to
carry protocols other than IP multicasting, e.g., Ethernet, PPP, and
SONET/SDH, but this document only defines IP multicasting (IPv4 and
IPv6) as a forwarding equivalence class object (FEC).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-multicast-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-yasukawa-mpls-rsvp-multicast-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-yasukawa-mpls-rsvp-multicast-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020626134652.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-yasukawa-mpls-rsvp-multicast-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-yasukawa-mpls-rsvp-multicast-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626134652.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Jun 27 06:41:32 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09675
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 06:41:31 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw05220
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 10:42:13 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvaw03620;
	Thu, 27 Jun 2002 10:41:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvaw05370
	for mpls-outgoing; Thu, 27 Jun 2002 10:41:15 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvaw05285
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 10:41:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvaw14156
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw25937
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvaw25928
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:41:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA02918 for <mpls@uu.net>; Thu, 27 Jun 2002 06:41:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA20362 for mpls@uu.net; Thu, 27 Jun 2002 06:41:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvaw05184
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 10:39:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvaw11577
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:48 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvaw02718
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:47 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQmvaw02714
	for <mpls@uu.net>; Thu, 27 Jun 2002 10:39:47 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09077;
	Thu, 27 Jun 2002 06:39:03 -0400 (EDT)
Message-Id: <200206271039.GAA09077@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
Date: Thu, 27 Jun 2002 06:39:03 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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


	Title		: MPLS Traffic Engineering Fast reroute: backup tunnel 
                          path computation for bandwidth protection
	Author(s)	: J. Vasseur et al.
	Filename	: draft-vasseur-mpls-backup-computation-00.txt
	Pages		: 43
	Date		: 26-Jun-02
	
This draft proposes an efficient model called ''Facility based 
computation model'' for computing bypass tunnels paths in the context of 
the MPLS TE Fast Reroute, while allowing bandwidth sharing between 
backup tunnel protecting independent resources. Both a centralized and 
a distributed path computation scenarios are described. The required 
signaling extensions are also addressed in the draft.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-vasseur-mpls-backup-computation-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-vasseur-mpls-backup-computation-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020626134733.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-vasseur-mpls-backup-computation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626134733.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Jun 27 10:05:09 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19248
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 10:05:09 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbk10700
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 14:05:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbk08424;
	Thu, 27 Jun 2002 14:04:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbk08944
	for mpls-outgoing; Thu, 27 Jun 2002 14:04:10 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvbk08843
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 14:04:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbk14418
	for <mpls@uu.net>; Thu, 27 Jun 2002 14:03:10 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbk07345
	for <mpls@uu.net>; Thu, 27 Jun 2002 14:03:08 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvbk06804
	for <mpls@uu.net>; Thu, 27 Jun 2002 14:02:58 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA12087 for <mpls@uu.net>; Thu, 27 Jun 2002 10:02:57 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11035 for mpls@uu.net; Thu, 27 Jun 2002 10:02:57 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmuzh08754
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 00:23:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmuzh18254
	for <mpls@uu.net>; Thu, 27 Jun 2002 00:22:47 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmuzh15580
	for <mpls@uu.net>; Thu, 27 Jun 2002 00:22:46 GMT
Received: from melete.ch.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chfdns02.ch.intel.com [143.182.246.25])
	id QQmuzh15562
	for <mpls@uu.net>; Thu, 27 Jun 2002 00:22:46 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5R0Mjm02167
	for <mpls@uu.net>; Thu, 27 Jun 2002 00:22:45 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062617230913987
 ; Wed, 26 Jun 2002 17:23:09 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <NWJT4HSL>; Wed, 26 Jun 2002 17:22:45 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D5019CE9297@fmsmsx37.fm.intel.com>
From: "Juneja, Manoj" <manoj.juneja@intel.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Cc: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'cheenu@paramanet.com'"
	 <cheenu@paramanet.com>,
        "'arun@force10networks.com'"
	 <arun@force10networks.com>
Subject: MPLS TE MIB Doubt
Date: Wed, 26 Jun 2002 17:22:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        In MPLS-TE mib, it is written that the information necessary to
build entries within mplsTunelARHopTable is not provided by some MPLS
signaling protocols and therefore the implementation of this table is
optional. RSVP-TE has the RRO mechanism but CR-LDP don't have such kind of 
mechanism. 
Is it fine if one uses Path Vector information to build this table
in case of CR-LDP ?

Does this mean that this table is not applicable to CR-LDP ?

Regards,
manoj.



From owner-mpls@UU.NET  Thu Jun 27 10:55:27 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21788
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 10:55:26 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbn15227
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 14:56:07 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbn12938;
	Thu, 27 Jun 2002 14:54:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbn02513
	for mpls-outgoing; Thu, 27 Jun 2002 14:54:45 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvbn02476
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 14:54:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvbn12527
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:54:34 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbn23417
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:54:34 GMT
Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97])
	id QQmvbn23409
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:54:34 GMT
Received: from bucket.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5REsqP0004005;
	Thu, 27 Jun 2002 10:54:56 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-24.cisco.com [161.44.145.24])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF46451;
	Thu, 27 Jun 2002 10:54:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020627105323.01cf70a0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 27 Jun 2002 10:54:19 -0400
To: "Juneja, Manoj" <manoj.juneja@intel.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: MPLS TE MIB Doubt
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'cheenu@paramanet.com'" <cheenu@paramanet.com>,
        "'arun@force10networks.com'" <arun@force10networks.com>
In-Reply-To: <F1CE15E08172D4119247009027AE9D5019CE9297@fmsmsx37.fm.intel
 .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



>         In MPLS-TE mib, it is written that the information necessary to
>build entries within mplsTunelARHopTable is not provided by some MPLS
>signaling protocols and therefore the implementation of this table is
>optional. RSVP-TE has the RRO mechanism but CR-LDP don't have such kind of
>mechanism.
>Is it fine if one uses Path Vector information to build this table
>in case of CR-LDP ?
>
>Does this mean that this table is not applicable to CR-LDP ?

         We were aware of the fact that some implementations
could not build the actual route information, thus we made the
table optional.

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 



From owner-mpls@UU.NET  Thu Jun 27 11:17:04 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23232
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 11:17:03 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbp03370
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 15:16:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbp00152;
	Thu, 27 Jun 2002 15:15:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbo28323
	for mpls-outgoing; Thu, 27 Jun 2002 15:14:59 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvbo28318
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 15:14:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbo06028
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:14:24 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbo29537
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:14:24 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvbo29530
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:14:24 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA17510 for <mpls@uu.net>; Thu, 27 Jun 2002 11:14:23 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19454 for mpls@uu.net; Thu, 27 Jun 2002 11:14:22 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvbn01634
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 14:52:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbn25742
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:50:44 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbn10828
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:50:44 GMT
Received: from web21206.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web21206.mail.yahoo.com [216.136.175.8])
	id QQmvbn10773
	for <mpls@UU.NET>; Thu, 27 Jun 2002 14:50:43 GMT
Message-ID: <20020627145039.2897.qmail@web21206.mail.yahoo.com>
Received: from [216.140.58.174] by web21206.mail.yahoo.com via HTTP; Thu, 27 Jun 2002 07:50:39 PDT
Date: Thu, 27 Jun 2002 07:50:39 -0700 (PDT)
From: Richard Stephens <scullptor@yahoo.com>
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Is there any automated mechanism in existing MPLS
drafts that enable the automated generation of two
lsp's given two equal cost paths?  What i'm looking
for is the ability to use lsp load balancing without
having to static an lsp for all possible paths.

Thanks in advance

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com



From owner-mpls@UU.NET  Thu Jun 27 12:03:40 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27239
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 12:03:39 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbs03289
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 16:04:17 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbs00083;
	Thu, 27 Jun 2002 16:02:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbs10075
	for mpls-outgoing; Thu, 27 Jun 2002 16:02:26 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvbs10048
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 16:02:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvbs24591
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:00:40 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbs14897
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:00:40 GMT
Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102])
	id QQmvbs14886
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:00:39 GMT
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id BAA00083
	for <mpls@UU.NET>; Fri, 28 Jun 2002 01:00:37 +0900 (JST)
	(envelope-from yasukawa.seisho@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g5RG0bxV022218
	for <mpls@UU.NET>; Fri, 28 Jun 2002 01:00:37 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g5RG0Zn5000429
	for <mpls@UU.NET>; Fri, 28 Jun 2002 01:00:35 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id BAA23621;
	Fri, 28 Jun 2002 01:00:34 +0900 (JST)
Received: from lab.ntt.co.jp
	by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id BAA15189;
	Fri, 28 Jun 2002 01:00:34 +0900 (JST)
Message-ID: <3D1B364C.9070806@lab.ntt.co.jp>
Date: Fri, 28 Jun 2002 00:59:08 +0900
From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: ja
MIME-Version: 1.0
To: mpls@UU.NET
Subject: [Fwd: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt]
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi 

Please note that the following draft has been newly posted to MPLS WG.

draft-yasukawa-mpls-rsvp-multicast-00.txt

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-multicast-00.txt 

We think p-to-mp LSP establishment mechanism is essential
for multicast application and L2/MPLS application.
And we strongly need this technology.
 
Please discuss this technology and give us comments.

Thanks, 
Seisho




From owner-mpls@UU.NET  Thu Jun 27 12:30:33 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29427
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 12:30:33 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbu15239
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 16:31:09 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbt12106;
	Thu, 27 Jun 2002 16:29:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbt27181
	for mpls-outgoing; Thu, 27 Jun 2002 16:29:12 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvbt27176
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 16:29:11 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbt09545
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:29:04 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbt18884
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:29:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvbt18863
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:29:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23501 for <mpls@uu.net>; Thu, 27 Jun 2002 12:29:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28019 for mpls@uu.net; Thu, 27 Jun 2002 12:29:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvbq00827
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 15:35:02 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbq00887
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:34:37 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbq08980
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:34:36 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: europe.cisco.com [144.254.52.73])
	id QQmvbq08418
	for <mpls@uu.net>; Thu, 27 Jun 2002 15:34:26 GMT
Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp4122.cisco.com [10.50.16.25])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA09635;
	Thu, 27 Jun 2002 17:34:24 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20020627154020.0753e260@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 27 Jun 2002 17:34:22 +0200
To: mpls@UU.NET
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
Cc: ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

This draft proposes a model for the backup tunnel computation to provide 
bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the 
capability to provide not only a fast convergence but also bandwidth 
guaranties while making an efficient backup bandwidth usage.

Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be 
related to the ongoing protection/restoration work done in CCAMP.

Any comment is of course very welcome.

Thanks.

JP.

>To: IETF-Announce:;
>CC: mpls@UU.NET
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>Date: Thu, 27 Jun 2002 06:39:03 -0400
>Sender: owner-mpls@UU.NET
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : MPLS Traffic Engineering Fast reroute: backup 
> tunnel
>                           path computation for bandwidth protection
>         Author(s)       : J. Vasseur et al.
>         Filename        : draft-vasseur-mpls-backup-computation-00.txt
>         Pages           : 43
>         Date            : 26-Jun-02
>
>This draft proposes an efficient model called ''Facility based
>computation model'' for computing bypass tunnels paths in the context of
>the MPLS TE Fast Reroute, while allowing bandwidth sharing between
>backup tunnel protecting independent resources. Both a centralized and
>a distributed path computation scenarios are described. The required
>signaling extensions are also addressed in the draft.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>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-vasseur-mpls-backup-computation-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:
>         mailserv@ietf.org.
>In the body type:
>         "FILE /internet-drafts/draft-vasseur-mpls-backup-computation-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.
>Content-Type: text/plain
>Content-ID:     <20020626134733.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt>



From owner-mpls@UU.NET  Thu Jun 27 12:44:35 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00397
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 12:44:35 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbu29723
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 16:44:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvbu26130;
	Thu, 27 Jun 2002 16:42:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvbu28225
	for mpls-outgoing; Thu, 27 Jun 2002 16:42:25 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvbu28220
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 16:42:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbu23668
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:42:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbu25672
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:42:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvbu25667
	for <mpls@uu.net>; Thu, 27 Jun 2002 16:42:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24565 for <mpls@uu.net>; Thu, 27 Jun 2002 12:42:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA29949 for mpls@uu.net; Thu, 27 Jun 2002 12:42:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvbu28003
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 16:40:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvbu15553
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:39:46 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvbu24623
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:39:46 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvbu24618
	for <mpls@UU.NET>; Thu, 27 Jun 2002 16:39:45 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24370; Thu, 27 Jun 2002 12:39:45 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26903; Thu, 27 Jun 2002 12:39:45 -0400 (EDT)
Date: Thu, 27 Jun 2002 12:39:45 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Richard Stephens <scullptor@yahoo.com>
Cc: mpls@UU.NET
Subject: Re: your mail
Message-ID: <20020627163945.GM24180@eosborne-u10.cisco.com>
References: <20020627145039.2897.qmail@web21206.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020627145039.2897.qmail@web21206.mail.yahoo.com>
User-Agent: Mutt/1.4i
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 27, 2002 at 07:50:39AM -0700, Richard Stephens wrote:
> Is there any automated mechanism in existing MPLS
> drafts that enable the automated generation of two
> lsp's given two equal cost paths?  What i'm looking
> for is the ability to use lsp load balancing without
> having to static an lsp for all possible paths.

LDP will do this automatically, as it follows the IGP; there are no
provisions in TE to do this, but it could certainly be done by an
operator.



eric

> 
> Thanks in advance
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com



From owner-mpls@UU.NET  Thu Jun 27 13:37:56 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03402
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 13:37:56 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvby19574
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 17:38:37 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvby17211;
	Thu, 27 Jun 2002 17:37:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvby24349
	for mpls-outgoing; Thu, 27 Jun 2002 17:37:11 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvby24344
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 17:37:08 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvby20259
	for <mpls@UU.NET>; Thu, 27 Jun 2002 17:36:23 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvby25086
	for <mpls@UU.NET>; Thu, 27 Jun 2002 17:36:23 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmvby25079
	for <mpls@UU.NET>; Thu, 27 Jun 2002 17:36:23 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21949
	for <mpls@UU.NET>; Thu, 27 Jun 2002 13:36:21 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28709
	for <mpls@UU.NET>; Thu, 27 Jun 2002 13:36:21 -0400 (EDT)
Message-ID: <3D1B4D0C.7070509@marconi.com>
Date: Thu, 27 Jun 2002 13:36:12 -0400
From: David Charlap <david.charlap@marconi.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020626
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: IETF MPLS List <mpls@UU.NET>
Subject: Re: I-D ACTION:draft-yasukawa-mpls-rsvp-multicast-00.txt
References: <200206271038.GAA08972@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title		: Extended RSVP-TE for Multicast LSP Tunnels
> 	Author(s)	: S. Yasukawa et al.
> 	Filename	: draft-yasukawa-mpls-rsvp-multicast-00.txt
> 	Pages		: 39
> 	Date		: 26-Jun-02

Since Seisho Yasukawa has explicitly asked for comments.....

In my opinion, this draft is not necessary.  It is based on the 
incorrect assumption that RSVP-TE, as it is currently defined, does not 
have supprort for multicast.

Classical RSVP was designed around multicast, and RSVP-TE introduces 
nothing to change this, even though it does not explicitly describe a 
multicast implementation.

For a multicast LSP, one has only to specify a multicast group address 
in the SESSION object (the tunnel endpoint address), and do not include 
an EXPLICIT_ROUTE object.  Normal Path processing should propagate the 
Path message to all next-hops in the multicast group, according to the 
multicast table that already exists.

When Resv messages return, the FLOWSPEC values are merged according to 
the rules for classical RSVP (RFC 2205 and related documents).  Incoming 
LABEL objects are installed on the next-hop interfaces.  One label is 
generated to send upstream - using the merged FLOWSPEC object.

I am aware that RSVP-TE's definition of EXPLICIT_ROUTE and RECORD_ROUTE 
does not accommodate multicast.  If there is some need to specify an 
explicit multicast tree that differs from the multicast routing table, 
then this might be required.

Personally, I think attempting to traffic-engineer a multicast tree 
beyond what existing multicast routing protocols already do is 
pointless.  Any automatic process for generating these trees will 
duplicate all of the work that routing protocols already do.  Any manual 
process will be unmanageable, since receivers may be continuously 
joining and leaving the multicast group.

Given the infeasability of a manually-configured multicast LSP, we're 
back to automatic configuration.  RSVP, as it currently stands, is 
sufficient in this situation.  It reads the existing multicast routing 
table to determine the next-hops for a multicast group, and monitors the 
routing table to add and remove next-hops as needed.  Rules for merging 
FLOWSPEC objects are already in place.  Rules for merging labels are 
self-evident.

While it is true that current RSVP-TE implementations do not have 
support for multicast LSPs, there is nothing in RFC 3209 that prohibits 
the use of RSVP-TE for multicast situations.  Note that the only part of 
RSVP-TE that is not multicast-friendly is the EXPLICIT_ROUTE object - 
ant this object is optional in Path messages anyway.

-- David



From owner-mpls@UU.NET  Thu Jun 27 14:57:06 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09126
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 14:57:05 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcd02512
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 18:57:34 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvcd29384;
	Thu, 27 Jun 2002 18:55:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvcd22502
	for mpls-outgoing; Thu, 27 Jun 2002 18:55:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvcd22481
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 18:55:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvcd13925
	for <mpls@uu.net>; Thu, 27 Jun 2002 18:55:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcd02582
	for <mpls@uu.net>; Thu, 27 Jun 2002 18:55:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvcd02577
	for <mpls@uu.net>; Thu, 27 Jun 2002 18:55:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05315 for <mpls@uu.net>; Thu, 27 Jun 2002 14:55:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA14334 for mpls@uu.net; Thu, 27 Jun 2002 14:55:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvcd22398
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 18:54:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvcd10345
	for <mpls@UU.NET>; Thu, 27 Jun 2002 18:53:30 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcd02069
	for <mpls@UU.NET>; Thu, 27 Jun 2002 18:53:30 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvcd02064
	for <mpls@UU.NET>; Thu, 27 Jun 2002 18:53:30 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05189; Thu, 27 Jun 2002 14:53:29 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA27220; Thu, 27 Jun 2002 14:53:29 -0400 (EDT)
Date: Thu, 27 Jun 2002 14:53:29 -0400
From: Eric Osborne <eosborne@cisco.com>
To: George Sheng <george_s97@hotmail.com>
Cc: eosborne@cisco.com, scullptor@yahoo.com, mpls@UU.NET
Subject: Re: your mail
Message-ID: <20020627185329.GS24180@eosborne-u10.cisco.com>
References: <F2080Vd9kA6uhmWBmqA00001333@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F2080Vd9kA6uhmWBmqA00001333@hotmail.com>
User-Agent: Mutt/1.4i
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 27, 2002 at 05:03:25PM +0000, George Sheng wrote:
> ] On Thu, Jun 27, 2002 at 07:50:39AM -0700, Richard Stephens wrote:
> ] > Is there any automated mechanism in existing MPLS
> ] > drafts that enable the automated generation of two
> ] > lsp's given two equal cost paths?  What i'm looking
> ] > for is the ability to use lsp load balancing without
> ] > having to static an lsp for all possible paths.
> ]
> ] LDP will do this automatically, as it follows the IGP; there are no
> ] provisions in TE to do this, but it could certainly be done by an
> ] operator.
> 
> 
> for ldp, yes if it's at the first hop of the lsp tunnel;
> but i think he is asking for ECMP even in the middle of
> the ldp tunnels. thus ldp needs to assign multi labels
> to its upstream for a single prefix which has ECMP.

not true with LDP in a frame-mode environment; ECMP is inherent in the
architecture.  with LDP cell-mode or with TE, yes, you're correct.


eric



From owner-mpls@UU.NET  Thu Jun 27 16:05:40 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13165
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 16:05:40 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvci10207
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 20:06:14 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvci07572;
	Thu, 27 Jun 2002 20:04:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvci06514
	for mpls-outgoing; Thu, 27 Jun 2002 20:04:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvci06509
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 20:04:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvci02077
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:04:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvci07534
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:04:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvci07529
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:04:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10622 for <mpls@uu.net>; Thu, 27 Jun 2002 16:04:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22330 for mpls@uu.net; Thu, 27 Jun 2002 16:04:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvci06462
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 20:03:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvci29576
	for <mpls@UU.NET>; Thu, 27 Jun 2002 20:03:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvci10532
	for <mpls@UU.NET>; Thu, 27 Jun 2002 20:03:03 GMT
Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmvci10526
	for <mpls@UU.NET>; Thu, 27 Jun 2002 20:03:02 GMT
Received: (qmail 2639 invoked by uid 104); 27 Jun 2002 20:03:02 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 0.443839 secs); 27 Jun 2002 20:03:02 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 27 Jun 2002 20:03:01 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5RK2uc14058;
	Thu, 27 Jun 2002 13:02:56 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4WCH8>; Thu, 27 Jun 2002 13:02:57 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB0371F@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Osborne'" <eosborne@cisco.com>,
        George Sheng
	 <george_s97@hotmail.com>
Cc: scullptor@yahoo.com, mpls@UU.NET
Subject: RE: your mail
Date: Thu, 27 Jun 2002 13:02:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> ECMP is inherent in the architecture. 

What? ECMP is a kludge to overcome LDP's inability to TE. If you think about it doing hashing of multiple labels and perhaps IP header in the middle of an LSP actually defeats the purpose of MPLS, which was supposed to be have a simple label lookup in the core.

-Shahram 
 



From owner-mpls@UU.NET  Thu Jun 27 17:04:04 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15824
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 17:04:04 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcm03340
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 21:04:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvcm00692;
	Thu, 27 Jun 2002 21:03:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvcm09626
	for mpls-outgoing; Thu, 27 Jun 2002 21:03:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvcm09555
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 21:03:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvcm28551
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:02:38 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcm29637
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:02:37 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmvcm29628
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:02:36 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06446;
	Thu, 27 Jun 2002 17:02:34 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA11238;
	Thu, 27 Jun 2002 17:02:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <NL669HG9>; Thu, 27 Jun 2002 17:02:35 -0400
Message-ID: <39469E08BD83D411A3D900204840EC55763231@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Eric Osborne'"
	 <eosborne@cisco.com>,
        George Sheng <george_s97@hotmail.com>
Cc: scullptor@yahoo.com, mpls@UU.NET
Subject: RE: your mail
Date: Thu, 27 Jun 2002 17:02:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram,

-> > ECMP is inherent in the architecture. 
-> 
-> What? ECMP is a kludge to overcome LDP's inability to TE. If 
-> you think about it doing hashing of multiple labels and 
-> perhaps IP header in the middle of an LSP actually defeats 
-> the purpose of MPLS, which was supposed to be have a simple 
-> label lookup in the core.

 Who said that ECMP will be achieved only by hashing labels
 or IP header? I think you are thinking IP ECMP methods
 (RFCs 2991 and 2992) to solve MPLS ECMP. You can do ECMP
 in what ever way a vendor likes - after all, it is for
 load balancing. You can still achieve simple label lookup at
 the core by using appropriate ECMP technique(s).

--
Venkata.


From owner-mpls@UU.NET  Thu Jun 27 17:24:26 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16961
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 17:24:26 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvck25376
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 20:36:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvck20254;
	Thu, 27 Jun 2002 20:33:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvck19797
	for mpls-outgoing; Thu, 27 Jun 2002 20:32:39 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvck19792
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 20:32:36 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvck20110
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:31:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvck19485
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:31:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvck19476
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:31:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12689 for <mpls@uu.net>; Thu, 27 Jun 2002 16:31:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26477 for mpls@uu.net; Thu, 27 Jun 2002 16:31:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvcj19663
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 20:29:57 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvcj03798
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:28:11 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcj25072
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:28:11 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQmvcj25065
	for <mpls@uu.net>; Thu, 27 Jun 2002 20:28:10 GMT
Received: (qmail 983 invoked by uid 104); 27 Jun 2002 20:28:10 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 1.433906 secs); 27 Jun 2002 20:28:10 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 27 Jun 2002 20:28:08 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5RKS7c02950
	for <mpls@uu.net>; Thu, 27 Jun 2002 13:28:07 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4WDAV>; Thu, 27 Jun 2002 13:28:09 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03721@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-recovery-frmwrk-04.txt
Date: Thu, 27 Jun 2002 13:28:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Why is that in section 3.6. (Fault Notification), the only notification method mentioned is sending FIS upstream, hop-by-hop. Although this is possible but a simpler and more conventional method is to send the FIS to the PML and let the PML inform the PSL. Is this type of notification excluded? If so why, and if not could the authors please add it to the text.


Thanks,
Shahram 



From owner-mpls@UU.NET  Thu Jun 27 17:25:05 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16983
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 17:25:05 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcn13915
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 21:25:49 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvcn11286;
	Thu, 27 Jun 2002 21:24:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvcn26780
	for mpls-outgoing; Thu, 27 Jun 2002 21:24:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvcn26768
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 21:24:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvcn19011
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:21:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcn07007
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:21:53 GMT
Received: from web21002.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web21002.mail.yahoo.com [216.136.227.56])
	id QQmvcn06995
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:21:52 GMT
Message-ID: <20020627212136.39735.qmail@web21002.mail.yahoo.com>
Received: from [204.192.44.242] by web21002.mail.yahoo.com via HTTP; Thu, 27 Jun 2002 14:21:36 PDT
Date: Thu, 27 Jun 2002 14:21:36 -0700 (PDT)
From: Carlos Patriawan <carlos_mpls@yahoo.com>
Subject: Re: target ldp question:
To: Chetan Pinto <chetanpinto@hotmail.com>, mpls@UU.NET
In-Reply-To: <F26mz8Phg8VMb5UWgP100000673@hotmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-679145271-1025212896=:39732"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-679145271-1025212896=:39732
Content-Type: text/plain; charset=us-ascii


 
  Chetan Pinto <chetanpinto@hotmail.com> wrote: 
>The requirement for router("r" in below ase) between 2
>targeted session peer is capable of mpls forwarding.
>
>Question: in the case where R2 as the egress for FEC x
>and R2 assigns label 0 as label binding for fec x on
>its session with R1 ; now If transit LSR 'r'
>forward the mpls frame(w/ label 0) to R1, does it
>violate the RFC since RFC says LSR has to pop mpls
>frame w/ label 0 ?

First of all R1 needs to forward the frame to 'r'.
I think this is what u meant [not the other way around]
---
Thanks for the correction.


At R1, there needs be a 2 level label stack for the LSP
corresponding to FEC x outgoing towards r
The bottom most is the one corresponding R2's label [value = 0]
The top most is the one corresponding to r's label [value = 'a']
---
Targeted session with 2 label stack (rsvp over ldp) is more to vendor implementation, 
as per-RFC there's no requirement for targeted session that should be in two label stack format. 

To be more precise, in targeted session w/ one label stack environment, is it acceptable 
for transit LSR  to forward mpls frame with exp-null label ?

Carlos



---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--0-679145271-1025212896=:39732
Content-Type: text/html; charset=us-ascii

<P> 
<P>&nbsp; <B><I>Chetan Pinto &lt;chetanpinto@hotmail.com&gt;</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>&gt;The requirement for router("r" in below ase) between 2<BR>&gt;targeted session peer is capable of mpls forwarding.<BR>&gt;<BR>&gt;Question: in the case where R2 as the egress for FEC x<BR>&gt;and R2 assigns label 0 as label binding for fec x on<BR>&gt;its session with R1 ; now If transit LSR 'r'<BR>&gt;forward the mpls frame(w/ label 0) to R1, does it<BR>&gt;violate the RFC since RFC says LSR has to pop mpls<BR>&gt;frame w/ label 0 ?<BR><BR>First of all R1 needs to forward the frame to 'r'.<BR>I think this is what u meant [not the other way around]<BR>---<BR>Thanks for the correction.</P>
<P><BR>At R1, there needs be a 2 level label stack for the LSP<BR>corresponding to FEC x outgoing towards r<BR>The bottom most is the one corresponding R2's label [value = 0]<BR>The top most is the one corresponding to r's label [value = 'a']<BR>---<BR>Targeted session with 2 label stack (rsvp over ldp) is more to vendor implementation, <BR>as per-RFC there's no requirement for targeted session that should be in two label stack format. <BR><BR>To be more precise,&nbsp;in targeted session w/ one label stack environment, is it acceptable <BR>for transit LSR&nbsp; to forward mpls frame with exp-null label ?</P>
<P>Carlos</P></BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com/fc/en/spl">Sign-up for Video Highlights</a> of 2002 FIFA World Cup
--0-679145271-1025212896=:39732--


From owner-mpls@UU.NET  Thu Jun 27 17:26:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17113
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 17:26:58 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcn18243
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 21:27:39 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvcn11045;
	Thu, 27 Jun 2002 21:24:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvcn26779
	for mpls-outgoing; Thu, 27 Jun 2002 21:24:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvcn26764
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 21:24:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvcn24399
	for <mpls@uu.net>; Thu, 27 Jun 2002 21:23:51 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcn11258
	for <mpls@uu.net>; Thu, 27 Jun 2002 21:23:50 GMT
Received: from almso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: almso2.att.com [192.128.166.71])
	id QQmvcn11241
	for <mpls@uu.net>; Thu, 27 Jun 2002 21:23:50 GMT
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g5RL6Udw028754
	for <mpls@uu.net>; Thu, 27 Jun 2002 17:23:49 -0400 (EDT)
Received: from OCCLUST01EVS1.ugd.att.com (135.71.164.6) by attrh1i.attrh.att.com (5.5.029)
        id 3CBB497300381007 for mpls@uu.net; Thu, 27 Jun 2002 17:23:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: LDP-MIB & VPN-MIB
Date: Thu, 27 Jun 2002 17:23:42 -0400
Message-ID: <5F2B8267D7B55B47BDE2868D227BF50C06A65D@OCCLUST01EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: LDP-MIB & VPN-MIB
Thread-Index: AcIeIOldLhtlIInhEdaBYgAQpK0tbw==
From: "Chung, Li-Jin W, ALCNS" <lic@att.com>
To: <mpls@UU.NET>
Cc: "Ash, Gerald R (Jerry), ALASO" <gash@att.com>,
        "Nguyen, Mai-Uyen T, ALCNS" <mtnguyen@att.com>,
        "D'Souza, Kevin L, ALCNS" <kld@att.com>,
        "Lai, Wai S (Waisum), ALASO" <wlai@att.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17113

Hi.,

I am new to this list. So, if what I say here has been addressed by other means please let me know. 
Recently, I have studied draft-ietf-mpls-ldp-mib-08 and  draft-ietf-ppvpn-mpls-vpn-mib-03 and have identified some potential enhancement areas for our future considerations. I would like to get your feedback if these areas of observations make sense to you. 

In the LDP-MIB,
(1) The variables in the following two notifications do not have the information related to the IfIndex in the IF-MIB, this will prolong the proactive fault management cycle time for operators. 
1. mplsLdpSessionUp & 
2. mplsLdpSessionDown 

I would like to suggest to include "mplsLdpConfGenericIfIndexOrZero" or equivalent of such variable in the notification object.

(2)  There is no specification on how to retain the counters when an LDP-entity/session is broken and then reestablished again. Because of such, some implemenation will remove the entire entry statistics when an LDP-session is broken and when the same session is re-established again  the counter will be treated as a new counter. Some accumulation of such old and new counters need to be specified.

In the VPN-MIB,

(1) Although there is a notification  of  VRF maximum route threshold exceeded, there is no counter of number of routes dropped due to such threshold exceeds. I would like to suggest to add a counter of such dropped routes for capacity planning and for threshold tunning. 

(2) From what I can tell, in the route target table, there is no mapping for the associated RD. I would like to suggest to add such association between VRF, RD and RT in the RT table. 

Please let me know if you have any comments.

Thanks,

Li Chung




From owner-mpls@UU.NET  Thu Jun 27 18:11:01 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19458
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 18:11:01 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvcn14151;
	Thu, 27 Jun 2002 21:25:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvcn26817
	for mpls-outgoing; Thu, 27 Jun 2002 21:25:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvcn26808
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Jun 2002 21:25:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvcn04609
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:24:25 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvcn12503
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:24:24 GMT
Received: from mlsrv1.avici.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged))
	id QQmvcn12482
	for <mpls@UU.NET>; Thu, 27 Jun 2002 21:24:24 GMT
Received: from aatlas-lt.avici.com (b2-pc38.avici.com [10.2.100.58])
	by mlsrv1.avici.com (8.11.0/8.11.0) with ESMTP id g5RLO0n28360;
	Thu, 27 Jun 2002 17:24:00 -0400 (EDT)
Message-Id: <5.1.0.14.2.20020627171955.02081ce0@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 27 Jun 2002 17:25:15 -0400
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
From: Alia Atlas <aatlas@avici.com>
Subject: RE: your mail
Cc: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Eric Osborne'" <eosborne@cisco.com>,
        George Sheng <george_s97@hotmail.com>, scullptor@yahoo.com,
        mpls@UU.NET
In-Reply-To: <39469E08BD83D411A3D900204840EC55763231@vie-msgusr-01.dc.fo
 re.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

While it may be preferable to hash on the entire label stack (minus any 
reserved label values for the bottommost label) or the embedded IP header 
because this provides more diversity, it certainly possible to only 
consider the topmost label.  The same issue comes up for link-aggregation 
as for ECMP; traffic needs to be broken into micro-flows.  What constitutes 
a micro-flow and how large that can be is determined by the network 
location and application.

Regardless, the single label lookup for hardware is not currently a strong 
motivator for MPLS; it is the ability to decouple forwarding and control to 
provide what are essentially circuits which is a stronger motivator.

Alia

At 05:02 PM 6/27/2002 -0400, Naidu, Venkata wrote:
>Shahram,
>
>-> > ECMP is inherent in the architecture.
>->
>-> What? ECMP is a kludge to overcome LDP's inability to TE. If
>-> you think about it doing hashing of multiple labels and
>-> perhaps IP header in the middle of an LSP actually defeats
>-> the purpose of MPLS, which was supposed to be have a simple
>-> label lookup in the core.
>
>  Who said that ECMP will be achieved only by hashing labels
>  or IP header? I think you are thinking IP ECMP methods
>  (RFCs 2991 and 2992) to solve MPLS ECMP. You can do ECMP
>  in what ever way a vendor likes - after all, it is for
>  load balancing. You can still achieve simple label lookup at
>  the core by using appropriate ECMP technique(s).
>
>--
>Venkata.




From owner-mpls@UU.NET  Thu Jun 27 20:51:11 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24634
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 20:51:11 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdb05843
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 00:51:48 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvdb02654;
	Fri, 28 Jun 2002 00:49:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvdb18644
	for mpls-outgoing; Fri, 28 Jun 2002 00:49:44 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvdb18639
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 00:49:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvdb14760
	for <mpls@uu.net>; Fri, 28 Jun 2002 00:49:07 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdb17181
	for <mpls@uu.net>; Fri, 28 Jun 2002 00:49:06 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvdb17147
	for <mpls@uu.net>; Fri, 28 Jun 2002 00:49:03 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA26638 for <mpls@uu.net>; Thu, 27 Jun 2002 20:49:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA23929 for mpls@uu.net; Thu, 27 Jun 2002 20:49:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvdb18543
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 00:48:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvdb03925
	for <mpls@UU.NET>; Fri, 28 Jun 2002 00:47:47 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdb21373
	for <mpls@UU.NET>; Fri, 28 Jun 2002 00:47:47 GMT
Received: from hawk.CrescentNetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144])
	id QQmvdb21306
	for <mpls@UU.NET>; Fri, 28 Jun 2002 00:47:39 GMT
Received: from crescentnetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id UAA22899;
	Thu, 27 Jun 2002 20:46:41 -0400 (EDT)
Message-ID: <3D1BB27B.5D556FC5@crescentnetworks.com>
Date: Thu, 27 Jun 2002 20:48:59 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Chung, Li-Jin W, ALCNS" <lic@att.com>
CC: mpls@UU.NET, "Ash, Gerald R (Jerry), ALASO" <gash@att.com>,
        "Nguyen, Mai-Uyen T, ALCNS" <mtnguyen@att.com>,
        "D'Souza, Kevin L, ALCNS" <kld@att.com>,
        "Lai, Wai S (Waisum), ALASO" <wlai@att.com>
Subject: Re: LDP-MIB & VPN-MIB
References: <5F2B8267D7B55B47BDE2868D227BF50C06A65D@OCCLUST01EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello,

"Chung, Li-Jin W, ALCNS" wrote:
> 
> Hi.,
> 
> I am new to this list. So, if what I say here has been addressed by other means please let me know.
> Recently, I have studied draft-ietf-mpls-ldp-mib-08 and  draft-ietf-ppvpn-mpls-vpn-mib-03 and have identified some potential enhancement areas for our future considerations. I would like to get your feedback if these areas of observations make sense to you.
> 
> In the LDP-MIB,
> (1) The variables in the following two notifications do not have the information related to the IfIndex in the IF-MIB, this will prolong the proactive fault management cycle time for operators.
> 1. mplsLdpSessionUp &
> 2. mplsLdpSessionDown
> 
> I would like to suggest to include "mplsLdpConfGenericIfIndexOrZero" or equivalent of such variable in the notification object.

The mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId
(which are included) would give an operator a clear indication of which
port.  Operators would be creating Entities on each LSR and 
assign the LDP Identifiers, so in this specific case they would
have created the Entity (and assigned the mplsLdpEntityLdpId) and the
Peer (and assigned the mplsLdpPeerLdpId), so they should have the info
needed.

> 
> (2)  There is no specification on how to retain the counters when an LDP-entity/session is broken and then reestablished again. Because of such, some implemenation will remove the entire entry statistics when an LDP-session is broken and when the same session is re-established again  the counter will be treated as a new counter. Some accumulation of such old and new counters need to be specified.

There are 2 tables of counters.  

The first table of counters, mplsLdpEntityStatsTable, contain counters
of an Entity because these are counters which are received when a
session
is attempted/initializing.  These counters will help determine whether
or not the
session ever gets established.  These counters do not have a
discontinuity
time associated with them because seeing these is an indication that the
Session is not being established.  So, in other words, if you see these
counters increasing, that could be an indication that something is
misconfigured
with the corresponding Entity.  If you don't see a Session being
established on
this entity, then these counters are meant to help figure out why.


The second table of counters, mplsLdpSesStatsTable, contain
counters on a session.  These counters may have a discontinuity (i.e.
session up/down)
but that is noted in the mplsLdpSesDiscontinuityTime object which
corresponds to the entry.


Hope that help,
  -Joan


> 
> In the VPN-MIB,
> 
> (1) Although there is a notification  of  VRF maximum route threshold exceeded, there is no counter of number of routes dropped due to such threshold exceeds. I would like to suggest to add a counter of such dropped routes for capacity planning and for threshold tunning.
> 
> (2) From what I can tell, in the route target table, there is no mapping for the associated RD. I would like to suggest to add such association between VRF, RD and RT in the RT table.
> 
> Please let me know if you have any comments.
> 
> Thanks,
> 
> Li Chung



From owner-mpls@UU.NET  Thu Jun 27 22:16:40 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26820
	for <mpls-archive@lists.ietf.org>; Thu, 27 Jun 2002 22:16:40 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdh19857
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 02:17:19 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvdh16962;
	Fri, 28 Jun 2002 02:15:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvdh09094
	for mpls-outgoing; Fri, 28 Jun 2002 02:15:18 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvdh08910
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 02:15:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvdg11714
	for <mpls@uu.net>; Fri, 28 Jun 2002 02:14:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdg09718
	for <mpls@uu.net>; Fri, 28 Jun 2002 02:14:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvdg09707
	for <mpls@uu.net>; Fri, 28 Jun 2002 02:14:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA29599 for <mpls@uu.net>; Thu, 27 Jun 2002 22:14:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA02800 for mpls@uu.net; Thu, 27 Jun 2002 22:14:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvdg08579
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 02:12:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvdg17968
	for <mpls@UU.NET>; Fri, 28 Jun 2002 02:11:55 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvdg08176
	for <mpls@UU.NET>; Fri, 28 Jun 2002 02:11:55 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvdg08170
	for <mpls@UU.NET>; Fri, 28 Jun 2002 02:11:55 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA29496; Thu, 27 Jun 2002 22:11:54 -0400 (EDT)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA27624; Thu, 27 Jun 2002 22:11:54 -0400 (EDT)
Date: Thu, 27 Jun 2002 22:11:54 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Eric Osborne'" <eosborne@cisco.com>,
        George Sheng <george_s97@hotmail.com>, scullptor@yahoo.com,
        mpls@UU.NET
Subject: Re: your mail
Message-ID: <20020628021154.GX24180@eosborne-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB0371F@nt-exch-yow.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB0371F@nt-exch-yow.pmc-sierra.bc.ca>
User-Agent: Mutt/1.4i
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote:
> > ECMP is inherent in the architecture. 
> 
> What? ECMP is a kludge to overcome LDP's inability to TE. 

That seems to be an Extremely Silly statement; if you want TE, use
RSVP.  RFC3209, in case you've missed it...:)



eric

> If you think about it doing hashing of multiple labels and perhaps
> IP header in the middle of an LSP actually defeats the purpose of
> MPLS, which was supposed to be have a simple label lookup in the
> core.

> -Shahram 
>  



From owner-mpls@UU.NET  Fri Jun 28 03:49:40 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13362
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 03:49:40 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmved25829
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 07:50:20 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmved23408;
	Fri, 28 Jun 2002 07:49:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmved24726
	for mpls-outgoing; Fri, 28 Jun 2002 07:49:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmved24721
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 07:48:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmved01682
	for <mpls@UU.NET>; Fri, 28 Jun 2002 07:48:24 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmved22873
	for <mpls@UU.NET>; Fri, 28 Jun 2002 07:48:24 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f33.law12.hotmail.com [64.4.19.33])
	id QQmved22865
	for <mpls@UU.NET>; Fri, 28 Jun 2002 07:48:23 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 28 Jun 2002 00:48:23 -0700
Received: from 63.197.79.145 by lw12fd.law12.hotmail.msn.com with HTTP;
	Fri, 28 Jun 2002 07:48:22 GMT
X-Originating-IP: [63.197.79.145]
From: "George Sheng" <george_s97@hotmail.com>
To: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com
Cc: scullptor@yahoo.com, mpls@UU.NET
Subject: Re: your mail
Date: Fri, 28 Jun 2002 07:48:22 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F33njQ8vjqueolj8Jec000004f7@hotmail.com>
X-OriginalArrivalTime: 28 Jun 2002 07:48:23.0025 (UTC) FILETIME=[2DA14E10:01C21E78]
Sender: owner-mpls@UU.NET
Precedence: bulk

] On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote:
] > > ECMP is inherent in the architecture.
] >
] > What? ECMP is a kludge to overcome LDP's inability to TE.
]
] That seems to be an Extremely Silly statement; if you want TE, use
] RSVP.  RFC3209, in case you've missed it...:)
]

Ok, let's not to argue with the diff between the ECMP and TE;
The point is that, it's trivial to do per packet loadsharing,
I assume this is not you meant by "architecture". The trick
is to do flow based loadsharing in the middle of LDP tunnels
without performance degradation.

]
]
] eric
]
] > If you think about it doing hashing of multiple labels and perhaps
] > IP header in the middle of an LSP actually defeats the purpose of
] > MPLS, which was supposed to be have a simple label lookup in the
] > core.
]
] > -Shahram
] >
]
-george


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From owner-mpls@UU.NET  Fri Jun 28 04:37:19 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14517
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 04:37:19 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmveg22185
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 08:37:57 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmveg20257;
	Fri, 28 Jun 2002 08:37:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmveg20333
	for mpls-outgoing; Fri, 28 Jun 2002 08:36:40 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmveg20328
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 08:36:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmveg19079
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:36:00 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmveg15009
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:36:00 GMT
Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.190.133.225])
	id QQmveg14976
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:35:55 GMT
Received: from cyborg (localhost [127.0.0.1])
	by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g5S8cMK21002
	for <mpls@UU.NET>; Fri, 28 Jun 2002 14:08:22 +0530
Reply-To: <mkumar@aplion.stpn.soft.net>
From: "Mayank Kumar" <mkumar@aplion.stpn.soft.net>
To: <mpls@UU.NET>
Subject: Mayank (New member)
Date: Fri, 28 Jun 2002 14:08:45 +0530
Message-ID: <017b01c21e7f$38170db0$feca64c0@cyborg>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi

i am new to this mailing list and a newbie to the MPLS standard as well.
I have read all the relevant rfc's related to MPLS.I have three questions to
the group:-

1:why is a shim header called so??? I mean , what does shim stand for???

2:on a frame based LSR , there can be two atm interfaces. While switcing
between these two atm interfaces on a frame based LSR, is segmentation and
reassembly performed??

3:I want to setup a LSP for a certain destination using hop-by-hop routed
path. Can anybody describe the complete set of procedcures for doing this...

thanks
and regds
Mayank






From owner-mpls@UU.NET  Fri Jun 28 04:53:50 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14897
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 04:53:49 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmveh20391
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 08:54:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmveh17677;
	Fri, 28 Jun 2002 08:53:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmveh21913
	for mpls-outgoing; Fri, 28 Jun 2002 08:52:45 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmveh21908
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 08:52:41 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmveh05963
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:51:46 GMT
From: suchauhan@hss.hns.com
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmveh20176
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:51:46 GMT
Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.26.202])
	id QQmveh20163
	for <mpls@UU.NET>; Fri, 28 Jun 2002 08:51:44 GMT
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g5S8qLY08990;
	Fri, 28 Jun 2002 14:22:21 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g5S8qh913235;
	Fri, 28 Jun 2002 14:22:43 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256BE6.003056BD ; Fri, 28 Jun 2002 14:17:59 +0530
X-Lotus-FromDomain: HSS
To: mkumar@aplion.stpn.soft.net
cc: mpls@UU.NET
Message-ID: <65256BE6.003055D2.00@sandesh.hss.hns.com>
Date: Fri, 28 Jun 2002 14:20:25 +0530
Subject: Re: Mayank (New member)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



welcome!
     Pls see answers below. Hope it helps

ciao
sumit




"Mayank Kumar" <mkumar@aplion.stpn.soft.net> on 06/28/2002 02:08:45 PM

Please respond to mkumar@aplion.stpn.soft.net

To:   mpls@UU.NET
cc:    (bcc: Sumit Chauhan/HSS)

Subject:  Mayank (New member)




hi

i am new to this mailing list and a newbie to the MPLS standard as well.
I have read all the relevant rfc's related to MPLS.I have three questions to
the group:-

1:why is a shim header called so??? I mean , what does shim stand for???
Ans. dunno....I guess shim means thin!

2:on a frame based LSR , there can be two atm interfaces. While switcing
between these two atm interfaces on a frame based LSR, is segmentation and
reassembly performed??
Ans. Segmentations and reassembly essentially should be carried out at the
ingress and destination respectively to avoid overhead. Should use PMTU
protocol.

3:I want to setup a LSP for a certain destination using hop-by-hop routed
path. Can anybody describe the complete set of procedcures for doing this...
Ans. Hmmmmm its hard to give the exact set of evets/configurations here but
lemme try to give you a top level view

Step 1 . Let IGP stabilize on all participating LSRs after the network comes up

Step 2. Use the unicast rechability information given to you by IGP to setup
LSPs between LSRs using DoD or Unsolicited mechanisms

Step 3. The ingress LSRs should start classifying packets based on the FEC
information that has any linked LSPs with it.

Step 4. Packets coming in with the correct FEC match are used for searching the
ILM table and forwarded to the intermediate LSRs which search their FTN and
forward the packet using appropriate labels (ATM, FR, Shim etc)

Step 5. The egress LSR (penultimate in case of PHP support) shall strip the
packet MPLS header and forward the native data (IP) packet.

thanks
and regds
Mayank












From owner-mpls@UU.NET  Fri Jun 28 05:21:11 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15412
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 05:21:11 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvej06937
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 09:21:51 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvej05392;
	Fri, 28 Jun 2002 09:20:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvej16060
	for mpls-outgoing; Fri, 28 Jun 2002 09:20:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvej16055
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 09:20:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvej29316
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:20:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvej22190
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:20:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvej22178
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:20:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA17776 for <mpls@uu.net>; Fri, 28 Jun 2002 05:20:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA15147 for mpls@uu.net; Fri, 28 Jun 2002 05:20:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvej15990
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 09:18:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvej11857
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:18:30 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvej21158
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:18:30 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: europe.cisco.com [144.254.52.73])
	id QQmvej21150
	for <mpls@uu.net>; Fri, 28 Jun 2002 09:18:29 GMT
Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp4189.cisco.com [10.50.16.92])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19851;
	Fri, 28 Jun 2002 11:18:22 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20020628111537.0419b690@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Jun 2002 11:18:19 +0200
To: mpls@UU.NET
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
Cc: ccamp@ops.ietf.org, acharny@cisco.com, flefauch@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Sorry for the confusion ... I meant:

"Although, this draft fits in MPLS WG, I'm copying CCAMP as some aspects 
are related to the ongoing protection/restoration work done in CCAMP".

And we're still interested by your comments, thanks.

JP.

>Date: Thu, 27 Jun 2002 17:34:22 +0200
>To: mpls@uu.net
>From: Jean Philippe Vasseur <jvasseur@cisco.com>
>Subject: Fwd: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>Cc: ccamp@ops.ietf.org
>
>Hi,
>
>This draft proposes a model for the backup tunnel computation to provide 
>bandwidth guaranty with MPLS TE Fast Reroute. This gives to FRR the 
>capability to provide not only a fast convergence but also bandwidth 
>guaranties while making an efficient backup bandwidth usage.
>
>Altough this draft fits in CCAMP, I'm copying CCAMP as some aspects may be 
>related to the ongoing protection/restoration work done in CCAMP.
>
>Any comment is of course very welcome.
>
>Thanks.
>
>JP.
>
>>To: IETF-Announce:;
>>CC: mpls@UU.NET
>>From: Internet-Drafts@ietf.org
>>Reply-to: Internet-Drafts@ietf.org
>>Subject: I-D ACTION:draft-vasseur-mpls-backup-computation-00.txt
>>Date: Thu, 27 Jun 2002 06:39:03 -0400
>>Sender: owner-mpls@UU.NET
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>
>>         Title           : MPLS Traffic Engineering Fast reroute: backup 
>> tunnel
>>                           path computation for bandwidth protection
>>         Author(s)       : J. Vasseur et al.
>>         Filename        : draft-vasseur-mpls-backup-computation-00.txt
>>         Pages           : 43
>>         Date            : 26-Jun-02
>>
>>This draft proposes an efficient model called ''Facility based
>>computation model'' for computing bypass tunnels paths in the context of
>>the MPLS TE Fast Reroute, while allowing bandwidth sharing between
>>backup tunnel protecting independent resources. Both a centralized and
>>a distributed path computation scenarios are described. The required
>>signaling extensions are also addressed in the draft.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>>
>>To remove yourself from the IETF Announcement list, send a message to
>>ietf-announce-request with the word unsubscribe in the body of the message.
>>
>>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-vasseur-mpls-backup-computation-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:
>>         mailserv@ietf.org.
>>In the body type:
>>         "FILE 
>> /internet-drafts/draft-vasseur-mpls-backup-computation-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.
>>Content-Type: text/plain
>>Content-ID:     <20020626134733.I-D@ietf.org>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-vasseur-mpls-backup-computation-00.txt
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-00.txt>



From owner-mpls@UU.NET  Fri Jun 28 06:20:28 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16697
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 06:20:28 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven24067
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 10:21:12 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmven22766;
	Fri, 28 Jun 2002 10:20:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmven12560
	for mpls-outgoing; Fri, 28 Jun 2002 10:19:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmven12554
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 10:19:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmven17453
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:15 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven26397
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:15 GMT
Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmven26372
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:15 GMT
Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19)
	id <NXZBB3NY>; Fri, 28 Jun 2002 11:18:03 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABF36@mbddmknt01.hc.bt.com>
To: Venkata.Naidu@Marconi.com
Cc: mpls@UU.NET
Subject: RE: your mail
Date: Fri, 28 Jun 2002 11:15:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Venkata,

So that I can better understand what you mean here, can you please then
explain:
-	how you are going to know how to load balance when we have IP
clients and other clients of the LSPs (eg the XoverMPLS PWE3 drafts)
-	how pkt misordering is avoided for clients that expect ordered
delivery?
-	how correctly behaving load-balancing is ensured, ie how are defects
in the load balancing detected/diagnosed?
-	where is all the above specified?

regards, Neil

> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: 27 June 2002 22:03
> To: 'Shahram Davari'; 'Eric Osborne'; George Sheng
> Cc: scullptor@yahoo.com; mpls@UU.NET
> Subject: RE: your mail
> 
> 
> Shahram,
> 
> -> > ECMP is inherent in the architecture. 
> -> 
> -> What? ECMP is a kludge to overcome LDP's inability to TE. If 
> -> you think about it doing hashing of multiple labels and 
> -> perhaps IP header in the middle of an LSP actually defeats 
> -> the purpose of MPLS, which was supposed to be have a simple 
> -> label lookup in the core.
> 
>  Who said that ECMP will be achieved only by hashing labels
>  or IP header? I think you are thinking IP ECMP methods
>  (RFCs 2991 and 2992) to solve MPLS ECMP. You can do ECMP
>  in what ever way a vendor likes - after all, it is for
>  load balancing. You can still achieve simple label lookup at
>  the core by using appropriate ECMP technique(s).
> 
> --
> Venkata.
> 


From owner-mpls@UU.NET  Fri Jun 28 06:21:02 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16720
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 06:21:01 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven06359
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 10:21:44 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmven05077;
	Fri, 28 Jun 2002 10:21:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmven12565
	for mpls-outgoing; Fri, 28 Jun 2002 10:19:59 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmven12555
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 10:19:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmven18109
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:28 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven26596
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:28 GMT
Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmven26578
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:28 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <NVVX90HD>; Fri, 28 Jun 2002 11:18:12 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABF37@mbddmknt01.hc.bt.com>
To: aatlas@avici.com
Cc: mpls@UU.NET
Subject: RE: your mail
Date: Fri, 28 Jun 2002 11:15:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Alia Atlas wrote 27 June 2002 22:25
> 
> While it may be preferable to hash on the entire label stack 
> (minus any 
> reserved label values for the bottommost label) or the 
> embedded IP header 
> because this provides more diversity, it certainly possible to only 
> consider the topmost label.  The same issue comes up for 
> link-aggregation 
> as for ECMP; traffic needs to be broken into micro-flows.  
> What constitutes 
> a micro-flow and how large that can be is determined by the network 
> location and application.
> 
> Regardless, the single label lookup for hardware is not 
> currently a strong 
> motivator for MPLS; it is the ability to decouple forwarding 
> and control to 
> provide what are essentially circuits which is a stronger motivator.
NH=> I agree with you Alia.  But to me 'ccts' = p2p trails.  These can be
properly and deterministically managed.  LDP mp2p stuff can't, and
introduces problems that don't exist for IP or p2p LSPs.  If you want
any-any behaviour IP(inIP say) is the right solution.  If you want strong
fault/QoS management p2p LSPs is the right solution.  IP(inIP) self-protects
against misconnectivity problems because each pkt carries a full/absolute
address......in MPLS we only have relative addresses (labels) and these give
poor protection against connectivity defects.  Merging across
like-DS-classes is another problem, ie can' separate per VPN survivability,
and post failure behaviour is now an indeterministic temporally varying
function of the traffic active in VPNs (answer is to over-engineer and
hope).  Inability to do anything but SPF is another problem....so we have to
start looking above the label, and I agree with Shahram this is now breaking
the simple label-fowarding idea of MPLS.
<snipped to end>


From owner-mpls@UU.NET  Fri Jun 28 06:21:17 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16747
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 06:21:17 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven29926
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 10:22:01 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmven28582;
	Fri, 28 Jun 2002 10:21:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmven12593
	for mpls-outgoing; Fri, 28 Jun 2002 10:20:19 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmven12586
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 10:20:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmven09846
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:16 GMT
From: neil.2.harrison@bt.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmven26421
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:16 GMT
Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQmven26395
	for <mpls@UU.NET>; Fri, 28 Jun 2002 10:19:15 GMT
Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19)
	id <NXZBB3N7>; Fri, 28 Jun 2002 11:18:03 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE0514BABF38@mbddmknt01.hc.bt.com>
To: eosborne@cisco.com, Shahram_Davari@pmc-sierra.com
Cc: mpls@UU.NET
Subject: RE: your mail
Date: Fri, 28 Jun 2002 11:15:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric Osborne wrote  28 June 2002 03:12

> On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote:
> > > ECMP is inherent in the architecture. 
> > 
> > What? ECMP is a kludge to overcome LDP's inability to TE. 
> 
> That seems to be an Extremely Silly statement; if you want TE, use
> RSVP.  RFC3209, in case you've missed it...:)
NH=> Eric, I'd agree it would be a silly statement if it were not
true......but it is true (otherwise why it is being done?)


From owner-mpls@UU.NET  Fri Jun 28 10:02:17 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27034
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 10:02:17 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfc28413
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 14:03:00 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfc26039;
	Fri, 28 Jun 2002 14:01:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfc14610
	for mpls-outgoing; Fri, 28 Jun 2002 14:01:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvfc14498
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 14:01:34 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvfc28074
	for <mpls@UU.NET>; Fri, 28 Jun 2002 14:01:29 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfc25722
	for <mpls@UU.NET>; Fri, 28 Jun 2002 14:01:29 GMT
Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18])
	id QQmvfc25715
	for <mpls@UU.NET>; Fri, 28 Jun 2002 14:01:28 GMT
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA01628;
	Fri, 28 Jun 2002 16:01:08 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA20639;
	Fri, 28 Jun 2002 16:01:10 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2653.19)
	id <MYNQ7XC4>; Fri, 28 Jun 2002 16:00:41 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B8B8@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: mpls@UU.NET
Cc: "'pwe3@ietf.org'" <pwe3@ietf.org>
Subject: N-square problem related investigations
Date: Fri, 28 Jun 2002 16:00:39 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I submitted the following I-D, which reports about 4 different methods on how to
accomplish a full mesh connectivity, i.e. on how to tackle the N-square problem.
The reported results are based on a sample network with N=200 PEs.

http://search.ietf.org/internet-drafts/draft-hummel-mpls-n-square-investigations-00.txt 

This draft is a companion draft to 
http://search.ietf.org/internet-drafts/draft-hummel-mpls-hierarchical-lsp-01.txt

The topic of both I-Ds has also been the topic of the "pwe3 question" thread on the pwe3-mailing list.

Your comments are appreciated.

Regards,
Heinrich Hummel
Siemens AG


From owner-mpls@UU.NET  Fri Jun 28 11:11:08 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00139
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 11:11:08 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfg22270
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 15:11:45 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfg20430;
	Fri, 28 Jun 2002 15:10:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfg07621
	for mpls-outgoing; Fri, 28 Jun 2002 15:10:24 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvfg07593
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 15:10:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvfg10417
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:09:51 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfg19978
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:09:50 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvfg19972
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:09:50 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA04801; Fri, 28 Jun 2002 11:09:49 -0400 (EDT)
Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA20668; Fri, 28 Jun 2002 11:09:49 -0400 (EDT)
Message-Id: <200206281509.LAA20668@erosen-u10.cisco.com>
X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs
To: Eric Osborne <eosborne@cisco.com>
cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        George Sheng <george_s97@hotmail.com>, scullptor@yahoo.com,
        mpls@UU.NET
Subject: Re: your mail 
In-reply-to: Your message of Thu, 27 Jun 2002 22:11:54 -0400.
             <20020628021154.GX24180@eosborne-u10.cisco.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 28 Jun 2002 11:09:49 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Shahram> ECMP is a kludge to overcome LDP's inability to TE. 

EricO> That seems to be an Extremely Silly statement

Yes, indeed.  That's  a bit like saying that dynamic routing  is a kludge to
overcome IP's inability to set up end-to-end circuits for individual flows.

The ability to do load  balancing without creating extra states is generally
construed as  a good  thing, but I  guess not  by the "CO  networking rules"
crowd.  Next  we'll be  hearing  that  equal  cost load  balancing  couldn't
possibly work; violates some ITU architecture, no doubt.  ;-)






From owner-mpls@UU.NET  Fri Jun 28 11:29:42 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01007
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 11:29:42 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfi09994
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 15:30:23 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfh07389;
	Fri, 28 Jun 2002 15:29:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfh19163
	for mpls-outgoing; Fri, 28 Jun 2002 15:28:54 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvfh19154
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 15:28:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvfh14658
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:28:39 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfh07036
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:28:39 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQmvfh07028
	for <mpls@UU.NET>; Fri, 28 Jun 2002 15:28:39 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11714;
	Fri, 28 Jun 2002 11:28:37 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09546;
	Fri, 28 Jun 2002 11:28:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <NL660GNR>; Fri, 28 Jun 2002 11:28:36 -0400
Message-ID: <39469E08BD83D411A3D900204840EC55763234@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        "Naidu, Venkata"
	 <Venkata.Naidu@Marconi.com>
Cc: mpls@UU.NET
Subject: RE: your mail
Date: Fri, 28 Jun 2002 11:28:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Neil,

-> So that I can better understand what you mean here, can you 
-> please then
-> explain:
-> -	how you are going to know how to load balance when we have IP
-> clients and other clients of the LSPs (eg the XoverMPLS PWE3 drafts)

  I agree on this issue here - ECMP has inherent limitations.
  But load balancing is useful when we know what we are doing.
  So making it a configurable options is the way to solve
  the issue.

  IRTF Routing drafts reads... 
     4.7 Dynamic Load Balancing 

        Past history has shown that using the routing system to perform 
        highly dynamic load balancing among multiple more-or-less-equal 
        paths usually ends up causing all kinds of instability, etc, in 
        the network.  Thus, we do not require such a capability. 

        However, this is an area that is ripe for additional research, 
        and some believe that the capability will be necessary in the 
        future. Thus, the architecture and protocols should be 
        "malleable" enough to allow development and deployment of 
        dynamic load balancing capabilities, should we ever figure out 
        how to do it.   

  What I don't agree - "Just because MPLS is connection oriented
  and simple/fast label lookup doesn't mean that we shouldn't do
  load balancing. There is no requirement that we must do 
  load balancing using constraint based routing".

  You can do load balancing using plain old IP routing and signaling
  protocols which uses that routing (like LDP).

-> -	how pkt misordering is avoided for clients that expect ordered
-> delivery?

  Are you expecting that all connection-oriented protocols must
  assure ordered delivery ? In the interest of end-to-end Internet
  design, I expect all transport/session layer protocols will take 
  care of ordered delivery of packets to applications.

-> -	how correctly behaving load-balancing is ensured, ie 
-> how are defects in the load balancing detected/diagnosed?

  It is difficult to debug - even in case of *classical* IP ECMP.
  This is not a new issue with MPLS ECMP.
  
  RFC2991 reads...
   Debugging
         Common debugging utilities such as ping and traceroute are much
         less reliable in the presence of multiple paths and may even
         present completely wrong results.

-> -	where is all the above specified?

  As I said before, whether to do load balancing or not 
  is _not_ an interoperability issue. It's the best interest
  of any vendor. No *specification* required - *requirements*
  may be sufficient.

--
Venkata

-> > -----Original Message-----
-> > From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
-> > Sent: 27 June 2002 22:03
-> > To: 'Shahram Davari'; 'Eric Osborne'; George Sheng
-> > Cc: scullptor@yahoo.com; mpls@UU.NET
-> > Subject: RE: your mail
-> > 
-> > 
-> > Shahram,
-> > 
-> > -> > ECMP is inherent in the architecture. 
-> > -> 
-> > -> What? ECMP is a kludge to overcome LDP's inability to TE. If 
-> > -> you think about it doing hashing of multiple labels and 
-> > -> perhaps IP header in the middle of an LSP actually defeats 
-> > -> the purpose of MPLS, which was supposed to be have a simple 
-> > -> label lookup in the core.
-> > 
-> >  Who said that ECMP will be achieved only by hashing labels
-> >  or IP header? I think you are thinking IP ECMP methods
-> >  (RFCs 2991 and 2992) to solve MPLS ECMP. You can do ECMP
-> >  in what ever way a vendor likes - after all, it is for
-> >  load balancing. You can still achieve simple label lookup at
-> >  the core by using appropriate ECMP technique(s).
-> > 
-> > --
-> > Venkata.
-> > 
-> 


From owner-mpls@UU.NET  Fri Jun 28 11:42:56 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01742
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 11:42:56 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfi22692
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 15:43:24 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfi18898;
	Fri, 28 Jun 2002 15:41:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfi20173
	for mpls-outgoing; Fri, 28 Jun 2002 15:41:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvfi20091
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 15:41:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvfi23419
	for <mpls@uu.net>; Fri, 28 Jun 2002 15:41:00 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfi19847
	for <mpls@uu.net>; Fri, 28 Jun 2002 15:40:59 GMT
Received: from maynard.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: maynard.mail.mindspring.net [207.69.200.243])
	id QQmvfi19843
	for <mpls@uu.net>; Fri, 28 Jun 2002 15:40:59 GMT
Received: from user-uinjmf0.dsl.mindspring.com ([165.121.217.224] helo=METANOIA)
	by maynard.mail.mindspring.net with smtp (Exim 3.33 #1)
	id 17Nxrg-000516-00; Fri, 28 Jun 2002 11:40:52 -0400
Reply-To: <v.sharma@ieee.org>
From: "Vishal Sharma" <v.sharma@ieee.org>
To: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-recovery-frmwrk-04.txt
Date: Fri, 28 Jun 2002 11:46:31 -0400
Message-ID: <MMECLKMDFPCEJFECIBCMMEIMCNAA.v.sharma@ieee.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <4B6D09F3B826D411A67300D0B706EFDEB03721@nt-exch-yow.pmc-sierra.bc.ca>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Shahram,

Thanks for the observation. You are correct, both possibilities need to be
allowed for. We will update the text accordingly and reissue a revised
version,
which will only appear after Yokohama at this stage.

If you have any other questions, let us know.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Thursday, June 27, 2002 4:28 PM
> To: 'mpls@uu.net'
> Subject: RE: draft-ietf-mpls-recovery-frmwrk-04.txt
>
>
> Hi,
>
> Why is that in section 3.6. (Fault Notification), the only
> notification method mentioned is sending FIS upstream,
> hop-by-hop. Although this is possible but a simpler and more
> conventional method is to send the FIS to the PML and let the PML
> inform the PSL. Is this type of notification excluded? If so why,
> and if not could the authors please add it to the text.
>
>
> Thanks,
> Shahram
>




From owner-mpls@UU.NET  Fri Jun 28 13:28:38 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08640
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 13:28:38 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfp09972
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 17:29:19 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfp07935;
	Fri, 28 Jun 2002 17:28:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfp14457
	for mpls-outgoing; Fri, 28 Jun 2002 17:28:15 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvfp14440
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 17:28:05 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvfp11112
	for <mpls@UU.NET>; Fri, 28 Jun 2002 17:27:17 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfp01880
	for <mpls@UU.NET>; Fri, 28 Jun 2002 17:27:17 GMT
Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged))
	id QQmvfp01875
	for <mpls@UU.NET>; Fri, 28 Jun 2002 17:27:16 GMT
Message-ID: <EB5FFC72F183D411B38200062957342901E57922@r2d2.axiowave.com>
From: Jeff Parker <jparker@axiowave.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Cc: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: Control vs Client Links in IS-IS TE
Date: Fri, 28 Jun 2002 13:27:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Consider a service provider who wishes to distinguish his control traffic
from the network he provides subscribers, by distinguishing his control
links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that
only run customer traffic. 

Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP
to router B.  How can IS-IS distinguish the two types of links if it is
using wide metrics?

In OSPF, we can send an Opaque LSA with info about an LSP.  This will not be
used for the IGP's SPF.  
However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus
looks like a normal link from A to B when the router is using Wide Metrics
in the SPF.  If B also has an LSP to A, other routers will have no way to
distinguish an MPLS LSP link intended for CSPF and those to be used in the
IGP's SPF.  I could imagine using a field such as Switch Capability, to
decide if a link should be included in SPF or not, but haven't seen this
suggested anywhere.  

- jeff parker
- axiowave networks


From owner-mpls@UU.NET  Fri Jun 28 14:09:49 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11175
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 14:09:49 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfs20611
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 18:10:31 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfs18118;
	Fri, 28 Jun 2002 18:09:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfs08514
	for mpls-outgoing; Fri, 28 Jun 2002 18:08:55 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvfs08505
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 18:08:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvfs05255
	for <mpls@UU.NET>; Fri, 28 Jun 2002 18:07:24 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfs14722
	for <mpls@UU.NET>; Fri, 28 Jun 2002 18:07:24 GMT
Received: from xover.netplane.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQmvfs14717
	for <mpls@UU.NET>; Fri, 28 Jun 2002 18:07:23 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <NYGKRD8T>; Fri, 28 Jun 2002 14:07:22 -0400
Message-ID: <E7E13AAF2F3ED41197C100508BD6A328291FA5@india_exch.hyderabad.mindspeed.com>
From: "Manral, Vishwas" <VishwasM@netplane.com>
To: "'Jeff Parker'" <jparker@axiowave.com>, "'mpls@UU.NET'" <mpls@UU.NET>
Cc: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: RE: Control vs Client Links in IS-IS TE
Date: Fri, 28 Jun 2002 14:09:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Jeff,

I guess in Section 4.0 of draft
http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt it is
stated that

   If a link is advertised with the maximum link metric (2^24 - 1), this
   link should not be considered during the normal SPF computation.

So if we want to preclude a link from normal SPF and yet use it for MPLS
LSP's we can set the metric to the value 2^24 - 1.

Thanks,
Vishwas

-----Original Message-----
From: Jeff Parker [mailto:jparker@axiowave.com]
Sent: Friday, June 28, 2002 10:57 PM
To: 'mpls@UU.NET'
Cc: 'ccamp@ops.ietf.org'
Subject: Control vs Client Links in IS-IS TE


Consider a service provider who wishes to distinguish his control traffic
from the network he provides subscribers, by distinguishing his control
links, running pure IP traffic and the IS-IS protocol, from MPLS LSPs that
only run customer traffic. 

Imagine an MPLS router A that has some IP control interfaces and an MPLS LSP
to router B.  How can IS-IS distinguish the two types of links if it is
using wide metrics?

In OSPF, we can send an Opaque LSA with info about an LSP.  This will not be
used for the IGP's SPF.  
However, TLV 22 in ISIS always includes 3 bytes of default metric, and thus
looks like a normal link from A to B when the router is using Wide Metrics
in the SPF.  If B also has an LSP to A, other routers will have no way to
distinguish an MPLS LSP link intended for CSPF and those to be used in the
IGP's SPF.  I could imagine using a field such as Switch Capability, to
decide if a link should be included in SPF or not, but haven't seen this
suggested anywhere.  

- jeff parker
- axiowave networks


From owner-mpls@UU.NET  Fri Jun 28 15:51:02 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17891
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 15:51:02 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfz27833
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 19:51:41 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvfz24554;
	Fri, 28 Jun 2002 19:49:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvfz09496
	for mpls-outgoing; Fri, 28 Jun 2002 19:49:39 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvfz09490
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 19:49:36 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvfz14282
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:49:27 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfz05489
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:49:27 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvfz05484
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:49:26 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA27286 for <mpls@uu.net>; Fri, 28 Jun 2002 15:49:26 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA03266 for mpls@uu.net; Fri, 28 Jun 2002 15:49:26 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvfw27060
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 19:04:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvfw26198
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:04:11 GMT
From: mpls@savio.mailshell.com
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvfw17518
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:04:11 GMT
Received: from mailshell.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: www14.mailshell.com [209.157.66.246])
	id QQmvfw17511
	for <mpls@uu.net>; Fri, 28 Jun 2002 19:04:10 GMT
Received: (qmail 3257 invoked by uid 99); 28 Jun 2002 19:04:09 -0000
Message-ID: <20020628190409.14407.qmail@mailshell.com>
Subject: MplsBitRate inconsistently described in MPLS-TE and MPLS-TC MIBS
Date: Fri, 28 Jun 2002 15:03:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
To: mpls@UU.NET
Sender: owner-mpls@UU.NET
Precedence: bulk

I've listed below some inconsistencies that I came across in the MPLS-TE and
MPLS-TC MIBS. These issues may have been already been addressed here, if
that is the case please consider this a reminder to make the necessary
updates.

Thanks.
-patrick.

1. The TE MIB reads "bits per second" under UNITS for various objects that
use the "MplsBitRate" SYNTAX.
The TC MIB however says that it is in "1000 bits per second".
2. The description for mplsTunnelResourceMaxRate says that the values for
mplsTunnelResourceMaxRate, mplsTunnelResourceMeanRate and
mplsTunnelResourceMaxBurstSize can be set to 0 to indicate Best Effort
Treatment. If this is to be allowed then the range for MplsBitRate needs to
be corrected in the TC MIB, the range is currently "Integer32
(1..2147483647)".
3. The description for MplsBitRate in the TC MIB reads 
          "...If this object reports a value of 'n' then
          the rate of the object is somewhere in the range of
          'n-500' to 'n+499'..."
I think the last part should read 'n*1000-500' to 'n*1000+499' otherwise if
the object returns 1, then the object would be in the range of -499 to 500
which is wrong.


---------------------------------------------------------
Patrick Dominic-Savio    
Marconi Communications 
2000 Marconi Drive 1-155 
Warrendale, PA 15086 



From owner-mpls@UU.NET  Fri Jun 28 18:07:01 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25120
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 18:07:01 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvgi13996
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 22:07:38 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvgi09734;
	Fri, 28 Jun 2002 22:05:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvgi22379
	for mpls-outgoing; Fri, 28 Jun 2002 22:04:55 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvgi20954
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 22:04:46 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvgi28796
	for <mpls@uu.net>; Fri, 28 Jun 2002 22:04:03 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvgi27391
	for <mpls@uu.net>; Fri, 28 Jun 2002 22:04:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvgi27377
	for <mpls@uu.net>; Fri, 28 Jun 2002 22:04:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA06851 for <mpls@uu.net>; Fri, 28 Jun 2002 18:04:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA16974 for mpls@uu.net; Fri, 28 Jun 2002 18:04:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvgi18267
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Jun 2002 22:02:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvgi11353
	for <mpls@UU.NET>; Fri, 28 Jun 2002 22:01:40 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvgi06930
	for <mpls@UU.NET>; Fri, 28 Jun 2002 22:01:40 GMT
Received: from hawk.CrescentNetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144])
	id QQmvgi06921
	for <mpls@UU.NET>; Fri, 28 Jun 2002 22:01:40 GMT
Received: from crescentnetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id SAA19563;
	Fri, 28 Jun 2002 18:01:38 -0400 (EDT)
Message-ID: <3D1CDD4A.F301CF43@crescentnetworks.com>
Date: Fri, 28 Jun 2002 18:03:54 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@savio.mailshell.com
CC: mpls@UU.NET
Subject: Re: MplsBitRate inconsistently described in MPLS-TE and MPLS-TC MIBS
References: <20020628190409.14407.qmail@mailshell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Patrick,

These MIB drafts are currently being updated.
The MPLS-TE MIB will IMPORT the Textual Conventions(TCs) from
the MPLS-TC MIB.

Also, the inconsistencies you point out have been addressed
in the updates of the TC MIB and will be available in the
next draft of this MIB.

Thank you for your email!

-Joan

mpls@savio.mailshell.com wrote:
> 
> I've listed below some inconsistencies that I came across in the MPLS-TE and
> MPLS-TC MIBS. These issues may have been already been addressed here, if
> that is the case please consider this a reminder to make the necessary
> updates.
> 
> Thanks.
> -patrick.
> 
> 1. The TE MIB reads "bits per second" under UNITS for various objects that
> use the "MplsBitRate" SYNTAX.
> The TC MIB however says that it is in "1000 bits per second".
> 2. The description for mplsTunnelResourceMaxRate says that the values for
> mplsTunnelResourceMaxRate, mplsTunnelResourceMeanRate and
> mplsTunnelResourceMaxBurstSize can be set to 0 to indicate Best Effort
> Treatment. If this is to be allowed then the range for MplsBitRate needs to
> be corrected in the TC MIB, the range is currently "Integer32
> (1..2147483647)".
> 3. The description for MplsBitRate in the TC MIB reads
>           "...If this object reports a value of 'n' then
>           the rate of the object is somewhere in the range of
>           'n-500' to 'n+499'..."
> I think the last part should read 'n*1000-500' to 'n*1000+499' otherwise if
> the object returns 1, then the object would be in the range of -499 to 500
> which is wrong.
> 
> ---------------------------------------------------------
> Patrick Dominic-Savio
> Marconi Communications
> 2000 Marconi Drive 1-155
> Warrendale, PA 15086



From owner-mpls@UU.NET  Fri Jun 28 21:50:17 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02362
	for <mpls-archive@lists.ietf.org>; Fri, 28 Jun 2002 21:50:16 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvgx14502
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 01:50:58 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvgx11631;
	Sat, 29 Jun 2002 01:49:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvgx22426
	for mpls-outgoing; Sat, 29 Jun 2002 01:49:20 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvgx22421
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 29 Jun 2002 01:49:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmvgx16257
	for <mpls@UU.NET>; Sat, 29 Jun 2002 01:49:11 GMT
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvgx11366
	for <mpls@UU.NET>; Sat, 29 Jun 2002 01:49:10 GMT
Received: from mail.cad.zju.edu.cn by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: cad.zju.edu.cn [210.32.131.2])
	id QQmvgx11362
	for <mpls@UU.NET>; Sat, 29 Jun 2002 01:49:09 GMT
Received: (qmail 22959 invoked from network); 29 Jun 2002 01:54:22 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 29 Jun 2002 01:54:22 -0000
Message-ID: <3D1D1219.A3AD600@cad.zju.edu.cn>
Date: Sat, 29 Jun 2002 09:49:13 +0800
From: Jing Shen <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
CC: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>, mpls@UU.NET
Subject: Re: your mail
References: <39469E08BD83D411A3D900204840EC55763234@vie-msgusr-01.dc.fore.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


>   What I don't agree - "Just because MPLS is connection oriented
>   and simple/fast label lookup doesn't mean that we shouldn't do
>   load balancing. There is no requirement that we must do
>   load balancing using constraint based routing".
> 
>   You can do load balancing using plain old IP routing and signaling
>   protocols which uses that routing (like LDP).
> 

Although someone has presented that by optimizing path weight load
balancing across
ISP network could be achieved, its ability is limited by its
prerequirement of determining
traffic matrix before computing. As network usage increase
exponentially, such method 
has the drawback of computing load. That is why I think we should find
new way to
do with TE requirement. LDP using shortest-path first algorithm could
not solve
the problem, while CR-LDP with source routing could be a solution but
perhaps multipath
routing is the best one. 

But, there has not been much research done with multipath routing esp.
under the 
situation of self-similar traffic load, and how to provide monitoring
and debugging
ability in multipath routing system is another open problem. 




>   Are you expecting that all connection-oriented protocols must
>   assure ordered delivery ? In the interest of end-to-end Internet
>   design, I expect all transport/session layer protocols will take
>   care of ordered delivery of packets to applications.
> 

Although it has been showed that out-of-order has little effect on e2e
performance, high-speed access speed will enlarge that effect when 
more and more UDP based application is employed in current network which 
is the trends of current multimedia application. So, I think the to
avoid such
problem, stream based load balancing should be preferred. 



-- 
Jing Shen



**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************


From owner-mpls@UU.NET  Sat Jun 29 05:15:01 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20858
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 05:15:00 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvib06970
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 09:15:42 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvia04557;
	Sat, 29 Jun 2002 09:14:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvia21737
	for mpls-outgoing; Sat, 29 Jun 2002 09:14:19 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvia21730
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 29 Jun 2002 09:14:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvia09468
	for <mpls@uu.net>; Sat, 29 Jun 2002 09:13:24 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvia04127
	for <mpls@uu.net>; Sat, 29 Jun 2002 09:13:23 GMT
Received: from ls405.hinet.hr by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ls405.hinet.hr [195.29.150.97])
	id QQmvia04122
	for <mpls@uu.net>; Sat, 29 Jun 2002 09:13:22 GMT
Received: from ls401.hinet.hr (ls401.hinet.hr [195.29.150.2])
	by ls405.hinet.hr (0.0.0/8.11.6) with ESMTP id g5T9DMY09858
	for <mpls@uu.net>; Sat, 29 Jun 2002 11:13:22 +0200
Received: from strippy (ad28-m90.net.hinet.hr [195.29.63.90])
	by ls401.hinet.hr (8.11.6/8.11.3) with SMTP id g5T9DL131272
	for <mpls@uu.net>; Sat, 29 Jun 2002 11:13:21 +0200
Message-ID: <004501c21f4d$b5cf74d0$0100a8c0@strippy>
From: "Neven Milinovic" <neven.milinovic@zg.hinet.hr>
To: <mpls@UU.NET>
Subject: RATES: A server for MPLS Traffic Engineering
Date: Sat, 29 Jun 2002 11:16:53 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is it possible to find more information about RATES ( A server for MPLS
Traffic Engineering). Any documentation on implementation (papers, source
codes etc) and simulation results would be appreciated.



From owner-mpls@UU.NET  Sat Jun 29 05:27:41 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21042
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 05:27:41 -0400 (EDT)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvib18170
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 09:28:22 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvib11849;
	Sat, 29 Jun 2002 09:25:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvib22920
	for mpls-outgoing; Sat, 29 Jun 2002 09:25:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmvib22915
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 29 Jun 2002 09:25:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvib03136
	for <mpls@UU.NET>; Sat, 29 Jun 2002 09:25:05 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvib16993
	for <mpls@UU.NET>; Sat, 29 Jun 2002 09:25:04 GMT
Received: from web20807.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20807.mail.yahoo.com [216.136.226.196])
	id QQmvib16978
	for <mpls@UU.NET>; Sat, 29 Jun 2002 09:25:03 GMT
Message-ID: <20020629092502.17636.qmail@web20807.mail.yahoo.com>
Received: from [134.193.6.40] by web20807.mail.yahoo.com via HTTP; Sat, 29 Jun 2002 02:25:02 PDT
Date: Sat, 29 Jun 2002 02:25:02 -0700 (PDT)
From: senthil ayyasamy <mplsgeek@yahoo.com>
Subject: Re: RATES: A server for MPLS Traffic Engineering
To: Neven Milinovic <neven.milinovic@zg.hinet.hr>, mpls@UU.NET
In-Reply-To: <004501c21f4d$b5cf74d0$0100a8c0@strippy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


--- Neven Milinovic <neven.milinovic@zg.hinet.hr>
wrote:
> Is it possible to find more information about RATES
> ( A server for MPLS
> Traffic Engineering). Any documentation on
> implementation (papers, source
> codes etc) and simulation results would be
> appreciated.
> 
 - IEEE network paper(tutorials)
   http://citeseer.nj.nec.com/298267.html
They had a draft but expired .
  I am not aware of deployment of RATES.
  


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-mpls@UU.NET  Sat Jun 29 16:15:24 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04410
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 16:15:24 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvjt09561
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 20:16:02 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvjt07430;
	Sat, 29 Jun 2002 20:15:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvjs12889
	for mpls-outgoing; Sat, 29 Jun 2002 20:14:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvjs12880
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 29 Jun 2002 20:14:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvjs20307
	for <mpls@uu.net>; Sat, 29 Jun 2002 20:14:17 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvjs07149
	for <mpls@uu.net>; Sat, 29 Jun 2002 20:14:16 GMT
Received: from excalibur.santera.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: exchange.santera.com [4.22.157.11])
	id QQmvjs07143
	for <mpls@uu.net>; Sat, 29 Jun 2002 20:14:16 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: PPVPN-MIB draft
Date: Sat, 29 Jun 2002 15:14:12 -0500
Message-ID: <CD110021698980419241042CF576B8F2018F5206@EXCALIBUR.santera.com>
Thread-Topic: PPVPN-MIB draft
Thread-Index: AcIfqYg2oex0dq1HTI6k+Qn4pwuphQ==
From: "Zhu, Rupert" <rupert.zhu@santera.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04410

Just an editorial note on draft-ietf-ppvpn-mpls-vpn-mib-04.txt.

The "Table of Contents" and the main text are out of synch.
for example, Section 9.0 in TOC is as follows.

    9.0    Summary of MPLS-VPN-MIB

But this section does not exist in the text body.  The subsequent
sections are mis-numbered.

Thanks.

-- Rupert


From owner-mpls@UU.NET  Sat Jun 29 21:48:28 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10168
	for <mpls-archive@lists.ietf.org>; Sat, 29 Jun 2002 21:48:28 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvkp02821
	for <mpls-archive@lists.ietf.org>; Sun, 30 Jun 2002 01:49:05 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvkp00058;
	Sun, 30 Jun 2002 01:47:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvkp28179
	for mpls-outgoing; Sun, 30 Jun 2002 01:47:11 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQmvkp28174
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Jun 2002 01:47:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmvkp11425
	for <mpls@uu.net>; Sun, 30 Jun 2002 01:47:03 GMT
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvkp29846
	for <mpls@uu.net>; Sun, 30 Jun 2002 01:47:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvkp29842
	for <mpls@uu.net>; Sun, 30 Jun 2002 01:47:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA24854 for <mpls@uu.net>; Sat, 29 Jun 2002 21:47:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA25682 for mpls@uu.net; Sat, 29 Jun 2002 21:47:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvkp28155
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Jun 2002 01:46:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvkp00434
	for <mpls@UU.NET>; Sun, 30 Jun 2002 01:45:53 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvkp12553
	for <mpls@UU.NET>; Sun, 30 Jun 2002 01:45:52 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQmvkp12549
	for <mpls@UU.NET>; Sun, 30 Jun 2002 01:45:52 GMT
Received: (qmail 22361 invoked by uid 104); 30 Jun 2002 01:45:41 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4209. . Clean. Processed in 0.439341 secs); 30 Jun 2002 01:45:41 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 30 Jun 2002 01:45:40 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g5U1jec13493;
	Sat, 29 Jun 2002 18:45:40 -0700 (PDT)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <FXA4XAAR>; Sat, 29 Jun 2002 18:45:40 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03723@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Osborne '" <eosborne@cisco.com>
Cc: "'George Sheng '" <george_s97@hotmail.com>,
        "'scullptor@yahoo.com '"
	 <scullptor@yahoo.com>,
        "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: your mail
Date: Sat, 29 Jun 2002 18:45:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

 Silly or not, I am afraid it is the reality. LDP is inherently unable to do load ballancing, that is why this kludge is there.

-Shahram

-----Original Message-----
From: Eric Osborne
To: Shahram Davari
Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET
Sent: 6/27/02 7:11 PM
Subject: Re: your mail

On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote:
> > ECMP is inherent in the architecture. 
> 
> What? ECMP is a kludge to overcome LDP's inability to TE. 

That seems to be an Extremely Silly statement; if you want TE, use
RSVP.  RFC3209, in case you've missed it...:)



eric

> If you think about it doing hashing of multiple labels and perhaps
> IP header in the middle of an LSP actually defeats the purpose of
> MPLS, which was supposed to be have a simple label lookup in the
> core.

> -Shahram 
>  



From owner-mpls@UU.NET  Sun Jun 30 06:45:38 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27745
	for <mpls-archive@lists.ietf.org>; Sun, 30 Jun 2002 06:45:37 -0400 (EDT)
Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvlz15966
	for <mpls-archive@lists.ietf.org>; Sun, 30 Jun 2002 10:46:16 GMT
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQmvly12794;
	Sun, 30 Jun 2002 10:44:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmvly26394
	for mpls-outgoing; Sun, 30 Jun 2002 10:44:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQmvly26382
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Jun 2002 10:43:57 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvly03256
	for <mpls@uu.net>; Sun, 30 Jun 2002 10:43:03 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvly06089
	for <mpls@uu.net>; Sun, 30 Jun 2002 10:43:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmvly06083
	for <mpls@uu.net>; Sun, 30 Jun 2002 10:43:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA14998 for <mpls@uu.net>; Sun, 30 Jun 2002 06:43:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA18028 for mpls@uu.net; Sun, 30 Jun 2002 06:43:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmvly26343
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Jun 2002 10:42:48 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmvly19819
	for <mpls@UU.NET>; Sun, 30 Jun 2002 10:42:46 GMT
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: localhost [127.0.0.1])
	id QQmvly06047
	for <mpls@UU.NET>; Sun, 30 Jun 2002 10:42:46 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQmvly06042
	for <mpls@UU.NET>; Sun, 30 Jun 2002 10:42:45 GMT
Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA20563;
	Sun, 30 Jun 2002 06:42:24 -0400 (EDT)
Date: Sun, 30 Jun 2002 06:42:24 -0400 (EDT)
From: Ajay Simha <asimha@cisco.com>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: "'Eric Osborne '" <eosborne@cisco.com>,
        "'George Sheng '" <george_s97@hotmail.com>,
        "'scullptor@yahoo.com '" <scullptor@yahoo.com>,
        "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: your mail
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03723@nt-exch-yow.pmc-sierra.bc.ca>
Message-ID: <Pine.GSO.4.44.0206300639590.3152-100000@asimha-u10.cisco.com>
References: <4B6D09F3B826D411A67300D0B706EFDEB03723@nt-exch-yow.pmc-sierra.bc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sat, 29 Jun 2002, Shahram Davari wrote:

>SD: Silly or not, I am afraid it is the reality. LDP is inherently unable to
>SD:do load ballancing, that is why this kludge is there.

Shahram,

What are we comparing this against? IP? Please explain how in the IP world one
achieved IP vs non-IP load balancing and how it is different when you run LDP?

-ajay
>SD:
>SD:-Shahram
>SD:
>SD:-----Original Message-----
>SD:From: Eric Osborne
>SD:To: Shahram Davari
>SD:Cc: 'Eric Osborne'; George Sheng; scullptor@yahoo.com; mpls@UU.NET
>SD:Sent: 6/27/02 7:11 PM
>SD:Subject: Re: your mail
>SD:
>SD:On Thu, Jun 27, 2002 at 01:02:53PM -0700, Shahram Davari wrote:
>SD:> > ECMP is inherent in the architecture.
>SD:>
>SD:> What? ECMP is a kludge to overcome LDP's inability to TE.
>SD:
>SD:That seems to be an Extremely Silly statement; if you want TE, use
>SD:RSVP.  RFC3209, in case you've missed it...:)
>SD:
>SD:
>SD:
>SD:eric
>SD:
>SD:> If you think about it doing hashing of multiple labels and perhaps
>SD:> IP header in the middle of an LSP actually defeats the purpose of
>SD:> MPLS, which was supposed to be have a simple label lookup in the
>SD:> core.
>SD:
>SD:> -Shahram
>SD:>
>SD: