From owner-mpls@UU.NET  Wed Aug  1 01:47:30 2001
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 SMTP id BAA03870
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 01:47:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQladr12140;
	Wed, 1 Aug 2001 05:48:02 GMT
Received: by mail-control.mail.uu.net 
	id QQladr01346
	for mpls-outgoing; Wed, 1 Aug 2001 05:47:28 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQladr01338
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 05:47: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 QQladr01249
	for <mpls@UU.NET>; Wed, 1 Aug 2001 05:47:22 GMT
Received: from gatekeeper.cam.virata.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gatekeeper.virata.com [194.129.40.2])
	id QQladr12110
	for <mpls@UU.NET>; Wed, 1 Aug 2001 05:47:21 GMT
Received: from boletus.cam.virata.com (boletus.cam.virata.com [10.7.5.11])
	by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id GAA16240;
	Wed, 1 Aug 2001 06:47:19 +0100
Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.65.0.254])
	by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id GAA01383;
	Wed, 1 Aug 2001 06:47:16 +0100
Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21)
	id <PT7KHV8Z>; Wed, 1 Aug 2001 07:45:32 +0200
Message-ID: <C65A5D99A36ED411B1AB00B0D02272393F297A@fileserv.ta.virata.com>
From: "Lipovetsky, Sergey" <slipovetsky@virata.com>
To: "'David Charlap'" <david.charlap@marconi.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubts about MPLS-TE Mib
Date: Wed, 1 Aug 2001 07:45:30 +0200 
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

Hi David,

> > Here are comments on this thread.
> > RFC2205 states "RSVP defines a "session" to be a data flow with a
> > particular destination and transport-layer protocol." My
> > understanding is that it is not different for RSVP-TE and a session
> > object relates to the destination.
> 
> The SESSION object is not the same for RSVP and RSVP-TE.
> 
> In RSVP, the SESSION object consists of a 3-tuple consisting of
> destination address, destination L4-protocol, and destination port
> number.  In RSVP-TE, the SESSION object is a 3-tuple consisting of
> egress address, tunnel ID and extended tunnel ID.
> 
> In either case, the data in the SESSION object is what uniquely
> identifies the session, and nothing else does.
> 

I agree.

> > TunnelId is a part of the session object and probably also relates
> > to the destination. If this is true TunnelId should be locally
> > unique to the egress node and a pair [egress address, TunnelId]
> > should uniquely identify an RSVP session.
> 
> You're exchanging cause and effect here.  The data in the 
> SESSION object
> is what defines a session.  If two different LSPs are 
> signaled with Path
> messages containing identical SESSION objects, then they are 
> in the same
> session.  Period.  It doesn't matter what the user may or may not have
> wanted.
> 

I fully agree.

> Because tunnel ID can not be globally synchronized without using means
> beyond the scope of RSVP-TE, the extended tunnel ID was 
> created.  It can
> either be zero, in the case where resource sharing among different
> senders is desired, or it can be set to a globally unique value
> (preferrably the sender's IP address) in the case where such resource
> sharing is not desired.
> 

How can we say that tunnel ID is locally unique to the ingress node in this
case?
This is true only when the extended tunnel ID is not zero.
 
If the extended tunnel ID is zero, some global synchronization is required. 
Actually this synchronization is not so global, because only tunnel IDs for
the same egress node
require synchronization.
Can we say that tunnel ID is local unique to the egress node in this case?

This is different from CR-LDP, where lspid is really locally unique to the
ingress node
and does not require any synchronization.

> > However, there is a problem with TunnelId allocation on the ingress
> > node in this case.
> > 
> > The requirements to set Extended tunnel ID to a non-zero value to
> > guarantee session uniqueness, when TunnelId is allocated by the
> > ingress node prevents from merging LSPs having the same egress node
> > but different ingress nodes.
> > What is wrong here?
> 
> You are assuming that guaranteeing session uniqueness is 
> something that
> everybody always wants.  This is an invalid assumption.  There are
> situations where it is desirable and there are situations where it is
> not.
>
> There are situations where an operator may explicitly want 
> two different
> LSPs from different senders to share resources.  The only way 
> to signal
> this is by using a zero value for extended tunnel ID.
> 

I agree. I probably was not clear here.


From owner-mpls@UU.NET  Wed Aug  1 06:01:33 2001
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 SMTP id GAA25007
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 06:01:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaei00259;
	Wed, 1 Aug 2001 10:02:14 GMT
Received: by mail-control.mail.uu.net 
	id QQlaei07415
	for mpls-outgoing; Wed, 1 Aug 2001 10:01:44 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaei07216
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 10:01:24 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 QQlaeh14525
	for <mpls@uu.net>; Wed, 1 Aug 2001 09:59:57 GMT
Received: from smtp.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sz135.szptt.net.cn [202.96.135.132] (may be forged))
	id QQlaeh27138
	for <mpls@uu.net>; Wed, 1 Aug 2001 09:59:10 GMT
Received: from mplste01 ([10.110.9.73]) by smtp.huawei.com
          (Netscape Messaging Server 4.15) with SMTP id GHDVCJ02.H3E; Wed,
          1 Aug 2001 17:50:43 +0800 
Message-ID: <000501c11a70$3e1c83c0$49096e0a@huawei.com>
From: "Zhu Heqing" <zhuheqing@huawei.com>
To: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
Subject: Fast reroute feature!
Date: Wed, 1 Aug 2001 17:56:30 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id GAA25007

Hi:

I can't see the fast reroute feature has been implemented after IOS 12.1(3). 
But I can't make sure this. Who can tell me the reality?
And I feel confused about the document "MPLS Traffic Engineering Fast Reroute--Link Protection"
Which describes the fast reroute feature can only be supported at the POS links only.
What I feel is POS link has the capability of link restoration.
 
Any comments will be appreciated!

Zhu Heqing
University of Electronic Science.&Technology. of China.


From owner-mpls@UU.NET  Wed Aug  1 10:04:11 2001
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 SMTP id KAA03950
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 10:04:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaey22189;
	Wed, 1 Aug 2001 14:04:15 GMT
Received: by mail-control.mail.uu.net 
	id QQlaey16838
	for mpls-outgoing; Wed, 1 Aug 2001 14:03:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaey16706
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 14:03:40 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 QQlaey28883
	for <mpls@uu.net>; Wed, 1 Aug 2001 14:03:10 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlaey08806
	for <mpls@uu.net>; Wed, 1 Aug 2001 14:03:08 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 KAA17171 for <mpls@uu.net>; Wed, 1 Aug 2001 10:03:08 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18679 for mpls@uu.net; Wed, 1 Aug 2001 10:02:54 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaee14460
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 09:01:16 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 QQlaed04080
	for <mpls@UU.NET>; Wed, 1 Aug 2001 08:59:35 GMT
Received: from e-eihq01.eis.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.41.97.131])
	id QQlaed08098
	for <mpls@UU.NET>; Wed, 1 Aug 2001 08:59:25 GMT
Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM)
	id f719K3q0000020771; Wed, 1 Aug 2001 14:20:04 +0500 (GMT+0500)
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id OAA20561; Wed, 1 Aug 2001 14:25:17 -0500 (GMT)
>Received: from moon.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id MAA05109; Wed, 1 Aug 2001 12:47:33 -0500
Date: Wed, 1 Aug 2001 12:27:49 +0500 (GMT+0500)
From: Vaibhav Shandilya <vaibhav@cdotd.ernet.in>
To: Eric Gray <eric.gray@sandburst.com>
cc: David Charlap <david.charlap@marconi.com>, mpls@UU.NET,
        svaibhav@eudoramail.com
Subject: draft-shandilya-fault-tolerant-lsp-00.txt
In-Reply-To: <3ADE0242.43C41ADF@sandburst.com>
Message-ID: <Pine.OSF.4.10.10108011218210.5396-100000@moon.cdotd.ernet.in>
MIME-Version: 1.0
Received: from cdotd by vikram.doe.ernet.in; Wed,  1 Aug 2001 14:25 GMT
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


hello,

	This is in concern with the draft, which I submitted as an 
individual submission.
Its
http://www.ietf.org/internet-drafts/draft-shandilya-fault-tolerant-lsp-00.txt

The draft deals with finding(dynamically) fault-tolerant, backup LSPs
disjoint to primary LSPs. It also describes changes in the OSPF algorithm
to dynamically calculate fast rerouting paths along an E-LSP.

I didn't send the intimation regarding the draft to the chair WG, as I 
was under the impression that it would be done automatically.

I would love to discuss it at the forth-coming IETF conference at London.


regards,
Vaibhav







-----------------------------------------------------------------------
VAIBHAV SHANDILYA                            office:
Coordinating Engineer                            +91-11-4107296
 						 +91-11-4107297 
ATM Group                                    fax:    
C-DOT, New Delhi                                 +91-11-4104815

vaibhav@cdotd.ernet.in                       residence:
vaibhav@techie.com                               +91-11-7022431
http://members.tripod.com/~vaibhav_shandilya     
-----------------------------------------------------------------------
        At least counterfeiters try to follow a good example !








From owner-mpls@UU.NET  Wed Aug  1 10:18:05 2001
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 SMTP id KAA04647
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 10:18:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaez16273;
	Wed, 1 Aug 2001 14:17:08 GMT
Received: by mail-control.mail.uu.net 
	id QQlaez00524
	for mpls-outgoing; Wed, 1 Aug 2001 14:16:37 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaez00504
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 14:16:26 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 QQlaey01702
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:14:41 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 QQlaey11615
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:14:41 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 KAA29905
	for <mpls@UU.NET>; Wed, 1 Aug 2001 10:14:39 -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 KAA23829
	for <mpls@UU.NET>; Wed, 1 Aug 2001 10:14:41 -0400 (EDT)
Message-ID: <3B680ED3.2A1C7FF@marconi.com>
Date: Wed, 01 Aug 2001 10:14:43 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Doubts about MPLS-TE Mib
References: <F1CE15E08172D4119247009027AE9D500C7C9FC8@FMSMSX37>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Feng, Mark" wrote:
> 
> I agree fully. What I was trying to say is, if "sharing" is
> desired, the operator really needs to have some "global" knowledge
> of the tunnel IDs; otherwise, he/she might get a nasty surprise.

Absolutely.  No argument here.

> I agree with this as well:-). My point was, the egress router needs
> to base on some kind of criteria to decide the style. That is
> outside the scope of RSVP. Like you said, if the egress router
> completely ignore the information in the Path messages, the
> product might not be that appealing.

I can think of three situations where the egress router may ignore the
ingress router's choice of style:

1: The egress router's code only supports one style, so everything
   gets that style, regardless of request.

2: Another LSP in the same session is using a different style.

3: The operator configured the switch's local policy to override the
   requested style for the LSP.

If none of these three apply, a switch should observe the requested
style flag, since there is no good reason not to.

-- David


From owner-mpls@UU.NET  Wed Aug  1 10:22:03 2001
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 SMTP id KAA05035
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 10:22:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaey17761;
	Wed, 1 Aug 2001 14:11:25 GMT
Received: by mail-control.mail.uu.net 
	id QQlaey28856
	for mpls-outgoing; Wed, 1 Aug 2001 14:10:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaey28802
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 14:10:41 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 QQlaey21458
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:10:09 GMT
Received: from ottawa02.lanterncom.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.191.227.35])
	id QQlaey01570
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:10:09 GMT
Received: by OTTAWA02 with Internet Mail Service (5.5.2650.21)
	id <QBAFQY5F>; Wed, 1 Aug 2001 10:16:27 -0400
Message-ID: <4BAC766A2FCDD4119C5E00E018021DE92D8976@OTTAWA02>
From: Kshitij Kumar <kkumar@lanterncom.com>
To: "'Juha Heinanen'" <jh@lohi.eng.telia.fi>
Cc: "'mpls@uu.net'" <mpls@UU.NET>, te-wg@ops.ietf.org,
        Adisak Mekkittikul
	 <adisak@lanterncom.com>,
        Nader Vijeh <nader@lanterncom.com>
Subject: RE: QoS in Shared Media
Date: Wed, 1 Aug 2001 10:16:27 -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

Juha, et. al.,

In case people on the lists are curious, RPR is a work in progress, and
there is some interesting material available at the IEEE web site, presented
there a few weeks ago.

One such presentation I would highly recommend is available at:

http://www.ieee802.org/17/documents/presentations/jul2001/am_voqmdl_02.pdf

cheers!

Kshitij Kumar,
Lantern Communications, Canada.

-----Original Message-----
From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
Sent: Monday, July 30, 2001 11:53 AM
To: Jay Wang
Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
te-wg@ops.ietf.org
Subject: RE: QoS in Shared Media


jay,

i'm reading old emails and found your dpr/rpr/diffserv comment below to
which i have not had time to reply.  unfortunately i have to disagree
with you regarding dpt/rpr supporting diffserv.  the problem is their
node based fairness concept.

lets say that i have a 100 mbps rpr ring of four nodes a-b-c-d-a, there
may be 25 mbps of yellow and red af1 packets from both a to d and b to d
plus 70 mbps of green af1 packets from c to a.  in c, yellow and red
packets from a and b to d should not get 1/2 (50 mbps) of the bandwidth
causing 20 mbps of green af1 packets originating from c to be dropped.

-- juha
------------------------------------------------
Jay Wang writes:
 > 
 > Dunno what is the problem. To support diffserv, the underneath
 > transport (MAC layer and lower), does not have to have a
 > sophisticated traffic management matching diffserv PHBs. The fact
 > that cisco's DPT (or others RPR version for that matter), a MAC
 > layer technology, that supports only two transmit queueing priorities,
 > hence is not a disqualifier for supporting diffserv on the higher level,
 > where you suggested otherwise. In a share-media environment, from
 > diffserv's perspective, what we need from below is a link layer
 > that may ensure a quantifiable and stable guaranteed throughput for the
 > target nodes, regardless of the other sharing nodes. This is what is
 > missing in the original IEEE-802-style LAN. The DPT, on the other hand,
 > assures total_ring-BandWidth/node_num for each node. Given that, the
 > business of diffserv traffic management, e.g., BA classification,
 > policing, color-based RED dropping, PHB scheduling, and so on and so
forth,
 > can be conducted as they should have been at the connected nodes.
 > 
 > - jay
 > 
 > 
 > -----Original Message-----
 > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
 > Sent: Friday, May 04, 2001 10:52 PM
 > To: Jay Wang
 > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
 > te-wg@ops.ietf.org
 > Subject: RE: QoS in Shared Media
 > 
 > 
 > Jay Wang writes:
 > 
 >  > Well, RPR gives you bandwidth endurance at the link level, a shared
 >  > media in this case. On higher level, you may conduct your QoS as
 >  > appropriate, Diffserv, Intserv, or else. One does not preclude the
other,
 >  > IMO.
 > 
 > how about if someone would like to give different bandwidth assurance to
 > more than one independent traffic class?  also, within a diffserv
 > traffic class, droping of packets is based on the drop presedence of the
 > packet, not based on behind which nodes the packets arrived.
 > 
 > as i said before, node based fairness can only be applied to the highest
 > dp packets within each class.  dpt (and also rpr if it adopts dpt) thus
 > supports diffserv only in a very limited sense.  as far as i remember,
 > it is the only ieee mac standard, where the specification tells how many
 > queues the switch has.
 > 
 > -- juha
 > 
 > 
 > -----Original Message-----
 > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha
 > Heinanen
 > Sent: Friday, May 04, 2001 12:01 PM
 > To: HANSEN CHAN
 > Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org'
 > Subject: Re: QoS in Shared Media
 > 
 > HANSEN CHAN writes:
 > 
 >  > How about the work in IEEE 802.17 RPR? I believe it will be a
 > shared-media
 >  > technology. Does that mean they will have a hard time to achieve QoS
 >  > guarantees?
 > 
 > last time that i checked, the rpr proposal (based on cisco dpt) had two
 > classes of service (strict priority and best effort). that is clearly
 > not adequate for diffserv.  node based fairness applied to the best
 > effort class.  in diffserv, node based fairness makes sense only for the
 > highest dp packets in each traffic class.
 > 
 > -- juha
 > 


From owner-mpls@UU.NET  Wed Aug  1 10:23:25 2001
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 SMTP id KAA05080
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 10:23:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaez19490;
	Wed, 1 Aug 2001 14:21:52 GMT
Received: by mail-control.mail.uu.net 
	id QQlaez01029
	for mpls-outgoing; Wed, 1 Aug 2001 14:20:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaez00988
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 14:19:58 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 QQlaez18266
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:19:25 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 QQlaez26485
	for <mpls@UU.NET>; Wed, 1 Aug 2001 14:19: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 KAA00514
	for <mpls@UU.NET>; Wed, 1 Aug 2001 10:19: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 KAA25092
	for <mpls@UU.NET>; Wed, 1 Aug 2001 10:19:25 -0400 (EDT)
Message-ID: <3B680FEE.D0FEE8EF@marconi.com>
Date: Wed, 01 Aug 2001 10:19:26 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Doubts about MPLS-TE Mib
References: <C65A5D99A36ED411B1AB00B0D02272393F297A@fileserv.ta.virata.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Lipovetsky, Sergey" wrote:
> 
> How can we say that tunnel ID is locally unique to the ingress
> node in this case?

Because RSVP has no mechanism for synchronizing tunnel IDs across the
network.  Therefore the value is, by definition, only locally unique. 
This should be obvious.

> This is true only when the extended tunnel ID is not zero.

The uniqueness of tunnel ID is not affected by the value of other fields
in the SESSION object.

You seem to be confusing the tunnel ID with the entirity of the SESSION
object.

> If the extended tunnel ID is zero, some global synchronization is
> required.

It would be a good idea, but the protocol does not provide for any
mechanism.  And RSVP will work just fine with or without said
synchronization.  Your requirement is nothing more than wishful
thinking.

> Can we say that tunnel ID is local unique to the egress node in this
> case?

I don't see what your preoccupation with this is.  You seem die-hard
determined to change the RSVP spec such that it fits the MPLS-TE MIB.

> This is different from CR-LDP, where lspid is really locally unique
> to the ingress node and does not require any synchronization.

CR-LDP doesn't allow two LSPs to share resources either, so the entire
argument is moot there.

-- David


From owner-mpls@UU.NET  Wed Aug  1 11:03:45 2001
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 SMTP id LAA07766
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 11:03:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafc29334;
	Wed, 1 Aug 2001 15:03:48 GMT
Received: by mail-control.mail.uu.net 
	id QQlafc10303
	for mpls-outgoing; Wed, 1 Aug 2001 15:03:14 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlafc10269
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 15:03:13 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 QQlafc04447
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:03:00 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlafc13477
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:02:59 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA01252 for mpls@uu.net; Wed, 1 Aug 2001 11:02:59 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlafc09837
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 15:02:29 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 QQlafc00412
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:02:18 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlafc09612
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:02:17 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAHZ0P3L>; Wed, 1 Aug 2001 11:02:16 -0400
Message-ID: <87009604743AD411B1F600508BA0F9597B60B6@XOVER.dedham.mindspeed.com>
From: "Friedeborn, William" <bill.friedeborn@netplane.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: re: draft-martini-l2circuit-trans-mpls-06.txt
Date: Wed, 1 Aug 2001 11:02:15 -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

 Is the enum for CEM correct as 0x8008?

VC Type  Description

               0x0001   Frame Relay DLCI
               0x0002   ATM AAL5 VCC transport
               0x0003   ATM transparent cell transport
               0x0004   Ethernet VLAN
               0x0005   Ethernet
               0x0006   HDLC ( Cisco )
               0x0007   PPP
               0x8008   CEM [8]
               0x0009   ATM VCC cell transport
               0x000A   ATM VPC cell transport



From owner-mpls@UU.NET  Wed Aug  1 11:44:48 2001
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 SMTP id LAA17481
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 11:44:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafe03948;
	Wed, 1 Aug 2001 15:42:43 GMT
Received: by mail-control.mail.uu.net 
	id QQlafe29364
	for mpls-outgoing; Wed, 1 Aug 2001 15:42:10 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlafe29338
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 15:41:52 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 QQlafe26283
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:40:22 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlafe25082
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:40:21 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA21690
	for <mpls@uu.net>; Wed, 1 Aug 2001 11:40:21 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19492 for mpls@uu.net; Wed, 1 Aug 2001 11:40:06 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafc26025
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 15: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 QQlafc13190
	for <mpls@UU.NET>; Wed, 1 Aug 2001 15:13:03 GMT
Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221])
	id QQlafc24725
	for <mpls@UU.NET>; Wed, 1 Aug 2001 15:13:02 GMT
Received: from packetexchange.net (truman-firewall [212.161.41.120])
	by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP
	id 217A415F7E5; Wed,  1 Aug 2001 16:12:56 +0100 (BST)
Message-ID: <3B681CB6.175526F5@packetexchange.net>
Date: Wed, 01 Aug 2001 16:13:58 +0100
From: Giles Heron <giles@packetexchange.net>
Reply-To: giles@packetexchange.net
Organization: Gone2 Ltd.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Friedeborn, William" <bill.friedeborn@netplane.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: draft-martini-l2circuit-trans-mpls-06.txt
References: <87009604743AD411B1F600508BA0F9597B60B6@XOVER.dedham.mindspeed.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Friedeborn, William" wrote:
> 
>  Is the enum for CEM correct as 0x8008?
> 
> VC Type  Description
> 
>                0x0001   Frame Relay DLCI
>                0x0002   ATM AAL5 VCC transport
>                0x0003   ATM transparent cell transport
>                0x0004   Ethernet VLAN
>                0x0005   Ethernet
>                0x0006   HDLC ( Cisco )
>                0x0007   PPP
>                0x8008   CEM [8]
>                0x0009   ATM VCC cell transport
>                0x000A   ATM VPC cell transport

Yes.  I think the high  order bit is set to 1 to show that a control
word will always be used for CEM?

Giles

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



From owner-mpls@UU.NET  Wed Aug  1 12:05:15 2001
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 SMTP id MAA19030
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 12:05:15 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafg15402;
	Wed, 1 Aug 2001 16:03:17 GMT
Received: by mail-control.mail.uu.net 
	id QQlafg07092
	for mpls-outgoing; Wed, 1 Aug 2001 16:02:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlafg06996
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 16:02:43 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 QQlaff09434
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:58:44 GMT
Received: from blueyonder.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pcow028o.blueyonder.co.uk [195.188.53.124])
	id QQlaff14430
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:58:43 GMT
Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC;
	 Wed, 1 Aug 2001 16:40:11 +0100
Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Tue, 31 Jul 2001 20:23:24 +0100
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlacb04484;
	Tue, 31 Jul 2001 19:19:41 GMT
Received: by mail-control.mail.uu.net 
	id QQlacb29157
	for mpls-outgoing; Tue, 31 Jul 2001 19:18:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlacb29144
	for <mpls@mail-control.mail.uu.net>; Tue, 31 Jul 2001 19:17:49 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 QQlabz05932
	for <mpls@UU.NET>; Tue, 31 Jul 2001 18:59:41 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlabz02150
	for <mpls@UU.NET>; Tue, 31 Jul 2001 18:59:41 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id <PKB2HMBX>; Tue, 31 Jul 2001 15:59:36 -0300
Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D44328@MSTELEFONICA1>
From: Zappacosta Rolando Jorge <zappacor@TELEFONICA.COM.AR>
To: "'Mooney Sherman'" <Mooney.Sherman@gov.ab.ca>,
        "'Christian Kuhtz'"
	 <ck@arch.bellsouth.net>,
        Fabris Sergio <fabriss@TELEFONICA.COM.AR>
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Tue, 31 Jul 2001 15:59:32 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I totally agree. Even the test equipment manufacturers are working on that,
and in fact they have something available on the market.
But as implied before, it just an "agreement" between the customer and the
providers, or in a more general way, between two parties, and of course is
something not standardized.
Regards,
Rolando.

> -----Mensaje original-----
> De:	Mooney Sherman [SMTP:Mooney.Sherman@gov.ab.ca]
> Enviado el:	Viernes 27 de Julio de 2001 18:00
> Para:	'Christian Kuhtz'; Fabris Sergio
> CC:	mpls@UU.NET
> Asunto:	RE: SLA
> 
> I agree with some of your comments . It can be a marketing tool (gimmick?)
> but normally a client has certain expectations or need - such as a certain
> level of bandwidth requirement for the acceptable performance by an
> application - say video streaming. So the Telco guarantees a certain
> bandwidth that is acceptable or perhaps a maximum downtime in the form of
> SLA. SLA is simply an agreement that a vendor or supplier can and will
> deliver to a client. It can also be used in the context of an application
> i.e. an application can process/ redirect at least Xnumber of tags for
> instance in MPLS. Then this would be the SLA for it.
> 
> -----Original Message-----
> From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
> Sent: Friday, July 27, 2001 2:45 PM
> To: Fabris Sergio
> Cc: mpls@UU.NET
> Subject: Re: SLA
> 
> 
> 
> On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
> > Can it be used in an MPLS network?
> 
> Sergio,
> 
> You can define an SLA for literally anything, including the performance of
> your dry cleaner.  
> 
> And an MPLS network can be a 'DiffServ network'; I presume you intend to 
> describe a network in which differentiated services of some kind are 
> offered...
> 
> SLA per se has nothing to do with differentiated services, other than that
> 
> differentiated services with methods and tools as proposed by IETF
> DiffServ 
> can be used to provide a service as described by an SLA.  Note also that
> many 
> SLAs actually have little to do with a direct link to the technology
> underneath; it is possible that the service you purchase w/ SLA is
> identical
> 
> to the service you purchase w/out SLA, or the service w/ SLA may be very 
> different than the one w/out SLA.  An SLA can be a marketing gimmick,  a 
> financial tool, a technology constraint, or any combination of the above.
> 
> The term SLA is a very much abused term, often driven more by marketecture
> and
> marketeering than technology.  And then there's the set of issues around
> SLA's 
> with teeth..
> 
> But, I'm rambling..  What specifically are you looking for?
> 
> Cheers,
> Chris
> 
> -- 
> Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm
> Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA,
> U.S.
> "I speak for myself only.""


From owner-mpls@UU.NET  Wed Aug  1 12:09:00 2001
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 SMTP id MAA19238
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 12:09:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafg29165;
	Wed, 1 Aug 2001 16:07:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlafg13309
	for mpls-outgoing; Wed, 1 Aug 2001 16:06:32 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlafg13209
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 16:06: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 QQlafg22666
	for <mpls@uu.net>; Wed, 1 Aug 2001 16:01:52 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlafg17691
	for <mpls@uu.net>; Wed, 1 Aug 2001 16:01:52 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA06545 for mpls@uu.net; Wed, 1 Aug 2001 12:01:51 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlafg04217
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 16:01:13 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 QQlaff08484
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:58:25 GMT
Received: from blueyonder.co.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pcow028o.blueyonder.co.uk [195.188.53.124])
	id QQlaff05669
	for <mpls@uu.net>; Wed, 1 Aug 2001 15:58:25 GMT
Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC;
	 Wed, 1 Aug 2001 16:39:36 +0100
Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Tue, 31 Jul 2001 20:24:10 +0100
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlacb12145;
	Tue, 31 Jul 2001 19:24:06 GMT
Received: by mail-control.mail.uu.net 
	id QQlacb29778
	for mpls-outgoing; Tue, 31 Jul 2001 19:23:03 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlacb29496
	for <mpls@mail-control.mail.uu.net>; Tue, 31 Jul 2001 19:20:58 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 QQlaca25321
	for <mpls@uu.net>; Tue, 31 Jul 2001 19:04:07 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaca09682
	for <mpls@uu.net>; Tue, 31 Jul 2001 19:04:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA26718 for mpls@uu.net; Tue, 31 Jul 2001 15:04:07 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaca18810
	for <mpls@mail-control.mail.uu.net>; Tue, 31 Jul 2001 19:03:22 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 QQlabz21632
	for <mpls@UU.NET>; Tue, 31 Jul 2001 18:55:30 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlabz24619
	for <mpls@UU.NET>; Tue, 31 Jul 2001 18:55:29 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA27842; Tue, 31 Jul 2001 14:55:29 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-225.cisco.com [161.44.134.225])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AFB08677;
	Tue, 31 Jul 2001 14:55:28 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010731144213.022d2880@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 31 Jul 2001 15:01:25 -0400
To: manasa@gettos.com, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: TE-MIB
In-Reply-To: <20010731175844.6283F36F9@sitemail.everyone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>The mplsTunnelARHopTable of TE-MIB does give you
>the actual hops traversed by the tunnel in one
>direction.  But, if the LSP is a bi-directional one
>how would we get/record the actual hops traversed in
>the other direction?

         Boy, it is good to see all of this interest
in the MPLS-TE-MIB these days. Gives me the
impression that a lot of folks are implementing
it. 8)

         Bi-directional tunnels are not supported
in the MIB as they were not standardized in MPLS.
They are in GMPLS however, and will be covered
in the GMPLS-TE-MIB.

         --Tom




From owner-mpls@UU.NET  Wed Aug  1 13:44:37 2001
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 SMTP id NAA24351
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 13:44:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafm21249;
	Wed, 1 Aug 2001 17:44:52 GMT
Received: by mail-control.mail.uu.net 
	id QQlafm22878
	for mpls-outgoing; Wed, 1 Aug 2001 17:44:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafm22870
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 17:44:16 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 QQlafm11809
	for <mpls@UU.NET>; Wed, 1 Aug 2001 17:43:41 GMT
Received: from ganymede.or.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns01.or.intel.com [134.134.248.3])
	id QQlafm12973
	for <mpls@UU.NET>; Wed, 1 Aug 2001 17:43:41 GMT
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA03327
	for <mpls@UU.NET>; Wed, 1 Aug 2001 17:43:40 GMT
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 01 Aug 2001 17:43:37 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <PVHG02MT>; Wed, 1 Aug 2001 10:43:35 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7C9FCF@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubts about MPLS-TE Mib
Date: Wed, 1 Aug 2001 10:42:03 -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

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Wednesday, August 01, 2001 7:15 AM
> To: 'mpls@uu.net'
> > I agree with this as well:-). My point was, the egress router needs
> > to base on some kind of criteria to decide the style. That is
> > outside the scope of RSVP. Like you said, if the egress router
> > completely ignore the information in the Path messages, the
> > product might not be that appealing.
> 
> I can think of three situations where the egress router may ignore the
> ingress router's choice of style:
> 
> 1: The egress router's code only supports one style, so everything
>    gets that style, regardless of request.
> 
> 2: Another LSP in the same session is using a different style.
> 
> 3: The operator configured the switch's local policy to override the
>    requested style for the LSP.
> 
> If none of these three apply, a switch should observe the requested
> style flag, since there is no good reason not to.
>

I agree.

- Mark
 
> -- David
> 



From owner-mpls@UU.NET  Wed Aug  1 13:58:57 2001
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 SMTP id NAA25154
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 13:58:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafn15485;
	Wed, 1 Aug 2001 17:57:37 GMT
Received: by mail-control.mail.uu.net 
	id QQlafn24923
	for mpls-outgoing; Wed, 1 Aug 2001 17:57:06 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlafn24860
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 17:56:50 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 QQlafn19540
	for <mpls@uu.net>; Wed, 1 Aug 2001 17:55:35 GMT
From: bhaskara@turinnetworks.com
Received: from blueyonder.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pcow028o.blueyonder.co.uk [195.188.53.124])
	id QQlafn12198
	for <mpls@uu.net>; Wed, 1 Aug 2001 17:55:35 GMT
Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC;
	 Wed, 1 Aug 2001 17:55:03 +0100
Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Tue, 31 Jul 2001 21:41:31 +0100
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlacg11186;
	Tue, 31 Jul 2001 20:40:07 GMT
Received: by mail-control.mail.uu.net 
	id QQlacg26196
	for mpls-outgoing; Tue, 31 Jul 2001 20:38:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlacg26188
	for <mpls@mail-control.mail.uu.net>; Tue, 31 Jul 2001 20:38:46 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 QQlacg01240
	for <mpls@UU.NET>; Tue, 31 Jul 2001 20:36:30 GMT
Received: from milan.turinnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 63-197-247-126.turinntwks.com [63.197.247.126] (may be forged))
	id QQlacg06262
	for <mpls@UU.NET>; Tue, 31 Jul 2001 20:36:29 GMT
Received: by milan.turinnetworks.com with Internet Mail Service (5.5.2653.19)
	id <QATA5Y5L>; Tue, 31 Jul 2001 13:36:29 -0700
Message-ID: <36EF020032CFD411B7B400508B55E590A21B55@milan.turinnetworks.com>
To: afarrel@movaz.com, manasa@gettos.com
Cc: mpls@UU.NET, tnadeau@cisco.com
Subject: RE: TE-MIB
Date: Tue, 31 Jul 2001 13:36:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C11A00.792D7930"
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_01C11A00.792D7930
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Adrian,

It would be more informative if Label value is also added in the ArHopTable
of GMPLS-TE-MIB.
And in the bi-directional case, eventhough it may follow the same reverse
route,
but, one can not gaurantee the same label values...so, thought should be
given
in this respect before finalyzing the extensions.

regards
bhaskara

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Tuesday, July 31, 2001 12:57 PM
To: manasa@gettos.com
Cc: mpls@UU.NET; Thomas D. Nadeau
Subject: Re: TE-MIB


Incidentally,
In GMPLS, bi-directional tunnels use the same route (in opposite directions)
so
the ARHopTable will apply perfectly well.
As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it)
will
support the GMPLS extensions.  For bi-directional LSPs the interesting point
(in
this respect) will be additional features of the RRO such as label recording
for
both directions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: <manasa@gettos.com>; <mpls@UU.NET>
Sent: Tuesday, July 31, 2001 3:01 PM
Subject: Re: TE-MIB


>
> >The mplsTunnelARHopTable of TE-MIB does give you
> >the actual hops traversed by the tunnel in one
> >direction.  But, if the LSP is a bi-directional one
> >how would we get/record the actual hops traversed in
> >the other direction?
>
>          Boy, it is good to see all of this interest
> in the MPLS-TE-MIB these days. Gives me the
> impression that a lot of folks are implementing
> it. 8)
>
>          Bi-directional tunnels are not supported
> in the MIB as they were not standardized in MPLS.
> They are in GMPLS however, and will be covered
> in the GMPLS-TE-MIB.
>
>          --Tom
>
>
>


------_=_NextPart_001_01C11A00.792D7930
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.2653.12">
<TITLE>RE: TE-MIB</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Adrian,</FONT>
</P>

<P><FONT SIZE=2>It would be more informative if Label value is also added in the ArHopTable of GMPLS-TE-MIB.</FONT>
<BR><FONT SIZE=2>And in the bi-directional case, eventhough it may follow the same reverse route,</FONT>
<BR><FONT SIZE=2>but, one can not gaurantee the same label values...so, thought should be given</FONT>
<BR><FONT SIZE=2>in this respect before finalyzing the extensions.</FONT>
</P>

<P><FONT SIZE=2>regards</FONT>
<BR><FONT SIZE=2>bhaskara</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Adrian Farrel [<A HREF="mailto:afarrel@movaz.com">mailto:afarrel@movaz.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, July 31, 2001 12:57 PM</FONT>
<BR><FONT SIZE=2>To: manasa@gettos.com</FONT>
<BR><FONT SIZE=2>Cc: mpls@UU.NET; Thomas D. Nadeau</FONT>
<BR><FONT SIZE=2>Subject: Re: TE-MIB</FONT>
</P>
<BR>

<P><FONT SIZE=2>Incidentally,</FONT>
<BR><FONT SIZE=2>In GMPLS, bi-directional tunnels use the same route (in opposite directions) so</FONT>
<BR><FONT SIZE=2>the ARHopTable will apply perfectly well.</FONT>
<BR><FONT SIZE=2>As Tom says, the GMPLS TE MIB (come to the ccamp meeting and hear about it) will</FONT>
<BR><FONT SIZE=2>support the GMPLS extensions.&nbsp; For bi-directional LSPs the interesting point (in</FONT>
<BR><FONT SIZE=2>this respect) will be additional features of the RRO such as label recording for</FONT>
<BR><FONT SIZE=2>both directions.</FONT>
</P>

<P><FONT SIZE=2>Adrian</FONT>
<BR><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>Adrian Farrel</FONT>
<BR><FONT SIZE=2>Movaz Networks Inc.</FONT>
<BR><FONT SIZE=2>afarrel@movaz.com</FONT>
<BR><FONT SIZE=2>----- Original Message -----</FONT>
<BR><FONT SIZE=2>From: &quot;Thomas D. Nadeau&quot; &lt;tnadeau@cisco.com&gt;</FONT>
<BR><FONT SIZE=2>To: &lt;manasa@gettos.com&gt;; &lt;mpls@UU.NET&gt;</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, July 31, 2001 3:01 PM</FONT>
<BR><FONT SIZE=2>Subject: Re: TE-MIB</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;The mplsTunnelARHopTable of TE-MIB does give you</FONT>
<BR><FONT SIZE=2>&gt; &gt;the actual hops traversed by the tunnel in one</FONT>
<BR><FONT SIZE=2>&gt; &gt;direction.&nbsp; But, if the LSP is a bi-directional one</FONT>
<BR><FONT SIZE=2>&gt; &gt;how would we get/record the actual hops traversed in</FONT>
<BR><FONT SIZE=2>&gt; &gt;the other direction?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Boy, it is good to see all of this interest</FONT>
<BR><FONT SIZE=2>&gt; in the MPLS-TE-MIB these days. Gives me the</FONT>
<BR><FONT SIZE=2>&gt; impression that a lot of folks are implementing</FONT>
<BR><FONT SIZE=2>&gt; it. 8)</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bi-directional tunnels are not supported</FONT>
<BR><FONT SIZE=2>&gt; in the MIB as they were not standardized in MPLS.</FONT>
<BR><FONT SIZE=2>&gt; They are in GMPLS however, and will be covered</FONT>
<BR><FONT SIZE=2>&gt; in the GMPLS-TE-MIB.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11A00.792D7930--


From owner-mpls@UU.NET  Wed Aug  1 14:08:04 2001
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 SMTP id OAA25521
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 14:08:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafo20903;
	Wed, 1 Aug 2001 18:08:22 GMT
Received: by mail-control.mail.uu.net 
	id QQlafo08323
	for mpls-outgoing; Wed, 1 Aug 2001 18:07:52 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafo08131
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 18:07: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 QQlafo07156
	for <mpls@UU.NET>; Wed, 1 Aug 2001 18:06:47 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f47.law11.hotmail.com [64.4.17.47])
	id QQlafo00466
	for <mpls@UU.NET>; Wed, 1 Aug 2001 18:06:46 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 1 Aug 2001 11:06:45 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Wed, 01 Aug 2001 18:06:45 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: jnplonka@earthlink.net
Cc: Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net, fabriss@TELEFONICA.COM.AR,
        mpls@UU.NET
Subject: Re: SLA
Date: Wed, 01 Aug 2001 14:06:45 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F47IqtQvAauNjVuMhvq0000cecc@hotmail.com>
X-OriginalArrivalTime: 01 Aug 2001 18:06:45.0740 (UTC) FILETIME=[B9D712C0:01C11AB4]
Sender: owner-mpls@UU.NET
Precedence: bulk

Jon,

This is not an SLA forum and I am not selling SPs here.
I just said what I read. See the link below.
http://www.williamscommunications.com/newsroom/newsreleases/2001/062001.html

Thanks,
Irfan Lateef


>From: Jonathon Plonka <jnplonka@earthlink.net>
>Reply-To: jnplonka@earthlink.net
>To: "Irfan Lateef" <irfanlateef@hotmail.com>
>CC: Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net, 
>fabriss@TELEFONICA.COM.AR,        mpls@UU.NET
>Subject: Re: SLA
>Date: Sat, 28 Jul 2001 21:46:36 -0400
>
>Hmm delay less than 50 ms on a global network,  Must be that new fangled
>faster than light tacyon networking.
>
>On Fri, 27 Jul 2001 20:41:42 -0400, Irfan Lateef wrote:
>
> >Fabriss,
> >
> >Earlier comments are generally true. But recent SPs have tightened
> >the SLA spec which is specified in term of the following,
> >
> >Bandwidth=100 Mbits,
> >Delay= less than 50 msecs,
> >and uptime = 99.999 %
> >and some more parameters ....
> >
> >And vendors are getting serious in engineering their products
> >to meet and exceed these expectations.
> >
> >Now the this can be implemented using several techologies and
> >frameworks, where MPLS and Diffserv both can be used mutually
> >or exclusively to meet the SLA.
> >
> >I can go on and on but look at this article which gives a good
> >view on SLA.
> >
> >http://www.networkmagazine.com/article/NMG20010521S0002
> >
> >Irfan Lateef
> >
> >
> >
> >
> >
> >>From: Mooney Sherman <Mooney.Sherman@gov.ab.ca>
> >>To: 'Christian Kuhtz' <ck@arch.bellsouth.net>,        Fabris Sergio
> >><fabriss@TELEFONICA.COM.AR>
> >>CC: mpls@UU.NET
> >>Subject: RE: SLA
> >>Date: Fri, 27 Jul 2001 14:59:36 -0600
> >>
> >>I agree with some of your comments . It can be a marketing tool 
>(gimmick?)
> >>but normally a client has certain expectations or need - such as a 
>certain
> >>level of bandwidth requirement for the acceptable performance by an
> >>application - say video streaming. So the Telco guarantees a certain
> >>bandwidth that is acceptable or perhaps a maximum downtime in the form 
>of
> >>SLA. SLA is simply an agreement that a vendor or supplier can and will
> >>deliver to a client. It can also be used in the context of an 
>application
> >>i.e. an application can process/ redirect at least Xnumber of tags for
> >>instance in MPLS. Then this would be the SLA for it.
> >>
> >>-----Original Message-----
> >>From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
> >>Sent: Friday, July 27, 2001 2:45 PM
> >>To: Fabris Sergio
> >>Cc: mpls@UU.NET
> >>Subject: Re: SLA
> >>
> >>
> >>
> >>On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> >> > Is SLA (Service Level Agreement) a term for DiffServ networks only?
> >> > Can it be used in an MPLS network?
> >>
> >>Sergio,
> >>
> >>You can define an SLA for literally anything, including the performance 
>of
> >>your dry cleaner.
> >>
> >>And an MPLS network can be a 'DiffServ network'; I presume you intend to
> >>describe a network in which differentiated services of some kind are
> >>offered...
> >>
> >>SLA per se has nothing to do with differentiated services, other than 
>that
> >>differentiated services with methods and tools as proposed by IETF 
>DiffServ
> >>can be used to provide a service as described by an SLA.  Note also that
> >>many
> >>SLAs actually have little to do with a direct link to the technology
> >>underneath; it is possible that the service you purchase w/ SLA is
> >>identical
> >>
> >>to the service you purchase w/out SLA, or the service w/ SLA may be very
> >>different than the one w/out SLA.  An SLA can be a marketing gimmick,  a
> >>financial tool, a technology constraint, or any combination of the 
>above.
> >>
> >>The term SLA is a very much abused term, often driven more by 
>marketecture
> >>and
> >>marketeering than technology.  And then there's the set of issues around
> >>SLA's
> >>with teeth..
> >>
> >>But, I'm rambling..  What specifically are you looking for?
> >>
> >>Cheers,
> >>Chris
> >>
> >>--
> >>Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm
> >>Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, 
>U.S.
> >>"I speak for myself only.""
> >
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug  1 14:41:13 2001
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 SMTP id OAA27150
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 14:41:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafq12868;
	Wed, 1 Aug 2001 18:41:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlafq19859
	for mpls-outgoing; Wed, 1 Aug 2001 18:40:34 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafq19842
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 18:40:24 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 QQlafq26007
	for <mpls@uu.net>; Wed, 1 Aug 2001 18:39:58 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlafq29083
	for <mpls@uu.net>; Wed, 1 Aug 2001 18:39:58 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id <PKB22WWB>; Wed, 1 Aug 2001 15:39:52 -0300
Message-ID: <3D9C91EAD5D1D411851300508BCF243F02CC60C1@MSTELEFONICA3>
From: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
To: mpls@UU.NET
Subject: reserving
Date: Wed, 1 Aug 2001 15:39:49 -0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

A contsraint-based routing scheme automatically choose 
paths with minimum hop count, largest available bandwidth, etc.
But if I want to find a path and setup tunnel for 10Mbs for example. 
How does the path finder algorithm know that? 
Is it signaled by RSVP?

Thanks.

Sergio


From owner-mpls@UU.NET  Wed Aug  1 16:02:16 2001
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 SMTP id QAA01934
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 16:02:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafw13806;
	Wed, 1 Aug 2001 20:02:48 GMT
Received: by mail-control.mail.uu.net 
	id QQlafw24032
	for mpls-outgoing; Wed, 1 Aug 2001 20:02:16 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlafw23832
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 20:02: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 QQlafw27940
	for <mpls@UU.NET>; Wed, 1 Aug 2001 20:00:58 GMT
Received: from viola.watersprings.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: viola.watersprings.org [211.130.20.221])
	id QQlafw00150
	for <mpls@UU.NET>; Wed, 1 Aug 2001 20:00:56 GMT
Received: from localhost (localhost [127.0.0.1])
	by viola.watersprings.org (8.11.0/8.11.0) with ESMTP id f71K3ng00551;
	Thu, 2 Aug 2001 05:03:49 +0900 (JST)
From: Noritoshi Demizu <demizu@dd.iij4u.or.jp>
To: mpls@UU.NET
Subject: Re: MPLS Agenda
In-Reply-To: Your message of "Tue, 31 Jul 2001 17:35:09 -0400"
References: <200107312135.RAA20625@telescope.cisco.com>
X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3
X-URL: http://www.dd.iij4u.or.jp/~demizu/
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010802050348T.demizu@dd.iij4u.or.jp>
Date: Thu, 02 Aug 2001 05:03:48 +0900
X-Dispatcher: impost version 0.99i (Apr. 6, 1997)
Lines: 11
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear mpls experts,

I converted the MPLS WG agenda to HTML format.  It is located at

  http://www.watersprings.org/links/mlr/article/mpls-0108-agenda.html

It has titles and links to all I-Ds on the agenda.
Please let me know when you find errors.  Thank you.

Best Regards,
Noritoshi Demizu


From owner-mpls@UU.NET  Wed Aug  1 16:19:53 2001
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 SMTP id QAA02940
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 16:19:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafx19910;
	Wed, 1 Aug 2001 20:20:12 GMT
Received: by mail-control.mail.uu.net 
	id QQlafx10432
	for mpls-outgoing; Wed, 1 Aug 2001 20:19:41 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlafx10419
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 20:19:32 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 QQlafx09904
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:17:54 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlafx13871
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:17:53 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA29389
	for <mpls@uu.net>; Wed, 1 Aug 2001 16:17:52 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA20429 for mpls@uu.net; Wed, 1 Aug 2001 16:17:38 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlafw09509
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 20:11:41 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 QQlafw20648
	for <mpls@UU.net>; Wed, 1 Aug 2001 20:09:52 GMT
Received: from stephens.ittc.ku.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: stephens.ittc.ku.edu [129.237.125.220])
	id QQlafw09461
	for <mpls@UU.net>; Wed, 1 Aug 2001 20:09:52 GMT
Received: from astro.ittc.ku.edu (astro.ittc.ku.edu [129.237.126.119])
	by stephens.ittc.ku.edu (8.11.2/8.11.2/ITTC-NOSPAM-NOVIRUS-2.2) with ESMTP id f71K9pV25529;
	Wed, 1 Aug 2001 15:09:51 -0500
Received: from localhost by astro.ittc.ku.edu (8.9.3/KU-4.0-client)
	id PAA06657; Wed, 1 Aug 2001 15:09:50 -0500
Date: Wed, 1 Aug 2001 15:09:50 -0500 (CDT)
From: Rameshbabu Prabagaran <ramesh@ittc.ku.edu>
To: fabriss@TELEFONICA.COM.AR
cc: mpls@UU.NET
Subject: Re: reserving
Message-ID: <Pine.LNX.4.10.10108011509150.6655-100000@astro.ittc.ku.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Fabris,

> A contsraint-based routing scheme automatically
> choose paths with minimum hop count, largest
> available bandwidth, etc.
> But if I want to find a path and setup tunnel for
> 10Mbs for example.  How does the path finder
> algorithm know that? 

Finding a path for 10Mbps is done by the CSPF algorithm
that takes both the link state and available bandwidth
information into consideration when computing the
optimal path. The information, 10 Mbps for example in
your case, can be fed to the algorithm in the form
of configuration on a box. So, based on requirements
(your inputs) and available bandwidth information, the
CSPF algorithm can compute the shortest path.

> Is it signaled by RSVP?

You can use either of the signaling protocols RSVP-TE
or CR-LDP. 

I hope that answers your question :)

Thanks,
Ramesh.




From owner-mpls@UU.NET  Wed Aug  1 16:45:14 2001
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 SMTP id QAA04369
	for <mpls-archive@lists.ietf.org>; Wed, 1 Aug 2001 16:45:14 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafz16752;
	Wed, 1 Aug 2001 20:45:15 GMT
Received: by mail-control.mail.uu.net 
	id QQlafy12610
	for mpls-outgoing; Wed, 1 Aug 2001 20:44:41 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlafy12603
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 20:44:35 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 QQlafy03509
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:44:28 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlafy28593
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:44:28 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA05776 for mpls@uu.net; Wed, 1 Aug 2001 16:44:28 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafy12526
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 20:43:50 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 QQlafy11444
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:43:22 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlafy14679
	for <mpls@uu.net>; Wed, 1 Aug 2001 20:43:21 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA09777; Wed, 1 Aug 2001 16:42:44 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AFF01473;
	Wed, 1 Aug 2001 16:42:43 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010801164404.01eadc58@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Aug 2001 16:48:45 -0400
To: mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: comment about text in MPLS-LDP-MIB-07
Cc: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


	I am not sure if you guys have caught this,
but there is a typo in "3.7.1.  LDP Notifications".
It appears that the last sentence was chopped off.

    The 'mplsLdpEntityFailedInitSessionTrapEnable' object is used to
    enable or disable the sending of the If enabled, then this trap is
    sent when the 'mplsLdpEntityFailedInitSessionThreshold' is exceeded.
    This notification should indicate to the operator that there may be a
    misconfigured mplsLdpEntityEntry because the session associated with
    this Entity is not being established, and the Entity keeps trying to
    establish the session.  A side effect of this situation is that a row
    in the mplsLdpSessionTable may not be reaching the operational state
    as indicated by the

	--Tom




From owner-mpls@UU.NET  Thu Aug  2 00:32:03 2001
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 SMTP id AAA23186
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 00:32:02 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlahe26736;
	Thu, 2 Aug 2001 04:32:18 GMT
Received: by mail-control.mail.uu.net 
	id QQlahe08904
	for mpls-outgoing; Thu, 2 Aug 2001 04:31:47 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlahe08891
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 04:31: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 QQlahd22535
	for <mpls@UU.NET>; Thu, 2 Aug 2001 04:29:46 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlahd05705
	for <mpls@UU.NET>; Thu, 2 Aug 2001 04:29:44 GMT
Received: from multitech.co.in ([192.168.1.33])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f724PuP15898;
	Thu, 2 Aug 2001 09:55:56 +0530
Message-ID: <3B68D842.3C11D7CA@multitech.co.in>
Date: Thu, 02 Aug 2001 10:04:10 +0530
From: abhay <abhay@multitech.co.in>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
CC: mpls@UU.NET
Subject: Re: reserving
References: <3D9C91EAD5D1D411851300508BCF243F02CC60C1@MSTELEFONICA3>
Content-Type: multipart/alternative;
 boundary="------------278EB84F1AE7DB6401F8C9C7"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------278EB84F1AE7DB6401F8C9C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Fabris,

      If you can see the constraint-based routing schemes,one of the path finder

      algorithm's attribute is

      *)It knows the available bandwidth at each priority

      This information can be got by extensions to routing protocols such as OSPF

      and IS-IS

      Hence you can modify your path finder algorithm in this way:

      1)Let it also take the required bandwidth into account,then the

        algorithm may not return you the path if there is no sufficient bandwidth

        available and it can also tell u which paths can be pre-empted in order

        to satisfy your 10Mbps requriment.

       Once the path is found it can signaled by the signaling protocol.

       Hope this throws some light,

       Regards,

       Abhay







Fabris Sergio wrote:

> Hi,
>
> A contsraint-based routing scheme automatically choose
> paths with minimum hop count, largest available bandwidth, etc.
> But if I want to find a path and setup tunnel for 10Mbs for example.
> How does the path finder algorithm know that?
> Is it signaled by RSVP?
>
> Thanks.
>
> Sergio

--------------278EB84F1AE7DB6401F8C9C7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>Fabris,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you can see the constraint-based routing schemes,one of the path finder</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; algorithm's attribute is</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *)It knows the available bandwidth at each priority</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This information can be got by extensions to routing protocols such as OSPF</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and IS-IS</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hence you can modify your path finder algorithm in this way:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1)Let it also take the required bandwidth into account,then the</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; algorithm may not return you the path if there is no sufficient bandwidth</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; available and it can also tell u which paths can be pre-empted in order</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to satisfy your 10Mbps requriment.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Once the path is found it can signaled by the signaling protocol.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope this throws some light,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Abhay</pre>

<pre>&nbsp;</pre>

<pre>&nbsp;</pre>

<pre>&nbsp;</pre>

<p><br>Fabris Sergio wrote:
<blockquote TYPE=CITE>Hi,
<p>A contsraint-based routing scheme automatically choose
<br>paths with minimum hop count, largest available bandwidth, etc.
<br>But if I want to find a path and setup tunnel for 10Mbs for example.
<br>How does the path finder algorithm know that?
<br>Is it signaled by RSVP?
<p>Thanks.
<p>Sergio</blockquote>
</html>

--------------278EB84F1AE7DB6401F8C9C7--



From owner-mpls@UU.NET  Thu Aug  2 06:21:57 2001
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 SMTP id GAA20022
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 06:21:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaib09621;
	Thu, 2 Aug 2001 10:18:24 GMT
Received: by mail-control.mail.uu.net 
	id QQlaib08699
	for mpls-outgoing; Thu, 2 Aug 2001 10:17:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaib08691
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 10:17:35 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 QQlaib09088
	for <mpls@UU.NET>; Thu, 2 Aug 2001 10:15:37 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlaib05675
	for <mpls@UU.NET>; Thu, 2 Aug 2001 10:15:32 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QAD7NC4G>; Thu, 2 Aug 2001 15:43:05 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAC9@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET
Subject: Mapping of Traffic Parameters
Date: Thu, 2 Aug 2001 15:43:02 +0530 
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,

The Tspec object is used to indicate the requirements of a flow to the
Intserv layer which does the actual reservation in IntServ.

This consists of :
Token Bucket Rate [r]
Token Bucket Size [b]    
Peak Data Rate    [p] 
Minimum Policed Unit [m] 
Maximum Packet Size [M]
The first three parameters should be mapped to the following parameters in
the mplsTunnelResourceTable:
mplsTunnelResourceMeanRate :        Token Bucket Rate [r]
mplsTunnelResourceMeanBurstSize:  Token Bucket Size [b]    
mplsTunnelResourceMaxRate:           Peak Data Rate    [p] 
Is this assumption correct ?

And how are the values of m and M deduced at the ingress? ( There does not
seem to be any corresponding values in the Resource table and these
parameters might be important to police individual flows )

Thanks in advance,
Apratim 




From owner-mpls@UU.NET  Thu Aug  2 06:22:56 2001
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 SMTP id GAA20075
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 06:22:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaib13553;
	Thu, 2 Aug 2001 10:20:47 GMT
Received: by mail-control.mail.uu.net 
	id QQlaib08841
	for mpls-outgoing; Thu, 2 Aug 2001 10:20:16 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaib08782
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 10:20:01 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 QQlaib24636
	for <mpls@UU.NET>; Thu, 2 Aug 2001 10:18:07 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlaib09095
	for <mpls@UU.NET>; Thu, 2 Aug 2001 10:18:02 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QAD7NC4M>; Thu, 2 Aug 2001 15:45:37 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BACA@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET
Subject: Repetition of fields in CRLDPRes and Resource Table 
Date: Thu, 2 Aug 2001 15:45:36 +0530 
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,

The CRLDPResourceTable appears to have the same elements as the Resource
Table which is augments :
mplsTunnelCRLDPResMeanBurstSize  --->
mplsTunnelResourceMeanBurstSize
mplsTunnelCRLDPResExcessBurstSize--->
				mplsTunnelResourceExcessBurstSize	
mplsTunnelCRLDPResFrequency         --->
				mplsTunnelResourceFrequency
mplsTunnelCRLDPResWeight               --->  
				mplsTunnelResourceWeight
The only field which appears to be an 'augmented'  field is
mplsTunnelCRLDPResFlags.
Since the CRLDPResTable appears to be an augment to Resource Table ( since
there is no index in Tunnel Table to this table, access is through
mplsTunnelResourceIndex) , why is it required to keep the same parameters in
this table ? 
Why isn't this table collapsed into the mplsTunnelResourceTable by adding
one more field mplsTunnelResourceFlags with same semantics as
mplsTunnelCRLDPResFlags?

Thanks ,
Apratim



From owner-mpls@UU.NET  Thu Aug  2 12:26:25 2001
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 SMTP id MAA05119
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 12:26:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaiz00616;
	Thu, 2 Aug 2001 16:25:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlaiz10815
	for mpls-outgoing; Thu, 2 Aug 2001 16:24:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaiz10766
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 16:24:13 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 QQlaiz15201
	for <mpls@uu.net>; Thu, 2 Aug 2001 16:23:16 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 QQlaiz27445
	for <mpls@uu.net>; Thu, 2 Aug 2001 16:23:16 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 MAA25147
	for <mpls@uu.net>; Thu, 2 Aug 2001 12:23:13 -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 MAA01025
	for <mpls@uu.net>; Thu, 2 Aug 2001 12:23:17 -0400 (EDT)
Message-ID: <3B697E74.AFF248CA@marconi.com>
Date: Thu, 02 Aug 2001 12:23:16 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Doubts about MPLS-TE Mib
References: <C65A5D99A36ED411B1AB00B0D02272393F2985@fileserv.ta.virata.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Lipovetsky, Sergey" wrote:
> 
> I will try to restate the things. Please correct me if something is
> wrong.
> 
> Suppose we have two ingress routers (IP addresses: ingr1, ingr2) and
> two egress routers (IP addresses: egr1, egr2) and several TE tunnels
> defined by the following session objects:
> 
>    extended tunnel ID     tunnel ID   IPv4 tunnel end point address
> 1) ingr1                       1                       egr1
> 2) ingr1                       1                       egr2
> 
> 3) ingr2                       1                       egr1
> 4) ingr2                       1                       egr2
> 
> 5) 0                           1                       egr1
> 6) 0                           1                       egr2
> 
> All these TE tunnels can co-exist without any collisions.

Correct.

> In cases 1-4 tunnel ID is allocated for a given pair of
> ingress-egress nodes.
> In cases 5-6 tunnel ID is allocated for a given egress node.

This subdivision is splitting hairs unnecessarily.  In all cases, tunnel
ID is chosen by the ingress node, using whatever means it is configured
for (auto-generated, manually configured, off-line database, etc.)

In all cases, the session is identified by the 3-tuple of address,
tunnel ID and extended tunnel ID.  To try and define the properties of
one based on the values of the other may be an interesting intellectual
exercise, but it has no practical effect on the protocol.

-- David


From owner-mpls@UU.NET  Thu Aug  2 15:18:07 2001
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 SMTP id PAA14787
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 15:18:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaiv21542;
	Thu, 2 Aug 2001 15:22:01 GMT
Received: by mail-control.mail.uu.net 
	id QQlaiv14258
	for mpls-outgoing; Thu, 2 Aug 2001 15:21:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaiv14247
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 15:21: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 QQlaiv15303
	for <mpls@uu.net>; Thu, 2 Aug 2001 15:15:54 GMT
Received: from gatekeeper.cam.virata.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gatekeeper.virata.com [194.129.40.2])
	id QQlaiv01656
	for <mpls@uu.net>; Thu, 2 Aug 2001 15:15:53 GMT
Received: from boletus.cam.virata.com (boletus.cam.virata.com [10.7.5.11])
	by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id QAA04072;
	Thu, 2 Aug 2001 16:15:52 +0100
Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.65.0.254])
	by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA23065;
	Thu, 2 Aug 2001 16:15:50 +0100
Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21)
	id <PT7KHW7W>; Thu, 2 Aug 2001 17:14:05 +0200
Message-ID: <C65A5D99A36ED411B1AB00B0D02272393F2985@fileserv.ta.virata.com>
From: "Lipovetsky, Sergey" <slipovetsky@virata.com>
To: "'David Charlap'" <david.charlap@marconi.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubts about MPLS-TE Mib
Date: Thu, 2 Aug 2001 17:14:03 +0200 
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

Hi David,

Thank you for your response.
I will try to restate the things. Please correct me if something is wrong.

Suppose we have two ingress routers (IP addresses: ingr1, ingr2) and two
egress routers (IP addresses: egr1, egr2)
and several TE tunnels defined by the following session objects:

     extended tunnel ID        tunnel ID     IPv4 tunnel end point address
1)        ingr1                           1                       egr1
2)        ingr1                           1                       egr2

3)        ingr2                           1                       egr1   
4)        ingr2                           1                       egr2

5)           0                             1                       egr1
6)           0                             1                       egr2

All these TE tunnels can co-exist without any collisions.
In cases 1-4 tunnel ID is allocated for a given pair of ingress-egress
nodes.
In cases 5-6 tunnel ID is allocated for a given egress node.

Sergey
 
> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Wednesday, August 01, 2001 4:19 PM
> To: 'mpls@uu.net'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> "Lipovetsky, Sergey" wrote:
> > 
> > How can we say that tunnel ID is locally unique to the ingress
> > node in this case?
> 
> Because RSVP has no mechanism for synchronizing tunnel IDs across the
> network.  Therefore the value is, by definition, only locally unique. 
> This should be obvious.
> 
> > This is true only when the extended tunnel ID is not zero.
> 
> The uniqueness of tunnel ID is not affected by the value of 
> other fields
> in the SESSION object.
> 
> You seem to be confusing the tunnel ID with the entirity of 
> the SESSION
> object.
> 
> > If the extended tunnel ID is zero, some global synchronization is
> > required.
> 
> It would be a good idea, but the protocol does not provide for any
> mechanism.  And RSVP will work just fine with or without said
> synchronization.  Your requirement is nothing more than wishful
> thinking.
> 
> > Can we say that tunnel ID is local unique to the egress node in this
> > case?
> 
> I don't see what your preoccupation with this is.  You seem die-hard
> determined to change the RSVP spec such that it fits the MPLS-TE MIB.
> 
> > This is different from CR-LDP, where lspid is really locally unique
> > to the ingress node and does not require any synchronization.
> 
> CR-LDP doesn't allow two LSPs to share resources either, so the entire
> argument is moot there.
> 
> -- David
> 


From owner-mpls@UU.NET  Thu Aug  2 17:56:45 2001
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 SMTP id RAA24892
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 17:56:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlajv28906;
	Thu, 2 Aug 2001 21:56:53 GMT
Received: by mail-control.mail.uu.net 
	id QQlajv27209
	for mpls-outgoing; Thu, 2 Aug 2001 21:56:18 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlajv27193
	for <mpls@mail-control.mail.uu.net>; Thu, 2 Aug 2001 21:56: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 QQlajv27595
	for <mpls@UU.NET>; Thu, 2 Aug 2001 21:53:21 GMT
Received: from viola.watersprings.org by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: viola.watersprings.org [211.130.20.221])
	id QQlajv13439
	for <mpls@UU.NET>; Thu, 2 Aug 2001 21:53:19 GMT
Received: from localhost (localhost [127.0.0.1])
	by viola.watersprings.org (8.11.0/8.11.0) with ESMTP id f72Lu6L00458;
	Fri, 3 Aug 2001 06:56:14 +0900 (JST)
From: Noritoshi Demizu <demizu@dd.iij4u.or.jp>
To: mpls@UU.NET
Subject: Re: MPLS Agenda
In-Reply-To: Your message of "Thu, 02 Aug 2001 05:03:48 +0900"
References: <20010802050348T.demizu@dd.iij4u.or.jp>
X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3
X-URL: http://www.dd.iij4u.or.jp/~demizu/
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010803065336J.demizu@dd.iij4u.or.jp>
Date: Fri, 03 Aug 2001 06:53:36 +0900
X-Dispatcher: impost version 0.99i (Apr. 6, 1997)
Lines: 21
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

 > I converted the MPLS WG agenda to HTML format.  It is located at
 >
 >   http://www.watersprings.org/links/mlr/article/mpls-0108-agenda.html
 >
 > It has titles and links to all I-Ds on the agenda.
 > Please let me know when you find errors.  Thank you.

I am sorry that the link to the I-D of "MPLS Signaling Extensions for
Shared Fast Rerouting" was incorrect.  I fixed the problem.
The difference is the revision number.  (01 vs. 00)

  Correct:   draft-atlas-rsvp-local-protect-interop-01.txt

  Incorrect (old): draft-atlas-rsvp-local-protect-interop-00.txt

Please fetch again if you have retrieved.

Best Regards,
Noritoshi Demizu


From owner-mpls@UU.NET  Thu Aug  2 22:09:59 2001
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 SMTP id WAA09647
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 22:09:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlakm16710;
	Fri, 3 Aug 2001 02:10:23 GMT
Received: by mail-control.mail.uu.net 
	id QQlakm26539
	for mpls-outgoing; Fri, 3 Aug 2001 02:09:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlakm26480
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:09:32 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 QQlakm01213
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:16 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlakm15080
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:14 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA09311 for mpls@uu.net; Thu, 2 Aug 2001 22:09:14 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlakm26352
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:08:43 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 QQlakm15074
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:08 GMT
Received: from postoffice.sarnoff.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlakm16122
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:08 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYF400.3CO for <mpls@uu.net>; Thu, 2 Aug 2001 21:49:52 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CD700.V0V; Fri, 27 Jul 2001 15:19:55 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08815;
	Fri, 27 Jul 2001 13:32:08 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18447
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:15:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13115
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07628;
	Fri, 27 Jul 2001 07:22:30 -0400 (EDT)
Message-Id: <200107271122.HAA07628@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-generalized-cr-ldp-04.txt
Date: Fri, 27 Jul 2001 07:22:30 -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		: Generalized MPLS Signaling - CR-LDP Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-cr-ldp-04.txt
	Pages		: 20
	Date		: 26-Jul-01
	
This document describes extensions to CR-LDP signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents a CR-LDP specific description of the
extensions.  An RSVP-TE specific description can be found in [GMPLS-
RSVP].  A generic functional description is presented in [GMPLS-SIG].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-cr-ldp-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-generalized-cr-ldp-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:	<20010726171026.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-04.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug  2 22:11:36 2001
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 SMTP id WAA09998
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 22:11:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlakm20745;
	Fri, 3 Aug 2001 02:12:02 GMT
Received: by mail-control.mail.uu.net 
	id QQlakm26791
	for mpls-outgoing; Fri, 3 Aug 2001 02:11:31 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlakm26633
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:10:18 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 QQlakm17564
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:22 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlakm15263
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:22 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA09368 for mpls@uu.net; Thu, 2 Aug 2001 22:09:21 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlakm26351
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:08:43 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 QQlakm15059
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:08 GMT
Received: from postoffice.sarnoff.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlakm16112
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:08 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYF100.1CZ for <mpls@uu.net>; Thu, 2 Aug 2001 21:49:49 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CAN00.70E; Fri, 27 Jul 2001 15:18:23 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA09386;
	Fri, 27 Jul 2001 13:46:55 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18764
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13129
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07669;
	Fri, 27 Jul 2001 07:22:39 -0400 (EDT)
Message-Id: <200107271122.HAA07669@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-02.txt
Date: Fri, 27 Jul 2001 07:22:39 -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
	Author(s)	: P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki
	Filename	: draft-ietf-mpls-te-feed-02.txt
	Pages		: 10
	Date		: 26-Jul-01
	
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.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-te-feed-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-te-feed-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:	<20010726171047.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug  2 22:12:35 2001
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 SMTP id WAA10370
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 22:12:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlakm22418;
	Fri, 3 Aug 2001 02:13:03 GMT
Received: by mail-control.mail.uu.net 
	id QQlakm26822
	for mpls-outgoing; Fri, 3 Aug 2001 02:11:36 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlakm26634
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:10:19 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 QQlakm17565
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:22 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlakm15264
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:09:22 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA09369 for mpls@uu.net; Thu, 2 Aug 2001 22:09:21 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlakm26353
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:08:43 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 QQlakm15119
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:09 GMT
Received: from postoffice.sarnoff.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlakm16132
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:08 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYF500.ED9 for <mpls@uu.net>; Thu, 2 Aug 2001 21:49:53 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CD700.90L; Fri, 27 Jul 2001 15:19:55 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA09133;
	Fri, 27 Jul 2001 13:39:17 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18617
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13122
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:37 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07640;
	Fri, 27 Jul 2001 07:22:35 -0400 (EDT)
Message-Id: <200107271122.HAA07640@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-generalized-rsvp-te-04.txt
Date: Fri, 27 Jul 2001 07:22:34 -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		: Generalized MPLS Signaling - RSVP-TE Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-rsvp-te-04.txt
	Pages		: 33
	Date		: 26-Jul-01
	
This document describes extensions to RSVP-TE signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents an RSVP-TE specific description of
the extensions.  A CR-LDP specific description can be found in
[GMPLS-LDP].  A generic functional description is presented in
[GMPLS-SIG].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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:	<20010726171036.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug  2 22:14:26 2001
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 SMTP id WAA10624
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 22:14:25 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlakm23502;
	Fri, 3 Aug 2001 02:14:57 GMT
Received: by mail-control.mail.uu.net 
	id QQlakm27352
	for mpls-outgoing; Fri, 3 Aug 2001 02:14:03 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlakm26849
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:12:08 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 QQlakm13085
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:10:17 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlakm16524
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:10:16 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA09453 for mpls@uu.net; Thu, 2 Aug 2001 22:10:16 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlakm26517
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:09:43 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 QQlakm00184
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:09 GMT
Received: from postoffice.sarnoff.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlakm16143
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:09 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYFA00.6CZ for <mpls@uu.net>; Thu, 2 Aug 2001 21:49:58 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CJL00.40V; Fri, 27 Jul 2001 15:23:45 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA07990;
	Fri, 27 Jul 2001 13:08:05 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA18100
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 12:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13101
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07598;
	Fri, 27 Jul 2001 07:22:20 -0400 (EDT)
Message-Id: <200107271122.HAA07598@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-recovery-frmwrk-03.txt
Date: Fri, 27 Jul 2001 07:22:20 -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		: Framework for MPLS-based Recovery
	Author(s)	: V. Sharma et al.
	Filename	: draft-ietf-mpls-recovery-frmwrk-03.txt
	Pages		: 32
	Date		: 26-Jul-01
	
Multi-protocol label switching (MPLS) [1] integrates the label 
swapping forwarding paradigm with network layer routing. To deliver 
reliable service, MPLS requires a set of procedures to provide 
protection of the traffic carried on different paths. This requires 
that the label switched routers (LSRs) support fault detection, fault 
notification, and fault recovery mechanisms, and that MPLS signaling 
[2], [3], [4], [5], [6], [7] support the configuration of recovery. 
With these objectives in mind, this document specifies a framework 
for MPLS based recovery.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-recovery-frmwrk-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-recovery-frmwrk-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:	<20010726171007.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-03.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Thu Aug  2 22:17:13 2001
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 SMTP id WAA11082
	for <mpls-archive@lists.ietf.org>; Thu, 2 Aug 2001 22:17:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlakn27877;
	Fri, 3 Aug 2001 02:17:47 GMT
Received: by mail-control.mail.uu.net 
	id QQlakm27358
	for mpls-outgoing; Fri, 3 Aug 2001 02:14:09 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlakm26850
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:12:08 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 QQlakm12956
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:10:14 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlakm16431
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:10:14 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA09428 for mpls@uu.net; Thu, 2 Aug 2001 22:10:13 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlakm26518
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 02:09:43 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 QQlakm00179
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:09 GMT
Received: from postoffice.sarnoff.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlakm16140
	for <mpls@uu.net>; Fri, 3 Aug 2001 02:08:09 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYF600.6CY for <mpls@uu.net>; Thu, 2 Aug 2001 21:49:54 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CH800.R11; Fri, 27 Jul 2001 15:22:20 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08583;
	Fri, 27 Jul 2001 13:23:56 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18255
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13108
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:27 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07611;
	Fri, 27 Jul 2001 07:22:25 -0400 (EDT)
Message-Id: <200107271122.HAA07611@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-generalized-signaling-05.txt
Date: Fri, 27 Jul 2001 07:22:25 -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		: Generalized MPLS - Signaling Functional Description
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-signaling-05.txt
	Pages		: 31
	Date		: 26-Jul-01
	
This document describes extensions to MPLS signaling required to
support Generalized MPLS.  Generalized MPLS extends the MPLS control
plane to encompass time-division (e.g. SONET ADMs), wavelength
(optical lambdas) and spatial switching (e.g. incoming port or fiber
to outgoing port or fiber).  This document presents a functional
description of the extensions.  Protocol specific formats and
mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP].  Technology
specific details are expected to be specified in independent
technology specific documents, e.g., [GMPLS-SONET].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-signaling-05.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-generalized-signaling-05.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:	<20010726171016.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 04:56:22 2001
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 SMTP id EAA09485
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 04:56:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaln09563;
	Fri, 3 Aug 2001 08:56:28 GMT
Received: by mail-control.mail.uu.net 
	id QQlaln26836
	for mpls-outgoing; Fri, 3 Aug 2001 08:55:56 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaln26831
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:55:53 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 QQlaln24227
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:06 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaln18509
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01567 for mpls@uu.net; Fri, 3 Aug 2001 04:55:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaln26699
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:54: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 QQlaln22497
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:23 GMT
Received: from postoffice.sarnoff.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlaln05429
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:23 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF2700.NQB for <mpls@uu.net>; Fri, 3 Aug 2001 03:49:19 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CJL00.40V; Fri, 27 Jul 2001 15:23:45 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA07990;
	Fri, 27 Jul 2001 13:08:05 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA18100
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 12:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13101
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07598;
	Fri, 27 Jul 2001 07:22:20 -0400 (EDT)
Message-Id: <200107271122.HAA07598@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-recovery-frmwrk-03.txt
Date: Fri, 27 Jul 2001 07:22:20 -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		: Framework for MPLS-based Recovery
	Author(s)	: V. Sharma et al.
	Filename	: draft-ietf-mpls-recovery-frmwrk-03.txt
	Pages		: 32
	Date		: 26-Jul-01
	
Multi-protocol label switching (MPLS) [1] integrates the label 
swapping forwarding paradigm with network layer routing. To deliver 
reliable service, MPLS requires a set of procedures to provide 
protection of the traffic carried on different paths. This requires 
that the label switched routers (LSRs) support fault detection, fault 
notification, and fault recovery mechanisms, and that MPLS signaling 
[2], [3], [4], [5], [6], [7] support the configuration of recovery. 
With these objectives in mind, this document specifies a framework 
for MPLS based recovery.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-recovery-frmwrk-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-recovery-frmwrk-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:	<20010726171007.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-recovery-frmwrk-03.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 04:57:55 2001
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 SMTP id EAA09689
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 04:57:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaln24076;
	Fri, 3 Aug 2001 08:57:59 GMT
Received: by mail-control.mail.uu.net 
	id QQlaln26982
	for mpls-outgoing; Fri, 3 Aug 2001 08:57:26 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaln26909
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:56:13 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 QQlaln15125
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaln18487
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01550 for mpls@uu.net; Fri, 3 Aug 2001 04:55:03 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaln26697
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:54: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 QQlaln22499
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:23 GMT
Received: from postoffice.sarnoff.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlaln05435
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:23 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF7C00.VQJ for <mpls@uu.net>; Fri, 3 Aug 2001 03:52:24 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CAN00.70E; Fri, 27 Jul 2001 15:18:23 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA09386;
	Fri, 27 Jul 2001 13:46:55 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18764
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13129
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07669;
	Fri, 27 Jul 2001 07:22:39 -0400 (EDT)
Message-Id: <200107271122.HAA07669@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-02.txt
Date: Fri, 27 Jul 2001 07:22:39 -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
	Author(s)	: P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki
	Filename	: draft-ietf-mpls-te-feed-02.txt
	Pages		: 10
	Date		: 26-Jul-01
	
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.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-te-feed-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-te-feed-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:	<20010726171047.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 04:58:48 2001
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 SMTP id EAA09778
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 04:58:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaln26213;
	Fri, 3 Aug 2001 08:59:06 GMT
Received: by mail-control.mail.uu.net 
	id QQlaln26985
	for mpls-outgoing; Fri, 3 Aug 2001 08:57:31 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaln26910
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:56:14 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 QQlaln15141
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaln18503
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01558 for mpls@uu.net; Fri, 3 Aug 2001 04:55:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaln26698
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:54: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 QQlaln22568
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:26 GMT
Received: from postoffice.sarnoff.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlaln05520
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:26 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF2400.AQJ for <mpls@uu.net>; Fri, 3 Aug 2001 03:49:16 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CD700.V0V; Fri, 27 Jul 2001 15:19:55 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08815;
	Fri, 27 Jul 2001 13:32:08 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18447
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:15:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13115
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07628;
	Fri, 27 Jul 2001 07:22:30 -0400 (EDT)
Message-Id: <200107271122.HAA07628@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-generalized-cr-ldp-04.txt
Date: Fri, 27 Jul 2001 07:22:30 -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		: Generalized MPLS Signaling - CR-LDP Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-cr-ldp-04.txt
	Pages		: 20
	Date		: 26-Jul-01
	
This document describes extensions to CR-LDP signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents a CR-LDP specific description of the
extensions.  An RSVP-TE specific description can be found in [GMPLS-
RSVP].  A generic functional description is presented in [GMPLS-SIG].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-cr-ldp-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-generalized-cr-ldp-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:	<20010726171026.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-04.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 04:59:49 2001
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 SMTP id EAA09844
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 04:59:49 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlalo24125;
	Fri, 3 Aug 2001 09:00:15 GMT
Received: by mail-control.mail.uu.net 
	id QQlaln26999
	for mpls-outgoing; Fri, 3 Aug 2001 08:57:36 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaln26911
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:56:14 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 QQlaln15181
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:06 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaln18504
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01557 for mpls@uu.net; Fri, 3 Aug 2001 04:55:04 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaln26691
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:54:18 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 QQlaln27353
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:22 GMT
Received: from postoffice.sarnoff.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlaln05415
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:22 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF2500.VQG for <mpls@uu.net>; Fri, 3 Aug 2001 03:49:17 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CD700.90L; Fri, 27 Jul 2001 15:19:55 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA09133;
	Fri, 27 Jul 2001 13:39:17 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18617
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13122
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:37 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07640;
	Fri, 27 Jul 2001 07:22:35 -0400 (EDT)
Message-Id: <200107271122.HAA07640@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-generalized-rsvp-te-04.txt
Date: Fri, 27 Jul 2001 07:22:34 -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		: Generalized MPLS Signaling - RSVP-TE Extensions
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-rsvp-te-04.txt
	Pages		: 33
	Date		: 26-Jul-01
	
This document describes extensions to RSVP-TE signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents an RSVP-TE specific description of
the extensions.  A CR-LDP specific description can be found in
[GMPLS-LDP].  A generic functional description is presented in
[GMPLS-SIG].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-rsvp-te-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-generalized-rsvp-te-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:	<20010726171036.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 04:59:59 2001
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 SMTP id EAA09857
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 04:59:58 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlalo28732;
	Fri, 3 Aug 2001 09:00:21 GMT
Received: by mail-control.mail.uu.net 
	id QQlaln27002
	for mpls-outgoing; Fri, 3 Aug 2001 08:57:41 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaln26912
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:56:14 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 QQlaln15138
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaln18502
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:55:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA01559 for mpls@uu.net; Fri, 3 Aug 2001 04:55:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaln26700
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 08:54: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 QQlaln22490
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:23 GMT
Received: from postoffice.sarnoff.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: postoffice.sarnoff.com [130.33.10.147])
	id QQlaln05425
	for <mpls@uu.net>; Fri, 3 Aug 2001 08:53:22 GMT
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF2600.DQF for <mpls@uu.net>; Fri, 3 Aug 2001 03:49:18 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5CH800.R11; Fri, 27 Jul 2001 15:22:20 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id NAA08583;
	Fri, 27 Jul 2001 13:23:56 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA18255
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 13:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13108
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:27 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07611;
	Fri, 27 Jul 2001 07:22:25 -0400 (EDT)
Message-Id: <200107271122.HAA07611@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-generalized-signaling-05.txt
Date: Fri, 27 Jul 2001 07:22:25 -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		: Generalized MPLS - Signaling Functional Description
	Author(s)	: P. Ashwood-Smith et al.
	Filename	: draft-ietf-mpls-generalized-signaling-05.txt
	Pages		: 31
	Date		: 26-Jul-01
	
This document describes extensions to MPLS signaling required to
support Generalized MPLS.  Generalized MPLS extends the MPLS control
plane to encompass time-division (e.g. SONET ADMs), wavelength
(optical lambdas) and spatial switching (e.g. incoming port or fiber
to outgoing port or fiber).  This document presents a functional
description of the extensions.  Protocol specific formats and
mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP].  Technology
specific details are expected to be specified in independent
technology specific documents, e.g., [GMPLS-SONET].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-generalized-signaling-05.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-generalized-signaling-05.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:	<20010726171016.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-05.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug  3 09:49:04 2001
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 SMTP id JAA16041
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 09:49:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlamh22234;
	Fri, 3 Aug 2001 13:48:42 GMT
Received: by mail-control.mail.uu.net 
	id QQlamh06391
	for mpls-outgoing; Fri, 3 Aug 2001 13:48:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlamh06351
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 13:47:47 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 QQlamh11579
	for <mpls@UU.NET>; Fri, 3 Aug 2001 13:45:50 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlamh03740
	for <mpls@UU.NET>; Fri, 3 Aug 2001 13:45:50 GMT
Message-ID: <3B6AAB08.CD455DE1@sandburst.com>
Date: Fri, 03 Aug 2001 09:45:44 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>,
        Arun Viswanathan <arun@force10networks.com>,
        Cheenu Srinivasan <csrinivasan@tachion.com>
Cc: Apratim Mukherjee <ApratimM@netbrahma.com>, mpls@UU.NET
Subject: Re: Repetition of fields in CRLDPRes and Resource Table
References: <13D467F625FAD511AE2A00D0B7B917D706BACA@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tom, et al. -

    Apratim's questions refer to your draft (draft-ietf-mpls-te-mib-06.txt).  I
cannot find - in this draft - how these values would be determined.  Pardon me
if these questions have been aksed, and answered, previously.  Also, I had
earlier asked Tom a couple of questions about this draft and did not receive a
reply.

Re: to Apratim's questions -
==========================

    The text states that the CRLDP resource table is an extension of the MPLS
resource table.  Specific entries in the CRLDP resource table state that values
are in addition to resource values in the MPLS resource table.  What is intended

here?  Does this mean that there are resources consumed by CRLDP that are not
associated with MPLS, or does it mean that CRLDP signalled resources are kept
in the CRLDP resource table and all other MPLS related resources are kept in the

MPLS resource table?

    If there are resources associated with CRLDP signalled tunnels that are not
MPLS related, what are these resources?

    If the intent is to manage CRLDP associated resources separately from other
resources, why this distinction?  Isn't there also an equal need to distinguish
signaled resources from provisioned resources?  What if resources are consumed
by some - as yet undefined - signaling?

My earlier questions -
====================

    Is it possible I could prevail on you to add a space between "fastReroute"
and
"This" toward the end of page 20 and between "recordRoute" and "This" about
one third the way down on page 21?

    Also, what is the intended mechanism for finding out RSVP-related MIB
information that applies to a TE Tunnel?  I assumed it would be using the
session
number as an index, but cannot see how this works.

--
Eric Gray

Apratim Mukherjee wrote:

> Hi,
>
> The CRLDPResourceTable appears to have the same elements as the Resource
> Table which is augments :
> mplsTunnelCRLDPResMeanBurstSize  --->
> mplsTunnelResourceMeanBurstSize
> mplsTunnelCRLDPResExcessBurstSize--->
>                                 mplsTunnelResourceExcessBurstSize
> mplsTunnelCRLDPResFrequency         --->
>                                 mplsTunnelResourceFrequency
> mplsTunnelCRLDPResWeight               --->
>                                 mplsTunnelResourceWeight
> The only field which appears to be an 'augmented'  field is
> mplsTunnelCRLDPResFlags.
> Since the CRLDPResTable appears to be an augment to Resource Table ( since
> there is no index in Tunnel Table to this table, access is through
> mplsTunnelResourceIndex) , why is it required to keep the same parameters in
> this table ?
> Why isn't this table collapsed into the mplsTunnelResourceTable by adding
> one more field mplsTunnelResourceFlags with same semantics as
> mplsTunnelCRLDPResFlags?
>
> Thanks ,
> Apratim



From owner-mpls@UU.NET  Fri Aug  3 14:32:09 2001
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 SMTP id OAA23722
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 14:32:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlana08986;
	Fri, 3 Aug 2001 18:32:25 GMT
Received: by mail-control.mail.uu.net 
	id QQlana14099
	for mpls-outgoing; Fri, 3 Aug 2001 18:31:55 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlana14078
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 18:31: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 QQlana12364
	for <mpls@uu.net>; Fri, 3 Aug 2001 18:30:29 GMT
From: Tim.Jackson@TeraBeam.com
Received: from TERA-EMAIL.terabeam.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: NE-CBwsp000122wss.terabeam.com [216.137.15.2] (may be forged))
	id QQlana10781
	for <mpls@uu.net>; Fri, 3 Aug 2001 18:30:29 GMT
Received: by tera-email.terabeam.com with Internet Mail Service (5.5.2653.19)
	id <P9JQ24GZ>; Fri, 3 Aug 2001 11:28:57 -0700
Message-ID: <F03A5CDD25F1D411BE6C00508BAFACB201DC6BEC@tera-email.terabeam.com>
To: mpls@UU.NET
Subject: RSVP-TE: ERO question
Date: Fri, 3 Aug 2001 11:28:50 -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

I haven't seen reference to the following in any archives, so I hope someone
can shed some light on this for me.

Section 3.1.5 of RFC2205 (RSVP V1) stipulates the following: "A PathTear
message must be routed exactly like the corresponding Path message."

Given that the RSVP-TE draft defines the EXPLICT_ROUTE object (ERO) that can
effectively circumvent the active route from any given node to the session
DestAddress and, moreover, that the ERO is applicable to the Path message
exclusively (see section 3 of the RSVP-TE draft), it follows that, if an ERO
is employed, a PathTear message may follow a different path than the
corresponding Path message.
Is this not a conflict?

Tim Jackson
Terabeam


From owner-mpls@UU.NET  Fri Aug  3 14:51:11 2001
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 SMTP id OAA24199
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 14:51:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlanb01673;
	Fri, 3 Aug 2001 18:51:27 GMT
Received: by mail-control.mail.uu.net 
	id QQlanb16831
	for mpls-outgoing; Fri, 3 Aug 2001 18:50:55 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlanb16808
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 18:50:43 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 QQlanb10173
	for <mpls@UU.NET>; Fri, 3 Aug 2001 18:50:09 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 QQlanb28700
	for <mpls@UU.NET>; Fri, 3 Aug 2001 18:50:09 GMT
Message-ID: <3B6AF257.516FF292@sandburst.com>
Date: Fri, 03 Aug 2001 14:49:59 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Tim.Jackson@TeraBeam.com
Cc: mpls@UU.NET
Subject: Re: RSVP-TE: ERO question
References: <F03A5CDD25F1D411BE6C00508BAFACB201DC6BEC@tera-email.terabeam.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tim,

    A PATH message needs to continue to carry the ERO object in
refreshing PATH messages because it has the ability to specify a
different Explicit Route over time.  This is not needed for a PATH
TEAR message, therefore it is possible to correctly propagate the
PATH TEAR using RSVP state alone.

--
Eric Gray

You wrote:

> I haven't seen reference to the following in any archives, so I hope someone
> can shed some light on this for me.
>
> Section 3.1.5 of RFC2205 (RSVP V1) stipulates the following: "A PathTear
> message must be routed exactly like the corresponding Path message."
>
> Given that the RSVP-TE draft defines the EXPLICT_ROUTE object (ERO) that can
> effectively circumvent the active route from any given node to the session
> DestAddress and, moreover, that the ERO is applicable to the Path message
> exclusively (see section 3 of the RSVP-TE draft), it follows that, if an ERO
> is employed, a PathTear message may follow a different path than the
> corresponding Path message.
> Is this not a conflict?
>
> Tim Jackson
> Terabeam



From owner-mpls@UU.NET  Fri Aug  3 15:41:07 2001
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 PAA25295
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 15:41:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlane10515;
	Fri, 3 Aug 2001 19:41:29 GMT
Received: by mail-control.mail.uu.net 
	id QQlane11350
	for mpls-outgoing; Fri, 3 Aug 2001 19:40:57 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlane11341
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 19:40: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 QQlane21308
	for <mpls@UU.NET>; Fri, 3 Aug 2001 19:39:18 GMT
Received: from [207.53.175.56] by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [207.53.175.56])
	id QQlane24649
	for <mpls@UU.NET>; Fri, 3 Aug 2001 19:39:18 GMT
Received: from hostr607.alcatel.com by [207.53.175.56]
          via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 3 Aug 2001 19:39:18 UT
Received: by steam.corp.packetengines.com with Internet Mail Service (5.5.2650.21)
	id <PS2DQZ6Z>; Fri, 3 Aug 2001 12:34:36 -0700
Message-ID: <A821AF2B0A8CD211B34900E0B104148C032B7CF2@steam.corp.packetengines.com>
From: Marc Lewis <mlewis@ind.alcatel.com>
To: mpls@UU.NET
Subject: RE: RSVP-TE: ERO question
Date: Fri, 3 Aug 2001 12:34:32 -0700 
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



-----Original Message-----
From: Tim.Jackson@terabeam.com [mailto:Tim.Jackson@terabeam.com]
Sent: Friday, August 03, 2001 11:29 AM
To: mpls@UU.NET
Subject: RSVP-TE: ERO question


> I haven't seen reference to the following in any archives, so I hope
someone
> can shed some light on this for me.

> Section 3.1.5 of RFC2205 (RSVP V1) stipulates the following: "A PathTear
> message must be routed exactly like the corresponding Path message."

> Given that the RSVP-TE draft defines the EXPLICT_ROUTE object (ERO) that
can
> effectively circumvent the active route from any given node to the session
> DestAddress and, moreover, that the ERO is applicable to the Path message
> exclusively (see section 3 of the RSVP-TE draft), it follows that, if an
ERO
> is employed, a PathTear message may follow a different path than the
> corresponding Path message.
> Is this not a conflict?

Nope, it simply means you have to route the PATH TEAR explicitly, just like
you did the original PATH message.  A piece of cake, as you should have
previously recorded the outgoing interface in the path state block (or
session control block).



From owner-mpls@UU.NET  Fri Aug  3 20:24:51 2001
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 UAA01587
	for <mpls-archive@lists.ietf.org>; Fri, 3 Aug 2001 20:24:51 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlafp22568;
	Wed, 1 Aug 2001 18:20:38 GMT
Received: by mail-control.mail.uu.net 
	id QQlafp17224
	for mpls-outgoing; Wed, 1 Aug 2001 18:19:53 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlafp17203
	for <mpls@mail-control.mail.uu.net>; Wed, 1 Aug 2001 18:19:37 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 QQlafp07096
	for <mpls@uu.net>; Wed, 1 Aug 2001 18:19:21 GMT
Received: from blueyonder.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pcow028o.blueyonder.co.uk [195.188.53.124])
	id QQlafp07616
	for <mpls@uu.net>; Wed, 1 Aug 2001 18:19:20 GMT
Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC;
	 Wed, 1 Aug 2001 18:10:24 +0100
Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by blueyonder.co.uk  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Tue, 31 Jul 2001 22:04:01 +0100
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaci28291;
	Tue, 31 Jul 2001 21:03:41 GMT
Received: by mail-control.mail.uu.net 
	id QQlaci03962
	for mpls-outgoing; Tue, 31 Jul 2001 21:02:34 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaci03520
	for <mpls@mail-control.mail.uu.net>; Tue, 31 Jul 2001 21:02: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 QQlaci03602
	for <mpls@UU.NET>; Tue, 31 Jul 2001 21:02:02 GMT
Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQlaci08848
	for <mpls@UU.NET>; Tue, 31 Jul 2001 21:02:02 GMT
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6VL21O21778
	for <mpls@UU.NET>; Tue, 31 Jul 2001 17:02:01 -0400 (EDT)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21)
	id <P6VHV39Z>; Tue, 31 Jul 2001 17:02:01 -0400
Message-ID: <4490F7068AC0D111A7120008C72878EC0ADFF373@nj7460exch003u.ho.lucent.com>
From: "Kyriakopoulos, Aris (Aris)" <aris@lucent.com>
To: "'Fabris Sergio'" <fabriss@TELEFONICA.COM.AR>, mpls@UU.NET
Subject: RE: classification
Date: Tue, 31 Jul 2001 17:01:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Sergio,

The statement below says that the best (longest) match is determined by the
IP routing table to be with prefix X.  Absent any other information, that is
the FEC and resulting label the incoming IP packet maps to.  So your LSP
follows the same path determined by an IP routing protocol.  This isn't a
traffic engineering issue.  

There is no requirement that an FEC should consist of both a source and
destination IP address, although it is certainly allowed.  In this case, you
would use an explicitly-routed or constraint-routed LSP.  If you do this,
you are free to use a path that does not follow the standard
destination-based route.  *That* is an example of TE!

Regards,
Aris

-----Original Message-----
From: Fabris Sergio [mailto:fabriss@TELEFONICA.COM.AR]
Sent: Tuesday, July 31, 2001 2:39 PM
To: mpls@UU.NET
Subject: classification

Traffic Engineering:

..........A standard IP packet arrives at Interface 1 of LSR 1. After
performing a longest-match
lookup in its IP routing table, LSR 1 discovers that the best match is with
Prefix X and that
all traffic matching Prefix X should to be forwarded on Interface 2 with a
Label = 10.............

How LSR1 discover that the best match is whit that Prefix X??
Does It made same classification based on source address??

Thanks.

Sergio


From owner-mpls@UU.NET  Sat Aug  4 09:29:48 2001
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 JAA26105
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 09:29:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlapy21089;
	Sat, 4 Aug 2001 13:30:04 GMT
Received: by mail-control.mail.uu.net 
	id QQlapx27852
	for mpls-outgoing; Sat, 4 Aug 2001 13:29:32 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlapx27845
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 13:29:27 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 QQlapx25478
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:13 GMT
From: neil.2.harrison@bt.com
Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41])
	id QQlapx18312
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:12 GMT
Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP;
          Sat, 4 Aug 2001 14:27:48 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) 
          id <QGFY7QA1>; Sat, 4 Aug 2001 14:27:42 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891594@mbddmknt01.hc.bt.com>
To: mattsquire@acm.org
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
Date: Sat, 4 Aug 2001 14:27:38 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Matt...I agree with you but for a different and more fundamantal reason.
The basic issue here is the client/server relationship between IP and MPLS.
MPLS creates layer networks that are independent of IP (data-plane) (I know
some find this concept a bit hard to grasp or accept, but its true....the
data-plane per technology in GMPLS is exactly the same).  Router Alert is an
IP data-plane layer function.....it should, therefore, be as irrelevant to
MPLS LSP trails as it is to SDH or OTN trails say.  Hence, architecturally
if an IP packet (or indeed any other client packet) goes over an LSP it
should be treated simply as a client payload of the LSP.  Indeed, one of the
problems with the Ping draft is that it has both cross-layer dependancies
(ie mixing IP layer ICMP OAM functions with MPLS server layer data-plane
OAM) and cross-plane dependancies (ie tying data-plane behaviour to a
specific control-plane protocol behaviour).  Both are usually not very
sensible architectural practices since they can come back to create
evolution and backwards compatibility problems later, ie create difficulties
in adding/removing/changing protocols independently.  Of course vendors can
implement such schemes as an expediency if they choose to, but IMO such
practices should not be countenanced for standardisation.

We need to strive for MPLS data-plane OAM to be stand-alone irrespective of
client (or server) layer networks and be decoupled from reliance on specific
control-plane protocols. 

regards, Neil

> -----Original Message-----
> From: Matt Squire [mailto:mattsquire@acm.org]
> Sent: 18 July 2001 00:58
> To: David Charlap
> Cc: mpls-list
> Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
> 
> 
> David Charlap wrote:
> > 
> > Punj, Arun wrote:
> > > Matt Squire wrote:
> > >>
> > >> What prevents a packet with a router alert flag set from being
> > >> sent over an LSP?  I don't recall anything in the specs that
> > >> specifies router alter packets can't be LSP'd.
> > >
> > > Interesting.. Should it not be in the spec? If not, than are you
> > > not changing the meaning of router alert. If yes, Eric's solution
> > > seems perfectly OK, although it would require some sort of
> > > additional support on the intermediate nodes.
> > 
> > Logically, it would not make sense to forward a 
> router-alerted packet
> > into an LSP.
> > 
> > The purpose of router alert is so that intermediate nodes 
> will closely
> > examine the packet, and possibly intercept it for processing.  The
> > purpose of an LSP is to quickly forward a packet with a minimum of
> > processing by the transit routers.  These are two 
> diametrically opposed
> > goals.
> > 
> > Nevertheless, I don't think there is anything forbidding a 
> router from
> > sending a router-alert packet into an LSP.
> > 
> 
> LSPs can be used to provide L2 VPN connectivity.  LSPs can be used to
> provide virtual p2p connections between two virtual routers.  
> LSRs might
> not even be L3 forwarders.  When used in such ways, it is conceivable
> and probably desired that router alert messages be sent down 
> LSP as the
> LSP is not spanning multiple L3 routers from the perspective of the
> ingress - the LSP is just a single hop.  
> 
> Strictly outlawing router alert messages from LSPs would not be a
> desirable end goal.
> 
> - Matt
> 


From owner-mpls@UU.NET  Sat Aug  4 09:30:36 2001
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 JAA26124
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 09:30:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlapy22995;
	Sat, 4 Aug 2001 13:31:10 GMT
Received: by mail-control.mail.uu.net 
	id QQlapx27862
	for mpls-outgoing; Sat, 4 Aug 2001 13:29:38 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlapx27846
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 13:29: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 QQlapx25711
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:28 GMT
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQlapx04593
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:27 GMT
Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP;
          Sat, 4 Aug 2001 14:27:53 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) 
          id <3X2VTFT7>; Sat, 4 Aug 2001 14:27:46 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891593@mbddmknt01.hc.bt.com>
To: irfanlateef@hotmail.com, Mooney.Sherman@gov.ab.ca, ck@arch.bellsouth.net,
        fabriss@TELEFONICA.COM.AR
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Sat, 4 Aug 2001 14:27:37 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Agreed.....but for an operator to be able to create sensible/measureable
SLAs it requires that these factors are addressed:
-	defect defintions (entry/exit criteria) are specified
-	......which leads to required definitions of unavailability (and its
SLA) 
-	and where the QoS metrics (and their SLA) should only be associated
with the available state.
Note that these factors have a sequential dependency.

If you have tracked the recent OAM debate (ie on the Ping draft), it is
clear these issues have not yet been properly addressed.

regards, Neil 

> -----Original Message-----
> From: Irfan Lateef [mailto:irfanlateef@hotmail.com]
> Sent: 28 July 2001 01:42
> To: Mooney.Sherman@gov.ab.ca; ck@arch.bellsouth.net;
> fabriss@TELEFONICA.COM.AR
> Cc: mpls@UU.NET
> Subject: RE: SLA
> 
> 
> Fabriss,
> 
> Earlier comments are generally true. But recent SPs have tightened
> the SLA spec which is specified in term of the following,
> 
> Bandwidth=100 Mbits,
> Delay= less than 50 msecs,
> and uptime = 99.999 %
> and some more parameters ....
> 
> And vendors are getting serious in engineering their products
> to meet and exceed these expectations.
> 
> Now the this can be implemented using several techologies and
> frameworks, where MPLS and Diffserv both can be used mutually
> or exclusively to meet the SLA.
> 
> I can go on and on but look at this article which gives a good
> view on SLA.
> 
> http://www.networkmagazine.com/article/NMG20010521S0002
> 
> Irfan Lateef
> 
> 
> 
> 
> 
> >From: Mooney Sherman <Mooney.Sherman@gov.ab.ca>
> >To: 'Christian Kuhtz' <ck@arch.bellsouth.net>,        Fabris Sergio  
> ><fabriss@TELEFONICA.COM.AR>
> >CC: mpls@UU.NET
> >Subject: RE: SLA
> >Date: Fri, 27 Jul 2001 14:59:36 -0600
> >
> >I agree with some of your comments . It can be a marketing 
> tool (gimmick?)
> >but normally a client has certain expectations or need - 
> such as a certain
> >level of bandwidth requirement for the acceptable performance by an
> >application - say video streaming. So the Telco guarantees a certain
> >bandwidth that is acceptable or perhaps a maximum downtime 
> in the form of
> >SLA. SLA is simply an agreement that a vendor or supplier 
> can and will
> >deliver to a client. It can also be used in the context of 
> an application
> >i.e. an application can process/ redirect at least Xnumber 
> of tags for
> >instance in MPLS. Then this would be the SLA for it.
> >
> >-----Original Message-----
> >From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
> >Sent: Friday, July 27, 2001 2:45 PM
> >To: Fabris Sergio
> >Cc: mpls@UU.NET
> >Subject: Re: SLA
> >
> >
> >
> >On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > > Is SLA (Service Level Agreement) a term for DiffServ 
> networks only?
> > > Can it be used in an MPLS network?
> >
> >Sergio,
> >
> >You can define an SLA for literally anything, including the 
> performance of
> >your dry cleaner.
> >
> >And an MPLS network can be a 'DiffServ network'; I presume 
> you intend to
> >describe a network in which differentiated services of some kind are
> >offered...
> >
> >SLA per se has nothing to do with differentiated services, 
> other than that
> >differentiated services with methods and tools as proposed 
> by IETF DiffServ
> >can be used to provide a service as described by an SLA.  
> Note also that
> >many
> >SLAs actually have little to do with a direct link to the technology
> >underneath; it is possible that the service you purchase w/ SLA is 
> >identical
> >
> >to the service you purchase w/out SLA, or the service w/ SLA 
> may be very
> >different than the one w/out SLA.  An SLA can be a marketing 
> gimmick,  a
> >financial tool, a technology constraint, or any combination 
> of the above.
> >
> >The term SLA is a very much abused term, often driven more 
> by marketecture
> >and
> >marketeering than technology.  And then there's the set of 
> issues around
> >SLA's
> >with teeth..
> >
> >But, I'm rambling..  What specifically are you looking for?
> >
> >Cheers,
> >Chris
> >
> >--
> >Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm
> >Sr. Architect, Engineering & Architecture, BellSouth.net, 
> Atlanta, GA, U.S.
> >"I speak for myself only.""
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 


From owner-mpls@UU.NET  Sat Aug  4 09:31:37 2001
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 JAA26147
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 09:31:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlapy24789;
	Sat, 4 Aug 2001 13:32:11 GMT
Received: by mail-control.mail.uu.net 
	id QQlapx27872
	for mpls-outgoing; Sat, 4 Aug 2001 13:29:43 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlapx27847
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 13:29:28 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 QQlapx25840
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:35 GMT
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQlapx22999
	for <mpls@UU.NET>; Sat, 4 Aug 2001 13:28:35 GMT
Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP;
          Sat, 4 Aug 2001 14:27:50 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) 
          id <QGFY7QAF>; Sat, 4 Aug 2001 14:27:49 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891596@mbddmknt01.hc.bt.com>
To: pingpan@juniper.net, Brijesh@coronanetworks.com
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Sat, 4 Aug 2001 14:27:44 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping wrote:
> Sent: 26 July 2001 01:22
> To: Brijesh Kumar
> Cc: mpls-list
> Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> 
> 
> > Brijesh Kumar wrote:
> > 
> > From this draft:
> > 
> >    When the ingress LSR suspects that the LSP may have 
> failed and the
> >    RSVP control plane shows the LSP as operational, the ingress LSR
> > MUST
> >    send LSP-ping messages to the egress over the LSP, periodically.
> > The
> >    value of the time interval should be configurable.
> > 
> > Could you please tell me what do you mean by "LSR 
> suspects"? In other
> > words,
> > what is the triggering input for LSR to start "suspecting" 
> the LSP may
> > have failed?
> > 
> > It will be better if you replace "suspect" with "detect" in 
> your draft
> > as suspect is an imprecise human emotion and no operator would like
> > routers that have negative emotions ;-).
> > 
> 
> It's network operators suspect something may have gone wrong with some
> LSP's....
NH=> How do they 'suspect' this?....is some crystal-ball going to be
supplied with the implementation?  It is not acceptable to have to rely on
customers to 1st complain.  So what is the detection mechanism for the
defects, you need to explain this more precisely...see also later comments.
> 
> > In addition, I do have issues with introducing a mechanism dependent
> > on a particular signalling protocol for a generic problem - testing
> > liveness of the label switched data path. 
> 
> OK. Do you have problem with the mechanism itself?
NH=> I have some problems with it.
Coming back from 2 weeks leave and trying to wade through the large volume
of discussion this draft has generated tells me there is a fundamental lack
of clarity of the problem being solved here.  We really should get the
problem statement agreed and also agree a set of OAM arch principles to
prevent bad practice. In summary here is what I propose...and I would
appreciate some positive feedback on each of these statements if there is
disagreement:

1	Problem statement:

Operators need to determine the operational status of LSPs.  They need
simple management tools to do this and operational costs must be driven down
(ie we can't afford an army of CCIEs to run networks).  As a minimum, this
requires all defects to be identified and specified in terms of entry/exit
criteria and the appropriate consequent actions to be taken in order to (i)
protect customer traffic and (ii) allow simple diagnostics for operational
staff.  This is also required so that the operators/customers can define
consistent and measurable availability SLAs and, as a dependent corollary,
QoS SLAs (since QoS only has any meaning when the LSP is in the available
state).  Customer/operator SLAs are increasing in importance and this needs
to be recognised.

2	Arch principles:
Note - although stated against the MPLS case, these can (and should) be
generalised to apply to any network...including the GMPLS cases (where
perhaps they may be more obvious to some).

2.1	the data-plane and control-plane must have independent OAM.  Note
that the control-plane must use some data-plane (not necessarily the same as
that used for customer traffic) and hence needs both its own data-plane OAM
and OAM (aka as error handling) which is specific to each of the
control-plane protocols in use....so that would be specific OAM for RSVP-TE,
CR-LDP, LDP, OSPF, etc.

2.2	cross-layer network data-plane OAM dependancies must be avoided.  In
other words, one should not rely on OAM in technology X to detect/diagnose
defects in technology Y (whether X is a client or server layer wrt Y).  This
requirement is also necessary for evolution and backwards compatibility, ie
to allow layer networks/protocols to be added/removed/modified independently
and without affecting other layer networks/protocols.

2.3	cross-plane OAM dependancies must be avoided.  For example, the
data-plane OAM should function independent of the signalling/routing
protocols being used (including the case of no control-plane).  This has
similar evolution and backwards compatibilty issues as in 2.2.

2.4	customers must not be expected to act as the default defect
detection devices.  Nor must customer traffic activity be used as part of
the defect detection function (since users can be quiescent).  Note that
defect detection and defect diagnosis are 2 distinct functions.  This also
implies that defect detection needs to be a continuous function (at least on
important LSPs).
BTW - IMO QoS measurements are 2nd order importance compared to defect
handling.  QoS should be tackled as a network design and TE issue, with
suitable verification via population or ad hoc sampling as needed, and not
overkill measurements which can be both costly and swamp operations people.

2.5	OAM mechanisms should be designed to correctly function under
failure conditions, ie OAM mechanisms must not rely on 'well-behaved'
network behaviour after a defect has occurred since, by defintion, the fact
that the network has failed implies its behaviour cannot be expected to be
predictable.

2.6	A failure in a server layer network should not create alarm storms
in client layer networks.  Noting that client layer networks may be owned by
different organisations and have a large geographical dispersion.

2.7	data-plane LSP OAM should not require a return LSP to
function....and even with bi-directional LSPs each direction should be
monitored independently.

2.8	failures of the control-plane (either the data-plane aspect or any
one of the control-plane protocols that run on this) should not result in
failures of the customer traffic data-plane where such trails are permanent
or semi-permanent (this is more obvious in the GMPLS case).

The Ping draft either does not address or fails to meet many of these
requirements.  More specifically:
-	it does not identify/specify any defects;
-	it cannot detect any defects unless it is running continuously;
-	it could not detect or diagnose all potential defects even if
running continously, eg mismerging defects;
-	it relies on both cross-layer (ie ICMP is a IP layer OAM mechanism)
and cross-plane (ie it is only defined for the RSVP-TE case) functional
dependancies.  Although this expediency may have some near-term benefit(?)
it is not good arch practice.  
-	since defects are not detected/defined it is unclear (i) what
consequent actions are to be taken to protect customer traffic (none it
seems), (ii) how this will help operators target diagnostic activities or
(iii) how it will prevent client layer alarm storms.
-	its all very well having variable behaviour (wrt timers) but this
will create complexities elsewhere, ie inconsistent entry/exit criteria for
defects and  availability states, no clear/consistent datums for when QoS
metrics collection (if being measured) are valid, ie when to start/stop QoS
metric aggregation.  So this means complexities in SLA derivations.

So, whilst I would certainly not want to stop any vendor implementing this
draft, as an operator with responsibilities for the integrity of my
customers traffic and a need to define SLAs for such, I find it
professionally very difficult to condone it becoming a 'standard'.

> 
> > Secondly, can we have some
> > input/justification with regards to the assumption that there is a
> > need to detect such a failure since only cause for such a failure
> > given in the draft is "memory Corruption". What causes so called
> > memory corruption? Are we trying to repair badly written code here?
> > 
> 
> The problem did happen in the real network. I'm not going to point
> fingers on the cause of the problem. But we (vendors and 
> providers) did
> realize from that incidence that we need to have a simple mechanism to
> check LSP's data plane in today's operational networks.
NH=> Some time ago I was hearing comments such as 'these defects won't
happen' and 'don't fix software bugs with additional software' (an erroneous
argument anyway).  So having now establised that defects do exist, I fully
agree we need some way of detecting/diagnosing such defects.  But this seems
not what is being advocated here, since the mechanism does not help
operators to detect the defects in the first place.  To address the
detection aspect some mechanism has to run continuously, and a technique
that is unidirectional would seem to be simpler/better than one that
requires a return path.  At some point one needs to raise an alarm and take
other consequent actions (eg maybe even squelching customer traffic if
intergity/security could be being compromised, and stop any QoS metric
aggregation (if being used)) and raise a vertical indication to the NMS...so
what better place to do this than at the point where the defect is being
initially detected, ie the LSP sink?

Given all this, could those advocating the Ping draft please explain what is
actually wrong with the more comprehensive solution we orginally proposed
(in draft-harrison-mpls-oam-00.txt).....and in particular, the use of the CV
flow.....which is really nothing more than a keepalive running from soure to
sink with a unique source identifier and deterministic behaviour....surely
it can't be much simpler than this can it? 
> 
> The whole purpose on various proposals (fast reroute, graceful restart
> and LSP-ping) is to make the whole network working nicely, 
> even when we
> have routers from other vendors that have badly written code.
> 
> - Ping
> 


From owner-mpls@UU.NET  Sat Aug  4 16:43:44 2001
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 QAA00685
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 16:43:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlara19052;
	Sat, 4 Aug 2001 20:44:06 GMT
Received: by mail-control.mail.uu.net 
	id QQlara18374
	for mpls-outgoing; Sat, 4 Aug 2001 20:43:36 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlara18366
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 20:43: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 QQlara13090
	for <mpls@UU.NET>; Sat, 4 Aug 2001 20:42:22 GMT
Received: from maildev.edc.gov.ab.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [142.229.18.133])
	id QQlara05908
	for <mpls@UU.NET>; Sat, 4 Aug 2001 20:42:22 GMT
Received: by maildev.edc.gov.ab.ca with Internet Mail Service (5.5.2653.19)
	id <Q1SZ5KX9>; Sat, 4 Aug 2001 14:43:43 -0600
Message-ID: <F9C6AC22A8FED211AD2F0090276D80DC051F4162@maildev.edc.gov.ab.ca>
From: Mooney Sherman <Mooney.Sherman@gov.ab.ca>
To: "'neil.2.harrison@bt.com '" <neil.2.harrison@bt.com>,
        "'irfanlateef@hotmail.com '" <irfanlateef@hotmail.com>,
        Mooney Sherman
	 <Mooney.Sherman@gov.ab.ca>,
        "'ck@arch.bellsouth.net '"
	 <ck@arch.bellsouth.net>,
        "'fabriss@TELEFONICA.COM.AR '"
	 <fabriss@TELEFONICA.COM.AR>
Cc: "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: SLA
Date: Sat, 4 Aug 2001 14:43:42 -0600 
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 agree with your comments but would like to add that SLAs are evolving and
its demand is increasing by the clients. These issues certainly must be
addressed in out forum's context as new intelligent networks are being
planned on the initial understanding of MPLS and its potential. One of the
potential benefit for the consideration of implementation was/is its ability
in providing QoS and the provider's ability to define various SLA's
depending on the client's bandwidth - this would also help determine - how
much bandwidth is enough to meet the business needs of an organization.

Mooney

-----Original Message-----
From: neil.2.harrison@bt.com
To: irfanlateef@hotmail.com; Mooney.Sherman@gov.ab.ca;
ck@arch.bellsouth.net; fabriss@TELEFONICA.COM.AR
Cc: mpls@UU.NET
Sent: 04/08/01 7:27 AM
Subject: RE: SLA

Agreed.....but for an operator to be able to create sensible/measureable
SLAs it requires that these factors are addressed:
-	defect defintions (entry/exit criteria) are specified
-	......which leads to required definitions of unavailability (and
its
SLA) 
-	and where the QoS metrics (and their SLA) should only be
associated
with the available state.
Note that these factors have a sequential dependency.

If you have tracked the recent OAM debate (ie on the Ping draft), it is
clear these issues have not yet been properly addressed.

regards, Neil 

> -----Original Message-----
> From: Irfan Lateef [mailto:irfanlateef@hotmail.com]
> Sent: 28 July 2001 01:42
> To: Mooney.Sherman@gov.ab.ca; ck@arch.bellsouth.net;
> fabriss@TELEFONICA.COM.AR
> Cc: mpls@UU.NET
> Subject: RE: SLA
> 
> 
> Fabriss,
> 
> Earlier comments are generally true. But recent SPs have tightened
> the SLA spec which is specified in term of the following,
> 
> Bandwidth=100 Mbits,
> Delay= less than 50 msecs,
> and uptime = 99.999 %
> and some more parameters ....
> 
> And vendors are getting serious in engineering their products
> to meet and exceed these expectations.
> 
> Now the this can be implemented using several techologies and
> frameworks, where MPLS and Diffserv both can be used mutually
> or exclusively to meet the SLA.
> 
> I can go on and on but look at this article which gives a good
> view on SLA.
> 
> http://www.networkmagazine.com/article/NMG20010521S0002
> 
> Irfan Lateef
> 
> 
> 
> 
> 
> >From: Mooney Sherman <Mooney.Sherman@gov.ab.ca>
> >To: 'Christian Kuhtz' <ck@arch.bellsouth.net>,        Fabris Sergio  
> ><fabriss@TELEFONICA.COM.AR>
> >CC: mpls@UU.NET
> >Subject: RE: SLA
> >Date: Fri, 27 Jul 2001 14:59:36 -0600
> >
> >I agree with some of your comments . It can be a marketing 
> tool (gimmick?)
> >but normally a client has certain expectations or need - 
> such as a certain
> >level of bandwidth requirement for the acceptable performance by an
> >application - say video streaming. So the Telco guarantees a certain
> >bandwidth that is acceptable or perhaps a maximum downtime 
> in the form of
> >SLA. SLA is simply an agreement that a vendor or supplier 
> can and will
> >deliver to a client. It can also be used in the context of 
> an application
> >i.e. an application can process/ redirect at least Xnumber 
> of tags for
> >instance in MPLS. Then this would be the SLA for it.
> >
> >-----Original Message-----
> >From: Christian Kuhtz [mailto:ck@arch.bellsouth.net]
> >Sent: Friday, July 27, 2001 2:45 PM
> >To: Fabris Sergio
> >Cc: mpls@UU.NET
> >Subject: Re: SLA
> >
> >
> >
> >On Fri, Jul 27, 2001 at 04:34:09PM -0300, Fabris Sergio wrote:
> > > Is SLA (Service Level Agreement) a term for DiffServ 
> networks only?
> > > Can it be used in an MPLS network?
> >
> >Sergio,
> >
> >You can define an SLA for literally anything, including the 
> performance of
> >your dry cleaner.
> >
> >And an MPLS network can be a 'DiffServ network'; I presume 
> you intend to
> >describe a network in which differentiated services of some kind are
> >offered...
> >
> >SLA per se has nothing to do with differentiated services, 
> other than that
> >differentiated services with methods and tools as proposed 
> by IETF DiffServ
> >can be used to provide a service as described by an SLA.  
> Note also that
> >many
> >SLAs actually have little to do with a direct link to the technology
> >underneath; it is possible that the service you purchase w/ SLA is 
> >identical
> >
> >to the service you purchase w/out SLA, or the service w/ SLA 
> may be very
> >different than the one w/out SLA.  An SLA can be a marketing 
> gimmick,  a
> >financial tool, a technology constraint, or any combination 
> of the above.
> >
> >The term SLA is a very much abused term, often driven more 
> by marketecture
> >and
> >marketeering than technology.  And then there's the set of 
> issues around
> >SLA's
> >with teeth..
> >
> >But, I'm rambling..  What specifically are you looking for?
> >
> >Cheers,
> >Chris
> >
> >--
> >Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm
> >Sr. Architect, Engineering & Architecture, BellSouth.net, 
> Atlanta, GA, U.S.
> >"I speak for myself only.""
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> 


From owner-mpls@UU.NET  Sat Aug  4 17:30:32 2001
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 RAA01164
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 17:30:32 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlare10687;
	Sat, 4 Aug 2001 21:31:06 GMT
Received: by mail-control.mail.uu.net 
	id QQlare11667
	for mpls-outgoing; Sat, 4 Aug 2001 21:30:36 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlare11653
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 21:30:25 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 QQlard21656
	for <mpls@uu.net>; Sat, 4 Aug 2001 21:29:02 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlard15349
	for <mpls@uu.net>; Sat, 4 Aug 2001 21:29:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA12565 for mpls@uu.net; Sat, 4 Aug 2001 17:29:00 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlard11496
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 21:28:16 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 QQlard23635
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:27:28 GMT
Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlard13962
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:27:28 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f74LPcJ18652;
	Sat, 4 Aug 2001 14:25:38 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f74LRLD26852;
	Sat, 4 Aug 2001 14:27:21 -0700 (PDT)
Message-ID: <3B6C6838.4A26AB03@cisco.com>
Date: Sat, 04 Aug 2001 14:25:12 -0700
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: neil.2.harrison@bt.com
CC: pingpan@juniper.net, Brijesh@coronanetworks.com, mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
References: <B9571FDEBD3DD21181E500606DD5EE050E891596@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Neil,

> Given all this, could those advocating the Ping draft please explain what is
> actually wrong with the more comprehensive solution we orginally proposed
> (in draft-harrison-mpls-oam-00.txt).....

Let me try ...

First let me say that your draft seems to be architecturally perfect.
Unfortunately in practice in may meet the following obstacles:

* It is very CPU intensive. It requires per each LSP continues
processing of incomming CV packets in the transit nodes of such an LSP.
Imagine the case that you have 15000 of LSPs in a transit node and each
send you periodically a CV packet. (Ping's draft does not require any
CPU work per transt LSP).

* In the failure detection situation I don't see how it guarantees the
successful notification propagation the head. I can easily think of
cases when your returning FDI or BDI signals get lost due to some purly
forwarding bugs. (Ping's draft uses a control channel for return which
is working correctly).

* It requires 100% of software upgrade in all routes in a given network
(I am sure you realize quite a challange in large networks). 

* It requires simultanues support from all vendors on a given network.
(Is this realistic :) ?

* With all of the complications it does not seems to guarantee the
detection of LDP LSPs failures - only TE LSPs failures. (Sure Ping does
not address this neither yet but is way much more simpler).

* I don't see in the Ping's draft any requirement for end user = client
action - to detect the LSP failure - since you have brought this
argument a lot could you elaborate a bit where in his draft you see such
a need ?

Rgs,
Robert


> neil.2.harrison@bt.com wrote:
> 
> Ping wrote:
> > Sent: 26 July 2001 01:22
> > To: Brijesh Kumar
> > Cc: mpls-list
> > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> >
> >
> > > Brijesh Kumar wrote:
> > >
> > > From this draft:
> > >
> > >    When the ingress LSR suspects that the LSP may have
> > failed and the
> > >    RSVP control plane shows the LSP as operational, the ingress LSR
> > > MUST
> > >    send LSP-ping messages to the egress over the LSP, periodically.
> > > The
> > >    value of the time interval should be configurable.
> > >
> > > Could you please tell me what do you mean by "LSR
> > suspects"? In other
> > > words,
> > > what is the triggering input for LSR to start "suspecting"
> > the LSP may
> > > have failed?
> > >
> > > It will be better if you replace "suspect" with "detect" in
> > your draft
> > > as suspect is an imprecise human emotion and no operator would like
> > > routers that have negative emotions ;-).
> > >
> >
> > It's network operators suspect something may have gone wrong with some
> > LSP's....
> NH=> How do they 'suspect' this?....is some crystal-ball going to be
> supplied with the implementation?  It is not acceptable to have to rely on
> customers to 1st complain.  So what is the detection mechanism for the
> defects, you need to explain this more precisely...see also later comments.
> >
> > > In addition, I do have issues with introducing a mechanism dependent
> > > on a particular signalling protocol for a generic problem - testing
> > > liveness of the label switched data path.
> >
> > OK. Do you have problem with the mechanism itself?
> NH=> I have some problems with it.
> Coming back from 2 weeks leave and trying to wade through the large volume
> of discussion this draft has generated tells me there is a fundamental lack
> of clarity of the problem being solved here.  We really should get the
> problem statement agreed and also agree a set of OAM arch principles to
> prevent bad practice. In summary here is what I propose...and I would
> appreciate some positive feedback on each of these statements if there is
> disagreement:
> 
> 1       Problem statement:
> 
> Operators need to determine the operational status of LSPs.  They need
> simple management tools to do this and operational costs must be driven down
> (ie we can't afford an army of CCIEs to run networks).  As a minimum, this
> requires all defects to be identified and specified in terms of entry/exit
> criteria and the appropriate consequent actions to be taken in order to (i)
> protect customer traffic and (ii) allow simple diagnostics for operational
> staff.  This is also required so that the operators/customers can define
> consistent and measurable availability SLAs and, as a dependent corollary,
> QoS SLAs (since QoS only has any meaning when the LSP is in the available
> state).  Customer/operator SLAs are increasing in importance and this needs
> to be recognised.
> 
> 2       Arch principles:
> Note - although stated against the MPLS case, these can (and should) be
> generalised to apply to any network...including the GMPLS cases (where
> perhaps they may be more obvious to some).
> 
> 2.1     the data-plane and control-plane must have independent OAM.  Note
> that the control-plane must use some data-plane (not necessarily the same as
> that used for customer traffic) and hence needs both its own data-plane OAM
> and OAM (aka as error handling) which is specific to each of the
> control-plane protocols in use....so that would be specific OAM for RSVP-TE,
> CR-LDP, LDP, OSPF, etc.
> 
> 2.2     cross-layer network data-plane OAM dependancies must be avoided.  In
> other words, one should not rely on OAM in technology X to detect/diagnose
> defects in technology Y (whether X is a client or server layer wrt Y).  This
> requirement is also necessary for evolution and backwards compatibility, ie
> to allow layer networks/protocols to be added/removed/modified independently
> and without affecting other layer networks/protocols.
> 
> 2.3     cross-plane OAM dependancies must be avoided.  For example, the
> data-plane OAM should function independent of the signalling/routing
> protocols being used (including the case of no control-plane).  This has
> similar evolution and backwards compatibilty issues as in 2.2.
> 
> 2.4     customers must not be expected to act as the default defect
> detection devices.  Nor must customer traffic activity be used as part of
> the defect detection function (since users can be quiescent).  Note that
> defect detection and defect diagnosis are 2 distinct functions.  This also
> implies that defect detection needs to be a continuous function (at least on
> important LSPs).
> BTW - IMO QoS measurements are 2nd order importance compared to defect
> handling.  QoS should be tackled as a network design and TE issue, with
> suitable verification via population or ad hoc sampling as needed, and not
> overkill measurements which can be both costly and swamp operations people.
> 
> 2.5     OAM mechanisms should be designed to correctly function under
> failure conditions, ie OAM mechanisms must not rely on 'well-behaved'
> network behaviour after a defect has occurred since, by defintion, the fact
> that the network has failed implies its behaviour cannot be expected to be
> predictable.
> 
> 2.6     A failure in a server layer network should not create alarm storms
> in client layer networks.  Noting that client layer networks may be owned by
> different organisations and have a large geographical dispersion.
> 
> 2.7     data-plane LSP OAM should not require a return LSP to
> function....and even with bi-directional LSPs each direction should be
> monitored independently.
> 
> 2.8     failures of the control-plane (either the data-plane aspect or any
> one of the control-plane protocols that run on this) should not result in
> failures of the customer traffic data-plane where such trails are permanent
> or semi-permanent (this is more obvious in the GMPLS case).
> 
> The Ping draft either does not address or fails to meet many of these
> requirements.  More specifically:
> -       it does not identify/specify any defects;
> -       it cannot detect any defects unless it is running continuously;
> -       it could not detect or diagnose all potential defects even if
> running continously, eg mismerging defects;
> -       it relies on both cross-layer (ie ICMP is a IP layer OAM mechanism)
> and cross-plane (ie it is only defined for the RSVP-TE case) functional
> dependancies.  Although this expediency may have some near-term benefit(?)
> it is not good arch practice.
> -       since defects are not detected/defined it is unclear (i) what
> consequent actions are to be taken to protect customer traffic (none it
> seems), (ii) how this will help operators target diagnostic activities or
> (iii) how it will prevent client layer alarm storms.
> -       its all very well having variable behaviour (wrt timers) but this
> will create complexities elsewhere, ie inconsistent entry/exit criteria for
> defects and  availability states, no clear/consistent datums for when QoS
> metrics collection (if being measured) are valid, ie when to start/stop QoS
> metric aggregation.  So this means complexities in SLA derivations.
> 
> So, whilst I would certainly not want to stop any vendor implementing this
> draft, as an operator with responsibilities for the integrity of my
> customers traffic and a need to define SLAs for such, I find it
> professionally very difficult to condone it becoming a 'standard'.
> 
> >
> > > Secondly, can we have some
> > > input/justification with regards to the assumption that there is a
> > > need to detect such a failure since only cause for such a failure
> > > given in the draft is "memory Corruption". What causes so called
> > > memory corruption? Are we trying to repair badly written code here?
> > >
> >
> > The problem did happen in the real network. I'm not going to point
> > fingers on the cause of the problem. But we (vendors and
> > providers) did
> > realize from that incidence that we need to have a simple mechanism to
> > check LSP's data plane in today's operational networks.
> NH=> Some time ago I was hearing comments such as 'these defects won't
> happen' and 'don't fix software bugs with additional software' (an erroneous
> argument anyway).  So having now establised that defects do exist, I fully
> agree we need some way of detecting/diagnosing such defects.  But this seems
> not what is being advocated here, since the mechanism does not help
> operators to detect the defects in the first place.  To address the
> detection aspect some mechanism has to run continuously, and a technique
> that is unidirectional would seem to be simpler/better than one that
> requires a return path.  At some point one needs to raise an alarm and take
> other consequent actions (eg maybe even squelching customer traffic if
> intergity/security could be being compromised, and stop any QoS metric
> aggregation (if being used)) and raise a vertical indication to the NMS...so
> what better place to do this than at the point where the defect is being
> initially detected, ie the LSP sink?
> 
> Given all this, could those advocating the Ping draft please explain what is
> actually wrong with the more comprehensive solution we orginally proposed
> (in draft-harrison-mpls-oam-00.txt).....and in particular, the use of the CV
> flow.....which is really nothing more than a keepalive running from soure to
> sink with a unique source identifier and deterministic behaviour....surely
> it can't be much simpler than this can it?
> >
> > The whole purpose on various proposals (fast reroute, graceful restart
> > and LSP-ping) is to make the whole network working nicely,
> > even when we
> > have routers from other vendors that have badly written code.
> >
> > - Ping
> >



From owner-mpls@UU.NET  Sat Aug  4 17:50:22 2001
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 RAA01401
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 17:50:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlarf01557;
	Sat, 4 Aug 2001 21:50:38 GMT
Received: by mail-control.mail.uu.net 
	id QQlarf13559
	for mpls-outgoing; Sat, 4 Aug 2001 21:50:07 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlarf13467
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 21:49: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 QQlarf13640
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:49:19 GMT
Received: from viola.watersprings.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: viola.watersprings.org [211.130.20.221])
	id QQlarf14805
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:49:18 GMT
Received: from localhost (localhost [127.0.0.1])
	by viola.watersprings.org (8.11.0/8.11.0) with ESMTP id f74LqDq00697;
	Sun, 5 Aug 2001 06:52:13 +0900 (JST)
From: Noritoshi Demizu <demizu@dd.iij4u.or.jp>
To: mpls@UU.NET
Subject: FYI: PPVPN and IPO agenda in HTML format
In-Reply-To: Your message of "Fri, 03 Aug 2001 06:53:36 +0900"
References: <20010803065336J.demizu@dd.iij4u.or.jp>
X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3
X-URL: http://www.dd.iij4u.or.jp/~demizu/
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010805065212O.demizu@dd.iij4u.or.jp>
Date: Sun, 05 Aug 2001 06:52:12 +0900
X-Dispatcher: impost version 0.99i (Apr. 6, 1997)
Lines: 17
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

I also converted the PPVPN and IPO agenda to HTML format.
They are located at

  http://www.watersprings.org/links/mlr/article/ppvpn-0108-agenda.html
  http://www.watersprings.org/links/mlr/article/ipo-0108-agenda.html

Please let me know if you found errors.  Thank you.

Best Regards,
Noritoshi Demizu


ps. Because I think many people on this mailing list have interest of
    these working groups, I sent this announcement to this list.
    I am sorry if you do not have interest.


From owner-mpls@UU.NET  Sat Aug  4 20:20:03 2001
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 UAA02713
	for <mpls-archive@lists.ietf.org>; Sat, 4 Aug 2001 20:20:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlarp01280;
	Sun, 5 Aug 2001 00:20:24 GMT
Received: by mail-control.mail.uu.net 
	id QQlarp23640
	for mpls-outgoing; Sun, 5 Aug 2001 00:19:49 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlarp23632
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 00:19:38 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 QQlarp28615
	for <mpls@uu.net>; Sun, 5 Aug 2001 00:18:34 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlarp17174
	for <mpls@uu.net>; Sun, 5 Aug 2001 00:18:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA18857 for mpls@uu.net; Sat, 4 Aug 2001 20:18:33 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlarp23572
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 00:18: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 QQlarp21868
	for <mpls@uu.net>; Sun, 5 Aug 2001 00:17:33 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQlarp11583
	for <mpls@uu.net>; Sun, 5 Aug 2001 00:17:33 GMT
Received: from cisco.com (sjc-vpn1-13.cisco.com [10.21.96.13])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA24101
	for <mpls@uu.net>; Sat, 4 Aug 2001 17:17:31 -0700 (PDT)
Message-ID: <3B6C9098.92C23408@cisco.com>
Date: Sat, 04 Aug 2001 17:17:28 -0700
From: Abdul Rahim <arahim@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Basic Question on Sec 3.27.5 in RFC 3031
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi guys

Can some body give me practical example of Implict peering

I guess both BGP peer and Endpoint of LSP tunnels come under the
definition of Explicit peering

Thanks
Abdul Rahim



From owner-mpls@UU.NET  Sun Aug  5 03:37:17 2001
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 DAA04761
	for <mpls-archive@lists.ietf.org>; Sun, 5 Aug 2001 03:37:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlass03359;
	Sun, 5 Aug 2001 07:37:34 GMT
Received: by mail-control.mail.uu.net 
	id QQlass14150
	for mpls-outgoing; Sun, 5 Aug 2001 07:37:04 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlass14145
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 07:37: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 QQlass20792
	for <mpls@UU.NET>; Sun, 5 Aug 2001 07:36:40 GMT
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQlass02092
	for <mpls@UU.NET>; Sun, 5 Aug 2001 07:36:39 GMT
Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP;
          Sun, 5 Aug 2001 08:36:08 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) 
          id <3X2VTMJC>; Sun, 5 Aug 2001 08:36:00 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E89159F@mbddmknt01.hc.bt.com>
To: raszuk@cisco.com
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Sun, 5 Aug 2001 08:35:54 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello Robert...please see comments below:
Regards, Neil

> Hi Neil,
> 
> > Given all this, could those advocating the Ping draft 
> please explain what is
> > actually wrong with the more comprehensive solution we 
> orginally proposed
> > (in draft-harrison-mpls-oam-00.txt).....
> 
> Let me try ...
> 
> First let me say that your draft seems to be architecturally perfect.
NH=> It is not perfect, but its the closest and simplest scheme I have yet
seen.  And it is the only one that meets most of our requirements as an
operator....you seem to have overlooked responding to these, or at least
acknowledging that the Ping draft fails to satisfy them, ie its no good
having a 'simple' (though I disagree the Ping draft is simpler that ours)
solution if its not fit for purpose is it?

> Unfortunately in practice in may meet the following obstacles:
> 
> * It is very CPU intensive. It requires per each LSP continues
> processing of incomming CV packets in the transit nodes of 
> such an LSP.
> Imagine the case that you have 15000 of LSPs in a transit 
> node and each
> send you periodically a CV packet. (Ping's draft does not require any
> CPU work per transt LSP).
NH=> I don't think you understand how this works.  The whole point of it is
*not* to put any load on transit LSRs.......these simply pass the OAM CV
payload transparently (forwarding is on the lower 'normal traffic' LSP
header since for OAM pkts the label stack becomes 2 deep instead of 1).  The
same would apply to any other OAM pkt types if employed, ie they would only
ever invoke processing at source and sink points.  If you were doing some
per node loopback (like some route-trace say) then I agree this could be CPU
intensive since every node would have to check every LSP pkt to see if it
was a OAM route-trace pkt or not.....but our scheme was designed from the
outset to avoid this on purpose and hence be scalable.  The only points that
have anything to do with CV processing are the source and sink.  And
further, there is big difference between generating the CV at the LSP source
(which is trivial since it is always invariant) and processing it at the LSP
sink.....indeed, on non-important LSPs one would not have to process it if
you did not want (eg to generate availability statistics for such LSPs).
The only downside to not checking the CV at all LSP sink points is that we
might miss leaking traffic out of an important LSP onto a non-important
LSP.....clearly we can detect leaking the other way round (due to seeing an
unexpected CV flow arriving).   
> 
> * In the failure detection situation I don't see how it guarantees the
> successful notification propagation the head. I can easily think of
> cases when your returning FDI or BDI signals get lost due to 
> some purly
> forwarding bugs. (Ping's draft uses a control channel for return which
> is working correctly).
NH=> FDI and BDI are 'nice to have' features but are not essential in a
single domain (they do however, become increasingly important when/if we
ever get round to inter-domain interworking or client/server services, eg
transit LSP service).....but CV is mandatory since this is the main defect
detection mechanism.  FDI is there to stop alarm storms in higher layers and
BDI is there is you want to tell the source of outgoing defect, ie defect in
other direction.  But, why should you always want to tell the head-end?  If
you want to invoke prot-sw in a non 1+1 case from the head end then yes you
would want some return information, but the absolute minimum requirement is
(i) to detect all failures at the sink and (ii) to take appropriate
consequent actions at that point, eg raise a failure indication at the sink
point, stop QoS agggretaion, etc.  So there has to be some form of
processing at the sink point in any case.  Note that the draft does not
imply that BDI (if required) be always sent on a return LSP....it can go OOB
in the management-plane (or even the control-plane).  Note also that,
assuming bi-directional LSPs,  we can have unidirectional and bi-directional
failures (this also has implications for QoS processing, if being used,
which have to be done on a per direction basis).  In former case the CV flow
of only the broken direction is interrupted (so here one could see incoming
CV and BDI) whilst in the latter case the CV flow of both directions is
missing.......and further, if the failure is from a lower layer then:
-	this would appear as incoming AIS if below MPLS fabric (eg SDH) at
1st downstream LSR past failure, or
-	this would appear as incoming FDI (+ loss of CV) if lower LSP
failure and FDI being employed.
So, if full OAM set being used one gets comprensive and simple operational
diagnostics for our operational staff.
Note - there are further subtleties in FDI and BDI (if used) to aid failure
location and failure type that I have not discussed here...again they have
operational benefits in an inter-domain case.
> 
> * It requires 100% of software upgrade in all routes in a 
> given network
> (I am sure you realize quite a challange in large networks).
NH=> I agree some changes are needed....but this is true of any new
functions.  The proposals are also backwards compatible.  And note that the
CV processing is constrained to source/sink points as I noted above, so it
does not necsaarily imply wholesale fork-lift upgrade of all nodes at once.
However, I see MPLS as such a potentially important technology (for a whole
raft of reasons) that I want to see things like defect handling addressed
properly from the outset.....because if we don't, it is even harder to get
things done right once some inferior solution is adopted just to suit some
expediency.  Indeed, this is the whole purpose of (i) agreeing the problem
statement and (ii) setting arch principles that must or should be met, ie
before someone decides that solution X is what is needed there should be
general agreement across the operator community that solution X is fit for
their purpose.
> 
> * It requires simultanues support from all vendors on a given network.
> (Is this realistic :) ?
NH=> No its does not...it can be introduced gradually as I noted above.
> 
> * With all of the complications it does not seems to guarantee the
> detection of LDP LSPs failures - only TE LSPs failures. (Sure 
> Ping does
> not address this neither yet but is way much more simpler).
NH=> I disagree Ping is simpler.....you can't get simpler than the CV flow
(it is only a 'hello' by another name).  We have been looking at extending
the support to LDP and some ideas here.  Further, the Ping draft only seems
to address simple breaks in connectivity (though it does not even detect
these, which is a primary requirement, and appears to rely on customers to
complain...which I would argue is unaccetable).  Not only does CV detect
below/within MPLS fabric simple breaks, it also detects all mismerging cases
and so offers both greater functionally and protection of customer traffic
integrity.
> 
> * I don't see in the Ping's draft any requirement for end 
> user = client
> action - to detect the LSP failure - since you have brought this
> argument a lot could you elaborate a bit where in his draft 
> you see such
> a need ?
NH=> Why not ask Ping how defects are detected in the 1st place?  I asked
this in my orginal mail and so did Brijesh Kumar.  I am awaiting a response.
All Ping said in his response to Brijesh was:
"> It's network operators suspect something may have gone wrong with some
> LSP's...."  So I too want to understand how operators are supposed to
'suspect' something is wrong with an LSP.
> 
> Rgs,
> Robert
> 
> 
> > neil.2.harrison@bt.com wrote:
> > 
> > Ping wrote:
> > > Sent: 26 July 2001 01:22
> > > To: Brijesh Kumar
> > > Cc: mpls-list
> > > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> > >
> > >
> > > > Brijesh Kumar wrote:
> > > >
> > > > From this draft:
> > > >
> > > >    When the ingress LSR suspects that the LSP may have
> > > failed and the
> > > >    RSVP control plane shows the LSP as operational, the 
> ingress LSR
> > > > MUST
> > > >    send LSP-ping messages to the egress over the LSP, 
> periodically.
> > > > The
> > > >    value of the time interval should be configurable.
> > > >
> > > > Could you please tell me what do you mean by "LSR
> > > suspects"? In other
> > > > words,
> > > > what is the triggering input for LSR to start "suspecting"
> > > the LSP may
> > > > have failed?
> > > >
> > > > It will be better if you replace "suspect" with "detect" in
> > > your draft
> > > > as suspect is an imprecise human emotion and no 
> operator would like
> > > > routers that have negative emotions ;-).
> > > >
> > >
> > > It's network operators suspect something may have gone 
> wrong with some
> > > LSP's....
> > NH=> How do they 'suspect' this?....is some crystal-ball going to be
> > supplied with the implementation?  It is not acceptable to 
> have to rely on
> > customers to 1st complain.  So what is the detection 
> mechanism for the
> > defects, you need to explain this more precisely...see also 
> later comments.
> > >
> > > > In addition, I do have issues with introducing a 
> mechanism dependent
> > > > on a particular signalling protocol for a generic 
> problem - testing
> > > > liveness of the label switched data path.
> > >
> > > OK. Do you have problem with the mechanism itself?
> > NH=> I have some problems with it.
> > Coming back from 2 weeks leave and trying to wade through 
> the large volume
> > of discussion this draft has generated tells me there is a 
> fundamental lack
> > of clarity of the problem being solved here.  We really 
> should get the
> > problem statement agreed and also agree a set of OAM arch 
> principles to
> > prevent bad practice. In summary here is what I 
> propose...and I would
> > appreciate some positive feedback on each of these 
> statements if there is
> > disagreement:
> > 
> > 1       Problem statement:
> > 
> > Operators need to determine the operational status of LSPs. 
>  They need
> > simple management tools to do this and operational costs 
> must be driven down
> > (ie we can't afford an army of CCIEs to run networks).  As 
> a minimum, this
> > requires all defects to be identified and specified in 
> terms of entry/exit
> > criteria and the appropriate consequent actions to be taken 
> in order to (i)
> > protect customer traffic and (ii) allow simple diagnostics 
> for operational
> > staff.  This is also required so that the 
> operators/customers can define
> > consistent and measurable availability SLAs and, as a 
> dependent corollary,
> > QoS SLAs (since QoS only has any meaning when the LSP is in 
> the available
> > state).  Customer/operator SLAs are increasing in 
> importance and this needs
> > to be recognised.
> > 
> > 2       Arch principles:
> > Note - although stated against the MPLS case, these can 
> (and should) be
> > generalised to apply to any network...including the GMPLS 
> cases (where
> > perhaps they may be more obvious to some).
> > 
> > 2.1     the data-plane and control-plane must have 
> independent OAM.  Note
> > that the control-plane must use some data-plane (not 
> necessarily the same as
> > that used for customer traffic) and hence needs both its 
> own data-plane OAM
> > and OAM (aka as error handling) which is specific to each of the
> > control-plane protocols in use....so that would be specific 
> OAM for RSVP-TE,
> > CR-LDP, LDP, OSPF, etc.
> > 
> > 2.2     cross-layer network data-plane OAM dependancies 
> must be avoided.  In
> > other words, one should not rely on OAM in technology X to 
> detect/diagnose
> > defects in technology Y (whether X is a client or server 
> layer wrt Y).  This
> > requirement is also necessary for evolution and backwards 
> compatibility, ie
> > to allow layer networks/protocols to be 
> added/removed/modified independently
> > and without affecting other layer networks/protocols.
> > 
> > 2.3     cross-plane OAM dependancies must be avoided.  For 
> example, the
> > data-plane OAM should function independent of the signalling/routing
> > protocols being used (including the case of no 
> control-plane).  This has
> > similar evolution and backwards compatibilty issues as in 2.2.
> > 
> > 2.4     customers must not be expected to act as the default defect
> > detection devices.  Nor must customer traffic activity be 
> used as part of
> > the defect detection function (since users can be 
> quiescent).  Note that
> > defect detection and defect diagnosis are 2 distinct 
> functions.  This also
> > implies that defect detection needs to be a continuous 
> function (at least on
> > important LSPs).
> > BTW - IMO QoS measurements are 2nd order importance 
> compared to defect
> > handling.  QoS should be tackled as a network design and TE 
> issue, with
> > suitable verification via population or ad hoc sampling as 
> needed, and not
> > overkill measurements which can be both costly and swamp 
> operations people.
> > 
> > 2.5     OAM mechanisms should be designed to correctly 
> function under
> > failure conditions, ie OAM mechanisms must not rely on 
> 'well-behaved'
> > network behaviour after a defect has occurred since, by 
> defintion, the fact
> > that the network has failed implies its behaviour cannot be 
> expected to be
> > predictable.
> > 
> > 2.6     A failure in a server layer network should not 
> create alarm storms
> > in client layer networks.  Noting that client layer 
> networks may be owned by
> > different organisations and have a large geographical dispersion.
> > 
> > 2.7     data-plane LSP OAM should not require a return LSP to
> > function....and even with bi-directional LSPs each 
> direction should be
> > monitored independently.
> > 
> > 2.8     failures of the control-plane (either the 
> data-plane aspect or any
> > one of the control-plane protocols that run on this) should 
> not result in
> > failures of the customer traffic data-plane where such 
> trails are permanent
> > or semi-permanent (this is more obvious in the GMPLS case).
> > 
> > The Ping draft either does not address or fails to meet 
> many of these
> > requirements.  More specifically:
> > -       it does not identify/specify any defects;
> > -       it cannot detect any defects unless it is running 
> continuously;
> > -       it could not detect or diagnose all potential 
> defects even if
> > running continously, eg mismerging defects;
> > -       it relies on both cross-layer (ie ICMP is a IP 
> layer OAM mechanism)
> > and cross-plane (ie it is only defined for the RSVP-TE 
> case) functional
> > dependancies.  Although this expediency may have some 
> near-term benefit(?)
> > it is not good arch practice.
> > -       since defects are not detected/defined it is 
> unclear (i) what
> > consequent actions are to be taken to protect customer 
> traffic (none it
> > seems), (ii) how this will help operators target diagnostic 
> activities or
> > (iii) how it will prevent client layer alarm storms.
> > -       its all very well having variable behaviour (wrt 
> timers) but this
> > will create complexities elsewhere, ie inconsistent 
> entry/exit criteria for
> > defects and  availability states, no clear/consistent 
> datums for when QoS
> > metrics collection (if being measured) are valid, ie when 
> to start/stop QoS
> > metric aggregation.  So this means complexities in SLA derivations.
> > 
> > So, whilst I would certainly not want to stop any vendor 
> implementing this
> > draft, as an operator with responsibilities for the integrity of my
> > customers traffic and a need to define SLAs for such, I find it
> > professionally very difficult to condone it becoming a 'standard'.
> > 
> > >
> > > > Secondly, can we have some
> > > > input/justification with regards to the assumption that 
> there is a
> > > > need to detect such a failure since only cause for such 
> a failure
> > > > given in the draft is "memory Corruption". What causes so called
> > > > memory corruption? Are we trying to repair badly 
> written code here?
> > > >
> > >
> > > The problem did happen in the real network. I'm not going to point
> > > fingers on the cause of the problem. But we (vendors and
> > > providers) did
> > > realize from that incidence that we need to have a simple 
> mechanism to
> > > check LSP's data plane in today's operational networks.
> > NH=> Some time ago I was hearing comments such as 'these 
> defects won't
> > happen' and 'don't fix software bugs with additional 
> software' (an erroneous
> > argument anyway).  So having now establised that defects do 
> exist, I fully
> > agree we need some way of detecting/diagnosing such 
> defects.  But this seems
> > not what is being advocated here, since the mechanism does not help
> > operators to detect the defects in the first place.  To address the
> > detection aspect some mechanism has to run continuously, 
> and a technique
> > that is unidirectional would seem to be simpler/better than one that
> > requires a return path.  At some point one needs to raise 
> an alarm and take
> > other consequent actions (eg maybe even squelching customer 
> traffic if
> > intergity/security could be being compromised, and stop any 
> QoS metric
> > aggregation (if being used)) and raise a vertical 
> indication to the NMS...so
> > what better place to do this than at the point where the 
> defect is being
> > initially detected, ie the LSP sink?
> > 
> > Given all this, could those advocating the Ping draft 
> please explain what is
> > actually wrong with the more comprehensive solution we 
> orginally proposed
> > (in draft-harrison-mpls-oam-00.txt).....and in particular, 
> the use of the CV
> > flow.....which is really nothing more than a keepalive 
> running from soure to
> > sink with a unique source identifier and deterministic 
> behaviour....surely
> > it can't be much simpler than this can it?
> > >
> > > The whole purpose on various proposals (fast reroute, 
> graceful restart
> > > and LSP-ping) is to make the whole network working nicely,
> > > even when we
> > > have routers from other vendors that have badly written code.
> > >
> > > - Ping
> > >
> 


From owner-mpls@UU.NET  Sun Aug  5 04:25:22 2001
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 EAA10277
	for <mpls-archive@lists.ietf.org>; Sun, 5 Aug 2001 04:25:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlasv10444;
	Sun, 5 Aug 2001 08:25:51 GMT
Received: by mail-control.mail.uu.net 
	id QQlasv07626
	for mpls-outgoing; Sun, 5 Aug 2001 08:25:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlasv07609
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 08:25:03 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 QQlasv11187
	for <mpls@uu.net>; Sun, 5 Aug 2001 08:23:27 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlasv06091
	for <mpls@uu.net>; Sun, 5 Aug 2001 08:23:26 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA05552 for mpls@uu.net; Sun, 5 Aug 2001 04:23:25 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlasv07505
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 08:22:47 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 QQlasv05931
	for <mpls@UU.NET>; Sun, 5 Aug 2001 08:17:36 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 QQlasv20396
	for <mpls@UU.NET>; Sun, 5 Aug 2001 08:17:35 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f758HnY07968;
	Sun, 5 Aug 2001 01:17:49 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f758HVh11974;
	Sun, 5 Aug 2001 01:17:31 -0700 (PDT)
Message-ID: <3B6D009A.4B0FEEC1@cisco.com>
Date: Sun, 05 Aug 2001 01:15:22 -0700
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: neil.2.harrison@bt.com
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
References: <B9571FDEBD3DD21181E500606DD5EE050E89159F@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Neil,

A few follow up questions ...

1.

>    The node in the layer network, which first detects a defect (sourced 
>    from within that layer), should apply a well-known 'Forward Defect 

>    (1)  There should be a complimentary Backward Defect Indication 

If FDIs & BDIs are optional I think you should s/should/may/. On the
other hand I think that those msg are costly in cpu but very usefull
(especially in the diagnostic case). Making them optional really changes
the understanding of your draft.

2. 

Reg item 5.7 

...

>    It is therefore required that a unique trail source identifier be 
>    periodically transmitted from the trail source to the trail sink to 
>    detect these types of defect. 

> But, why should you always want to tell the head-end?  If
> you want to invoke prot-sw in a non 1+1 case from the head end then yes you
> would want some return information, but the absolute minimum requirement is
> (i) to detect all failures at the sink and (ii) to take appropriate
> consequent actions at that point, eg raise a failure indication at the sink
> point, stop QoS agggretaion, etc. 

Here we seems to quite disagree. IMHO source needs to know about given
LSP failure to take corective action and not the sink. Rasing failure
indication at the sink and counting for either an offline tool action or
even worse human action to fix it is way too slow. 

If the LSP is broken source should immediately either shut given LSP or
switch the traffic to another path (if past protection is applied).

> Further, the Ping draft only seems
> > to address simple breaks in connectivity (though it does not even detect
> > these, which is a primary requirement, and appears to rely on customers to
> > complain...which I would argue is unaccetable).

I will either let Ping address this or we can talk live ....

Rgs,
Robert

PS. It would be probably easier to get together next week and discuss
this face to face. I will send an offline mail reg this.

> neil.2.harrison@bt.com wrote:
> 
> Hello Robert...please see comments below:
> Regards, Neil
> 
> > Hi Neil,
> >
> > > Given all this, could those advocating the Ping draft
> > please explain what is
> > > actually wrong with the more comprehensive solution we
> > orginally proposed
> > > (in draft-harrison-mpls-oam-00.txt).....
> >
> > Let me try ...
> >
> > First let me say that your draft seems to be architecturally perfect.
> NH=> It is not perfect, but its the closest and simplest scheme I have yet
> seen.  And it is the only one that meets most of our requirements as an
> operator....you seem to have overlooked responding to these, or at least
> acknowledging that the Ping draft fails to satisfy them, ie its no good
> having a 'simple' (though I disagree the Ping draft is simpler that ours)
> solution if its not fit for purpose is it?
> 
> > Unfortunately in practice in may meet the following obstacles:
> >
> > * It is very CPU intensive. It requires per each LSP continues
> > processing of incomming CV packets in the transit nodes of
> > such an LSP.
> > Imagine the case that you have 15000 of LSPs in a transit
> > node and each
> > send you periodically a CV packet. (Ping's draft does not require any
> > CPU work per transt LSP).
> NH=> I don't think you understand how this works.  The whole point of it is
> *not* to put any load on transit LSRs.......these simply pass the OAM CV
> payload transparently (forwarding is on the lower 'normal traffic' LSP
> header since for OAM pkts the label stack becomes 2 deep instead of 1).  The
> same would apply to any other OAM pkt types if employed, ie they would only
> ever invoke processing at source and sink points.  If you were doing some
> per node loopback (like some route-trace say) then I agree this could be CPU
> intensive since every node would have to check every LSP pkt to see if it
> was a OAM route-trace pkt or not.....but our scheme was designed from the
> outset to avoid this on purpose and hence be scalable.  The only points that
> have anything to do with CV processing are the source and sink.  And
> further, there is big difference between generating the CV at the LSP source
> (which is trivial since it is always invariant) and processing it at the LSP
> sink.....indeed, on non-important LSPs one would not have to process it if
> you did not want (eg to generate availability statistics for such LSPs).
> The only downside to not checking the CV at all LSP sink points is that we
> might miss leaking traffic out of an important LSP onto a non-important
> LSP.....clearly we can detect leaking the other way round (due to seeing an
> unexpected CV flow arriving).
> >
> > * In the failure detection situation I don't see how it guarantees the
> > successful notification propagation the head. I can easily think of
> > cases when your returning FDI or BDI signals get lost due to
> > some purly
> > forwarding bugs. (Ping's draft uses a control channel for return which
> > is working correctly).
> NH=> FDI and BDI are 'nice to have' features but are not essential in a
> single domain (they do however, become increasingly important when/if we
> ever get round to inter-domain interworking or client/server services, eg
> transit LSP service).....but CV is mandatory since this is the main defect
> detection mechanism.  FDI is there to stop alarm storms in higher layers and
> BDI is there is you want to tell the source of outgoing defect, ie defect in
> other direction.  But, why should you always want to tell the head-end?  If
> you want to invoke prot-sw in a non 1+1 case from the head end then yes you
> would want some return information, but the absolute minimum requirement is
> (i) to detect all failures at the sink and (ii) to take appropriate
> consequent actions at that point, eg raise a failure indication at the sink
> point, stop QoS agggretaion, etc.  So there has to be some form of
> processing at the sink point in any case.  Note that the draft does not
> imply that BDI (if required) be always sent on a return LSP....it can go OOB
> in the management-plane (or even the control-plane).  Note also that,
> assuming bi-directional LSPs,  we can have unidirectional and bi-directional
> failures (this also has implications for QoS processing, if being used,
> which have to be done on a per direction basis).  In former case the CV flow
> of only the broken direction is interrupted (so here one could see incoming
> CV and BDI) whilst in the latter case the CV flow of both directions is
> missing.......and further, if the failure is from a lower layer then:
> -       this would appear as incoming AIS if below MPLS fabric (eg SDH) at
> 1st downstream LSR past failure, or
> -       this would appear as incoming FDI (+ loss of CV) if lower LSP
> failure and FDI being employed.
> So, if full OAM set being used one gets comprensive and simple operational
> diagnostics for our operational staff.
> Note - there are further subtleties in FDI and BDI (if used) to aid failure
> location and failure type that I have not discussed here...again they have
> operational benefits in an inter-domain case.
> >
> > * It requires 100% of software upgrade in all routes in a
> > given network
> > (I am sure you realize quite a challange in large networks).
> NH=> I agree some changes are needed....but this is true of any new
> functions.  The proposals are also backwards compatible.  And note that the
> CV processing is constrained to source/sink points as I noted above, so it
> does not necsaarily imply wholesale fork-lift upgrade of all nodes at once.
> However, I see MPLS as such a potentially important technology (for a whole
> raft of reasons) that I want to see things like defect handling addressed
> properly from the outset.....because if we don't, it is even harder to get
> things done right once some inferior solution is adopted just to suit some
> expediency.  Indeed, this is the whole purpose of (i) agreeing the problem
> statement and (ii) setting arch principles that must or should be met, ie
> before someone decides that solution X is what is needed there should be
> general agreement across the operator community that solution X is fit for
> their purpose.
> >
> > * It requires simultanues support from all vendors on a given network.
> > (Is this realistic :) ?
> NH=> No its does not...it can be introduced gradually as I noted above.
> >
> > * With all of the complications it does not seems to guarantee the
> > detection of LDP LSPs failures - only TE LSPs failures. (Sure
> > Ping does
> > not address this neither yet but is way much more simpler).
> NH=> I disagree Ping is simpler.....you can't get simpler than the CV flow
> (it is only a 'hello' by another name).  We have been looking at extending
> the support to LDP and some ideas here.  Further, the Ping draft only seems
> to address simple breaks in connectivity (though it does not even detect
> these, which is a primary requirement, and appears to rely on customers to
> complain...which I would argue is unaccetable).  Not only does CV detect
> below/within MPLS fabric simple breaks, it also detects all mismerging cases
> and so offers both greater functionally and protection of customer traffic
> integrity.
> >
> > * I don't see in the Ping's draft any requirement for end
> > user = client
> > action - to detect the LSP failure - since you have brought this
> > argument a lot could you elaborate a bit where in his draft
> > you see such
> > a need ?
> NH=> Why not ask Ping how defects are detected in the 1st place?  I asked
> this in my orginal mail and so did Brijesh Kumar.  I am awaiting a response.
> All Ping said in his response to Brijesh was:
> "> It's network operators suspect something may have gone wrong with some
> > LSP's...."  So I too want to understand how operators are supposed to
> 'suspect' something is wrong with an LSP.
> >
> > Rgs,
> > Robert
> >
> >
> > > neil.2.harrison@bt.com wrote:
> > >
> > > Ping wrote:
> > > > Sent: 26 July 2001 01:22
> > > > To: Brijesh Kumar
> > > > Cc: mpls-list
> > > > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> > > >
> > > >
> > > > > Brijesh Kumar wrote:
> > > > >
> > > > > From this draft:
> > > > >
> > > > >    When the ingress LSR suspects that the LSP may have
> > > > failed and the
> > > > >    RSVP control plane shows the LSP as operational, the
> > ingress LSR
> > > > > MUST
> > > > >    send LSP-ping messages to the egress over the LSP,
> > periodically.
> > > > > The
> > > > >    value of the time interval should be configurable.
> > > > >
> > > > > Could you please tell me what do you mean by "LSR
> > > > suspects"? In other
> > > > > words,
> > > > > what is the triggering input for LSR to start "suspecting"
> > > > the LSP may
> > > > > have failed?
> > > > >
> > > > > It will be better if you replace "suspect" with "detect" in
> > > > your draft
> > > > > as suspect is an imprecise human emotion and no
> > operator would like
> > > > > routers that have negative emotions ;-).
> > > > >
> > > >
> > > > It's network operators suspect something may have gone
> > wrong with some
> > > > LSP's....
> > > NH=> How do they 'suspect' this?....is some crystal-ball going to be
> > > supplied with the implementation?  It is not acceptable to
> > have to rely on
> > > customers to 1st complain.  So what is the detection
> > mechanism for the
> > > defects, you need to explain this more precisely...see also
> > later comments.
> > > >
> > > > > In addition, I do have issues with introducing a
> > mechanism dependent
> > > > > on a particular signalling protocol for a generic
> > problem - testing
> > > > > liveness of the label switched data path.
> > > >
> > > > OK. Do you have problem with the mechanism itself?
> > > NH=> I have some problems with it.
> > > Coming back from 2 weeks leave and trying to wade through
> > the large volume
> > > of discussion this draft has generated tells me there is a
> > fundamental lack
> > > of clarity of the problem being solved here.  We really
> > should get the
> > > problem statement agreed and also agree a set of OAM arch
> > principles to
> > > prevent bad practice. In summary here is what I
> > propose...and I would
> > > appreciate some positive feedback on each of these
> > statements if there is
> > > disagreement:
> > >
> > > 1       Problem statement:
> > >
> > > Operators need to determine the operational status of LSPs.
> >  They need
> > > simple management tools to do this and operational costs
> > must be driven down
> > > (ie we can't afford an army of CCIEs to run networks).  As
> > a minimum, this
> > > requires all defects to be identified and specified in
> > terms of entry/exit
> > > criteria and the appropriate consequent actions to be taken
> > in order to (i)
> > > protect customer traffic and (ii) allow simple diagnostics
> > for operational
> > > staff.  This is also required so that the
> > operators/customers can define
> > > consistent and measurable availability SLAs and, as a
> > dependent corollary,
> > > QoS SLAs (since QoS only has any meaning when the LSP is in
> > the available
> > > state).  Customer/operator SLAs are increasing in
> > importance and this needs
> > > to be recognised.
> > >
> > > 2       Arch principles:
> > > Note - although stated against the MPLS case, these can
> > (and should) be
> > > generalised to apply to any network...including the GMPLS
> > cases (where
> > > perhaps they may be more obvious to some).
> > >
> > > 2.1     the data-plane and control-plane must have
> > independent OAM.  Note
> > > that the control-plane must use some data-plane (not
> > necessarily the same as
> > > that used for customer traffic) and hence needs both its
> > own data-plane OAM
> > > and OAM (aka as error handling) which is specific to each of the
> > > control-plane protocols in use....so that would be specific
> > OAM for RSVP-TE,
> > > CR-LDP, LDP, OSPF, etc.
> > >
> > > 2.2     cross-layer network data-plane OAM dependancies
> > must be avoided.  In
> > > other words, one should not rely on OAM in technology X to
> > detect/diagnose
> > > defects in technology Y (whether X is a client or server
> > layer wrt Y).  This
> > > requirement is also necessary for evolution and backwards
> > compatibility, ie
> > > to allow layer networks/protocols to be
> > added/removed/modified independently
> > > and without affecting other layer networks/protocols.
> > >
> > > 2.3     cross-plane OAM dependancies must be avoided.  For
> > example, the
> > > data-plane OAM should function independent of the signalling/routing
> > > protocols being used (including the case of no
> > control-plane).  This has
> > > similar evolution and backwards compatibilty issues as in 2.2.
> > >
> > > 2.4     customers must not be expected to act as the default defect
> > > detection devices.  Nor must customer traffic activity be
> > used as part of
> > > the defect detection function (since users can be
> > quiescent).  Note that
> > > defect detection and defect diagnosis are 2 distinct
> > functions.  This also
> > > implies that defect detection needs to be a continuous
> > function (at least on
> > > important LSPs).
> > > BTW - IMO QoS measurements are 2nd order importance
> > compared to defect
> > > handling.  QoS should be tackled as a network design and TE
> > issue, with
> > > suitable verification via population or ad hoc sampling as
> > needed, and not
> > > overkill measurements which can be both costly and swamp
> > operations people.
> > >
> > > 2.5     OAM mechanisms should be designed to correctly
> > function under
> > > failure conditions, ie OAM mechanisms must not rely on
> > 'well-behaved'
> > > network behaviour after a defect has occurred since, by
> > defintion, the fact
> > > that the network has failed implies its behaviour cannot be
> > expected to be
> > > predictable.
> > >
> > > 2.6     A failure in a server layer network should not
> > create alarm storms
> > > in client layer networks.  Noting that client layer
> > networks may be owned by
> > > different organisations and have a large geographical dispersion.
> > >
> > > 2.7     data-plane LSP OAM should not require a return LSP to
> > > function....and even with bi-directional LSPs each
> > direction should be
> > > monitored independently.
> > >
> > > 2.8     failures of the control-plane (either the
> > data-plane aspect or any
> > > one of the control-plane protocols that run on this) should
> > not result in
> > > failures of the customer traffic data-plane where such
> > trails are permanent
> > > or semi-permanent (this is more obvious in the GMPLS case).
> > >
> > > The Ping draft either does not address or fails to meet
> > many of these
> > > requirements.  More specifically:
> > > -       it does not identify/specify any defects;
> > > -       it cannot detect any defects unless it is running
> > continuously;
> > > -       it could not detect or diagnose all potential
> > defects even if
> > > running continously, eg mismerging defects;
> > > -       it relies on both cross-layer (ie ICMP is a IP
> > layer OAM mechanism)
> > > and cross-plane (ie it is only defined for the RSVP-TE
> > case) functional
> > > dependancies.  Although this expediency may have some
> > near-term benefit(?)
> > > it is not good arch practice.
> > > -       since defects are not detected/defined it is
> > unclear (i) what
> > > consequent actions are to be taken to protect customer
> > traffic (none it
> > > seems), (ii) how this will help operators target diagnostic
> > activities or
> > > (iii) how it will prevent client layer alarm storms.
> > > -       its all very well having variable behaviour (wrt
> > timers) but this
> > > will create complexities elsewhere, ie inconsistent
> > entry/exit criteria for
> > > defects and  availability states, no clear/consistent
> > datums for when QoS
> > > metrics collection (if being measured) are valid, ie when
> > to start/stop QoS
> > > metric aggregation.  So this means complexities in SLA derivations.
> > >
> > > So, whilst I would certainly not want to stop any vendor
> > implementing this
> > > draft, as an operator with responsibilities for the integrity of my
> > > customers traffic and a need to define SLAs for such, I find it
> > > professionally very difficult to condone it becoming a 'standard'.
> > >
> > > >
> > > > > Secondly, can we have some
> > > > > input/justification with regards to the assumption that
> > there is a
> > > > > need to detect such a failure since only cause for such
> > a failure
> > > > > given in the draft is "memory Corruption". What causes so called
> > > > > memory corruption? Are we trying to repair badly
> > written code here?
> > > > >
> > > >
> > > > The problem did happen in the real network. I'm not going to point
> > > > fingers on the cause of the problem. But we (vendors and
> > > > providers) did
> > > > realize from that incidence that we need to have a simple
> > mechanism to
> > > > check LSP's data plane in today's operational networks.
> > > NH=> Some time ago I was hearing comments such as 'these
> > defects won't
> > > happen' and 'don't fix software bugs with additional
> > software' (an erroneous
> > > argument anyway).  So having now establised that defects do
> > exist, I fully
> > > agree we need some way of detecting/diagnosing such
> > defects.  But this seems
> > > not what is being advocated here, since the mechanism does not help
> > > operators to detect the defects in the first place.  To address the
> > > detection aspect some mechanism has to run continuously,
> > and a technique
> > > that is unidirectional would seem to be simpler/better than one that
> > > requires a return path.  At some point one needs to raise
> > an alarm and take
> > > other consequent actions (eg maybe even squelching customer
> > traffic if
> > > intergity/security could be being compromised, and stop any
> > QoS metric
> > > aggregation (if being used)) and raise a vertical
> > indication to the NMS...so
> > > what better place to do this than at the point where the
> > defect is being
> > > initially detected, ie the LSP sink?
> > >
> > > Given all this, could those advocating the Ping draft
> > please explain what is
> > > actually wrong with the more comprehensive solution we
> > orginally proposed
> > > (in draft-harrison-mpls-oam-00.txt).....and in particular,
> > the use of the CV
> > > flow.....which is really nothing more than a keepalive
> > running from soure to
> > > sink with a unique source identifier and deterministic
> > behaviour....surely
> > > it can't be much simpler than this can it?
> > > >
> > > > The whole purpose on various proposals (fast reroute,
> > graceful restart
> > > > and LSP-ping) is to make the whole network working nicely,
> > > > even when we
> > > > have routers from other vendors that have badly written code.
> > > >
> > > > - Ping
> > > >
> >



From owner-mpls@UU.NET  Sun Aug  5 05:17:50 2001
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 FAA10782
	for <mpls-archive@lists.ietf.org>; Sun, 5 Aug 2001 05:17:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlasz07790;
	Sun, 5 Aug 2001 09:18:17 GMT
Received: by mail-control.mail.uu.net 
	id QQlasz01218
	for mpls-outgoing; Sun, 5 Aug 2001 09:17:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlasz01207
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 09:17:22 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 QQlasz24965
	for <mpls@UU.NET>; Sun, 5 Aug 2001 09:16:27 GMT
From: neil.2.harrison@bt.com
Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29])
	id QQlasz05869
	for <mpls@UU.NET>; Sun, 5 Aug 2001 09:16:26 GMT
Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP;
          Sun, 5 Aug 2001 10:15:52 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) 
          id <QGFY7W8B>; Sun, 5 Aug 2001 10:15:50 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E8915A2@mbddmknt01.hc.bt.com>
To: raszuk@cisco.com
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Sun, 5 Aug 2001 10:15:45 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Robert....many thanks for swift turn-round response.  Have tried to
answer below (and snipped at end to shorten).

Regards, Neil

 
> A few follow up questions ...
> 
> 1.
> 
> >    The node in the layer network, which first detects a 
> defect (sourced 
> >    from within that layer), should apply a well-known 
> 'Forward Defect 
> 
> >    (1)  There should be a complimentary Backward Defect Indication 
> 
> If FDIs & BDIs are optional I think you should s/should/may/. On the
> other hand I think that those msg are costly in cpu but very usefull
> (especially in the diagnostic case). Making them optional 
> really changes
> the understanding of your draft.
NH=> I agree.....IMO FDI and BDI should be indicated as optional (esp in
intra-domain case *if* there is a decent NMS in place).    
> 2. 
> 
> Reg item 5.7 
> 
> ...
> 
> >    It is therefore required that a unique trail source 
> identifier be 
> >    periodically transmitted from the trail source to the 
> trail sink to 
> >    detect these types of defect. 
> 
> > But, why should you always want to tell the head-end?  If
> > you want to invoke prot-sw in a non 1+1 case from the head 
> end then yes you
> > would want some return information, but the absolute 
> minimum requirement is
> > (i) to detect all failures at the sink and (ii) to take appropriate
> > consequent actions at that point, eg raise a failure 
> indication at the sink
> > point, stop QoS agggretaion, etc. 
> 
> Here we seems to quite disagree. IMHO source needs to know about given
> LSP failure to take corective action and not the sink. Rasing failure
> indication at the sink and counting for either an offline 
> tool action or
> even worse human action to fix it is way too slow. 
> 
> If the LSP is broken source should immediately either shut 
> given LSP or
> switch the traffic to another path (if past protection is applied).
NH=> Well in principle I agree for *those* LSPs which require some form of
protection and that don't use 1+1 case.  However, any scheme requires that
one can detect the failure in the 1st place....so this does imply a
continuous detection process, and the Ping draft does not adequately address
this, nor does it cater for the mismerging case.  So even if we were to use
a control-plane technique to return the information (instead of BDI in a
returned data-plane sense, or via some OOB management-plane) we need to be
clear of about the independent integrity of the outgoing/return directions.
Note - In order to be sure one can differentiate outgoing/return status in
the Ping draft one needs to ensure diversity of the data-plane of both
directions (and in case of return direction, I am talking about the
data-plane aspect of the control-plane here....since even a control-plane
must have some data-plane).  Its not at all clear to me how practically one
can achieve this....especially if ownership of the duct network is under
some other domain, ie leased L1 capacity.  Something to think about
perhaps....though this can be generalised to more than the Ping draft, and
which is why it is usually important to sure make the data-plane of the
control-plane (or management-plane) only takes its survivability cues from
the duct network.
> 
> > Further, the Ping draft only seems
> > > to address simple breaks in connectivity (though it does 
> not even detect
> > > these, which is a primary requirement, and appears to 
> rely on customers to
> > > complain...which I would argue is unaccetable).
> 
> I will either let Ping address this or we can talk live ....
NH=> Let's discuss next week.  But as noted above, if you really want to
have fast restoration, you need proper defect detection....so this implies
some form of continuous conectivity verification in place for all cases.
> 
> Rgs,
> Robert
> 
> PS. It would be probably easier to get together next week and discuss
> this face to face. I will send an offline mail reg this.
NH=> Fine and thanks....hopefully we can now start to home in a mutually
satisfactory solution.


From owner-mpls@UU.NET  Sun Aug  5 05:50:12 2001
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 FAA11258
	for <mpls-archive@lists.ietf.org>; Sun, 5 Aug 2001 05:50:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlatb18774;
	Sun, 5 Aug 2001 09:50:29 GMT
Received: by mail-control.mail.uu.net 
	id QQlatb03785
	for mpls-outgoing; Sun, 5 Aug 2001 09:49:58 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlatb03770
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 09:49: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 QQlatb12709
	for <mpls@uu.net>; Sun, 5 Aug 2001 09:49:24 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlatb05456
	for <mpls@uu.net>; Sun, 5 Aug 2001 09:49:24 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA08902 for mpls@uu.net; Sun, 5 Aug 2001 05:49:22 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlatb03687
	for <mpls@mail-control.mail.uu.net>; Sun, 5 Aug 2001 09:48:46 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 QQlatb28579
	for <mpls@UU.NET>; Sun, 5 Aug 2001 09:47:43 GMT
Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlatb03231
	for <mpls@UU.NET>; Sun, 5 Aug 2001 09:47:43 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f759joJ08881;
	Sun, 5 Aug 2001 02:45:50 -0700 (PDT)
Received: from cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f759lZc21919;
	Sun, 5 Aug 2001 02:47:35 -0700 (PDT)
Message-ID: <3B6D15B6.8866B4AB@cisco.com>
Date: Sun, 05 Aug 2001 02:45:26 -0700
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: neil.2.harrison@bt.com
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
References: <B9571FDEBD3DD21181E500606DD5EE050E8915A2@mbddmknt01.hc.bt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Neil,

> one can detect the failure in the 1st place....so this does imply a
> continuous detection process, 

Agree !

> and the Ping draft does not adequately address
> this, 

Why not ? The continutiy of detection is provided by a continues regular
ICMP msg on all tested LSPs.

> nor does it cater for the mismerging case.

Yes, but I believe that this is due to the preference of the least cpu
consumption as much as possible. It is not so rear that icmp can be even
processedon the line cards these days. Dealing with mpls deployments for
a last few years I have never seen a mismerged LSP ;). Broken -- yes but
not mismerged. So I am not sure how important that case is.

> Note - In order to be sure one can differentiate outgoing/return status in
> the Ping draft one needs to ensure diversity of the data-plane of both
> directions (and in case of return direction, I am talking about the
> data-plane aspect of the control-plane here....since even a control-plane
> must have some data-plane).

That is in fact the good trick of ping's draft :). As the LSP under test
is up (the LSP-ping packets has arrived at the tail/sink of an LSP and
intial ICMP failed) the failure is in the return data path somewhere
from tail to head. So if the LSP is up the path taken by RSVP RESV msg
must be up. Therefor appending the LSP_ECHO object into the RESV msg for
me seems as a quite clever way of making sure that the head will be
notified of successful delivery of LSP-ping to the tail and therefor
about OK condition for the LSP.

> NH=> Fine and thanks....hopefully we can now start to home in a mutually
> satisfactory solution.

Would be too great to happen ! My goal would be to at least understand
well all of the proposals on the plate ;).

R.


> neil.2.harrison@bt.com wrote:
> 
> Hi Robert....many thanks for swift turn-round response.  Have tried to
> answer below (and snipped at end to shorten).
> 
> Regards, Neil
> 
> 
> > A few follow up questions ...
> >
> > 1.
> >
> > >    The node in the layer network, which first detects a
> > defect (sourced
> > >    from within that layer), should apply a well-known
> > 'Forward Defect
> >
> > >    (1)  There should be a complimentary Backward Defect Indication
> >
> > If FDIs & BDIs are optional I think you should s/should/may/. On the
> > other hand I think that those msg are costly in cpu but very usefull
> > (especially in the diagnostic case). Making them optional
> > really changes
> > the understanding of your draft.
> NH=> I agree.....IMO FDI and BDI should be indicated as optional (esp in
> intra-domain case *if* there is a decent NMS in place).
> > 2.
> >
> > Reg item 5.7
> >
> > ...
> >
> > >    It is therefore required that a unique trail source
> > identifier be
> > >    periodically transmitted from the trail source to the
> > trail sink to
> > >    detect these types of defect.
> >
> > > But, why should you always want to tell the head-end?  If
> > > you want to invoke prot-sw in a non 1+1 case from the head
> > end then yes you
> > > would want some return information, but the absolute
> > minimum requirement is
> > > (i) to detect all failures at the sink and (ii) to take appropriate
> > > consequent actions at that point, eg raise a failure
> > indication at the sink
> > > point, stop QoS agggretaion, etc.
> >
> > Here we seems to quite disagree. IMHO source needs to know about given
> > LSP failure to take corective action and not the sink. Rasing failure
> > indication at the sink and counting for either an offline
> > tool action or
> > even worse human action to fix it is way too slow.
> >
> > If the LSP is broken source should immediately either shut
> > given LSP or
> > switch the traffic to another path (if past protection is applied).
> NH=> Well in principle I agree for *those* LSPs which require some form of
> protection and that don't use 1+1 case.  However, any scheme requires that
> one can detect the failure in the 1st place....so this does imply a
> continuous detection process, and the Ping draft does not adequately address
> this, nor does it cater for the mismerging case.  So even if we were to use
> a control-plane technique to return the information (instead of BDI in a
> returned data-plane sense, or via some OOB management-plane) we need to be
> clear of about the independent integrity of the outgoing/return directions.
> Note - In order to be sure one can differentiate outgoing/return status in
> the Ping draft one needs to ensure diversity of the data-plane of both
> directions (and in case of return direction, I am talking about the
> data-plane aspect of the control-plane here....since even a control-plane
> must have some data-plane).  Its not at all clear to me how practically one
> can achieve this....especially if ownership of the duct network is under
> some other domain, ie leased L1 capacity.  Something to think about
> perhaps....though this can be generalised to more than the Ping draft, and
> which is why it is usually important to sure make the data-plane of the
> control-plane (or management-plane) only takes its survivability cues from
> the duct network.
> >
> > > Further, the Ping draft only seems
> > > > to address simple breaks in connectivity (though it does
> > not even detect
> > > > these, which is a primary requirement, and appears to
> > rely on customers to
> > > > complain...which I would argue is unaccetable).
> >
> > I will either let Ping address this or we can talk live ....
> NH=> Let's discuss next week.  But as noted above, if you really want to
> have fast restoration, you need proper defect detection....so this implies
> some form of continuous conectivity verification in place for all cases.
> >
> > Rgs,
> > Robert
> >
> > PS. It would be probably easier to get together next week and discuss
> > this face to face. I will send an offline mail reg this.
> NH=> Fine and thanks....hopefully we can now start to home in a mutually
> satisfactory solution.



From owner-mpls@UU.NET  Mon Aug  6 02:34:36 2001
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 CAA17780
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 02:34:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlawg24775;
	Mon, 6 Aug 2001 06:34:58 GMT
Received: by mail-control.mail.uu.net 
	id QQlawg28909
	for mpls-outgoing; Mon, 6 Aug 2001 06:34:27 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlawg28904
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 06:34: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 QQlawg05033
	for <mpls@UU.NET>; Mon, 6 Aug 2001 06:33:47 GMT
From: neil.2.harrison@bt.com
Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82])
	id QQlawg22864
	for <mpls@UU.NET>; Mon, 6 Aug 2001 06:33:46 GMT
Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP;
          Mon, 6 Aug 2001 07:31:05 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) 
          id <QGFY8A0G>; Mon, 6 Aug 2001 07:30:57 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E8915A6@mbddmknt01.hc.bt.com>
To: raszuk@cisco.com
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Mon, 6 Aug 2001 07:30:43 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello Robert....
> > one can detect the failure in the 1st place....so this does imply a
> > continuous detection process, 
> 
> Agree !
NH=> Good....at least we have 1 item of common ground now.
> 
> > and the Ping draft does not adequately address
> > this, 
> 
> Why not ? The continutiy of detection is provided by a 
> continues regular
> ICMP msg on all tested LSPs.
NH=> You should speak to my operational people about how much they love ICMP
as a detection/diagnostics tool even for IP......I'll introduce you to one
this week at IETF.  We wanted something much better for MPLS.  BTW - ICMP is
an IP layer OAM function.  If I extrapolate this cross-layer use of OAM
notion I could use any cient layer to detect defects on any server layer
(plenty of combinations possible here).  Point is this is not a correct arch
approach...I mean are you now going to say to the the people who manage OTNs
that fault detection starts with ICMP/IP then MPLS then SDH then OTN (say
using some combination of G.709 and/or LMP)?  Further, the client and server
layers can be owned by different domains operators/customers.....and it is
simply bad practice to expect to use a client layer OAM function to fault
manage a server layer network.
> 
> > nor does it cater for the mismerging case.
> 
> Yes, but I believe that this is due to the preference of the least cpu
> consumption as much as possible. It is not so rear that icmp 
> can be even
> processedon the line cards these days. Dealing with mpls 
> deployments for
> a last few years I have never seen a mismerged LSP ;).
NH=> Well if you can't detect it this is hardly surprising is it?  I have
already heard about cases of misdelivered VPN traffic.  Misconfigurations
(via human or HW/SW faults/bugs) of swapped/misbranching traffic have
happened in other technologies and they will happen again.  If we can find a
reasonably simply way to protect/detect/handle these events we should do so
now.....its harder to go back later and fix things. 

Broken 
> -- yes but
> not mismerged. So I am not sure how important that case is.
> 
> > Note - In order to be sure one can differentiate 
> outgoing/return status in
> > the Ping draft one needs to ensure diversity of the 
> data-plane of both
> > directions (and in case of return direction, I am talking about the
> > data-plane aspect of the control-plane here....since even a 
> control-plane
> > must have some data-plane).
> 
> That is in fact the good trick of ping's draft :). As the LSP 
> under test
> is up (the LSP-ping packets has arrived at the tail/sink of an LSP and
> intial ICMP failed) the failure is in the return data path somewhere
> from tail to head. So if the LSP is up the path taken by RSVP RESV msg
> must be up. Therefor appending the LSP_ECHO object into the 
> RESV msg for
> me seems as a quite clever way of making sure that the head will be
> notified of successful delivery of LSP-ping to the tail and therefor
> about OK condition for the LSP.
NH=> Having only just returned for a couple of weeks leave I have not had
time to properly discuss with colleagues here all possible scenarios.......I
saw some of the questions from Shahram last week on the list and maybe we
can also discuss further this week.  What I was saying above is that it
could be highly likely that both LSP directions fail together (and I am not
sure whether ICMP could be returned or not here under all cases) or perhaps
just the return LSP direction fails (for whatever reason, be this a
data-plane or control-plane (ie SW) misfunction)......so how are these
differentiated?  Seems in latter case outgoing LSPs have not failed and
should not be taken down, whereas in former case they have and should
be....we need to differentiate these cases wrt to appropriate consequent
actions.  However, I remain to be convinced that the scheme works correctly
under all defect cases. 
> 
> > NH=> Fine and thanks....hopefully we can now start to home 
> in a mutually
> > satisfactory solution.
> 
> Would be too great to happen ! My goal would be to at least understand
> well all of the proposals on the plate ;).
NH=> My goal too......and its clear from the questions I have seen raised
that people don't fully grasp all the nuances yet.  IMO a significant
problem here is (i) lack of agreed problem statement, (ii) (stemming from)
insufficient operator input on exactly what is required and (iii)
insufficient/poor and explanations in drafts.  Hopefully see you later this
morning.  Regards, Neil


From owner-mpls@UU.NET  Mon Aug  6 06:03:40 2001
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 GAA20658
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 06:03:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlawu08536;
	Mon, 6 Aug 2001 10:04:02 GMT
Received: by mail-control.mail.uu.net 
	id QQlawu24126
	for mpls-outgoing; Mon, 6 Aug 2001 10:03:33 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlawu24121
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 10:03:27 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 QQlawu20137
	for <mpls@UU.NET>; Mon, 6 Aug 2001 10:03:13 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlawu15737
	for <mpls@UU.NET>; Mon, 6 Aug 2001 10:03:10 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QLZNW1TT>; Mon, 6 Aug 2001 15:30:37 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6861@mailserver.netbrahma.com>
From: Manoj Agiwal <ManojA@netbrahma.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Cc: "'rsvp@isi.edu'" <rsvp@isi.edu>
Subject: RSVP-TE messages .
Date: Mon, 6 Aug 2001 15:30:36 +0530 
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 ,
       What does RSVP-TE  PATH messages send from ingress to egress contains
in the destination address fields of the IP Header ? Is it the address of (
Egress ) Session IP address .

       What will happen in case of ERO object when object is going    
hop by hop . Will it still contain the destination IP address .
Regards ,
Manoj
 


From owner-mpls@UU.NET  Mon Aug  6 09:35:35 2001
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 JAA23083
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 09:35:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxi22817;
	Mon, 6 Aug 2001 13:35:45 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxi18462
	for mpls-outgoing; Mon, 6 Aug 2001 13:35:13 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaxi18445
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 13:35:07 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 QQlaxi20610
	for <mpls@uu.net>; Mon, 6 Aug 2001 13:35:00 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlaxi21670
	for <mpls@uu.net>; Mon, 6 Aug 2001 13:34:59 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA01732
	for <mpls@uu.net>; Mon, 6 Aug 2001 09:34:59 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07071 for mpls@uu.net; Mon, 6 Aug 2001 09:34:42 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlard11468
	for <mpls@mail-control.mail.uu.net>; Sat, 4 Aug 2001 21:27:46 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 QQlard21326
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:26:00 GMT
Received: from web20209.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20209.mail.yahoo.com [216.136.226.64])
	id QQlard11018
	for <mpls@UU.NET>; Sat, 4 Aug 2001 21:26:00 GMT
Message-ID: <20010804212559.87379.qmail@web20209.mail.yahoo.com>
Received: from [128.96.52.65] by web20209.mail.yahoo.com; Sat, 04 Aug 2001 14:25:59 PDT
Date: Sat, 4 Aug 2001 14:25:59 -0700 (PDT)
From: rsvp te <rsvpt@yahoo.com>
Subject: unknown clas/type number
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I sent Resv msg with Unknown class 127(01111111) in
session field to ingress LSR, but LSR does not send me
the ResvErr error msg back.  So I was wondering if the
127 is unknown class number or not.

Also what is the unknown type number mentioned in the
rsvp msg?

Thanks in advance.




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Mon Aug  6 09:36:22 2001
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 JAA23109
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 09:36:22 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxi25009;
	Mon, 6 Aug 2001 13:36:53 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxi18467
	for mpls-outgoing; Mon, 6 Aug 2001 13:35:20 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaxi18375
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 13:34:54 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 QQlaxi09115
	for <mpls@uu.net>; Mon, 6 Aug 2001 13:34:29 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlaxi20949
	for <mpls@uu.net>; Mon, 6 Aug 2001 13:34:28 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 JAA10996 for <mpls@uu.net>; Mon, 6 Aug 2001 09:34:28 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07065 for mpls@uu.net; Mon, 6 Aug 2001 09:34:11 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlana15432
	for <mpls@mail-control.mail.uu.net>; Fri, 3 Aug 2001 18:41:53 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 QQlana20637
	for <mpls@UU.NET>; Fri, 3 Aug 2001 18:41:42 GMT
Received: from ray.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQlana17030
	for <mpls@UU.NET>; Fri, 3 Aug 2001 18:41:36 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f73IerR06236;
	Fri, 3 Aug 2001 11:41:02 -0700
Date: Fri, 3 Aug 2001 11:40:53 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: <Tim.Jackson@TeraBeam.com>
cc: <mpls@UU.NET>
Subject: Re: RSVP-TE: ERO question
In-Reply-To: <F03A5CDD25F1D411BE6C00508BAFACB201DC6BEC@tera-email.terabeam.com>
Message-ID: <Pine.LNX.4.33.0108031138320.3139-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


>
> I haven't seen reference to the following in any archives, so I hope someone
> can shed some light on this for me.
>
> Section 3.1.5 of RFC2205 (RSVP V1) stipulates the following: "A PathTear
> message must be routed exactly like the corresponding Path message."
>
> Given that the RSVP-TE draft defines the EXPLICT_ROUTE object (ERO) that can
> effectively circumvent the active route from any given node to the session
> DestAddress and, moreover, that the ERO is applicable to the Path message
> exclusively (see section 3 of the RSVP-TE draft), it follows that, if an ERO
> is employed, a PathTear message may follow a different path than the
> corresponding Path message.
> Is this not a conflict?
>
> Tim Jackson
> Terabeam
>
Tim,

I think the PathTear will take the same route, because all the routers
already have the PSBs(Path State Block) installed, they should know where
to send out the PathTear message.

Ray



From owner-mpls@UU.NET  Mon Aug  6 10:09:20 2001
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 KAA23695
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 10:09:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxk11076;
	Mon, 6 Aug 2001 14:08:15 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxk03661
	for mpls-outgoing; Mon, 6 Aug 2001 14:07:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlaxk03338
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 14:07:35 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 QQlaxk20332
	for <mpls@UU.NET>; Mon, 6 Aug 2001 14:04:43 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 QQlaxk05669
	for <mpls@UU.NET>; Mon, 6 Aug 2001 14:04:42 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 KAA18385;
	Mon, 6 Aug 2001 10:04:34 -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 KAA12525;
	Mon, 6 Aug 2001 10:04:34 -0400 (EDT)
Message-ID: <3B6EA400.204869C2@marconi.com>
Date: Mon, 06 Aug 2001 10:04:48 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
CC: "'mpls@UU.NET'" <mpls@UU.NET>, "'rsvp@isi.edu'" <rsvp@isi.edu>
Subject: Re: RSVP-TE messages .
References: <13D467F625FAD511AE2A00D0B7B917D71E6861@mailserver.netbrahma.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Manoj Agiwal wrote:
> 
>        What does RSVP-TE  PATH messages send from ingress to egress
> contains in the destination address fields of the IP Header ? Is it
> the address of ( Egress ) Session IP address .

Yes.  It contains the session address (egress router's address).  Router
alert is set to prevent it from being forwarded by RSVP-aware routers.

>        What will happen in case of ERO object when object is going
> hop by hop . Will it still contain the destination IP address .

The destination address doesn't change.  The ERO overrides the routing
table when determining the next-hop.  It does not change the packet's
encapsulation.

-- David


From owner-mpls@UU.NET  Mon Aug  6 10:50:41 2001
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 KAA24565
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 10:50:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxn11688;
	Mon, 6 Aug 2001 14:51:01 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxn16737
	for mpls-outgoing; Mon, 6 Aug 2001 14:50:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaxn16708
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 14:50:16 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 QQlaxn29521
	for <mpls@uu.net>; Mon, 6 Aug 2001 14:48:48 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlaxn20791
	for <mpls@uu.net>; Mon, 6 Aug 2001 14:48:48 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 KAA20681 for <mpls@uu.net>; Mon, 6 Aug 2001 10:48:48 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07620 for mpls@uu.net; Mon, 6 Aug 2001 10:48:30 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaxn16367
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 14:46:30 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 QQlaxn13175
	for <mpls@UU.NET>; Mon, 6 Aug 2001 14:45:56 GMT
Received: from web20202.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20202.mail.yahoo.com [216.136.226.57])
	id QQlaxn05396
	for <mpls@UU.NET>; Mon, 6 Aug 2001 14:45:55 GMT
Message-ID: <20010806144555.28662.qmail@web20202.mail.yahoo.com>
Received: from [128.96.54.189] by web20202.mail.yahoo.com; Mon, 06 Aug 2001 07:45:55 PDT
Date: Mon, 6 Aug 2001 07:45:55 -0700 (PDT)
From: rsvp te <rsvpt@yahoo.com>
Subject: trigger PathTear msge sent out
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Is there anyway to let Egress to trigger Ingress to
send out PathTear msg?

As I know, there are one way to let Ingress to send
out PahtTear msg, one is to delete LSP from Ingress
router itself, and after a path state timeout from
this router, the Ingress router will send out PahtTear
msg out.

Is there any ResvErr msg from Egress which can trigger
Ingress to send out PathTear msg?

Thanks in advance.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Mon Aug  6 11:03:19 2001
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 LAA25001
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 11:03:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxo29946;
	Mon, 6 Aug 2001 15:02:07 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxo21168
	for mpls-outgoing; Mon, 6 Aug 2001 15:01:34 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlaxo21134
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 15:01:31 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 QQlaxo29392
	for <mpls@UU.NET>; Mon, 6 Aug 2001 15:01:24 GMT
Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQlaxo02396
	for <mpls@UU.NET>; Mon, 6 Aug 2001 15:01:22 GMT
Received: from mail1.tellium.com (mail1 [151.198.92.140])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f76EvjA26051;
	Mon, 6 Aug 2001 10:57:45 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <QG2FP6SJ>; Mon, 6 Aug 2001 11:00:49 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D022040402088946@mail1.tellium.com>
From: Hang Liu <hliu@tellium.com>
To: Bala Rajagopalan <BRaja@tellium.com>,
        "'kireeti@juniper.net'"
	 <kireeti@juniper.net>
Cc: "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>,
        "'mpls@UU.NET'"
	 <mpls@UU.NET>
Subject: unnumbered links/control channel separation in GMPLS signaling
Date: Mon, 6 Aug 2001 11:00:43 -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

Hi. Bala and Kireeti,

By going over the new gmpls drafts and other two related drafts about
unnumbered links and link bundles, draft-kompella-mpls-bundle-05.txt and
draft-ietf-mpls-rsvp-unnum-01.txt, I have several questions and hope you can
help me to clarify them.

(1)	In draft-ietf-mpls-generalized-rsvp-te-04.txt, section 8.1 defines
IF_ID RSVP_HOP object that includes IF_ID TLV. It does not mention how to
include IF_ID TLV in the ERO. Can I assume that IF_ID TLV can be put into
ERO to replace normal explicit node/interface ID by the ingress node? The
receiving node checks the initial subobject in the ERO to determine the
outgoing link. If the receiving node is an intermediate node, it should copy
the IF_ID TLV from the initial ERO subobject to the new IF_ID RSVP_HOP. This
new IF_ID RSVP_HOP will be contained in the outgoing Path message to the
next hop. Note that the initial subobject is removed from the ERO before the
Path message is sent to next hop. 
(2)	For unnumbered bundled links, the IF_ID in the ERO should be the
IF_ID of this bundled link. If the bi-directional LSP is requested, both
upstream IF_ID and downstream IF_ID will be included in ERO. Upstream IF_ID
and downstream IF_ID may not be one-to-one mapping. However only one IF_ID
TLV (IF_INDEX) is defined in section 9.1.1,
draft-ietf-mpls-generalized-signaling-05.txt. Do we need to define a
separate downstream IF_ID TLV and an upstream IF_ID TLV? This applies to the
case of any unnumbered links/link bundles without upstream and downstream
one-to-one mapping.

Thank you very much.

Hang Liu
Tellium, Inc



From owner-mpls@UU.NET  Mon Aug  6 13:34:58 2001
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 NAA28213
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 13:34:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaxy28652;
	Mon, 6 Aug 2001 17:34:42 GMT
Received: by mail-control.mail.uu.net 
	id QQlaxy29670
	for mpls-outgoing; Mon, 6 Aug 2001 17:34:09 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlaxy29657
	for <mpls@mail-control.mail.uu.net>; Mon, 6 Aug 2001 17:33:54 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 QQlaxy07468
	for <mpls@UU.NET>; Mon, 6 Aug 2001 17:33:14 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.129.242.157])
	id QQlaxy16215
	for <mpls@UU.NET>; Mon, 6 Aug 2001 17:33:13 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f76HWl906743
	for <mpls@UU.NET>; Mon, 6 Aug 2001 13:32:47 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 6 Aug 2001 13:32:31 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSG5MX>; Mon, 6 Aug 2001 13:32:33 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD341FD779@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: a-iwata@ah.jp.nec.com, "'mpls@UU.NET'" <mpls@UU.NET>
Subject: draft-iwata-mpls-shared-fast-reroute-00
Date: Mon, 6 Aug 2001 13:32:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11E9D.C3177E00"
X-Orig: <dallan@americasm01.nt.com>
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_01C11E9D.C3177E00
Content-Type: text/plain;
	charset="iso-8859-1"

A simple question (which I did not get a chance to ask in the meeting
today):

When the "Backup LSP trigger" message is issued up the primary path, should
it not also contain an ERO object for the primary path as well as the first
backup route.

Seems to me I should care a whole lot about the tributaries to the shared
backup being diverse with the primary path. (I'll call them tributaries as I
couldn't find a specific term for them). Right now I do not think I can make
that statement unless every LSR in the primary path retains ERO information
(in order to verify this when performing the shared path computation), and
it would not currently (IMHO) have reason to do so.  So my shared path
computation becomes, "shortest path to the first backup LSP that is route
diverse with the primary LSP".

This is really a separate issue from the suggestion that there is no shared
path computation required, and the backup LSP from any LSR in the primary
path simply be opportunistic in merging with any other backup paths for the
same LSP encountered along the optimal backup route. This would appear to
have the same effect as constantly updating the ERO propagated with the
"backup LSP trigger" after the establishment of each backup tributary.

BTW, I'm inclined to note that if there is any resource committment
associated with these LSPs, it makes 1+1 look positively frugal. Perhaps we
could invest some effort in fault propagation efficiency and save a whole
lot of bandwidth....

cheers
Dave

------_=_NextPart_001_01C11E9D.C3177E00
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.2654.89">
<TITLE>draft-iwata-mpls-shared-fast-reroute-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A simple question (which I did not get a chance to =
ask in the meeting today):</FONT>
</P>

<P><FONT SIZE=3D2>When the &quot;Backup LSP trigger&quot; message is =
issued up the primary path, should it not also contain an ERO object =
for the primary path as well as the first backup route.</FONT></P>

<P><FONT SIZE=3D2>Seems to me I should care a whole lot about the =
tributaries to the shared backup being diverse with the primary path. =
(I'll call them tributaries as I couldn't find a specific term for =
them). Right now I do not think I can make that statement unless every =
LSR in the primary path retains ERO information (in order to verify =
this when performing the shared path computation), and it would not =
currently (IMHO) have reason to do so.&nbsp; So my shared path =
computation becomes, &quot;shortest path to the first backup LSP that =
is route diverse with the primary LSP&quot;.</FONT></P>

<P><FONT SIZE=3D2>This is really a separate issue from the suggestion =
that there is no shared path computation required, and the backup LSP =
from any LSR in the primary path simply be opportunistic in merging =
with any other backup paths for the same LSP encountered along the =
optimal backup route. This would appear to have the same effect as =
constantly updating the ERO propagated with the &quot;backup LSP =
trigger&quot; after the establishment of each backup =
tributary.</FONT></P>

<P><FONT SIZE=3D2>BTW, I'm inclined to note that if there is any =
resource committment associated with these LSPs, it makes 1+1 look =
positively frugal. Perhaps we could invest some effort in fault =
propagation efficiency and save a whole lot of bandwidth....</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11E9D.C3177E00--


From owner-mpls@UU.NET  Mon Aug  6 21:34:01 2001
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 VAA05660
	for <mpls-archive@lists.ietf.org>; Mon, 6 Aug 2001 21:34:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlaze07747;
	Tue, 7 Aug 2001 01:33:34 GMT
Received: by mail-control.mail.uu.net 
	id QQlaze15128
	for mpls-outgoing; Tue, 7 Aug 2001 01:33:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaze15120
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 01:32:53 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 QQlaze25233
	for <mpls@uu.net>; Tue, 7 Aug 2001 01:32:13 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlaze05937
	for <mpls@uu.net>; Tue, 7 Aug 2001 01:32:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA22669 for mpls@uu.net; Mon, 6 Aug 2001 21:32:10 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlaze15036
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 01:31: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 QQlaze20638
	for <mpls@UU.NET>; Tue, 7 Aug 2001 01:30:31 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 QQlaze29659
	for <mpls@UU.NET>; Tue, 7 Aug 2001 01:30:31 GMT
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f771UTW26436
	for <mpls@UU.NET>; Mon, 6 Aug 2001 21:30:29 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id DAA00009; Tue, 7 Aug 2001 03:30:28 +0200 (MET DST)
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id DAA29985; Tue, 7 Aug 2001 03:30:24 +0200 (MET DST)
Message-ID: <3B6F44AF.4ADB419B@lucent.com>
Date: Tue, 07 Aug 2001 03:30:23 +0200
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin Dubuc <martin.dubuc@edgeflow.com>
Original-CC: mpls@UU.NET, ccamp@ops.ietf.org
Subject: Re: Queries regarding LMP.
References: <E5A6D1B50FEDDF4ABE699DE2ECF57A8109424B@edgsvr04.edgeflow.edgeflow.com>
Content-Type: multipart/mixed;
 boundary="------------1482458F7B558D6517853310"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Martin,

Martin Dubuc wrote:
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).
> 

In an OTN network the fault isolation is provided by the transport plane; no
need for LMP here (at least this aspect). In the truly optical part of the OTN
there is OTS, OMS and OCh overhead to take care of fault isolation. And when
reaching a 3R point, the OTUk and ODUk overhead continue/perform this fault
isolation role.

Same is true for SDH/SONET networks; no need for fault isolation within LMP.

So in my opinion this fault isolation aspect in LMP is limited to pre-OTN
networks.

Regards,

Maarten
--------------1482458F7B558D6517853310
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

--------------1482458F7B558D6517853310--



From owner-mpls@UU.NET  Tue Aug  7 00:58:31 2001
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 AAA09580
	for <mpls-archive@lists.ietf.org>; Tue, 7 Aug 2001 00:58:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlazr06038;
	Tue, 7 Aug 2001 04:58:10 GMT
Received: by mail-control.mail.uu.net 
	id QQlazr29626
	for mpls-outgoing; Tue, 7 Aug 2001 04:57:39 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlazr29618
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 04:57: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 QQlazr00888
	for <mpls@UU.NET>; Tue, 7 Aug 2001 04:57:21 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlazr04579
	for <mpls@UU.NET>; Tue, 7 Aug 2001 04:57:15 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QLZNWG1X>; Tue, 7 Aug 2001 10:24:41 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BAD0@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET
Subject: RE: Mapping of Traffic Parameters
Date: Tue, 7 Aug 2001 10:24:40 +0530 
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 , 

I would like to repeat my question on mapping of traffic parameters . I will
try to make it more clear since the context might not have been very clear
in my last mail on this . 
My question is based on mapping the fields in the TSpec object defined in
the Intserv RFC 2210 / 2211 as well as in the RSVP RFC 2205 to the
parameters in the mplsTunnelResourceTable in draft-ietf-mpls-te-mib-06.txt .
This is necessary since after this table is filled through SNMP or other
means , the values in this table have to be interpreted and put in the RSVP
Sender TSpec object at the ingress. 
How has this been resolved in existing solutions ??

> The Tspec object is used to indicate the requirements of a flow to the
> Intserv layer which does the actual reservation in IntServ.
> 
> This consists of :
> Token Bucket Rate [r]
> Token Bucket Size [b]    
> Peak Data Rate    [p] 
> Minimum Policed Unit [m] 
> Maximum Packet Size [M]
> The first three parameters should be mapped to the following parameters in
> the mplsTunnelResourceTable:
> mplsTunnelResourceMeanRate :        Token Bucket Rate [r]
> mplsTunnelResourceMeanBurstSize:  Token Bucket Size [b]    
> mplsTunnelResourceMaxRate:           Peak Data Rate    [p] 
	Is this assumption correct ??

> And how are the values of m and M deduced at the ingress??
>  ( There does not seem to be any corresponding values in the Resource
> table and these
> parameters might be important to police individual flows )
> 
Hope that my question is clearer now,
Thanks,
Apratim.



From owner-mpls@UU.NET  Tue Aug  7 03:35:23 2001
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 DAA27156
	for <mpls-archive@lists.ietf.org>; Tue, 7 Aug 2001 03:35:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbac03660;
	Tue, 7 Aug 2001 07:34:56 GMT
Received: by mail-control.mail.uu.net 
	id QQlbac09980
	for mpls-outgoing; Tue, 7 Aug 2001 07:34:23 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlbac09972
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 07:34:16 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 QQlbac07700
	for <mpls@UU.NET>; Tue, 7 Aug 2001 07:33:49 GMT
Received: from momotaro.labs.nec.co.jp by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: momotaro.labs.nec.co.jp [202.247.6.209])
	id QQlbac15426
	for <mpls@UU.NET>; Tue, 7 Aug 2001 07:33:48 GMT
Received: from iwata-pc2.nwk.cl.nec.co.jp by momotaro.labs.nec.co.jp (8.11.3/MOMO-010516) with ESMTP
	id f777XYM19696; Tue, 7 Aug 2001 16:33:35 +0900 (JST)
Message-Id: <4.3.2-J.20010807162047.00c9e3f0@momotaro.labs.nec.co.jp>
X-Sender: iwata@momotaro.labs.nec.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Tue, 07 Aug 2001 16:37:05 +0900
To: "David Allan" <dallan@nortelnetworks.com>
From: Atsushi Iwata <iwata@ccm.CL.nec.co.jp>
Subject: Re: draft-iwata-mpls-shared-fast-reroute-00
Cc: <mpls@UU.NET>, Norihito Fujita <n-fujita@ccm.CL.nec.co.jp>,
        Tetsuro Nishida <nishida@ipn.abk.nec.co.jp>
In-Reply-To: <3549C09B853DD5119B540002A52CDD341FD779@zcard0ka.ca.nortel.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

David,

Thank you for your comments.

At 13:32 01/08/06 -0400, David Allan wrote:

>A simple question (which I did not get a chance to ask in the meeting today): 
>
>When the "Backup LSP trigger" message is issued up the primary path, 
should it not also contain an ERO object for the primary path as well as 
the first backup route.

I see your point. I forgot to mention it on my presentation. 

Yes. We have to include the ERO object for the primary path as well for 
computing the disjoint path from this primary path.


>Seems to me I should care a whole lot about the tributaries to the shared 
backup being diverse with the primary path. (I'll call them tributaries as 
I couldn't find a specific term for them). Right now I do not think I can 
make that statement unless every LSR in the primary path retains ERO 
information (in order to verify this when performing the shared path 
computation), and it would not currently (IMHO) have reason to do so.  So 
my shared path computation becomes, "shortest path to the first backup LSP 
that is route diverse with the primary LSP".

I understand your concern. Even if we allow the primary path to retain the 
ERO information, there is a case where Path message for estabishing the 
primary only includes the loose source route information. In such a case, 
such a ERO information is not enough to compute the disjoint path from the 
primary path. Therefore, as I described above, we need to include the ERO 
object for the primary path in the Backup LSP Trigger message. 


>This is really a separate issue from the suggestion that there is no 
shared path computation required, and the backup LSP from any LSR in the 
primary path simply be opportunistic in merging with any other backup paths 
for the same LSP encountered along the optimal backup route. This would 
appear to have the same effect as constantly updating the ERO propagated 
with the "backup LSP trigger" after the establishment of each backup tributary.

Interesting to me. This might be an another option. We can reoptimize it by 
using such a soft state your proposed here.


>BTW, I'm inclined to note that if there is any resource committment 
associated with these LSPs, it makes 1+1 look positively frugal. Perhaps we 
could invest some effort in fault propagation efficiency and save a whole 
lot of bandwidth....

Good comment.

If we use 1+1, then we need to add another capability on my proposed share 
fast-reroute. On the merging point of shared backup path, we have to have a 
intelligent filtering which only forwards one of the the others to 
downstream node so that the data should not be replicated at the merging point. 

Thank you for your valuable comments. I'll reflect your comments in the 
future draft.

Best Regards,

----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Principal Researcher
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     a-iwata@ah.jp.nec.com
NEC-internal E-mail: iwata@ccm.CL.nec.co.jp

*** Organization has been a bit changed since Apr.2001 ***



From owner-mpls@UU.NET  Tue Aug  7 06:36:40 2001
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 GAA29767
	for <mpls-archive@lists.ietf.org>; Tue, 7 Aug 2001 06:36:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbao03968;
	Tue, 7 Aug 2001 10:35:40 GMT
Received: by mail-control.mail.uu.net 
	id QQlbao22639
	for mpls-outgoing; Tue, 7 Aug 2001 10:35:10 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbao22580
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 10:34:56 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 QQlbao12839
	for <mpls@uu.net>; Tue, 7 Aug 2001 10:34:37 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlbao09302
	for <mpls@uu.net>; Tue, 7 Aug 2001 10:34:36 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA12903 for mpls@uu.net; Tue, 7 Aug 2001 06:34:35 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbao22539
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 10:34:10 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 QQlbao15083
	for <mpls@UU.NET>; Tue, 7 Aug 2001 10:33:58 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 QQlbao08415
	for <mpls@UU.NET>; Tue, 7 Aug 2001 10:33:57 GMT
Received: (qmail 23300 invoked by uid 104); 7 Aug 2001 10:33:57 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.479094 secs); 07/08/2001 03:33:56
Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227)
  by father.pmc-sierra.bc.ca with SMTP; 7 Aug 2001 10:33:56 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f77AY3P05139;
	Tue, 7 Aug 2001 03:34:03 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <N6ALBHB9>; Tue, 7 Aug 2001 03:33:52 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6DE6@BBY1EXM01>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'raszuk@cisco.com'" <raszuk@cisco.com>, neil.2.harrison@bt.com
Cc: pingpan@juniper.net, Brijesh@coronanetworks.com, mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
Date: Tue, 7 Aug 2001 03:33:51 -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 Robert,

Since I got this message first, let me answer some of your concerns. I ma sure Neil has his own response too.

See below:

> -----Original Message-----
> From: Robert Raszuk [mailto:raszuk@cisco.com]
> Sent: Saturday, August 04, 2001 5:25 PM
> To: neil.2.harrison@bt.com
> Cc: pingpan@juniper.net; Brijesh@coronanetworks.com; mpls@UU.NET
> Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> 
> 
> Hi Neil,
> 
> > Given all this, could those advocating the Ping draft 
> please explain what is
> > actually wrong with the more comprehensive solution we 
> orginally proposed
> > (in draft-harrison-mpls-oam-00.txt).....
> 
> Let me try ...
> 
> First let me say that your draft seems to be architecturally perfect.
> Unfortunately in practice in may meet the following obstacles:
> 
> * It is very CPU intensive. It requires per each LSP continues
> processing of incomming CV packets in the transit nodes of 
> such an LSP.
> Imagine the case that you have 15000 of LSPs in a transit 
> node and each
> send you periodically a CV packet. (Ping's draft does not require any
> CPU work per transt LSP).

1) I think you probably have not read our draft carefully. CV packets are only revealed at the egress LSR of the LSP being tested. Therefore only ingress and egress LSR of the LSP under test require to process the CV (or MPLS OAM) packets. The intermediate (transit) LSR do not even see the OAM label, and therefore forward the CV packet as a normal MPLS packet.

2) In order to detect that a failure has occurred, and to take corrective actions, you MUST continuously run some kind of liveliness message. This is unavoidable, unless you wait for a customer to complain that he is not receiving his traffic, which is very slow and helps providers loose customers.

> 
> * In the failure detection situation I don't see how it guarantees the
> successful notification propagation the head. I can easily think of
> cases when your returning FDI or BDI signals get lost due to 
> some purly
> forwarding bugs. (Ping's draft uses a control channel for return which
> is working correctly).

FDI and BDI are not mandatory. They help you better handle a defect, but you could still detect and process a defect without using FDI/BDI. 

> * It requires 100% of software upgrade in all routes in a 
> given network
> (I am sure you realize quite a challange in large networks).

As I said at the beginning it only requires upgrade of the ingress and egress LSRs not all LSRs. Ping's proposal requires the same upgrade too.
 
> 
> * It requires simultaneous support from all vendors on a given network.
> (Is this realistic :) ?

This is true for Ping's proposal too. Ping's draft says : "Before initiating the liveliness test, the user must make sure that both ingress and egress LSR can support the LSR-ping."

> 
> * With all of the complications it does not seems to guarantee the
> detection of LDP LSPs failures - only TE LSPs failures. (Sure 
> Ping does
> not address this neither yet but is way much more simpler).

We have updated our proposal, and now it can support LDP LSPs too.

> 
> * I don't see in the Ping's draft any requirement for end 
> user = client
> action - to detect the LSP failure - since you have brought this
> argument a lot could you elaborate a bit where in his draft 
> you see such
> a need ?

Let me explain. The LSP-ping is only a diagnosis tool, not a failure detection tool. In other words after a failure has been detected (by other means), the LSP-ping can tell you whether this failure is due to forward LSP or reverse LSP. Now the question is which method detects whether a failure has occurred at the first place. The answer is not very clear from the Ping's draft. As far as I have understood there are probably two possibilities:

1) Wait for the customer to report that he is not receiving his traffic. or
2) Run continuous ICMP ping.

The first method is only acceptable to providers who like loosing customer. The second method is essentially the same as the CV flow that we proposed, because:

a) It runs continuously
b) In general it requires a reserved label (IPV4 explicit null)

But it has a major problem: "Layer violation"


Hope that helps.

Thanks,
-Shahram

> 
> Rgs,
> Robert
> 
> 
> > neil.2.harrison@bt.com wrote:
> > 
> > Ping wrote:
> > > Sent: 26 July 2001 01:22
> > > To: Brijesh Kumar
> > > Cc: mpls-list
> > > Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-01.txt]
> > >
> > >
> > > > Brijesh Kumar wrote:
> > > >
> > > > From this draft:
> > > >
> > > >    When the ingress LSR suspects that the LSP may have
> > > failed and the
> > > >    RSVP control plane shows the LSP as operational, the 
> ingress LSR
> > > > MUST
> > > >    send LSP-ping messages to the egress over the LSP, 
> periodically.
> > > > The
> > > >    value of the time interval should be configurable.
> > > >
> > > > Could you please tell me what do you mean by "LSR
> > > suspects"? In other
> > > > words,
> > > > what is the triggering input for LSR to start "suspecting"
> > > the LSP may
> > > > have failed?
> > > >
> > > > It will be better if you replace "suspect" with "detect" in
> > > your draft
> > > > as suspect is an imprecise human emotion and no 
> operator would like
> > > > routers that have negative emotions ;-).
> > > >
> > >
> > > It's network operators suspect something may have gone 
> wrong with some
> > > LSP's....
> > NH=> How do they 'suspect' this?....is some crystal-ball going to be
> > supplied with the implementation?  It is not acceptable to 
> have to rely on
> > customers to 1st complain.  So what is the detection 
> mechanism for the
> > defects, you need to explain this more precisely...see also 
> later comments.
> > >
> > > > In addition, I do have issues with introducing a 
> mechanism dependent
> > > > on a particular signalling protocol for a generic 
> problem - testing
> > > > liveness of the label switched data path.
> > >
> > > OK. Do you have problem with the mechanism itself?
> > NH=> I have some problems with it.
> > Coming back from 2 weeks leave and trying to wade through 
> the large volume
> > of discussion this draft has generated tells me there is a 
> fundamental lack
> > of clarity of the problem being solved here.  We really 
> should get the
> > problem statement agreed and also agree a set of OAM arch 
> principles to
> > prevent bad practice. In summary here is what I 
> propose...and I would
> > appreciate some positive feedback on each of these 
> statements if there is
> > disagreement:
> > 
> > 1       Problem statement:
> > 
> > Operators need to determine the operational status of LSPs. 
>  They need
> > simple management tools to do this and operational costs 
> must be driven down
> > (ie we can't afford an army of CCIEs to run networks).  As 
> a minimum, this
> > requires all defects to be identified and specified in 
> terms of entry/exit
> > criteria and the appropriate consequent actions to be taken 
> in order to (i)
> > protect customer traffic and (ii) allow simple diagnostics 
> for operational
> > staff.  This is also required so that the 
> operators/customers can define
> > consistent and measurable availability SLAs and, as a 
> dependent corollary,
> > QoS SLAs (since QoS only has any meaning when the LSP is in 
> the available
> > state).  Customer/operator SLAs are increasing in 
> importance and this needs
> > to be recognised.
> > 
> > 2       Arch principles:
> > Note - although stated against the MPLS case, these can 
> (and should) be
> > generalised to apply to any network...including the GMPLS 
> cases (where
> > perhaps they may be more obvious to some).
> > 
> > 2.1     the data-plane and control-plane must have 
> independent OAM.  Note
> > that the control-plane must use some data-plane (not 
> necessarily the same as
> > that used for customer traffic) and hence needs both its 
> own data-plane OAM
> > and OAM (aka as error handling) which is specific to each of the
> > control-plane protocols in use....so that would be specific 
> OAM for RSVP-TE,
> > CR-LDP, LDP, OSPF, etc.
> > 
> > 2.2     cross-layer network data-plane OAM dependancies 
> must be avoided.  In
> > other words, one should not rely on OAM in technology X to 
> detect/diagnose
> > defects in technology Y (whether X is a client or server 
> layer wrt Y).  This
> > requirement is also necessary for evolution and backwards 
> compatibility, ie
> > to allow layer networks/protocols to be 
> added/removed/modified independently
> > and without affecting other layer networks/protocols.
> > 
> > 2.3     cross-plane OAM dependancies must be avoided.  For 
> example, the
> > data-plane OAM should function independent of the signalling/routing
> > protocols being used (including the case of no 
> control-plane).  This has
> > similar evolution and backwards compatibilty issues as in 2.2.
> > 
> > 2.4     customers must not be expected to act as the default defect
> > detection devices.  Nor must customer traffic activity be 
> used as part of
> > the defect detection function (since users can be 
> quiescent).  Note that
> > defect detection and defect diagnosis are 2 distinct 
> functions.  This also
> > implies that defect detection needs to be a continuous 
> function (at least on
> > important LSPs).
> > BTW - IMO QoS measurements are 2nd order importance 
> compared to defect
> > handling.  QoS should be tackled as a network design and TE 
> issue, with
> > suitable verification via population or ad hoc sampling as 
> needed, and not
> > overkill measurements which can be both costly and swamp 
> operations people.
> > 
> > 2.5     OAM mechanisms should be designed to correctly 
> function under
> > failure conditions, ie OAM mechanisms must not rely on 
> 'well-behaved'
> > network behaviour after a defect has occurred since, by 
> defintion, the fact
> > that the network has failed implies its behaviour cannot be 
> expected to be
> > predictable.
> > 
> > 2.6     A failure in a server layer network should not 
> create alarm storms
> > in client layer networks.  Noting that client layer 
> networks may be owned by
> > different organisations and have a large geographical dispersion.
> > 
> > 2.7     data-plane LSP OAM should not require a return LSP to
> > function....and even with bi-directional LSPs each 
> direction should be
> > monitored independently.
> > 
> > 2.8     failures of the control-plane (either the 
> data-plane aspect or any
> > one of the control-plane protocols that run on this) should 
> not result in
> > failures of the customer traffic data-plane where such 
> trails are permanent
> > or semi-permanent (this is more obvious in the GMPLS case).
> > 
> > The Ping draft either does not address or fails to meet 
> many of these
> > requirements.  More specifically:
> > -       it does not identify/specify any defects;
> > -       it cannot detect any defects unless it is running 
> continuously;
> > -       it could not detect or diagnose all potential 
> defects even if
> > running continously, eg mismerging defects;
> > -       it relies on both cross-layer (ie ICMP is a IP 
> layer OAM mechanism)
> > and cross-plane (ie it is only defined for the RSVP-TE 
> case) functional
> > dependancies.  Although this expediency may have some 
> near-term benefit(?)
> > it is not good arch practice.
> > -       since defects are not detected/defined it is 
> unclear (i) what
> > consequent actions are to be taken to protect customer 
> traffic (none it
> > seems), (ii) how this will help operators target diagnostic 
> activities or
> > (iii) how it will prevent client layer alarm storms.
> > -       its all very well having variable behaviour (wrt 
> timers) but this
> > will create complexities elsewhere, ie inconsistent 
> entry/exit criteria for
> > defects and  availability states, no clear/consistent 
> datums for when QoS
> > metrics collection (if being measured) are valid, ie when 
> to start/stop QoS
> > metric aggregation.  So this means complexities in SLA derivations.
> > 
> > So, whilst I would certainly not want to stop any vendor 
> implementing this
> > draft, as an operator with responsibilities for the integrity of my
> > customers traffic and a need to define SLAs for such, I find it
> > professionally very difficult to condone it becoming a 'standard'.
> > 
> > >
> > > > Secondly, can we have some
> > > > input/justification with regards to the assumption that 
> there is a
> > > > need to detect such a failure since only cause for such 
> a failure
> > > > given in the draft is "memory Corruption". What causes so called
> > > > memory corruption? Are we trying to repair badly 
> written code here?
> > > >
> > >
> > > The problem did happen in the real network. I'm not going to point
> > > fingers on the cause of the problem. But we (vendors and
> > > providers) did
> > > realize from that incidence that we need to have a simple 
> mechanism to
> > > check LSP's data plane in today's operational networks.
> > NH=> Some time ago I was hearing comments such as 'these 
> defects won't
> > happen' and 'don't fix software bugs with additional 
> software' (an erroneous
> > argument anyway).  So having now establised that defects do 
> exist, I fully
> > agree we need some way of detecting/diagnosing such 
> defects.  But this seems
> > not what is being advocated here, since the mechanism does not help
> > operators to detect the defects in the first place.  To address the
> > detection aspect some mechanism has to run continuously, 
> and a technique
> > that is unidirectional would seem to be simpler/better than one that
> > requires a return path.  At some point one needs to raise 
> an alarm and take
> > other consequent actions (eg maybe even squelching customer 
> traffic if
> > intergity/security could be being compromised, and stop any 
> QoS metric
> > aggregation (if being used)) and raise a vertical 
> indication to the NMS...so
> > what better place to do this than at the point where the 
> defect is being
> > initially detected, ie the LSP sink?
> > 
> > Given all this, could those advocating the Ping draft 
> please explain what is
> > actually wrong with the more comprehensive solution we 
> orginally proposed
> > (in draft-harrison-mpls-oam-00.txt).....and in particular, 
> the use of the CV
> > flow.....which is really nothing more than a keepalive 
> running from soure to
> > sink with a unique source identifier and deterministic 
> behaviour....surely
> > it can't be much simpler than this can it?
> > >
> > > The whole purpose on various proposals (fast reroute, 
> graceful restart
> > > and LSP-ping) is to make the whole network working nicely,
> > > even when we
> > > have routers from other vendors that have badly written code.
> > >
> > > - Ping
> > >
> 



From owner-mpls@UU.NET  Tue Aug  7 13:05:59 2001
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 NAA08431
	for <mpls-archive@lists.ietf.org>; Tue, 7 Aug 2001 13:05:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbbo21595;
	Tue, 7 Aug 2001 17:05:34 GMT
Received: by mail-control.mail.uu.net 
	id QQlbbo07190
	for mpls-outgoing; Tue, 7 Aug 2001 17:05:01 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbbo06395
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 17:04:43 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 QQlbbo05107
	for <mpls@UU.NET>; Tue, 7 Aug 2001 17:04:03 GMT
From: neil.2.harrison@bt.com
Received: from dent.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dent.axion.bt.co.uk [132.146.16.161])
	id QQlbbo24179
	for <mpls@UU.NET>; Tue, 7 Aug 2001 17:04:03 GMT
Received: from cclmsent02.lon.bt.com by dent (local) with ESMTP;
          Tue, 7 Aug 2001 18:03:00 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) 
          id <Q3RKN2C1>; Tue, 7 Aug 2001 18:02:59 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E8915AB@mbddmknt01.hc.bt.com>
To: Mooney.Sherman@gov.ab.ca, irfanlateef@hotmail.com, ck@arch.bellsouth.net,
        fabriss@TELEFONICA.COM.AR
Cc: mpls@UU.NET
Subject: RE: SLA
Date: Tue, 7 Aug 2001 18:03:09 +0100 
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Mooney, 
> I agree with your comments but would like to add that SLAs 
> are evolving and
> its demand is increasing by the clients.
Yes this is true.  But note that we should agree the base metrics (since we
all want to measure the same thing, ie they need standardising so we can
compare apples with apples) and the variation (in stringency) occurs in the
*objectives* associated with the metrics.
regards, Neil


From owner-mpls@UU.NET  Wed Aug  8 09:29:53 2001
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 JAA12160
	for <mpls-archive@lists.ietf.org>; Wed, 8 Aug 2001 09:29:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlber26114;
	Wed, 8 Aug 2001 13:28:03 GMT
Received: by mail-control.mail.uu.net 
	id QQlber06938
	for mpls-outgoing; Wed, 8 Aug 2001 13:27:31 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlber06933
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 13:27:30 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 QQlber23677
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:48 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlber14674
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:47 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 JAA07954 for <mpls@uu.net>; Wed, 8 Aug 2001 09:24:47 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15540 for mpls@uu.net; Wed, 8 Aug 2001 09:24:29 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlbcb05470
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 20:15:49 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 QQlbcb22184
	for <mpls@uu.net>; Tue, 7 Aug 2001 20:15:39 GMT
Received: from web11704.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web11704.mail.yahoo.com [216.136.172.70])
	id QQlbcb24477
	for <mpls@uu.net>; Tue, 7 Aug 2001 20:15:39 GMT
Message-ID: <20010807201538.4155.qmail@web11704.mail.yahoo.com>
Received: from [198.205.33.111] by web11704.mail.yahoo.com; Tue, 07 Aug 2001 13:15:38 PDT
Date: Tue, 7 Aug 2001 13:15:38 -0700 (PDT)
From: rao vadlamani <vrnrao@yahoo.com>
Subject: L-LSP's
To: mpls@UU.NET
Cc: mpls-ops@mplsrc.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

Does Cisco, Juniper suppport L-LSP's in any of their
releases ? If so, which one ?

Thanks in advance,
Regards
vrnrao@yahoo.com




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Wed Aug  8 09:30:24 2001
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 JAA12176
	for <mpls-archive@lists.ietf.org>; Wed, 8 Aug 2001 09:30:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlber28229;
	Wed, 8 Aug 2001 13:29:09 GMT
Received: by mail-control.mail.uu.net 
	id QQlber06947
	for mpls-outgoing; Wed, 8 Aug 2001 13:27:36 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlber06924
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 13:27:27 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 QQlber09292
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:52 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlber14293
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:51 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 JAA07965 for <mpls@uu.net>; Wed, 8 Aug 2001 09:24:51 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15548 for mpls@uu.net; Wed, 8 Aug 2001 09:24:32 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbea27500
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 09:06:34 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 QQlbea06723
	for <mpls@uu.net>; Wed, 8 Aug 2001 09:06:18 GMT
From: Jose.Mendez@nokia.com
Received: from mgw-x2.nokia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mgw-x2.nokia.com [131.228.20.22])
	id QQlbea29354
	for <mpls@uu.net>; Wed, 8 Aug 2001 09:06:18 GMT
Received: from esvir06nok.ntc.nokia.com (esvir06nokt.ntc.nokia.com [172.21.143.38])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7896c313893
	for <mpls@uu.net>; Wed, 8 Aug 2001 12:06:39 +0300 (EET DST)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir06nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T553e79973fac158f262df@esvir06nok.ntc.nokia.com> for <mpls@uu.net>;
 Wed, 8 Aug 2001 12:06:16 +0300
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <35H47C6C>; Wed, 8 Aug 2001 12:06:16 +0300
Message-ID: <A914533BF4B9D2118D980008C7894C0A04B082B8@dueis01nok>
To: mpls@UU.NET
Subject: Encapsulation for MPLS over AAL5
Date: Wed, 8 Aug 2001 12:06:15 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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 JAA12176

Hi all,

I'm currently learning about MPLS and ATM and I have a question
concerning the encapsulation used for MPLS.

According to RFC3035 MPLS requires null encapsulation. 
Are there any circumstances where a deviation from the RFC (i.e.
use of LLC/SNAP encapsulation) would be recommended?

Do you know how this is handled in real implementations 
(i.e. market products)?


Thanks a lot,

Jose

____________________________________________________________

Jose Mendez						 
Software Design Engineer			
Research & Development

Nokia Networks			Phone:  +49 211 9412 3341
Heltorfer Strasse 22		Mobile: +49 177 941 3341
D-40472 Düsseldorf		Fax:    +49 211 9412 3224
Germany				E-mail: jose.mendez@nokia.com
____________________________________________________________



From owner-mpls@UU.NET  Wed Aug  8 09:31:04 2001
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 JAA12209
	for <mpls-archive@lists.ietf.org>; Wed, 8 Aug 2001 09:31:04 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbes00830;
	Wed, 8 Aug 2001 13:30:30 GMT
Received: by mail-control.mail.uu.net 
	id QQlber07140
	for mpls-outgoing; Wed, 8 Aug 2001 13:29:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlber06993
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 13:28:22 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 QQlber17867
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:50 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlber14751
	for <mpls@uu.net>; Wed, 8 Aug 2001 13:24:49 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 JAA07960 for <mpls@uu.net>; Wed, 8 Aug 2001 09:24:49 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15544 for mpls@uu.net; Wed, 8 Aug 2001 09:24:31 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbce20803
	for <mpls@mail-control.mail.uu.net>; Tue, 7 Aug 2001 21:05:11 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 QQlbce29992
	for <mpls@UU.NET>; Tue, 7 Aug 2001 21:03:54 GMT
Received: from web20210.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20210.mail.yahoo.com [216.136.226.65])
	id QQlbce11384
	for <mpls@UU.NET>; Tue, 7 Aug 2001 21:03:53 GMT
Message-ID: <20010807210353.15247.qmail@web20210.mail.yahoo.com>
Received: from [128.96.54.189] by web20210.mail.yahoo.com; Tue, 07 Aug 2001 14:03:53 PDT
Date: Tue, 7 Aug 2001 14:03:53 -0700 (PDT)
From: rsvp te <rsvpt@yahoo.com>
Subject: Re: unknown clas/type number
To: mpls@UU.NET
In-Reply-To: <3B6EA4B3.92EFD931@marconi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks for your reply.

It is an unknown class number.  the reason you are
> not getting a ResvErr
> is that the switch can not send you one.  A SESSION
> object is required
> for sending a ResvErr, but the incoming message does
> not have one. 
> Therefore, it is impossible to generate a legal
> ResvErr message.  So
> nothing is generated.

Then which field I should to put this unknown class
number 127 in the resv msg in order to let Ingress to
send me this ResvErr msg out.

> Also what is the unknown type number mentioned in
> the
> > rsvp msg?
> 
> Unknown type?  You mean unknown message type in the
> common header? 
> There is no error message for this.  This is one of
> the errors where RFC
> 2205 explicitly states that the packet is to be
> silently dropped.

No, I mean the what is unknown c-type for rsvp msg,
basically I want to send out Resv msg with unknown
ctype in one field of Resv msg, and then Ingress will
send ResvErr msg back with error code unknown ctype.

Basically I will to test this senario to get the
ResvErr msg back with error code 13/14.

Thanks for your help.




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Wed Aug  8 10:28:06 2001
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 KAA13444
	for <mpls-archive@lists.ietf.org>; Wed, 8 Aug 2001 10:28:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbev28057;
	Wed, 8 Aug 2001 14:26:20 GMT
Received: by mail-control.mail.uu.net 
	id QQlbev02004
	for mpls-outgoing; Wed, 8 Aug 2001 14:25:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbev01996
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 14:25:35 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 QQlbev15197
	for <mpls@UU.NET>; Wed, 8 Aug 2001 14:24:12 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 QQlbev29190
	for <mpls@UU.NET>; Wed, 8 Aug 2001 14:24: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 KAA10416
	for <mpls@UU.NET>; Wed, 8 Aug 2001 10:24: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 KAA06755
	for <mpls@UU.NET>; Wed, 8 Aug 2001 10:24:05 -0400 (EDT)
Message-ID: <3B714B9B.57D4DA40@marconi.com>
Date: Wed, 08 Aug 2001 10:24:27 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: unknown clas/type number
References: <20010807210353.15247.qmail@web20210.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

rsvp te wrote:
> David Charlap wrote:
>>
>> It is an unknown class number.  the reason you are not getting a
>> ResvErr is that the switch can not send you one.  A SESSION object
>> is required for sending a ResvErr, but the incoming message does
>> not have one.  Therefore, it is impossible to generate a legal
>> ResvErr message.  So nothing is generated.
> 
> Then which field I should to put this unknown class number 127 in
> the resv msg in order to let Ingress to send me this ResvErr msg
> out.

You just don't get it.

You can not generate a ResvErr message if you don't have the objects
that are mandatory for ResvErr messages.  You can't just invent them out
of thin air.  If you change the class of a mandatory object, then that
object's identity will change and the switch will be completely unable
to recognize it.

You are asking for the impossible.

>>> Also what is the unknown type number mentioned in the rsvp msg?
>>
> > Unknown type?  You mean unknown message type in the common
>> header? There is no error message for this.  This is one of the
>> errors where RFC 2205 explicitly states that the packet is to be
>> silently dropped.
> 
> No, I mean the what is unknown c-type for rsvp msg, basically I
> want to send out Resv msg with unknown ctype in one field of Resv
> msg, and then Ingress will send ResvErr msg back with error code
> unknown ctype.
> 
> Basically I will to test this senario to get the ResvErr msg back
> with error code 13/14.

If the object with the illegal C-Type is not mandatory for generating
the ResvErr message, there shouldn't be any problem.  If you change the
C-Type of an object that is mandatory for ResvErr messages, it is likely
that the error won't be generated, since the object could not be parsed.

If the switch does not have the ResvErr's mandatory objects, it will be
unable to generate the error message.

-- David


From owner-mpls@UU.NET  Wed Aug  8 16:51:41 2001
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 QAA21242
	for <mpls-archive@lists.ietf.org>; Wed, 8 Aug 2001 16:51:41 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbfv19015;
	Wed, 8 Aug 2001 20:51:23 GMT
Received: by mail-control.mail.uu.net 
	id QQlbfv07797
	for mpls-outgoing; Wed, 8 Aug 2001 20:50:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbfv07767
	for <mpls@mail-control.mail.uu.net>; Wed, 8 Aug 2001 20:50:24 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 QQlbfv00988
	for <mpls@UU.NET>; Wed, 8 Aug 2001 20:47:27 GMT
Received: from EXCHANGE.networkelements.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat.networkelements.com [198.107.63.227] (may be forged))
	id QQlbfv26090
	for <mpls@UU.NET>; Wed, 8 Aug 2001 20:47:23 GMT
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: Label operations question
Date: Wed, 8 Aug 2001 13:47:22 -0700
Message-ID: <7C9FD61585BE294DB290E2207B6001AF30D984@EXCHANGE.networkelements.com>
Thread-Topic: Label operations question
Thread-Index: AcEgS1KASxA30uTSScOsxg7uajIg6Q==
From: "Nepple, Bruce" <bnepple@networkelements.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 QAA21242

I have some questions about label operations given real
world networks.  If this is not the correct forum for this
question, please let me know.

I am trying to classify the label operations that can occur 
within a single LSR given real world networks.  In addition, 
I would like to distinguish between operations on unlabeled 
packets (edge) and already-labeled packets (non-edge).  

For example, an unlabeled packet entering an mpls-vpn domain and
immediately tunneling requires 3 label push operations. 
(VPN,FAR_END,TUNNEL). (I think this is the maximum operation
for an unlabeled packet in a pure mpls domain)

As another example:
A labeled packet being routed into a tunnel requires a swap
and a push. (FAR_END, TUNNEL) (Is this the maximum for a 
labeled packet?)

The main thrust of this question is to try and uncover
more complex operations that might be neccessary. (maybe
there should be a prize given for "discovering" the most 
complex set of real world label operations within a 
single LSR)

Also, I am wondering if Router_Alert labels are ever
used and if so, how widely. What sort of additional actions 
are generally taken as a result of a router alert label? 
Router_Alert labels require an additional operation 
in that one must operate on the second label, possibly 
popping two labels, or even popping, swapping and pushing.

Thank you for you time

Bruce Nepple
Network Elements, Inc









 


From owner-mpls@UU.NET  Thu Aug  9 09:28:17 2001
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 JAA23095
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 09:28:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbij08804;
	Thu, 9 Aug 2001 13:28:01 GMT
Received: by mail-control.mail.uu.net 
	id QQlbij14872
	for mpls-outgoing; Thu, 9 Aug 2001 13:27:29 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbij14860
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 13:27:18 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 QQlbij16295
	for <mpls@uu.net>; Thu, 9 Aug 2001 13:25:55 GMT
Received: from iol.unh.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQlbij26036
	for <mpls@uu.net>; Thu, 9 Aug 2001 13:25:54 GMT
Received: from localhost (jzou@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA16041
	for <mpls@uu.net>; Thu, 9 Aug 2001 09:25:54 -0400 (EDT)
Date: Thu, 9 Aug 2001 09:25:54 -0400
From: Jie Zou <jzou@mars.iol.unh.edu>
To: mpls@UU.NET
Subject: Unsignalled backup lsp
Message-ID: <Pine.SGI.4.20.0108090918590.15790-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

I am reading the draft of "MPLS RSVP-TE Interoperability for Local
Protection/Fast Reroute." I have a question about the unsignalled
backup lsp: how to create it? Another question is how to compute the
bypass backup tunnel, CSPF?

Thanks in advance!

--Jie Zou
----------------
MPLS Consortium
IOL,UNH








From owner-mpls@UU.NET  Thu Aug  9 09:47:45 2001
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 JAA23526
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 09:47:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbil01137;
	Thu, 9 Aug 2001 13:47:47 GMT
Received: by mail-control.mail.uu.net 
	id QQlbil16767
	for mpls-outgoing; Thu, 9 Aug 2001 13:47:13 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbil16753
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 13:46: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 QQlbil16476
	for <mpls@UU.NET>; Thu, 9 Aug 2001 13:46:35 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 QQlbil29201
	for <mpls@UU.NET>; Thu, 9 Aug 2001 13:46:34 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 JAA04731;
	Thu, 9 Aug 2001 09:46:26 -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 JAA06306;
	Thu, 9 Aug 2001 09:46:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRH350>; Thu, 9 Aug 2001 09:46:24 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C6A8@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Jie Zou'" <jzou@mars.iol.unh.edu>, mpls@UU.NET
Subject: RE: Unsignalled backup lsp
Date: Thu, 9 Aug 2001 09:46:22 -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

Jie:

   There are many proprietary MPLS LSP protection/restoration/
   fast reroute/crankback drafts available but none of them 
   talks about how to compute maximally disjoint backup tunnel(s). 
   Because there are so many ways to achieve this (just by 
   making small additional changes in QoS/Constraint Routing 
   algos - CSPF)
  
   Look at:

     "Survivable Networks: Algorithms for Diverse Routing" 
     by Ramesh Bhandari

     M Kodialam and T. V. Lakshman, "Dynamic routing of bandwidth 
     guaranteed tunnels with restoration," in Proceedings of the 
     Conference on Computer Communications (IEEE Infocom),Mar2000
 
--Venkata Naidu


-> Hi,
-> 
-> I am reading the draft of "MPLS RSVP-TE Interoperability for Local
-> Protection/Fast Reroute." I have a question about the unsignalled
-> backup lsp: how to create it? Another question is how to compute the
-> bypass backup tunnel, CSPF?
-> 
-> Thanks in advance!
-> 
-> --Jie Zou
-> ----------------
-> MPLS Consortium
-> IOL,UNH


From owner-mpls@UU.NET  Thu Aug  9 11:00:55 2001
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 LAA26210
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 11:00:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbiq03476;
	Thu, 9 Aug 2001 15:01:05 GMT
Received: by mail-control.mail.uu.net 
	id QQlbiq14573
	for mpls-outgoing; Thu, 9 Aug 2001 15:00:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbiq13130
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 15:00:11 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 QQlbip07776
	for <mpls@UU.NET>; Thu, 9 Aug 2001 14:57:40 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 QQlbip27439
	for <mpls@UU.NET>; Thu, 9 Aug 2001 14:57: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 KAA18057;
	Thu, 9 Aug 2001 10:57:36 -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 KAA05863;
	Thu, 9 Aug 2001 10:57:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <PKPRHWMJ>; Thu, 9 Aug 2001 10:57:30 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C6AA@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Jose.Mendez@nokia.com'" <Jose.Mendez@nokia.com>, mpls@UU.NET
Subject: RE: Encapsulation for MPLS over AAL5
Date: Thu, 9 Aug 2001 10:57:29 -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

Jose:
 
-> I'm currently learning about MPLS and ATM and I have a question
-> concerning the encapsulation used for MPLS.
-> 
-> According to RFC3035 MPLS requires null encapsulation. 

   Yes! This is true for ATM LSRs. (LC-ATM interfaces)
   http://cell-relay.indiana.edu/mhonarc/mpls/1999-Mar/msg00183.html

-> Are there any circumstances where a deviation from the RFC (i.e.
-> use of LLC/SNAP encapsulation) would be recommended?

   Two frame-based  LSRs (not ATM-LSRs) attached via a point-to-point
   link can use LLC/SNAP encapsulation.
   http://cell-relay.indiana.edu/mhonarc/mpls/1999-Jun/msg00030.html


--Venkata Naidu


From owner-mpls@UU.NET  Thu Aug  9 12:27:03 2001
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 MAA29424
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 12:27:03 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbiv29860;
	Thu, 9 Aug 2001 16:27:21 GMT
Received: by mail-control.mail.uu.net 
	id QQlbiv04132
	for mpls-outgoing; Thu, 9 Aug 2001 16:26:46 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbiv04112
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 16:26: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 QQlbiv10348
	for <mpls@UU.NET>; Thu, 9 Aug 2001 16:22:32 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlbiv11859
	for <mpls@UU.NET>; Thu, 9 Aug 2001 16:22:30 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id <PKB2SSY5>; Thu, 9 Aug 2001 12:35:18 -0300
Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D44358@MSTELEFONICA1>
From: Zappacosta Rolando Jorge <zappacor@TELEFONICA.COM.AR>
To: mpls@UU.NET
Subject: Questions regarding LER's
Date: Thu, 9 Aug 2001 12:35:17 -0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all. I've a question that may sound dumb for almost everybody of you;
I've been thinking about the answers but I want to be sure I'm right.
The question is wether it's necesary (or at least better) to run BGP on the
LER's under the following scenarios:
Common Assumptions: in each of the scenarios supposse I've an MPLS network
running OSPF as IGP and that the routers are able to impose labels to OSPF
learned routes.
SCENARIO 1: The LER's have no other routers beyond them, i.e. I've only
directly connected networks with hosts and *no any router* outside the core.
Of course I won't see outside OSPF adjacencies, so IGP doesn't really
matter.
I think it's unnecesary BGP just because I can't figure out any advantage
using it. I will just let the routers impose labels learned through OSPF
here.
SCENARIO 2: The LER's are seeing just a few same area OSPF routers outside.
Here, I think the only advantage will be an inferior convergence time in
case a link failure inside the core, but it would be almost unperceptible.
So it doesn't care so much.
SCENARIO 3: The LER's have a lot of routers outside. So, I think here it is
highly recomendable to run BGP, no matter the outside OSPF routers are or
are not from the same area. This will increase the convergence time in case
of failures and decrease the memory and CPU usage in the inside routers to
hold the routes and links status.

Am I right? Any comments?

Thanks a lot in advance,



Rolando J. Zappacosta
Gerencia Laboratorios - DER
Reconquista 179
Ciudadela (B1702FCC)
Pcia. de Buenos Aires - ARGENTINA
Tel: +54-11-4332-8360
Fax: +54-11-4303-5586 Ext: 6005


From owner-mpls@UU.NET  Thu Aug  9 16:38:16 2001
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 QAA05116
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 16:38:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbjm02130;
	Thu, 9 Aug 2001 20:38:36 GMT
Received: by mail-control.mail.uu.net 
	id QQlbjm18353
	for mpls-outgoing; Thu, 9 Aug 2001 20:37:58 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbjm18344
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 20:37: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 QQlbjm29345
	for <mpls@uu.net>; Thu, 9 Aug 2001 20:34:25 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlbjm26165
	for <mpls@uu.net>; Thu, 9 Aug 2001 20:34: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 QAA28177 for <mpls@uu.net>; Thu, 9 Aug 2001 16:34:24 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA20417 for mpls@uu.net; Thu, 9 Aug 2001 16:34:04 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbji23924
	for <mpls@mail-control.mail.uu.net>; Thu, 9 Aug 2001 19:44:24 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 QQlbji02469
	for <mpls@uu.net>; Thu, 9 Aug 2001 19:43:17 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f84.law14.hotmail.com [64.4.21.84])
	id QQlbji21155
	for <mpls@uu.net>; Thu, 9 Aug 2001 19:43:16 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 9 Aug 2001 12:43:16 -0700
Received: from 38.204.3.195 by lw14fd.law14.hotmail.msn.com with HTTP;	Thu, 09 Aug 2001 19:43:16 GMT
X-Originating-IP: [38.204.3.195]
From: "Raju Venkatraman" <raju_vvs@hotmail.com>
To: ccamp@ops.ietf.org
Subject: Testing Requirements for RSVP-TE
Date: Thu, 09 Aug 2001 19:43:16 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F84C8k8gVKIYIpVMgXL00002d07@hotmail.com>
X-OriginalArrivalTime: 09 Aug 2001 19:43:16.0332 (UTC) FILETIME=[889B4AC0:01C1210B]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Is it possible to test RSVP-TE implementation with just Sun-Solaris/Sparc 
machines? I would appreciate if someone could help me.

Thanks.
Raju

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug  9 22:04:17 2001
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 WAA09791
	for <mpls-archive@lists.ietf.org>; Thu, 9 Aug 2001 22:04:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbki26712;
	Fri, 10 Aug 2001 02:04:45 GMT
Received: by mail-control.mail.uu.net 
	id QQlbki02840
	for mpls-outgoing; Fri, 10 Aug 2001 02:04:15 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbki02792
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 02:04:08 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 QQlbki21764
	for <mpls@UU.NET>; Fri, 10 Aug 2001 02:02:26 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlbki12500
	for <mpls@UU.NET>; Fri, 10 Aug 2001 02:02:25 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id CAA14028
	for <mpls@UU.NET>; Fri, 10 Aug 2001 02:02:24 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001080919005608803
 ; Thu, 09 Aug 2001 19:00:56 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <QT1HGHNQ>; Thu, 9 Aug 2001 19:02:24 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA014@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'David Charlap'" <david.charlap@marconi.com>, mpls@UU.NET
Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
Date: Thu, 9 Aug 2001 19:02:22 -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

Sorry, I still have some doubts on this that I hope someone can shed some
light on.

With what we discussed below, what would happen is that, if S1, S3 only need
1M of bandwidth, and S2, S4 need 10M, on the path where S1, S3 take, even if
they only need 1M, they will get a request of 10M and as a result, get a
reservation of 10M. This seems to be wasteful on that particular path. 

Would this be potential problem?

I really cannot find any reference/explanation in RFC2205 and the RSVP-TE
draft.

Thanks in advance.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 17, 2001 12:15 PM
> To: mpls@UU.NET
> Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> 
> 
> "Feng, Mark" wrote:
> >>> 
> >>>                     ______
> >>>                    |      |
> >>>                +---|      |---+
> >>>                |   |______|   |
> >>>                |              |
> >>>                |s1,s3         |s1,s3
> >>>  s1,s2 ______  |              |  ______
> >>>  -----|      |-+              +-|      | s1,s2,s3,s4
> >>>  -----|      |-+              +-|      |------
> >>>  s3,s4|______| |              | |______|
> >>>                |s2,s4_____    |s2,s4
> >>>                |   |      |   |
> >>>                +---|      |---+
> >>>                    |______|
> >>>
> >>> Is this possible in RSVP-TE?
> >>
> >> SE style only shares resources among LSPs that share a single
> >> session.
> > 
> > Sorry I didn't make it clear. All the senders in the diagram belong
> > to the same session.
> 
> Then all senders will get the same reservation.
> 
> > Considering the first node on the diagram, S1, S2 come in at one
> > interface, and S3, S4 come in at a different interface. Even though
> > they belong to the same session, the Path messages travel a
> > different path. This is somewhat different from RSVP/RFC 2205,
> > where, in unicast, Path messages for the same session take the
> > same path.
> > 
> > In this case, because Path messages take different routes, Resv
> > messages will arrive at different interfaces, with potentially
> > different resource requirements. The process of handling the
> > resource allocation at various interfaces, as a result, is
> > somewhat different from RSVP/RFC 2205.
> 
> Not really.  Reservations all come from the egress.  All LSPs share a
> common egress router.  Whatever reservation it chooses for one sender
> must be used for all of them.  This Resv message may split up (with
> different filterspecs in the flow descriptor) as it follows to the
> different PHOP routers, but they all reserve the same resources.  When
> they come back together at the ingress router, they are still 
> the same.
> 
> If the egress router tries to send different flowspecs for 
> each sender,
> then it is in error.
> 


From owner-mpls@UU.NET  Fri Aug 10 00:30:07 2001
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 AAA12347
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 00:30:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbks14121;
	Fri, 10 Aug 2001 04:30:11 GMT
Received: by mail-control.mail.uu.net 
	id QQlbkr01769
	for mpls-outgoing; Fri, 10 Aug 2001 04:29:40 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbkr01761
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 04:29:30 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 QQlbkr16378
	for <mpls@UU.NET>; Fri, 10 Aug 2001 04:26:30 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlbkr10421
	for <mpls@UU.NET>; Fri, 10 Aug 2001 04:26:27 GMT
Received: from multitech.co.in ([192.168.1.33])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f7A4Lco23395;
	Fri, 10 Aug 2001 09:51:38 +0530
Message-ID: <3B736367.76DB8AC1@multitech.co.in>
Date: Fri, 10 Aug 2001 10:00:31 +0530
From: abhay <abhay@multitech.co.in>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jie Zou <jzou@mars.iol.unh.edu>
CC: mpls@UU.NET
Subject: Re: Unsignalled backup lsp
References: <Pine.SGI.4.20.0108090918590.15790-100000@mars.iol.unh.edu>
Content-Type: multipart/alternative;
 boundary="------------16633E5F083C9C8498C75423"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------16633E5F083C9C8498C75423
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jie Zou,

        Since you have already read the draft.

        Creating a backup LSP can be done in these following ways

        1)Create a disjoint backup lsp by calling CSPF

        2)Create a local backup again using CSPF,but at this time..giving an include

          and exclude option to CSPF.

        Hope this helps,

        Regards,

        Abhay

Jie Zou wrote:

> Hi,
>
> I am reading the draft of "MPLS RSVP-TE Interoperability for Local
> Protection/Fast Reroute." I have a question about the unsignalled
> backup lsp: how to create it? Another question is how to compute the
> bypass backup tunnel, CSPF?
>
> Thanks in advance!
>
> --Jie Zou
> ----------------
> MPLS Consortium
> IOL,UNH

--------------16633E5F083C9C8498C75423
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>Jie Zou,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Since you have already read the draft.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Creating a backup LSP can be done in these following ways</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1)Create a disjoint backup lsp by calling CSPF</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2)Create a local backup again using CSPF,but at this time..giving an include</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and exclude option to CSPF.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope this helps,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Abhay</pre>

<p><br>Jie Zou wrote:
<blockquote TYPE=CITE>Hi,
<p>I am reading the draft of "MPLS RSVP-TE Interoperability for Local
<br>Protection/Fast Reroute." I have a question about the unsignalled
<br>backup lsp: how to create it? Another question is how to compute the
<br>bypass backup tunnel, CSPF?
<p>Thanks in advance!
<p>--Jie Zou
<br>----------------
<br>MPLS Consortium
<br>IOL,UNH</blockquote>
</html>

--------------16633E5F083C9C8498C75423--



From owner-mpls@UU.NET  Fri Aug 10 00:31:12 2001
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 AAA12370
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 00:31:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbks20920;
	Fri, 10 Aug 2001 04:31:37 GMT
Received: by mail-control.mail.uu.net 
	id QQlbks01928
	for mpls-outgoing; Fri, 10 Aug 2001 04:31:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbks01860
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 04:30:10 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 QQlbkr24141
	for <mpls@uu.net>; Fri, 10 Aug 2001 04:29:46 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlbkr16052
	for <mpls@uu.net>; Fri, 10 Aug 2001 04:29:42 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QQTB30V2>; Fri, 10 Aug 2001 09:57:02 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BADB@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: "'Feng, Mark'" <m_feng@trillium.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
Date: Fri, 10 Aug 2001 09:57:01 +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 
RFC 2205 clearly states the three ways in which reservations can be made in
Rsvp ( SE , FF and Wildcard ) . Further , the draft states that the Wildcard
style is not permitted for Rsvp-Te . Thus , we are left with two ways in
which to make the reservation . 
a) SE . In this case , what you are saying is correct . All data packets
from flows originating from S1,S2,S3 and S4 will flow into a 'pipe' with a
maximum capacity of 10 Mbps . If explicit routes are being used , there
would be two different routes having reservation of 10 Mbps each ! 
b) FF , wherein all flows have different reservations and the whole scenario
is like  a cable with 4 lines , one for each sender . Hence S1 gets a line
of 1 Mbps , S2 of 10 Mpbs and so on . As is clear , there is a wastage in
THIS case since no  sharing is taking place .
c) Also , there is no restriction on keeping each  sender in different
tunnels , or for that matter , make two tunnels , one having one SE styled
reservation of 1 Mbps for S1 and S3 and another tunnel having one SE styled
reservation of 10 Mbps for S2 and S4 . 
Thus ,Rsvp and Rsvp-te gives us many choices for handling of reservations
and it is the decision of the administrator / policy agent to make the best
decision from these choices. 

Apratim


> ----------
> From: 	Feng, Mark[SMTP:m_feng@trillium.com]
> Sent: 	Friday, August 10, 2001 7:32 AM
> To: 	'David Charlap'; mpls@UU.NET
> Subject: 	RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> 
> Sorry, I still have some doubts on this that I hope someone can shed some
> light on.
> 
> With what we discussed below, what would happen is that, if S1, S3 only
> need
> 1M of bandwidth, and S2, S4 need 10M, on the path where S1, S3 take, even
> if
> they only need 1M, they will get a request of 10M and as a result, get a
> reservation of 10M. This seems to be wasteful on that particular path. 
> 
> Would this be potential problem?
> 
> I really cannot find any reference/explanation in RFC2205 and the RSVP-TE
> draft.
> 
> Thanks in advance.
> 
> - Mark
> 
> > -----Original Message-----
> > From: David Charlap [mailto:david.charlap@marconi.com]
> > Sent: Tuesday, July 17, 2001 12:15 PM
> > To: mpls@UU.NET
> > Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> > 
> > 
> > "Feng, Mark" wrote:
> > >>> 
> > >>>                     ______
> > >>>                    |      |
> > >>>                +---|      |---+
> > >>>                |   |______|   |
> > >>>                |              |
> > >>>                |s1,s3         |s1,s3
> > >>>  s1,s2 ______  |              |  ______
> > >>>  -----|      |-+              +-|      | s1,s2,s3,s4
> > >>>  -----|      |-+              +-|      |------
> > >>>  s3,s4|______| |              | |______|
> > >>>                |s2,s4_____    |s2,s4
> > >>>                |   |      |   |
> > >>>                +---|      |---+
> > >>>                    |______|
> > >>>
> > >>> Is this possible in RSVP-TE?
> > >>
> > >> SE style only shares resources among LSPs that share a single
> > >> session.
> > > 
> > > Sorry I didn't make it clear. All the senders in the diagram belong
> > > to the same session.
> > 
> > Then all senders will get the same reservation.
> > 
> > > Considering the first node on the diagram, S1, S2 come in at one
> > > interface, and S3, S4 come in at a different interface. Even though
> > > they belong to the same session, the Path messages travel a
> > > different path. This is somewhat different from RSVP/RFC 2205,
> > > where, in unicast, Path messages for the same session take the
> > > same path.
> > > 
> > > In this case, because Path messages take different routes, Resv
> > > messages will arrive at different interfaces, with potentially
> > > different resource requirements. The process of handling the
> > > resource allocation at various interfaces, as a result, is
> > > somewhat different from RSVP/RFC 2205.
> > 
> > Not really.  Reservations all come from the egress.  All LSPs share a
> > common egress router.  Whatever reservation it chooses for one sender
> > must be used for all of them.  This Resv message may split up (with
> > different filterspecs in the flow descriptor) as it follows to the
> > different PHOP routers, but they all reserve the same resources.  When
> > they come back together at the ingress router, they are still 
> > the same.
> > 
> > If the egress router tries to send different flowspecs for 
> > each sender,
> > then it is in error.
> > 
> 


From owner-mpls@UU.NET  Fri Aug 10 03:05:57 2001
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 DAA00100
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 03:05:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlblc09369;
	Fri, 10 Aug 2001 07:06:23 GMT
Received: by mail-control.mail.uu.net 
	id QQlblc02849
	for mpls-outgoing; Fri, 10 Aug 2001 07:05:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlblc02245
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 07:05:29 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 QQlblc01402
	for <mpls@uu.net>; Fri, 10 Aug 2001 07:03:39 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlblc05014
	for <mpls@uu.net>; Fri, 10 Aug 2001 07:03:36 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QQTB309B>; Fri, 10 Aug 2001 12:30:55 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D705C305@mailserver.netbrahma.com>
From: Mohit Misra <MohitM@netbrahma.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: MPLS over FR
Date: Fri, 10 Aug 2001 12:30:54 +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

I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
are connected over a FR cloud and intermediate FR switches are MPLS unaware.
A label mapping (DLCI) is negotiated between them. When the upstream node
sends a labled packet with the negotiated DLCI, the intermediate switches
will modify this value and finally it will reach the downstream node with a
different DLCI value (which was not negotiated ). ATM solves this problem by
VCID notification. How it is resolved in FR case ?
				/Mohit


From owner-mpls@UU.NET  Fri Aug 10 09:47:20 2001
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 JAA04923
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 09:47:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbmd09225;
	Fri, 10 Aug 2001 13:47:37 GMT
Received: by mail-control.mail.uu.net 
	id QQlbmd13214
	for mpls-outgoing; Fri, 10 Aug 2001 13:46:57 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlbmd13205
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 13:46:53 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 QQlbmd14552
	for <mpls@uu.net>; Fri, 10 Aug 2001 13:46:31 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlbmd24218
	for <mpls@uu.net>; Fri, 10 Aug 2001 13:46:30 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA19644
	for <mpls@uu.net>; Fri, 10 Aug 2001 09:46:30 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23020 for mpls@uu.net; Fri, 10 Aug 2001 09:46:10 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbkj12690
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 02:18:57 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 QQlbkj26119
	for <mpls@UU.NET>; Fri, 10 Aug 2001 02:17:58 GMT
Received: from web14601.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14601.mail.yahoo.com [216.136.224.79])
	id QQlbkj05534
	for <mpls@UU.NET>; Fri, 10 Aug 2001 02:17:57 GMT
Message-ID: <20010810021757.49970.qmail@web14601.mail.yahoo.com>
Received: from [134.134.248.29] by web14601.mail.yahoo.com; Thu, 09 Aug 2001 19:17:57 PDT
Date: Thu, 9 Aug 2001 19:17:57 -0700 (PDT)
From: Mark Feng <mfeng00@yahoo.com>
Subject: RE: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
To: david.charlap@marconi.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Sorry to send this again. There is problem with the
e-mail system at work.

======================================================
Sorry, I still have some doubts on this that I hope
someone can shed some light on.

With what we discussed below, what would happen is
that, if S1, S3 only need 1M of bandwidth, and S2, S4
need 10M, on the path where S1, S3 take, even if they
only need 1M, they will get a request of 10M and as a
result, get a reservation of 10M. This seems to be
wasteful on that particular path. 

Would this be potential problem?

I really cannot find any reference/explanation in
RFC2205 and the RSVP-TE draft.

Thanks in advance.

- Mark

> -----Original Message-----
> From: David Charlap
[mailto:david.charlap@marconi.com]
> Sent: Tuesday, July 17, 2001 12:15 PM
> To: mpls@UU.NET
> Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> 
> 
> "Feng, Mark" wrote:
> >>> 
> >>>                     ______
> >>>                    |      |
> >>>                +---|      |---+
> >>>                |   |______|   |
> >>>                |              |
> >>>                |s1,s3         |s1,s3
> >>>  s1,s2 ______  |              |  ______
> >>>  -----|      |-+              +-|      |
s1,s2,s3,s4
> >>>  -----|      |-+              +-|      |------
> >>>  s3,s4|______| |              | |______|
> >>>                |s2,s4_____    |s2,s4
> >>>                |   |      |   |
> >>>                +---|      |---+
> >>>                    |______|
> >>>
> >>> Is this possible in RSVP-TE?
> >>
> >> SE style only shares resources among LSPs that
share a single
> >> session.
> > 
> > Sorry I didn't make it clear. All the senders in
the diagram belong
> > to the same session.
> 
> Then all senders will get the same reservation.
> 
> > Considering the first node on the diagram, S1, S2
come in at one
> > interface, and S3, S4 come in at a different
interface. Even though
> > they belong to the same session, the Path messages
travel a
> > different path. This is somewhat different from
RSVP/RFC 2205,
> > where, in unicast, Path messages for the same
session take the
> > same path.
> > 
> > In this case, because Path messages take different
routes, Resv
> > messages will arrive at different interfaces, with
potentially
> > different resource requirements. The process of
handling the
> > resource allocation at various interfaces, as a
result, is
> > somewhat different from RSVP/RFC 2205.
> 
> Not really.  Reservations all come from the egress. 
All LSPs share a
> common egress router.  Whatever reservation it
chooses for one sender
> must be used for all of them.  This Resv message may
split up (with
> different filterspecs in the flow descriptor) as it
follows to the
> different PHOP routers, but they all reserve the
same resources.  When
> they come back together at the ingress router, they
are still 
> the same.
> 
> If the egress router tries to send different
flowspecs for 
> each sender,
> then it is in error.
> 




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Fri Aug 10 10:41:53 2001
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 KAA05587
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 10:41:53 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbmg08912;
	Fri, 10 Aug 2001 14:41:39 GMT
Received: by mail-control.mail.uu.net 
	id QQlbmg07193
	for mpls-outgoing; Fri, 10 Aug 2001 14:41:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbmg07151
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 14:40:53 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 QQlbmg23103
	for <mpls@UU.NET>; Fri, 10 Aug 2001 14:39:15 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 QQlbmg03771
	for <mpls@UU.NET>; Fri, 10 Aug 2001 14:39:15 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 KAA16962
	for <mpls@UU.NET>; Fri, 10 Aug 2001 10:39:12 -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 KAA07762
	for <mpls@UU.NET>; Fri, 10 Aug 2001 10:39:13 -0400 (EDT)
Message-ID: <3B73F22C.A0F66954@marconi.com>
Date: Fri, 10 Aug 2001 10:39:40 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
References: <F1CE15E08172D4119247009027AE9D500C7CA014@FMSMSX37>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Feng, Mark" wrote:
> 
> With what we discussed below, what would happen is that, if S1, S3
> only need 1M of bandwidth, and S2, S4 need 10M, on the path where
> S1, S3 take, even if they only need 1M, they will get a request of
> 10M and as a result, get a reservation of 10M. This seems to be
> wasteful on that particular path.
>
> ...
>                     ______
>                    |      |
>                +---|      |---+
>                |   |______|   |
>                |              |
>                |s1,s3         |s1,s3
>  s1,s2 ______  |              |  ______
>  -----|      |-+              +-|      | s1,s2,s3,s4
>  -----|      |-+              +-|      |------
>  s3,s4|______| |              | |______|
>                |s2,s4_____    |s2,s4
>                |   |      |   |
>                +---|      |---+
>                    |______|

It doesn't matter how much each one "requires".  If they are all in the
same session and the egress router chooses to use SE-style for the
reservation, then all will get the same bandwidth - 1M, 10M, or anything
else.  (But probably 10M, since that's the smallest size that will
satisfy everybody's request.)

If this is unacceptible, then the ingress router shouldn't put these
four LSPs all in the same session together.

-- David


From owner-mpls@UU.NET  Fri Aug 10 11:47:57 2001
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 LAA06730
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 11:47:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbml18231;
	Fri, 10 Aug 2001 15:47:11 GMT
Received: by mail-control.mail.uu.net 
	id QQlbml02710
	for mpls-outgoing; Fri, 10 Aug 2001 15:46:32 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbml02554
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 15:46:19 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 QQlbml18593
	for <mpls@uu.net>; Fri, 10 Aug 2001 15:45:28 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlbml07681
	for <mpls@uu.net>; Fri, 10 Aug 2001 15:45:28 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 LAA05952 for <mpls@uu.net>; Fri, 10 Aug 2001 11:45:25 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA23780 for mpls@uu.net; Fri, 10 Aug 2001 11:45:05 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbmk01887
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 15:41: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 QQlbmk03954
	for <mpls@uu.net>; Fri, 10 Aug 2001 15:39:45 GMT
From: Gelder35@aol.com
Received: from imo-m10.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-m10.mx.aol.com [64.12.136.165])
	id QQlbmk07155
	for <mpls@uu.net>; Fri, 10 Aug 2001 15:39:45 GMT
Received: from Gelder35@aol.com
	by imo-m10.mx.aol.com (mail_out_v31.9.) id 1.b9.12094528 (3844)
	 for <mpls@uu.net>; Fri, 10 Aug 2001 11:39:31 -0400 (EDT)
Message-ID: <b9.12094528.28a55a33@aol.com>
Date: Fri, 10 Aug 2001 11:39:31 EDT
Subject: (no subject)
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 5.0 for Windows sub 109
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have a few newbie questions on vlan over mpls.

In Martini's drafts, there is a Group Id on LDP.
The use of Group ID is not explained clearly. I
am wondering if anybody out there can help me out

1. How Group ID is assigned in this context?

2. Should local group id and remote group id match?
   Is it ok a local group has a different id than a
   remote group?

3. Is group id network-wide significant or node-wide
   significant or peers-between significant?

4. In Cisco's implementation, there is a VC ID. It 
   seems that Cisco uses VC ID to relate a local VC 
   label to a remote VC label. But VC ID is missing
   in the LDP/RSVP for VC signalling, why?



From owner-mpls@UU.NET  Fri Aug 10 13:15:07 2001
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 NAA08525
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 13:15:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbmq06221;
	Fri, 10 Aug 2001 17:14:30 GMT
Received: by mail-control.mail.uu.net 
	id QQlbmq20073
	for mpls-outgoing; Fri, 10 Aug 2001 17:13:57 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbmq20068
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 17:13:56 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 QQlbmq17442
	for <mpls@uu.net>; Fri, 10 Aug 2001 17:13:43 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlbmq15888
	for <mpls@uu.net>; Fri, 10 Aug 2001 17:13:41 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA14907
	for <mpls@uu.net>; Fri, 10 Aug 2001 13:13:41 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA24262 for mpls@uu.net; Fri, 10 Aug 2001 13:13:21 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlbmn25090
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 16:17:45 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 QQlbmm23533
	for <mpls@UU.NET>; Fri, 10 Aug 2001 16:14:17 GMT
Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221])
	id QQlbmm12474
	for <mpls@UU.NET>; Fri, 10 Aug 2001 16:14:17 GMT
Received: from packetexchange.net (truman-firewall [212.161.41.120])
	by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP
	id C2CFA15F83B; Fri, 10 Aug 2001 17:14:11 +0100 (BST)
Message-ID: <3B740875.7FDC725@packetexchange.net>
Date: Fri, 10 Aug 2001 17:14:45 +0100
From: Giles Heron <giles@packetexchange.net>
Reply-To: giles@packetexchange.net
Organization: PacketExchange Ltd.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Gelder35@aol.com
Cc: mpls@UU.NET, PWE3 mailing list <pwe3@ietf.org>
Subject: Re: (no subject)
References: <b9.12094528.28a55a33@aol.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gelder35@aol.com wrote:
> 
> I have a few newbie questions on vlan over mpls.
> 
> In Martini's drafts, there is a Group Id on LDP.
> The use of Group ID is not explained clearly. I
> am wondering if anybody out there can help me out
> 
> 1. How Group ID is assigned in this context?

It is a local decision as to how to assign the group ID.

Two options mentioned in the draft are:

1.  port index
2.  virtual tunnel index.

> 2. Should local group id and remote group id match?
>    Is it ok a local group has a different id than a
>    remote group?

No, they are not required to match.  So it is OK if they are different
:)

The PWE3 MIB stores both local and remote Group IDs. 

> 3. Is group id network-wide significant or node-wide
>    significant or peers-between significant?

Only between peers.  It allows a node to (for example) issue a wild-card
withdraw to a peer for all VCs with a given Group ID.

> 4. In Cisco's implementation, there is a VC ID. It
>    seems that Cisco uses VC ID to relate a local VC
>    label to a remote VC label. But VC ID is missing
>    in the LDP/RSVP for VC signalling, why?

No, VC ID is in draft-martini.  The VC ID/VC type must match (and is
unique) between the two peers.

BTW the mailing list where draft-martini gets discussed is
pwe3@ietf.org.

HTH

Giles

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



From owner-mpls@UU.NET  Fri Aug 10 13:32:29 2001
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 NAA08746
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 13:32:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbms27759;
	Fri, 10 Aug 2001 17:32:21 GMT
Received: by mail-control.mail.uu.net 
	id QQlbms21594
	for mpls-outgoing; Fri, 10 Aug 2001 17:31:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlbms21584
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 17:31:32 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 QQlbmr09804
	for <mpls@uu.net>; Fri, 10 Aug 2001 17:28:36 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlbmr21017
	for <mpls@uu.net>; Fri, 10 Aug 2001 17:28:16 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA14987 for mpls@uu.net; Fri, 10 Aug 2001 13:25:42 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbmr21067
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 17:24:56 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 QQlbmr01373
	for <mpls@UU.NET>; Fri, 10 Aug 2001 17:24:28 GMT
Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f233.law10.hotmail.com [64.4.15.233])
	id QQlbmr21443
	for <mpls@UU.NET>; Fri, 10 Aug 2001 17:24:28 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 Aug 2001 10:24:27 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Fri, 10 Aug 2001 17:24:27 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: david.charlap@marconi.com
Cc: mpls@UU.NET
Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
Date: Fri, 10 Aug 2001 10:24:27 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F233yi67EKRuYDlrjbu000042dd@hotmail.com>
X-OriginalArrivalTime: 10 Aug 2001 17:24:27.0697 (UTC) FILETIME=[4EC43210:01C121C1]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi David,
           If S1, S2 can be reachable through incoming interface I1 and 
require bandwidth 1M and 2M respectively. The senders S3, S4 falling under 
the same session (as of S1 and S2) require bandwidth 5M and 10M respectively 
but reachable through different incoming interface I2. Do I still need to 
reserve 10M on both the incoming interfaces (i.e. I1 and I2) ? Even though 
we are aware that only 2M (larger of S1, S2) will be utilized on I1. Why is 
it defined like this in the protocol ?

Regards,
manoj.

Feng, Mark" wrote:
>
>With what we discussed below, what would happen is that, if S1, S3
>only need 1M of bandwidth, and S2, S4 need 10M, on the path where
>S1, S3 take, even if they only need 1M, they will get a request of
>10M and as a result, get a reservation of 10M. This seems to be
>wasteful on that particular path.
>
>...
>                     ______
>                    |      |
>                +---|      |---+
>                |   |______|   |
>                |              |
>                |s1,s3         |s1,s3
>  s1,s2 ______  |              |  ______
>  -----|      |-+              +-|      | s1,s2,s3,s4
>  -----|      |-+              +-|      |------
>  s3,s4|______| |              | |______|
>                |s2,s4_____    |s2,s4
>                |   |      |   |
>                +---|      |---+
>                    |______|

It doesn't matter how much each one "requires".  If they are all in the
same session and the egress router chooses to use SE-style for the
reservation, then all will get the same bandwidth - 1M, 10M, or anything
else.  (But probably 10M, since that's the smallest size that will
satisfy everybody's request.)

If this is unacceptible, then the ingress router shouldn't put these
four LSPs all in the same session together.

-- David


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Fri Aug 10 13:36:52 2001
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 NAA08787
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 13:36:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbms04785;
	Fri, 10 Aug 2001 17:36:29 GMT
Received: by mail-control.mail.uu.net 
	id QQlbms21894
	for mpls-outgoing; Fri, 10 Aug 2001 17:35:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlbms21881
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 17:35:47 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 QQlbms02374
	for <mpls@UU.NET>; Fri, 10 Aug 2001 17:35:03 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 QQlbms08117
	for <mpls@UU.NET>; Fri, 10 Aug 2001 17:35:03 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 NAA03379
	for <mpls@UU.NET>; Fri, 10 Aug 2001 13:35:00 -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 NAA19716
	for <mpls@UU.NET>; Fri, 10 Aug 2001 13:35:04 -0400 (EDT)
Message-ID: <3B741B66.B16E4EC2@marconi.com>
Date: Fri, 10 Aug 2001 13:35:34 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
References: <F233yi67EKRuYDlrjbu000042dd@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

manoj juneja wrote:
> 
> If S1, S2 can be reachable through incoming interface I1 and require
> bandwidth 1M and 2M respectively. The senders S3, S4 falling under
> the same session (as of S1 and S2) require bandwidth 5M and 10M
> respectively but reachable through different incoming interface I2.
> Do I still need to reserve 10M on both the incoming interfaces (i.e.
> I1 and I2) ? Even though we are aware that only 2M (larger of S1,
> S2) will be utilized on I1. Why is it defined like this in the
> protocol ?

Because it's a single _SHARED_ reservation.  It's not four separate
reservations that happen to share resources where convenient.

When the egress router sends an SE-style Resv message, there is exactly
_ONE_ flowspec object transmitted, which covers _ALL_ of the filterspecs
in the flow descriptor.

What I don't understand is why you think you should put LSPs with
different incompatible resource requirements in the same session
together.

-- David


From owner-mpls@UU.NET  Fri Aug 10 15:42:10 2001
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 PAA10615
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 15:42:10 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbna04583;
	Fri, 10 Aug 2001 19:42:11 GMT
Received: by mail-control.mail.uu.net 
	id QQlbna12312
	for mpls-outgoing; Fri, 10 Aug 2001 19:41:39 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbna12295
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 19:41:25 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 QQlbna20970
	for <mpls@uu.net>; Fri, 10 Aug 2001 19:41:04 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlbna00623
	for <mpls@uu.net>; Fri, 10 Aug 2001 19:41:04 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA23665 for mpls@uu.net; Fri, 10 Aug 2001 15:41:03 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlbna12183
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 19:40:29 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 QQlbna09477
	for <mpls@uu.net>; Fri, 10 Aug 2001 19:40:10 GMT
Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f269.law10.hotmail.com [64.4.14.144])
	id QQlbna00282
	for <mpls@uu.net>; Fri, 10 Aug 2001 19:40:09 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 Aug 2001 12:40:09 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Fri, 10 Aug 2001 19:40:08 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: david.charlap@marconi.com
Cc: mpls@UU.NET
Date: Fri, 10 Aug 2001 12:40:08 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F269JrNKBqujsclWXSZ000020c5@hotmail.com>
X-OriginalArrivalTime: 10 Aug 2001 19:40:09.0185 (UTC) FILETIME=[4378AD10:01C121D4]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi David,
          It means that if incoming interface I1 can not allocate 100M
(may be its max. reservable bandwidth is < 100M) of bandwidth then the
LSP establishment will fail eventhough the senders that are reachable
through incoming interface I1 require much less than 100M . I mean to
say what if different interfaces (I1 and I2) have different max.
reservable bandwidth configured (say I1 has max. reservable bandwidth
as 20M and I2 has max reservable bandwidth as 200M). There may be
different senders connected (reachable through different routers) to
different routers may fall in same session without knowledge (if they
don't include extended tunnel Id).

Regards,
manoj.

manoj juneja wrote:
>
>If S1, S2 can be reachable through incoming interface I1 and require
>bandwidth 1M and 2M respectively. The senders S3, S4 falling under
>the same session (as of S1 and S2) require bandwidth 5M and 10M
>respectively but reachable through different incoming interface I2.
>Do I still need to reserve 10M on both the incoming interfaces (i.e.
>I1 and I2) ? Even though we are aware that only 2M (larger of S1,
>S2) will be utilized on I1. Why is it defined like this in the
>protocol ?

Because it's a single _SHARED_ reservation.  It's not four separate
reservations that happen to share resources where convenient.

When the egress router sends an SE-style Resv message, there is exactly
_ONE_ flowspec object transmitted, which covers _ALL_ of the filterspecs
in the flow descriptor.

What I don't understand is why you think you should put LSPs with
different incompatible resource requirements in the same session
together.

-- David


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Fri Aug 10 15:58:59 2001
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 PAA10814
	for <mpls-archive@lists.ietf.org>; Fri, 10 Aug 2001 15:58:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQlbnb28834;
	Fri, 10 Aug 2001 19:59:13 GMT
Received: by mail-control.mail.uu.net 
	id QQlbnb14008
	for mpls-outgoing; Fri, 10 Aug 2001 19:58:42 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlbnb13957
	for <mpls@mail-control.mail.uu.net>; Fri, 10 Aug 2001 19:58: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 QQlbnb16133
	for <mpls@UU.NET>; Fri, 10 Aug 2001 19:58:19 GMT
Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQlbnb09742
	for <mpls@UU.NET>; Fri, 10 Aug 2001 19:58:19 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 PAA10115
	for <mpls@UU.NET>; Fri, 10 Aug 2001 15:54:00 -0400 (EDT)
Subject: opaque object----unknown object
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF870527E1.BA939BCA-ON85256AA4.006C8921@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 10 Aug 2001 15:52:59 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/10/2001 03:52:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Can you help me for this questions?

For opaque object, it will be appeared in all the rsvp-te msgs(path, resv,
patherr, pathtear, resvtear, resvtear, hello, resvConf) or only path and
resv msgs? (it was not mentioned in the spec)
Also I did not see any requirement from spec on where to put this opaque
object.

Thanks for your help.

Julia






From owner-mpls@UU.NET  Tue Aug 14 12:36:12 2001
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 MAA09310
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:36:12 -0400 (EDT)
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 QQlcbi21352;
	Tue, 14 Aug 2001 16:35:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi12497
	for mpls-outgoing; Tue, 14 Aug 2001 16:35: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 QQlcbi12439
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:34:46 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 QQlcai11972
	for <mpls@UU.NET>; Tue, 14 Aug 2001 10:09:45 GMT
Received: from ext1.ics.forth.gr by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2])
	id QQlcai04669
	for <mpls@UU.NET>; Tue, 14 Aug 2001 10:09:44 GMT
Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51])
	by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id NAA18335;
	Tue, 14 Aug 2001 13:09:19 +0300 (EET DST)
Received: from crete.csi.forth.gr (crete.ics.forth.gr [139.91.190.10]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id NAA14550; Tue, 14 Aug 2001 13:09:26 +0300 (EET DST)
Posted-Date: Tue, 14 Aug 2001 13:09:26 +0300 (EET DST)
Received: from localhost (tziou@localhost)
	by crete.csi.forth.gr (8.9.3/ICS-FORTH/V8.1-NULL) with ESMTP id MAA09975;
	Tue, 14 Aug 2001 12:58:57 +0300 (EET DST)
Organization:   
X-Authentication-Warning: crete.csi.forth.gr: tziou owned process doing -bs
Date: Tue, 14 Aug 2001 12:58:57 +0300 (EET DST)
From: Chrysostomos Tziouvaras <tziou@ics.forth.gr>
To: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>
Subject: An algorithm for calculating all paths between an s-d pair
Message-ID: <Pine.GSO.4.33.0108141254200.9926-100000@crete.csi.forth.gr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I am searching for an algorithm for calculating all paths between an s-d
pair. Can you provide me pointers to books or URLs?

Thanks
Chrysostomos



From owner-mpls@UU.NET  Tue Aug 14 12:37:15 2001
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 MAA09348
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:37: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 QQlcbi14421;
	Tue, 14 Aug 2001 16:35:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi12551
	for mpls-outgoing; Tue, 14 Aug 2001 16:35: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 QQlcbi12456
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:34:51 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 QQlbxj13775
	for <mpls@UU.NET>; Mon, 13 Aug 2001 14:59:08 GMT
Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: samar.sasken.com [164.164.56.2])
	id QQlbxj10938
	for <mpls@UU.NET>; Mon, 13 Aug 2001 14:59:05 GMT
Received: from samar (localhost [127.0.0.1])
	by samar.sasken.com (8.11.3/8.11.3) with SMTP id f7DEwmg02337;
	Mon, 13 Aug 2001 20:28:49 +0530 (IST)
Received: from sasken.com (pcsva204.sasken.com [10.1.65.204])
	by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id UAA20848;
	Mon, 13 Aug 2001 20:28:47 +0530 (IST)
Message-ID: <3B77EB76.735DA1E8@sasken.com>
Date: Mon, 13 Aug 2001 20:30:07 +0530
From: Rajesh P Jain <rpjain@sasken.com>
Organization: SASKEN Communication Technologies Ltd
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS UUNET Mailing List <mpls@UU.NET>, mpls-ops@mplsrc.com
Subject: Doubt on Make Before Break Concept
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
                    I have some doubts on Smooth Re-Routing of LSP
Tunnels.

1. As I understand the draft, the make-before-break (Smooth Re-Routing)
should be initiated by the Sender Node (Path Message is sent new with
new ERO object and ofcourse with a different LSP ID in the
SENDER_TEMPLATE ). The receiver receives this Path Message.

2. Now, the receiver HAS to send a RESERVE message with SE reservation
style (Of course with Filter spec list containing the SENDER_TEMPLATE of
the old Path Message and SENDER_TEMPLATE of new Path Message i.e they
differ only in their LSP ID's, and of course ERO's).

3. Now, the New Path Message received  is AS GOOD AS A New Sender for
this receiver and hence it MAY NOT send a RESERVE Message for this
sender (The receiver sends only if it wants some reservation for this
sender).

4. In case, if the receiver chooses not to send the reserve message,
then Smooth Re-Route WILL NOT happen.

                    So, can anyone explain whether the Smooth Re-Routing
is Sender-Based  or Receiver -Based (Who has the control of Re-Routing
the traffic ??) ???

                    In case of Increase in Band-width (For a particular
LSP), the Sender indicates the increase in band-width BUT still the
Receiver HAS to send the Reserve message for this increase in the
Band-width. So, the same problem holds good for this case also????

                    Am I missing something???? Please throw light on
this issue possibly with an example.

TIA
        Rajesh P Jain





From owner-mpls@UU.NET  Tue Aug 14 12:37:20 2001
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 MAA09362
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:37:20 -0400 (EDT)
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 QQlcbi24528;
	Tue, 14 Aug 2001 16:37:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi12936
	for mpls-outgoing; Tue, 14 Aug 2001 16:36: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 QQlcbi12598
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:35:23 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 QQlbzm07370
	for <mpls@UU.NET>; Tue, 14 Aug 2001 04:30:59 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlbzm03455
	for <mpls@UU.NET>; Tue, 14 Aug 2001 04:30:56 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QV8NPAG4>; Tue, 14 Aug 2001 09:58:10 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6871@mailserver.netbrahma.com>
From: Manoj Agiwal <ManojA@netbrahma.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RRO Processing
Date: Tue, 14 Aug 2001 09:58:01 +0530
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 ,
      In case of RRO processing ,

"If the newly added subobject causes the RRO to be too big to fit 
in a  Path (or Resv) message, the RRO object SHALL be dropped 
from the  message and message processing continues as normal"

 In this particular case will the RRO object will be dropped for all the
Filter Descriptors  , or for the one which is new .

How the case should be handled in case if RRO was not there and subsequent
adding the RRO object starts giving this error .

Regards ,
Manoj




From owner-mpls@UU.NET  Tue Aug 14 12:37:48 2001
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 MAA09375
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:37:48 -0400 (EDT)
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 QQlcbi25941;
	Tue, 14 Aug 2001 16:37:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi12937
	for mpls-outgoing; Tue, 14 Aug 2001 16:36: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 QQlcbi12632
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:35: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 QQlbzg22438
	for <mpls@UU.NET>; Tue, 14 Aug 2001 03:04:30 GMT
From: i-nishioka@cb.jp.nec.com
Received: from TYO202.gate.nec.co.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: TYO202.gate.nec.co.jp [202.247.6.41])
	id QQlbzg06263
	for <mpls@UU.NET>; Tue, 14 Aug 2001 03:04:28 GMT
Received: from mailgate4.nec.co.jp ([10.7.69.197])
	by TYO202.gate.nec.co.jp (8.11.3/3.7W01080315) with ESMTP id f7E33s110418;
	Tue, 14 Aug 2001 12:03:54 +0900 (JST)
Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP
	id f7E33rx05168; Tue, 14 Aug 2001 12:03:53 +0900 (JST)
Received: from optsys1.optsys.cl.nec.co.jp (optsys1.optsys.cl.nec.co.jp [10.56.36.1]) by mailsv4.nec.co.jp (8.11.3/3.7W-MAILSV4-NEC) with ESMTP
	id f7E33pL21674; Tue, 14 Aug 2001 12:03:51 +0900 (JST)
Received: from NISHIOKA-PC (nishioka-pc [10.56.36.172])
	by optsys1.optsys.cl.nec.co.jp (8.9.3/3.7W-optsys-000511) with SMTP id MAA39173;
	Tue, 14 Aug 2001 12:03:44 +0900 (JST)
To: mpls@UU.NET, ccamp@ops.ietf.org
Subject: LSP Deletion and Admin status 
Reply-To: i-nishioka@cb.jp.nec.com
Date: Tue, 14 Aug 2001 11:56:43 +0900
Message-Id: <20010814115643i-nishioka@optsys1.cb.jp.nec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Mailer: WeMail32[1.97A] ID:1C0005
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I have questions about LSP deletion procedure with 
Admin status object in draft-ietf-mpls-generalized-rsvp-04.

As described in section 7, 
LSP state is changed to "down"  by admin status object in Path/Resv Msg,
before deletion from ingress node

One question; 
How to transpot Admin status object in case of deletion from egress node?

Another question;
Why does Round-trip procedure (Path->Resv procedure) need,
to change LSP state? 

I think round trip procedure is different from UNI 1.0 signaling procedure,
because signaling to change LSP state is only one-way in UNI 1.0.

Thanks in advance,
Itaru Nishioka.



From owner-mpls@UU.NET  Tue Aug 14 12:38:52 2001
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 MAA09394
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:38:52 -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 QQlcbi02557;
	Tue, 14 Aug 2001 16:39:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13070
	for mpls-outgoing; Tue, 14 Aug 2001 16:37:18 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 QQlcbi12950
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:36: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 QQlcba14117
	for <mpls@UU.NET>; Tue, 14 Aug 2001 14:36:37 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 QQlcba07288
	for <mpls@UU.NET>; Tue, 14 Aug 2001 14:36:37 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 KAA06768;
	Tue, 14 Aug 2001 10:36:29 -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 KAA26662;
	Tue, 14 Aug 2001 10:36:32 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <Q6LA3851>; Tue, 14 Aug 2001 10:36:30 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C6CC@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ashwin C. Prabhu'" <Ashwinp@in.huawei.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV
Date: Tue, 14 Aug 2001 10:36:30 -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

Prabhu:

->             Can anyone please tell me what are these 8 
-> priority levels and what for these 
->             used ? 

  There are no set of semantics for each priority level. 
  The different levels provide an ordering that can be 
  used to determine preemption during the establishment 
  of LSPs. They can also be used by an implementation 
  as a means of ordering LSP computation and setup.

  How to use these priority levels? Look at:
  CR-LDP draft-ietf-mpls-cr-ldp-05.txt and
  RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt

-> why we need this. 

  The need for priority levels is specified in
  RFC 2702. There is a consensus of eight protocols 
  being sufficient.  

  In Dan's terms...

  "The priority attribute defines the relative importance of traffic
   trunks.  If a constraint-based routing framework is used with MPLS,
   then priorities become very important because they can be used to
   determine the order in which path selection is done for traffic
   trunks at connection establishment and under fault scenarios.

   Priorities are also important in implementations  permitting
   preemption because they can be used to impose a partial order on the
   set of traffic trunks according to which preemptive policies can be
   actualized."

--Venkata Naidu


From owner-mpls@UU.NET  Tue Aug 14 12:40:00 2001
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 MAA09450
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:40:00 -0400 (EDT)
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 QQlcbi27090;
	Tue, 14 Aug 2001 16:38:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13061
	for mpls-outgoing; Tue, 14 Aug 2001 16: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 QQlcbi12940
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:36:44 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 QQlbxs15602
	for <mpls@UU.NET>; Mon, 13 Aug 2001 17:03:15 GMT
Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQlbxs22758
	for <mpls@UU.NET>; Mon, 13 Aug 2001 17:03:15 GMT
Received: from prometheus (IDENT:root@ssh-int.avici.com [10.6.0.28])
	by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f7DH2Js23591;
	Mon, 13 Aug 2001 13:02:19 -0400 (EDT)
Message-Id: <4.1.20010813130124.00975850@localhost>
X-Sender: aatlas@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 13 Aug 2001 13:05:44 -0400
To: Jie Zou <jzou@mars.iol.unh.edu>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: Unsignalled backup lsp
Cc: mpls@UU.NET
In-Reply-To: <Pine.SGI.4.20.0108090918590.15790-100000@mars.iol.unh.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The unsignalled backup LSP is that described in the
draft-swallow-rsvp-bypass-label-01.txt. 
Basically, a bypass tunnel which goes to the appropriate merge node is
created, based upon a CSPF computation.  Depending upon the possible
implementations, that bypass tunnel could have been statically configured
or created dynamically when the need for one arose.

Once a bypass tunnel exists, the unsignalled backup LSP can be created once
the label record sub-object in the RRO from the merge node has been
received at the PLR.  Only local configuration at the PLR is necessary to
create the unsignalled backup LSP; no RSVP signalling is necessary.

Hope this helps,
Alia Atlas


At 09:25 AM 8/9/01 -0400, Jie Zou wrote:
>
>Hi,
>
>I am reading the draft of "MPLS RSVP-TE Interoperability for Local
>Protection/Fast Reroute." I have a question about the unsignalled
>backup lsp: how to create it? Another question is how to compute the
>bypass backup tunnel, CSPF?
>
>Thanks in advance!
>
>--Jie Zou
>----------------
>MPLS Consortium
>IOL,UNH
>
>
>
>
>
>



From owner-mpls@UU.NET  Tue Aug 14 12:40:18 2001
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 MAA09487
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:40:13 -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 QQlcbi04628;
	Tue, 14 Aug 2001 16:40:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13450
	for mpls-outgoing; Tue, 14 Aug 2001 16:39: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 QQlcbi13146
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:37: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 QQlbzr15955
	for <mpls@UU.NET>; Tue, 14 Aug 2001 05:59:19 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlbzr05000
	for <mpls@UU.NET>; Tue, 14 Aug 2001 05:59:17 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <Q3W0V9XH>; Tue, 14 Aug 2001 11:32:28 +0500
Message-ID: <751B6DD7A243D511AB9F0002557C5687ACC6A9@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Traffic Engineering TLV
Date: Tue, 14 Aug 2001 11:32:22 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1248A.E01872F0"
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_01C1248A.E01872F0
Content-Type: text/plain;
	charset="iso-8859-1"



Hello 

         The draft-katz-yeung-ospf-traffic-04.txt section 2.5.8 specifies 

          2.5.8. Unreserved Bandwidth

   	The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
   	not yet reserved at each of the eight priority levels, in IEEE
   	floating point format.  Each value will be less than or equal to the
  	 maximum reservable bandwidth.  The units are bytes per second.

   	The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in
   	length.


            Can anyone please tell me what are these 8 priority levels and
what for these 
            used ? why we need this.
          
Thanks in Advance
Ashwin





------_=_NextPart_001_01C1248A.E01872F0
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>Traffic Engineering TLV</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
draft-katz-yeung-ospf-traffic-04.txt section 2.5.8 specifies </FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2.5.8. Unreserved Bandwidth</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
The Unreserved Bandwidth sub-TLV<B> specifies the amount of =
bandwidth</B></FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp; not yet reserved at each of the eight priority =
levels,</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">in IEEE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
floating point format.&nbsp; Each value will be less than or equal to =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maximum reservable =
bandwidth.&nbsp; The units are bytes per second.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets =
in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
length.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Can anyone please tell me what are these 8 priority levels =
and what for these </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; used ? why we need this.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks in Advance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ashwin</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1248A.E01872F0--


From owner-mpls@UU.NET  Tue Aug 14 12:40:30 2001
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 MAA09503
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:40:30 -0400 (EDT)
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 QQlcbi00655;
	Tue, 14 Aug 2001 16:40:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13482
	for mpls-outgoing; Tue, 14 Aug 2001 16:39:49 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 QQlcbi13258
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:38: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 QQlcar18100
	for <mpls@UU.NET>; Tue, 14 Aug 2001 12:27:18 GMT
Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mason2.gmu.edu [129.174.1.11])
	id QQlcar29596
	for <mpls@UU.NET>; Tue, 14 Aug 2001 12:27:17 GMT
Received: from localhost (rpapneja@localhost)
	by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id IAA28708
	for <mpls@UU.NET>; Tue, 14 Aug 2001 08:27:17 -0400 (EDT)
Date: Tue, 14 Aug 2001 08:27:17 -0400 (EDT)
From: Rajiv Papneja <rpapneja@osf1.gmu.edu>
X-Sender: rpapneja@mason2.gmu.edu
To: mpls@UU.NET
Subject: MPLS 2001 Int. Conference Registration -Oct 7-9, Wash, DC 
Message-ID: <Pine.OSF.4.21.0108140823230.28415-100000@mason2.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


*****************Our apologies if you receive this multiple times********* 

                MPLS2001 International Conference
           4th Annual International Conference on MPLS
                        October 7-9, 2001
               Omni Shoreham Hotel, Washington, DC.
                        Hosted jointly by
     UUNET Technologies/Worldcom and Advanced Internet Laboratory
 
                        Program Schedule

        Tutorials               : October 7, 1:00 - 6:00 pm
        Conference sessions     : October 8-9, 8:30 am - 6:00 pm
        Exhibits                : October 8-9
        2nd Public Inter-Op Demo: October 10-12 (OIF UNI, MPLS, GMPLS)

       			Important Dates
        Early Registration Rates Cut-Off Date: August 20
        Hotel Rate Cut-Off Rate              : September 15

       
   You are cordially invited to attend the MPLS 2001 International
Conference to be held in Washington DC, Oct. 7-9.  MPLS 2001, 4th Annual
International Conference on MPLS, co-hosted by WorldCom (UUNET
Technologies) and Advanced Internet Lab of GMU, is being sponsored by
Agilent Technologies, Alcatel, Avici Systems, Cisco Systems, Data
Connection, Ericsson, IXIA, Juniper Networks, Laurel Networks, Lucent
Technologies, Metera Networks, Nortel Networks, Ocular Networks, OPNET
Technologies, Spirent Communications, Unisphere Networks, and Wavesmith 
Networks. Sponsors will be exhibiting their products and services
throughout Monday and Tuesday.

  We hope you would be able to actively participate in MPLS 2001
International Conference. The event consists of a two-day highly
technical sessions, preceded by a half-a-day of technical tutorials.

   MPLS 2001 offers an excellent blend of various topics covering
important aspects of MPLS and its application in Optical Networks. The
updated tutorials and  technical sessions have been posted at MPLS 2001
web site under "Technical Sessions" and "Tutorials" sections,
(http://www.mpls2001.com/technical.htm) and is being continuously updated.

   Registration for the conference is open and you may register for
MPLS 2001 either On-line or Off-line by visiting
http://www.mpls2001.com/registration.htm and following the
instructions. The early registration fees are extremely attractive and we
hope that you can benefit from the opportunity and pre-register for
MPLS2001 soon. Pre-registration rates are valid till August 20.

   If you are planning to attend MPLS 2001, you may want to make your
hotel reservations now as we have blocked limited number of rooms at Omni
Shoreham Hotel (Conference Venue and the designated hotel) at special
rates. In order to benefit from the discounted conference rate, we
urge you to make your reservations immediately. You may visit 
(http://www.mpls2001.com/hotels.htm) for more information on hotel
reservations.

   For any additional information, please visit http://www.mpls2001.com. 
We look forward to seeing you in the "MPLS 2001 International Conference." 
Thanks.
   
  Regards,
   -Rajiv







From owner-mpls@UU.NET  Tue Aug 14 12:41:55 2001
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 MAA09589
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:41:55 -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 QQlcbi26831;
	Tue, 14 Aug 2001 16:41:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13685
	for mpls-outgoing; Tue, 14 Aug 2001 16:41:12 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 QQlcbi13514
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:39:51 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 QQlcbi17629
	for <mpls@uu.net>; Tue, 14 Aug 2001 16:39:39 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcbi22478
	for <mpls@uu.net>; Tue, 14 Aug 2001 16:39:38 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 MAA12574 for <mpls@uu.net>; Tue, 14 Aug 2001 12:39:33 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA01132 for mpls@uu.net; Tue, 14 Aug 2001 12:39:10 -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 QQlcbi12596
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:35: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 QQlbyk20081
	for <mpls@UU.NET>; Mon, 13 Aug 2001 21:35:45 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQlbyk15218
	for <mpls@UU.NET>; Mon, 13 Aug 2001 21:35:45 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GSTD>; Mon, 13 Aug 2001 17:31:25 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A42E@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'Rajesh P Jain'" <rpjain@sasken.com>,
        MPLS UUNET Mailing List
	 <mpls@UU.NET>, mpls-ops@mplsrc.com
Cc: "'pmk@sasken.com'" <pmk@sasken.com>
Subject: RE: Doubt on Make Before Break Concept
Date: Mon, 13 Aug 2001 17:31:17 -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

Hi 
If u see on page no 14 of draft_ietf_mpls_lsp_tunnel_08.txt-->>
ur doubt will be cleared.
On links ( LSr s) that are held in common( old LSP , new LSP as process of
"smooth" rerouting)
, the shared SESSION object and SE style allow the LSP to be established
sharing resources with the old LSP.

SO if for the new LSP PATH message , the treatment of nodes varies depends
on its type.
If it is new node , it will take the PATH message conventionally./
Otherwise , it will allow to share the resources of old LSP with new LSP.
This is how new LSP will be established , then u can tear down the old LSP ,
once u get RESV_CONFORM messaqge for the new LSP.

NOTE : Shared SE style , Common  SESSION attribute will be helpful to do
smooth rerouting,
and also in bandwidth increase of a tunnel.
If u do not have above , ( SE style reservation and commom SESSION id ) then
this new LSP will try to get
extra BW than necessary.
Ex., One LSP link has 10 Mb/s , where as u want to increase it to 20 Mb/s.
ACtual link capacity is 21Mb/s.
It will not allow to increase the bandwidth to 20Mb/s as , the available is
only 10Mb/s.

But the Link does not know that u wanted to give up the allocated 10Mb/s
after once u finish this new reservation for 20Mb/s. This is sort of
Deadlock
The solution is : If u can make use of the allocated bw ie., 10Mb/s in the
admission control , then u can entertain the new request and after taht u
can release the old allocated bw.
for this to happen , the new pathn request should have 2 things in common to
old request(with which u got 10Mb/s)
they are : same session id( with different LSP tunnel id) , and reservation
style is SE.SO that the new and old LSPs will share the bandwidth .

Regards
Ravikumar Kota 
Cratos Networks Inc
100, NAGOG PARK
ACTON ,MA-01824

-----Original Message-----
From: Rajesh P Jain [mailto:rpjain@sasken.com]
Sent: Monday, August 13, 2001 11:00 AM
To: MPLS UUNET Mailing List; mpls-ops@mplsrc.com
Subject: Doubt on Make Before Break Concept


Hi,
                    I have some doubts on Smooth Re-Routing of LSP
Tunnels.

1. As I understand the draft, the make-before-break (Smooth Re-Routing)
should be initiated by the Sender Node (Path Message is sent new with
new ERO object and ofcourse with a different LSP ID in the
SENDER_TEMPLATE ). The receiver receives this Path Message.

2. Now, the receiver HAS to send a RESERVE message with SE reservation
style (Of course with Filter spec list containing the SENDER_TEMPLATE of
the old Path Message and SENDER_TEMPLATE of new Path Message i.e they
differ only in their LSP ID's, and of course ERO's).

3. Now, the New Path Message received  is AS GOOD AS A New Sender for
this receiver and hence it MAY NOT send a RESERVE Message for this
sender (The receiver sends only if it wants some reservation for this
sender).

4. In case, if the receiver chooses not to send the reserve message,
then Smooth Re-Route WILL NOT happen.

                    So, can anyone explain whether the Smooth Re-Routing
is Sender-Based  or Receiver -Based (Who has the control of Re-Routing
the traffic ??) ???

                    In case of Increase in Band-width (For a particular
LSP), the Sender indicates the increase in band-width BUT still the
Receiver HAS to send the Reserve message for this increase in the
Band-width. So, the same problem holds good for this case also????

                    Am I missing something???? Please throw light on
this issue possibly with an example.

TIA
        Rajesh P Jain



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml



From owner-mpls@UU.NET  Tue Aug 14 12:44:08 2001
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 MAA09696
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:44:08 -0400 (EDT)
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 QQlcbi04580;
	Tue, 14 Aug 2001 16:42:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi13694
	for mpls-outgoing; Tue, 14 Aug 2001 16:41: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 QQlcbi13412
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:39: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 QQlcay00889
	for <mpls@UU.NET>; Tue, 14 Aug 2001 14:00:01 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 QQlcay15672
	for <mpls@UU.NET>; Tue, 14 Aug 2001 14:00:01 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 JAA01819;
	Tue, 14 Aug 2001 09:59:24 -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 JAA12835;
	Tue, 14 Aug 2001 09:59:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <Q6LA35LZ>; Tue, 14 Aug 2001 09:56:29 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C6CB@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Kshitij Kumar'" <kkumar@lanterncom.com>,
        "'Juha Heinanen'"
	 <jh@lohi.eng.telia.fi>
Cc: "'mpls@uu.net'" <mpls@UU.NET>, te-wg@ops.ietf.org,
        Adisak Mekkittikul
	 <adisak@lanterncom.com>,
        Nader Vijeh <nader@lanterncom.com>
Subject: RE: QoS in Shared Media
Date: Tue, 14 Aug 2001 09:56:27 -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

Juha, et. al.,

   Please look at (some relevance)   
   http://www.marconi.com/media/qos100.pdf


--Venkata Naidu


-> Juha, et. al.,
-> 
-> In case people on the lists are curious, RPR is a work in 
-> progress, and
-> there is some interesting material available at the IEEE web 
-> site, presented
-> there a few weeks ago.
-> 
-> One such presentation I would highly recommend is available at:
-> 
-> http://www.ieee802.org/17/documents/presentations/jul2001/am_
-> voqmdl_02.pdf
-> 
-> cheers!
-> 
-> Kshitij Kumar,
-> Lantern Communications, Canada.
-> 
-> -----Original Message-----
-> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
-> Sent: Monday, July 30, 2001 11:53 AM
-> To: Jay Wang
-> Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
-> te-wg@ops.ietf.org
-> Subject: RE: QoS in Shared Media
-> 
-> 
-> jay,
-> 
-> i'm reading old emails and found your dpr/rpr/diffserv 
-> comment below to
-> which i have not had time to reply.  unfortunately i have to disagree
-> with you regarding dpt/rpr supporting diffserv.  the problem is their
-> node based fairness concept.
-> 
-> lets say that i have a 100 mbps rpr ring of four nodes 
-> a-b-c-d-a, there
-> may be 25 mbps of yellow and red af1 packets from both a to 
-> d and b to d
-> plus 70 mbps of green af1 packets from c to a.  in c, yellow and red
-> packets from a and b to d should not get 1/2 (50 mbps) of 
-> the bandwidth
-> causing 20 mbps of green af1 packets originating from c to 
-> be dropped.
-> 
-> -- juha
-> ------------------------------------------------
-> Jay Wang writes:
->  > 
->  > Dunno what is the problem. To support diffserv, the underneath
->  > transport (MAC layer and lower), does not have to have a
->  > sophisticated traffic management matching diffserv PHBs. The fact
->  > that cisco's DPT (or others RPR version for that matter), a MAC
->  > layer technology, that supports only two transmit 
-> queueing priorities,
->  > hence is not a disqualifier for supporting diffserv on 
-> the higher level,
->  > where you suggested otherwise. In a share-media environment, from
->  > diffserv's perspective, what we need from below is a link layer
->  > that may ensure a quantifiable and stable guaranteed 
-> throughput for the
->  > target nodes, regardless of the other sharing nodes. This 
-> is what is
->  > missing in the original IEEE-802-style LAN. The DPT, on 
-> the other hand,
->  > assures total_ring-BandWidth/node_num for each node. 
-> Given that, the
->  > business of diffserv traffic management, e.g., BA classification,
->  > policing, color-based RED dropping, PHB scheduling, and 
-> so on and so
-> forth,
->  > can be conducted as they should have been at the connected nodes.
->  > 
->  > - jay
->  > 
->  > 
->  > -----Original Message-----
->  > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
->  > Sent: Friday, May 04, 2001 10:52 PM
->  > To: Jay Wang
->  > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net';
->  > te-wg@ops.ietf.org
->  > Subject: RE: QoS in Shared Media
->  > 
->  > 
->  > Jay Wang writes:
->  > 
->  >  > Well, RPR gives you bandwidth endurance at the link 
-> level, a shared
->  >  > media in this case. On higher level, you may conduct 
-> your QoS as
->  >  > appropriate, Diffserv, Intserv, or else. One does not 
-> preclude the
-> other,
->  >  > IMO.
->  > 
->  > how about if someone would like to give different 
-> bandwidth assurance to
->  > more than one independent traffic class?  also, within a diffserv
->  > traffic class, droping of packets is based on the drop 
-> presedence of the
->  > packet, not based on behind which nodes the packets arrived.
->  > 
->  > as i said before, node based fairness can only be applied 
-> to the highest
->  > dp packets within each class.  dpt (and also rpr if it 
-> adopts dpt) thus
->  > supports diffserv only in a very limited sense.  as far 
-> as i remember,
->  > it is the only ieee mac standard, where the specification 
-> tells how many
->  > queues the switch has.
->  > 
->  > -- juha
->  > 
->  > 
->  > -----Original Message-----
->  > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On 
-> Behalf Of Juha
->  > Heinanen
->  > Sent: Friday, May 04, 2001 12:01 PM
->  > To: HANSEN CHAN
->  > Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 
-> 'te-wg@ops.ietf.org'
->  > Subject: Re: QoS in Shared Media
->  > 
->  > HANSEN CHAN writes:
->  > 
->  >  > How about the work in IEEE 802.17 RPR? I believe it will be a
->  > shared-media
->  >  > technology. Does that mean they will have a hard time 
-> to achieve QoS
->  >  > guarantees?
->  > 
->  > last time that i checked, the rpr proposal (based on 
-> cisco dpt) had two
->  > classes of service (strict priority and best effort). 
-> that is clearly
->  > not adequate for diffserv.  node based fairness applied 
-> to the best
->  > effort class.  in diffserv, node based fairness makes 
-> sense only for the
->  > highest dp packets in each traffic class.
->  > 
->  > -- juha
->  > 
-> 


From owner-mpls@UU.NET  Tue Aug 14 12:45:03 2001
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 MAA09776
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 12:45:03 -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 QQlcbi01413;
	Tue, 14 Aug 2001 16:43:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbi14028
	for mpls-outgoing; Tue, 14 Aug 2001 16:43: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 QQlcbi13999
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 16:43:07 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 QQlcbf06251
	for <mpls@uu.net>; Tue, 14 Aug 2001 15:55:27 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 QQlcbf01672
	for <mpls@uu.net>; Tue, 14 Aug 2001 15:55:21 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [192.168.235.4])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f7ELYSJ20693
	for <mpls@uu.net>; Tue, 14 Aug 2001 21:34:28 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GI2F6L00.16X for <mpls@uu.net>; Tue, 14 Aug 2001 21:31:33 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id QAA11948 for <mpls@uu.net>; Tue, 14 Aug 2001 16:34:54 +0530
Date: Tue, 14 Aug 2001 21:29:21 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: Need some mpls statistics.......
Message-ID: <Pine.LNX.4.31.0105251013090.24283-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,
	I wanted some statistics about the real-world mpls networks.
Basically I need information about MPLS control planes particularly
with respect to the Label Distribution Protocols with regard to the
following items:

1. What would be the normal number of adjacencies you would find in a core
router
2. Approximate number of sessions we could find in a core router.
3. Average number of LSP's that could be seen over each session

... and things like this. This is primarily to look at the ways of stress
testing at the laboratory level. Any information is appreciated.

regards
Bhushana





From owner-mpls@UU.NET  Tue Aug 14 13:28:25 2001
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 NAA11109
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 13:28:25 -0400 (EDT)
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 QQlcbl13961;
	Tue, 14 Aug 2001 17:26:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbl06543
	for mpls-outgoing; Tue, 14 Aug 2001 17:26: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 QQlcbl06536
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 17:26:25 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 QQlcbl13884
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:22:09 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcbl27519
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:22: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 NAA17770 for <mpls@uu.net>; Tue, 14 Aug 2001 13:22:04 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA01389 for mpls@uu.net; Tue, 14 Aug 2001 13:21:42 -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 QQlcbl06129
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 17:20:51 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 QQlcbl06999
	for <mpls@UU.NET>; Tue, 14 Aug 2001 17:19:21 GMT
Received: from qlink.queensu.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: Qlink.QueensU.CA [130.15.129.2])
	id QQlcbl01400
	for <mpls@UU.NET>; Tue, 14 Aug 2001 17:19:20 GMT
Received: from Arthur (d141-159-32.home.cgocable.net [24.141.159.32])
	by qlink.queensu.ca (8.10.1/8.10.1) with SMTP id f7EHIvE24096;
	Tue, 14 Aug 2001 13:18:57 -0400 (EDT)
Message-ID: <02fc01c124fa$64432330$209f8d18@Arthur>
From: "Pin-Han Ho" <8ph5@qlink.queensu.ca>
To: "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>, <mpls-ops@mplsrc.com>,
        <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>
References: <Pine.GSO.4.33.0108141254200.9926-100000@crete.csi.forth.gr>
Subject: Re: [IP-Optical] An algorithm for calculating all paths between an s-d pair
Date: Tue, 14 Aug 2001 12:50:32 -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 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

What kind of paths do you need? Shortest ones?
----- Original Message -----
From: "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
To: <mpls-ops@mplsrc.com>; <mpls@UU.NET>; <IP-Optical@lists.bell-labs.com>
Sent: Tuesday, August 14, 2001 2:58 AM
Subject: [IP-Optical] An algorithm for calculating all paths between an s-d
pair


Hi,
I am searching for an algorithm for calculating all paths between an s-d
pair. Can you provide me pointers to books or URLs?

Thanks
Chrysostomos






From owner-mpls@UU.NET  Tue Aug 14 13:35:36 2001
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 NAA11269
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 13:35:36 -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 QQlcbm18113;
	Tue, 14 Aug 2001 17:34:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbm06935
	for mpls-outgoing; Tue, 14 Aug 2001 17:34:38 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 QQlcbm06930
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 17:34:34 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 QQlcbm22231
	for <mpls@UU.NET>; Tue, 14 Aug 2001 17:32:41 GMT
Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQlcbm14502
	for <mpls@UU.NET>; Tue, 14 Aug 2001 17:32:41 GMT
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7EHWdL02014;
	Tue, 14 Aug 2001 13:32:39 -0400 (EDT)
Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id NAA14222; Tue, 14 Aug 2001 13:32:38 -0400
Message-ID: <3B79619E.34932480@hotair.hobl.lucent.com>
Date: Tue, 14 Aug 2001 13:36:30 -0400
From: Ramesh Bhandari <bhandari1@lucent.com>
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chrysostomos Tziouvaras <tziou@ics.forth.gr>
CC: mpls-ops@mplsrc.com, mpls@UU.NET, IP-Optical@lists.bell-labs.com
Subject: Re: An algorithm for calculating all paths between an s-d pair
References: <Pine.GSO.4.33.0108141254200.9926-100000@crete.csi.forth.gr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Chrysostomos,

I believe you are searching for the K-shortest path algorithm, which
provides paths for a given pair of nodes in ascending order of their
lengths. An example website for information on this is
http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.

But, if you are looking for algorithms for K-disjoint paths, these can
be found in my book: "Survivable Networks: Algorithms for Diverse
Routing", Kluwer Academic Publishers (1999).

Regards,

Ramesh

Chrysostomos Tziouvaras wrote:
> 
> Hi,
> I am searching for an algorithm for calculating all paths between an s-d
> pair. Can you provide me pointers to books or URLs?
> 
> Thanks
> Chrysostomos


From owner-mpls@UU.NET  Tue Aug 14 14:00:36 2001
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 OAA11845
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 14:00:36 -0400 (EDT)
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 QQlcbn07745;
	Tue, 14 Aug 2001 17:58:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcbn08285
	for mpls-outgoing; Tue, 14 Aug 2001 17:58: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 QQlcbn08280
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 17:58:33 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 QQlcbn20387
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:53:29 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcbn24977
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:53:29 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 NAA21998 for <mpls@uu.net>; Tue, 14 Aug 2001 13:53:28 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA01526 for mpls@uu.net; Tue, 14 Aug 2001 13:53:06 -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 QQlcbm06875
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 17:32:39 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 QQlcbm19856
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:31:43 GMT
Received: from maties2.sun.ac.za by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: maties2.sun.ac.za [146.232.128.10])
	id QQlcbm12814
	for <mpls@uu.net>; Tue, 14 Aug 2001 17:31:41 GMT
Received: from erwin.cs.sun.ac.za ([146.232.212.13])
	by maties2.sun.ac.za with esmtp (Exim 3.32 #1)
	id 15WhmZ-0007lE-00; Tue, 14 Aug 2001 19:15:11 +0200
Received: from bagula (helo=localhost)
	by erwin.cs.sun.ac.za with local-esmtp (Exim 3.22 #1 (Debian))
	id 15WhmZ-0004G5-00; Tue, 14 Aug 2001 19:15:11 +0200
Date: Tue, 14 Aug 2001 19:15:11 +0200 (SAST)
From: Antoine Bagula <bagula@cs.sun.ac.za>
To: Chrysostomos Tziouvaras <tziou@ics.forth.gr>
cc: mpls-ops@mplsrc.com, mpls@UU.NET, IP-Optical@lists.bell-labs.com
Subject: Re: An algorithm for calculating all paths between an s-d pair
In-Reply-To: <Pine.GSO.4.33.0108141254200.9926-100000@crete.csi.forth.gr>
Message-ID: <Pine.LNX.4.21.0108141901060.16037-100000@erwin.cs.sun.ac.za>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

> I am searching for an algorithm for calculating all paths between an s-d
> pair. Can you provide me pointers to books or URLs?
It depends on the routing model you want to implement. Is it an off-line
or an on-line model. If it is an off-line model, you can use either the
"flow deviation" algorithm by Kleinrock which allows you to calculate not
only the paths but also their assigned bandwidth. If you just want to
calculate the paths, you can use the "KSP" (k-shortest paths) method which
calculates link-disjoint paths. There are some research work done on that
topic (path selection and bandwidth allocation in MPLS networks) and two
papers submitted at MASCOTS2001 and ITCOM2001 will be available at
http://www.cs.sun.ac.za/COE early september.

Hope that i am not out of track

Antoine



From owner-mpls@UU.NET  Tue Aug 14 17:12:28 2001
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 RAA15262
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 17:12: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 QQlcca23189;
	Tue, 14 Aug 2001 21:11:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcca10186
	for mpls-outgoing; Tue, 14 Aug 2001 21:11:06 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 QQlcca10103
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 21:10:47 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 QQlcca22962
	for <mpls@UU.NET>; Tue, 14 Aug 2001 21:07:40 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlcca08056
	for <mpls@UU.NET>; Tue, 14 Aug 2001 21:07:40 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA29586
	for <mpls@UU.NET>; Tue, 14 Aug 2001 21:07:39 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001081414071925035
 for <mpls@UU.NET>; Tue, 14 Aug 2001 14:07:19 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <Q82P44HS>; Tue, 14 Aug 2001 14:08:38 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA01B@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: MPLS UUNET Mailing List <mpls@UU.NET>
Subject: RE: Doubt on Make Before Break Concept
Date: Tue, 14 Aug 2001 14:07:32 -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

When the receiver receives the new Path message, it triggers a state change.
A new Resv message will be sent out, with the new sender added. 

When the transit nodes process the new Resv message, since there is a new
sender in the Resv message, it also triggers a state change. Resv message
will then be sent out at each of the transit node. 

If the new path tranverses through different nodes, at the new nodes, the
Resv message also triggers a state change, since it is new, resulting in the
Resv message being sent out.

In other words, the Resv message is not absorbed anywhere, as you suggested.

Samething applies to increase of bandwidth.

Hope this helps.

-Mark

> -----Original Message-----
> From: Rajesh P Jain [mailto:rpjain@sasken.com]
> Sent: Monday, August 13, 2001 8:00 AM
> To: MPLS UUNET Mailing List; mpls-ops@mplsrc.com
> Subject: Doubt on Make Before Break Concept
> 
> 
> Hi,
>                     I have some doubts on Smooth Re-Routing of LSP
> Tunnels.
> 
> 1. As I understand the draft, the make-before-break (Smooth 
> Re-Routing)
> should be initiated by the Sender Node (Path Message is sent new with
> new ERO object and ofcourse with a different LSP ID in the
> SENDER_TEMPLATE ). The receiver receives this Path Message.
> 
> 2. Now, the receiver HAS to send a RESERVE message with SE reservation
> style (Of course with Filter spec list containing the 
> SENDER_TEMPLATE of
> the old Path Message and SENDER_TEMPLATE of new Path Message i.e they
> differ only in their LSP ID's, and of course ERO's).
> 
> 3. Now, the New Path Message received  is AS GOOD AS A New Sender for
> this receiver and hence it MAY NOT send a RESERVE Message for this
> sender (The receiver sends only if it wants some reservation for this
> sender).
> 
> 4. In case, if the receiver chooses not to send the reserve message,
> then Smooth Re-Route WILL NOT happen.
> 
>                     So, can anyone explain whether the Smooth 
> Re-Routing
> is Sender-Based  or Receiver -Based (Who has the control of Re-Routing
> the traffic ??) ???
> 
>                     In case of Increase in Band-width (For a 
> particular
> LSP), the Sender indicates the increase in band-width BUT still the
> Receiver HAS to send the Reserve message for this increase in the
> Band-width. So, the same problem holds good for this case also????
> 
>                     Am I missing something???? Please throw light on
> this issue possibly with an example.
> 
> TIA
>         Rajesh P Jain
> 
> 
> 
> 


From owner-mpls@UU.NET  Tue Aug 14 19:46:15 2001
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 TAA17334
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 19:46:15 -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 QQlcck00815;
	Tue, 14 Aug 2001 23:44:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcck29647
	for mpls-outgoing; Tue, 14 Aug 2001 23:43: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 QQlcck29640
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 23:43:35 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 QQlcck23375
	for <mpls@UU.NET>; Tue, 14 Aug 2001 23:42:20 GMT
Received: from iscan.toyocom.co.jp by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.toyocom.co.jp [210.232.21.1])
	id QQlcck28087
	for <mpls@UU.NET>; Tue, 14 Aug 2001 23:42:18 GMT
Received: from iscan.toyocom.co.jp (localhost [127.0.0.1])
	by iscan.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA10397
	for <mpls@UU.NET>; Wed, 15 Aug 2001 08:41:23 +0900
Received: from smtp.toyocom.co.jp (smtp.toyocom.co.jp [10.1.11.24])
	by iscan.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA10384
	for <mpls@UU.NET>; Wed, 15 Aug 2001 08:41:23 +0900
Received: from gateway4 ([172.16.72.141])
	by smtp.toyocom.co.jp (8.9.3+3.2W/3.7W) with ESMTP id IAA05570
	for <mpls@UU.NET>; Wed, 15 Aug 2001 08:48:52 +0900
Message-Id: <200108142348.IAA05570@smtp.toyocom.co.jp>
Date: Wed, 15 Aug 2001 08:42:44 +0900
From: Mohit Misra <MohitM@netbrahma.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: MPLS over FR
MIME-Version: 1.0
Content-Type: text/plain;
 charset="iso-8859-1"
X-UIDL: 148ae57fded750fd45430ead75318034
X-Mailer: Becky! ver. 2.00.03
Sender: owner-mpls@UU.NET
Precedence: bulk

I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
are connected over a FR cloud and intermediate FR switches are MPLS unaware.
A label mapping (DLCI) is negotiated between them. When the upstream node
sends a labled packet with the negotiated DLCI, the intermediate switches
will modify this value and finally it will reach the downstream node with a
different DLCI value (which was not negotiated ). ATM solves this problem by
VCID notification. How it is resolved in FR case ?
				/Mohit



From owner-mpls@UU.NET  Tue Aug 14 19:50:13 2001
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 TAA17391
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 19:50:13 -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 QQlccl01079;
	Tue, 14 Aug 2001 23:50:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlccl00089
	for mpls-outgoing; Tue, 14 Aug 2001 23:49:46 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 QQlccl00074
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 23:49:37 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 QQlcck27516
	for <mpls@UU.net>; Tue, 14 Aug 2001 23:42:48 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f112.law3.hotmail.com [209.185.241.112])
	id QQlcck22074
	for <mpls@UU.net>; Tue, 14 Aug 2001 23:42:48 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 14 Aug 2001 16:42:47 -0700
Received: from 38.186.47.9 by lw3fd.law3.hotmail.msn.com with HTTP;	Tue, 14 Aug 2001 23:42:47 GMT
X-Originating-IP: [38.186.47.9]
From: "Gangadharan Ramakrishnan" <gangadharanr@hotmail.com>
To: mpls@UU.NET
Cc: morekonda@hotmail.com
Date: Tue, 14 Aug 2001 23:42:47 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F112wsazVDVuodAHK0300009d10@hotmail.com>
X-OriginalArrivalTime: 14 Aug 2001 23:42:47.0922 (UTC) FILETIME=[D2CEA520:01C1251A]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I'm new to this MPLS domain. I have a question on MPLS Arch (rfc3031). I 
think, may be some one else might have asked this question earlier. Well, 
the question is,

Why the bindings are assigned by the downstream LSR and why not the upstream 
LSR? What makes the architecture to expect aggsinement and distribution of 
label bindings from downstream to upstream not the other way?

Thanks in advance....

Cheers,
ganges....

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Tue Aug 14 20:58:26 2001
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 UAA18654
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 20:58:25 -0400 (EDT)
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 QQlccp10955;
	Wed, 15 Aug 2001 00:58:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlccp24104
	for mpls-outgoing; Wed, 15 Aug 2001 00:57:42 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 QQlccp24099
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 00:57:34 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 QQlccp24342
	for <mpls@uu.net>; Wed, 15 Aug 2001 00:56:30 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlccp11652
	for <mpls@uu.net>; Wed, 15 Aug 2001 00:56:29 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA01158 for mpls@uu.net; Tue, 14 Aug 2001 20:56:28 -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 QQlccp24006
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 00:56: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 QQlccp23470
	for <mpls@UU.NET>; Wed, 15 Aug 2001 00:51:34 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 QQlccp01423
	for <mpls@UU.NET>; Wed, 15 Aug 2001 00:51:34 GMT
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7F0nZD28567;
	Tue, 14 Aug 2001 17:49:35 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f7F0pPd08279;
	Tue, 14 Aug 2001 17:51:25 -0700 (PDT)
Received: from ZAZIZ-W2K.cisco.com (dhcp-171-69-103-139.cisco.com [171.69.103.139]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA21516; Tue, 14 Aug 2001 17:51:24 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010814173808.048bc4e8@ce-nfs-1.cisco.com>
X-Sender: zaziz@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 Aug 2001 17:51:20 -0700
To: Mohit Misra <MohitM@netbrahma.com>
From: Zaheer Aziz <zaziz@cisco.com>
Subject: Re: MPLS over FR
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <200108142348.IAA05570@smtp.toyocom.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 08:42 AM 8/15/2001 +0900, Mohit Misra wrote:
>I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
>are connected over a FR cloud and intermediate FR switches are MPLS unaware.
>A label mapping (DLCI) is negotiated between them. When the upstream node
>sends a labled packet with the negotiated DLCI,


LSRA---dlci 1--FR-SW1-----FR-SW2--dlci 2---LSRB----FEC X

LSRA and LSRB are LDP peers and has exchanged label (L) for FEC X.
FR-SW are not running MPLS.

This negotiated label (L) through LDP is put in MPLS Header for any traffic 
destined for FEC F, but
to reach LSRB, LSRA uses DLCI 1 which FR-SW1 understands and forwards it to 
SW2 which maps DLC2
to reach LSRB.
Now LSR B receives MPLS header with label L and it should have a mapping in 
LFIB to forward appropriately.

Thanks
Zaheer




>the intermediate switches
>will modify this value and finally it will reach the downstream node with a
>different DLCI value (which was not negotiated ). ATM solves this problem by
>VCID notification. How it is resolved in FR case ?
>                                 /Mohit



From owner-mpls@UU.NET  Tue Aug 14 21:24:14 2001
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 VAA19073
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 21:24:14 -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 QQlccr21447;
	Wed, 15 Aug 2001 01:23:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlccr15334
	for mpls-outgoing; Wed, 15 Aug 2001 01:23:39 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 QQlccr15329
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 01:23:37 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 QQlccr16139
	for <mpls@uu.net>; Wed, 15 Aug 2001 01:22:20 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlccr18883
	for <mpls@uu.net>; Wed, 15 Aug 2001 01:22:20 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA02653 for mpls@uu.net; Tue, 14 Aug 2001 21:22:15 -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 QQlccr15268
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 01:21:55 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 QQlccr20850
	for <mpls@UU.NET>; Wed, 15 Aug 2001 01:18:21 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQlccr13311
	for <mpls@UU.NET>; Wed, 15 Aug 2001 01:18:20 GMT
Received: from cisco.com (sj-cse-155.cisco.com [171.68.200.172])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA07198;
	Tue, 14 Aug 2001 18:18:20 -0700 (PDT)
Message-ID: <3B79CDD6.8BB30EEA@cisco.com>
Date: Tue, 14 Aug 2001 18:18:14 -0700
From: "Gopal@Cisco" <gnaganab@cisco.com>
Organization: Cisco Systems Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>
CC: mpls@UU.NET, morekonda@hotmail.com
Subject: Re: 
References: <F112wsazVDVuodAHK0300009d10@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ganges,
prefix-X------Rd--------Ru--

Data packets flow from upstream to downstream towards the destination.
Ru will use the label distributed by Rd to impose/insert/swap into the
data packet. Rd will take the forwarding decision based on the label it
looks in the data packet.
So it is necessary for Ru to use the label distributed by Rd for proper
transmission.
"> Why the bindings are assigned by the downstream LSR"--> i believe you
meant labels are assigned.....

" What makes the architecture to expect aggsinement and distribution of
> label bindings from downstream to upstream not the other way?"
> 
Label distribution can happen bothways(depending on distribution
methods: unsolicited or ondemand). However, label assignement depends on
the routing table. Ru's routing table point to Rd as the next-hop for
prefix-X. Hence Ru will use the label distributed by Rd while forwarding
data to preix X. however Rd's routing entry to prefix-X will not point
to Ru as the next-hop. Hence Rd will not use the label distributed by Ru
for prefix X.

rgds,
gopal


Gangadharan Ramakrishnan wrote:
> 
> Hi,
> 
> I'm new to this MPLS domain. I have a question on MPLS Arch (rfc3031). I
> think, may be some one else might have asked this question earlier. Well,
> the question is,
> 
> Why the bindings are assigned by the downstream LSR and why not the upstream
> LSR? What makes the architecture to expect aggsinement and distribution of
> label bindings from downstream to upstream not the other way?
> 
> Thanks in advance....
> 
> Cheers,
> ganges....
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

-- 
Gopal(www-tac/~gnaganab),CCIE#6209,1.408.525.9922,RP-TAC,9:00AM-5:00PM(PST)
TAC Tools/Doc's:    http://www.cisco.com/tac/
TAC Top Issues:     http://www.cisco.com/kobayashi/support/top_issues/
Attach your email to a case: attach@cisco.com , keep the case# in
'Subject'



From owner-mpls@UU.NET  Tue Aug 14 22:53:07 2001
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 WAA21632
	for <mpls-archive@lists.ietf.org>; Tue, 14 Aug 2001 22:53:06 -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 QQlccx22939;
	Wed, 15 Aug 2001 02:52:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlccx11111
	for mpls-outgoing; Wed, 15 Aug 2001 02:52: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 QQlccx11106
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 02:52:29 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 QQlccx04533
	for <mpls@UU.NET>; Wed, 15 Aug 2001 02:52:14 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f68.law3.hotmail.com [209.185.241.68])
	id QQlccx01385
	for <mpls@UU.NET>; Wed, 15 Aug 2001 02:52:14 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 14 Aug 2001 19:52:13 -0700
Received: from 38.186.47.9 by lw3fd.law3.hotmail.msn.com with HTTP;	Wed, 15 Aug 2001 02:52:12 GMT
X-Originating-IP: [38.186.47.9]
From: "Gangadharan Ramakrishnan" <gangadharanr@hotmail.com>
To: gnaganab@cisco.com
Cc: mpls@UU.NET, morekonda@hotmail.com
Subject: Re: Label assignment and distribution
Date: Wed, 15 Aug 2001 02:52:12 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F6839x6HHGNZ4mF1IT10000a04c@hotmail.com>
X-OriginalArrivalTime: 15 Aug 2001 02:52:13.0762 (UTC) FILETIME=[49603220:01C12535]
Sender: owner-mpls@UU.NET
Precedence: bulk

Gopal,
See my comments inline....

Cheers,
ganges...

>From: "Gopal@Cisco" <gnaganab@cisco.com>
>To: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>
>CC: mpls@UU.NET, morekonda@hotmail.com
>Subject: Re:
>Date: Tue, 14 Aug 2001 18:18:14 -0700
>
>Ganges,
>prefix-X------Rd--------Ru--
>
>Data packets flow from upstream to downstream towards the destination.
>Ru will use the label distributed by Rd to impose/insert/swap into the
>data packet. Rd will take the forwarding decision based on the label it
>looks in the data packet.
>So it is necessary for Ru to use the label distributed by Rd for proper
>transmission.
>"> Why the bindings are assigned by the downstream LSR"--> i believe you
>meant labels are assigned.....
Ganges::; Yes, i mean that exactly.
>
>" What makes the architecture to expect aggsinement and distribution of
> > label bindings from downstream to upstream not the other way?"
> >
>Label distribution can happen bothways(depending on distribution
>methods: unsolicited or ondemand). However, label assignement depends on 
>the routing table. Ru's routing table point to Rd as the next-hop for

Ganges:::: Well, but the rfc says that,
3.4. Label Assignment and Distribution

   In the MPLS architecture, the decision to bind a particular label L
   to a particular FEC F is made by the LSR which is DOWNSTREAM with
   respect to that binding.  The downstream LSR then informs the
   upstream LSR of the binding.  Thus labels are "downstream-assigned",
   and label bindings are distributed in the "downstream to upstream"
   direction.

In both distribution methods: Unsolicited or OnDemand, is a way how Ru gets 
the label assignment information and it is not specifying who is 
distributing the label assignment. DOWNSTREAM LSR is the one which 
distributes the label assiagnment in both the methods. Please, correct me if 
i'm wrong.

>prefix-X. Hence Ru will use the label distributed by Rd while forwarding
>data to preix X. however Rd's routing entry to prefix-X will not point
>to Ru as the next-hop. Hence Rd will not use the label distributed by Ru
>for prefix X.
>
>rgds,
>gopal
>
>
>Gangadharan Ramakrishnan wrote:
> >
> > Hi,
> >
> > I'm new to this MPLS domain. I have a question on MPLS Arch (rfc3031). I
> > think, may be some one else might have asked this question earlier. 
>Well,
> > the question is,
> >
> > Why the bindings are assigned by the downstream LSR and why not the 
>upstream
> > LSR? What makes the architecture to expect aggsinement and distribution 
>of
> > label bindings from downstream to upstream not the other way?
> >
> > Thanks in advance....
> >
> > Cheers,
> > ganges....
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
>
>--
>Gopal(www-tac/~gnaganab),CCIE#6209,1.408.525.9922,RP-TAC,9:00AM-5:00PM(PST)
>TAC Tools/Doc's:    http://www.cisco.com/tac/
>TAC Top Issues:     http://www.cisco.com/kobayashi/support/top_issues/
>Attach your email to a case: attach@cisco.com , keep the case# in
>'Subject'


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 15 07:04:40 2001
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 HAA12658
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 07:04:39 -0400 (EDT)
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 QQlcee20610;
	Wed, 15 Aug 2001 11:03:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcee28883
	for mpls-outgoing; Wed, 15 Aug 2001 11:02:48 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 QQlcee28876
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 11:02: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 QQlcee15480
	for <mpls@UU.NET>; Wed, 15 Aug 2001 11:02:18 GMT
From: neil.2.harrison@bt.com
Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQlcee19270
	for <mpls@UU.NET>; Wed, 15 Aug 2001 11:02:17 GMT
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <QS55T6TX>; Wed, 15 Aug 2001 12:02:29 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E8915F7@MBDDMKNT01>
To: pingpan@juniper.net, mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 12:02:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping,

Can you please explain (i) what causes such RSVP nodal re-starts in the 1st
place and (ii) how frequently you see them per reason (I assume they must be
of some concern to have written this ID)?

Thanks, Neil

> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: 24 July 2001 17:45
> To: mpls-list
> Subject: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
> 
> 
> Hi,
> 
> Here is an updated version on draft, Graceful Restart Mechanism for
> RSVP-TE. We believe that this is useful and important for LSR failure
> recovery. We have explained further on the use of Restart-Time and
> Recovery-Time in this revision.
> 
> Thanks!
> 
> - Ping
> 


From owner-mpls@UU.NET  Wed Aug 15 09:08:57 2001
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 JAA18428
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 09:08:57 -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 QQlcem00222;
	Wed, 15 Aug 2001 13:07:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcem22216
	for mpls-outgoing; Wed, 15 Aug 2001 13:07:09 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 QQlcem22161
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 13:07:08 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 QQlcem20639
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:04:28 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlcem15125
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:04:28 GMT
Message-ID: <3B7A7355.A9422730@sandburst.com>
Date: Wed, 15 Aug 2001 09:04:21 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Mohit Misra <MohitM@netbrahma.com>
Cc: MPLS Mailing List <mpls@UU.NET>
Subject: Re: MPLS over FR
References: <200108142348.IAA05570@smtp.toyocom.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mohit,

    Please read section 6 of RFC 3034 - in particular the very first statement
which says (in part):

"To support label switching a Frame Relay Switch MUST implement the
   control component of label switching, ..."

--
Eric Gray

You wrote:

> I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
> are connected over a FR cloud and intermediate FR switches are MPLS unaware.
> A label mapping (DLCI) is negotiated between them. When the upstream node
> sends a labled packet with the negotiated DLCI, the intermediate switches
> will modify this value and finally it will reach the downstream node with a
> different DLCI value (which was not negotiated ). ATM solves this problem by
> VCID notification. How it is resolved in FR case ?
>                                 /Mohit



From owner-mpls@UU.NET  Wed Aug 15 09:09:54 2001
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 JAA18500
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 09:09:54 -0400 (EDT)
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 QQlcem23380;
	Wed, 15 Aug 2001 13:09:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcem26765
	for mpls-outgoing; Wed, 15 Aug 2001 13:09:23 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 QQlcem26756
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 13:09:17 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 QQlcem23277
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:07:43 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlcem00824
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:07:43 GMT
Message-ID: <3B7A7418.1A6E7397@sandburst.com>
Date: Wed, 15 Aug 2001 09:07:36 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>
Cc: mpls@UU.NET, morekonda@hotmail.com
Subject: Re: 
References: <F112wsazVDVuodAHK0300009d10@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ganges,

    At this point, 'because' would be more than sufficient reason.

    Think about the reason why you would want to use MPLS labels.  What
is an implementor likely to want to use an incoming label for?  How would
that work if the receiver doesn't get to pick the label?

--
Eric Gray

You wrote:

> Hi,
>
> I'm new to this MPLS domain. I have a question on MPLS Arch (rfc3031). I
> think, may be some one else might have asked this question earlier. Well,
> the question is,
>
> Why the bindings are assigned by the downstream LSR and why not the upstream
> LSR? What makes the architecture to expect aggsinement and distribution of
> label bindings from downstream to upstream not the other way?
>
> Thanks in advance....
>
> Cheers,
> ganges....
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 15 09:38:20 2001
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 JAA19946
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 09:38:20 -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 QQlceo10663;
	Wed, 15 Aug 2001 13:36:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlceo29443
	for mpls-outgoing; Wed, 15 Aug 2001 13:36:01 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 QQlceo29406
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 13:35:56 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 QQlceo24487
	for <mpls@uu.net>; Wed, 15 Aug 2001 13:35:17 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlceo03194
	for <mpls@uu.net>; Wed, 15 Aug 2001 13:35:16 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA22654
	for <mpls@uu.net>; Wed, 15 Aug 2001 09:35:15 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04658 for mpls@uu.net; Wed, 15 Aug 2001 09:34:53 -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 QQlcby18431
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 14 Aug 2001 20:37:40 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 QQlcby19732
	for <mpls@UU.NET>; Tue, 14 Aug 2001 20:37:22 GMT
Received: from photonics.eecs.berkeley.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: photonics.EECS.Berkeley.EDU [169.229.34.215])
	id QQlcby28958
	for <mpls@UU.NET>; Tue, 14 Aug 2001 20:37:21 GMT
Received: from LTJLS (dhcp-139-216.EECS.Berkeley.EDU [128.32.139.216])
	by photonics.eecs.berkeley.edu (8.9.3+Sun/8.9.1) with SMTP id NAA27348;
	Tue, 14 Aug 2001 13:37:14 -0700 (PDT)
From: "John Strand" <jls@photonics.eecs.berkeley.edu>
To: "Pin-Han Ho" <8ph5@qlink.queensu.ca>,
        "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>, <mpls-ops@mplsrc.com>,
        <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>
Subject: RE: [IP-Optical] An algorithm for calculating all paths between an s-d pair
Date: Tue, 14 Aug 2001 13:38:00 -0700
Message-ID: <NCBBJJFHPDCPBCAKHOIHOEJKPOAB.jls@photonics.eecs.berkeley.edu>
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)
Importance: Normal
In-Reply-To: <02fc01c124fa$64432330$209f8d18@Arthur>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think you need to define your problem better. I assume you dont want
loops,
for example. For most apps there are lots of paths that dont make any
sense - for example hopping repeatedly from one side of the network to the
other. Also, unless you are working in quite a small network a complete
path list will be HUGE.

John

-----Original Message-----
From: ip-optical-admin@lists.bell-labs.com
[mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Pin-Han Ho
Sent: Tuesday, August 14, 2001 12:51 PM
To: Chrysostomos Tziouvaras; mpls-ops@mplsrc.com; mpls@UU.NET;
IP-Optical@lists.bell-labs.com
Subject: Re: [IP-Optical] An algorithm for calculating all paths between
an s-d pair


What kind of paths do you need? Shortest ones?
----- Original Message -----
From: "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
To: <mpls-ops@mplsrc.com>; <mpls@UU.NET>; <IP-Optical@lists.bell-labs.com>
Sent: Tuesday, August 14, 2001 2:58 AM
Subject: [IP-Optical] An algorithm for calculating all paths between an s-d
pair


Hi,
I am searching for an algorithm for calculating all paths between an s-d
pair. Can you provide me pointers to books or URLs?

Thanks
Chrysostomos





_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical



From owner-mpls@UU.NET  Wed Aug 15 09:41:44 2001
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 JAA20232
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 09:41:44 -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 QQlceo21488;
	Wed, 15 Aug 2001 13:41:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlceo29793
	for mpls-outgoing; Wed, 15 Aug 2001 13:41:03 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 QQlceo29788
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 13:41:02 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 QQlceo12024
	for <mpls@uu.net>; Wed, 15 Aug 2001 13:36:07 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlceo10226
	for <mpls@uu.net>; Wed, 15 Aug 2001 13:36:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA03957 for mpls@uu.net; Wed, 15 Aug 2001 09:36:05 -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 QQlceo29399
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 13:35:51 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 QQlceo23729
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:34:04 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 QQlceo10579
	for <mpls@UU.NET>; Wed, 15 Aug 2001 13:34:03 GMT
Received: from juniper.net ([172.16.167.238])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FDXv018263;
	Wed, 15 Aug 2001 06:33:57 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7A7A4F.67B8F9CB@juniper.net>
Date: Wed, 15 Aug 2001 06:34:07 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <B9571FDEBD3DD21181E500606DD5EE050E8915F7@MBDDMKNT01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

neil.2.harrison@bt.com wrote:
> 
> Ping,
> 
> Can you please explain (i) what causes such RSVP nodal re-starts in the 1st
> place 

Neil,

The same cause why routing engine may fail in the network, while data
forwarding is fine. The graceful restart technique is not new, as being
define for IGP and BGP already.

> and (ii) how frequently you see them per reason (I assume they must be
> of some concern to have written this ID)?
>

If you believe the data collected at
http://www.merit.edu/ipma/instability/, network does run into instable
conditions. Our draft is to localize the problem when that happens.

- Ping



From owner-mpls@UU.NET  Wed Aug 15 10:23:52 2001
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 KAA21977
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 10:23:52 -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 QQlcer20032;
	Wed, 15 Aug 2001 14:21:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcer22370
	for mpls-outgoing; Wed, 15 Aug 2001 14:21:21 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 QQlcer22361
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 14:21:11 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 QQlcer25624
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:19:56 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcer26776
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:19:50 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FEJLp16191
	for <mpls@UU.NET>; Wed, 15 Aug 2001 10:19:21 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 15 Aug 2001 10:19:19 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YJ0VN8>; Wed, 15 Aug 2001 10:19:21 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3429DA9C@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Ping Pan <pingpan@juniper.net>, neil.2.harrison@bt.com
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 10:19:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12595.45854040"
X-Orig: <dallan@americasm01.nt.com>
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_01C12595.45854040
Content-Type: text/plain;
	charset="iso-8859-1"

Ping:

I'm having trouble correlating route flap instability data with your problem
statement. Similarly I have trouble with the analogy between graceful
restart for routing (which has a fair chasm between it and forwarding) and a
soft state signalling protocol which would appear to require a much tighter
coupling.

Is this really more applicable to GMPLS and should be tagged as such?

rgds
Dave

-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Wednesday, August 15, 2001 9:34 AM
To: neil.2.harrison@bt.com
Cc: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]


neil.2.harrison@bt.com wrote:
> 
> Ping,
> 
> Can you please explain (i) what causes such RSVP nodal re-starts in the
1st
> place 

Neil,

The same cause why routing engine may fail in the network, while data
forwarding is fine. The graceful restart technique is not new, as being
define for IGP and BGP already.

> and (ii) how frequently you see them per reason (I assume they must be
> of some concern to have written this ID)?
>

If you believe the data collected at
http://www.merit.edu/ipma/instability/, network does run into instable
conditions. Our draft is to localize the problem when that happens.

- Ping


------_=_NextPart_001_01C12595.45854040
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.2654.89">
<TITLE>RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ping:</FONT>
</P>

<P><FONT SIZE=3D2>I'm having trouble correlating route flap instability =
data with your problem statement. Similarly I have trouble with the =
analogy between graceful restart for routing (which has a fair chasm =
between it and forwarding) and a soft state signalling protocol which =
would appear to require a much tighter coupling.</FONT></P>

<P><FONT SIZE=3D2>Is this really more applicable to GMPLS and should be =
tagged as such?</FONT>
</P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ping Pan [<A =
HREF=3D"mailto:pingpan@juniper.net">mailto:pingpan@juniper.net</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 9:34 AM</FONT>
<BR><FONT SIZE=3D2>To: neil.2.harrison@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Fwd: I-D =
ACTION:draft-pan-rsvp-te-restart-01.txt]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>neil.2.harrison@bt.com wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ping,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Can you please explain (i) what causes such =
RSVP nodal re-starts in the 1st</FONT>
<BR><FONT SIZE=3D2>&gt; place </FONT>
</P>

<P><FONT SIZE=3D2>Neil,</FONT>
</P>

<P><FONT SIZE=3D2>The same cause why routing engine may fail in the =
network, while data</FONT>
<BR><FONT SIZE=3D2>forwarding is fine. The graceful restart technique =
is not new, as being</FONT>
<BR><FONT SIZE=3D2>define for IGP and BGP already.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; and (ii) how frequently you see them per reason =
(I assume they must be</FONT>
<BR><FONT SIZE=3D2>&gt; of some concern to have written this =
ID)?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>If you believe the data collected at</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.merit.edu/ipma/instability/" =
TARGET=3D"_blank">http://www.merit.edu/ipma/instability/</A>, network =
does run into instable</FONT>
<BR><FONT SIZE=3D2>conditions. Our draft is to localize the problem =
when that happens.</FONT>
</P>

<P><FONT SIZE=3D2>- Ping</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12595.45854040--


From owner-mpls@UU.NET  Wed Aug 15 10:53:35 2001
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 KAA22933
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 10:53: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 QQlcet02850;
	Wed, 15 Aug 2001 14:48:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcet24626
	for mpls-outgoing; Wed, 15 Aug 2001 14:48: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 QQlcet24618
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 14:48: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 QQlces23410
	for <mpls@uu.net>; Wed, 15 Aug 2001 14:42:58 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlces18764
	for <mpls@uu.net>; Wed, 15 Aug 2001 14:42:58 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA09540 for mpls@uu.net; Wed, 15 Aug 2001 10:42:56 -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 QQlces24052
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 14:42: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 QQlces19655
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:33:36 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 QQlces19858
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:33:36 GMT
Received: from juniper.net ([172.16.167.238])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FEWq019806;
	Wed, 15 Aug 2001 07:32:52 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7A881E.9D61768B@juniper.net>
Date: Wed, 15 Aug 2001 07:33:02 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
CC: neil.2.harrison@bt.com, mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DA9C@zcard0ka.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> David Allan wrote:
> 
> Ping:
> 
> I'm having trouble correlating route flap instability data with your
> problem statement. Similarly I have trouble with the analogy between
> graceful restart for routing (which has a fair chasm between it and
> forwarding) and a soft state signalling protocol which would appear to
> require a much tighter coupling.
> 

Dave,

The point was that in the network, there could be cases where the
control engine is crashed while the data forwarding engine is fine. To
reduce the side-effects, control protocols (routing and signaling)
should use various graceful restart mechanisms. In our draft, I think
the control and forwarding are tightly coupled. Please let me know why
you think otherwise.

> Is this really more applicable to GMPLS and should be tagged as such?
> 

Both GMPLS and MPLS can benefit from this. In case of GMPLS, graceful
restart can be used to recover from control channel failure.

Regards,

- Ping



From owner-mpls@UU.NET  Wed Aug 15 11:28:24 2001
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 LAA23678
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 11:28: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 QQlcev16229;
	Wed, 15 Aug 2001 15:26:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcev17781
	for mpls-outgoing; Wed, 15 Aug 2001 15:26:27 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 QQlcev17770
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 15:26:26 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 QQlcev07756
	for <mpls@UU.NET>; Wed, 15 Aug 2001 15:22:22 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcev08912
	for <mpls@UU.NET>; Wed, 15 Aug 2001 15:22:14 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FFLRp26028
	for <mpls@UU.NET>; Wed, 15 Aug 2001 11:21:27 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 15 Aug 2001 11:21:17 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YJ0XKF>; Wed, 15 Aug 2001 11:21:18 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Ping Pan <pingpan@juniper.net>
Cc: neil.2.harrison@bt.com, mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 11:21:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1259D.EA38D1D0"
X-Orig: <dallan@americasm01.nt.com>
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_01C1259D.EA38D1D0
Content-Type: text/plain;
	charset="iso-8859-1"

Ping:

I don't see control and data planes as tightly coupled in your proposal.
You're clearly operationally divorcing the two (which is the trend you refer
to for BGP, IGP and now RSVP restart mechanisms). Not that this is a bad
thing, it just cannot be done in isolation. You (and others, my point is not
specific to this I-D) are eliminating all forms of fate sharing between the
control and data planes, despite (in the MPLS case vs. GMPLS) the use of
common resources in the control and data plane adjacencies. 

This may suggest that control plane failure is today significantly more
frequent than data plane or link failure and there is a real problem to
solve, but adding restart mechanisms to everything in the control plane is
not the complete answer. Every divorce in the fate-sharing world adds a new
failure detection requirement and more maintenance messaging.

cheers
Dave



-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Wednesday, August 15, 2001 10:33 AM
To: Allan, David [CAR:NS00:EXCH]
Cc: neil.2.harrison@bt.com; mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]


> David Allan wrote:
> 
> Ping:
> 
> I'm having trouble correlating route flap instability data with your
> problem statement. Similarly I have trouble with the analogy between
> graceful restart for routing (which has a fair chasm between it and
> forwarding) and a soft state signalling protocol which would appear to
> require a much tighter coupling.
> 

Dave,

The point was that in the network, there could be cases where the
control engine is crashed while the data forwarding engine is fine. To
reduce the side-effects, control protocols (routing and signaling)
should use various graceful restart mechanisms. In our draft, I think
the control and forwarding are tightly coupled. Please let me know why
you think otherwise.

> Is this really more applicable to GMPLS and should be tagged as such?
> 

Both GMPLS and MPLS can benefit from this. In case of GMPLS, graceful
restart can be used to recover from control channel failure.

Regards,

- Ping

------_=_NextPart_001_01C1259D.EA38D1D0
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.2654.89">
<TITLE>RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ping:</FONT>
</P>

<P><FONT SIZE=3D2>I don't see control and data planes as tightly =
coupled in your proposal. You're clearly operationally divorcing the =
two (which is the trend you refer to for BGP, IGP and now RSVP restart =
mechanisms). Not that this is a bad thing, it just cannot be done in =
isolation. You (and others, my point is not specific to this I-D) are =
eliminating all forms of fate sharing between the control and data =
planes, despite (in the MPLS case vs. GMPLS) the use of common =
resources in the control and data plane adjacencies. </FONT></P>

<P><FONT SIZE=3D2>This may suggest that control plane failure is today =
significantly more frequent than data plane or link failure and there =
is a real problem to solve, but adding restart mechanisms to everything =
in the control plane is not the complete answer. Every divorce in the =
fate-sharing world adds a new failure detection requirement and more =
maintenance messaging.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ping Pan [<A =
HREF=3D"mailto:pingpan@juniper.net">mailto:pingpan@juniper.net</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 10:33 AM</FONT>
<BR><FONT SIZE=3D2>To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: neil.2.harrison@bt.com; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Fwd: I-D =
ACTION:draft-pan-rsvp-te-restart-01.txt]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ping:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm having trouble correlating route flap =
instability data with your</FONT>
<BR><FONT SIZE=3D2>&gt; problem statement. Similarly I have trouble =
with the analogy between</FONT>
<BR><FONT SIZE=3D2>&gt; graceful restart for routing (which has a fair =
chasm between it and</FONT>
<BR><FONT SIZE=3D2>&gt; forwarding) and a soft state signalling =
protocol which would appear to</FONT>
<BR><FONT SIZE=3D2>&gt; require a much tighter coupling.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Dave,</FONT>
</P>

<P><FONT SIZE=3D2>The point was that in the network, there could be =
cases where the</FONT>
<BR><FONT SIZE=3D2>control engine is crashed while the data forwarding =
engine is fine. To</FONT>
<BR><FONT SIZE=3D2>reduce the side-effects, control protocols (routing =
and signaling)</FONT>
<BR><FONT SIZE=3D2>should use various graceful restart mechanisms. In =
our draft, I think</FONT>
<BR><FONT SIZE=3D2>the control and forwarding are tightly coupled. =
Please let me know why</FONT>
<BR><FONT SIZE=3D2>you think otherwise.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Is this really more applicable to GMPLS and =
should be tagged as such?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Both GMPLS and MPLS can benefit from this. In case of =
GMPLS, graceful</FONT>
<BR><FONT SIZE=3D2>restart can be used to recover from control channel =
failure.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>- Ping</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1259D.EA38D1D0--


From owner-mpls@UU.NET  Wed Aug 15 13:21:40 2001
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 NAA26868
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 13:21:40 -0400 (EDT)
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 QQlcfd26823;
	Wed, 15 Aug 2001 17:21:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfd06989
	for mpls-outgoing; Wed, 15 Aug 2001 17:21: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 QQlcfd06984
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:21:01 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 QQlcfd03202
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:19:20 GMT
From: neil.2.harrison@bt.com
Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQlcfd23380
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:19:20 GMT
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <QS554J4W>; Wed, 15 Aug 2001 18:19:32 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891603@MBDDMKNT01>
To: pingpan@juniper.net
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 18:12:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping Pan replied 15 August 2001 14:34
> > Can you please explain (i) what causes such RSVP nodal 
> re-starts in the 1st
> > place 

> The same cause why routing engine may fail in the network, while data
> forwarding is fine. The graceful restart technique is not 
> new, as being
> define for IGP and BGP already.
> 
> > and (ii) how frequently you see them per reason (I assume 
> they must be
> > of some concern to have written this ID)?
> >
> 
> If you believe the data collected at
> http://www.merit.edu/ipma/instability/, network does run into instable
> conditions. Our draft is to localize the problem when that happens.
> 
Thanks Ping.....but when I looked at the site the topic is route-flaps.
Which I can understand for LDP stability, since this is dependent on IGP/BGP
stability.  But I failed to understand why you consider this the cause of
RSVP-TE restarts.  I would have thought other mechanisms would have been the
key cause, which are (RSVP) protocol specific....maybe error events taking
out 3 hello messages perhaps?  Can you clarify what I am missing here?

regards, Neil


From owner-mpls@UU.NET  Wed Aug 15 13:28:57 2001
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 NAA27034
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 13:28:56 -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 QQlcfd18188;
	Wed, 15 Aug 2001 17:28:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfd07770
	for mpls-outgoing; Wed, 15 Aug 2001 17:28: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 QQlcfd07761
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:28:17 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 QQlcfd07951
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:20:17 GMT
Received: from arthur.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: arthur.axion.bt.co.uk [132.146.5.4])
	id QQlcfd24857
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:20:11 GMT
Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) 
          by arthur (local) with SMTP; Wed, 15 Aug 2001 18:19:30 +0100
Received: from ip-engineering.bt.com 
          by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id SAA04783;
          Wed, 15 Aug 2001 18:19:29 +0100 (BST)
Message-Id: <200108151719.SAA04783@celiborn.ip-engineering.bt.com>
X-Mailer: exmh version 2.0.3 9/28/98
To: Ping Pan <pingpan@juniper.net>
cc: David Allan <dallan@nortelnetworks.com>, neil.2.harrison@bt.com,
        mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt] 
In-reply-to: Your message of "Wed, 15 Aug 2001 07:33:02 PDT." <3B7A881E.9D61768B@juniper.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 Aug 2001 18:19:29 +0100
From: Peter Willis <pjw@ip-engineering.bt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping & The List,

Has any one observed the loss of RSVP state due simply to RSVP packet losses? 
It would seem that RSVP-TE graceful restart could aid recovery from this
situation?  Or do people expect rfc2961 to protect against problems with small
Rs & Ks?

Regards,
Peter.



From owner-mpls@UU.NET  Wed Aug 15 13:29:24 2001
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 NAA27046
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 13:29:23 -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 QQlcfd18835;
	Wed, 15 Aug 2001 17:28:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfd07791
	for mpls-outgoing; Wed, 15 Aug 2001 17:28: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 QQlcfd07786
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:28:31 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 QQlcfd06837
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:18:16 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfd15312
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:18:16 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA20940 for mpls@uu.net; Wed, 15 Aug 2001 13:18:15 -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 QQlcfd06872
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:18:01 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 QQlcfc18697
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:13:00 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQlcfc23368
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:13:00 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FHCO026428;
	Wed, 15 Aug 2001 10:12:24 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AAD82.5020307@juniper.net>
Date: Wed, 15 Aug 2001 10:12:34 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.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

David Allan wrote:

> You (and others, my 
> point is not specific to this I-D) are eliminating all forms of fate 
> sharing between the control and data planes, despite (in the MPLS case 
> vs. GMPLS) the use of common resources in the control and data plane 
> adjacencies.
> 


David,

What has been proposed in all forms of graceful restart is the message 
format on the wire. How you implement the routers to support these 
messages is totally up to the developers.


> This may suggest that control plane failure is today significantly more 
> frequent than data plane or link failure and there is a real problem to 
> solve, but adding restart mechanisms to everything in the control plane 
> is not the complete answer.


You are right. There are several solutions to help routers/networks in 
case of failure condition. Graceful restart is to solve the problem when 
control plane dies, but data forwarding is up. Fast reroute is to solve 
the problem when data forwarding is in trouble. LSP-ping (please don't 
start all those architectural beatification argument again) is to detect 
data plane black-hole problem....

Regards,

- Ping




From owner-mpls@UU.NET  Wed Aug 15 13:51:44 2001
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 NAA27765
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 13:51:44 -0400 (EDT)
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 QQlcff14036;
	Wed, 15 Aug 2001 17:51:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcff10011
	for mpls-outgoing; Wed, 15 Aug 2001 17:50: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 QQlcff10007
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:50:44 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 QQlcff17518
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:47:10 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcff01925
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:47:10 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA23597 for mpls@uu.net; Wed, 15 Aug 2001 13:47:08 -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 QQlcff09842
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:46:50 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 QQlcfe15630
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:43:24 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 QQlcfe02087
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:43:23 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FHhL028565;
	Wed, 15 Aug 2001 10:43:21 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AB4C3.7090007@juniper.net>
Date: Wed, 15 Aug 2001 10:43:31 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <B9571FDEBD3DD21181E500606DD5EE050E891603@MBDDMKNT01>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

neil.2.harrison@bt.com wrote:


>>
> Thanks Ping.....but when I looked at the site the topic is route-flaps.
> Which I can understand for LDP stability, since this is dependent on IGP/BGP
> stability.  But I failed to understand why you consider this the cause of
> RSVP-TE restarts.  I would have thought other mechanisms would have been the
> key cause, which are (RSVP) protocol specific....maybe error events taking
> out 3 hello messages perhaps?  Can you clarify what I am missing here?
> 


When a router times out a neighbor (hello messages), or the instance 
number in a neighbor's hello has changed, it means that the neighbor's 
control has restarted. If the data link is still up and running, the 
router and the neighbor can use the procedure defined in the draft to 
recover.

Hope this will help.

- Ping



From owner-mpls@UU.NET  Wed Aug 15 13:56:57 2001
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 NAA27843
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 13:56:56 -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 QQlcff02401;
	Wed, 15 Aug 2001 17:56:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcff10564
	for mpls-outgoing; Wed, 15 Aug 2001 17:56:10 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 QQlcff10548
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:56: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 QQlcff14951
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:55:08 GMT
Received: from chimera.elec.qmul.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQlcff16953
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:55:08 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15X4sl-0007WS-00
	for mpls@UU.NET; Wed, 15 Aug 2001 18:55:07 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <mpls@UU.NET>
Subject: how to set up VP and VC in ATM network
Date: Wed, 15 Aug 2001 19:02:28 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOOEPECEAA.hongwei.zhou@elec.qmul.ac.uk>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3B7AAD82.5020307@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

ATM network uses VPI and VCI to route cells. But how are the VP and VC set
up first? and what should the network operator
should do when a new ATM router is added to the network? is there any
address in ATM network like IP address in IP network?

This question seems irrelevant to the topic of the discussion group, but ATM
works very similarly to MPLS, and there is no ATM group
at uu.net, so I beg your forgive that I put the question here, and I will
appreciate every help.

Cheers,

--Henry



From owner-mpls@UU.NET  Wed Aug 15 14:02:30 2001
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 OAA27987
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 14:02:30 -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 QQlcfg11529;
	Wed, 15 Aug 2001 18:02:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfg15256
	for mpls-outgoing; Wed, 15 Aug 2001 18:01: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 QQlcfg15234
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 18:01:38 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 QQlcff21965
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:55:52 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcff18105
	for <mpls@uu.net>; Wed, 15 Aug 2001 17:55:52 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA24286 for mpls@uu.net; Wed, 15 Aug 2001 13:55:51 -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 QQlcff10449
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 17:55:00 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 QQlcff18506
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:48: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 QQlcff03685
	for <mpls@UU.NET>; Wed, 15 Aug 2001 17:48:18 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FHmC028899;
	Wed, 15 Aug 2001 10:48:12 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AB5E6.8010808@juniper.net>
Date: Wed, 15 Aug 2001 10:48:22 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Willis <pjw@ip-engineering.bt.com>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <200108151719.SAA04783@celiborn.ip-engineering.bt.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

Peter Willis wrote:

> Ping & The List,
> 
> Has any one observed the loss of RSVP state due simply to RSVP packet losses? 
> It would seem that RSVP-TE graceful restart could aid recovery from this
> situation?  Or do people expect rfc2961 to protect against problems with small
> Rs & Ks?
> 


RFC2961 defines exponential backoff to improve reliable delivery. People 
can increase K also.

- Ping





From owner-mpls@UU.NET  Wed Aug 15 14:14:35 2001
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 OAA28309
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 14:14:35 -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 QQlcfg17705;
	Wed, 15 Aug 2001 18:12:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfg01133
	for mpls-outgoing; Wed, 15 Aug 2001 18:12:21 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 QQlcfg01120
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 18:12:09 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 QQlcfg24701
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:03:23 GMT
Received: from humid.lightning.net by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: humid.lightning.net [209.51.160.9])
	id QQlcfg01775
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:03:23 GMT
Received: (qmail 43665 invoked from network); 15 Aug 2001 17:37:06 -0000
Received: from greased.lightning.net (HELO lightning.net) (216.66.51.67)
  by humid.lightning.net with SMTP; 15 Aug 2001 17:37:06 -0000
Message-ID: <3B7AB96A.36E32F67@lightning.net>
Date: Wed, 15 Aug 2001 14:03:22 -0400
From: Steve Nash <snash@lightning.net>
Organization: Lightning Internet Services, LLC
X-Mailer: Mozilla 4.78 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hongwei <hongwei.zhou@elec.qmul.ac.uk>
CC: mpls@UU.NET
Subject: Re: how to set up VP and VC in ATM network
References: <MEEJLEKIFLLBNABPKDAOOEPECEAA.hongwei.zhou@elec.qmul.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henry,

The VPI and VCI are assigned by the administrator through his/her configuration on the particular ATM switch(es) they
are configuring.  That then is handed off to the customer as the PVC (vpi/vci).  The ATM switch usually
has an IP address so you can manage it (oob, side-band, whatnot management).  When a new ATM switch is
added to the network, it is usually meshed into the existing ATM infrastructure, and if it is added between switches, you have
to make sure it contains all the PVC information for all your customers/internal PVCs...etc

HTH,

/s

Hongwei wrote:

> Hi,
>
> ATM network uses VPI and VCI to route cells. But how are the VP and VC set
> up first? and what should the network operator
> should do when a new ATM router is added to the network? is there any
> address in ATM network like IP address in IP network?
>
> This question seems irrelevant to the topic of the discussion group, but ATM
> works very similarly to MPLS, and there is no ATM group
> at uu.net, so I beg your forgive that I put the question here, and I will
> appreciate every help.
>
> Cheers,
>
> --Henry



From owner-mpls@UU.NET  Wed Aug 15 14:53:06 2001
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 OAA29114
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 14:53:06 -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 QQlcfj26678;
	Wed, 15 Aug 2001 18:52:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfj04342
	for mpls-outgoing; Wed, 15 Aug 2001 18:52: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 QQlcfj04335
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 18:52:13 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 QQlcfi26839
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:41:42 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 QQlcfi12144
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:41:42 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 OAA10149
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:41:39 -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 OAA10094
	for <mpls@UU.NET>; Wed, 15 Aug 2001 14:41:43 -0400 (EDT)
Message-ID: <3B7AC268.E6F06E35@marconi.com>
Date: Wed, 15 Aug 2001 14:41:44 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: how to set up VP and VC in ATM network
References: <MEEJLEKIFLLBNABPKDAOOEPECEAA.hongwei.zhou@elec.qmul.ac.uk> <3B7AB96A.36E32F67@lightning.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Steve Nash wrote:
> 
> The VPI and VCI are assigned by the administrator through his/her
> configuration on the particular ATM switch(es) they are configuring.
> That then is handed off to the customer as the PVC (vpi/vci).  The
> ATM switch usually has an IP address so you can manage it (oob,
> side-band, whatnot management).  When a new ATM switch is added to
> the network, it is usually meshed into the existing ATM
> infrastructure, and if it is added between switches, you have to
> make sure it contains all the PVC information for all your
> customers/internal PVCs...etc

This is massively off topic for this list.  ATM information is available
from the ATM Forum: http://www.atmforum.com/.

As for your particular description, that is but one method.  ATM
switches have not required manual configuration of PVCs for quite a long
time, even though many sites still prefer it over the automatic VC setup
mechanisms.

ATM switches have per-port NSAP addresses.  They are not IP addresses.

ATM switches run routing protocols (like PNNI), which are used to
compute paths through the network.

There are signaling protocols (like UNI) which are used to set up
virtual circuits without manual specifying the VPI/VCI at every hop.

There are a great many other protocols in ATM that do other useful
things, but this is not the place to get into a discussion of them. 
Specifications are available from the ATM Forum's web site.  There are
also many books on the subject.

-- David


From owner-mpls@UU.NET  Wed Aug 15 15:00:05 2001
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 PAA29229
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 15:00:05 -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 QQlcfj07871;
	Wed, 15 Aug 2001 18:59:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfj04791
	for mpls-outgoing; Wed, 15 Aug 2001 18: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 QQlcfj04786
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 18:59: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 QQlcfj04037
	for <mpls@uu.net>; Wed, 15 Aug 2001 18:55:11 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcfj04174
	for <mpls@uu.net>; Wed, 15 Aug 2001 18:55:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA05897
	for <mpls@uu.net>; Wed, 15 Aug 2001 14:55:10 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA05846 for mpls@uu.net; Wed, 15 Aug 2001 14:54:47 -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 QQlcfj04056
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 18:48:31 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 QQlcfi11109
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:44:49 GMT
Received: from ray.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQlcfi17382
	for <mpls@UU.NET>; Wed, 15 Aug 2001 18:44:49 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7FIg7W03028;
	Wed, 15 Aug 2001 11:42:07 -0700
Date: Wed, 15 Aug 2001 11:42:07 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Ping Pan <pingpan@juniper.net>
cc: <mpls@UU.NET>
Subject: I-D ACTION:draft-pan-rsvp-te-restart-01.txt
In-Reply-To: <3B7AB5E6.8010808@juniper.net>
Message-ID: <Pine.LNX.4.33.0108151121010.2877-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Ping,

I have one simple question regarding the RSVP restart-01 draft.

How can you demonstrate the control plane failure?

Thanks,
Ray




From owner-mpls@UU.NET  Wed Aug 15 15:21:33 2001
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 PAA29625
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 15:21:33 -0400 (EDT)
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 QQlcfl05656;
	Wed, 15 Aug 2001 19:21:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfl25889
	for mpls-outgoing; Wed, 15 Aug 2001 19:21:00 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 QQlcfl25881
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 19:20:51 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 QQlcfk25533
	for <mpls@UU.NET>; Wed, 15 Aug 2001 19:03:11 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcfk17234
	for <mpls@UU.NET>; Wed, 15 Aug 2001 19:03:11 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7FJ2lp23834
	for <mpls@UU.NET>; Wed, 15 Aug 2001 15:02:47 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 15 Aug 2001 15:02:59 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <Q5YJ075Y>; Wed, 15 Aug 2001 15:03:00 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3429DC51@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Ping Pan <pingpan@juniper.net>
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 15:03:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C125BC.E7142120"
X-Orig: <dallan@americasm01.nt.com>
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_01C125BC.E7142120
Content-Type: text/plain;
	charset="iso-8859-1"

Ping:

Comments in line....

<snip>
	> You (and others, my 
	> point is not specific to this I-D) are eliminating all forms of
fate 
	> sharing between the control and data planes, despite (in the MPLS
case 
	> vs. GMPLS) the use of common resources in the control and data
plane 
	> adjacencies.

	David,

	What has been proposed in all forms of graceful restart is the
message 
	format on the wire. How you implement the routers to support these 
	messages is totally up to the developers.

Seems to me that interoperability and overall network survivability would
mandate at least some agreement on the semantics associated with this
stuff.... 

	> This may suggest that control plane failure is today significantly
more 
	> frequent than data plane or link failure and there is a real
problem to 
	> solve, but adding restart mechanisms to everything in the control
plane 
	> is not the complete answer.

	You are right. There are several solutions to help routers/networks
in 
	case of failure condition. Graceful restart is to solve the problem
when 
	control plane dies, but data forwarding is up. Fast reroute is to
solve 
	the problem when data forwarding is in trouble. LSP-ping (please
don't 
	start all those architectural beatification argument again) is to
detect 
	data plane black-hole problem....

Secular issues aside ;-), what you describe above is a pragmatic response to
improving the reliability of a particular application of MPLS, and that's
OK, but I trust you aren't suggesting that the above is a complete
solution....

cheers
Dave


------_=_NextPart_001_01C125BC.E7142120
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.2654.89">
<TITLE>RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ping:</FONT>
</P>

<P><FONT SIZE=3D2>Comments in line....</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; You =
(and others, my </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; =
point is not specific to this I-D) are eliminating all forms of fate =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; =
sharing between the control and data planes, despite (in the MPLS case =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; vs. =
GMPLS) the use of common resources in the control and data plane =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; =
adjacencies.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>David,</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>What has =
been proposed in all forms of graceful restart is the message </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>format on =
the wire. How you implement the routers to support these </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>messages =
is totally up to the developers.</FONT>
</P>

<P><FONT SIZE=3D2>Seems to me that interoperability and overall network =
survivability would mandate at least some agreement on the semantics =
associated with this stuff.... </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; This =
may suggest that control plane failure is today significantly more =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; =
frequent than data plane or link failure and there is a real problem to =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; =
solve, but adding restart mechanisms to everything in the control plane =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&gt; is =
not the complete answer.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>You are =
right. There are several solutions to help routers/networks in </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>case of =
failure condition. Graceful restart is to solve the problem when =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>control =
plane dies, but data forwarding is up. Fast reroute is to solve </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>the =
problem when data forwarding is in trouble. LSP-ping (please don't =
</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>start all =
those architectural beatification argument again) is to detect </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>data =
plane black-hole problem....</FONT>
</P>

<P><FONT SIZE=3D2>Secular issues aside ;-), what you describe above is =
a pragmatic response to improving the reliability of a particular =
application of MPLS, and that's OK, but I trust you aren't suggesting =
that the above is a complete solution....</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C125BC.E7142120--


From owner-mpls@UU.NET  Wed Aug 15 15:44:06 2001
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 PAA29980
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 15:44: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 QQlcfm15469;
	Wed, 15 Aug 2001 19:41:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfm27431
	for mpls-outgoing; Wed, 15 Aug 2001 19:41: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 QQlcfm27426
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 19:41: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 QQlcfm20756
	for <mpls@UU.NET>; Wed, 15 Aug 2001 19:41:27 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQlcfm08120
	for <mpls@UU.NET>; Wed, 15 Aug 2001 19:41:27 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7FJfPe03656;
	Wed, 15 Aug 2001 15:41:26 -0400 (EDT)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA11104; Wed, 15 Aug 2001 15:41:19 -0400 (EDT)
Message-ID: <3B7AD05F.12C6EA9C@lucent.com>
Date: Wed, 15 Aug 2001 15:41:19 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com> <3B7AAD82.5020307@juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Ping,

The restart procedure you described virtually turns the RSVP from a soft state
protocol to a hard state protocol.

Are we adding/changing too much to the RSVP and turning it into a totally
different thing?


Thanks,

Yangguang


Ping Pan wrote:
> 
> David Allan wrote:
> 
> > You (and others, my
> > point is not specific to this I-D) are eliminating all forms of fate
> > sharing between the control and data planes, despite (in the MPLS case
> > vs. GMPLS) the use of common resources in the control and data plane
> > adjacencies.
> >
> 
> David,
> 
> What has been proposed in all forms of graceful restart is the message
> format on the wire. How you implement the routers to support these
> messages is totally up to the developers.
> 
> > This may suggest that control plane failure is today significantly more
> > frequent than data plane or link failure and there is a real problem to
> > solve, but adding restart mechanisms to everything in the control plane
> > is not the complete answer.
> 
> You are right. There are several solutions to help routers/networks in
> case of failure condition. Graceful restart is to solve the problem when
> control plane dies, but data forwarding is up. Fast reroute is to solve
> the problem when data forwarding is in trouble. LSP-ping (please don't
> start all those architectural beatification argument again) is to detect
> data plane black-hole problem....
> 
> Regards,
> 
> - Ping


From owner-mpls@UU.NET  Wed Aug 15 16:20:44 2001
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 QAA00454
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 16:20:43 -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 QQlcfp15007;
	Wed, 15 Aug 2001 20:20:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfp19622
	for mpls-outgoing; Wed, 15 Aug 2001 20:19: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 QQlcfp19617
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:19:42 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 QQlcfo15383
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:07:45 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfo01009
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:07:44 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA06188 for mpls@uu.net; Wed, 15 Aug 2001 16:07:43 -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 QQlcfo17924
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:07:19 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 QQlcfn22660
	for <mpls@uu.net>; Wed, 15 Aug 2001 19:57:15 GMT
Received: from exchsrv2.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.88.104.144])
	id QQlcfn09352
	for <mpls@uu.net>; Wed, 15 Aug 2001 19:57:12 GMT
Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19)
	id <Q6WXV8A0>; Wed, 15 Aug 2001 12:56:36 -0700
Message-ID: <6CECAF1A722ED842B24EC8EDA5B076048D8A97@exchsrv4>
From: Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: draft minutes from London meeting
Date: Wed, 15 Aug 2001 12:56:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C125C4.554C3540"
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_01C125C4.554C3540
Content-Type: text/plain;
	charset="iso-8859-1"


Here are the draft minutes from the London IETF, thanks to Eric Gray.
Comments to the list please.

The presentations are available from:
<http://www.mindspring.com/~ewgray/ietf51/aatlas.ppt>
 <http://www.mindspring.com/~ewgray/ietf51/fhellstrand.ppt>
 <http://www.mindspring.com/~ewgray/ietf51/ppan2.ppt> 
<http://www.mindspring.com/~ewgray/ietf51/tnadeau.ppt> 
<http://www.mindspring.com/~ewgray/ietf51/aiwata.pdf> 
<http://www.mindspring.com/~ewgray/ietf51/ppan1.ppt>
<http://www.mindspring.com/~ewgray/ietf51/sganti.ppt> 


MPLS Working Group Meeting - 9:00 A.M. Monday, 6 August

 Chairs       Agenda

 Fiffi Hellstrand
              "Framework for MPLS-based Recovery"
              <draft-ietf-mpls-recovery-frmwrk-03.txt> 

 Ping Pan     "A Method for MPLS LSP Fast-Reroute Using RSVP Detours", 
              <draft-gan-fast-reroute-00.txt> 

 Atsushi Iwata 
              "MPLS Signaling Extensions for Shared Fast Rerouting" 
              <draft-iwata-mpls-shared-fastreroute-00.txt> 

 Alia Atlas   "MPLS RSVP-TE Interoperability for Local Protection/Fast
              Reroute" <draft-atlas-rsvp-local-protect-interop-01.txt> 

 Tissa Senevirathne 
              "MPLS Label Stack Authentication methods and algorithms" 
              <draft-tsenevir-mpls-lauth-01.txt> 

 Ping Pan     "Graceful Restart Mechanism for RSVP-TE" 
              <draft-pan-rsvp-te-restart-01.txt> 

 Sudhakar Ganti 
              "MPLS Support of Differentiated Services using E-LSP" 
              <draft-ganti-mpls-diffserv-elsp-00.txt> 
 Tom Nadeau   "Link Bundling Information Base Using SMIv2" 
              <draft-dubuc-mpls-bundle-mib-02.txt> 

 Chairs       Workgroup status 


(Slides for the below presentation are located in file fhellstrand.ppt)

Presentation by Fiffi Hellstrand on "Framework for MPLS-based Recovery"
(draft-ietf-mpls-recovery-frmwrk-03.txt). She gave an update on status of 
this draft and requested that the draft go to last call immediately after 
meeting and move in the direction of becoming an informational RFC.

George Swallow will post the last call to the mailing list.

(Slides for the below presentation are located in file ppan1.ppt)

Presentation by Ping Pan on Juniper Fast Reroute "A Method for MPLS LSP 
Fast-Reroute Using RSVP Detours" (draft-gan-fast-reroute-00.txt) - designed 
by Tony Li and Der-Hwa Gan some time back.  This is a flexible approach that
protects against both link and node failure.

Flexible and extensible. Single solution for both link and node protection.
Adaptive, minimal user impact and operational.  Designed to protect LSPs
selectively.  Support LSP detour merging to reduce # of LSPs.  Helped by
refresh reduction.

Question: (David Allan) Semantics of merging, etc. seem to imply central 
control and the merging seems to reduce the ability of the approach to 
support against a node failure?

Question: How do you protect against node failure?  How fast does this work?
Answer: detect node failure via refresh expiry and direct link failure.

Question: (Loa Andersson) Have interoperability issues been considered (for
example with LDP Fault tolerance?  Also, there is a general issue of  
preserving state/label mappings if you have part of the LSP setup by LDP 
and part of them done by RSVP-TE.
Answer: None at present.

Question: How is merging performed using signaling?
Answer: George Swallow said that a draft needs to be generated to describe
path selection for detour LSPs, but the place where that work belongs has
not been determined yet.

Question: (Loa Andersson) what is happening to this draft?
Answer: (George Swallow) We have more drafts to be heard on this topic.
Other drafts are being presented that impact on this.

(Slides for the below presentation are located in file aiwata.pdf)

Presentation by Atsushi Iwata. He presented a detailed discussion of the 
content of draft "MPLS Signaling Extensions for Shared Fast Rerouting" 
(draft-iwata-mpls-shared-fastreroute-00.txt).

Question: (George Swallow) is there a dependency in this approach on 
ordered setup.  If something goes wrong on the backup path, do you have
to start over?
Answer: At present, yes - but he will be looking into this.

Question: (Loa Andersson) is there an assumption that resource sharing
is the only parameter needed, even if this forces setup of a non-optimal 
path through paths set up for "upstream" recovery paths for the same 
primary paths?  There might be other parameters that could be used, for
example, the most optimal path from the node doing the recovery to some
merge point downstream.  Otherwise you might always be forced to use 
shared explicit resources for backup LSPs.
Answer: The approach does depend on use of shared resources, if you can do
this, then you can use this approach.  Optimization issues depend on the
specific network topology in use.  If an operator designs a network 
considering the proposed shared fast-reroute scheme, optimization can
be done in nearly every case. However, if there are topology constraints 
preventing this, the operator will want to have the option - at the ingress 
node - to use the Gan approach.

(Slides for the below presentation are located in file aatlas.ppt)

Presentation by Alia Atlas. She presented a detailed discussion of the
content
of draft "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute" 
(draft-atlas-rsvp-local-protect-interop-01.txt).

Ping Pan said his draft does support local repair.

Comment from George Swallow (not as chair): his draft and the Ping Pan,
Der-Hwa Gan draft are not competitors and the authors from the two drafts
should form a single draft design team.

Question: There appears to be a lot of complexity in these proposals,
will they be implemented or deployed?
Answer: From George Swallow, these are already implemented and deployed
and this is an opportunity to specify how this is done.

(Slides for the below presentation are not yet available)

Presentation by Tissa Senevirathne on "MPLS Label Stack Authentication 
methods and algorithms" (draft-tsenevir-mpls-lauth-01.txt).  He discussed 
the reasoning for this proposal: protect against connection hijack, 
bandwidth hijacking and denial of service attacks.

Question/Observation: Because the nature of this authentication mechanism
involves some computational complexity, it seems likely that this approach 
may easily be subverted to introduce a denial of service attack.

Question: How is this approach better than other proposals to protect
backbone traffic such as encryption at the link layer?
Answer: This is not encryption of MPLS.

George Swallow asked if there were people in the room who felt that this
was something they needed to see in their networks.  No one answered.

(Slides for the below presentation are located in file ppan2.ppt)

Presentation by Ping Pan of "Graceful Restart Mechanism for RSVP-TE" 
(draft-pan-rsvp-te-restart-01.txt). He discussed the concepts of the
draft in some detail.  Conclusions: Useful, simple and compatible.

Question: (David Allan) 

George Swallow said that this work will need to be taken to CCAMP for
more general usability.

Question: (Loa Andersson) Is there any effort to make this sort of thing
work for LDP as well.
Answer: There has been work on LDP fault tolerance to handle this.

Question: (Yanguang Xu) the suggested label object is being overloaded
here and we should think about using some other object.
Answer: (Lou Berger) authors felt that the same information would then
be used to carry duplicate information since much of the same information
would have to be in the suggested label object anyways.

George Swallow suggested taking this off-line.

(Slides for the below presentation are located in file sganti.ppt)

Presentation by Sudhakar Ganti on "MPLS Support of Differentiated Services
using 
E-LSP" (draft-ganti-mpls-diffserv-elsp-00.txt).  He provided an overview
of the contents of the draft.  The draft essentially proposes explicit
signaling for E-LSP setup.  The draft also includes how the mechanisms may
be extended for E-LSP support in CR-LDP.  He requested that the document 
become a working group draft.

George Swallow asked for a sense of how many felt that this was work we
should undertake.  Several people raised their hands (much less than 1/2
of those present).  George Swallow stated that there is a simplistic
approach described in existing specifications, and he would like to see 
some stronger support before adopting this work.

Question: What is the driving application for this? What criteria are used
to determine relative survivability for large numbers of LSPs?
Answer: The driving application is mostly L2VPN deployment.  The criteria 
for survivabilty is not the issue here.

Question: (Vijay Srinivasan) Given that AF and EF are not going to be on
the same LSP anyways, are we going to signal separately for each AF class?
Why would this be useful?
Answer: (Scott Bradner) there isn't a defined relationship between
AF classes and no natural presumption of a priority order between them.

Comment: (Bruce Davie) Not much added by this draft.  You have to buy into
the premise that effectively signaling L-LSPs using the EXP bits is
something 
we want to be able to do.  There doesn't seem to be any obvious need for
this.
Answer: There is value in doing this.  A lot depends on how you want to
distinguish the different service levels in a single LSP and how we deploy 
these services. End-to-end service deployment with SLA gurantees and path 
protection is a good candidate for using E-LSPs

George Swallow stated that we do not want to build mechanisms for
mechanism's
sake - we need to understand what the need is for the proposed mechanism.

(Slides for the below presentation are located in file tnadeau.ppt)

Presentation by Tom Nadeau on "Link Bundling Information Base Using SMIv2" 
(draft-dubuc-mpls-bundle-mib-02.txt).  He first summarized the draft for
those who have not had a chance to read it, then discussed the evolution 
of the draft and asked to have it accepted as a working group document.

Question: Do we have/need an overview of the various MPLS and TE MIBs to
simplify the process of determining what MIBs are used for what purposes.
George asked to see how much support there is for the link bundling MIB
draft 
as a working group draft.  Many hands were raised, however, George suggested

that we take the discussion of whether or not to adopt this work in the MPLS

working group to the mailing list.

George Swallow used this as an opportunity to segue into MPLS draft status,
saying that he would like to hear the status on unnumbered link,
hierarchical
LSP setup and link bundling from Kireeti Kompella.  Kireeti said that he is 
going to respin these drafts soon.  Kireeti talked briefly about changes
that
need to be made to these drafts.

George asked if the drafts would be ready for last call by the end of
August.  Kireeti said between Yakov and himself, they should be able to get
it done.  He cautioned that he would be on vacation until the end of August
himself however.

Question for the chairs: what is the status of drafts in the IESG and
RFC editor's queue?

Scott Bradner said that he would get back on that.
############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

------_=_NextPart_001_01C125C4.554C3540
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>draft minutes from London meeting</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here are the draft minutes from the =
London IETF, thanks to Eric Gray.&nbsp; Comments to the list =
please.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The presentations are available =
from:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/aatlas.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/aatlas.ppt</A=
>&gt;</FONT></U>
<BR><FONT FACE=3D"Times New Roman"></FONT><U>&nbsp;<FONT =
COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/fhellstrand.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/fhellstrand.p=
pt</A>&gt;</FONT></U>
<BR><FONT FACE=3D"Times New Roman"></FONT><U>&nbsp;<FONT =
COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/ppan2.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/ppan2.ppt</A>=
&gt;</FONT></U><FONT FACE=3D"Times New Roman"> </FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/tnadeau.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/tnadeau.ppt</=
A>&gt;</FONT></U><FONT FACE=3D"Times New Roman"> </FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/aiwata.pdf" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/aiwata.pdf</A=
>&gt;</FONT></U><FONT FACE=3D"Times New Roman"> </FONT>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/ppan1.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/ppan1.ppt</A>=
&gt;</FONT></U>
<BR><U><FONT COLOR=3D"#0000FF" FACE=3D"Times New Roman">&lt;<A =
HREF=3D"http://www.mindspring.com/~ewgray/ietf51/sganti.ppt" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray/ietf51/sganti.ppt</A=
>&gt;</FONT></U><FONT FACE=3D"Times New Roman"> </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">MPLS Working Group Meeting - 9:00 A.M. =
Monday, 6 August</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;Chairs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Agenda</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Fiffi Hellstrand</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &quot;Framework for MPLS-based =
Recovery&quot;</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-ietf-mpls-recovery-frmwrk-03.txt&gt; =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Ping Pan&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;A Method for MPLS LSP Fast-Reroute Using RSVP Detours&quot;, =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-gan-fast-reroute-00.txt&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Atsushi Iwata </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &quot;MPLS Signaling Extensions for Shared Fast =
Rerouting&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; =
&lt;draft-iwata-mpls-shared-fastreroute-00.txt&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Alia Atlas&nbsp;&nbsp; =
&quot;MPLS RSVP-TE Interoperability for Local Protection/Fast</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Reroute&quot; =
&lt;draft-atlas-rsvp-local-protect-interop-01.txt&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Tissa Senevirathne </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &quot;MPLS Label Stack Authentication methods and =
algorithms&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-tsenevir-mpls-lauth-01.txt&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Ping Pan&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;Graceful Restart Mechanism for RSVP-TE&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-pan-rsvp-te-restart-01.txt&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Sudhakar Ganti </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &quot;MPLS Support of Differentiated Services =
using E-LSP&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-ganti-mpls-diffserv-elsp-00.txt&gt; =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Tom Nadeau&nbsp;&nbsp; =
&quot;Link Bundling Information Base Using SMIv2&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; &lt;draft-dubuc-mpls-bundle-mib-02.txt&gt; =
</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;Chairs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Workgroup status </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file fhellstrand.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Fiffi Hellstrand on =
&quot;Framework for MPLS-based Recovery&quot;</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">(draft-ietf-mpls-recovery-frmwrk-03.txt). She gave an =
update on status of </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this draft and requested that the =
draft go to last call immediately after </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">meeting and move in the direction of =
becoming an informational RFC.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow will post the last call =
to the mailing list.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file ppan1.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Ping Pan on Juniper =
Fast Reroute &quot;A Method for MPLS LSP </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fast-Reroute Using RSVP Detours&quot; =
(draft-gan-fast-reroute-00.txt) - designed </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">by Tony Li and Der-Hwa Gan some time =
back.&nbsp; This is a flexible approach that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protects against both link and node =
failure.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Flexible and extensible. Single =
solution for both link and node protection.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Adaptive, minimal user impact and =
operational.&nbsp; Designed to protect LSPs</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">selectively.&nbsp; Support LSP detour =
merging to reduce # of LSPs.&nbsp; Helped by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">refresh reduction.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (David Allan) Semantics of =
merging, etc. seem to imply central </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">control and the merging seems to =
reduce the ability of the approach to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">support against a node =
failure?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: How do you protect against =
node failure?&nbsp; How fast does this work?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: detect node failure via =
refresh expiry and direct link failure.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Loa Andersson) Have =
interoperability issues been considered (for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">example with LDP Fault =
tolerance?&nbsp; Also, there is a general issue of&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">preserving state/label mappings if =
you have part of the LSP setup by LDP </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and part of them done by =
RSVP-TE.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: None at present.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: How is merging performed =
using signaling?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: George Swallow said that a =
draft needs to be generated to describe</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">path selection for detour LSPs, but =
the place where that work belongs has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not been determined yet.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Loa Andersson) what is =
happening to this draft?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: (George Swallow) We have more =
drafts to be heard on this topic.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Other drafts are being presented that =
impact on this.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file aiwata.pdf)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Atsushi Iwata. He =
presented a detailed discussion of the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">content of draft &quot;MPLS Signaling =
Extensions for Shared Fast Rerouting&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">(draft-iwata-mpls-shared-fastreroute-00.txt).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (George Swallow) is there a =
dependency in this approach on </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ordered setup.&nbsp; If something =
goes wrong on the backup path, do you have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to start over?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: At present, yes - but he will =
be looking into this.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Loa Andersson) is there an =
assumption that resource sharing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is the only parameter needed, even if =
this forces setup of a non-optimal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">path through paths set up for =
&quot;upstream&quot; recovery paths for the same </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">primary paths?&nbsp; There might be =
other parameters that could be used, for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">example, the most optimal path from =
the node doing the recovery to some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">merge point downstream.&nbsp; =
Otherwise you might always be forced to use </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">shared explicit resources for backup =
LSPs.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: The approach does depend on =
use of shared resources, if you can do</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this, then you can use this =
approach.&nbsp; Optimization issues depend on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">specific network topology in =
use.&nbsp; If an operator designs a network </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">considering the proposed shared =
fast-reroute scheme, optimization can</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be done in nearly every case. =
However, if there are topology constraints </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">preventing this, the operator will =
want to have the option - at the ingress </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">node - to use the Gan =
approach.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file aatlas.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Alia Atlas. She =
presented a detailed discussion of the content</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of draft &quot;MPLS RSVP-TE =
Interoperability for Local Protection/Fast Reroute&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">(draft-atlas-rsvp-local-protect-interop-01.txt).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ping Pan said his draft does support =
local repair.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Comment from George Swallow (not as =
chair): his draft and the Ping Pan,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Der-Hwa Gan draft are not competitors =
and the authors from the two drafts</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should form a single draft design =
team.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: There appears to be a lot of =
complexity in these proposals,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will they be implemented or =
deployed?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: From George Swallow, these =
are already implemented and deployed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and this is an opportunity to specify =
how this is done.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
not yet available)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Tissa Senevirathne on =
&quot;MPLS Label Stack Authentication </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">methods and algorithms&quot; =
(draft-tsenevir-mpls-lauth-01.txt).&nbsp; He discussed </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the reasoning for this proposal: =
protect against connection hijack, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">bandwidth hijacking and denial of =
service attacks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question/Observation: Because the =
nature of this authentication mechanism</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">involves some computational =
complexity, it seems likely that this approach </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">may easily be subverted to introduce =
a denial of service attack.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: How is this approach better =
than other proposals to protect</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">backbone traffic such as encryption =
at the link layer?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: This is not encryption of =
MPLS.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow asked if there were =
people in the room who felt that this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">was something they needed to see in =
their networks.&nbsp; No one answered.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file ppan2.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Ping Pan of =
&quot;Graceful Restart Mechanism for RSVP-TE&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(draft-pan-rsvp-te-restart-01.txt). =
He discussed the concepts of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">draft in some detail.&nbsp; =
Conclusions: Useful, simple and compatible.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (David Allan) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow said that this work =
will need to be taken to CCAMP for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">more general usability.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Loa Andersson) Is there any =
effort to make this sort of thing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">work for LDP as well.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: There has been work on LDP =
fault tolerance to handle this.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Yanguang Xu) the suggested =
label object is being overloaded</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">here and we should think about using =
some other object.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: (Lou Berger) authors felt =
that the same information would then</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be used to carry duplicate =
information since much of the same information</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">would have to be in the suggested =
label object anyways.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow suggested taking this =
off-line.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file sganti.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Sudhakar Ganti on =
&quot;MPLS Support of Differentiated Services using </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">E-LSP&quot; =
(draft-ganti-mpls-diffserv-elsp-00.txt).&nbsp; He provided an =
overview</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of the contents of the draft.&nbsp; =
The draft essentially proposes explicit</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signaling for E-LSP setup.&nbsp; The =
draft also includes how the mechanisms may</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be extended for E-LSP support in =
CR-LDP.&nbsp; He requested that the document </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">become a working group draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow asked for a sense of =
how many felt that this was work we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should undertake.&nbsp; Several =
people raised their hands (much less than 1/2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of those present).&nbsp; George =
Swallow stated that there is a simplistic</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">approach described in existing =
specifications, and he would like to see </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some stronger support before adopting =
this work.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: What is the driving =
application for this? What criteria are used</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to determine relative survivability =
for large numbers of LSPs?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: The driving application is =
mostly L2VPN deployment.&nbsp; The criteria </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for survivabilty is not the issue =
here.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: (Vijay Srinivasan) Given =
that AF and EF are not going to be on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the same LSP anyways, are we going to =
signal separately for each AF class?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Why would this be useful?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: (Scott Bradner) there isn't a =
defined relationship between</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">AF classes and no natural presumption =
of a priority order between them.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Comment: (Bruce Davie) Not much added =
by this draft.&nbsp; You have to buy into</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the premise that effectively =
signaling L-LSPs using the EXP bits is something </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">we want to be able to do.&nbsp; There =
doesn't seem to be any obvious need for this.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Answer: There is value in doing =
this.&nbsp; A lot depends on how you want to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">distinguish the different service =
levels in a single LSP and how we deploy </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">these services. End-to-end service =
deployment with SLA gurantees and path </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protection is a good candidate for =
using E-LSPs</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow stated that we do not =
want to build mechanisms for mechanism's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sake - we need to understand what the =
need is for the proposed mechanism.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(Slides for the below presentation are =
located in file tnadeau.ppt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Presentation by Tom Nadeau on =
&quot;Link Bundling Information Base Using SMIv2&quot; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">(draft-dubuc-mpls-bundle-mib-02.txt).&nbsp; He first =
summarized the draft for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">those who have not had a chance to =
read it, then discussed the evolution </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of the draft and asked to have it =
accepted as a working group document.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question: Do we have/need an overview =
of the various MPLS and TE MIBs to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">simplify the process of determining =
what MIBs are used for what purposes.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">George asked to see how much support =
there is for the link bundling MIB draft </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as a working group draft.&nbsp; Many =
hands were raised, however, George suggested </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that we take the discussion of =
whether or not to adopt this work in the MPLS </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">working group to the mailing =
list.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Swallow used this as an =
opportunity to segue into MPLS draft status,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">saying that he would like to hear the =
status on unnumbered link, hierarchical</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">LSP setup and link bundling from =
Kireeti Kompella.&nbsp; Kireeti said that he is </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">going to respin these drafts =
soon.&nbsp; Kireeti talked briefly about changes that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">need to be made to these =
drafts.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George asked if the drafts would be =
ready for last call by the end of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">August.&nbsp; Kireeti said between =
Yakov and himself, they should be able to get</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it done.&nbsp; He cautioned that he =
would be on vacation until the end of August</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">himself however.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Question for the chairs: what is the =
status of drafts in the IESG and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RFC editor's queue?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Scott Bradner said that he would get =
back on that.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">#########################################################=
############################################# This email communication =
may contain CONFIDENTIAL INFORMATION and is intended only for the use =
of the intended recipients identified above.&nbsp; If you are not the =
intended recipient of this communication, you must not use, disclose, =
distribute, copy or print this email. If you have received this =
communication in error, please immediately notify the sender by reply =
email, delete the communication and destroy all copies. =
########################################################################=
##############################</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C125C4.554C3540--



From owner-mpls@UU.NET  Wed Aug 15 16:43:54 2001
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 QAA00775
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 16:43:54 -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 QQlcfq00053;
	Wed, 15 Aug 2001 20:43:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfq21310
	for mpls-outgoing; Wed, 15 Aug 2001 20:43: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 QQlcfq21305
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:42: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 QQlcfq25291
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:41:18 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfq26475
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:41:17 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08707 for mpls@uu.net; Wed, 15 Aug 2001 16:41:16 -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 QQlcfq21158
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:41:03 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 QQlcfq13611
	for <mpls@UU.net>; Wed, 15 Aug 2001 20:39:07 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlcfq08291
	for <mpls@UU.net>; Wed, 15 Aug 2001 20:39:06 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AFP6>; Wed, 15 Aug 2001 16:38:48 -0400
Message-ID: <87009604743AD411B1F600508BA0F959AF572A@XOVER.dedham.mindspeed.com>
From: "Barnett, Joe" <joe.barnett@netplane.com>
To: "'mpls@UU.net'" <mpls@UU.NET>
Subject: Question on the sender descriptor within a PATH message...
Date: Wed, 15 Aug 2001 16:38:38 -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

I am wondering if when receiving a PATH message, that the component objects
defined within the sender descriptor should be processed in any order within
the PATH message. By this I mean, seeing that the sender descriptor looks
like so:
       <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                                         [ <ADSPEC> ]
                                         [ <RECORD_ROUTE> ]
and the path message looks as so:
      <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                               <SESSION> <RSVP_HOP>
                               <TIME_VALUES>
                               [ <EXPLICIT_ROUTE> ]
                               <LABEL_REQUEST>
                               [ <SESSION_ATTRIBUTE> ]
                               [ <POLICY_DATA> ... ]
                               <sender descriptor>
Now, for example, lets say that the order in which I received the PATH
message objects looked like this:
      <path msg stream> ::=      <Common Header>
                                 <SESSION>
                               <SENDER_TSPEC>
                               <RSVP_HOP>
                               <TIME_VALUES>
                               <RECORD_ROUTE>
                               <LABEL_REQUEST>
                              <SENDER_TEMPLATE>
notice that all mandatory objects are present, however the sender
descriptors object components are not contiguous. Is this an acceptable PATH
message formation? I know I should accept objects in any permissible order,
however would this be the case with the sender descriptor's component
objects?

Kind regards,
Joseph Barnett



From owner-mpls@UU.NET  Wed Aug 15 16:48:50 2001
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 QAA00839
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 16:48:50 -0400 (EDT)
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 QQlcfr21639;
	Wed, 15 Aug 2001 20:47:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfr21857
	for mpls-outgoing; Wed, 15 Aug 2001 20:47: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 QQlcfr21846
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:46: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 QQlcfq29240
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:44:25 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfq02543
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:44:25 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08975 for mpls@uu.net; Wed, 15 Aug 2001 16:44:24 -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 QQlcfq21374
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 20:44:01 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 QQlcfq28111
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:42:29 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlcfq13804
	for <mpls@uu.net>; Wed, 15 Aug 2001 20:42:27 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AFQD>; Wed, 15 Aug 2001 16:42:09 -0400
Message-ID: <87009604743AD411B1F600508BA0F959AF572B@XOVER.dedham.mindspeed.com>
From: "Barnett, Joe" <joe.barnett@netplane.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question on the sender descriptor within a PATH message...
Date: Wed, 15 Aug 2001 16:42:06 -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

> I am wondering if when receiving a PATH message, that the component
> objects defined within the sender descriptor should be processed in any
> order within the PATH message. By this I mean, seeing that the sender
> descriptor looks like so:
>        <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
>                                          [ <ADSPEC> ]
>                                          [ <RECORD_ROUTE> ]
> and the path message looks as so:
>       <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
>                                <SESSION> <RSVP_HOP>
>                                <TIME_VALUES>
>                                [ <EXPLICIT_ROUTE> ]
>                                <LABEL_REQUEST>
>                                [ <SESSION_ATTRIBUTE> ]
>                                [ <POLICY_DATA> ... ]
>                                <sender descriptor>
> Now, for example, lets say that the order in which I received the PATH
> message objects looked like this:
>       <path msg stream> ::=      <Common Header>
>                                  <SESSION>
>                                <SENDER_TSPEC>
>                                <RSVP_HOP>
>                                <TIME_VALUES>
>                                <RECORD_ROUTE>
>                                <LABEL_REQUEST>
>                               <SENDER_TEMPLATE>
> notice that all mandatory objects are present, however the sender
> descriptors object components are not contiguous. Is this an acceptable
> PATH message formation? I know I should accept objects in any permissible
> order, however would this be the case with the sender descriptor's
> component objects?
> 
> Kind regards,
> Joseph Barnett
> 
Work on the person and the world comes together...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-mpls@UU.NET  Wed Aug 15 17:10:49 2001
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 RAA01184
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 17:10:49 -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 QQlcfs18180;
	Wed, 15 Aug 2001 21:10:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfs12808
	for mpls-outgoing; Wed, 15 Aug 2001 21:09: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 QQlcfs12801
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:09: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 QQlcfs28236
	for <mpls@uu.net>; Wed, 15 Aug 2001 21:07:52 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfs29985
	for <mpls@uu.net>; Wed, 15 Aug 2001 21:07:51 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10998 for mpls@uu.net; Wed, 15 Aug 2001 17:07:50 -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 QQlcfs07681
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:05:03 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 QQlcfs25508
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:02:32 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 QQlcfs17034
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:02:32 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FL2U041382;
	Wed, 15 Aug 2001 14:02:30 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AE371.1080806@juniper.net>
Date: Wed, 15 Aug 2001 14:02:41 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com> <3B7AAD82.5020307@juniper.net> <3B7AD05F.12C6EA9C@lucent.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

Yangguang Xu wrote:

> Ping,
> 
> The restart procedure you described virtually turns the RSVP from a soft state
> protocol to a hard state protocol.
>


How? Please explain.


> Are we adding/changing too much to the RSVP and turning it into a totally
> different thing?
> 



I am interested in solving the problems, not interested in defining names.

- Ping




From owner-mpls@UU.NET  Wed Aug 15 17:20:44 2001
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 RAA01363
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 17:20:44 -0400 (EDT)
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 QQlcft16469;
	Wed, 15 Aug 2001 21:20:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcft13848
	for mpls-outgoing; Wed, 15 Aug 2001 21:20:14 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 QQlcft13842
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:20: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 QQlcft03186
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:17:03 GMT
Received: from hebe.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns02.or.intel.com [134.134.248.4])
	id QQlcft14763
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:17:01 GMT
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA14974
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:17:00 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 15 Aug 2001 21:17:00 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <QYXVHRSS>; Wed, 15 Aug 2001 14:16:58 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA028@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RRO Processing
Date: Wed, 15 Aug 2001 14:16:29 -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 the Path message, there should be only one RRO. So, if it is too big, the
RRO is removed.

In Resv message, IMO, it should be consistent with Path, i.e. the RRO should
be dropped per sender.

I am not sure what you mean by "new". The RRO procedure initiates either by
the ingress or the egress.

-Mark

> -----Original Message-----
> From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> Sent: Monday, August 13, 2001 9:28 PM
> To: 'mpls@UU.NET'
> Subject: RRO Processing
> 
> 
> Hi ,
>       In case of RRO processing ,
> 
> "If the newly added subobject causes the RRO to be too big to fit 
> in a  Path (or Resv) message, the RRO object SHALL be dropped 
> from the  message and message processing continues as normal"
> 
>  In this particular case will the RRO object will be dropped 
> for all the
> Filter Descriptors  , or for the one which is new .
> 
> How the case should be handled in case if RRO was not there 
> and subsequent
> adding the RRO object starts giving this error .
> 
> Regards ,
> Manoj
> 
> 
>  



From owner-mpls@UU.NET  Wed Aug 15 17:27:48 2001
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 RAA01511
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 17:27:48 -0400 (EDT)
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 QQlcft28145;
	Wed, 15 Aug 2001 21:27:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcft14524
	for mpls-outgoing; Wed, 15 Aug 2001 21:26:58 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 QQlcft14519
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:26:57 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 QQlcft21592
	for <mpls@uu.net>; Wed, 15 Aug 2001 21:20:15 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcft20059
	for <mpls@uu.net>; Wed, 15 Aug 2001 21:20:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA12119 for mpls@uu.net; Wed, 15 Aug 2001 17:20:13 -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 QQlcft13799
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:19: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 QQlcfs01671
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:14: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 QQlcfs05689
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:14:16 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FLEC042354;
	Wed, 15 Aug 2001 14:14:12 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AE62F.8030200@juniper.net>
Date: Wed, 15 Aug 2001 14:14:23 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DC51@zcard0ka.ca.nortel.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

David Allan wrote:

> 
> Secular issues aside ;-), what you describe above is a pragmatic 
> response to improving the reliability of a particular application of 
> MPLS, and that's OK, but I trust you aren't suggesting that the above is 
> a complete solution....
> 


Dave,

You are right. We are not solving all the problems in the MPLS world. In 
fact I doubt anybody knows all the problems.  :-)

Base on our (both vendors and providers) experience, we will solve the 
problems as they come up. I hope this is a reasonable approach.

Best regards,

- Ping




From owner-mpls@UU.NET  Wed Aug 15 17:56:36 2001
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 RAA01877
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 17:56:35 -0400 (EDT)
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 QQlcfv16507;
	Wed, 15 Aug 2001 21:56:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfv17355
	for mpls-outgoing; Wed, 15 Aug 2001 21:55: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 QQlcfv17347
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 21:55:34 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 QQlcfv12033
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:49:46 GMT
Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQlcfv06290
	for <mpls@UU.NET>; Wed, 15 Aug 2001 21:49:45 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7FLniw11463;
	Wed, 15 Aug 2001 17:49:44 -0400 (EDT)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA03498; Wed, 15 Aug 2001 17:49:38 -0400 (EDT)
Message-ID: <3B7AEE72.D43D3572@lucent.com>
Date: Wed, 15 Aug 2001 17:49:38 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com> <3B7AAD82.5020307@juniper.net> <3B7AD05F.12C6EA9C@lucent.com> <3B7AE371.1080806@juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


See my reply below,

> >
> > The restart procedure you described virtually turns the RSVP from a soft state
> > protocol to a hard state protocol.
> >
> 
> How? Please explain.
> 

From RFC 2205 "RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and periodically
refreshed by Path and Resv messages.  The state is deleted if no matching
refresh messages arrive before the expiration of a "cleanup timeout" interval."

The "state" here is data plane state. If you separate the control and transport
plane, you can't depend on the periodically refreshing of Path and Resv message
to maintain the data plane state any more. Indeed, you can't even associate the
health of control and data plane any more.

Thanks,

Yangguang


From owner-mpls@UU.NET  Wed Aug 15 18:09:49 2001
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 SAA02032
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 18:09:49 -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 QQlcfw03226;
	Wed, 15 Aug 2001 22:09:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfw02604
	for mpls-outgoing; Wed, 15 Aug 2001 22:09: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 QQlcfw02549
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 22:09:16 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 QQlcfw20687
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:06:23 GMT
Received: from radiant.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radiant.calient.net [63.102.55.206])
	id QQlcfw26552
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:06:22 GMT
Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <P2KSY9K1>; Wed, 15 Aug 2001 15:06:22 -0700
Message-ID: <A1AFE5CF886C5D439494D9D5DE84EEF3737238@radiant.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Yangguang Xu'" <xuyg@lucent.com>, Ping Pan <pingpan@juniper.net>
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Wed, 15 Aug 2001 15:06:13 -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

Actually, Ping uses the soft state nature of RSVP to rebuild control plane
state in the case
where the data plane state exists but the control plane state doesn't.  

-----Original Message-----
From: Yangguang Xu [mailto:xuyg@lucent.com]
Sent: Wednesday, August 15, 2001 2:50 PM
To: Ping Pan
Cc: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]



See my reply below,

> >
> > The restart procedure you described virtually turns the RSVP from a soft
state
> > protocol to a hard state protocol.
> >
> 
> How? Please explain.
> 

From RFC 2205 "RSVP takes a "soft state" approach to managing the
reservation
state in routers and hosts. RSVP soft state is created and periodically
refreshed by Path and Resv messages.  The state is deleted if no matching
refresh messages arrive before the expiration of a "cleanup timeout"
interval."

The "state" here is data plane state. If you separate the control and
transport
plane, you can't depend on the periodically refreshing of Path and Resv
message
to maintain the data plane state any more. Indeed, you can't even associate
the
health of control and data plane any more.

Thanks,

Yangguang


From owner-mpls@UU.NET  Wed Aug 15 18:15:27 2001
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 SAA02150
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 18:15:27 -0400 (EDT)
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 QQlcfx18777;
	Wed, 15 Aug 2001 22:15:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfw08527
	for mpls-outgoing; Wed, 15 Aug 2001 22:14: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 QQlcfw08522
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 22:14:41 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 QQlcfw24180
	for <mpls@uu.net>; Wed, 15 Aug 2001 22:13:29 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcfw09716
	for <mpls@uu.net>; Wed, 15 Aug 2001 22:13:29 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA16200 for mpls@uu.net; Wed, 15 Aug 2001 18:13:27 -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 QQlcfw08202
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 22:12:42 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 QQlcfw21027
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:10:39 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 QQlcfw05105
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:10:38 GMT
Received: from juniper.net (panther.juniper.net [172.17.12.226])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7FMAX046273;
	Wed, 15 Aug 2001 15:10:33 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B7AF359.2196DD5@juniper.net>
Date: Wed, 15 Aug 2001 15:10:33 -0700
From: Ping Pan <pingpan@juniper.net>
Organization: Juniper Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Yangguang Xu <xuyg@lucent.com>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com> <3B7AAD82.5020307@juniper.net> <3B7AD05F.12C6EA9C@lucent.com> <3B7AE371.1080806@juniper.net> <3B7AEE72.D43D3572@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yangguang Xu wrote:
> 
> 
> >From RFC 2205 "RSVP takes a "soft state" approach to managing the reservation
> state in routers and hosts. RSVP soft state is created and periodically
> refreshed by Path and Resv messages.  The state is deleted if no matching
> refresh messages arrive before the expiration of a "cleanup timeout" interval."
> 
> The "state" here is data plane state.

No. The "state" here is the control information such as RSVP source,
destination, flowspec, etc. Data plane states are filter entries, FIB,
etc.



From owner-mpls@UU.NET  Wed Aug 15 18:48:11 2001
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 SAA02400
	for <mpls-archive@lists.ietf.org>; Wed, 15 Aug 2001 18:48:11 -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 QQlcfz16143;
	Wed, 15 Aug 2001 22:47:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcfz12395
	for mpls-outgoing; Wed, 15 Aug 2001 22:47: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 QQlcfz12387
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 15 Aug 2001 22:47:25 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 QQlcfy03257
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:31:18 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 QQlcfy15647
	for <mpls@UU.NET>; Wed, 15 Aug 2001 22:31:18 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7FMVGV08305;
	Wed, 15 Aug 2001 18:31:16 -0400 (EDT)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id SAA08383; Wed, 15 Aug 2001 18:31:10 -0400 (EDT)
Message-ID: <3B7AF82E.6CD4F386@lucent.com>
Date: Wed, 15 Aug 2001 18:31:10 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
References: <3549C09B853DD5119B540002A52CDD3429DB04@zcard0ka.ca.nortel.com> <3B7AAD82.5020307@juniper.net> <3B7AD05F.12C6EA9C@lucent.com> <3B7AE371.1080806@juniper.net> <3B7AEE72.D43D3572@lucent.com> <3B7AF359.2196DD5@juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


> >
> > >From RFC 2205 "RSVP takes a "soft state" approach to managing the reservation
> > state in routers and hosts. RSVP soft state is created and periodically
> > refreshed by Path and Resv messages.  The state is deleted if no matching
> > refresh messages arrive before the expiration of a "cleanup timeout" interval."
> >
> > The "state" here is data plane state.
> 
> No. The "state" here is the control information such as RSVP source,
> destination, flowspec, etc. Data plane states are filter entries, FIB,
> etc.

There was no distinction about these two states in RFC 2205. So I guess it then
can be interpreted differently to serve different purposes. 

Yangguang


From owner-mpls@UU.NET  Thu Aug 16 00:25:05 2001
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 AAA08085
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 00:25:05 -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 QQlcgv21991;
	Thu, 16 Aug 2001 04:24:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcgv09013
	for mpls-outgoing; Thu, 16 Aug 2001 04:24:04 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 QQlcgv09002
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 04:23:55 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 QQlcgv21418
	for <mpls@UU.NET>; Thu, 16 Aug 2001 04:15:01 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlcgu04758
	for <mpls@UU.NET>; Thu, 16 Aug 2001 04:14:59 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <Q3W0WHSP>; Thu, 16 Aug 2001 09:48:05 +0500
Message-ID: <751B6DD7A243D511AB9F0002557C5687AF4E95@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: RE: Traffic Engineering TLV
Date: Thu, 16 Aug 2001 09:48:05 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1260E.A3116B70"
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_01C1260E.A3116B70
Content-Type: text/plain;
	charset="iso-8859-1"



Dear Naidu

       The priority/premption is a task of MPLS Management module. I would
like 
       to know why the 8 priority levels are provided in the OSPF Extension?
What 
       i was thinking is this 8 priority levels is used by the CSPF for the
computation 
       of the routes. If so, why is it Unreservable Bandwidth for the 8
priority levels ? 
       does it mean that on a link we configure the Bandwidth for different
priority levels ?
       (Like Priority 0 -> 30 % bandwidth etc )
       Or this is ment for some other purpose ?
       As i found the draft draft-katz-yeung-ospf-traffic-04 not mentioning
it clearly.
   

Regds
Ashwin



-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Tuesday, August 14, 2001 7:37 PM
To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV


Prabhu:

->             Can anyone please tell me what are these 8 
-> priority levels and what for these 
->             used ? 

  There are no set of semantics for each priority level. 
  The different levels provide an ordering that can be 
  used to determine preemption during the establishment 
  of LSPs. They can also be used by an implementation 
  as a means of ordering LSP computation and setup.

  How to use these priority levels? Look at:
  CR-LDP draft-ietf-mpls-cr-ldp-05.txt and
  RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt

-> why we need this. 

  The need for priority levels is specified in
  RFC 2702. There is a consensus of eight protocols 
  being sufficient.  

  In Dan's terms...

  "The priority attribute defines the relative importance of traffic
   trunks.  If a constraint-based routing framework is used with MPLS,
   then priorities become very important because they can be used to
   determine the order in which path selection is done for traffic
   trunks at connection establishment and under fault scenarios.

   Priorities are also important in implementations  permitting
   preemption because they can be used to impose a partial order on the
   set of traffic trunks according to which preemptive policies can be
   actualized."

--Venkata Naidu

------_=_NextPart_001_01C1260E.A3116B70
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>RE: Traffic Engineering TLV</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>Dear Naidu</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
priority/premption is a task of MPLS Management module. I would like =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to know why the =
8 priority levels are provided in the OSPF Extension? What </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i was thinking =
is this 8 priority levels is used by the CSPF for the computation =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the routes. =
If so, why is it Unreservable Bandwidth for the 8 priority levels ? =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; does it mean =
that on a link we configure the Bandwidth for different priority levels =
?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Like Priority =
0 -&gt; 30 % bandwidth etc )</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Or this is ment =
for some other purpose ?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As i found the =
draft draft-katz-yeung-ospf-traffic-04 not mentioning it =
clearly.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Regds</FONT>
<BR><FONT SIZE=3D2>Ashwin</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Naidu, Venkata [<A =
HREF=3D"mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 14, 2001 7:37 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Ashwin C. Prabhu'; mpls@UU.NET; =
mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=3D2>Subject: FW: Traffic Engineering TLV</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Prabhu:</FONT>
</P>

<P><FONT =
SIZE=3D2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Can anyone please tell me what are these 8 </FONT>
<BR><FONT SIZE=3D2>-&gt; priority levels and what for these </FONT>
<BR><FONT =
SIZE=3D2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; used ? </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; There are no set of semantics for each =
priority level. </FONT>
<BR><FONT SIZE=3D2>&nbsp; The different levels provide an ordering that =
can be </FONT>
<BR><FONT SIZE=3D2>&nbsp; used to determine preemption during the =
establishment </FONT>
<BR><FONT SIZE=3D2>&nbsp; of LSPs. They can also be used by an =
implementation </FONT>
<BR><FONT SIZE=3D2>&nbsp; as a means of ordering LSP computation and =
setup.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; How to use these priority levels? Look =
at:</FONT>
<BR><FONT SIZE=3D2>&nbsp; CR-LDP draft-ietf-mpls-cr-ldp-05.txt =
and</FONT>
<BR><FONT SIZE=3D2>&nbsp; RSVP-TE =
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt</FONT>
</P>

<P><FONT SIZE=3D2>-&gt; why we need this. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; The need for priority levels is specified =
in</FONT>
<BR><FONT SIZE=3D2>&nbsp; RFC 2702. There is a consensus of eight =
protocols </FONT>
<BR><FONT SIZE=3D2>&nbsp; being sufficient.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; In Dan's terms...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; &quot;The priority attribute defines the =
relative importance of traffic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; trunks.&nbsp; If a constraint-based =
routing framework is used with MPLS,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; then priorities become very important =
because they can be used to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; determine the order in which path =
selection is done for traffic</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; trunks at connection establishment and =
under fault scenarios.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; Priorities are also important in =
implementations&nbsp; permitting</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; preemption because they can be used to =
impose a partial order on the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; set of traffic trunks according to =
which preemptive policies can be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; actualized.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>--Venkata Naidu</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1260E.A3116B70--


From owner-mpls@UU.NET  Thu Aug 16 00:36:34 2001
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 AAA08237
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 00:36:34 -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 QQlcgw02819;
	Thu, 16 Aug 2001 04:36:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcgw09870
	for mpls-outgoing; Thu, 16 Aug 2001 04:35: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 QQlcgw09858
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 04:35:39 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 QQlcgw06611
	for <mpls@UU.NET>; Thu, 16 Aug 2001 04:31:29 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlcgw00655
	for <mpls@UU.NET>; Thu, 16 Aug 2001 04:31:27 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <QV8NP1JG>; Thu, 16 Aug 2001 09:58:34 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6872@mailserver.netbrahma.com>
From: Manoj Agiwal <ManojA@netbrahma.com>
To: "'Feng, Mark'" <m_feng@trillium.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RRO Processing
Date: Thu, 16 Aug 2001 09:58:34 +0530
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 Feng ,
     One Resv message may contain multiple filter descriptors ,
and each filter descriptor may contain RRO . By "new" I meant
should we drop the RRO for the filter descriptor newly added  in the Resv
Message , for a new sender .
     There is another possibility that initially for the PSB state and the
corresponding RSB  state does not contain RRO object and
down the line Path messages starts including the RRO object, now the
corresponding Resv messages for this sender  also starts including the RRO
object at the egress , in such a scenario 
at any LSR if one gets MTU exceed error, the RRO for which sender should be
removed ( Resv message contains multiple filter descriptor )
Regards ,
Manoj

     

> ----------
> From: 	Feng, Mark[SMTP:m_feng@trillium.com]
> Sent: 	Thursday, August 16, 2001 2:46 AM
> To: 	'mpls@UU.NET'
> Subject: 	RE: RRO Processing
> 
> In the Path message, there should be only one RRO. So, if it is too big,
> the
> RRO is removed.
> 
> In Resv message, IMO, it should be consistent with Path, i.e. the RRO
> should
> be dropped per sender.
> 
> I am not sure what you mean by "new". The RRO procedure initiates either
> by
> the ingress or the egress.
> 
> -Mark
> 
> > -----Original Message-----
> > From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> > Sent: Monday, August 13, 2001 9:28 PM
> > To: 'mpls@UU.NET'
> > Subject: RRO Processing
> > 
> > 
> > Hi ,
> >       In case of RRO processing ,
> > 
> > "If the newly added subobject causes the RRO to be too big to fit 
> > in a  Path (or Resv) message, the RRO object SHALL be dropped 
> > from the  message and message processing continues as normal"
> > 
> >  In this particular case will the RRO object will be dropped 
> > for all the
> > Filter Descriptors  , or for the one which is new .
> > 
> > How the case should be handled in case if RRO was not there 
> > and subsequent
> > adding the RRO object starts giving this error .
> > 
> > Regards ,
> > Manoj
> > 
> > 
> >  
> 


From owner-mpls@UU.NET  Thu Aug 16 02:10:53 2001
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 CAA25036
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 02:10:53 -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 QQlchc22990;
	Thu, 16 Aug 2001 06:10:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlchc24620
	for mpls-outgoing; Thu, 16 Aug 2001 06:10: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 QQlchc24394
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 06:10:16 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 QQlchc14803
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:08:19 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQlchc28567
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:08:18 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7G68CP26352
	for <mpls@uu.net>; Thu, 16 Aug 2001 08:08:12 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256AAA.0021B3EC ; Thu, 16 Aug 2001 08:08:07 +0200
X-Lotus-FromDomain: ALCATEL
To: mpls@UU.NET
Message-ID: <C1256AAA.0021B1EA.00@Bemail06.net.alcatel.be>
Date: Thu, 16 Aug 2001 08:08:02 +0200
Subject: RFC 3107
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




Hello,

Section 3 of RFC 3107 states the following:

> b) Label:
>
>         The Label field carries one or more labels (that corresponds to
>         the stack of labels [MPLS-ENCAPS]).  Each label is encoded as 3
>        octets, where the high-order 20 bits contain the label value,
>        and the low order bit contains "Bottom of Stack" (as defined in
>         [MPLS-ENCAPS]).

This description only covers the setting of 20 + 1 bits out of the 24 bits. How should the remaining 3 bits be set:
* Should they be set to 0 when transmitting and be ignored on receipt?
OR
* Should they be used to carry exp information?

Thanks for your reply.

     Francis.




From owner-mpls@UU.NET  Thu Aug 16 02:21:59 2001
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 CAA25129
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 02:21:59 -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 QQlchd24241;
	Thu, 16 Aug 2001 06:21:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlchd26409
	for mpls-outgoing; Thu, 16 Aug 2001 06:20: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 QQlchd26401
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 06:20:25 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 QQlchd19463
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:19:06 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 QQlchd20010
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:19:04 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [192.168.235.4])
	by wiprom2mx1.wipro.com (8.10.2+Sun/8.11.3) with SMTP id f7GBwBJ01776
	for <mpls@UU.NET>; Thu, 16 Aug 2001 11:58:11 GMT
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GI5DU400.NOR; Thu, 16 Aug 2001 11:55:16 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id GAA16799; Thu, 16 Aug 2001 06:58:38 +0530
Date: Thu, 16 Aug 2001 11:53:10 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: Zaheer Aziz <zaziz@cisco.com>
cc: Mohit Misra <MohitM@netbrahma.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: MPLS over FR
In-Reply-To: <4.3.2.7.2.20010814173808.048bc4e8@ce-nfs-1.cisco.com>
Message-ID: <Pine.LNX.4.31.0108161150280.14806-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi Zaheer,
	How do you do this label stacking in FR n/ws? As far as my
knowledge is concerned I don't find any reference any where(including 3034
RFC) regarding label stacking in FR. Eric's quote from 3034 is more
appropriate here, I feel.

regards
Bhushana


> At 08:42 AM 8/15/2001 +0900, Mohit Misra wrote:
> >I have a doubt regarding MPLS over FR. Consider the case when two LDP peers
> >are connected over a FR cloud and intermediate FR switches are MPLS unaware.
> >A label mapping (DLCI) is negotiated between them. When the upstream node
> >sends a labled packet with the negotiated DLCI,
>
>
> LSRA---dlci 1--FR-SW1-----FR-SW2--dlci 2---LSRB----FEC X
>
> LSRA and LSRB are LDP peers and has exchanged label (L) for FEC X.
> FR-SW are not running MPLS.
>
> This negotiated label (L) through LDP is put in MPLS Header for any traffic
> destined for FEC F, but
> to reach LSRB, LSRA uses DLCI 1 which FR-SW1 understands and forwards it to
> SW2 which maps DLC2
> to reach LSRB.
> Now LSR B receives MPLS header with label L and it should have a mapping in
> LFIB to forward appropriately.
>
> Thanks
> Zaheer
>
>
>
>
> >the intermediate switches
> >will modify this value and finally it will reach the downstream node with a
> >different DLCI value (which was not negotiated ). ATM solves this problem by
> >VCID notification. How it is resolved in FR case ?
> >                                 /Mohit
>
>



From owner-mpls@UU.NET  Thu Aug 16 02:58:29 2001
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 CAB25406
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 02:58:29 -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 QQlchf02790;
	Thu, 16 Aug 2001 06:58:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlchf29162
	for mpls-outgoing; Thu, 16 Aug 2001 06:57: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 QQlchf29155
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 06:57:47 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 QQlchf02186
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:56:35 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlchf14399
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:56:35 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA10564 for mpls@uu.net; Thu, 16 Aug 2001 02:56:33 -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 QQlchf29064
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 06:56:24 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 QQlchf27764
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:46:24 GMT
Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQlchf01350
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:46:24 GMT
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7G6kNT14209;
	Wed, 15 Aug 2001 23:46:23 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f7G6kHf13484;
	Wed, 15 Aug 2001 23:46:17 -0700 (PDT)
Received: from ZAZIZ-W2K.cisco.com (zaziz-dsl1.cisco.com [144.254.219.198]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id XAA10547; Wed, 15 Aug 2001 23:46:04 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010815233753.02163e58@ce-nfs-1.cisco.com>
X-Sender: zaziz@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 15 Aug 2001 23:46:01 -0700
To: <nagabhushana.ramaswamy@wipro.com>
From: Zaheer Aziz <zaziz@cisco.com>
Subject: Re: MPLS over FR
Cc: Mohit Misra <MohitM@netbrahma.com>, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <Pine.LNX.4.31.0108161150280.14806-100000@boochi.alc.wipinf
 o.soft.net>
References: <4.3.2.7.2.20010814173808.048bc4e8@ce-nfs-1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 11:53 AM 8/16/2001 +0400, Nagabhushana Ramaswamy Nadig wrote:

>Hi Zaheer,

Hi Bhushana,


>         How do you do this label stacking in FR n/ws? As far as my
>knowledge is concerned I don't find any reference any where(including 3034
>RFC) regarding label stacking in FR. Eric's quote from 3034 is more
>appropriate here, I feel.
>

For Frame Relay encapsulation as described in RFC 1490 it should be like 
in  section

4.1.  Routed Frames sections
Modification in the packet done by LSR would be
ethertype  be 8847(unicast IPv4) followed by label stack (32 bits each) 
followed by data payload, FCS and 7E Flag






What Eric is talking about it when DLCI == labels when FR switches in the 
middle runs LDP, where as your question precisely asked when FR switches 
are not running MPLS.

You wrote
"Consider the case when two LDP peers are connected over a FR cloud and 
intermediate FR switches are MPLS unaware."


Switches will not look at the MPLS labels and they should just switch based 
on DLCI mapping taken from Frame Relay header
(Q.922 Address)


Hope this helps
Zaheer




>regards
>Bhushana
>
>
> > At 08:42 AM 8/15/2001 +0900, Mohit Misra wrote:
> > >I have a doubt regarding MPLS over FR. Consider the case when two LDP 
> peers
> > >are connected over a FR cloud and intermediate FR switches are MPLS 
> unaware.
> > >A label mapping (DLCI) is negotiated between them. When the upstream node
> > >sends a labled packet with the negotiated DLCI,
> >
> >
> > LSRA---dlci 1--FR-SW1-----FR-SW2--dlci 2---LSRB----FEC X
> >
> > LSRA and LSRB are LDP peers and has exchanged label (L) for FEC X.
> > FR-SW are not running MPLS.
> >
> > This negotiated label (L) through LDP is put in MPLS Header for any traffic
> > destined for FEC F, but
> > to reach LSRB, LSRA uses DLCI 1 which FR-SW1 understands and forwards it to
> > SW2 which maps DLC2
> > to reach LSRB.
> > Now LSR B receives MPLS header with label L and it should have a mapping in
> > LFIB to forward appropriately.
> >
> > Thanks
> > Zaheer
> >
> >
> >
> >
> > >the intermediate switches
> > >will modify this value and finally it will reach the downstream node 
> with a
> > >different DLCI value (which was not negotiated ). ATM solves this 
> problem by
> > >VCID notification. How it is resolved in FR case ?
> > >                                 /Mohit
> >
> >



From owner-mpls@UU.NET  Thu Aug 16 03:01:29 2001
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 DAA25451
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 03:01:29 -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 QQlchg07749;
	Thu, 16 Aug 2001 07:01:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlchg01868
	for mpls-outgoing; Thu, 16 Aug 2001 07:00: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 QQlchg01581
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 07:00:35 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 QQlchf14766
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:57:15 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlchf15347
	for <mpls@uu.net>; Thu, 16 Aug 2001 06:57:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA10593 for mpls@uu.net; Thu, 16 Aug 2001 02:57:14 -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 QQlchf29106
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 06:57:00 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 QQlche23384
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:32:12 GMT
Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlche09491
	for <mpls@UU.NET>; Thu, 16 Aug 2001 06:32:11 GMT
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7G6VxQ00558;
	Wed, 15 Aug 2001 23:31:59 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f7G6WAR08898;
	Wed, 15 Aug 2001 23:32:10 -0700 (PDT)
Received: from ZAZIZ-W2K.cisco.com (zaziz-dsl1.cisco.com [144.254.219.198]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id XAA09405; Wed, 15 Aug 2001 23:31:58 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010815232920.022060c8@ce-nfs-1.cisco.com>
X-Sender: zaziz@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 15 Aug 2001 23:31:55 -0700
To: francis.arts@alcatel.be
From: Zaheer Aziz <zaziz@cisco.com>
Subject: Re: RFC 3107
Cc: mpls@UU.NET
In-Reply-To: <C1256AAA.0021B1EA.00@Bemail06.net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 08:08 AM 8/16/2001 +0200, francis.arts@alcatel.be wrote:



>Hello,
>
>Section 3 of RFC 3107 states the following:
>
> > b) Label:
> >
> >         The Label field carries one or more labels (that corresponds to
> >         the stack of labels [MPLS-ENCAPS]).  Each label is encoded as 3
> >        octets, where the high-order 20 bits contain the label value,
> >        and the low order bit contains "Bottom of Stack" (as defined in
> >         [MPLS-ENCAPS]).
>
>This description only covers the setting of 20 + 1 bits out of the 24 
>bits. How should the remaining 3 bits be set:
>* Should they be set to 0 when transmitting and be ignored on receipt?

it should be set to 0 as no other usage is specified. 24 bit makes it on 
a  nice octet boundary and makes it easy to READ

Zaheer


>OR
>* Should they be used to carry exp information?
>
>Thanks for your reply.
>
>      Francis.



From owner-mpls@UU.NET  Thu Aug 16 09:47:36 2001
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 JAA06580
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 09:47:36 -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 QQlcih12668;
	Thu, 16 Aug 2001 13:46:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcih14711
	for mpls-outgoing; Thu, 16 Aug 2001 13:46:13 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 QQlcih14671
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 13:46:10 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 QQlcig19926
	for <mpls@UU.NET>; Thu, 16 Aug 2001 13:43:39 GMT
Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcig18075
	for <mpls@UU.NET>; Thu, 16 Aug 2001 13:43:34 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GDh3p17765
	for <mpls@UU.NET>; Thu, 16 Aug 2001 09:43:04 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 16 Aug 2001 09:42:49 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RABF92BV>; Thu, 16 Aug 2001 09:42:53 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3429DE44@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Ping Pan <pingpan@juniper.net>
Cc: mpls@UU.NET
Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]
Date: Thu, 16 Aug 2001 09:42:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12659.5A833E60"
X-Orig: <dallan@americasm01.nt.com>
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_01C12659.5A833E60
Content-Type: text/plain;
	charset="iso-8859-1"

I guess this is where we don't see eye to eye. There is plenty of experience
with similar technologies and that experience is portable such that some
problems can be anticipated. This tells me we can be more proactive than
merely sticking our fingers in the dyke.

rgds
Dave

-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Wednesday, August 15, 2001 5:14 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: mpls@UU.NET
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]


David Allan wrote:

> 
> Secular issues aside ;-), what you describe above is a pragmatic 
> response to improving the reliability of a particular application of 
> MPLS, and that's OK, but I trust you aren't suggesting that the above is 
> a complete solution....
> 


Dave,

You are right. We are not solving all the problems in the MPLS world. In 
fact I doubt anybody knows all the problems.  :-)

Base on our (both vendors and providers) experience, we will solve the 
problems as they come up. I hope this is a reasonable approach.

Best regards,

- Ping



------_=_NextPart_001_01C12659.5A833E60
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.2654.89">
<TITLE>RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I guess this is where we don't see eye to eye. There =
is plenty of experience with similar technologies and that experience =
is portable such that some problems can be anticipated. This tells me =
we can be more proactive than merely sticking our fingers in the =
dyke.</FONT></P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ping Pan [<A =
HREF=3D"mailto:pingpan@juniper.net">mailto:pingpan@juniper.net</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 5:14 PM</FONT>
<BR><FONT SIZE=3D2>To: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Fwd: I-D =
ACTION:draft-pan-rsvp-te-restart-01.txt]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>David Allan wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Secular issues aside ;-), what you describe =
above is a pragmatic </FONT>
<BR><FONT SIZE=3D2>&gt; response to improving the reliability of a =
particular application of </FONT>
<BR><FONT SIZE=3D2>&gt; MPLS, and that's OK, but I trust you aren't =
suggesting that the above is </FONT>
<BR><FONT SIZE=3D2>&gt; a complete solution....</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dave,</FONT>
</P>

<P><FONT SIZE=3D2>You are right. We are not solving all the problems in =
the MPLS world. In </FONT>
<BR><FONT SIZE=3D2>fact I doubt anybody knows all the problems.&nbsp; =
:-)</FONT>
</P>

<P><FONT SIZE=3D2>Base on our (both vendors and providers) experience, =
we will solve the </FONT>
<BR><FONT SIZE=3D2>problems as they come up. I hope this is a =
reasonable approach.</FONT>
</P>

<P><FONT SIZE=3D2>Best regards,</FONT>
</P>

<P><FONT SIZE=3D2>- Ping</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C12659.5A833E60--


From owner-mpls@UU.NET  Thu Aug 16 10:20:00 2001
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 KAA08636
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 10:20:00 -0400 (EDT)
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 QQlcij24507;
	Thu, 16 Aug 2001 14:21:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcij07473
	for mpls-outgoing; Thu, 16 Aug 2001 14:20:33 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 QQlcij07462
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 14:20:25 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 QQlcii21287
	for <mpls@uu.net>; Thu, 16 Aug 2001 14:12:34 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcii08750
	for <mpls@uu.net>; Thu, 16 Aug 2001 14:12:33 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 KAA12359 for <mpls@uu.net>; Thu, 16 Aug 2001 10:12:33 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06513 for mpls@uu.net; Thu, 16 Aug 2001 10:12:10 -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 QQlcgx11075
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 04:50:10 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 QQlcgx17109
	for <mpls@uu.net>; Thu, 16 Aug 2001 04:49:58 GMT
Received: from web20302.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20302.mail.yahoo.com [216.136.226.83])
	id QQlcgx28748
	for <mpls@uu.net>; Thu, 16 Aug 2001 04:49:58 GMT
Message-ID: <20010816044957.30477.qmail@web20302.mail.yahoo.com>
Received: from [63.25.3.169] by web20302.mail.yahoo.com; Wed, 15 Aug 2001 21:49:57 PDT
Date: Wed, 15 Aug 2001 21:49:57 -0700 (PDT)
From: Jia Hong <jia_hong2000@yahoo.com>
Subject: Hello Message Extension
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        I have one more doubt related to hello
message. If there are say 3 interfaces between two
nodes then the hellos should be transmitted on all the
3 interfaces. This means the hello message are used to
detect the interface failures and not the node failure
in case there are multiple parallel point to point
links between two nodes.

Thanks in advance,
Jia.

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Thu Aug 16 10:20:19 2001
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 KAA08673
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 10:20:18 -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 QQlcij11705;
	Thu, 16 Aug 2001 14:21:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcij07686
	for mpls-outgoing; Thu, 16 Aug 2001 14:20:56 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 QQlcij07669
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 14:20: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 QQlcii00987
	for <mpls@uu.net>; Thu, 16 Aug 2001 14:12:42 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcii10528
	for <mpls@uu.net>; Thu, 16 Aug 2001 14:12:42 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 KAA12384 for <mpls@uu.net>; Thu, 16 Aug 2001 10:12:42 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06517 for mpls@uu.net; Thu, 16 Aug 2001 10:12:18 -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 QQlcgx11367
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 04:54:38 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 QQlcgw11714
	for <mpls@uu.net>; Thu, 16 Aug 2001 04:44:36 GMT
Received: from web20301.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20301.mail.yahoo.com [216.136.226.82])
	id QQlcgw15581
	for <mpls@uu.net>; Thu, 16 Aug 2001 04:44:36 GMT
Message-ID: <20010816044435.81201.qmail@web20301.mail.yahoo.com>
Received: from [63.25.3.169] by web20301.mail.yahoo.com; Wed, 15 Aug 2001 21:44:35 PDT
Date: Wed, 15 Aug 2001 21:44:35 -0700 (PDT)
From: Jia Hong <jia_hong2000@yahoo.com>
Subject: RSVP Refresh Reduction
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        I have a doubt related to message_id object in
refresh reduction draft. If there are two nodes that
are RSVP (and refresh reduction) capable. There are
say 3 point-to-point interfaces between these nodes.
The RSVP mailing list says once you get the SREFRESH
message, first try to get the session to whom the
message_id belongs. Should the message_ids be same
across the different interfaces towards the same node
? I mean to say message_id pools be different for
different interfaces toward the same neighbor or these
interfaces use the same message_id pool for allocation
of message_ids towards one neighbor/node ? Should
neighbor be considered as one interface or physical
node itself irrespective of # of interfaces between
two adjacent nodes ?
If these pools are interface based, then multiple
sessions use the same pool that fall under the same
interface ?

Thanks in advance,
Jia.

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Thu Aug 16 10:20:27 2001
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 KAA08687
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 10:20: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 QQlcij22139;
	Thu, 16 Aug 2001 14:21:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcij07695
	for mpls-outgoing; Thu, 16 Aug 2001 14:21: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 QQlcij07674
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 14:20:50 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 QQlcii00923
	for <mpls@UU.NET>; Thu, 16 Aug 2001 14:12:26 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 QQlcii09841
	for <mpls@UU.NET>; Thu, 16 Aug 2001 14:12:20 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 KAA13914;
	Thu, 16 Aug 2001 10:12:09 -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 KAA25136;
	Thu, 16 Aug 2001 10:12:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <Q6LAS89B>; Thu, 16 Aug 2001 10:12:07 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C6E4@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ashwin C. Prabhu'" <Ashwinp@in.huawei.com>,
        "Naidu, Venkata"
	 <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV
Date: Thu, 16 Aug 2001 10:12:06 -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

Ashwin:

   Please look at my inline comments...

-> The priority/preemption is a task of MPLS Management 
-> module. I would like to know why the 8 priority levels 
-> are provided in the OSPF Extension? 

   OSPF (for that matter any IGP) job is to flood the TE
   information throughout the area (at present) for TE
   purpose. The 8 priority levels for unreserved bw is 
   nothing to do with OSPF calculations. Just flood the info!

-> What i was thinking is this 8 priority levels is used by 
-> the CSPF for the computation of the routes. If so, why 
-> is it Unreservable Bandwidth for the 8 priority levels ? 

   Yes! After flooding the TE information, ingress LERs do 
   CSPF to prune links (which are not met the requested 
   bw, priority, preemption etc) to find the best path to egress.

-> does it mean that on a link we configure the Bandwidth 
-> for different priority levels ? 
->        (Like Priority 0 -> 30 % bandwidth etc ) 
->        Or this is ment for some other purpose ? 

   It is not that simple, please look at Kompella's paper
   draft-kompella-tewg-bw-acct-00.txt (and nested references)

->        As i found the draft draft-katz-yeung-ospf-traffic-04 
-> not mentioning it clearly. 

   As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do
   with configuration of priority levels. 

--Venkata Naidu


-> -----Original Message----- 
-> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] 
-> Sent: Tuesday, August 14, 2001 7:37 PM 
-> To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com 
-> Subject: FW: Traffic Engineering TLV 
-> 
-> 
-> Prabhu: 
-> ->             Can anyone please tell me what are these 8 
-> -> priority levels and what for these 
-> ->             used ? 
->   There are no set of semantics for each priority level. 
->   The different levels provide an ordering that can be 
->   used to determine preemption during the establishment 
->   of LSPs. They can also be used by an implementation 
->   as a means of ordering LSP computation and setup. 
->   How to use these priority levels? Look at: 
->   CR-LDP draft-ietf-mpls-cr-ldp-05.txt and 
->   RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 
-> -> why we need this. 
->   The need for priority levels is specified in 
->   RFC 2702. There is a consensus of eight protocols 
->   being sufficient.  
->   In Dan's terms... 
->   "The priority attribute defines the relative importance of traffic 
->    trunks.  If a constraint-based routing framework is used 
-> with MPLS, 
->    then priorities become very important because they can be used to 
->    determine the order in which path selection is done for traffic 
->    trunks at connection establishment and under fault scenarios. 
->    Priorities are also important in implementations  permitting 
->    preemption because they can be used to impose a partial 
-> order on the 
->    set of traffic trunks according to which preemptive 
-> policies can be 
->    actualized." 
-> --Venkata Naidu 
-> 


From owner-mpls@UU.NET  Thu Aug 16 11:08:36 2001
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 LAA11534
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 11:08:36 -0400 (EDT)
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 QQlcim15098;
	Thu, 16 Aug 2001 15:09:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcim26112
	for mpls-outgoing; Thu, 16 Aug 2001 15:09: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 QQlcim25573
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 15:09:04 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 QQlcil08064
	for <mpls@UU.NET>; Thu, 16 Aug 2001 14:53:05 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 QQlcil11244
	for <mpls@UU.NET>; Thu, 16 Aug 2001 14:53:05 GMT
Message-ID: <3B7BDE45.C26A5AD5@sandburst.com>
Date: Thu, 16 Aug 2001 10:52:53 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Zaheer Aziz <zaziz@cisco.com>
Cc: nagabhushana.ramaswamy@wipro.com, Mohit Misra <MohitM@netbrahma.com>,
        MPLS Mailing List <mpls@UU.NET>
Subject: Re: MPLS over FR
References: <4.3.2.7.2.20010814173808.048bc4e8@ce-nfs-1.cisco.com> <4.3.2.7.2.20010815233753.02163e58@ce-nfs-1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Zaheer,

    I'm not certain I entirely agree with what you've suggested here.

    Encapsulation of generic MPLS labels over a Frame Relay PVC
(or SVC) is somewhat messier than even you've indicated.  Either
the two end points of the FR-PVC/SVC have to infer the following
label stack from the DLCIs, or the FR-PVC/SVC has to carry the
generic MPLS labels encapsulated in some higher level protocol
for which support is directly defined in RFC 1490 (e.g. Ethernet), or
by cheating (somewhat) by using SNAP and OUI indicating that an
Ethertype follows and following it with the Ethertype for Unicast
MPLS (not IPv4).  I think this is a slight cheat, because it may not
be the case that every FR switch will support this Ethertype, it not
having been defined all that long ago.

    Also, FR-LSRs (like ATM-LSRs), labelled packets are supposed
to be transmitted using NULL encapsulation.  Therefore, it is likely
that even MPLS aware FR switches may not be expecting to see the
SNAP/OUI/Ethertype combination for MPLS labelled packets.

    My interpretation of the original question was based somewhat on
the suggestion that the DLCIs negotiated by non-adjacent FR-LSRs
should in some way be significant to each such LSR inspite of the fact
that there are intervening non-LSR FR switches.  This cannot be the
case, which is why I pointed out the text relating to the use of common
control.

You wrote:

> At 11:53 AM 8/16/2001 +0400, Nagabhushana Ramaswamy Nadig wrote:
>
> >Hi Zaheer,
>
> Hi Bhushana,
>
> >         How do you do this label stacking in FR n/ws? As far as my
> >knowledge is concerned I don't find any reference any where(including 3034
> >RFC) regarding label stacking in FR. Eric's quote from 3034 is more
> >appropriate here, I feel.
> >
>
> For Frame Relay encapsulation as described in RFC 1490 it should be like
> in  section
>
> 4.1.  Routed Frames sections
> Modification in the packet done by LSR would be
> ethertype  be 8847(unicast IPv4) followed by label stack (32 bits each)
> followed by data payload, FCS and 7E Flag
>
> What Eric is talking about it when DLCI == labels when FR switches in the
> middle runs LDP, where as your question precisely asked when FR switches
> are not running MPLS.
>
> You wrote
> "Consider the case when two LDP peers are connected over a FR cloud and
> intermediate FR switches are MPLS unaware."
>
> Switches will not look at the MPLS labels and they should just switch based
> on DLCI mapping taken from Frame Relay header
> (Q.922 Address)
>
> Hope this helps
> Zaheer
>
> >regards
> >Bhushana
> >
> >
> > > At 08:42 AM 8/15/2001 +0900, Mohit Misra wrote:
> > > >I have a doubt regarding MPLS over FR. Consider the case when two LDP
> > peers
> > > >are connected over a FR cloud and intermediate FR switches are MPLS
> > unaware.
> > > >A label mapping (DLCI) is negotiated between them. When the upstream node
> > > >sends a labled packet with the negotiated DLCI,
> > >
> > >
> > > LSRA---dlci 1--FR-SW1-----FR-SW2--dlci 2---LSRB----FEC X
> > >
> > > LSRA and LSRB are LDP peers and has exchanged label (L) for FEC X.
> > > FR-SW are not running MPLS.
> > >
> > > This negotiated label (L) through LDP is put in MPLS Header for any traffic
> > > destined for FEC F, but
> > > to reach LSRB, LSRA uses DLCI 1 which FR-SW1 understands and forwards it to
> > > SW2 which maps DLC2
> > > to reach LSRB.
> > > Now LSR B receives MPLS header with label L and it should have a mapping in
> > > LFIB to forward appropriately.
> > >
> > > Thanks
> > > Zaheer
> > >
> > >
> > >
> > >
> > > >the intermediate switches
> > > >will modify this value and finally it will reach the downstream node
> > with a
> > > >different DLCI value (which was not negotiated ). ATM solves this
> > problem by
> > > >VCID notification. How it is resolved in FR case ?
> > > >                                 /Mohit
> > >
> > >



From owner-mpls@UU.NET  Thu Aug 16 11:52:23 2001
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 LAA14022
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 11:52:22 -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 QQlcip22303;
	Thu, 16 Aug 2001 15:53:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcip07032
	for mpls-outgoing; Thu, 16 Aug 2001 15:52: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 QQlcip07012
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 15:52:50 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 QQlcin06622
	for <mpls@UU.NET>; Thu, 16 Aug 2001 15:19:45 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 QQlcin24323
	for <mpls@UU.NET>; Thu, 16 Aug 2001 15:19:45 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 LAA22246
	for <mpls@UU.NET>; Thu, 16 Aug 2001 11:19:43 -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 LAA19246
	for <mpls@UU.NET>; Thu, 16 Aug 2001 11:19:45 -0400 (EDT)
Message-ID: <3B7BE495.34659A4A@marconi.com>
Date: Thu, 16 Aug 2001 11:19:49 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Hello Message Extension
References: <20010816044957.30477.qmail@web20302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jia Hong wrote:
> 
>         I have one more doubt related to hello message. If there are
> say 3 interfaces between two nodes then the hellos should be
> transmitted on all the 3 interfaces. This means the hello message
> are used to detect the interface failures and not the node failure
> in case there are multiple parallel point to point links between two
> nodes.

What protocol are you talking about?

In LDP, Hellos are transmitted on every interface, and work as you
describe - detecting link failures.

In RSVP, if all the interfaces are numbered, Hellos will be sent on each
interface.  If there are unnumbered interfaces, however, Hellos will
only be sent on one interface (per neighbor, of course).  The RSVP-TE
document describes the details of how this is supposed to work.

-- David


From owner-mpls@UU.NET  Thu Aug 16 12:16:59 2001
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 MAA14939
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 12:16:59 -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 QQlcir27390;
	Thu, 16 Aug 2001 16:18:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcir28886
	for mpls-outgoing; Thu, 16 Aug 2001 16:17: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 QQlcir28880
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 16:17:45 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 QQlciq09246
	for <mpls@uu.net>; Thu, 16 Aug 2001 16:12:03 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlciq17680
	for <mpls@uu.net>; Thu, 16 Aug 2001 16:12:03 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA11136 for mpls@uu.net; Thu, 16 Aug 2001 12:12: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 QQlciq27920
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 16:11: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 QQlcio17465
	for <mpls@UU.NET>; Thu, 16 Aug 2001 15:43:22 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlcio11530
	for <mpls@UU.NET>; Thu, 16 Aug 2001 15:43:22 GMT
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: [IP-Optical] Re: An algorithm for calculating all paths between an s-d pair
Date: Thu, 16 Aug 2001 11:43:21 -0400
Message-ID: <A6B096B65978D148BB1B313B18CECC80195B891B@exchange01.movaz.com>
Thread-Topic: [IP-Optical] Re: An algorithm for calculating all paths between an s-d pair
Thread-Index: AcEk6jfBDFFDjrMiQ4O9zzeZBnVmcwBfiZgw
From: "Awduche, Daniel" <awduche@movaz.com>
To: "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>,
        "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
Cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>,
        "Awduche, Daniel" <awduche@movaz.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14939

The 'K-Shortest Path' problem is well known and
well studied (dating back to the late 1950's).
Many different versions of this problem exist, 
subject to various types of restrictions.

There are solution techniques based on improvements
to Dijkstra's algorithm, and many others based 
on network flows and dynamic programming methods.
Some approaches involve elegant graph transformations
(as was the case, for example, in Ramesh's book on 
diverse routing).

In addition to the references mentioned by Ramesh, 
the works of David Eppstein (and the references
therein) may be of interest:
<http://www.ics.uci.edu/~eppstein/pubs/all.html>. 

CAVEAT:-- Many theoretical versions of the K-Shortest
Path problem do not require the paths to be simple 
(i.e. loop-free). 

Yes, the K-Shortest Path problem may have relevance in
optical connection routing, especially when considering
wavelength assignment, optical impairments, and other
constraints.

Cheers,
/Dan  


> -----Original Message-----
> From: Ramesh Bhandari [mailto:bhandari@hotair.hobl.lucent.com]
> Sent: Tuesday, August 14, 2001 1:37 PM
> To: Chrysostomos Tziouvaras
> Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com
> Subject: [IP-Optical] Re: An algorithm for calculating all 
> paths between
> an s-d pair
> 
> 
> Hi Chrysostomos,
> 
> I believe you are searching for the K-shortest path algorithm, which
> provides paths for a given pair of nodes in ascending order of their
> lengths. An example website for information on this is
> http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.
> 
> But, if you are looking for algorithms for K-disjoint paths, these can
> be found in my book: "Survivable Networks: Algorithms for Diverse
> Routing", Kluwer Academic Publishers (1999).
> 
> Regards,
> 
> Ramesh
> 
> Chrysostomos Tziouvaras wrote:
> > 
> > Hi,
> > I am searching for an algorithm for calculating all paths 
> between an s-d
> > pair. Can you provide me pointers to books or URLs?
> > 
> > Thanks
> > Chrysostomos
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 



From owner-mpls@UU.NET  Thu Aug 16 12:45:33 2001
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 MAA15620
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 12:45:33 -0400 (EDT)
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 QQlcit27465;
	Thu, 16 Aug 2001 16:46:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcit01523
	for mpls-outgoing; Thu, 16 Aug 2001 16:46: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 QQlcit01515
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 16:46: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 QQlcis10624
	for <mpls@uu.net>; Thu, 16 Aug 2001 16:32:30 GMT
Received: from chimera.elec.qmul.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQlcis04996
	for <mpls@uu.net>; Thu, 16 Aug 2001 16:32:29 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15XQ4L-0005iu-00
	for mpls@UU.NET; Thu, 16 Aug 2001 17:32:29 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <mpls@UU.NET>
Subject: RE: Hello Message Extension
Date: Thu, 16 Aug 2001 17:39:53 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOCEAGCFAA.hongwei.zhou@elec.qmul.ac.uk>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3B7BE495.34659A4A@marconi.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi David,

Could you please hang on a second here? I have no a concrete concept about
"interface" in LDP specification. Is it a physical link or something else?

Another question is: how to know a router is a LDP egress router? is it the
responsibility of network administrator to configure, or the router itself
can automatically detect that it is on the boundary between MPLS domain and
non-MPLS domain by sending discovery hello message? if the router discovers
in this way , what if the routers in the non-mpls domain don't understand
the hello message?

Thanks a lot!

--henry

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap
Sent: 16 August 2001 16:20
To: mpls@UU.NET
Subject: Re: Hello Message Extension


Jia Hong wrote:
>
>         I have one more doubt related to hello message. If there are
> say 3 interfaces between two nodes then the hellos should be
> transmitted on all the 3 interfaces. This means the hello message
> are used to detect the interface failures and not the node failure
> in case there are multiple parallel point to point links between two
> nodes.

What protocol are you talking about?

In LDP, Hellos are transmitted on every interface, and work as you
describe - detecting link failures.

In RSVP, if all the interfaces are numbered, Hellos will be sent on each
interface.  If there are unnumbered interfaces, however, Hellos will
only be sent on one interface (per neighbor, of course).  The RSVP-TE
document describes the details of how this is supposed to work.

-- David



From owner-mpls@UU.NET  Thu Aug 16 13:51:15 2001
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 NAA17540
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 13:51:15 -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 QQlcix21895;
	Thu, 16 Aug 2001 17:52:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcix27317
	for mpls-outgoing; Thu, 16 Aug 2001 17:51: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 QQlcix27281
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 17:51: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 QQlciw05281
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:43:40 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlciw09183
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:43:39 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA25920
	for <mpls@uu.net>; Thu, 16 Aug 2001 13:43:39 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07478 for mpls@uu.net; Thu, 16 Aug 2001 13:43:15 -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 QQlciw26363
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 17:41:02 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 QQlciw15152
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:33:25 GMT
Received: from web20302.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20302.mail.yahoo.com [216.136.226.83])
	id QQlciw28051
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:33:24 GMT
Message-ID: <20010816173322.38495.qmail@web20302.mail.yahoo.com>
Received: from [38.204.3.195] by web20302.mail.yahoo.com; Thu, 16 Aug 2001 10:33:22 PDT
Date: Thu, 16 Aug 2001 10:33:22 -0700 (PDT)
From: Jia Hong <jia_hong2000@yahoo.com>
Subject: Message_id object in RSVP
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
        I have a doubt related to message_id object in
refresh reduction draft. If there are two nodes that
are RSVP (and refresh reduction) capable. There are
say 3 point-to-point interfaces between these nodes.
The RSVP mailing list says once you get the SREFRESH
message, first try to get the session to whom the
message_id belongs. Should the message_ids be same
across the different interfaces towards the same node
? I mean to say message_id pools be different for
different interfaces toward the same neighbor or these
interfaces use the same message_id pool for allocation
of message_ids towards one neighbor/node ? Should
neighbor be considered as one interface or physical
node itself irrespective of # of interfaces between
two adjacent nodes ?
If these pools are interface based, then multiple
sessions use the same pool that fall under the same
interface ?

Thanks in advance,
Jia.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Thu Aug 16 13:53:41 2001
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 NAA17590
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 13:53:41 -0400 (EDT)
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 QQlcix10575;
	Thu, 16 Aug 2001 17:54:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcix27542
	for mpls-outgoing; Thu, 16 Aug 2001 17:54:21 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 QQlcix27508
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 17:54:12 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 QQlcix17577
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:52:53 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcix22825
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:52:53 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA27254
	for <mpls@uu.net>; Thu, 16 Aug 2001 13:52:52 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07505 for mpls@uu.net; Thu, 16 Aug 2001 13:52:29 -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 QQlcix27062
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 17:48:29 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 QQlciw09163
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:35:51 GMT
Received: from web20302.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20302.mail.yahoo.com [216.136.226.83])
	id QQlciw11149
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:35:51 GMT
Message-ID: <20010816173550.39034.qmail@web20302.mail.yahoo.com>
Received: from [38.204.3.195] by web20302.mail.yahoo.com; Thu, 16 Aug 2001 10:35:50 PDT
Date: Thu, 16 Aug 2001 10:35:50 -0700 (PDT)
From: Jia Hong <jia_hong2000@yahoo.com>
Subject: Re:Hello Message extension
To: david.charlap@marconi.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi David,
           Thank You for your response. I was talking
of RSVP-TE. What if neighbr node does not respond to
hello messages i.e. it is just ignoring the hello
messages. Should I decide that node has gone down but
actually it is not.

Thanks,
Jia.

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Thu Aug 16 13:59:56 2001
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 NAA17728
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 13:59:56 -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 QQlciy05005;
	Thu, 16 Aug 2001 18:01:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlciy00526
	for mpls-outgoing; Thu, 16 Aug 2001 18:00: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 QQlciy00299
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 18:00:35 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 QQlciw12648
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:44:06 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlciw23984
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:44:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA17978 for mpls@uu.net; Thu, 16 Aug 2001 13:44:04 -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 QQlciw26578
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 17:43:33 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 QQlciu26917
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:14:43 GMT
Received: from kcmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso1.att.com [192.128.133.69])
	id QQlciu10248
	for <mpls@uu.net>; Thu, 16 Aug 2001 17:14:38 GMT
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f7GH9OW02590;
	Thu, 16 Aug 2001 13:09:25 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA14981; Thu, 16 Aug 2001 13:08:02 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <Q64FYKRK>; Thu, 16 Aug 2001 13:09:23 -0400
Message-ID: <E5B80B001D76D211879C00E0291077610854B9B9@njc240po05.mt.att.com>
From: "Lerner, Michah, ALSVC" <michah@att.com>
Subject: Call For Papers -- IEEE Communication Magazine - Internet Technol
	ogy Series
Date: Thu, 16 Aug 2001 13:09:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
To: undisclosed-recipients:;
Sender: owner-mpls@UU.NET
Precedence: bulk

                            Call for Papers
                     IEEE Communications Magazine
                      Internet Technology Series
         
                            Series Editors
      Michah Lerner (AT&T) and Khaled Elsayed (Cairo University)

                              IP in 2005  
   Scalability, Programmability, and Virtualization in the Internet


The scalable Internet presents challenges and paradoxes. Scalable and 
malleable services leverage stateless distributed control over the
global address space. Transport bindings nevertheless influence service 
behavior through the control of access, the logical flow of information, 
as well as the availability of diverse content.  Such systems challenge 
the traditional traffic engineering methods for allocation of buffers 
and assignment of resources. The Internet Technology series of the IEEE 
Communications Magazine is calling for original tutorial papers about 
these challenges and their resolution, and suggest the following topics

   o Scalability - the Internet Interdomain Routing Protocols and BGP 
   o Clouds (native IP) vs. strings (MPLS) - Internet evolution choices
   o Programmable routers - architectures and services 
   o Instantiation and Virtualization - IP services providing concrete 
     capabilities through the structuring of resources. 
   o Virtualization of the transport service layers - such as pervasive 
     virtual private networks 
   o Internet services - multilevel and location-aware mobile services,
     including voice over IP (VoIP) 

The IEEE Communications Magazine is read by tens of thousands of 
Communications Society members. The papers will be available on the 
Internet through Communications Magazine Interactive, the WWW edition
of the magazine. Details about IEEE Communications Magazine are online
at http://www.comsoc.org/ci/. 

The online site includes articles selected from Internet Technology
Series, published in the January 2001 and July 2001 IEEE Communications
Magazine. 
 
Tentative Schedule
=========================  
Manuscripts due:             Nov 1, 2001
Notification of acceptance:  Jan 15, 2002 (for the April 2002 issue)
Final copy due:              One month before final publication date
Prospective Magazine issues: April, August, and Oct. 2002


                       How to Submit Manuscripts

Article Style Information  
=========================  
Articles should be tutorial in nature and should be written in a style  
comprehensible to readers outside the specialty of the article.
Articles may be edited for content, and will be copyedited for  
compliance with the magazine's style guidelines. Page proofs will be  
sent to the contact author for final review prior to publication. 
Mathematical equations should not be used unless they are vital to the  
presentation. Even then, they should be kept to a minimum. If the  
article has numerous equations, please contact the editor handling the  
manuscript. 

References should be included only to guide readers to more information  
on the topic; the reference list should not include every available  
source (a limit of ten references is recommended). Use footnotes only  
where necessary. 

Articles should not exceed 4500 words. 

Figures and tables should be limited to a combined total of six. If the  
article exceeds these recommended limits, please contact the editor  
handling the manuscript. 

Submission  

Electronic submission of manuscripts as PDF or Postscript is required.

Please send your submission to both series editors:  
   Khaled Elsayed: khaled@ieee.org  
   Michah Lerner: michah@ieee.org 

-----------------------------------------------------------------------
This CFP is also online at http://inetseries.tripod.com  



From owner-mpls@UU.NET  Thu Aug 16 14:57:46 2001
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 OAA19865
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 14:57: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 QQlcjb04340;
	Thu, 16 Aug 2001 18:58:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjb23811
	for mpls-outgoing; Thu, 16 Aug 2001 18:58:28 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 QQlcjb23804
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 18:58:23 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 QQlcjb12566
	for <mpls@uu.net>; Thu, 16 Aug 2001 18:55:09 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcjb17937
	for <mpls@uu.net>; Thu, 16 Aug 2001 18:55:08 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA24325 for mpls@uu.net; Thu, 16 Aug 2001 14:55:07 -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 QQlcjb23063
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 18:54: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 QQlcjb12231
	for <mpls@uu.net>; Thu, 16 Aug 2001 18:48:46 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f152.law10.hotmail.com [64.4.15.152])
	id QQlcjb07280
	for <mpls@uu.net>; Thu, 16 Aug 2001 18:48:45 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 16 Aug 2001 11:48:44 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Thu, 16 Aug 2001 18:48:44 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: mpls@UU.NET
Subject: Hello Message Doubt
Date: Thu, 16 Aug 2001 11:48:44 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F152LqIfQdmEB4HGXAw00004781@hotmail.com>
X-OriginalArrivalTime: 16 Aug 2001 18:48:44.0646 (UTC) FILETIME=[136BE060:01C12684]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
         Does the transmission of hello messages to RSVP neighbors make 
sense when there is no RSVP session between them ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 16 15:36:55 2001
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 PAA20907
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 15:36: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 QQlcje02953;
	Thu, 16 Aug 2001 19:34:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcje16902
	for mpls-outgoing; Thu, 16 Aug 2001 19:34: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 QQlcje16889
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 19:34: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 QQlcje02830
	for <mpls@uu.net>; Thu, 16 Aug 2001 19:32:42 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 QQlcje29802
	for <mpls@uu.net>; Thu, 16 Aug 2001 19:32:42 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 PAA16456
	for <mpls@uu.net>; Thu, 16 Aug 2001 15:32:39 -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 PAA22822
	for <mpls@uu.net>; Thu, 16 Aug 2001 15:32:42 -0400 (EDT)
Message-ID: <3B7C1FDE.EEA41FC8@marconi.com>
Date: Thu, 16 Aug 2001 15:32:46 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Hello Message extension
References: <20010816173550.39034.qmail@web20302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jia Hong wrote:
> 
>            Thank You for your response. I was talking
> of RSVP-TE. What if neighbr node does not respond to
> hello messages i.e. it is just ignoring the hello
> messages. Should I decide that node has gone down but
> actually it is not.

If the neighbor node has never responded to a Hello message, you should
assume that the neighbor doesn't support the Hello extension.

If the neighbor was responding, and has since stopped, you should assume
that it has gone down.  That's what the purpose of Hello is for.

-- David


From owner-mpls@UU.NET  Thu Aug 16 16:03:21 2001
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 QAA21618
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 16:03:21 -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 QQlcjg16924;
	Thu, 16 Aug 2001 20:04:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjg00764
	for mpls-outgoing; Thu, 16 Aug 2001 20:04: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 QQlcjg00759
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 20:04:03 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 QQlcjf12895
	for <mpls@uu.net>; Thu, 16 Aug 2001 19:52:42 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcjf26211
	for <mpls@uu.net>; Thu, 16 Aug 2001 19:52:41 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 PAA27574 for <mpls@uu.net>; Thu, 16 Aug 2001 15:52:40 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07916 for mpls@uu.net; Thu, 16 Aug 2001 15:52:16 -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 QQlcje17273
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 19:38:29 GMT
Received: from tows021 by imr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: ippool138-218.corp.us.uu.net [153.39.138.218])
	id QQlcje03490;
	Thu, 16 Aug 2001 19:35:22 GMT
Message-Id: <3.0.5.32.20010816153630.00b39100@npiserve0.corp.us.uu.net>
X-Sender: durga@npiserve0.corp.us.uu.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 15:36:30 -0400
To: tziou@ics.forth.g
From: Durga Gangisetti <durga@UU.NET>
Subject: Re: Fwd: RE: [IP-Optical] Re: An algorithm for calculating all
   paths between an s-d pair
Cc: awduche@movaz.com, bhandari@hotair.hobl.lucent.com, mpls@UU.NET,
        IP-Optical@lists.bell-labs.com, mpls-ops@mplsrc.com, ilazar@mplsrc.com,
        durga@cisco.com
In-Reply-To: <5.1.0.14.2.20010816120630.01e653f0@mplsrc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Chrysostomos,

My two cents suuggestion: -)

KSP and maximum flow (MF) can be considered as the two widely used 
routing criteria in survivable networks. Both of them shoot to find the 
max disjoint paths between given/any node-pairs in the network. It can
be said that KSP is simpler computationally than MF, but doesnot may
always generate the optimal disjoint path set. Whereas MF is kind of
guaranted to produce the max no:of possible disjoint paths and maynot
produce the actual path set.

It is found that the difference in their effectiveness in practical network 
topologies is ver small...les than 0.27% ( I guess)according to an extensive
study reported by Dunn & Grover " Cmp of KSPs and MF routing",IEEE 
Jan'94.

Since the difference is so small and the computational complexity between
them is  substantial  [ O (n log (n) ) ) vs O(n*n*n ) + path-set calculation ]
most researchers may argue  that KSP can be used in practice instead of
MF with "no" penalty.

Helpful reference books ( incl what  Ramesh and Dan suggested),
1.Network Flows by Ravindra,Orlin,Magnanti  and
2.Network programming, K G Murthy

Regards,
Durga,
UUnet Technologies Inc,
A Worldcom Company.


At 12:07 PM 8/16/01 -0400, Irwin Lazar wrote:
>Forwarded:
>From: "Awduche, Daniel" <awduche@movaz.com>
>>To: "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>,
>>    "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
>>Cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>,
>>    "Awduche, Daniel" <awduche@movaz.com>
>>X-MIME-Autoconverted: from quoted-printable to 8bit by 
>>host.secure4-hosting.net id f7GFhR522007
>>X-Diagnostic: Not on the accept list
>>X-Envelope-To: mpls-ops
>>
>>The 'K-Shortest Path' problem is well known and
>>well studied (dating back to the late 1950's).
>>Many different versions of this problem exist,
>>subject to various types of restrictions.
>>
>>There are solution techniques based on improvements
>>to Dijkstra's algorithm, and many others based
>>on network flows and dynamic programming methods.
>>Some approaches involve elegant graph transformations
>>(as was the case, for example, in Ramesh's book on
>>diverse routing).
>>
>>In addition to the references mentioned by Ramesh,
>>the works of David Eppstein (and the references
>>therein) may be of interest:
>><http://www.ics.uci.edu/~eppstein/pubs/all.html>.
>>
>>CAVEAT:-- Many theoretical versions of the K-Shortest
>>Path problem do not require the paths to be simple
>>(i.e. loop-free).
>>
>>Yes, the K-Shortest Path problem may have relevance in
>>optical connection routing, especially when considering
>>wavelength assignment, optical impairments, and other
>>constraints.
>>
>>Cheers,
>>/Dan
>>
>>
>> > -----Original Message-----
>> > From: Ramesh Bhandari [mailto:bhandari@hotair.hobl.lucent.com]
>> > Sent: Tuesday, August 14, 2001 1:37 PM
>> > To: Chrysostomos Tziouvaras
>> > Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com
>> > Subject: [IP-Optical] Re: An algorithm for calculating all
>> > paths between
>> > an s-d pair
>> >
>> >
>> > Hi Chrysostomos,
>> >
>> > I believe you are searching for the K-shortest path algorithm, which
>> > provides paths for a given pair of nodes in ascending order of their
>> > lengths. An example website for information on this is
>> > http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.
>> >
>> > But, if you are looking for algorithms for K-disjoint paths, these can
>> > be found in my book: "Survivable Networks: Algorithms for Diverse
>> > Routing", Kluwer Academic Publishers (1999).
>> >
>> > Regards,
>> >
>> > Ramesh
>> >
>> > Chrysostomos Tziouvaras wrote:
>> > >
>> > > Hi,
>> > > I am searching for an algorithm for calculating all paths
>> > between an s-d
>> > > pair. Can you provide me pointers to books or URLs?
>> > >
>> > > Thanks
>> > > Chrysostomos
>> >
>> > _______________________________________________
>> > IP-Optical mailing list
>> > IP-Optical@lists.bell-labs.com
>> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml



From owner-mpls@UU.NET  Thu Aug 16 16:27:09 2001
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 QAA21992
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 16:27:09 -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 QQlcjh26956;
	Thu, 16 Aug 2001 20:28:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjh12344
	for mpls-outgoing; Thu, 16 Aug 2001 20: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 QQlcjh12339
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 20:27:58 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 QQlcjh26991
	for <mpls@uu.net>; Thu, 16 Aug 2001 20:25:47 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcjh22984
	for <mpls@uu.net>; Thu, 16 Aug 2001 20:25:47 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA01498 for mpls@uu.net; Thu, 16 Aug 2001 16:25:46 -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 QQlcjh12029
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 20:25: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 QQlcjg19013
	for <mpls@UU.NET>; Thu, 16 Aug 2001 20:12:36 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQlcjg02565
	for <mpls@UU.NET>; Thu, 16 Aug 2001 20:12:35 GMT
Received: from cisco.com (sj-cse-155.cisco.com [171.68.200.172])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA17277;
	Thu, 16 Aug 2001 13:12:27 -0700 (PDT)
Message-ID: <3B7C2926.E3E90010@cisco.com>
Date: Thu, 16 Aug 2001 13:12:22 -0700
From: "Gopal@Cisco" <gnaganab@cisco.com>
Organization: Cisco Systems Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>
CC: mpls@UU.NET, morekonda@hotmail.com
Subject: Re: Label assignment and distribution
References: <F6839x6HHGNZ4mF1IT10000a04c@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ganges,
> Ganges:::: Well, but the rfc says that,
> 3.4. Label Assignment and Distribution
> 
>    In the MPLS architecture, the decision to bind a particular label L
>    to a particular FEC F is made by the LSR which is DOWNSTREAM with
>    respect to that binding.  The downstream LSR then informs the
>    upstream LSR of the binding.  Thus labels are "downstream-assigned",
>    and label bindings are distributed in the "downstream to upstream"
>    direction.
> 
> In both distribution methods: Unsolicited or OnDemand, is a way how Ru gets
> the label assignment information and it is not specifying who is
> distributing the label assignment. DOWNSTREAM LSR is the one which
> distributes the label assiagnment in both the methods. Please, correct me if
> i'm wrong.

I am not very knowledgeable in this but this is my understanding. so,
others, pls correct if wrong.

prefix-X----R1--R2-----Rd1-------Ru-----
       \                       /
        \                     /
         --------------Rd2---/

Talking about unsolicited-distribution, Rd1, Rd2, Ru distribute labels
to each other fro the prefix-X. However, they install the right
out-label(remote-binding) in their forwarding table. This is driven by
the control plane(routing table + label binding table). So I wd say, the
decision to use the label is local to the LSR.
now from the rfc, === "In the MPLS architecture, the decision to bind a
particular label L
>    to a particular FEC F is *made* by the LSR which is DOWNSTREAM with
>    respect to that binding."

I personally not comfortable reading "*made* by". May be i
misunderstood.

If i have to assume RFC is *GOD*, then i wd try this:
when we say DOWNSTREAM, it is the next-hop. For Ru, if Rd1 is the
next-hop in his routing table, then Rd1 'is and only is':-) Ru's
DOWNSTREAM router. 
I think this explaination goes with the rfc.

About your comments----"" DOWNSTREAM LSR is the one which > distributes
the label assiagnment in both the methods. ""
Logically, it is imposible for any router to know it is the downstream
of another router. For example, Rd1 and Rd2 can not know if they are
DOWNSTREAM rtrs for Ru. However Ru wd know who the DOWNSTREAM router is
for the prefix-X from his routing table. Hence it is impossible for any
router to *assign* labels for another router but can only
advertise/distribute to other rotuers. (assign ---i understood as
installing in the label forwarding table)
Please remember, I may be wrong! Can some one comment??

Thnx, Gopal




Gangadharan Ramakrishnan wrote:
> 
> Gopal,
> See my comments inline....
> 
> Cheers,
> ganges...
> 
> >From: "Gopal@Cisco" <gnaganab@cisco.com>
> >To: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>
> >CC: mpls@UU.NET, morekonda@hotmail.com
> >Subject: Re:
> >Date: Tue, 14 Aug 2001 18:18:14 -0700
> >
> >Ganges,
> >prefix-X------Rd--------Ru--
> >
> >Data packets flow from upstream to downstream towards the destination.
> >Ru will use the label distributed by Rd to impose/insert/swap into the
> >data packet. Rd will take the forwarding decision based on the label it
> >looks in the data packet.
> >So it is necessary for Ru to use the label distributed by Rd for proper
> >transmission.
> >"> Why the bindings are assigned by the downstream LSR"--> i believe you
> >meant labels are assigned.....
> Ganges::; Yes, i mean that exactly.
> >
> >" What makes the architecture to expect aggsinement and distribution of
> > > label bindings from downstream to upstream not the other way?"
> > >
> >Label distribution can happen bothways(depending on distribution
> >methods: unsolicited or ondemand). However, label assignement depends on
> >the routing table. Ru's routing table point to Rd as the next-hop for
> 
> Ganges:::: Well, but the rfc says that,
> 3.4. Label Assignment and Distribution
> 
>    In the MPLS architecture, the decision to bind a particular label L
>    to a particular FEC F is made by the LSR which is DOWNSTREAM with
>    respect to that binding.  The downstream LSR then informs the
>    upstream LSR of the binding.  Thus labels are "downstream-assigned",
>    and label bindings are distributed in the "downstream to upstream"
>    direction.
> 
> In both distribution methods: Unsolicited or OnDemand, is a way how Ru gets
> the label assignment information and it is not specifying who is
> distributing the label assignment. DOWNSTREAM LSR is the one which
> distributes the label assiagnment in both the methods. Please, correct me if
> i'm wrong.
> 
> >prefix-X. Hence Ru will use the label distributed by Rd while forwarding
> >data to preix X. however Rd's routing entry to prefix-X will not point
> >to Ru as the next-hop. Hence Rd will not use the label distributed by Ru
> >for prefix X.
> >
> >rgds,
> >gopal
> >
> >
> >Gangadharan Ramakrishnan wrote:
> > >
> > > Hi,
> > >
> > > I'm new to this MPLS domain. I have a question on MPLS Arch (rfc3031). I
> > > think, may be some one else might have asked this question earlier.
> >Well,
> > > the question is,
> > >
> > > Why the bindings are assigned by the downstream LSR and why not the
> >upstream
> > > LSR? What makes the architecture to expect aggsinement and distribution
> >of
> > > label bindings from downstream to upstream not the other way?
> > >
> > > Thanks in advance....
> > >
> > > Cheers,
> > > ganges....
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> >
> >--
> >Gopal(www-tac/~gnaganab),CCIE#6209,1.408.525.9922,RP-TAC,9:00AM-5:00PM(PST)
> >TAC Tools/Doc's:    http://www.cisco.com/tac/
> >TAC Top Issues:     http://www.cisco.com/kobayashi/support/top_issues/
> >Attach your email to a case: attach@cisco.com , keep the case# in
> >'Subject'
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

-- 
Gopal(www-tac/~gnaganab),CCIE#6209,1.408.525.9922,RP-TAC,9:00AM-5:00PM(PST)
TAC Tools/Doc's:    http://www.cisco.com/tac/
TAC Top Issues:     http://www.cisco.com/kobayashi/support/top_issues/
Attach your email to a case: attach@cisco.com , keep the case# in
'Subject'



From owner-mpls@UU.NET  Thu Aug 16 16:28:10 2001
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 QAA22014
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 16:28: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 QQlcjh28569;
	Thu, 16 Aug 2001 20:29:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjh12388
	for mpls-outgoing; Thu, 16 Aug 2001 20:29: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 QQlcjh12383
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 20:29:02 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 QQlcjg17678
	for <mpls@uu.net>; Thu, 16 Aug 2001 20:08:47 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcjg26772
	for <mpls@uu.net>; Thu, 16 Aug 2001 20:08:47 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA00175 for mpls@uu.net; Thu, 16 Aug 2001 16:08:46 -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 QQlcjg09328
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 20:08:29 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 QQlcjg15512
	for <mpls@UU.NET>; Thu, 16 Aug 2001 20:01:20 GMT
Received: from qlink.queensu.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: Qlink.QueensU.CA [130.15.129.2])
	id QQlcjg07623
	for <mpls@UU.NET>; Thu, 16 Aug 2001 20:01:20 GMT
Received: from Arthur (d141-159-32.home.cgocable.net [24.141.159.32])
	by qlink.queensu.ca (8.10.1/8.10.1) with SMTP id f7GK18X00974;
	Thu, 16 Aug 2001 16:01:08 -0400 (EDT)
Message-ID: <03f701c1269f$a35c3830$209f8d18@Arthur>
From: "Pin-Han Ho" <8ph5@qlink.queensu.ca>
To: "Awduche, Daniel" <awduche@movaz.com>,
        "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>,
        "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
Cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>,
        "Awduche, Daniel" <awduche@movaz.com>
References: <A6B096B65978D148BB1B313B18CECC80195B891B@exchange01.movaz.com>
Subject: Re: [IP-Optical] Re: An algorithm for calculating all paths between an s-d pair
Date: Thu, 16 Aug 2001 15:06:01 -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 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

For performing shared protection in which working and protection paths are
selected based on different link metrics, is there any feasible diverse
routing algorithm?

Thanks.

Pin-Han

----- Original Message -----
From: "Awduche, Daniel" <awduche@movaz.com>
To: "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>; "Chrysostomos
Tziouvaras" <tziou@ics.forth.gr>
Cc: <mpls-ops@mplsrc.com>; <mpls@UU.NET>; <IP-Optical@lists.bell-labs.com>;
"Awduche, Daniel" <awduche@movaz.com>
Sent: Thursday, August 16, 2001 8:43 AM
Subject: RE: [IP-Optical] Re: An algorithm for calculating all paths between
an s-d pair


The 'K-Shortest Path' problem is well known and
well studied (dating back to the late 1950's).
Many different versions of this problem exist,
subject to various types of restrictions.

There are solution techniques based on improvements
to Dijkstra's algorithm, and many others based
on network flows and dynamic programming methods.
Some approaches involve elegant graph transformations
(as was the case, for example, in Ramesh's book on
diverse routing).

In addition to the references mentioned by Ramesh,
the works of David Eppstein (and the references
therein) may be of interest:
<http://www.ics.uci.edu/~eppstein/pubs/all.html>.

CAVEAT:-- Many theoretical versions of the K-Shortest
Path problem do not require the paths to be simple
(i.e. loop-free).

Yes, the K-Shortest Path problem may have relevance in
optical connection routing, especially when considering
wavelength assignment, optical impairments, and other
constraints.

Cheers,
/Dan


> -----Original Message-----
> From: Ramesh Bhandari [mailto:bhandari@hotair.hobl.lucent.com]
> Sent: Tuesday, August 14, 2001 1:37 PM
> To: Chrysostomos Tziouvaras
> Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com
> Subject: [IP-Optical] Re: An algorithm for calculating all
> paths between
> an s-d pair
>
>
> Hi Chrysostomos,
>
> I believe you are searching for the K-shortest path algorithm, which
> provides paths for a given pair of nodes in ascending order of their
> lengths. An example website for information on this is
> http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.
>
> But, if you are looking for algorithms for K-disjoint paths, these can
> be found in my book: "Survivable Networks: Algorithms for Diverse
> Routing", Kluwer Academic Publishers (1999).
>
> Regards,
>
> Ramesh
>
> Chrysostomos Tziouvaras wrote:
> >
> > Hi,
> > I am searching for an algorithm for calculating all paths
> between an s-d
> > pair. Can you provide me pointers to books or URLs?
> >
> > Thanks
> > Chrysostomos
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>







From owner-mpls@UU.NET  Thu Aug 16 17:10:21 2001
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 RAA22960
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 17:10:21 -0400 (EDT)
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 QQlcjk00809;
	Thu, 16 Aug 2001 21:11:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjk04383
	for mpls-outgoing; Thu, 16 Aug 2001 21:11:08 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 QQlcjk04350
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 21:11:03 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 QQlcjk05680;
	Thu, 16 Aug 2001 21:07:36 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQlcjk24194;
	Thu, 16 Aug 2001 21:07:36 GMT
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7GL7Pa12430;
	Thu, 16 Aug 2001 17:07:26 -0400 (EDT)
Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id RAA09000; Thu, 16 Aug 2001 17:07:21 -0400
Message-ID: <3B7C36F1.3EFC0A4B@hotair.hobl.lucent.com>
Date: Thu, 16 Aug 2001 17:11:13 -0400
From: Ramesh Bhandari <bhandari1@lucent.com>
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Durga Gangisetti <durga@UU.NET>
CC: tziou@ics.forth.g, awduche@movaz.com, mpls@UU.NET,
        IP-Optical@lists.bell-labs.com, mpls-ops@mplsrc.com, ilazar@mplsrc.com
Subject: Re: Fwd: RE: [IP-Optical] Re: An algorithm for calculating allpaths 
 between an s-d pair
References: <3.0.5.32.20010816153630.00b39100@npiserve0.corp.us.uu.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Durga,

If by KSP you mean K-disjoint shortest paths as discussed in my book,
then I disagree with your statement " ....KSP is simpler computationally
than MF, but doesnot may always generate the optimal disjoint path
set....". We did once a numerical comparison of the results based on the
algorithms in my book and the one based on the maximum flow (MF). While
the numerical results obtained were exactly identical, the MF method
took much longer to compute, which is not surprising, since the former
is simpler, being based on repeated application of a suitable shortest
path algorithm (e.g., a modified Dijkstra algorithm) in a properly
transformed graph.

Summary: KSP (not the naive algorithm, but the algorithm as given in my
book) is optimal and computationally fast.

Ramesh 

Durga Gangisetti wrote:
> 
> Chrysostomos,
> 
> My two cents suuggestion: -)
> 
> KSP and maximum flow (MF) can be considered as the two widely used
> routing criteria in survivable networks. Both of them shoot to find the
> max disjoint paths between given/any node-pairs in the network. It can
> be said that KSP is simpler computationally than MF, but doesnot may
> always generate the optimal disjoint path set. Whereas MF is kind of
> guaranted to produce the max no:of possible disjoint paths and maynot
> produce the actual path set.
> 
> It is found that the difference in their effectiveness in practical network
> topologies is ver small...les than 0.27% ( I guess)according to an extensive
> study reported by Dunn & Grover " Cmp of KSPs and MF routing",IEEE
> Jan'94.
> 
> Since the difference is so small and the computational complexity between
> them is  substantial  [ O (n log (n) ) ) vs O(n*n*n ) + path-set calculation ]
> most researchers may argue  that KSP can be used in practice instead of
> MF with "no" penalty.
> 
> Helpful reference books ( incl what  Ramesh and Dan suggested),
> 1.Network Flows by Ravindra,Orlin,Magnanti  and
> 2.Network programming, K G Murthy
> 
> Regards,
> Durga,
> UUnet Technologies Inc,
> A Worldcom Company.
> 
> At 12:07 PM 8/16/01 -0400, Irwin Lazar wrote:
> >Forwarded:
> >From: "Awduche, Daniel" <awduche@movaz.com>
> >>To: "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>,
> >>    "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
> >>Cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>,
> >>    "Awduche, Daniel" <awduche@movaz.com>
> >>X-MIME-Autoconverted: from quoted-printable to 8bit by
> >>host.secure4-hosting.net id f7GFhR522007
> >>X-Diagnostic: Not on the accept list
> >>X-Envelope-To: mpls-ops
> >>
> >>The 'K-Shortest Path' problem is well known and
> >>well studied (dating back to the late 1950's).
> >>Many different versions of this problem exist,
> >>subject to various types of restrictions.
> >>
> >>There are solution techniques based on improvements
> >>to Dijkstra's algorithm, and many others based
> >>on network flows and dynamic programming methods.
> >>Some approaches involve elegant graph transformations
> >>(as was the case, for example, in Ramesh's book on
> >>diverse routing).
> >>
> >>In addition to the references mentioned by Ramesh,
> >>the works of David Eppstein (and the references
> >>therein) may be of interest:
> >><http://www.ics.uci.edu/~eppstein/pubs/all.html>.
> >>
> >>CAVEAT:-- Many theoretical versions of the K-Shortest
> >>Path problem do not require the paths to be simple
> >>(i.e. loop-free).
> >>
> >>Yes, the K-Shortest Path problem may have relevance in
> >>optical connection routing, especially when considering
> >>wavelength assignment, optical impairments, and other
> >>constraints.
> >>
> >>Cheers,
> >>/Dan
> >>
> >>
> >> > -----Original Message-----
> >> > From: Ramesh Bhandari [mailto:bhandari@hotair.hobl.lucent.com]
> >> > Sent: Tuesday, August 14, 2001 1:37 PM
> >> > To: Chrysostomos Tziouvaras
> >> > Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com
> >> > Subject: [IP-Optical] Re: An algorithm for calculating all
> >> > paths between
> >> > an s-d pair
> >> >
> >> >
> >> > Hi Chrysostomos,
> >> >
> >> > I believe you are searching for the K-shortest path algorithm, which
> >> > provides paths for a given pair of nodes in ascending order of their
> >> > lengths. An example website for information on this is
> >> > http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.
> >> >
> >> > But, if you are looking for algorithms for K-disjoint paths, these can
> >> > be found in my book: "Survivable Networks: Algorithms for Diverse
> >> > Routing", Kluwer Academic Publishers (1999).
> >> >
> >> > Regards,
> >> >
> >> > Ramesh
> >> >
> >> > Chrysostomos Tziouvaras wrote:
> >> > >
> >> > > Hi,
> >> > > I am searching for an algorithm for calculating all paths
> >> > between an s-d
> >> > > pair. Can you provide me pointers to books or URLs?
> >> > >
> >> > > Thanks
> >> > > Chrysostomos
> >> >
> >> > _______________________________________________
> >> > IP-Optical mailing list
> >> > IP-Optical@lists.bell-labs.com
> >> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> -------
> >The MPLS-OPS Mailing List
> >Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


From owner-mpls@UU.NET  Thu Aug 16 17:13:28 2001
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 RAA23044
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 17:13:28 -0400 (EDT)
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 QQlcjk06271;
	Thu, 16 Aug 2001 21:14:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjk05137
	for mpls-outgoing; Thu, 16 Aug 2001 21:14:05 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 QQlcjk05106
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 21:13:51 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 QQlcjk18855
	for <mpls@UU.NET>; Thu, 16 Aug 2001 21:11:27 GMT
Received: from hebe.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jffdns02.or.intel.com [134.134.248.4])
	id QQlcjk04409
	for <mpls@UU.NET>; Thu, 16 Aug 2001 21:11:26 GMT
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA09267
	for <mpls@UU.NET>; Thu, 16 Aug 2001 21:11:25 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 16 Aug 2001 21:11:25 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <QYXVJ03C>; Thu, 16 Aug 2001 14:11:24 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA03E@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: mpls@UU.NET
Subject: RE: RSVP Refresh Reduction
Date: Thu, 16 Aug 2001 14:11:15 -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

As far as the receiver is concerned, the message ID is unique based on the
generator's IP address and the message ID. So, if these 3 point-to-point
interfaces have their own IP addresses, the message IDs are unique per
interface.

-Mark

> -----Original Message-----
> From: Jia Hong [mailto:jia_hong2000@yahoo.com]
> Sent: Wednesday, August 15, 2001 9:45 PM
> To: mpls@UU.NET
> Subject: RSVP Refresh Reduction
> 
> 
> Hi All,
>         I have a doubt related to message_id object in
> refresh reduction draft. If there are two nodes that
> are RSVP (and refresh reduction) capable. There are
> say 3 point-to-point interfaces between these nodes.
> The RSVP mailing list says once you get the SREFRESH
> message, first try to get the session to whom the
> message_id belongs. Should the message_ids be same
> across the different interfaces towards the same node
> ? I mean to say message_id pools be different for
> different interfaces toward the same neighbor or these
> interfaces use the same message_id pool for allocation
> of message_ids towards one neighbor/node ? Should
> neighbor be considered as one interface or physical
> node itself irrespective of # of interfaces between
> two adjacent nodes ?
> If these pools are interface based, then multiple
> sessions use the same pool that fall under the same
> interface ?
> 
> Thanks in advance,
> Jia.
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> 



From owner-mpls@UU.NET  Thu Aug 16 18:36:29 2001
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 SAA26816
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 18:36:29 -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 QQlcjq00384;
	Thu, 16 Aug 2001 22:37:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcjq01902
	for mpls-outgoing; Thu, 16 Aug 2001 22:37: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 QQlcjq01892
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 16 Aug 2001 22:37:10 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 QQlcjp09327
	for <mpls@UU.NET>; Thu, 16 Aug 2001 22:17:47 GMT
Received: from hypnos.cps.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hypnos.cps.intel.com [192.198.165.17])
	id QQlcjp14188
	for <mpls@UU.NET>; Thu, 16 Aug 2001 22:17:46 GMT
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA19288
	for <mpls@UU.NET>; Thu, 16 Aug 2001 22:17:45 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 16 Aug 2001 22:17:45 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <QXG98XXR>; Thu, 16 Aug 2001 15:17:44 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA040@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "Feng, Mark" <m_feng@trillium.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RRO Processing
Date: Thu, 16 Aug 2001 15:17:38 -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

Please see comments below. 

-Mark

> -----Original Message-----
> From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> Sent: Wednesday, August 15, 2001 9:29 PM
> To: 'Feng, Mark'
> Cc: 'mpls@UU.NET'
> Subject: RE: RRO Processing
> 
> 
> Hi Feng ,
>      One Resv message may contain multiple filter descriptors ,
> and each filter descriptor may contain RRO . By "new" I meant
> should we drop the RRO for the filter descriptor newly added  
> in the Resv
> Message , for a new sender .

It is more logical to drop the "newly" added sender's RRO.

>      There is another possibility that initially for the PSB 
> state and the
> corresponding RSB  state does not contain RRO object and
> down the line Path messages starts including the RRO object, now the
> corresponding Resv messages for this sender  also starts 
> including the RRO
> object at the egress , in such a scenario 
> at any LSR if one gets MTU exceed error, the RRO for which 
> sender should be
> removed ( Resv message contains multiple filter descriptor )

In the ResvErr, the sender should be specified. In the transit node, I don't
believe any action is taken, i.e. the transit node is not going to drop any
RRO, as long as that particular node can fit the RRO in the message.

BTW, I know the error code is "RRO too large for MTU". But I believe the
limit of RSVP message is the IP packet size.

> Regards ,
> Manoj
> 
>      
> 
> > ----------
> > From: 	Feng, Mark[SMTP:m_feng@trillium.com]
> > Sent: 	Thursday, August 16, 2001 2:46 AM
> > To: 	'mpls@UU.NET'
> > Subject: 	RE: RRO Processing
> > 
> > In the Path message, there should be only one RRO. So, if 
> it is too big,
> > the
> > RRO is removed.
> > 
> > In Resv message, IMO, it should be consistent with Path, 
> i.e. the RRO
> > should
> > be dropped per sender.
> > 
> > I am not sure what you mean by "new". The RRO procedure 
> initiates either
> > by
> > the ingress or the egress.
> > 
> > -Mark
> > 
> > > -----Original Message-----
> > > From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> > > Sent: Monday, August 13, 2001 9:28 PM
> > > To: 'mpls@UU.NET'
> > > Subject: RRO Processing
> > > 
> > > 
> > > Hi ,
> > >       In case of RRO processing ,
> > > 
> > > "If the newly added subobject causes the RRO to be too big to fit 
> > > in a  Path (or Resv) message, the RRO object SHALL be dropped 
> > > from the  message and message processing continues as normal"
> > > 
> > >  In this particular case will the RRO object will be dropped 
> > > for all the
> > > Filter Descriptors  , or for the one which is new .
> > > 
> > > How the case should be handled in case if RRO was not there 
> > > and subsequent
> > > adding the RRO object starts giving this error .
> > > 
> > > Regards ,
> > > Manoj
> > > 
> > > 
> > >  
> > 
> 



From owner-mpls@UU.NET  Thu Aug 16 21:08:14 2001
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 VAA28492
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 21:08:14 -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 QQlcka03885;
	Fri, 17 Aug 2001 01:09:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcka09735
	for mpls-outgoing; Fri, 17 Aug 2001 01:09: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 QQlcka09679
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 01:08:55 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 QQlcka10147
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:07:09 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcka15984
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:07:09 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA16535 for mpls@uu.net; Thu, 16 Aug 2001 21:07:08 -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 QQlcka04456
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 01:06:49 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 QQlcjz00085
	for <mpls@uu.net>; Fri, 17 Aug 2001 00:59:41 GMT
From: vt2X29xZ7@homeofficedigest.com
Received: from ikumail.iku.edu.tr by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [194.27.151.4])
	id QQlcjz29182
	for <mpls@uu.net>; Fri, 17 Aug 2001 00:59:39 GMT
Received: from K6eHROIb1 (portup708.portup.com [207.75.50.199]) by ikumail.iku.edu.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q95B21KJ; Fri, 17 Aug 2001 03:57:39 +0300
DATE: 16 Aug 01 9:04:50 PM
Message-ID: <W0dzFffbhoH>
TO: .@cisco.com, .@cisco.com
SUBJECT: Are You In Need Of A Lifestyle Change...
Sender: owner-mpls@UU.NET
Precedence: bulk


You were recently referred to me as someone who was
ready for a CHANGE, a financial breakthrough, so I'll
get right to the point.


I am the one that can help you make $125,000 plus this
Year from HOME with your computer and phone. 
This is Not MLM and it IS very REAL.


Are you Serious about making $2000 plus per week 
starting Right Away with a SIMPLE system 
where customers are contacting you and 
you do absolutely ZERO selling?


Can you follow simple step-by-step instructions and put
forth the effort to make this a reality for yourself starting
today? If your answer is YES, then we need to talk.


I have few positions available on my team and it's in my best
interest to train you for success.  In fact, I'm so sure that
I can do so, I'm willing to put my money where my mouth is!
Upon accepting you as a member on my team, I will provide 
you with complete Professional Training and Advertising  
Assistance to put you immediately on the road to success.


No experience necessary.... However you must have 
two qualities: moderate people skills and a serious desire 
for a personal and financial change.


Take a moment to take the next step by calling me at my 
Home Office and I will get you the details.


1-800-995-0796 Ext 4094
24 Hrs/ 7 Days


Prosperous Regards!
Dee Dee


"Profits are better than wages. Wages make you a living;
Profits make you a fortune"
                        - Jim Rohn


To be removed from our email list click here, you will automatically be removed <"mailto:clean2100@excite.com">hitting  reply will not remove you from our list







From owner-mpls@UU.NET  Thu Aug 16 21:32:47 2001
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 VAA28723
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 21:32: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 QQlckc10636;
	Fri, 17 Aug 2001 01:33:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckc12717
	for mpls-outgoing; Fri, 17 Aug 2001 01:33:35 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 QQlckc12706
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 01:33:25 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 QQlckb19488
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:29:47 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckb20387
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:29:46 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA18230 for mpls@uu.net; Thu, 16 Aug 2001 21:29:45 -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 QQlckb12350
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 01:29:19 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 QQlckb17372
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:23:02 GMT
Received: from jsmail.jsmedia.com.tw by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.168.194.51])
	id QQlckb07195
	for <mpls@uu.net>; Fri, 17 Aug 2001 01:23:01 GMT
Message-Id: <QQlckb07195.200108170123@cmr0.ash.ops.us.uu.net>
Received: from plain (63.232.132.54 [63.232.132.54]) by jsmail.jsmedia.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id P0Q9QRT6; Fri, 17 Aug 2001 09:22:05 +0800
From: mplsrich@hotmail.com
Reply-To: afriwood@yahoo.com
To: mplsrich@hotmail.com
Subject: African Alternative to Viagra - It Works! Time:8:29:22 PM
Date: Thu, 16 Aug 2001 20:29:22
Mime-Version: 1.0
Content-Type: text/plain; charset="DEFAULT_CHARSET"
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

Dear  mpress66,
Greetings!

AFRICAN ALTERNATIVE TO VIAGRA THAT WORKS!!!!

http://www.1xin.net/ch10/altwood/default.htm

This letter is not "spam".  Please click the "remove" link, below, to be removed from any future mailings.

AFRICANWOOD - The All-Natural Alternative to the "wonderdrug" for Erectile Dysfunction.
Also a great sexual stimulant that will liven up your sex life whether you are male or female!!

It really works!

ONLY 19.95 for 3 Nuts!  This means you can have up to SIX USES (average)
for less than you pay for TWO uses of the usual "treatment".  Note Africanwood is an
all-natural nut---straight from an African tree----and therefore not regulated by the FDA.
You use the product how you see fit!

Africanwood is not a potion---it is not processed.  It is simply the nut of an ancient african tree,
and best of all, IT WORKS!  Unbeknownst to most, Africans have been using the nut for its
stimulating properties for thousands of years!  Prolongs erections, increases sensitivity,
enhances sexual pleasures.

The scientific name for this particular variety of nut is "C. acuminata," and this variety is only
available in a very small area in a West African country.

FOR MORE INFORMATION CLICK HERE:

http://www.1xin.net/ch10/altwood/default.htm

Traditional uses include:
 - impotency
 - stimulating a weak heart
 - treating nervous debility
 - weakness
 - lack of emotion
 - nervous diarrhea
 - depression
 - despondency
 - brooding
 - anxiety sickness

There are many potions, powders and pills available that are "natural," but what most
people don't realize is that most natural remedies work best ONLY in their natural state.

The key constituents of the AfricanWood nut are theobromine, tannins and phenolics,
inlcuding d-catechin, I-epicatechin, kolatin, and kolanin.  All of these substances are
completely natural and work ONLY when the nut is fresh!

Order your nuts today, and see why the African culture has held this nut in such high
regard for so many centuries!

CLICK HERE to ORDER ONLINE!

http://www.1xin.net/ch10/altwood/default.htm

-or-

USE THIS FORM and send CHECK OR MONEY ORDER!



Name:______________________________________


Address:____________________________________


City:________________________________________


State (US or Canada)___________________________


Postal:_______________________________________


Country______________________________________


______3 Nuts for $19.95                                   Amount_________

______6 Nuts for $34.95                                   Amount_________


______10 Nuts for $44.95 (best value)             Amount_________


Shipping (3.50 domestic, $12.00 International             __________


TOTAL ORDER                                          ___________________



CHECK NUMBER___________

or

Credit Card Number______________________________  Exp   _____/_______  (mo/year)

NOTE WE DO NOT ACCEPT AMERICAN EXPRESS



Signature________________________________________


Name    _______________________________________(print)


Date   ___________________________________________



PLEASE ALLOW 2-3 WEEKS FOR DOMESTIC SHIPMENT, 4-6 WEEKS INTERNATIONAL!


SEND FORM and MAKE CHECK/MONEY ORDER to:

***click below to get more information and the mailing address:***

http://www.1xin.net/ch10/altwood/default.htm




Thank you for your order!




Click here to be removed from this list!

http://www.1xin.net/ch10/altwood/woodcleanlist.html


NOTE:

This advertisement is NOT sponsored by any internet service provider.  This is an advertisement that is produced and sponsored by Stratosphere to reach potential customers from what we believe to be opt-in mailing lists.

At the time of this mailing, the return email address is a bonafide legitimate email address that was established for the express purpose of received all undeliverable emails.  On occassion the return email address provided may become disrupted by the efforts of what we call "internet terrorists".  If this is the case, and you wish to be removed, just click the link above and we will make sure you are removed form the list.

The message is being sent in compliance with pending email bills and laws:  Section 301.  Per section, paragraph (a)  (2) (c) of S. 1618.  This message is NOT intended for residents in the states of Washington, Nevada, California, or Virginia.  Screening of the addresses has been done to the best of our technical ability.  If you are a resident of one of these states, please remove yourself from the list via the "remove link".

Thank you!







From owner-mpls@UU.NET  Thu Aug 16 22:37:26 2001
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 WAA01234
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 22:37:26 -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 QQlckg20092;
	Fri, 17 Aug 2001 02:38:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckg07241
	for mpls-outgoing; Fri, 17 Aug 2001 02:38: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 QQlckg07231
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 02:37:58 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 QQlckg10776
	for <mpls@uu.net>; Fri, 17 Aug 2001 02:32:30 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckg10635
	for <mpls@uu.net>; Fri, 17 Aug 2001 02:32:29 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA21323 for mpls@uu.net; Thu, 16 Aug 2001 22:32:28 -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 QQlckg06717
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 02:32:13 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 QQlckf10675
	for <mpls@uu.net>; Fri, 17 Aug 2001 02:28:44 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe22.law11.hotmail.com [64.4.16.79])
	id QQlckf18439
	for <mpls@uu.net>; Fri, 17 Aug 2001 02:28:43 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 16 Aug 2001 19:28:43 -0700
X-Originating-IP: [63.22.117.175]
From: "Louis" <louis_mo@hotmail.com>
To: <mpls@UU.NET>
Date: Thu, 16 Aug 2001 23:40:39 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0017_01C126AC.DB11ECE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID: <OE225V6QcqnWwAeRaNg00006fa3@hotmail.com>
X-OriginalArrivalTime: 17 Aug 2001 02:28:43.0343 (UTC) FILETIME=[5586D5F0:01C126C4]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

subscribe

------=_NextPart_000_0017_01C126AC.DB11ECE0
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.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>subscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C126AC.DB11ECE0--



From owner-mpls@UU.NET  Thu Aug 16 23:54:37 2001
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 XAA02477
	for <mpls-archive@lists.ietf.org>; Thu, 16 Aug 2001 23:54:37 -0400 (EDT)
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 QQlckl25005;
	Fri, 17 Aug 2001 03:55:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckl02340
	for mpls-outgoing; Fri, 17 Aug 2001 03:55:26 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 QQlckl02330
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 03: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 QQlckl10700
	for <mpls@uu.net>; Fri, 17 Aug 2001 03:47:55 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckl13156
	for <mpls@uu.net>; Fri, 17 Aug 2001 03:47:54 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA24074 for mpls@uu.net; Thu, 16 Aug 2001 23:47:53 -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 QQlckl01813
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 03:47:31 GMT
Received: from tows021 by imr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: ippool138-218.corp.us.uu.net [153.39.138.218])
	id QQlckk04153;
	Fri, 17 Aug 2001 03:41:21 GMT
Message-Id: <3.0.5.32.20010816234221.00b4c2d0@npiserve0.corp.us.uu.net>
X-Sender: durga@npiserve0.corp.us.uu.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 16 Aug 2001 23:42:21 -0400
To: Ramesh Bhandari <bhandari1@lucent.com>
From: Durga Gangisetti <durga@UU.NET>
Subject: Re: Fwd: RE: [IP-Optical] Re: An algorithm for calculating
  allpaths  between an s-d pair
Cc: tziou@ics.forth.g, awduche@movaz.com, mpls@UU.NET,
        IP-Optical@lists.bell-labs.com, mpls-ops@mplsrc.com, ilazar@mplsrc.com
In-Reply-To: <3B7C36F1.3EFC0A4B@hotair.hobl.lucent.com>
References: <3.0.5.32.20010816153630.00b39100@npiserve0.corp.us.uu.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ramesh,

>Summary: KSP (not the naive algorithm, but the algorithm as given in my
>book) is optimal and computationally fast.

I agree with you.  

But I think in case of multicommodity flows where non-linear variables like
QoS
and dynamic routing (not fixed routing - i.e; pre-determined) by splitted
traffic
with identical characteristics come in effect, it is at that point :
'  KSP doesnot may always generate the optimal disjoint path set. Whereas MF 
   is kind of guaranted to produce the max no:of possible disjoint paths
and may
    not produce the actual path set. '
it may be valid. Ofcourse above lines are sensitive and arises
architectural and
engieering issues in building an optimal and minimum cost optical network and
differs based on context.


Regards,

Durga,
UUnet Technologies Inc,
A Worldcom Company.



From owner-mpls@UU.NET  Fri Aug 17 00:17:32 2001
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 AAA02784
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 00:17:31 -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 QQlckn16476;
	Fri, 17 Aug 2001 04:18:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckn23003
	for mpls-outgoing; Fri, 17 Aug 2001 04:18: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 QQlckn22989
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 04:18: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 QQlckm15525
	for <mpls@uu.net>; Fri, 17 Aug 2001 04:13:21 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckm22483
	for <mpls@uu.net>; Fri, 17 Aug 2001 04:13:21 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id AAA25274 for mpls@uu.net; Fri, 17 Aug 2001 00:13:20 -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 QQlckm22334
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 04:12:54 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 QQlckm12807;
	Fri, 17 Aug 2001 04:05:50 GMT
From: achandras@howareyoutoday.org
Received: from mailserver.booster.co.kr by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: booster.co.kr [211.54.118.33])
	id QQlckm09684;
	Fri, 17 Aug 2001 04:05:43 GMT
Received: from gw02_[192.168.227.26] ([209.210.90.77]) by mailserver.booster.co.kr with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 17 Aug 2001 13:03:59 +0900
Received: from mail4.howareyoutoday.org by gw02 with ESMTP; Thu, 16 Aug 2001 23:12:50 -0400
Message-ID: <00002feb4c84$00005bab$000005bb@mail4.howareyoutoday.org>
To: <achandras@howareyoutoday.org>
Subject: re: contest confirmation                         1467
Date: Thu, 16 Aug 2001 23:12:41 -0400
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: lekkicee@mailandnews.com
X-OriginalArrivalTime: 17 Aug 2001 04:04:00.0437 (UTC) FILETIME=[A52E2650:01C126D1]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

<html>
<body>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><b><font col=
or=3D"#CC66FF" face=3D"Verdana" size=3D"2">Congratulations!!!</font></b><f=
ont size=3D"2" face=3D"Verdana"><br>
<br>
You have been selected as a finalist in the Getaway Travel Sweepstakes!<br=
>
<br>
<font color=3D"#000080"><b>Grand Prize:</b></font><font color=3D"#009900">=
<br>
</font><br>
	4 days / 3 nights in Orlando&nbsp;<br>
	3 days / 2 nights in Daytona Beach&nbsp;<br>
	3 days / 2 nights in Key West&nbsp;<br>
	Rental Car&nbsp;<br>
	Casino Cruise&nbsp;<br>
<br>
<font color=3D"#CC66FF"><b>Attractions include:</b></font> MGM, Universal =
Studios, Sea World, Epcot, Disney World, Swimming Pools, Discos, Vegas-sty=
le shows, PGA Golf Courses, Snorkeling, Sunscreen, and Swimsuits!<br>
<br>
 All you have to do is complete the finalists' registration form</font></p=
>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><font size=3D=
"2" face=3D"Verdana">Your Confirmation Number is:
<font color=3D"#FF0000" size=3D"2" face=3D"Verdana"><b><a href=3D"http://h=
ot.howareyoutoday.org">GTS0726xflz</a>.</b></font><br>
<br>
Why wait? You could be on your way! <a href=3D"http://hot.howareyoutoday.o=
rg"><b> CLICK HERE</b></a>&nbsp;<br>
<br>
Timothy Bocelli<br>
International Travel Coordinator<br>
<br>
</font></p>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0">&nbsp;</p>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><font size=3D=
"2" face=3D"Verdana"><br>
<a href=3D"http://far.howareyoutoday.org">Click Here To Be Removed</a><br>
</font><br>
</p>

</body>

</html>





From owner-mpls@UU.NET  Fri Aug 17 01:59:08 2001
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 BAA11610
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 01:59:08 -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 QQlcku18871;
	Fri, 17 Aug 2001 06:00:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcku20112
	for mpls-outgoing; Fri, 17 Aug 2001 06:00:01 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 QQlckt20058
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 05:59:56 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 QQlckt22697
	for <mpls@uu.net>; Fri, 17 Aug 2001 05:55:42 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckt21812
	for <mpls@uu.net>; Fri, 17 Aug 2001 05:55:41 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA00099 for mpls@uu.net; Fri, 17 Aug 2001 01:55:40 -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 QQlckt19733
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 05:55:30 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 QQlckt00143
	for <mpls@uu.net>; Fri, 17 Aug 2001 05:54:26 GMT
Received: from server3.www.palpilot.com.tw by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [210.71.154.97])
	id QQlckt19853
	for <mpls@uu.net>; Fri, 17 Aug 2001 05:54:24 GMT
Message-Id: <QQlckt19853.200108170554@cmr0.ash.ops.us.uu.net>
Received: from html (WIN20435 [168.143.160.134]) by server3.www.palpilot.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id 34HZL85K; Fri, 17 Aug 2001 13:48:22 +0800
From: MoneyMaking@mailexcite.com
To: quepraiser@yahoo.com
Subject:  THE INVESTOR REPORT DAILY FOR MONDAY
Date: Fri, 17 Aug 2001 01:44:41
Mime-Version: 1.0
Content-Type: text/html; charset="DEFAULT_CHARSET"
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

<HTML>
<HEAD>
<STYLE TYPE="text/css">
<!--
A:link {color:"#0000FF";}
A:visited {color:"#0000FF";}
A:hover {color:"red";}
-->
<!--        
A{text-decoration:none} 
-->
</STYLE>
</HEAD>
<BODY>
<FONT face="verdana, times new roman, MS Sans Serif"><FONT size="3">
<b>**FOR IMMEDIATE RELEASE**
<br>

<p><A href="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
Cal-Bay International (Stock Symbol: CBYI)</A></b></FONT>
<FONT size="2">
<p>
Watch for analyst "Strong Buy Recommendations" and several advisory Newsletters picking CBYI.
<br>CBYI has HUGE growth potential and has recently filed to be listed on NASDAQ.
<br>CBYI is undervalued in comparison to other companies and is poised for explosive growth.
<br>Acquire a position TODAY because share prices historically increase when companies get listed on NASDAQ.  
<br><b><A href="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
Click HERE for a QUOTE & NEWS!</A></b>
<p>
<b>REASONS TO OWN THE STOCK!</b>
<li>CBYI is one of the FASTEST growing companies in distributing environmental and safety equipment instruments.
<li>CBYI is profitable, has NO DEBT and is on track to beat ALL earnings estimates.
<li>CBYI has increased revenue of 50% annually!
<li>CBYI is a fully reporting SEC compliant company that has been in business since 1976.
<li>CBYI has an excellent management team with several EXCLUSIVE contracts and an IMPRESSIVE client list including:
Anheuser-Busch, Chevron Refining, Mitsubishi Heavy Industries, GE-Energy & Environmental Research and the U.S. Air Force.
<li>CBYI stock is currently trading around $1.00 a share
and should INCREASE to $4.00 - $5.00 a share in the near future.
<br><b><A href="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
Click HERE for a QUOTE & NEWS!</A></b>
<p>
<b>RAPIDLY GROWING INDUSTRY.</b>
<br>
Hold on tight for the largest Oil and Natural Gas expansion in U.S. History.  Demand for Energy is at its highest level putting tremendous
pressure on Scientific & Technical Instrumentation companies like CBYI.  There is rapid expansion in the energy industry with the
need for more power plants and cheaper fuel.  CBYI is a major benefactor of the growing need because it supplies specialized
"Smell Technology" analyzers for industrial applications in Natural Gas production and transmission.  The current industry revenues
exceeds $900,000,000 and should reach a triple digit growth rate for the next five or more years.  Estimates today indicate that
there could be as much as $25 billion in revenues from "smell technology" by the end of 2003.    
<p>
Our last 2 recommendations, STEM & NCCL are up over 300% from the price we recommended in our June (STEM) & July (NCCL) Newsletters!
<br>Acquire a position in CBYI TODAY!
<b><A href="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
Click HERE for a QUOTE & NEWS!</A></b>
<p>
AOL users or If this message in plain text simply cut and paste the below link in your browser window and hit Go.<br>
<b><a href="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi</a></b>
<p>
<i>Note: This symbol is not available on every Financial News Network or Website.
This will be corrected with its latest 10-SB filing.</i>
<p>
<br>
<FONT size="3"><b>FREE INVESTMENT ADVICE!</b></FONT>
<br>  
International Investment Experts & Research Analysts with 30+ years experience 
featured on CNN, 20/20, Wall Street Journal, Forbes, Fortune and many others OFFER YOU 
a FREE Investment Newsletter.  "The Alert Investor" is perfect for the New, Experienced and Long Term Investors.  
<li>Get expert Tips, SPECIAL UPDATES on undervalued companies & IPO's ready to explode.
<li>Profiled companies are up 147% since January 2001!
<li>Your first 6 month trial is absolutely FREE!  (A $219 Value)
<li>Over 635,000 have joined, get an inside track on Wall Street TODAY!
<p>
<b>For a FREE research report on CBYI or to Subscribe, fill out the following:</b>
<p>
<b>* = Required</b> (Email Address is the ONLY REQUIRED information)</b>
<!--start form-->	

	<form action="http://www.101020.com/cgi-bin/sitecounter.pl" method="POST">
    <input type="hidden" name="recipient" value="arial25253D@YAHOO.COM">
	<input type="hidden" name="required" value="email,email_verify">
	<input type="hidden" name="subject" value="Subscribe">
	<input type="hidden" name="redirect" value="http://host.wallstreetcity.com/wsc2/Corporate_Snapshot.html?DB=SQL&template=corpsnap.htm&Symbol=cbyi">
	<input type="hidden" name="title" value="Subscribe">
	<input type="hidden" name="env_report" value="REMOTE_ADDR">
	
	<CENTER>
	<TABLE BORDER="0">
	
	<TR>
	  <TD ALIGN="right"><FONT FACE="verdana, arial, times new roman" SIZE="2">First Name: </FONT></TD>
	  <TD><INPUT NAME="first_name" size="15"></TD>
	  	</TR>
	<TR>
	  <TD ALIGN="right"><FONT FACE="verdana, arial, times new roman" SIZE="2">Last Name: </FONT></TD>
	  <TD><INPUT NAME="last_name" size="15"></TD>
	  	</TR>
	<TR>
	  <TD ALIGN="right"><FONT FACE="verdana, arial, times new roman" SIZE="2">Email: *</FONT></TD>
	  <TD><INPUT NAME="email" SIZE="35"></TD>
	</TR>
	<TR>
	  <TD ALIGN="right"><FONT FACE="verdana, arial, times new roman" SIZE="2">Re-Type Email: *</FONT></TD>
	  <TD><INPUT NAME="email_verify" SIZE="35"></TD>
	</TR>
	<TR><TD ALIGN="RIGHT"><FONT FACE="verdana, arial, times new roman" SIZE="2">Home Phone: </FONT></TD>
		<TD><INPUT NAME="home_phone" SIZE="15"></TD>
	</TR>
	<TR>
		<TD ALIGN="RIGHT"><FONT FACE="verdana, arial, times new roman" SIZE="2">Work Phone: </FONT></TD>
		<TD><INPUT NAME="work_phone" SIZE="15"></TD>
	</TR>
    <TR><TD ALIGN="right"><FONT FACE="verdana, arial, times new roman" SIZE="2">Best Time To Call: </FONT></TD>
		<TD><INPUT NAME="best_time_to_call" size="20"></TD>
	</TR>
	<TR>
		<TD VALIGN="TOP" ALIGN="RIGHT"><FONT FACE="verdana, arial, times new roman" SIZE="2">Annual Income: </FONT></TD>
		<TD><SELECT NAME="annual_income" size="1">
		<option selected value="none">Select Your Income</option>
		<option value="less_than_50k">Less Than $50,000</option>
        <option value="50k_to_100k">$50,000 - $100,000</option>
        <option value="100k_to_250k">$100,000 - $250,000</option>
        <option value="over_250k">Over $250,000</option> 
		</SELECT></TD>
	</TR>
	<TR>
        <TD ALIGN="RIGHT"><FONT FACE="verdana, arial, times new roman" SIZE="2">Estimated Liquid Net Worth: <br>(cash, stocks, bonds, bank accounts)</FONT></TD>
        <TD><SELECT NAME="liquid_net_worth" size="1">
		<option selected value="none">Select Your Net Worth</option>
		<option value="less_than_50k">Less Than $50,000</option>
        <option value="50k_to_100k">$50,000 - $100,000</option>
        <option value="100k_to_250k">$100,000 - $250,000</option>
		<option value="250k_to_500k">$250,000 - $500,000</option>
        <option value="500k_to_1million">$500,000 - $1,000,000</option>
        <option value="over_1million">Over $1,000,000</option> 
		</SELECT></TD>
		</TR>
      	</TABLE>
	</CENTER>
	<CENTER>
	  <P><INPUT TYPE="submit" NAME="Submit"></P>
	</CENTER>
	</FORM>
	
<!--end form-->
<p>
<br><br>
<b><a href="mailto:no_thanksus@yahoo.com">Click HERE to be PERMANENTLY REMOVED!</a></b>
<BR>NOTE: ALL IP address are logged.
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>

Certain statements contained in this news release may be forward-looking statements 
within the meaning of The Private Securities Litigation Reform Act of 1995. 
These statements may be identified by such terms as "expect", "believe", 
"may", "will", and "intend" or similar terms. We are NOT a registered 
investment advisor or a broker dealer. This is NOT an offer to buy or sell 
securities. No recommendation that the securities of the companies profiled 
should be purchased, sold or held by individuals or entities that learn of the 
profiled companies. This is an independent electronic publication that was 
paid $5,000 in cash by a third party for the 
electronic dissemination of this company information. Be advised that investments 
in companies profiled are considered to be high-risk and use of the information 
provided is for reading purposes only. If anyone decides to act as an investor 
they are advised not to invest without the proper advisement from an attorney or 
a registered financial broker, if any party decides to participate as an 
investor then it will be that investor's sole risk. Be advised that the purchase 
of such high-risk securities may result in the loss of some or all of the 
investment. The companies that are profiled provide all information and make no representations.  
The profiled companies make no warranties or guarantees as to the accuracy or the 
completeness of the disclosure.  Investors should not rely solely on 
the information presented. Rather, investors should use the information provided 
by the profiled companies as a starting point for doing additional independent 
research on the profiled companies in order to allow the investor to form his 
or her own opinion regarding investing in the profiled companies. Factual 
statements made by the profiled companies are made as of the date stated and are 
subject to change without notice. The receipt of this information shall not 
create, under any circumstances, any implication that there has been no change 
in the affairs of the company profiled since the date of review. Investing in 
micro-cap securities is highly speculative and carries an extremely high degree 
of risk. It is possible that an investor's entire investment may be lost or 
impaired due to the speculative nature of the companies profiled. 
All information provided by the profiled companies may include 
information provided by outside sources, such as research reports, public 
filings or computer databases and information provided by management of the 
profiled company. 
</FONT>
</BODY></HTML>



From owner-mpls@UU.NET  Fri Aug 17 02:17:39 2001
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 CAA20170
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 02:17:39 -0400 (EDT)
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 QQlckv28293;
	Fri, 17 Aug 2001 06:18:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckv10419
	for mpls-outgoing; Fri, 17 Aug 2001 06:18:31 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 QQlckv10409
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 06:18:22 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 QQlckv27033
	for <mpls@uu.net>; Fri, 17 Aug 2001 06:15:42 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlckv23213
	for <mpls@uu.net>; Fri, 17 Aug 2001 06:15:41 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA01148 for mpls@uu.net; Fri, 17 Aug 2001 02:15:40 -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 QQlckv10129
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 06:15:20 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 QQlcku29398;
	Fri, 17 Aug 2001 06:14:11 GMT
From: estokes197@howareyoutoday.org
Received: from mail.expertsystem.co.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.expertsystem.co.jp [210.145.41.147])
	id QQlcku20403;
	Fri, 17 Aug 2001 06:13:53 GMT
Received: from [209.210.90.21] by mail.expertsystem.co.jp
          (Post.Office MTA v3.5.3J release 223-101-J
          ID# 1001-71310U100L100S0V35J) with SMTP id jp;
          Tue, 14 Aug 2001 01:08:56 +0900
Received: from mail3.howareyoutoday.org by gw05 with ESMTP; Mon, 13 Aug 2001 11:09:14 -0400
Message-ID: <0000472412a5$000057a1$00007189@mail3.howareyoutoday.org>
To: <estokes197@howareyoutoday.org>
Subject: Re: sweepstakes confirmation                         29065
Date: Mon, 13 Aug 2001 11:09:07 -0400
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: lloovvee@mailandnews.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

<html>
<body>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><b><font col=
or=3D"#CC66FF" face=3D"Verdana" size=3D"2">Congratulations!!!</font></b><f=
ont size=3D"2" face=3D"Verdana"><br>
<br>
You have been selected as a finalist in the Getaway Travel Sweepstakes!<br=
>
<br>
<font color=3D"#000080"><b>Grand Prize:</b></font><font color=3D"#009900">=
<br>
</font><br>
	4 days / 3 nights in Orlando&nbsp;<br>
	3 days / 2 nights in Daytona Beach&nbsp;<br>
	3 days / 2 nights in Key West&nbsp;<br>
	Rental Car&nbsp;<br>
	Casino Cruise&nbsp;<br>
<br>
<font color=3D"#CC66FF"><b>Attractions include:</b></font> MGM, Universal =
Studios, Sea World, Epcot, Disney World, Swimming Pools, Discos, Vegas-sty=
le shows, PGA Golf Courses, Snorkeling, Sunscreen, and Swimsuits!<br>
<br>
 All you have to do is complete the finalists' registration form</font></p=
>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><font size=3D=
"2" face=3D"Verdana">Your Confirmation Number is:
<font color=3D"#FF0000" size=3D"2" face=3D"Verdana"><b><a href=3D"http://h=
ot.howareyoutoday.org">GTS0726xflz</a>.</b></font><br>
<br>
Why wait? You could be on your way! <a href=3D"http://hot.howareyoutoday.o=
rg"><b> CLICK HERE</b></a>&nbsp;<br>
<br>
Timothy Bocelli<br>
International Travel Coordinator<br>
<br>
</font></p>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0">&nbsp;</p>
<p style=3D"word-spacing: 0; margin-top: 0; margin-bottom: 0"><font size=3D=
"2" face=3D"Verdana"><br>
<a href=3D"http://far.howareyoutoday.org">Click Here To Be Removed</a><br>
</font><br>
</p>

</body>

</html>





From owner-mpls@UU.NET  Fri Aug 17 03:28:32 2001
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 DAA20965
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 03:28:32 -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 QQlckz21686;
	Fri, 17 Aug 2001 07:29:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlckz05153
	for mpls-outgoing; Fri, 17 Aug 2001 07:29: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 QQlckz05148
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 07:29: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 QQlckz12483
	for <mpls@uu.net>; Fri, 17 Aug 2001 07:27:54 GMT
Received: from exchange1.exbit.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: test.exbit.com [213.129.28.92])
	id QQlckz15231
	for <mpls@uu.net>; Fri, 17 Aug 2001 07:27:53 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: MPLS list moderator needed?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 17 Aug 2001 09:27:52 +0200
Message-ID: <3480386340F255438495A675F692EA38079F2D@exchange1.exbit.com>
Thread-Topic: MPLS list moderator needed?
Thread-Index: AcEm7iA5z4heQ6SBRoiEN/m22eW4lg==
From: "Morten J. Christensen" <mjc@exbit.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 DAA20965

Hi All and especially mpls list maintainer

I receive a lot of spam mail from this and other IETF mailing lists
and I suspect a lot of you guys do too.

Is there anyway this list could be moderated so that the spam
could be removed before reaching thousands of recipients?

cheers

Morten



From owner-mpls@UU.NET  Fri Aug 17 07:20:46 2001
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 HAA23899
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 07:20:46 -0400 (EDT)
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 QQlclp26790;
	Fri, 17 Aug 2001 11:21:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlclp07541
	for mpls-outgoing; Fri, 17 Aug 2001 11:21: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 QQlclp07536
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 11:21:32 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 QQlclo11829
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:12:14 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlclo07749
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:12:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA11796 for mpls@uu.net; Fri, 17 Aug 2001 07:12:04 -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 QQlclo06709
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 11:11:46 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 QQlclo04348
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:03: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 QQlclo04992
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:03: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 HAA23263;
	Fri, 17 Aug 2001 07:02:45 -0400 (EDT)
Message-Id: <200108171102.HAA23263@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: forces@peach.ease.lsoft.com, mpls@UU.NET, ip-optical@lists.bell-labs.com,
        ccamp@ops.ietf.org, iporpr@external.cisco.com, gsmp@revnetworks.com,
        ppvpn@zephion.net, te-wg@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-amenyo-consion-sigint-optnet-00.txt
Date: Fri, 17 Aug 2001 07:02:36 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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


	Title		: ConSION: Control & Signaling Intelligence Overlay 
                          Ntworks for Optical Networking
	Author(s)	: J. Amenyo
	Filename	: draft-amenyo-consion-sigint-optnet-00.txt
	Pages		: 15
	Date		: 16-Aug-01
	
When one extrapolates from the ongoing evolutionary trends of IP 
router / switch development and its role in the build-out of optical 
core, edge, access and enterprise networks, it is reasonable to 
reach the almost inescapable conclusion that within a few years, 
there will be a complete physical separation of the commercial 
equipment embodying various concerns, aspects, roles and functions 
of data communications, Namely, 
1. Separate equipment for transport (transmission, switching and 
multiplexing) and traffic forwarding. 
2. Separate equipment concerned with control, signaling, traffic 
engineering, provisioning, protection and restoration control, as 
well as, traffic and flow management, (generalized 'softswitches'). 
3. Separate equipment for network management, operations support, 
measurement & metering, OAMP, inter-OSS, engineering management 
(including performance management, availability management, security 
management, accounting management), as well as life cycle support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-amenyo-consion-sigint-optnet-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-amenyo-consion-sigint-optnet-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-amenyo-consion-sigint-optnet-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:	<20010816080136.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-amenyo-consion-sigint-optnet-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-amenyo-consion-sigint-optnet-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug 17 08:33:58 2001
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 IAA27011
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 08:33: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 QQlclu01167;
	Fri, 17 Aug 2001 12:35:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlclu00775
	for mpls-outgoing; Fri, 17 Aug 2001 12:34:28 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 QQlclu00756
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 12:34:18 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 QQlclt06240
	for <mpls@uu.net>; Fri, 17 Aug 2001 12:23:02 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlclt03420
	for <mpls@uu.net>; Fri, 17 Aug 2001 12:23:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA15287 for mpls@uu.net; Fri, 17 Aug 2001 08:23:00 -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 QQlclt00014
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 12:22: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 QQlcls24105
	for <mpls@uu.net>; Fri, 17 Aug 2001 12:04:05 GMT
From: henere4kk@cityline.ru
Received: from wigo.wigo-df.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.wigo-df.com [202.155.72.187])
	id QQlcls04790
	for <mpls@uu.net>; Fri, 17 Aug 2001 12:04:03 GMT
Received: by WIGO with Internet Mail Service (5.5.1960.3)
	id <QTXZ63X1>; Fri, 17 Aug 2001 19:36:56 +0700
Received: from mcpeely.concentric.net (user178.lwpw-02.cwia.com [209.209.74.178]) by wigo.wigo-df.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id QTXZ63XD; Fri, 17 Aug 2001 19:36:47 +0700
To: blissford5@glasnet.ru
Message-ID: <000002574e2e$000039e9$00006d5d@mindspring (user-3qt5hn.dialup.mindspring.com [99.174.150.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id OAA06398  from 110140321worldnet.att.net ([102.70.21.32]) by mtiwmhc98.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <20090116195452.ZOMX28505@110940321worldnet.att.net>>
Subject: Affordable computing for everyone is here
Date: Fri, 17 Aug 2001 04:02:31 -0700
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Mozilla 4.72 [en] (Win98; U)
Sender: owner-mpls@UU.NET
Precedence: bulk

Sign up for a special Internet access offer 
and we'll give you a brand new PC!

No, it's not too good to be true - it is true.
The volume power of the Internet makes it possible.

In Touch, LLC brings together two of the biggest names 
in Internet computing to provide an unprecedented offer:

****************************************************
Call 1-800-274-7150 (M-F 9:30am - 10:30pm, Sat 10-4PM EST)
[Promotion Code: I424]
*****************************************************

This is a "real" computer from the No. 1 PC manufacturer
worldwide with everything you need to surf the Net, 
exchange email, create documents and presentations, 
play games and much more.

A brand new Intel(r) 800MHz computer comes loaded with:

* 64MB SDRAM (upgradable)
* 10GB Ultra ATA Hard Drive (upgradable)
* 15" High resolution monitor (upgradable)
* Intel 3D graphics
* 48X CD-ROM drive (upgradable)
* V.90 56K fax / modem
* 3.5" 1.44MB diskette drive
* QuietKey keyboard
* Logitech mouse
* 1 parallel, 1 serial port
* 2 USB ports
* Speakers
* Microsoft Windows(tm) Millennium Edition
* Microsoft Internet Explorer(tm)
* Microsoft Works Suite 2001(tm) with Money 2001
* Norton Anti-Virus 2000(tm)

(There's also special pricing on other popular upgrade
options available in conjunction with this offer)

******************************************************
Call 1-800-274-7150 (M-F 9:30am - 10:30pm, Sat 10-4PM EST)
[Promotion Code: I424]
******************************************************

Your new PC is backed by award winning 24 hour customer
support and 3 year warranty - including one full year 
of on-site / in-house service

All you need to do to get your new computer is to sign 
up for the Edge Benefits Internet access program that
includes 36 months of unlimited Internet access by a 
major international, Internet Service Provider and you 
will get a host of other extras including:

* Unlimited access 
* Over 7500 dial-up access numbers 
* 24 / 7  tech support 
* 8 personal email accounts 
* WebMail - check email with a Web browser 
* Instant Messaging - chat with friends on-line 
* Personal Start Page
* Free Web browsers 
* Free bLink magazine subscription 
* Free email newsletter 
* Free bonus software 

Yes it's true and it's absolutely guaranteed!

******************************************************
Call 1-800-274-7150 (M-F 9:30am - 10:30pm, Sat 10-4PM EST)
[Promotion Code: I424]
******************************************************

This email was sent to you by PW Marketing, LLC, 
an independent Internet Marketing company. If someone 
has placed you on our mailing list in error, you can 
be expunged from the list by sending an email to 
(mailto:paul6213@excite.com?subject=delete-me)



From owner-mpls@UU.NET  Fri Aug 17 09:59:48 2001
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 JAA02252
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 09:59:48 -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 QQlcma27832;
	Fri, 17 Aug 2001 14:00:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcma28864
	for mpls-outgoing; Fri, 17 Aug 2001 14:00:43 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 QQlcma28511
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:00:39 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 QQlclz19132
	for <mpls@UU.NET>; Fri, 17 Aug 2001 13:54:07 GMT
Received: from huaweimail.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlclz15619
	for <mpls@UU.NET>; Fri, 17 Aug 2001 13:54:04 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <Q3W0WS65>; Fri, 17 Aug 2001 19:27:11 +0500
Message-ID: <751B6DD7A243D511AB9F0002557C5687B55B98@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: RE: Traffic Engineering TLV
Date: Fri, 17 Aug 2001 19:27:08 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12728.B220BE70"
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_01C12728.B220BE70
Content-Type: text/plain;
	charset="iso-8859-1"


Dear Naidu

 I couldn't find the draft-kompella-tewg-bw-acct-00.txt draft can you please
 tell me where can i get this draft ?

Thanks & regds
Ashwin


-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Thursday, August 16, 2001 7:12 PM
To: 'Ashwin C. Prabhu'; Naidu, Venkata; mpls@UU.NET; mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV


Ashwin:

   Please look at my inline comments...

-> The priority/preemption is a task of MPLS Management 
-> module. I would like to know why the 8 priority levels 
-> are provided in the OSPF Extension? 

   OSPF (for that matter any IGP) job is to flood the TE
   information throughout the area (at present) for TE
   purpose. The 8 priority levels for unreserved bw is 
   nothing to do with OSPF calculations. Just flood the info!

-> What i was thinking is this 8 priority levels is used by 
-> the CSPF for the computation of the routes. If so, why 
-> is it Unreservable Bandwidth for the 8 priority levels ? 

   Yes! After flooding the TE information, ingress LERs do 
   CSPF to prune links (which are not met the requested 
   bw, priority, preemption etc) to find the best path to egress.

-> does it mean that on a link we configure the Bandwidth 
-> for different priority levels ? 
->        (Like Priority 0 -> 30 % bandwidth etc ) 
->        Or this is ment for some other purpose ? 

   It is not that simple, please look at Kompella's paper
   draft-kompella-tewg-bw-acct-00.txt (and nested references)

->        As i found the draft draft-katz-yeung-ospf-traffic-04 
-> not mentioning it clearly. 

   As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do
   with configuration of priority levels. 

--Venkata Naidu


-> -----Original Message----- 
-> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] 
-> Sent: Tuesday, August 14, 2001 7:37 PM 
-> To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com 
-> Subject: FW: Traffic Engineering TLV 
-> 
-> 
-> Prabhu: 
-> ->             Can anyone please tell me what are these 8 
-> -> priority levels and what for these 
-> ->             used ? 
->   There are no set of semantics for each priority level. 
->   The different levels provide an ordering that can be 
->   used to determine preemption during the establishment 
->   of LSPs. They can also be used by an implementation 
->   as a means of ordering LSP computation and setup. 
->   How to use these priority levels? Look at: 
->   CR-LDP draft-ietf-mpls-cr-ldp-05.txt and 
->   RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 
-> -> why we need this. 
->   The need for priority levels is specified in 
->   RFC 2702. There is a consensus of eight protocols 
->   being sufficient.  
->   In Dan's terms... 
->   "The priority attribute defines the relative importance of traffic 
->    trunks.  If a constraint-based routing framework is used 
-> with MPLS, 
->    then priorities become very important because they can be used to 
->    determine the order in which path selection is done for traffic 
->    trunks at connection establishment and under fault scenarios. 
->    Priorities are also important in implementations  permitting 
->    preemption because they can be used to impose a partial 
-> order on the 
->    set of traffic trunks according to which preemptive 
-> policies can be 
->    actualized." 
-> --Venkata Naidu 
-> 

------_=_NextPart_001_01C12728.B220BE70
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.2653.12">
<TITLE>RE: Traffic Engineering TLV</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Dear Naidu</FONT>
</P>

<P><FONT SIZE=2>&nbsp;I couldn't find the draft-kompella-tewg-bw-acct-00.txt draft can you please</FONT>
<BR><FONT SIZE=2>&nbsp;tell me where can i get this draft ?</FONT>
</P>

<P><FONT SIZE=2>Thanks &amp; regds</FONT>
<BR><FONT SIZE=2>Ashwin</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Naidu, Venkata [<A HREF="mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, August 16, 2001 7:12 PM</FONT>
<BR><FONT SIZE=2>To: 'Ashwin C. Prabhu'; Naidu, Venkata; mpls@UU.NET; mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=2>Subject: FW: Traffic Engineering TLV</FONT>
</P>
<BR>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Please look at my inline comments...</FONT>
</P>

<P><FONT SIZE=2>-&gt; The priority/preemption is a task of MPLS Management </FONT>
<BR><FONT SIZE=2>-&gt; module. I would like to know why the 8 priority levels </FONT>
<BR><FONT SIZE=2>-&gt; are provided in the OSPF Extension? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; OSPF (for that matter any IGP) job is to flood the TE</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; information throughout the area (at present) for TE</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; purpose. The 8 priority levels for unreserved bw is </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; nothing to do with OSPF calculations. Just flood the info!</FONT>
</P>

<P><FONT SIZE=2>-&gt; What i was thinking is this 8 priority levels is used by </FONT>
<BR><FONT SIZE=2>-&gt; the CSPF for the computation of the routes. If so, why </FONT>
<BR><FONT SIZE=2>-&gt; is it Unreservable Bandwidth for the 8 priority levels ? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Yes! After flooding the TE information, ingress LERs do </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; CSPF to prune links (which are not met the requested </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; bw, priority, preemption etc) to find the best path to egress.</FONT>
</P>

<P><FONT SIZE=2>-&gt; does it mean that on a link we configure the Bandwidth </FONT>
<BR><FONT SIZE=2>-&gt; for different priority levels ? </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Like Priority 0 -&gt; 30 % bandwidth etc ) </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Or this is ment for some other purpose ? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; It is not that simple, please look at Kompella's paper</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; draft-kompella-tewg-bw-acct-00.txt (and nested references)</FONT>
</P>

<P><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As i found the draft draft-katz-yeung-ospf-traffic-04 </FONT>
<BR><FONT SIZE=2>-&gt; not mentioning it clearly. </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; with configuration of priority levels. </FONT>
</P>

<P><FONT SIZE=2>--Venkata Naidu</FONT>
</P>
<BR>

<P><FONT SIZE=2>-&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=2>-&gt; From: Naidu, Venkata [<A HREF="mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.com</A>] </FONT>
<BR><FONT SIZE=2>-&gt; Sent: Tuesday, August 14, 2001 7:37 PM </FONT>
<BR><FONT SIZE=2>-&gt; To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com </FONT>
<BR><FONT SIZE=2>-&gt; Subject: FW: Traffic Engineering TLV </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
<BR><FONT SIZE=2>-&gt; Prabhu: </FONT>
<BR><FONT SIZE=2>-&gt; -&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can anyone please tell me what are these 8 </FONT>
<BR><FONT SIZE=2>-&gt; -&gt; priority levels and what for these </FONT>
<BR><FONT SIZE=2>-&gt; -&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used ? </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; There are no set of semantics for each priority level. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; The different levels provide an ordering that can be </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; used to determine preemption during the establishment </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; of LSPs. They can also be used by an implementation </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; as a means of ordering LSP computation and setup. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; How to use these priority levels? Look at: </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; CR-LDP draft-ietf-mpls-cr-ldp-05.txt and </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt </FONT>
<BR><FONT SIZE=2>-&gt; -&gt; why we need this. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; The need for priority levels is specified in </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; RFC 2702. There is a consensus of eight protocols </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; being sufficient.&nbsp; </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; In Dan's terms... </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; &quot;The priority attribute defines the relative importance of traffic </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; trunks.&nbsp; If a constraint-based routing framework is used </FONT>
<BR><FONT SIZE=2>-&gt; with MPLS, </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; then priorities become very important because they can be used to </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; determine the order in which path selection is done for traffic </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; trunks at connection establishment and under fault scenarios. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; Priorities are also important in implementations&nbsp; permitting </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; preemption because they can be used to impose a partial </FONT>
<BR><FONT SIZE=2>-&gt; order on the </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; set of traffic trunks according to which preemptive </FONT>
<BR><FONT SIZE=2>-&gt; policies can be </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; actualized.&quot; </FONT>
<BR><FONT SIZE=2>-&gt; --Venkata Naidu </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12728.B220BE70--


From owner-mpls@UU.NET  Fri Aug 17 10:05:14 2001
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 KAA02485
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:05:14 -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 QQlcma13279;
	Fri, 17 Aug 2001 14:06:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcma12758
	for mpls-outgoing; Fri, 17 Aug 2001 14:06: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 QQlcma11952
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:05:54 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 QQlcma01861
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:04:43 GMT
Received: from bgslc02.TBG.COM by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host2.tbg.com [63.99.125.2] (may be forged))
	id QQlcma04775
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:04:43 GMT
Received: by host2.tbg.com with Internet Mail Service (5.5.2653.19)
	id <QQ7704WH>; Fri, 17 Aug 2001 08:01:08 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7025A5AF6@host2.tbg.com>
From: Irwin Lazar <ILazar@tbg.com>
To: "'Morten J. Christensen'" <mjc@exbit.com>, mpls@UU.NET
Subject: RE: MPLS list moderator needed?
Date: Fri, 17 Aug 2001 08:01:05 -0600
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

It seems as if this list allows posting from people who aren't subscribed.
Merely implementing that restriction should cut way down on the spam.

Irwin

> -----Original Message-----
> From: Morten J. Christensen [mailto:mjc@exbit.com]
> Sent: Friday, August 17, 2001 3:28 AM
> To: mpls@UU.NET
> Subject: MPLS list moderator needed?
> 
> 
> Hi All and especially mpls list maintainer
> 
> I receive a lot of spam mail from this and other IETF mailing lists
> and I suspect a lot of you guys do too.
> 
> Is there anyway this list could be moderated so that the spam
> could be removed before reaching thousands of recipients?
> 
> cheers
> 
> Morten
> 


From owner-mpls@UU.NET  Fri Aug 17 10:12:03 2001
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 KAA02759
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:12:03 -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 QQlcma27157;
	Fri, 17 Aug 2001 14:13:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcma15098
	for mpls-outgoing; Fri, 17 Aug 2001 14:12:53 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 QQlcma15093
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:12:50 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 QQlcma22351
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:11:40 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcma16546
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:11:40 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA26086;
	Fri, 17 Aug 2001 10:11:39 -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 KAA11449; Fri, 17 Aug 2001 10:11:15 -0400 (EDT)
Message-Id: <200108171411.KAA11449@erosen-u10.cisco.com>
X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs
To: Irwin Lazar <ILazar@tbg.com>
cc: "'Morten J. Christensen'" <mjc@exbit.com>, mpls@UU.NET
Subject: Re: MPLS list moderator needed? 
In-reply-to: Your message of Fri, 17 Aug 2001 08:01:05 -0600.
             <0C875DC28791D21192CD00104B95BFE7025A5AF6@host2.tbg.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 17 Aug 2001 10:11:15 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Before  we  get  into  one   of  those  week-long  debates  about  anti-spam
procedures ... 

The spate of spam yesterday was due solely to a bug that was introduced into
the anti-spam recipes;  this bug is now fixed and the  spam volume should go
down again.



From owner-mpls@UU.NET  Fri Aug 17 10:20:15 2001
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 KAA03045
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:20:14 -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 QQlcmb03229;
	Fri, 17 Aug 2001 14:21:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmb16057
	for mpls-outgoing; Fri, 17 Aug 2001 14:21:02 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 QQlcmb16035
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:21: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 QQlcmb00266
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:15:51 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 QQlcmb03086
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:15:50 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 KAA14618
	for <mpls@uu.net>; Fri, 17 Aug 2001 10:15:48 -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 KAA11930
	for <mpls@uu.net>; Fri, 17 Aug 2001 10:15:52 -0400 (EDT)
Message-ID: <3B7D271F.847A41F6@marconi.com>
Date: Fri, 17 Aug 2001 10:15:59 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: MPLS list moderator needed?
References: <0C875DC28791D21192CD00104B95BFE7025A5AF6@host2.tbg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irwin Lazar wrote:
> 
> It seems as if this list allows posting from people who aren't
> subscribed.  Merely implementing that restriction should cut way
> down on the spam.

It has been suggested many times in the past.  For some reason, the list
owner does not want to implement this change.

So we all get spammed and can't do a thing about it without resorting to
content-based filters, which (for me, anyway) are too inaccurate to
actually use.

-- David


From owner-mpls@UU.NET  Fri Aug 17 10:21:24 2001
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 KAA03111
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:21:24 -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 QQlcmb05651;
	Fri, 17 Aug 2001 14:22:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmb16201
	for mpls-outgoing; Fri, 17 Aug 2001 14:22: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 QQlcmb16196
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:22: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 QQlcmb15411
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:21:11 GMT
Received: from prue.eim.surrey.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5])
	id QQlcmb06338
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:21:11 GMT
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 15XkUj-0007jn-00; Fri, 17 Aug 2001 15:21:05 +0100
Date: Fri, 17 Aug 2001 15:20:57 +0100 (BST)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood <L.Wood@eim.surrey.ac.uk>
To: Irwin Lazar <ILazar@tbg.com>
cc: "'Morten J. Christensen'" <mjc@exbit.com>, mpls@UU.NET
Subject: RE: MPLS list moderator needed?
In-Reply-To: <0C875DC28791D21192CD00104B95BFE7025A5AF6@host2.tbg.com>
Message-ID: <Pine.GSO.4.21.0108171519110.12007-100000@phaestos.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *15XkUj-0007jn-00*.uWGxDblBKg*                                
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 17 Aug 2001, Irwin Lazar wrote:

> It seems as if this list allows posting from people who aren't subscribed.
> Merely implementing that restriction should cut way down on the spam.

IETF lists are generally open to people who aren't subscribed, to
encourage cross-collaboration, cope with account mobility, etc.

You wouldn't want e.g. a message from the IESG to the list being
bounced or trapped...

This is thrashed out in nauseating detail every so often in poisson.

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



From owner-mpls@UU.NET  Fri Aug 17 10:23:40 2001
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 KAA03243
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:23:40 -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 QQlcmb09944;
	Fri, 17 Aug 2001 14:24:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmb16352
	for mpls-outgoing; Fri, 17 Aug 2001 14:24: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 QQlcmb16343
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:24:20 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 QQlcmb10536
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:24:04 GMT
Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcmb11314
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:24:04 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7HENgp26782
	for <mpls@uu.net>; Fri, 17 Aug 2001 10:23:42 -0400 (EDT)
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 17 Aug 2001 10:23:56 -0400
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id Q5Y48QDS; Fri, 17 Aug 2001 10:23:55 -0400
Received: from nortelnetworks.com (sandick2k.us.nortel.com [47.141.98.30]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id Q0KL6GCP; Fri, 17 Aug 2001 10:23:54 -0400
Message-ID: <3B7D2901.30BE921F@nortelnetworks.com>
Date: Fri, 17 Aug 2001 10:24:01 -0400
X-Sybari-Trust: c8dc9892 04008c04 04013600
From: "Hal Sandick" <hsandick@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: test ignore
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
              micalg=sha1; boundary="------------ms25E34EA7C6CB8F4DB62F0CC7"
X-Orig: <hsandick@nortelnetworks.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a cryptographically signed message in MIME format.

--------------ms25E34EA7C6CB8F4DB62F0CC7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------ms25E34EA7C6CB8F4DB62F0CC7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIbwYJKoZIhvcNAQcCoIIIYDCCCFwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BkIwggMRMIICeqADAgECAgMEeJQwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTAzMjYyMDUwNTJaFw0wMjAzMjYyMDUwNTJa
MIGcMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSowKAYJKoZIhvcNAQkBFhto
c2FuZGlja0Bub3J0ZWxuZXR3b3Jrcy5jb20xKjAoBgkqhkiG9w0BCQEWG2hzYW5kaWNrQGFt
ZXJpY2FzbTA2Lm50LmNvbTEhMB8GCSqGSIb3DQEJARYSc2FuZGlja0BpbnRyZXgubmV0MIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6UM3xSwrkTWvhZxUi2T96aWLN1JinlH/lcFEV
+ai53IdZ2i4MDgwGgAWXVM+uCb+aRGHYy+zK9+DQG0OEjCIGl34odwlw9YXPsI35+cJHr3MC
JNtDsx1L6Jj6Lenrklj3j6ZAGTE3dU5b4OfGptFsqn6/x09+7yyc5mkaApsPbQIDAQABo2kw
ZzBXBgNVHREEUDBOgRtoc2FuZGlja0Bub3J0ZWxuZXR3b3Jrcy5jb22BG2hzYW5kaWNrQGFt
ZXJpY2FzbTA2Lm50LmNvbYESc2FuZGlja0BpbnRyZXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEA1NrA7DapmT+B0fZ4UL5NB6vKiFfvs8fo934jWZmOT5miNAauHHHs
DVpWNTayTnPq3DVynnAajWKN54z1/U3Z432MzvQkBFzH1m/4JumozNXGFeaQ/DNes2hQh4mj
KlqCIzJK/g+lcR7c2Hzjtx2VEvUPhscWKDOVm62vKLDifwQwggMpMIICkqADAgECAgEMMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw
EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL
Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMC
WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQK
EwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz
b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y
8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5
tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UE
AxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYw
DQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxt
t88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe2
1Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggH1MIIB8QIBATCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU
b3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw
JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMEeJQwCQYFKw4DAhoF
AKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMTA4MTcx
NDI0MDFaMCMGCSqGSIb3DQEJBDEWBBS8ki3YLxLmCui6GWQgSvZ6yBU5kDBSBgkqhkiG9w0B
CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgEw2Ym3/Ve1u0QkVdNHRJ4H1
gtTXtSXeU2retmFT0h9AMTL60F3ftbtshTHYaFE1FuVCaMy0hNkpw3Qugdk1TmJJF7Puvs2A
MgoTZ3hZER7U1wPtiUybnyxJZHK+knZdPRuF+k514qTi/48R0+GYFwvzUzonMHxAyiUbENPJ
/Fkp
--------------ms25E34EA7C6CB8F4DB62F0CC7--



From owner-mpls@UU.NET  Fri Aug 17 10:32:47 2001
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 KAA03596
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:32:47 -0400 (EDT)
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 QQlcmc28609;
	Fri, 17 Aug 2001 14:33:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmc17206
	for mpls-outgoing; Fri, 17 Aug 2001 14:33: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 QQlcmc17198
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:33:34 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 QQlcmc00031
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:32:12 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcmc25882
	for <mpls@uu.net>; Fri, 17 Aug 2001 14:32: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 KAA12873 for <mpls@uu.net>; Fri, 17 Aug 2001 10:32:10 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11570 for mpls@uu.net; Fri, 17 Aug 2001 10:31:46 -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 QQlcmb16181
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:21:39 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 QQlcmb01764
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:19:36 GMT
Received: from huginn.ctccom.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: Huginn.CTCCom.net [207.190.194.11])
	id QQlcmb00044
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:19:36 GMT
Received: from MBRAHMANAPALLY ([64.69.123.121])
	by huginn.ctccom.net (Mirapoint)
	with SMTP id AEE80176;
	Fri, 17 Aug 2001 10:19:34 -0400 (EDT)
From: "Madhu Babu Brahmanapally" <madhubabu@kenetec.com>
To: <mpls@UU.NET>
Subject: Moderator needed?
Date: Fri, 17 Aug 2001 10:23:59 -0400
Message-ID: <005001c12728$4221c8d0$c500a8c0@MBRAHMANAPALLY>
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.2911.0)
Importance: Normal
In-Reply-To: <A1AFE5CF886C5D439494D9D5DE84EEF3737238@radiant.chromisys.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI All,
I think that sending mails from a unsubscribed user is fine as it will help
him/her to send queries to the list without subscribing. I think IETF does
allow this option.

Regards
Madhubabu



From owner-mpls@UU.NET  Fri Aug 17 10:32:54 2001
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 KAA03607
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 10:32:54 -0400 (EDT)
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 QQlcmc29071;
	Fri, 17 Aug 2001 14:34:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmc17220
	for mpls-outgoing; Fri, 17 Aug 2001 14:33: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 QQlcmc17211
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 14:33: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 QQlcmc10771
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:33:21 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcmc24310
	for <mpls@UU.NET>; Fri, 17 Aug 2001 14:33:20 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29009;
	Fri, 17 Aug 2001 10:33:20 -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 KAA11579; Fri, 17 Aug 2001 10:32:56 -0400 (EDT)
Message-Id: <200108171432.KAA11579@erosen-u10.cisco.com>
X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs
To: David Charlap <david.charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: MPLS list moderator needed? 
In-reply-to: Your message of Fri, 17 Aug 2001 10:15:59 -0400.
             <3B7D271F.847A41F6@marconi.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 17 Aug 2001 10:32:55 -0400
From: Eric Rosen <erosen@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Sigh. 

In fact, messages from non-members  are bounced to the list owner.  However,
the list owner  uses some automation to automatically  approve messages that
are  from legitimate  non-member participants.   This is  done  primarily to
allow companies  to use internal  mail exploders.  Occasionally a  bug works
its way  into the automated  procedures, and that's what  causes yesterday's
spam attack. 



From owner-mpls@UU.NET  Fri Aug 17 11:27:30 2001
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 LAA05177
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 11:27:30 -0400 (EDT)
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 QQlcls08526;
	Fri, 17 Aug 2001 12:06:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcls22564
	for mpls-outgoing; Fri, 17 Aug 2001 12:05:52 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 QQlcls22182
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 12:05:50 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 QQlclr24212
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:48:49 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlclr06710
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:48:49 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA13373 for mpls@uu.net; Fri, 17 Aug 2001 07:48:48 -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 QQlclo06706
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 11:11:44 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 QQlclo04680
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:04:49 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 QQlclo06219
	for <mpls@uu.net>; Fri, 17 Aug 2001 11:04:48 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23409;
	Fri, 17 Aug 2001 07:03:34 -0400 (EDT)
Message-Id: <200108171103.HAA23409@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-tc-mib-01.txt
Date: Fri, 17 Aug 2001 07:03:34 -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		: Definitions of Textual Conventions and 
                          OBJECT-IDENTITIES for Multi-Protocol Label Switching 
                          (MPLS) Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-mpls-tc-mib-01.txt
	Pages		: 13
	Date		: 16-Aug-01
	
This memo describes Textual Conventions and OBJECT-IDENTITIES used
for managing MPLS networks

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-tc-mib-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-tc-mib-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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:	<20010816140145.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-tc-mib-01.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Aug 17 13:53:27 2001
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 NAA09975
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 13:53:26 -0400 (EDT)
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 QQlcmp02892;
	Fri, 17 Aug 2001 17:54:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmp29246
	for mpls-outgoing; Fri, 17 Aug 2001 17:53:58 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 QQlcmp29232
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 17:53:53 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 QQlcmp06397
	for <mpls@UU.NET>; Fri, 17 Aug 2001 17:51:36 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQlcmp28618
	for <mpls@UU.NET>; Fri, 17 Aug 2001 17:51:36 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id <39P714XV>; Fri, 17 Aug 2001 12:50:34 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FED81@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" <mpour@celoxnetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Interworking between CR-LDP and RSVP-TE
Date: Fri, 17 Aug 2001 12:50:26 -0500
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,
I have a question regarding draft write-mpls-crldp-rsvpte-iw-00.txt on
interworking LSRs
supporting CR-LDP and RSVP-TE.

The draft gives four network scenarios, namely
1- RSVP-TE -> CR-LDP
2- CR-LDP -> RSVP-TE
3- RSVP-TE -> CR-LDP -> RSVP-TE
4- CR-LDP -> RSVP-TE -> CR-LDP

and states that scenarios 1, 2 and 3 are covered by this draft, but not 4. 
If the ingress LSR can support case 2 and the egress case 1, with RSVP-TE
supported in between, 
don't we get case 4? What am I missing? 

Thanks
Mort


From owner-mpls@UU.NET  Fri Aug 17 14:30:33 2001
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 OAA11837
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 14:30:32 -0400 (EDT)
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 QQlcms04274;
	Fri, 17 Aug 2001 18:31:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcms21409
	for mpls-outgoing; Fri, 17 Aug 2001 18:31: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 QQlcms21404
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:31:08 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 QQlcmr26432
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:22:26 GMT
Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQlcmr29960
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:22:26 GMT
Received: from aatlas-pc (aatlas-pc.avici.com [10.2.20.92])
	by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f7HILdn22119;
	Fri, 17 Aug 2001 14:21:40 -0400 (EDT)
Message-Id: <4.1.20010817141518.00ae27e0@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 17 Aug 2001 14:18:10 -0500
To: Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: draft minutes from London meeting
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <6CECAF1A722ED842B24EC8EDA5B076048D8A97@exchsrv4>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 12:56 PM 8/15/01 -0700, Vijay Srinivasan wrote: 
>
> (Slides for the below presentation are located in file aatlas.ppt) 
>
> Presentation by Alia Atlas. She presented a detailed discussion of the
> content 
> of draft "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute" 
> (draft-atlas-rsvp-local-protect-interop-01.txt). 
>
> Ping Pan said his draft does support local repair. 
>
> Comment from George Swallow (not as chair): his draft and the Ping Pan, 
> Der-Hwa Gan draft are not competitors and the authors from the two drafts 
> should form a single draft design team. 
>
> Question: There appears to be a lot of complexity in these proposals, 
> will they be implemented or deployed? 
> Answer: From George Swallow, these are already implemented and deployed 
> and this is an opportunity to specify how this is done. 


The agreement was that the authors of all 3 drafts,
draft-swallow-rsvp-bypass-labels-01.txt, draft-gan--fast-reroute-00.txt and
draft-atlas-rsvp-local-protect-interop-01.txt, should form a single draft
design team.

Alia Atlas





From owner-mpls@UU.NET  Fri Aug 17 14:32:10 2001
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 OAA11921
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 14:32:10 -0400 (EDT)
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 QQlcms07387;
	Fri, 17 Aug 2001 18:33:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcms21555
	for mpls-outgoing; Fri, 17 Aug 2001 18:32: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 QQlcms21550
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:32:56 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 QQlcmr03491
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:27:45 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcmr08031
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:27:45 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA11451 for mpls@uu.net; Fri, 17 Aug 2001 14:27:44 -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 QQlcmr21035
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:27:25 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 QQlcmr11713
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:26:27 GMT
Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221])
	id QQlcmr25686
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:26:27 GMT
Received: from packetexchange.net (host213-120-54-247.host.btclick.com [213.120.54.247])
	by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP
	id DD43115F838; Fri, 17 Aug 2001 19:26:14 +0100 (BST)
Message-ID: <3B7D6164.6EE838EC@packetexchange.net>
Date: Fri, 17 Aug 2001 19:24:36 +0100
From: Giles Heron <giles@packetexchange.net>
Reply-To: giles@packetexchange.net
Organization: PacketExchange Ltd.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Zelig <Davidz@corrigent.com>
Cc: "'pwe3@ietf.org'" <pwe3@ietf.org>, ppvpn@zephion.net, mpls@UU.NET
Subject: Re: [PWE3] New I-Ds related to Pseudo Wire MIBs
References: <8FA6CEF9A4E42B48A5F8DC038655B35372560F@mxtlv1.corrigent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi David (and others.)

A bit late for comments, I know, but I've finally had time to review the
MIB presentation and the MIBs.  The MIBs look good, but I've got a few
questions/comments:

1.  The presentation states that if there is no outer tunnel then the VC
is assumed to have entries in MPLS-LSR-MIB.  Why not always make this
assumption (i.e. store the VC labels in MPLS-LSR-MIB.)  I would imagine
that this is what vendors are doing in the interim in any case?  If they
aren't I could have trouble managing my service!

2.  The PW-MIB has VC labels in it.  Wouldn't these be better located in
the PSN-specific MIBs?

3.  I still feel that the signalling and encapsulation information
should be separate.  I'm not sure that it would be so difficult to
cross-associate these MIBs?

4.  The VC type of hdlcCisco needs to be renamed hdlc.

5.  Does the VC type of GRE refer to PW over GRE, or PW over MPLS over
GRE?

6.  Following on from the question above, perhaps we should separate PW
type and PSN type (so MPLS over IP would be a PW type of MPLS and a PSN
type of IP?)

7.  To be honest I think the APS stuff should probably be moved to a
PW-APS-MIB.  I think in general 1+1 APS will mostly be used for CEM (so
perhaps it should even be in the CEM MIB?)   In any case I'd rather keep
it out of the general PW MIB that those of us building packet networks
will use.

Giles

David Zelig wrote:
> 
> All,
> 
> The following I-Ds describe some of the MIB modules for PW operation.
> 
> http://www.ietf.org/internet-drafts/draft-zelig-pw-mib-00.txt
> This draft contains 2 MIB modules:
> 
> PW-MIB - Configures general parameters for the PW/VC creation and signaling,
> Independent of PSN type and PW service. It contains performance monitoring
> common to all service types and 1+1 APS at the VC level configuration.
> 
> PW-MPLS-MIB: Handles PW carried over MPLS PSN flavours :
> MPLS-TE, MPLS-LSP and VC only (no outer label).
> 
> Other PSNs modules will be added in the future.
> 
> Service specific modules will be defined in seperate i-d. For SoneT circuit
> emulation (CEM), the following MIB is available:
> http://search.ietf.org/internet-drafts/draft-danenberg-pw-cem-mib-00.txt
> 
> http://search.ietf.org/internet-drafts/draft-nadeau-pw-tc-mib-00.txt
> contains the textual conventions used in the PW MIBs modules.
> 
> Remarks and discussion are welcomed.
> 
> David
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> http://www.ietf.org/mailman/listinfo/pwe3

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



From owner-mpls@UU.NET  Fri Aug 17 14:46:00 2001
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 OAA12364
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 14:46:00 -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 QQlcmt09231;
	Fri, 17 Aug 2001 18:47:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmt23014
	for mpls-outgoing; Fri, 17 Aug 2001 18:46: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 QQlcmt23005
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:46:35 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 QQlcms09226
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:40:16 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlcms19710
	for <mpls@UU.NET>; Fri, 17 Aug 2001 18:40:15 GMT
Message-ID: <3B7D650E.9D7D1F4A@sandburst.com>
Date: Fri, 17 Aug 2001 14:40:14 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Pour, Mort" <mpour@celoxnetworks.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Re: Interworking between CR-LDP and RSVP-TE
References: <6F2719D5300C624BBC5F69424EC0C2060FED81@celox-stl-ems2.celoxnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mort,

    This draft was allowed to expire by its authors.  It expired almost a year
ago, and it is possible that people do not feel it is worth continuing this
work.  On this score, I don't know.

    However, the intent of the draft is captured in its title - "CR-LDP
Extensions for Interworking with RSVP-TE".  Note that it does not seem
to propose RSVP-TE extensions for interworking with CR-LDP.

    The draft also states that scenarios 1 and 2 are mutually exclusive.  This
makes sense, because these scenarios are intended to describe entire LSPs.
In the first two cases, the LSP starts with one protocol and ends with
another. In the last two cases, the LSP starts and ends with the same
protocol but traverses some non-zero number of LSRs using the other
protocol.

    From these facts, one might imagine that the authors felt that information
may be lost in transforming LSP-related transactions from one protocol to
another and - by proposing extensions to one of those protocols - authors
hoped to eliminate this loss of information in the case where that protocol
was in use between instances of the other protocol.  If information loss is
the concern, then scenario 4 would require extensions to RSVP-TE for the
purpose of preventing information loss when RSVP-TE is in use between
instances of CR-LDP.

    Hopefully, this answers your question.

--
Eric Gray

You wrote:

> Hi,
> I have a question regarding draft write-mpls-crldp-rsvpte-iw-00.txt on
> interworking LSRs
> supporting CR-LDP and RSVP-TE.
>
> The draft gives four network scenarios, namely
> 1- RSVP-TE -> CR-LDP
> 2- CR-LDP -> RSVP-TE
> 3- RSVP-TE -> CR-LDP -> RSVP-TE
> 4- CR-LDP -> RSVP-TE -> CR-LDP
>
> and states that scenarios 1, 2 and 3 are covered by this draft, but not 4.
> If the ingress LSR can support case 2 and the egress case 1, with RSVP-TE
> supported in between,
> don't we get case 4? What am I missing?
>
> Thanks
> Mort



From owner-mpls@UU.NET  Fri Aug 17 15:12:51 2001
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 PAA13040
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 15:12: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 QQlcmu14581;
	Fri, 17 Aug 2001 19:13:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmu13908
	for mpls-outgoing; Fri, 17 Aug 2001 19:13: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 QQlcmu13903
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 19:13:19 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 QQlcmu02690
	for <mpls@uu.net>; Fri, 17 Aug 2001 19:10:34 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcmu18244
	for <mpls@uu.net>; Fri, 17 Aug 2001 19:10:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA15117 for mpls@uu.net; Fri, 17 Aug 2001 15:10:33 -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 QQlcmu12988
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 19:10: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 QQlcmu14541
	for <mpls@UU.NET>; Fri, 17 Aug 2001 19:03:32 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcmu26351
	for <mpls@UU.NET>; Fri, 17 Aug 2001 19:03:32 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19558; Fri, 17 Aug 2001 15:03:31 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA17168; Fri, 17 Aug 2001 15:03:30 -0400 (EDT)
Message-Id: <200108171903.PAA17168@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: Alia Atlas <aatlas@avici.com>
cc: Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>,
        "'mpls@uu.net'" <mpls@UU.NET>, swallow@cisco.com
Subject: Re: draft minutes from London meeting 
In-reply-to: Your message of "Fri, 17 Aug 2001 14:18:10 CDT."
             <4.1.20010817141518.00ae27e0@mailhost.avici.com> 
Date: Fri, 17 Aug 2001 15:03:30 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> The agreement was that the authors of all 3 drafts,
> draft-swallow-rsvp-bypass-labels-01.txt, draft-gan--fast-reroute-00.txt and
> draft-atlas-rsvp-local-protect-interop-01.txt, should form a single draft
> design team.

Correct.

...george

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



From owner-mpls@UU.NET  Fri Aug 17 15:26:09 2001
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 PAA13377
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 15:26:08 -0400 (EDT)
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 QQlcmv06990;
	Fri, 17 Aug 2001 19:27:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcmv15384
	for mpls-outgoing; Fri, 17 Aug 2001 19:26: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 QQlcmv15372
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 19:26: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 QQlcmv27275
	for <mpls@UU.NET>; Fri, 17 Aug 2001 19:23:48 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQlcmv09115
	for <mpls@UU.NET>; Fri, 17 Aug 2001 19:23:48 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id <39P71V2A>; Fri, 17 Aug 2001 14:22:45 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FED83@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" <mpour@celoxnetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Interworking between CR-LDP and RSVP-TE
Date: Fri, 17 Aug 2001 14:22:38 -0500
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 Eric. 
I see your point about the need to extend one protocol (the one we are
mapping
messages to) to prevent information loss. For example in the case of
RSVP-TE -> CR-LDP we need to extend CR-LDP. Then in case 2 (CR-LDP ->
RSVP-TE) and 3
we would need to extend RSVP-TE. This is not done in the draft but yet it
claims to cover those cases. 

If those cases are covered, then, it seems to me, case 4 must also be
covered. 
It is still not clear to me.

On the point about obsoleteness, it seems that some vendors are supporting
RSVP-TE
and some others CR-LDP. If that is the case, won't interoperability become
an issue?

Thanks
Mort

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Friday, August 17, 2001 1:40 PM
To: Pour, Mort
Cc: 'mpls@UU.NET'
Subject: Re: Interworking between CR-LDP and RSVP-TE


Mort,

    This draft was allowed to expire by its authors.  It expired almost a
year
ago, and it is possible that people do not feel it is worth continuing this
work.  On this score, I don't know.

    However, the intent of the draft is captured in its title - "CR-LDP
Extensions for Interworking with RSVP-TE".  Note that it does not seem
to propose RSVP-TE extensions for interworking with CR-LDP.

    The draft also states that scenarios 1 and 2 are mutually exclusive.
This
makes sense, because these scenarios are intended to describe entire LSPs.
In the first two cases, the LSP starts with one protocol and ends with
another. In the last two cases, the LSP starts and ends with the same
protocol but traverses some non-zero number of LSRs using the other
protocol.

    From these facts, one might imagine that the authors felt that
information
may be lost in transforming LSP-related transactions from one protocol to
another and - by proposing extensions to one of those protocols - authors
hoped to eliminate this loss of information in the case where that protocol
was in use between instances of the other protocol.  If information loss is
the concern, then scenario 4 would require extensions to RSVP-TE for the
purpose of preventing information loss when RSVP-TE is in use between
instances of CR-LDP.

    Hopefully, this answers your question.

--
Eric Gray

You wrote:

> Hi,
> I have a question regarding draft write-mpls-crldp-rsvpte-iw-00.txt on
> interworking LSRs
> supporting CR-LDP and RSVP-TE.
>
> The draft gives four network scenarios, namely
> 1- RSVP-TE -> CR-LDP
> 2- CR-LDP -> RSVP-TE
> 3- RSVP-TE -> CR-LDP -> RSVP-TE
> 4- CR-LDP -> RSVP-TE -> CR-LDP
>
> and states that scenarios 1, 2 and 3 are covered by this draft, but not 4.
> If the ingress LSR can support case 2 and the egress case 1, with RSVP-TE
> supported in between,
> don't we get case 4? What am I missing?
>
> Thanks
> Mort


From owner-mpls@UU.NET  Fri Aug 17 17:51:11 2001
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 RAA15740
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 17:51:10 -0400 (EDT)
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 QQlcnf07214;
	Fri, 17 Aug 2001 21:52:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcnf06491
	for mpls-outgoing; Fri, 17 Aug 2001 21:51: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 QQlcnf06485
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 21:51:50 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 QQlcnf09222
	for <mpls@uu.net>; Fri, 17 Aug 2001 21:51:32 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcnf26666
	for <mpls@uu.net>; Fri, 17 Aug 2001 21:51:31 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA26994
	for <mpls@uu.net>; Fri, 17 Aug 2001 17:51:30 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA12071 for mpls@uu.net; Fri, 17 Aug 2001 17:51:06 -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 QQlcmr19866
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:16:13 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 QQlcmr14853
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:15:27 GMT
Received: from nwds0102.jc.digitran.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQlcmr07706
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:15:25 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Fri, 17 Aug 2001 11:14:42 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'MPLS Mailing List \(E-mail\)'" <mpls@UU.NET>
Subject: latest versions of TC and FTN MIBs posted
Date: Fri, 17 Aug 2001 11:59:30 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB0ED@OPTONT>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0000_01C12712.817752E0"
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.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C12712.817752E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I sent emails about this yesterday but didn't see it on
the list somehow ...

I posted the latest version of the TC MIB (v01) and
FTN MIB (v02) yesterday. Copies are attached. Note that
v02 of the FTN MIB needs v01 of the TC MIB.

Cheenu

------=_NextPart_000_0000_01C12712.817752E0
Content-Type: text/plain;
	name="draft-ietf-mpls-tc-mib-01.txt"
Content-Disposition: attachment;
	filename="draft-ietf-mpls-tc-mib-01.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Expires: January 2002                                               =20
                                                       Joan Cucchiara
                                                    Crescent Networks
                                                                    =20
                                                    Cheenu Srinivasan
                                                        Alphion Corp.
                                                                    =20
                                                     Arun Viswanathan
                                               Force10 Networks, Inc.
                                                                    =20
                                                       Hans Sjostrand
                                                          ipUnplugged
                                                                    =20
                                                      August 16, 2001
                              =20
                              =20
  Definition of Textual Conventions and OBJECT-IDENTITIES for
       Multi-Protocol Label Switching (MPLS) Management
                              =20
                 draft-ietf-mpls-tc-mib-01.txt


Status of this Memo
  =20
   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026.
  =20
   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.

Table of Contents

   1. Abstract                                             2
   2. Introduction                                         2
   3. The SNMP Management Framework                        2
   4. MPLS TC MIB Definitions                              3
   5. Security Considerations                             10
   6. References                                          10



Nadeau et al              Expires February 2002              [Page 1]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



   7. Authors' Addresses                                  12
   8. Full Copyright Statement                            12
  =20


1. Abstract
  =20
   This memo describes Textual Conventions and OBJECT-
   IDENTITIES used for managing MPLS networks.


2. Introduction
  =20
   This memo defines a portion of the Management Information
   Base (MIB) for use with network management protocols in the
   Internet community. In particular, it defines Textual
   Conventions used in IETF MPLS and MPLS-related MIBs.
  =20
   Comments should be made directly to the MPLS mailing list
   at mpls@uu.net.
  =20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
   and "OPTIONAL" in this document are to be interpreted as
   described in RFC 2119, reference [RFC2119].
  =20
   For an introduction to the concepts of MPLS, see [RFC3031].


3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five
   major components:
  =20
   -  An overall architecture, described in RFC 2571
      [RFC2571].
  =20
   -  Mechanisms for describing and naming objects and events
      for the purpose of management.  The first version of
      this Structure of Management Information (SMI) is
      called SMIv1 and described in STD 16, RFC 1155
      [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
      [RFC1215].  The second version, called SMIv2, is
      described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
      2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
  =20
   -  Message protocols for transferring management
      information.  The first version of the SNMP message
      protocol is called SNMPv1 and described in STD 15, RFC
      1157 [RFC1157].  A second version of the SNMP message



Nadeau et al              Expires February 2002              [Page 2]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



      protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901
      [RFC1901] and RFC 1906 [RFC1906].  The third version of
      the message protocol is called SNMPv3 and described in
      RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
      [RFC2574].
  =20
   -  Protocol operations for accessing management
      information.  The first set of protocol operations and
      associated PDU formats is described in STD 15, RFC 1157
      [RFC1157].  A second set of protocol operations and
      associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2573
      [RFC2573] and the view-based access control mechanism
      described in RFC 2575 [RFC2575].
  =20
   A more detailed introduction to the current SNMP Management
   Framework can be found in RFC 2570 [RFC2570].
  =20
   Managed objects are accessed via a virtual information
   store, termed the Management Information Base or MIB.
   Objects in the MIB are defined using the mechanisms defined
   in the SMI.
  =20
   This memo specifies a MIB module that is compliant to the
   SMIv2.  A MIB conforming to the SMIv1 can be produced
   through the appropriate translations.  The resulting
   translated MIB must be semantically equivalent, except
   where objects or events are omitted because no translation
   is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual
   descriptions in SMIv1 during the translation process.
   However, this loss of machine readable information is not
   considered to change the semantics of the MIB.


4. MPLS TC MIB Definitions

MPLS-TC-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
   MODULE-IDENTITY, Unsigned32, Integer32
      FROM SNMPv2-SMI
   transmission
      FROM RFC1213-MIB
   TEXTUAL-CONVENTION
      FROM SNMPv2-TC;




Nadeau et al              Expires February 2002              [Page 3]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



mplsTCMIB MODULE-IDENTITY
   LAST-UPDATED
        "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   ORGANIZATION
        "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO
        "        Thomas D. Nadeau
                 Cisco Systems, Inc.
                 tnadeau@cisco.com
       =20
                 Joan Cucchiara
                 Crescent Networks
                 jcucchiara@crescentnetworks.com
       =20
                 Cheenu Srinivasan
                 Alphion Corp.
                 cheenu@alphion.com
       =20
                 Arun Viswanathan
                 Force10 Networks, Inc.
                 arun@force10networks.com
       =20
                 Hans Sjostrand
                 ipUnplugged
                 hans@ipunplugged.com
       =20
        Email comments to the MPLS WG Mailing List at
          mpls@uu.net."
   DESCRIPTION
        "This MIB module defines Textual Conventions and
          OBJECT-IDENTITIES for use in documents defining
          management information bases (MIBs) for managing
          MPLS networks."
       =20
     -- Revision history.
       =20
   REVISION
        "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   DESCRIPTION
        "Updates based on IESG review."
   REVISION
        "200104101200Z"  -- 10 April 2001 12:00:00 GMT
   DESCRIPTION
        "Initial version."
       =20
   ::=3D { mplsMIB 1 }

-- This object identifier needs to be assigned by IANA.
-- Since mpls has been assigned an ifType of 166 we recommend
-- that this OID be 166 as well.



Nadeau et al              Expires February 2002              [Page 4]
=0C
IETF Draft                   MPLS TC MIB                  August 2001




mplsMIB OBJECT IDENTIFIER
   ::=3D { transmission xxx }

-- Textual Conventions.

MplsBitRate ::=3D TEXTUAL-CONVENTION
   DISPLAY-HINT "d"
   STATUS      current
   DESCRIPTION
        "An estimate of bandwidth in units of 1,000 bits per
          second.  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'. For objects which do not vary
          in bit rate, or for those where no accurate
          estimation can be made, this object should contain
          the nominal bit rate."
   SYNTAX  Integer32 (1..2147483647)

MplsBurstSize ::=3D TEXTUAL-CONVENTION
   DISPLAY-HINT "d"
   STATUS      current
   DESCRIPTION
        "The number of octets of MPLS data that the stream
          may send back-to-back without concern for
          policing."
   SYNTAX  Unsigned32 (1..4294967295)

MplsPortAddr ::=3D TEXTUAL-CONVENTION
   STATUS              current
   DESCRIPTION
        "A TCP or UDP port number. Along with an IP address
          identifies a stream of IP traffic uniquely."
   SYNTAX              INTEGER (0..65535)

MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "A unique identifier for an MPLS Tunnel. This MAY
          represent an IpV4 address of the ingress or egress
          LSR for the tunnel. This value is derived from the
          Extended Tunnel Id in RSVP or the Ingress Router ID
          for CR-LDP."
   REFERENCE
        "1. Awduche, D., et al., RSVP-TE: Extensions to RSVP
          for LSP Tunnels,  draft-ietf-mpls-rsvp-lsp-tunnel-
          08.txt, February 2001.
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          B., et al., draft-ietf-mpls-cr-ldp-05.txt, February
          2001."



Nadeau et al              Expires February 2002              [Page 5]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



   SYNTAX  Unsigned32

MplsLabel ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "This value represents an MPLS label as defined in
          [RFC3031],  [RFC3032], [RFC3034] and [RFC3035]."
   REFERENCE
        "1. Multiprotocol Label Switching Architecture, Rosen
          et al, RFC 3031, August 1999.
         2. MPLS Label Stack Encoding, Rosen et al, RFC 3032,
          January 2001.
         3. Use of Label Switching on Frame Relay Networks,
          Conta et al, RFC 3034, January 2001.
         4. MPLS using LDP and ATM VC switching, Davie et al,
          RFC 3035, January 2001."
   SYNTAX  Unsigned32 (0..4294967295)

MplsLdpGenAddr ::=3D TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
        "The value of an network layer or data link layer
          address."
   SYNTAX  OCTET STRING (SIZE (0..64))

MplsLdpIdentifier ::=3D TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
        "The LDP identifier is a six octet quantity which is
          used to identify an Label Switch Router (LSR) label
          space.
       =20
         The first four octets identify the LSR and must be a
          globally unique value, such as a 32-bit router ID
          assigned to the LSR, and the last two octets
          identify a specific label space within the LSR."
   SYNTAX  OCTET STRING (SIZE (6))

MplsLdpLabelTypes ::=3D TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
        "The Layer 2 label types which are defined for MPLS
          LDP/CRLDP are generic(1), atm(2), or
          frameRelay(3)."
   SYNTAX  INTEGER {
             generic(1),
             atm(2),
             frameRelay(3)
         }




Nadeau et al              Expires February 2002              [Page 6]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



MplsAtmVcIdentifier ::=3D TEXTUAL-CONVENTION
   STATUS  current
   DESCRIPTION
        "The VCI value for a VCL. The maximum VCI value
          cannot exceed the value allowable by
          atmInterfaceMaxVciBits defined in ATM-MIB. The
          minimum value is 32, values 0 to 31 are reserved
          for other uses by the ITU and ATM Forum.  32 is
          typically the  default value for the Control VC."
   REFERENCE
        "Definitions of Textual Conventions and OBJECT-
          IDENTITIES for ATM Management, RFC 2514, Feb.
          1999."
   SYNTAX  Integer32 (32..65535)

MplsLSPID ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "An identifier that is assigned to each LSP and is
          used to uniquely identify it.  This is assigned at
          the head end of the LSP and can be used by all LSRs
          to identify this LSP.  This value is piggybacked by
          the signaling protocol when this LSP is signaled
          within the network.  This identifier can then be
          used at each LSR to identify which labels are being
          swapped to other labels for this LSP.  For IPv4
          addresses this results in a 6-octet long cookie."
   SYNTAX  OCTET STRING (SIZE (0..31))

MplsLsrIdentifier ::=3D TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
        "The Label Switch Router (LSR) identifier is the
          first 4 bytes of the Label Distribution Protocol
          (LDP) identifier."
   SYNTAX  OCTET STRING (SIZE (4))

MplsInitialCreationSource ::=3D TEXTUAL-CONVENTION
   STATUS      current
   DESCRIPTION
        "The entity that originally created the object in
          question. The values of this enumeration are
          defined as follows:
       =20
         other(1) - This is used when an entity which has not
          been enumerated in this textual convention but
          which is known by the agent.
       =20
         snmp(2) - The Simple Network Management Protocol was
          used to configure this object initially.



Nadeau et al              Expires February 2002              [Page 7]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



       =20
         ldp(3 - The Label Distribution Protocol was used to
          configure this object initially.
       =20
         rsvp(4) - The Resource Reservation Protocol was used
          to configure this object initially.
       =20
         crldp(5) - The Constraint-Based Label Distribution
          Protocol was used to configure this object
          initially.
       =20
         policyAgent(6) - A policy agent (perhaps in
          combination with one of the above protocols) was
          used to configure this object initially.
       =20
         unknown(7) - the agent cannot discern which
          component created the object."
   SYNTAX  INTEGER {
             other(1),
             snmp(2),
             ldp(3),
             rsvp(4),
             crldp(5),
             policyAgent(6),
             unknown (7)
         }

MplsPathIndex ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "A unique identifier used to identify a specific path
          used by a tunnel."
   SYNTAX  Unsigned32

MplsPathIndexOrZero ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "A unique identifier used to identify a specific path
          used by a tunnel. If this value is set to 0, it
          indicates that no path is in use."
   SYNTAX  Unsigned32

MplsTunnelAffinity ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "Include-any, include-all, or exclude-all constraint
          for link selection."
   SYNTAX  Unsigned32

MplsTunnelIndex ::=3D TEXTUAL-CONVENTION



Nadeau et al              Expires February 2002              [Page 8]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



   STATUS        current
   DESCRIPTION
        "Index into mplsTunnelTable."
   SYNTAX  Integer32 (1..65535)

MplsTunnelInstanceIndex ::=3D TEXTUAL-CONVENTION
   STATUS        current
   DESCRIPTION
        "Instance index into mplsTunnelTable."
   SYNTAX  Unsigned32 (0..65535)

MplsFTNIndex ::=3D TEXTUAL-CONVENTION
   STATUS              current
   DESCRIPTION
        "Index for an FEC-to-NHLFE (FTN) entry."
   SYNTAX              Integer32(1..2147483647)

MplsFTNIndexOrZero ::=3D TEXTUAL-CONVENTION
   STATUS              current
   DESCRIPTION
        "Index for an FTN entry or zero."
   SYNTAX              Integer32(0..2147483647)

END


5. Security Considerations
  =20
   This memo defines textual conventions and object identities
   for use in MPLS MIB modules. Security issues for these MIB
   modules are addressed in the memos defining those modules.


6. References
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for
                 TCP/IP-based Internets", STD 16, RFC 1155,
                 May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J.
                 Davin, "Simple Network Management Protocol",
                 STD 15, RFC 1157, May 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", STD 16, RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps
                 for use with the SNMP", RFC 1215, March
                 1991.



Nadeau et al              Expires February 2002              [Page 9]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Introduction to Community-based
                 SNMPv2", RFC 1901, January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Protocol Operations for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1905, January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Transport Mappings for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1906, January 1996.
  =20
   [RFC2119]     Bradner, S., "Key words for use in RFCs to
                 Indicate Requirement Levels", BCP 14, RFC
                 2119, March 1997.
  =20
   [RFC2514]     Noto, et. al., "Definitions of Textual
                 Conventions and OBJECT-IDENTITIES for ATM
                 Management", RFC 2514, Feb. 1999
  =20
   [RFC2570]     Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction to Version 3 of the
                 Internet-standard Network Management
                 Framework", RFC 2570, April 1999.
  =20
   [RFC2571]     Harrington, D., Presuhn, R., and B. Wijnen,
                 "An Architecture for Describing SNMP
                 Management Frameworks", RFC 2571, April
                 1999.
  =20
   [RFC2572]     Case, J., Harrington D., Presuhn R., and B.
                 Wijnen, "Message Processing and Dispatching
                 for the Simple Network Management Protocol
                 (SNMP)", RFC 2572, April 1999.
  =20
   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2573, April 1999.
  =20
   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based
                 Security Model (USM) for version 3 of the
                 Simple Network Management Protocol
                 (SNMPv3)", RFC 2574, April 1999.
  =20
   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie,
                 "View-based Access Control Model (VACM) for
                 the Simple Network Management Protocol
                 (SNMP)", RFC 2575, April 1999.



Nadeau et al              Expires February 2002             [Page 10]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



  =20
   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Structure of Management Information Version
                 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  =20
   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Textual Conventions for SMIv2", STD 58, RFC
                 2579, April 1999.
  =20
   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Conformance Statements for SMIv2", STD 58,
                 RFC 2580, April 1999.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching
                 Architecture", RFC 3031, August 1999.
  =20
   [RFC3032]     Rosen, E., Rekhter, Y., Tappan, D.,
                 Farinacci, D., Federokow, G., Li, T., and A.
                 Conta, "MPLS Label Stack Encoding", RFC
                 3032, January 2001.
  =20
   [RFC3034]     Conta, A., Doolan, P., Malis, A., "Use of
                 Label Switching on Frame Relay Networks
                 Specification", RFC 3034, January 2001.
  =20
   [RFC3035]     Davie, B., Lawrence, J., McCloghrie, K.,
                 Rosen, E., Swallow, G., Rekhter, Y., and P.
                 Doolan, "MPLS using LDP and ATM VC
                 switching", RFC 3035, January 2001.
  =20
   [RFC3036]     Anderson, L., Doolan, P., Feldman, N.,
                 Fredette, A., and B. Thomas, "LDP
                 Specification", RFC 3036, January 2001.
  =20
   [Assigned]    Reynolds, J., and J. Postel, "Assigned
                 Numbers", RFC 1700, October 1994. See also:
                 http://www.isi.edu/in-
                 notes/iana/assignments/smi-numbers
  =20
   [RSVPTE]      Awduche, D., Berger, L., Gan, D., Li, T.,
                 Srinivasan, V., Swallow, G., RSVP-TE:
                 Extensions to RSVP for LSP Tunnels, draft-
                 ietf-mpls-rsvp-lsp-tunnel-08.txt, February
                 2001.
  =20
   [CRLDP]       Jamoussi, B., Aboul-Magd, O., Andersson, L.,



Nadeau et al              Expires February 2002             [Page 11]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



                 Ashwood-Smith, P., Hellstrand, F., Sundell,
                 K., Callon, R., Dantu, R., Wu, L., Doolan,
                 P., Worster, T., Feldman, N., Fredette, A.,
                 Girish, M., Gray, E., Halpern, J., Heinanen,
                 J., Kilty, T., Malis, A., Vaananen, P.,
                 Constraint-Based LSP Setup using LDP, draft-
                 ietf-mpls-cr-ldp-05.txt,  February 2001."


7. Authors' Addresses

   Thomas D. Nadeau
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: tnadeau@cisco.com
  =20
   Joan Cucchiara
   Crescent Networks
   900 Chelmsford Street
   Lowell, MA  01851
   Phone: +1-978-275-3183
   email: jcucchiara@crescentnetworks.com
  =20
   Cheenu Srinivasan
   Alphion Corp.
   4 Industrial Way West
   Eatontown, NJ 07724
   Phone: +1-732-676-7066
   Email: cheenu@alphion.com
  =20
   Arun Viswanathan
   Force10 Networks, Inc.
   1440 McCarthy Blvd
   Milpitas, CA 95035
   Phone: +1-408-571-3516
   Email: arun@force10networks.com
  =20
   Hans Sjostrand
   ipUnplugged
   P.O. Box 101 60
   S-121 28 Stockholm, Sweden
   Phone: +46-8-725-5930
   Email: hans@ipunplugged.com


8. Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights



Nadeau et al              Expires February 2002             [Page 12]
=0C
IETF Draft                   MPLS TC MIB                  August 2001



   Reserved.
  =20
   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.
  =20
   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.


























Nadeau et al              Expires February 2002             [Page 13]

------=_NextPart_000_0000_01C12712.817752E0
Content-Type: text/plain;
	name="draft-ietf-mpls-ftn-mib-02.txt"
Content-Disposition: attachment;
	filename="draft-ietf-mpls-ftn-mib-02.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                                  Thomas D. Nadeau
Internet Draft                                      Cisco Systems, Inc.
Expires: February 2002                                                =20
                                                      Cheenu Srinivasan
                                                          Alphion Corp.
                                                                      =20
                                                       Arun Viswanathan
                                                 Force10 Networks, Inc.
                                                                      =20
                                                            August 2001
                                   =20
                                   =20
         Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN)
                       Management Information Base
                                   =20
                     draft-ietf-mpls-ftn-mib-02.txt
                                   =20
                                   =20


Status of this Memo
  =20
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.
  =20
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract
  =20
   This memo defines an experimental portion of the Management
   Information Base  (MIB) for use with network management protocols in
   the Internet community.  In particular, it describes managed objects
   for defining FEC-to-NHLFE mapping and corresponding actions for use
   with Multiprotocol Label Switching (MPLS).


Table of Contents

   Status of this Memo                                               1



Nadeau et al.              Expires February 2002             [Page 1]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   Abstract                                                          1
   1. Introduction                                                   2
   2. Terminology                                                    2
   3. The SNMP Management Framework                                  2
    3.1. Object Definitions                                          3
   4. Motivation                                                     4
   5. Outline                                                        4
    5.1. mplsFTNTable                                                4
    5.2. mplsFTNMapTable                                             5
    5.3. mplsFTNPerfTable                                            5
   6. Example                                                        6
   7. The Use of RowPointer                                          7
   8. MPLS FTN MIB Definitions                                       8
   9. Security Considerations                                       21
   10. References                                                   22
   11. Authors' Addresses                                           23
   12. Acknowledgements                                             24
   13. Full Copyright Statement                                     24
  =20


1. Introduction
  =20
   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   the Internet community. In particular, it describes managed objects
   for specifying FEC to NHLFE mappings and corresponding actions for
   Multiprotocol Label Switching (MPLS).
  =20
   This memo does not, in its draft form, specify a standard for the
   Internet community.


2. Terminology
  =20
   Although all of the terminology used in this draft is either covered
   in the MPLS Architecture [RFC3031] or in the SNMP Architecture
   [RFC2271], it is informational to define some immediately pertinent
   acronyms/terminology here.
     =20
      MPLS  Multi-Protocol Label Switching
      FEC   Forwarding Equivalency Class
      NHLFE Next-Hop Label Forwarding Entry
      FTN   FEC-to-NHLFE
      MIB   Management Information Base


3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five major



Nadeau et al.              Expires February 2002             [Page 2]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   components:
  =20
   -  An overall architecture, described in RFC 2271 [RFC2271].
  =20
   -  Mechanisms for describing and naming objects and events for the
      purpose of management.  The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in RFC
      1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].  The
      second version, called SMIv2, is described in RFC 1902 [RFC1902],
      RFC 1903 [RFC1903] and RFC 1904 [RFC1904].
  =20
   -  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in RFC 1157 [RFC1157].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2 and described in RFC 1901 [RFC1901]
      and RFC 1906 [RFC1906].  The third version of the message
      protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
      RFC 2272 [RFC2272] and RFC 2274 [RFC2274].
  =20
   -  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in RFC 1157 [RFC1157].  A second set of protocol
      operations and associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2273 [RFC2273]
      and the view-based access control mechanism described in RFC 2275
      [RFC2275].  Managed objects are accessed via a virtual
      information store, termed the Management Information Base or MIB.
      Objects in the MIB are defined using the mechanisms defined in
      the SMI.  This memo specifies a MIB module that is compliant to
      the RFC1902.  A MIB conforming to the RFC1155 can be produced
      through the appropriate translations.  The resulting translated
      MIB must be semantically equivalent, except where objects or
      events are omitted because no translation is possible (use of
      Counter64).  Some machine-readable information in RFC1902 will be
      converted into textual descriptions in RFC1155 during the
      translation process.  However, this loss of machine-readable
      information is not considered to change the semantics of the MIB.


3.1.  Object Definitions
  =20
   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a



Nadeau et al.              Expires February 2002             [Page 3]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to also refer to
   the object type.


4. Motivation
  =20
   On the ingress of an MPLS network, packets entering the MPLS domain
   are assigned to a FEC. Those packets belonging to a forwarding
   equivalency class (FEC) are associated with an NHLFE via the FEC-to-
   NHLFE (FTN) mapping [MPLS-Arch].  This relationship defines how the
   LSR will impose MPLS labels onto an incoming flow. It is important to
   note that an NHLFE entry can redirect packets to either an LSP or a
   Traffic Engineered (TE) Tunnel.
  =20
   Conceptually,   some  of  the  FTN  table  functionality   could   be
   implemented using the Forwarding Information Base (FIB)  to  map  all
   packets  destined for a prefix to an LSP. However,  this  mapping  is
   coarse in nature.
  =20
   Similar functionality is already being used in other contexts, such
   as security filters, access filters, and for RSVP flow
   identification.  All of these require various combinations of
   matching based on IP header and upper-layer header information to
   identify packets for a particular treatment.  When packets match a
   particular rule, a corresponding action is executed against those
   packets.  For example, two popular actions to take when a successful
   match is detected are allowing the packet to be forwarded or to
   discard it.  However, other actions are possible, such as modifying
   the TOS byte, or redirecting a packet to a particular outgoing
   interface.
  =20
   This draft attempts to consolidate the various matching requirements
   and associated action options needed for MPLS into a single
   specification.


5. Outline
  =20
   This MIB resides on any LSR which does the FEC-to-NHLFE mapping in
   order to map traffic into the MPLS domain. The MIB consists of three
   tables: The mplsFTNTable defines the rule base against which incoming
   packets are matched and actions taken on matching packets. The
   mplsFTNMapTable defines the application of these rules to specific
   interfaces. Finally, the mplsFTNPerfTable provides performance
   counters for every FTN entry that is active, on a per-interface
   basis.


5.1.  mplsFTNTable



Nadeau et al.              Expires February 2002             [Page 4]
=0C
Internet Draft                MPLS FTN MIB                August 2001



  =20
   This table allows FEC to NHLFE mappings to be specified.  Each entry
   in this table defines a rule to be applied to incoming packets (on
   interfaces that the FTN entry is activated on using mplsFTNMapTable;
   see Section 5.2) and an action to be taken on matching packets.
   mplsFTNTable provides a 6-tuple matching and allows addresses, port
   ranges and the exp bits to be specified.  The action pointer points
   at either an MPLS LSR MIB [LSRMIB] mplsXCEntry when the NHLFE entry
   is a non-TE LSP, or it points at an mplsTunnelEntry in the MPLS TE
   MIB [TEMIB] if we wish to make the NHLFE the start of a TE tunnel.


5.2.  mplsFTNMapTable
  =20
   This table provides the capability to activate or map FTN entries
   defined in mplsFTNTable to specific interfaces in the system. FTN
   entries are compared with incoming packets in the order in which they
   are applied on an interface. For this reason, this table provides a
   mechanism to 'insert' an FTN entry between two existing FTN entries
   already applied on an interface.
  =20
   Using this linked-list structure, one can retrieve FTN entries in the
   order of application on a per-interface basis as follows:
  =20
   -  To determine the first FTN entry on an interface with index
      ifIndex perform a GETNEXT retrieval operation on
      mplsFTNMapIfIndex.ifIndex.0.0; the returned object, if one
      exists, is (say) mplsFTNMapIfIndex.ifIndex.0.n. Then the index of
      the first FTN entry applied on this interface is n.
  =20
   -  To determine the FTN entry applied after the one indexed by n
      perform a GETNEXT retrieval operation on
      mplsFTNMapIfIndex.ifIndex.n.0; the returned object, if one
      exists, is (say) mplsFTNMapIfIndex.ifIndex.n.m. Then the index of
      the next FTN entry applied on this interface is m.
  =20
   Use the above steps to retrieve all the applied FTN entries on a per-
   interface basis in application order. Note that the number of
   retrieval operations is the same as the number of applied FTN entries
   (i.e. the minimum number of GETNEXT operations needed using any
   indexing scheme).


5.3.  mplsFTNPerfTable
  =20
   This table provides performance counters for each FTN entry on a per-
   interface basis.  High capacity counters are provided for situations
   where 32-bit counters would wrap around too quickly.





Nadeau et al.              Expires February 2002             [Page 5]
=0C
Internet Draft                MPLS FTN MIB                August 2001



6. Example
  =20
   Suppose that we want to activate the following FTN entries.
   =20
    1. in ifIndex=3D1, dest addr=3D1.2.0.0 -> out ifIndex=3D50, out =
label=3D150
   =20
    2. in ifIndex=3D1, dest addr=3D1.3.0.0 -> tunnel=3D4
  =20
   In this case the tables will look as follows in the MPLS LSR, TE and
   FTN MIBs (we only show fields of interest in each case).
  =20
   Entry #1 results in the following.
  =20
   In mplsFTNTable:
   {
      mplsFTNIndex =3D 1,
      mplsFTNDescr =3D "FTN-1 for net 1.2.0.0",
      mplsFTNMask =3D 0x40, -- destination address only
      mplsFTNAddrType =3D ipv4,
      mplsFTNDestIpv4AddrMin =3D 1.2.0.0,
      mplsFTNDestIpv4AddrMax =3D 1.2.0.0,
      mplsFTNActionType =3D redirectLsp,
      mplsFTNActionPointer =3D mplsXCIndex.2.0.0.3
   }
   We indicate the LSP to redirect packets to by setting
   mplsFTNActionPointer to the first column object of the XC entry
   corresponding to this LSP, in this case mplsXCIndex.2.0.0.3 which
   represents the following XC entry.
  =20
   In mplsXCTable:
   {
      mplsXCIndex =3D 2,
      mplsInSegmentIfIndex =3D 0, -- originating LSP
      mplsInSegmentLabel =3D 0, -- originating LSP
      mplsOutSegmentIndex =3D 3,
      mplsXCLabelStackIndex =3D 0
   }
   Note that mplsInSegmentIfIndex and mplsInSegmentLabel values used to
   index this XC entry are zero as is required for an originating LSP
   [LSRMIB].
  =20
   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex =3D 3,
      mplsOutSegmentIfIndex =3D 50,
      mplsOutSegmentPushTopLabel =3D true,
      mplsOutSegmentTopLabel =3D 150
   }
  =20
   In mplsFTNMapTable:



Nadeau et al.              Expires February 2002             [Page 6]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   {
      mplsFTNMapIfIndex =3D 1,
      mplsFTNPrevIndex =3D 0, -- first FTN entry on this interface
      mplsFTNMapCurrIndex =3D 1,
   }
  =20
   Entry #2 results in the following.
  =20
   In mplsFTNTable:
   {
      mplsFTNIndex =3D 2,
      mplsFTNDescr =3D "FTN-2 for net 1.2.0.0",
      mplsFTNMask =3D 0x40, -- destination address only
      mplsFTNAddrType =3D ipv4,
      mplsFTNDestIpv4AddrMin =3D 1.3.0.0,
      mplsFTNDestIpv4AddrMax =3D 1.3.0.0,
      mplsFTNActionType =3D redirectTunnel,
      -- We assume that the ingress and egress LSR IDs are 1.1.1.1 and
      -- 2.2.2.2 respectively for this tunnel.
      mplsFTNActionPointer =3D mplsTunnelIndex.4.0.1.1.1.1.2.2.2.2
   }
  =20
   In mplsTunnelTable:
   {
      mplsTunnelIndex =3D 4,
      mplsTunnelInstance =3D 0, -- primary tunnel
      mplsTunnelIngressLSRID =3D 1.1.1.1,
      mplsTunnelEgressLSRID =3D 2.2.2.2
   }
  =20
   In mplsFTNMapTable:
   {
      mplsFTNMapIfIndex =3D 1,
      mplsFTNPrevIndex =3D 1,
      mplsFTNMapCurrIndex =3D 2
   }


7. The Use of RowPointer
  =20
   RowPointer is a textual convention used to identify a conceptual row
   in an SNMP Table by pointing to one of its objects.  In this MIB, in
   mplsFTNTable, the RowPointer object mplsFTNActionPointer indicates
   the LSP or TE Tunnel to redirect packets matching an FTN entry to.
   This object MUST point to the first column of the appropriate
   conceptual row in order to allow the manager to find the appropriate
   corresponding entry in either the MPLS LSR MIB [LSRMIB] or MPLS TE
   MIB [TEMIB]. If this object returns zeroDotZero it implies that there
   is no currently defined action that is associated with that
   particular FTN entry.



Nadeau et al.              Expires February 2002             [Page 7]
=0C
Internet Draft                MPLS FTN MIB                August 2001





8. MPLS FTN MIB Definitions

MPLS-FTN-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   Integer32, Unsigned32, Counter32, experimental
      FROM SNMPv2-SMI
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
      FROM SNMPv2-CONF
   TEXTUAL-CONVENTION, TruthValue, RowStatus,
   StorageType, DisplayString
      FROM SNMPv2-TC
   InterfaceIndexOrZero
      FROM IF-MIB
   MplsTunnelIndex, MplsPortAddr, MplsFTNIndex,
   MplsFTNIndexOrZero
      FROM MPLS-TC-MIB
   InetAddressIPv4, InetAddressIPv6, InetAddressType
      FROM INET-ADDRESS-MIB;

mplsFTNMIB MODULE-IDENTITY
   LAST-UPDATED "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO
       "        Thomas D. Nadeau
        Postal: Cisco Systems, Inc.
                250 Apollo Drive
                Chelmsford, MA 01824
        Tel:    +1-978-244-3051
        Email:  tnadeau@cisco.com
      =20
                Cheenu Srinivasan
        Postal: Alphion Corp.
                4 Industrial Way West
                Eatontown, NJ 07724
                +1-732-676-7066
        Email:  cheenu@alphion.com
      =20
                Arun Viswanathan
        Postal: Force10 Networks, Inc.
                1440 McCarthy Blvd
                Milpitas, CA 95035
        Tel:    +1-408-571-3516
        Email:  arun@force10networks.com"
  =20
   DESCRIPTION
       "This MIB module contains managed object definitions for



Nadeau et al.              Expires February 2002             [Page 8]
=0C
Internet Draft                MPLS FTN MIB                August 2001



        specifying FEC to NHLFE (FTN) mappings and corresponding
        performance for MPLS."
      =20
   -- Revision history.
      =20
   REVISION
       "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   DESCRIPTION
       "Updates to example section, which was TBD in the
        previous version.
      =20
        Added expBits to mplsFTNMask.
      =20
        Added mplsFTNExpBits to mplsFTNEntry.
      =20
        General cleanup of editorial issues including updating
        references."
    REVISION
      "200104011200Z"  -- 1 April 2001 12:00:00 GMT
    DESCRIPTION
      "Updates based on MPLS working group feedback."
    REVISION
      "200009201200Z"  -- 20 September 2000 12:00:00 GMT
    DESCRIPTION
      "First draft version issued as MPLS working group document."
    REVISION
      "200007141200Z"  -- 14 July 2000 12:00:00 GMT
    DESCRIPTION
      "Updated draft version."
    REVISION
      "200003032030Z"  -- 03 March 2000 20:30:00 GMT
    DESCRIPTION
      "Initial draft version."
    ::=3D { experimental 111 }
  =20

-- Top-Level Components of this MIB.

mplsFTNNotifications OBJECT IDENTIFIER ::=3D { mplsFTNMIB 0 }
mplsFTNObjects       OBJECT IDENTIFIER ::=3D { mplsFTNMIB 1 }
mplsFTNConformance   OBJECT IDENTIFIER ::=3D { mplsFTNMIB 2 }


-- FTN table.

mplsFTNIndexNext OBJECT-TYPE
   SYNTAX              MplsFTNIndexOrZero
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION



Nadeau et al.              Expires February 2002             [Page 9]
=0C
Internet Draft                MPLS FTN MIB                August 2001



       "This  object contains the next appropriate value to  be
        used  for  mplsFTNIndex when creating  entries  in  the
        mplsFTNTable.  If the number of unassigned  entries  is
        exhausted, this object MUST return a value  of  0.   To
        obtain  the  mplsFTNIndex value for a  new  entry,  the
        manager   must   first  issue  a  management   protocol
        retrieval operation to obtain the current value of this
        object.   The agent should modify the value to  reflect
        the   next   unassigned  index  after  each   retrieval
        operation.  After a manager retrieves a value the agent
        will determine through its local policy when this index
        value will be made available for reuse."
   ::=3D { mplsFTNObjects 1 }

mplsFTNTable  OBJECT-TYPE
   SYNTAX          SEQUENCE OF MplsFTNEntry
   MAX-ACCESS      not-accessible
   STATUS          current
   DESCRIPTION
       "This table contains the currently defined FTN entries."
   ::=3D  { mplsFTNObjects  2 }

mplsFTNEntry  OBJECT-TYPE
   SYNTAX          MplsFTNEntry
   MAX-ACCESS      not-accessible
   STATUS          current
   DESCRIPTION
       "Each entry represents one FTN entry which defines a
        rule to compare against incoming packets and an action
        to be taken on matching packets."
   INDEX { mplsFTNIndex }
   ::=3D  { mplsFTNTable 1 }

MplsFTNEntry  ::=3D  SEQUENCE {
      mplsFTNIndex               MplsFTNIndex,
      mplsFTNRowStatus           RowStatus,
      mplsFTNDescr               DisplayString,
      mplsFTNApplied             TruthValue,
      mplsFTNMask                BITS,
      mplsFTNAddrType            InetAddressType,
      mplsFTNSourceIpv4AddrMin   InetAddressIPv4,
      mplsFTNSourceIpv6AddrMin   InetAddressIPv6,
      mplsFTNSourceIpv4AddrMax   InetAddressIPv4,
      mplsFTNSourceIpv6AddrMax   InetAddressIPv6,
      mplsFTNDestIpv4AddrMin     InetAddressIPv4,
      mplsFTNDestIpv6AddrMin     InetAddressIPv6,
      mplsFTNDestIpv4AddrMax     InetAddressIPv4,
      mplsFTNDestIpv6AddrMax     InetAddressIPv6,
      mplsFTNSourcePortMin       MplsPortAddr,
      mplsFTNSourcePortMax       MplsPortAddr,



Nadeau et al.             Expires February 2002             [Page 10]
=0C
Internet Draft                MPLS FTN MIB                August 2001



      mplsFTNDestPortMin         MplsPortAddr,
      mplsFTNDestPortMax         MplsPortAddr,
      mplsFTNProtocol            INTEGER,
      mplsFTNActionType          INTEGER,
      mplsFTNActionPointer       RowPointer,
      mplsFTNExpBits             Unsigned32,
      mplsFTNStorageType         StorageType
   }

mplsFTNIndex   OBJECT-TYPE
   SYNTAX              MplsFTNIndex
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "Unique index for the this entry."
   ::=3D { mplsFTNEntry 1 }

mplsFTNRowStatus OBJECT-TYPE
   SYNTAX              RowStatus
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Used for controlling the creation and deletion of this
        row."
   ::=3D { mplsFTNEntry 2 }

mplsFTNDescr   OBJECT-TYPE
   SYNTAX              DisplayString
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The description of this FTN entry. Due to the arbitrary
        indexing of this table, this object should contain some
        meaningful  text that an operator could use to  further
        distinguish entries in this table."
   ::=3D { mplsFTNEntry 3 }

mplsFTNApplied OBJECT-TYPE
   SYNTAX              TruthValue
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Indicates whether this FTN entry is being applied on
        any interface (using mplsFTNMapTable) or not."
   ::=3D { mplsFTNEntry 4 }

mplsFTNMask OBJECT-TYPE
   SYNTAX             BITS {
                       sourceAddr(0),
                       destAddr(1),



Nadeau et al.             Expires February 2002             [Page 11]
=0C
Internet Draft                MPLS FTN MIB                August 2001



                       sourcePort(2),
                       destPort(3),
                       protocol(4),
                       expBits(5)
                      }
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "This bit map indicates which of the fields described
        next, namely source address range, destination address
        range, source port range, destination port range,
        protocol and exp bits is active for this FTN entry. If
        a particular bit is inactive (i.e., set to zero) then
        the corresponding field in the packet is ignored for
        comparison purposes."
   ::=3D { mplsFTNEntry 5 }

mplsFTNAddrType OBJECT-TYPE
   SYNTAX             InetAddressType
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "Type  of  IP packet that this entry will match against.
        If  this  object has the value ipv4(1) then the objects
        in  this  entry of type InetAddressIpv6 MUST be ignored
        by  management  applications. If this  object  has  the
        value  ipv6(1) then the objects in this entry  of  type
        InetAddressIpv4   MUST   be   ignored   by   management
        applications."
   DEFVAL { ipv4 }
   ::=3D { mplsFTNEntry 6 }

mplsFTNSourceIpv4AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 7 }

mplsFTNSourceIpv6AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source address range - IPv6 version."
   ::=3D { mplsFTNEntry 8 }

mplsFTNSourceIpv4AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv4



Nadeau et al.             Expires February 2002             [Page 12]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The upper end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 9 }

mplsFTNSourceIpv6AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The upper end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 10 }

mplsFTNDestIpv4AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  lower  end  of destination address  range  -  IPv4
        version."
   ::=3D { mplsFTNEntry 11 }

mplsFTNDestIpv6AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  lower  end  of destination address  range  -  IPv6
        version."
   ::=3D { mplsFTNEntry 12 }

mplsFTNDestIpv4AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  upper  end  of destination address  range  -  IPv4
        version "
   ::=3D { mplsFTNEntry 13 }

mplsFTNDestIpv6AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  upper  end  of destination address  range  -  IPv6
        version "
   ::=3D { mplsFTNEntry 14 }




Nadeau et al.             Expires February 2002             [Page 13]
=0C
Internet Draft                MPLS FTN MIB                August 2001



mplsFTNSourcePortMin OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source port range."
   ::=3D { mplsFTNEntry 15 }

mplsFTNSourcePortMax OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of source port range "
   ::=3D { mplsFTNEntry 16 }

mplsFTNDestPortMin OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of the destination port range."
   ::=3D { mplsFTNEntry 17 }

mplsFTNDestPortMax OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of the destination port range."
   ::=3D { mplsFTNEntry 18 }

mplsFTNProtocol OBJECT-TYPE
   SYNTAX             INTEGER (0..65535)
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  contents  of  the protocol  ID  field  in  the  IP
        header."
   ::=3D { mplsFTNEntry 19 }

mplsFTNActionType OBJECT-TYPE
   SYNTAX          INTEGER {
                   drop(1),          -- discard this packet
                   redirectLsp(2),   -- redirect into LSP
                   redirectTunnel(3) -- redirect into tunnel
                }
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION



Nadeau et al.             Expires February 2002             [Page 14]
=0C
Internet Draft                MPLS FTN MIB                August 2001



       "The type of action to be taken on packets matching this
        FTN entry."
   ::=3D { mplsFTNEntry 20 }

mplsFTNActionPointer OBJECT-TYPE
   SYNTAX             RowPointer
   MAX-ACCESS         read-create
   STATUS             current
   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. For
        other values of mplsFTNActionType this object MUST be
        ignored by management applications. Agents SHOULD
        return zeroDotZero as the value of this object to
        indicate this to management stations."
   ::=3D { mplsFTNEntry 21 }

mplsFTNExpBits OBJECT-TYPE
   SYNTAX             Unsigned32 (0..127)
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "This object indicates the contents of the exp bits
        field to match incoming traffic against."
   ::=3D { mplsFTNEntry 22 }

mplsFTNStorageType OBJECT-TYPE
   SYNTAX             StorageType
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The storage type for this FTN entry."
   ::=3D { mplsFTNEntry 23 }

-- End of mplsFTNTable.


-- FTN to interface mapping table.

mplsFTNMapTable OBJECT-TYPE
   SYNTAX              SEQUENCE OF MplsFTNMapEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "This table contains objects for mapping previously
        defined entries in mplsFTNTable to interfaces."



Nadeau et al.             Expires February 2002             [Page 15]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   ::=3D  { mplsFTNObjects 3 }

mplsFTNMapEntry OBJECT-TYPE
   SYNTAX              MplsFTNMapEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "Each  entry  indicates the application of a  particular
        entry  as defined in mplsFTNTable on an interface.  The
        order of application of FTN entries on an interface  is
        the  order  in  which  they will  be  compared  against
        incoming packets for a match. Each entry of this  table
        is indexed by the interface index that the FTN entry is
        applied   to,   with  the  value  0  representing   all
        interfaces, the index of the previous FTN entry applied
        on  the  interface  and the index of  the  current  FTN
        entry. This linked-list structure allows FTN entries to
        be  inserted at arbitrary positions in the list. Agents
        MUST  NOT  allow  the same FTN entries  to  be  applied
        multiple  times to the same interface. Agents MUST  not
        allow  the  creation of rows in this  table  until  the
        corresponding rows are created in the mplsFTNTable.  If
        the  corresponding row in the FTN table  is  destroyed,
        the  agent  MUST destroy the corresponding  entries  in
        this table as well."
   INDEX {
         mplsFTNMapIfIndex,
         mplsFTNMapPrevIndex,
         mplsFTNMapCurrIndex
   }
   ::=3D  { mplsFTNMapTable 1 }

MplsFTNMapEntry  ::=3D  SEQUENCE {
      mplsFTNMapIfIndex      InterfaceIndexOrZero,
      mplsFTNMapPrevIndex    MplsFTNIndexOrZero,
      mplsFTNMapCurrIndex    MplsFTNIndex,
      mplsFTNMapRowStatus    RowStatus,
      mplsFTNMapStorageType  StorageType
   }

mplsFTNMapIfIndex OBJECT-TYPE
   SYNTAX              InterfaceIndexOrZero
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The interface index that this FTN entry is being
        applied to. Zero represents all interfaces."
   ::=3D { mplsFTNMapEntry 1 }
  =20
mplsFTNMapPrevIndex OBJECT-TYPE



Nadeau et al.             Expires February 2002             [Page 16]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   SYNTAX              MplsFTNIndexOrZero
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The index of the previous FTN entry that was applied to
        this interface. Zero indicates that this should be the
        first FTN entry in the list."
   ::=3D  { mplsFTNMapEntry 2 }

mplsFTNMapCurrIndex OBJECT-TYPE
   SYNTAX              MplsFTNIndex
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Index of the current FTN entry that is being applied to
        this interface."
   ::=3D  { mplsFTNMapEntry 3 }

mplsFTNMapRowStatus OBJECT-TYPE
   SYNTAX              RowStatus
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "For controlling the creation and deletion of this row."
   ::=3D  { mplsFTNMapEntry 4 }

mplsFTNMapStorageType OBJECT-TYPE
   SYNTAX              StorageType
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The storage type for this entry."
   ::=3D { mplsFTNMapEntry 5 }

-- End of mplsFTNMapTable

-- FTN entry performance table

mplsFTNPerfTable OBJECT-TYPE
   SYNTAX              SEQUENCE OF MplsFTNPerfEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "This table contains performance statistics on FTN
        entries on a per-interface basis."
   ::=3D { mplsFTNObjects 4 }

mplsFTNPerfEntry OBJECT-TYPE
   SYNTAX              MplsFTNPerfEntry
   MAX-ACCESS          not-accessible



Nadeau et al.             Expires February 2002             [Page 17]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   STATUS              current
   DESCRIPTION
       "Each entry contains performance information for the
        specified interface and FTN entry activated/mapped to
        this interface."
   INDEX  { mplsFTNMapIfIndex, mplsFTNMapCurrIndex }
   ::=3D  { mplsFTNPerfTable 1 }

MplsFTNPerfEntry  ::=3D  SEQUENCE {
      mplsFTNMatchedPackets          Counter32,
      mplsFTNMatchedOctets           Counter32,
      mplsFTNMatchedHCPackets        Counter64,
      mplsFTNMatchedHCOctets         Counter64
   }

mplsFTNMatchedPackets OBJECT-TYPE
   SYNTAX              Counter32
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of packets that matched the specified FTN entry
        if it is applied/mapped to the specified interface."
   ::=3D { mplsFTNPerfEntry 1 }

mplsFTNMatchedOctets OBJECT-TYPE
   SYNTAX              Counter32
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of octets that matched the specified FTN entry
        if it is applied/mapped to the specified interface."
   ::=3D { mplsFTNPerfEntry 2 }

mplsFTNMatchedHCPackets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "High-capacity counter for the number of packets that
        matched the specified FTN entry if it is applied/mapped
        to the specified interface."
   ::=3D { mplsFTNPerfEntry 3 }

mplsFTNMatchedHCOctets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "High-capacity counter for the number of octets that
        matched the specified FTN entry if it is applied/mapped



Nadeau et al.             Expires February 2002             [Page 18]
=0C
Internet Draft                MPLS FTN MIB                August 2001



        to the specified interface."
   ::=3D { mplsFTNPerfEntry 4 }

-- End of mplsFTNPerfTable

-- Module compliance.

mplsFTNGroups
   OBJECT IDENTIFIER ::=3D { mplsFTNConformance 1 }

mplsFTNCompliances
   OBJECT IDENTIFIER ::=3D { mplsFTNConformance 2 }

mplsFTNModuleCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Compliance statement for agents that support  the  MPLS
        FTN MIB."

MODULE -- this module

   -- The mandatory groups have to be implemented
   -- by all LSRs.  However, they may all be supported
   -- as read-only objects in the case where manual
   -- configuration is unsupported.

   MANDATORY-GROUPS {
      mplsFTNRuleGroup,
      mplsFTNMapGroup
   }

   GROUP mplsFTNHCPerfGroup
   DESCRIPTION
       "This  group is mandatory for those performance  entries
        for   which   the  object  mplsFTNMatchedHCOctets   and
        mplsFTNMatchedHCPackets  wrap around too quickly."
   ::=3D { mplsFTNCompliances 1 }

-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNIndexNext,
      mplsFTNRowStatus,
      mplsFTNDescr,
      mplsFTNApplied,
      mplsFTNMask,
      mplsFTNAddrType,
      mplsFTNSourceIpv4AddrMin,
      mplsFTNSourceIpv6AddrMin,
      mplsFTNSourceIpv4AddrMax,



Nadeau et al.             Expires February 2002             [Page 19]
=0C
Internet Draft                MPLS FTN MIB                August 2001



      mplsFTNSourceIpv6AddrMax,
      mplsFTNDestIpv4AddrMin,
      mplsFTNDestIpv6AddrMin,
      mplsFTNDestIpv4AddrMax,
      mplsFTNDestIpv6AddrMax,
      mplsFTNSourcePortMin,
      mplsFTNSourcePortMax,
      mplsFTNDestPortMin,
      mplsFTNDestPortMax,
      mplsFTNProtocol,
      mplsFTNActionType,
      mplsFTNActionPointer,
      mplsFTNExpBits,
      mplsFTNStorageType
   }
   STATUS current
   DESCRIPTION
       "Collection   of   objects   needed   for    MPLS    FTN
        configuration."
   ::=3D { mplsFTNGroups 1 }

mplsFTNMapGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMapIfIndex,
      mplsFTNMapPrevIndex,
      mplsFTNMapCurrIndex,
      mplsFTNMapRowStatus,
      mplsFTNMapStorageType
   }
   STATUS current
   DESCRIPTION
       "Collection of objects needed for MPLS FTN activation."
   ::=3D { mplsFTNGroups 2 }

mplsFTNPerfGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMatchedPackets,
      mplsFTNMatchedOctets
   }
   STATUS current
   DESCRIPTION
       "Collection  of objects needed for MPLS FTN  performance
        monitoring."
   ::=3D { mplsFTNGroups 3 }

mplsFTNHCPerfGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMatchedHCPackets,
      mplsFTNMatchedHCOctets
   }



Nadeau et al.             Expires February 2002             [Page 20]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   STATUS current
   DESCRIPTION
       "Collection  of objects needed for MPLS FTN  performance
        monitoring using high-capacity counters."
   ::=3D { mplsFTNGroups 4 }

END


9. Security Considerations
  =20
   It is clear that this MIB can be used for configuration of certain
   objects, and anything that can be configured can be incorrectly
   configured, with potentially disastrous results.
  =20
   At this writing, no security holes have been identified beyond those
   that SNMP Security [RFC2271] is itself intended to address. These
   relate to primarily controlled access to sensitive information and
   the ability to configure a device - or which might result from
   operator error, which is beyond the scope of any security
   architecture.
  =20
   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. The use of SNMP Version 3 is recommended over
   prior versions, for configuration control, as its security model is
   improved.
  =20
   SNMPv1 or SNMPv2 are by themselves not a secure environment. Even if
   the network itself is secure (for example by using IPSec [IPSEC]),
   there is no control as to who on the secure network is allowed to
   access and GET/SET (read/change/create/delete) the objects in this
   MIB. It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework. Specifically, the use
   of the User-based Security Model [RFC2274] and the View-based Access
   Control [RFC2275] is recommended. It is then a customer/user
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB is properly configured to give access to the
   objects only to those principals (users) that have legitimate rights
   to indeed GET or SET (change/create/delete) them.
  =20
   There are a number of managed objects in this MIB that may contain
   information that may be sensitive from a business perspective, in
   that they represent a customer's interface to the MPLS network.
   Allowing uncontrolled access to these objects could result in
   malicious and unwanted disruptions of network traffic or incorrect
   configurations for these customers. There are no objects that are



Nadeau et al.             Expires February 2002             [Page 21]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   particularly sensitive in their own right, such as passwords or
   monetary amounts.


10.   References
  =20
   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS
                 Label Switch Router Management Information Base Using
                 RFC1902", Internet Draft <draft-ietf-mpls-lsr-mib-
                 07.txt>, January 2001.
  =20
   [TEMIB]       Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
                 Traffic Engineering Management Information Base Using
                 RFC1902", Internet Draft <draft-ietf-mpls-te-mib-
                 06.txt>, March 2001.
  =20
   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C, Viswanathan,
                 A. and H. Sjostrand, "Definition of Textual
                 Conventions and OBJECT-IDENTITIES for Multi-Protocol
                 Label Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-01.txt>, August 2001.
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for TCP/IP-
                 based Internets", RFC 1155, May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J. Davin,
                 "Simple Network Management Protocol", RFC 1157, May
                 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps for use with
                 the SNMP", RFC 1215, March 1991.
  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Introduction to Community-based SNMPv2", RFC 1901,
                 January 1996.
  =20
   [RFC1902]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Structure of Management Information for Version 2 of
                 the Simple Network Management Protocol (SNMPv2)", RFC
                 1902, January 1996.
  =20
   [RFC1903]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Textual Conventions for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1903, SNMP
                 Research, Inc., Cisco Systems, Inc., January 1996.
  =20



Nadeau et al.             Expires February 2002             [Page 22]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   [RFC1904]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Conformance Statements for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1904,
                 January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Protocol Operations for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1905,
                 January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Transport Mappings for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1906,
                 January 1996.
  =20
   [RFC2233]     McCloghrie, K. and F. Kastenholtz, "The Interface
                 Group MIB Using RFC1902", RFC 2233, November 1997.
  =20
   [RFC2271]     Harrington, D., Presuhn, R., and B. Wijnen, "An
                 Architecture for Describing SNMP Management
                 Frameworks", RFC 2271, January 1998.
  =20
   [RFC2272]     Case, J., Harrington D., Presuhn R., and B. Wijnen,
                 "Message Processing and Dispatching for the Simple
                 Network Management Protocol (SNMP)", RFC 2272, January
                 1998.
  =20
   [RFC2273]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2273, January 1998
  =20
   [RFC2274]     Blumenthal, U., and B. Wijnen, "User-based Security
                 Model (USM) for version 3 of the Simple Network
                 Management Protocol (SNMPv3)", RFC 2274, January 1998.
  =20
   [RFC2275]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
                 based Access Control Model (VACM) for the Simple
                 Network Management Protocol (SNMP)", RFC 2275, January
                 1998.
  =20
   [RFC2851]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwaelder, "Textual Conventions for Internet
                 Network Addresses", RFC 2851, June 2000.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC
                 3031, January 2001.


11.   Authors' Addresses




Nadeau et al.             Expires February 2002             [Page 23]
=0C
Internet Draft                MPLS FTN MIB                August 2001



  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051
  Email: tnadeau@cisco.com

  Cheenu Srinivasan
  Alphion Corp.
  4 Industrial Way West
  Eatontown, NJ 07724
  Phone: +1-732-676-7066
  Email: cheenu@alphion.com

  Arun Viswanathan
  Force10 Networks, Inc.
  1440 McCarthy Blvd
  Milpitas, CA 95035
  Phone: +1-408-571-3516
  Email: arun@force10networks.com


12.   Acknowledgements
  =20
   We would like to thank Joan Cucchiara and Adrian Grise for their
   insightful comments and additions to this draft.


13.   Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights Reserved.
  =20
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
  =20
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK



Nadeau et al.             Expires February 2002             [Page 24]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















































Nadeau et al.             Expires February 2002             [Page 25]

------=_NextPart_000_0000_01C12712.817752E0--



From owner-mpls@UU.NET  Fri Aug 17 17:51:40 2001
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 RAA15757
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 17:51:39 -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 QQlcnf27988;
	Fri, 17 Aug 2001 21:52:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcnf06546
	for mpls-outgoing; Fri, 17 Aug 2001 21:52:08 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 QQlcnf06538
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 21:52:04 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 QQlcnf18160
	for <mpls@uu.net>; Fri, 17 Aug 2001 21:51:34 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcnf26723
	for <mpls@uu.net>; Fri, 17 Aug 2001 21:51:33 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 RAA10819 for <mpls@uu.net>; Fri, 17 Aug 2001 17:51:33 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA12075 for mpls@uu.net; Fri, 17 Aug 2001 17:51:09 -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 QQlcmr21264
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 18:29:35 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 QQlcmr23037
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:28:15 GMT
Received: from nwds0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQlcmr08985
	for <mpls@uu.net>; Fri, 17 Aug 2001 18:28:15 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Thu, 16 Aug 2001 10:58:31 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "MPLS Mailing List \(E-mail\)" <mpls@UU.NET>
Subject: draft-ietf-mpls-ftn-mib-02.txt posted
Date: Thu, 16 Aug 2001 11:26:30 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB0E7@OPTONT>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0012_01C12644.A3918860"
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.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C12644.A3918860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have just posted an update to the FTN MIB and it should appear
on the IETF site shortly. A copy is attached.

Cheenu

------=_NextPart_000_0012_01C12644.A3918860
Content-Type: text/plain;
	name="draft-ietf-mpls-ftn-mib-02.txt"
Content-Disposition: attachment;
	filename="draft-ietf-mpls-ftn-mib-02.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                                  Thomas D. Nadeau
Internet Draft                                      Cisco Systems, Inc.
Expires: February 2002                                                =20
                                                      Cheenu Srinivasan
                                                          Alphion Corp.
                                                                      =20
                                                       Arun Viswanathan
                                                 Force10 Networks, Inc.
                                                                      =20
                                                            August 2001
                                   =20
                                   =20
         Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN)
                       Management Information Base
                                   =20
                     draft-ietf-mpls-ftn-mib-02.txt
                                   =20
                                   =20


Status of this Memo
  =20
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.
  =20
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract
  =20
   This memo defines an experimental portion of the Management
   Information Base  (MIB) for use with network management protocols in
   the Internet community.  In particular, it describes managed objects
   for defining FEC-to-NHLFE mapping and corresponding actions for use
   with Multiprotocol Label Switching (MPLS).


Table of Contents

   Status of this Memo                                               1



Nadeau et al.              Expires February 2002             [Page 1]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   Abstract                                                          1
   1. Introduction                                                   2
   2. Terminology                                                    2
   3. The SNMP Management Framework                                  2
    3.1. Object Definitions                                          3
   4. Motivation                                                     4
   5. Outline                                                        4
    5.1. mplsFTNTable                                                4
    5.2. mplsFTNMapTable                                             5
    5.3. mplsFTNPerfTable                                            5
   6. Example                                                        6
   7. The Use of RowPointer                                          7
   8. MPLS FTN MIB Definitions                                       8
   9. Security Considerations                                       21
   10. References                                                   22
   11. Authors' Addresses                                           23
   12. Acknowledgements                                             24
   13. Full Copyright Statement                                     24
  =20


1. Introduction
  =20
   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   the Internet community. In particular, it describes managed objects
   for specifying FEC to NHLFE mappings and corresponding actions for
   Multiprotocol Label Switching (MPLS).
  =20
   This memo does not, in its draft form, specify a standard for the
   Internet community.


2. Terminology
  =20
   Although all of the terminology used in this draft is either covered
   in the MPLS Architecture [RFC3031] or in the SNMP Architecture
   [RFC2271], it is informational to define some immediately pertinent
   acronyms/terminology here.
     =20
      MPLS  Multi-Protocol Label Switching
      FEC   Forwarding Equivalency Class
      NHLFE Next-Hop Label Forwarding Entry
      FTN   FEC-to-NHLFE
      MIB   Management Information Base


3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five major



Nadeau et al.              Expires February 2002             [Page 2]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   components:
  =20
   -  An overall architecture, described in RFC 2271 [RFC2271].
  =20
   -  Mechanisms for describing and naming objects and events for the
      purpose of management.  The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in RFC
      1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215].  The
      second version, called SMIv2, is described in RFC 1902 [RFC1902],
      RFC 1903 [RFC1903] and RFC 1904 [RFC1904].
  =20
   -  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in RFC 1157 [RFC1157].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2 and described in RFC 1901 [RFC1901]
      and RFC 1906 [RFC1906].  The third version of the message
      protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
      RFC 2272 [RFC2272] and RFC 2274 [RFC2274].
  =20
   -  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in RFC 1157 [RFC1157].  A second set of protocol
      operations and associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2273 [RFC2273]
      and the view-based access control mechanism described in RFC 2275
      [RFC2275].  Managed objects are accessed via a virtual
      information store, termed the Management Information Base or MIB.
      Objects in the MIB are defined using the mechanisms defined in
      the SMI.  This memo specifies a MIB module that is compliant to
      the RFC1902.  A MIB conforming to the RFC1155 can be produced
      through the appropriate translations.  The resulting translated
      MIB must be semantically equivalent, except where objects or
      events are omitted because no translation is possible (use of
      Counter64).  Some machine-readable information in RFC1902 will be
      converted into textual descriptions in RFC1155 during the
      translation process.  However, this loss of machine-readable
      information is not considered to change the semantics of the MIB.


3.1.  Object Definitions
  =20
   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI.  In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name.  The object
   type together with an object instance serves to uniquely identify a



Nadeau et al.              Expires February 2002             [Page 3]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   specific instantiation of the object.  For human convenience, we
   often use a textual string, termed the descriptor, to also refer to
   the object type.


4. Motivation
  =20
   On the ingress of an MPLS network, packets entering the MPLS domain
   are assigned to a FEC. Those packets belonging to a forwarding
   equivalency class (FEC) are associated with an NHLFE via the FEC-to-
   NHLFE (FTN) mapping [MPLS-Arch].  This relationship defines how the
   LSR will impose MPLS labels onto an incoming flow. It is important to
   note that an NHLFE entry can redirect packets to either an LSP or a
   Traffic Engineered (TE) Tunnel.
  =20
   Conceptually,   some  of  the  FTN  table  functionality   could   be
   implemented using the Forwarding Information Base (FIB)  to  map  all
   packets  destined for a prefix to an LSP. However,  this  mapping  is
   coarse in nature.
  =20
   Similar functionality is already being used in other contexts, such
   as security filters, access filters, and for RSVP flow
   identification.  All of these require various combinations of
   matching based on IP header and upper-layer header information to
   identify packets for a particular treatment.  When packets match a
   particular rule, a corresponding action is executed against those
   packets.  For example, two popular actions to take when a successful
   match is detected are allowing the packet to be forwarded or to
   discard it.  However, other actions are possible, such as modifying
   the TOS byte, or redirecting a packet to a particular outgoing
   interface.
  =20
   This draft attempts to consolidate the various matching requirements
   and associated action options needed for MPLS into a single
   specification.


5. Outline
  =20
   This MIB resides on any LSR which does the FEC-to-NHLFE mapping in
   order to map traffic into the MPLS domain. The MIB consists of three
   tables: The mplsFTNTable defines the rule base against which incoming
   packets are matched and actions taken on matching packets. The
   mplsFTNMapTable defines the application of these rules to specific
   interfaces. Finally, the mplsFTNPerfTable provides performance
   counters for every FTN entry that is active, on a per-interface
   basis.


5.1.  mplsFTNTable



Nadeau et al.              Expires February 2002             [Page 4]
=0C
Internet Draft                MPLS FTN MIB                August 2001



  =20
   This table allows FEC to NHLFE mappings to be specified.  Each entry
   in this table defines a rule to be applied to incoming packets (on
   interfaces that the FTN entry is activated on using mplsFTNMapTable;
   see Section 5.2) and an action to be taken on matching packets.
   mplsFTNTable provides a 6-tuple matching and allows addresses, port
   ranges and the exp bits to be specified.  The action pointer points
   at either an MPLS LSR MIB [LSRMIB] mplsXCEntry when the NHLFE entry
   is a non-TE LSP, or it points at an mplsTunnelEntry in the MPLS TE
   MIB [TEMIB] if we wish to make the NHLFE the start of a TE tunnel.


5.2.  mplsFTNMapTable
  =20
   This table provides the capability to activate or map FTN entries
   defined in mplsFTNTable to specific interfaces in the system. FTN
   entries are compared with incoming packets in the order in which they
   are applied on an interface. For this reason, this table provides a
   mechanism to 'insert' an FTN entry between two existing FTN entries
   already applied on an interface.
  =20
   Using this linked-list structure, one can retrieve FTN entries in the
   order of application on a per-interface basis as follows:
  =20
   -  To determine the first FTN entry on an interface with index
      ifIndex perform a GETNEXT retrieval operation on
      mplsFTNMapIfIndex.ifIndex.0.0; the returned object, if one
      exists, is (say) mplsFTNMapIfIndex.ifIndex.0.n. Then the index of
      the first FTN entry applied on this interface is n.
  =20
   -  To determine the FTN entry applied after the one indexed by n
      perform a GETNEXT retrieval operation on
      mplsFTNMapIfIndex.ifIndex.n.0; the returned object, if one
      exists, is (say) mplsFTNMapIfIndex.ifIndex.n.m. Then the index of
      the next FTN entry applied on this interface is m.
  =20
   Use the above steps to retrieve all the applied FTN entries on a per-
   interface basis in application order. Note that the number of
   retrieval operations is the same as the number of applied FTN entries
   (i.e. the minimum number of GETNEXT operations needed using any
   indexing scheme).


5.3.  mplsFTNPerfTable
  =20
   This table provides performance counters for each FTN entry on a per-
   interface basis.  High capacity counters are provided for situations
   where 32-bit counters would wrap around too quickly.





Nadeau et al.              Expires February 2002             [Page 5]
=0C
Internet Draft                MPLS FTN MIB                August 2001



6. Example
  =20
   Suppose that we want to activate the following FTN entries.
   =20
    1. in ifIndex=3D1, dest addr=3D1.2.0.0 -> out ifIndex=3D50, out =
label=3D150
   =20
    2. in ifIndex=3D1, dest addr=3D1.3.0.0 -> tunnel=3D4
  =20
   In this case the tables will look as follows in the MPLS LSR, TE and
   FTN MIBs (we only show fields of interest in each case).
  =20
   Entry #1 results in the following.
  =20
   In mplsFTNTable:
   {
      mplsFTNIndex =3D 1,
      mplsFTNDescr =3D "FTN-1 for net 1.2.0.0",
      mplsFTNMask =3D 0x40, -- destination address only
      mplsFTNAddrType =3D ipv4,
      mplsFTNDestIpv4AddrMin =3D 1.2.0.0,
      mplsFTNDestIpv4AddrMax =3D 1.2.0.0,
      mplsFTNActionType =3D redirectLsp,
      mplsFTNActionPointer =3D mplsXCIndex.2.0.0.3
   }
   We indicate the LSP to redirect packets to by setting
   mplsFTNActionPointer to the first column object of the XC entry
   corresponding to this LSP, in this case mplsXCIndex.2.0.0.3 which
   represents the following XC entry.
  =20
   In mplsXCTable:
   {
      mplsXCIndex =3D 2,
      mplsInSegmentIfIndex =3D 0, -- originating LSP
      mplsInSegmentLabel =3D 0, -- originating LSP
      mplsOutSegmentIndex =3D 3,
      mplsXCLabelStackIndex =3D 0
   }
   Note that mplsInSegmentIfIndex and mplsInSegmentLabel values used to
   index this XC entry are zero as is required for an originating LSP
   [LSRMIB].
  =20
   In mplsOutSegmentTable:
   {
      mplsOutSegmentIndex =3D 3,
      mplsOutSegmentIfIndex =3D 50,
      mplsOutSegmentPushTopLabel =3D true,
      mplsOutSegmentTopLabel =3D 150
   }
  =20
   In mplsFTNMapTable:



Nadeau et al.              Expires February 2002             [Page 6]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   {
      mplsFTNMapIfIndex =3D 1,
      mplsFTNPrevIndex =3D 0, -- first FTN entry on this interface
      mplsFTNMapCurrIndex =3D 1,
   }
  =20
   Entry #2 results in the following.
  =20
   In mplsFTNTable:
   {
      mplsFTNIndex =3D 2,
      mplsFTNDescr =3D "FTN-2 for net 1.2.0.0",
      mplsFTNMask =3D 0x40, -- destination address only
      mplsFTNAddrType =3D ipv4,
      mplsFTNDestIpv4AddrMin =3D 1.3.0.0,
      mplsFTNDestIpv4AddrMax =3D 1.3.0.0,
      mplsFTNActionType =3D redirectTunnel,
      -- We assume that the ingress and egress LSR IDs are 1.1.1.1 and
      -- 2.2.2.2 respectively for this tunnel.
      mplsFTNActionPointer =3D mplsTunnelIndex.4.0.1.1.1.1.2.2.2.2
   }
  =20
   In mplsTunnelTable:
   {
      mplsTunnelIndex =3D 4,
      mplsTunnelInstance =3D 0, -- primary tunnel
      mplsTunnelIngressLSRID =3D 1.1.1.1,
      mplsTunnelEgressLSRID =3D 2.2.2.2
   }
  =20
   In mplsFTNMapTable:
   {
      mplsFTNMapIfIndex =3D 1,
      mplsFTNPrevIndex =3D 1,
      mplsFTNMapCurrIndex =3D 2
   }


7. The Use of RowPointer
  =20
   RowPointer is a textual convention used to identify a conceptual row
   in an SNMP Table by pointing to one of its objects.  In this MIB, in
   mplsFTNTable, the RowPointer object mplsFTNActionPointer indicates
   the LSP or TE Tunnel to redirect packets matching an FTN entry to.
   This object MUST point to the first column of the appropriate
   conceptual row in order to allow the manager to find the appropriate
   corresponding entry in either the MPLS LSR MIB [LSRMIB] or MPLS TE
   MIB [TEMIB]. If this object returns zeroDotZero it implies that there
   is no currently defined action that is associated with that
   particular FTN entry.



Nadeau et al.              Expires February 2002             [Page 7]
=0C
Internet Draft                MPLS FTN MIB                August 2001





8. MPLS FTN MIB Definitions

MPLS-FTN-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   Integer32, Unsigned32, Counter32, experimental
      FROM SNMPv2-SMI
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
      FROM SNMPv2-CONF
   TEXTUAL-CONVENTION, TruthValue, RowStatus,
   StorageType, DisplayString
      FROM SNMPv2-TC
   InterfaceIndexOrZero
      FROM IF-MIB
   MplsTunnelIndex, MplsPortAddr, MplsFTNIndex,
   MplsFTNIndexOrZero
      FROM MPLS-TC-MIB
   InetAddressIPv4, InetAddressIPv6, InetAddressType
      FROM INET-ADDRESS-MIB;

mplsFTNMIB MODULE-IDENTITY
   LAST-UPDATED "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO
       "        Thomas D. Nadeau
        Postal: Cisco Systems, Inc.
                250 Apollo Drive
                Chelmsford, MA 01824
        Tel:    +1-978-244-3051
        Email:  tnadeau@cisco.com
      =20
                Cheenu Srinivasan
        Postal: Alphion Corp.
                4 Industrial Way West
                Eatontown, NJ 07724
                +1-732-676-7066
        Email:  cheenu@alphion.com
      =20
                Arun Viswanathan
        Postal: Force10 Networks, Inc.
                1440 McCarthy Blvd
                Milpitas, CA 95035
        Tel:    +1-408-571-3516
        Email:  arun@force10networks.com"
  =20
   DESCRIPTION
       "This MIB module contains managed object definitions for



Nadeau et al.              Expires February 2002             [Page 8]
=0C
Internet Draft                MPLS FTN MIB                August 2001



        specifying FEC to NHLFE (FTN) mappings and corresponding
        performance for MPLS."
      =20
   -- Revision history.
      =20
   REVISION
       "200108161200Z"  -- 16 August 2001 12:00:00 GMT
   DESCRIPTION
       "Updates to example section, which was TBD in the
        previous version.
      =20
        Added expBits to mplsFTNMask.
      =20
        Added mplsFTNExpBits to mplsFTNEntry.
      =20
        General cleanup of editorial issues including updating
        references."
    REVISION
      "200104011200Z"  -- 1 April 2001 12:00:00 GMT
    DESCRIPTION
      "Updates based on MPLS working group feedback."
    REVISION
      "200009201200Z"  -- 20 September 2000 12:00:00 GMT
    DESCRIPTION
      "First draft version issued as MPLS working group document."
    REVISION
      "200007141200Z"  -- 14 July 2000 12:00:00 GMT
    DESCRIPTION
      "Updated draft version."
    REVISION
      "200003032030Z"  -- 03 March 2000 20:30:00 GMT
    DESCRIPTION
      "Initial draft version."
    ::=3D { experimental 111 }
  =20

-- Top-Level Components of this MIB.

mplsFTNNotifications OBJECT IDENTIFIER ::=3D { mplsFTNMIB 0 }
mplsFTNObjects       OBJECT IDENTIFIER ::=3D { mplsFTNMIB 1 }
mplsFTNConformance   OBJECT IDENTIFIER ::=3D { mplsFTNMIB 2 }


-- FTN table.

mplsFTNIndexNext OBJECT-TYPE
   SYNTAX              MplsFTNIndexOrZero
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION



Nadeau et al.              Expires February 2002             [Page 9]
=0C
Internet Draft                MPLS FTN MIB                August 2001



       "This  object contains the next appropriate value to  be
        used  for  mplsFTNIndex when creating  entries  in  the
        mplsFTNTable.  If the number of unassigned  entries  is
        exhausted, this object MUST return a value  of  0.   To
        obtain  the  mplsFTNIndex value for a  new  entry,  the
        manager   must   first  issue  a  management   protocol
        retrieval operation to obtain the current value of this
        object.   The agent should modify the value to  reflect
        the   next   unassigned  index  after  each   retrieval
        operation.  After a manager retrieves a value the agent
        will determine through its local policy when this index
        value will be made available for reuse."
   ::=3D { mplsFTNObjects 1 }

mplsFTNTable  OBJECT-TYPE
   SYNTAX          SEQUENCE OF MplsFTNEntry
   MAX-ACCESS      not-accessible
   STATUS          current
   DESCRIPTION
       "This table contains the currently defined FTN entries."
   ::=3D  { mplsFTNObjects  2 }

mplsFTNEntry  OBJECT-TYPE
   SYNTAX          MplsFTNEntry
   MAX-ACCESS      not-accessible
   STATUS          current
   DESCRIPTION
       "Each entry represents one FTN entry which defines a
        rule to compare against incoming packets and an action
        to be taken on matching packets."
   INDEX { mplsFTNIndex }
   ::=3D  { mplsFTNTable 1 }

MplsFTNEntry  ::=3D  SEQUENCE {
      mplsFTNIndex               MplsFTNIndex,
      mplsFTNRowStatus           RowStatus,
      mplsFTNDescr               DisplayString,
      mplsFTNApplied             TruthValue,
      mplsFTNMask                BITS,
      mplsFTNAddrType            InetAddressType,
      mplsFTNSourceIpv4AddrMin   InetAddressIPv4,
      mplsFTNSourceIpv6AddrMin   InetAddressIPv6,
      mplsFTNSourceIpv4AddrMax   InetAddressIPv4,
      mplsFTNSourceIpv6AddrMax   InetAddressIPv6,
      mplsFTNDestIpv4AddrMin     InetAddressIPv4,
      mplsFTNDestIpv6AddrMin     InetAddressIPv6,
      mplsFTNDestIpv4AddrMax     InetAddressIPv4,
      mplsFTNDestIpv6AddrMax     InetAddressIPv6,
      mplsFTNSourcePortMin       MplsPortAddr,
      mplsFTNSourcePortMax       MplsPortAddr,



Nadeau et al.             Expires February 2002             [Page 10]
=0C
Internet Draft                MPLS FTN MIB                August 2001



      mplsFTNDestPortMin         MplsPortAddr,
      mplsFTNDestPortMax         MplsPortAddr,
      mplsFTNProtocol            INTEGER,
      mplsFTNActionType          INTEGER,
      mplsFTNActionPointer       RowPointer,
      mplsFTNExpBits             Unsigned32,
      mplsFTNStorageType         StorageType
   }

mplsFTNIndex   OBJECT-TYPE
   SYNTAX              MplsFTNIndex
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "Unique index for the this entry."
   ::=3D { mplsFTNEntry 1 }

mplsFTNRowStatus OBJECT-TYPE
   SYNTAX              RowStatus
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Used for controlling the creation and deletion of this
        row."
   ::=3D { mplsFTNEntry 2 }

mplsFTNDescr   OBJECT-TYPE
   SYNTAX              DisplayString
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The description of this FTN entry. Due to the arbitrary
        indexing of this table, this object should contain some
        meaningful  text that an operator could use to  further
        distinguish entries in this table."
   ::=3D { mplsFTNEntry 3 }

mplsFTNApplied OBJECT-TYPE
   SYNTAX              TruthValue
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Indicates whether this FTN entry is being applied on
        any interface (using mplsFTNMapTable) or not."
   ::=3D { mplsFTNEntry 4 }

mplsFTNMask OBJECT-TYPE
   SYNTAX             BITS {
                       sourceAddr(0),
                       destAddr(1),



Nadeau et al.             Expires February 2002             [Page 11]
=0C
Internet Draft                MPLS FTN MIB                August 2001



                       sourcePort(2),
                       destPort(3),
                       protocol(4),
                       expBits(5)
                      }
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "This bit map indicates which of the fields described
        next, namely source address range, destination address
        range, source port range, destination port range,
        protocol and exp bits is active for this FTN entry. If
        a particular bit is inactive (i.e., set to zero) then
        the corresponding field in the packet is ignored for
        comparison purposes."
   ::=3D { mplsFTNEntry 5 }

mplsFTNAddrType OBJECT-TYPE
   SYNTAX             InetAddressType
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "Type  of  IP packet that this entry will match against.
        If  this  object has the value ipv4(1) then the objects
        in  this  entry of type InetAddressIpv6 MUST be ignored
        by  management  applications. If this  object  has  the
        value  ipv6(1) then the objects in this entry  of  type
        InetAddressIpv4   MUST   be   ignored   by   management
        applications."
   DEFVAL { ipv4 }
   ::=3D { mplsFTNEntry 6 }

mplsFTNSourceIpv4AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 7 }

mplsFTNSourceIpv6AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source address range - IPv6 version."
   ::=3D { mplsFTNEntry 8 }

mplsFTNSourceIpv4AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv4



Nadeau et al.             Expires February 2002             [Page 12]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The upper end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 9 }

mplsFTNSourceIpv6AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The upper end of source address range - IPv4 version."
   ::=3D { mplsFTNEntry 10 }

mplsFTNDestIpv4AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  lower  end  of destination address  range  -  IPv4
        version."
   ::=3D { mplsFTNEntry 11 }

mplsFTNDestIpv6AddrMin OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  lower  end  of destination address  range  -  IPv6
        version."
   ::=3D { mplsFTNEntry 12 }

mplsFTNDestIpv4AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv4
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  upper  end  of destination address  range  -  IPv4
        version "
   ::=3D { mplsFTNEntry 13 }

mplsFTNDestIpv6AddrMax OBJECT-TYPE
   SYNTAX             InetAddressIPv6
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  upper  end  of destination address  range  -  IPv6
        version "
   ::=3D { mplsFTNEntry 14 }




Nadeau et al.             Expires February 2002             [Page 13]
=0C
Internet Draft                MPLS FTN MIB                August 2001



mplsFTNSourcePortMin OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of source port range."
   ::=3D { mplsFTNEntry 15 }

mplsFTNSourcePortMax OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of source port range "
   ::=3D { mplsFTNEntry 16 }

mplsFTNDestPortMin OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The lower end of the destination port range."
   ::=3D { mplsFTNEntry 17 }

mplsFTNDestPortMax OBJECT-TYPE
   SYNTAX             MplsPortAddr
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The higher end of the destination port range."
   ::=3D { mplsFTNEntry 18 }

mplsFTNProtocol OBJECT-TYPE
   SYNTAX             INTEGER (0..65535)
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The  contents  of  the protocol  ID  field  in  the  IP
        header."
   ::=3D { mplsFTNEntry 19 }

mplsFTNActionType OBJECT-TYPE
   SYNTAX          INTEGER {
                   drop(1),          -- discard this packet
                   redirectLsp(2),   -- redirect into LSP
                   redirectTunnel(3) -- redirect into tunnel
                }
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION



Nadeau et al.             Expires February 2002             [Page 14]
=0C
Internet Draft                MPLS FTN MIB                August 2001



       "The type of action to be taken on packets matching this
        FTN entry."
   ::=3D { mplsFTNEntry 20 }

mplsFTNActionPointer OBJECT-TYPE
   SYNTAX             RowPointer
   MAX-ACCESS         read-create
   STATUS             current
   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. For
        other values of mplsFTNActionType this object MUST be
        ignored by management applications. Agents SHOULD
        return zeroDotZero as the value of this object to
        indicate this to management stations."
   ::=3D { mplsFTNEntry 21 }

mplsFTNExpBits OBJECT-TYPE
   SYNTAX             Unsigned32 (0..127)
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "This object indicates the contents of the exp bits
        field to match incoming traffic against."
   ::=3D { mplsFTNEntry 22 }

mplsFTNStorageType OBJECT-TYPE
   SYNTAX             StorageType
   MAX-ACCESS         read-create
   STATUS             current
   DESCRIPTION
       "The storage type for this FTN entry."
   ::=3D { mplsFTNEntry 23 }

-- End of mplsFTNTable.


-- FTN to interface mapping table.

mplsFTNMapTable OBJECT-TYPE
   SYNTAX              SEQUENCE OF MplsFTNMapEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "This table contains objects for mapping previously
        defined entries in mplsFTNTable to interfaces."



Nadeau et al.             Expires February 2002             [Page 15]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   ::=3D  { mplsFTNObjects 3 }

mplsFTNMapEntry OBJECT-TYPE
   SYNTAX              MplsFTNMapEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "Each  entry  indicates the application of a  particular
        entry  as defined in mplsFTNTable on an interface.  The
        order of application of FTN entries on an interface  is
        the  order  in  which  they will  be  compared  against
        incoming packets for a match. Each entry of this  table
        is indexed by the interface index that the FTN entry is
        applied   to,   with  the  value  0  representing   all
        interfaces, the index of the previous FTN entry applied
        on  the  interface  and the index of  the  current  FTN
        entry. This linked-list structure allows FTN entries to
        be  inserted at arbitrary positions in the list. Agents
        MUST  NOT  allow  the same FTN entries  to  be  applied
        multiple  times to the same interface. Agents MUST  not
        allow  the  creation of rows in this  table  until  the
        corresponding rows are created in the mplsFTNTable.  If
        the  corresponding row in the FTN table  is  destroyed,
        the  agent  MUST destroy the corresponding  entries  in
        this table as well."
   INDEX {
         mplsFTNMapIfIndex,
         mplsFTNMapPrevIndex,
         mplsFTNMapCurrIndex
   }
   ::=3D  { mplsFTNMapTable 1 }

MplsFTNMapEntry  ::=3D  SEQUENCE {
      mplsFTNMapIfIndex      InterfaceIndexOrZero,
      mplsFTNMapPrevIndex    MplsFTNIndexOrZero,
      mplsFTNMapCurrIndex    MplsFTNIndex,
      mplsFTNMapRowStatus    RowStatus,
      mplsFTNMapStorageType  StorageType
   }

mplsFTNMapIfIndex OBJECT-TYPE
   SYNTAX              InterfaceIndexOrZero
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The interface index that this FTN entry is being
        applied to. Zero represents all interfaces."
   ::=3D { mplsFTNMapEntry 1 }
  =20
mplsFTNMapPrevIndex OBJECT-TYPE



Nadeau et al.             Expires February 2002             [Page 16]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   SYNTAX              MplsFTNIndexOrZero
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The index of the previous FTN entry that was applied to
        this interface. Zero indicates that this should be the
        first FTN entry in the list."
   ::=3D  { mplsFTNMapEntry 2 }

mplsFTNMapCurrIndex OBJECT-TYPE
   SYNTAX              MplsFTNIndex
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "Index of the current FTN entry that is being applied to
        this interface."
   ::=3D  { mplsFTNMapEntry 3 }

mplsFTNMapRowStatus OBJECT-TYPE
   SYNTAX              RowStatus
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "For controlling the creation and deletion of this row."
   ::=3D  { mplsFTNMapEntry 4 }

mplsFTNMapStorageType OBJECT-TYPE
   SYNTAX              StorageType
   MAX-ACCESS          read-create
   STATUS              current
   DESCRIPTION
       "The storage type for this entry."
   ::=3D { mplsFTNMapEntry 5 }

-- End of mplsFTNMapTable

-- FTN entry performance table

mplsFTNPerfTable OBJECT-TYPE
   SYNTAX              SEQUENCE OF MplsFTNPerfEntry
   MAX-ACCESS          not-accessible
   STATUS              current
   DESCRIPTION
       "This table contains performance statistics on FTN
        entries on a per-interface basis."
   ::=3D { mplsFTNObjects 4 }

mplsFTNPerfEntry OBJECT-TYPE
   SYNTAX              MplsFTNPerfEntry
   MAX-ACCESS          not-accessible



Nadeau et al.             Expires February 2002             [Page 17]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   STATUS              current
   DESCRIPTION
       "Each entry contains performance information for the
        specified interface and FTN entry activated/mapped to
        this interface."
   INDEX  { mplsFTNMapIfIndex, mplsFTNMapCurrIndex }
   ::=3D  { mplsFTNPerfTable 1 }

MplsFTNPerfEntry  ::=3D  SEQUENCE {
      mplsFTNMatchedPackets          Counter32,
      mplsFTNMatchedOctets           Counter32,
      mplsFTNMatchedHCPackets        Counter64,
      mplsFTNMatchedHCOctets         Counter64
   }

mplsFTNMatchedPackets OBJECT-TYPE
   SYNTAX              Counter32
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of packets that matched the specified FTN entry
        if it is applied/mapped to the specified interface."
   ::=3D { mplsFTNPerfEntry 1 }

mplsFTNMatchedOctets OBJECT-TYPE
   SYNTAX              Counter32
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "Number of octets that matched the specified FTN entry
        if it is applied/mapped to the specified interface."
   ::=3D { mplsFTNPerfEntry 2 }

mplsFTNMatchedHCPackets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "High-capacity counter for the number of packets that
        matched the specified FTN entry if it is applied/mapped
        to the specified interface."
   ::=3D { mplsFTNPerfEntry 3 }

mplsFTNMatchedHCOctets OBJECT-TYPE
   SYNTAX              Counter64
   MAX-ACCESS          read-only
   STATUS              current
   DESCRIPTION
       "High-capacity counter for the number of octets that
        matched the specified FTN entry if it is applied/mapped



Nadeau et al.             Expires February 2002             [Page 18]
=0C
Internet Draft                MPLS FTN MIB                August 2001



        to the specified interface."
   ::=3D { mplsFTNPerfEntry 4 }

-- End of mplsFTNPerfTable

-- Module compliance.

mplsFTNGroups
   OBJECT IDENTIFIER ::=3D { mplsFTNConformance 1 }

mplsFTNCompliances
   OBJECT IDENTIFIER ::=3D { mplsFTNConformance 2 }

mplsFTNModuleCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Compliance statement for agents that support  the  MPLS
        FTN MIB."

MODULE -- this module

   -- The mandatory groups have to be implemented
   -- by all LSRs.  However, they may all be supported
   -- as read-only objects in the case where manual
   -- configuration is unsupported.

   MANDATORY-GROUPS {
      mplsFTNRuleGroup,
      mplsFTNMapGroup
   }

   GROUP mplsFTNHCPerfGroup
   DESCRIPTION
       "This  group is mandatory for those performance  entries
        for   which   the  object  mplsFTNMatchedHCOctets   and
        mplsFTNMatchedHCPackets  wrap around too quickly."
   ::=3D { mplsFTNCompliances 1 }

-- Units of conformance.
mplsFTNRuleGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNIndexNext,
      mplsFTNRowStatus,
      mplsFTNDescr,
      mplsFTNApplied,
      mplsFTNMask,
      mplsFTNAddrType,
      mplsFTNSourceIpv4AddrMin,
      mplsFTNSourceIpv6AddrMin,
      mplsFTNSourceIpv4AddrMax,



Nadeau et al.             Expires February 2002             [Page 19]
=0C
Internet Draft                MPLS FTN MIB                August 2001



      mplsFTNSourceIpv6AddrMax,
      mplsFTNDestIpv4AddrMin,
      mplsFTNDestIpv6AddrMin,
      mplsFTNDestIpv4AddrMax,
      mplsFTNDestIpv6AddrMax,
      mplsFTNSourcePortMin,
      mplsFTNSourcePortMax,
      mplsFTNDestPortMin,
      mplsFTNDestPortMax,
      mplsFTNProtocol,
      mplsFTNActionType,
      mplsFTNActionPointer,
      mplsFTNExpBits,
      mplsFTNStorageType
   }
   STATUS current
   DESCRIPTION
       "Collection   of   objects   needed   for    MPLS    FTN
        configuration."
   ::=3D { mplsFTNGroups 1 }

mplsFTNMapGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMapIfIndex,
      mplsFTNMapPrevIndex,
      mplsFTNMapCurrIndex,
      mplsFTNMapRowStatus,
      mplsFTNMapStorageType
   }
   STATUS current
   DESCRIPTION
       "Collection of objects needed for MPLS FTN activation."
   ::=3D { mplsFTNGroups 2 }

mplsFTNPerfGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMatchedPackets,
      mplsFTNMatchedOctets
   }
   STATUS current
   DESCRIPTION
       "Collection  of objects needed for MPLS FTN  performance
        monitoring."
   ::=3D { mplsFTNGroups 3 }

mplsFTNHCPerfGroup OBJECT-GROUP
   OBJECTS {
      mplsFTNMatchedHCPackets,
      mplsFTNMatchedHCOctets
   }



Nadeau et al.             Expires February 2002             [Page 20]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   STATUS current
   DESCRIPTION
       "Collection  of objects needed for MPLS FTN  performance
        monitoring using high-capacity counters."
   ::=3D { mplsFTNGroups 4 }

END


9. Security Considerations
  =20
   It is clear that this MIB can be used for configuration of certain
   objects, and anything that can be configured can be incorrectly
   configured, with potentially disastrous results.
  =20
   At this writing, no security holes have been identified beyond those
   that SNMP Security [RFC2271] is itself intended to address. These
   relate to primarily controlled access to sensitive information and
   the ability to configure a device - or which might result from
   operator error, which is beyond the scope of any security
   architecture.
  =20
   There are a number of management objects defined in this MIB that
   have a MAX-ACCESS clause of read-write and/or read-create. Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations. The use of SNMP Version 3 is recommended over
   prior versions, for configuration control, as its security model is
   improved.
  =20
   SNMPv1 or SNMPv2 are by themselves not a secure environment. Even if
   the network itself is secure (for example by using IPSec [IPSEC]),
   there is no control as to who on the secure network is allowed to
   access and GET/SET (read/change/create/delete) the objects in this
   MIB. It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework. Specifically, the use
   of the User-based Security Model [RFC2274] and the View-based Access
   Control [RFC2275] is recommended. It is then a customer/user
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB is properly configured to give access to the
   objects only to those principals (users) that have legitimate rights
   to indeed GET or SET (change/create/delete) them.
  =20
   There are a number of managed objects in this MIB that may contain
   information that may be sensitive from a business perspective, in
   that they represent a customer's interface to the MPLS network.
   Allowing uncontrolled access to these objects could result in
   malicious and unwanted disruptions of network traffic or incorrect
   configurations for these customers. There are no objects that are



Nadeau et al.             Expires February 2002             [Page 21]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   particularly sensitive in their own right, such as passwords or
   monetary amounts.


10.   References
  =20
   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS
                 Label Switch Router Management Information Base Using
                 RFC1902", Internet Draft <draft-ietf-mpls-lsr-mib-
                 07.txt>, January 2001.
  =20
   [TEMIB]       Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS
                 Traffic Engineering Management Information Base Using
                 RFC1902", Internet Draft <draft-ietf-mpls-te-mib-
                 06.txt>, March 2001.
  =20
   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C, Viswanathan,
                 A. and H. Sjostrand, "Definition of Textual
                 Conventions and OBJECT-IDENTITIES for Multi-Protocol
                 Label Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-01.txt>, August 2001.
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for TCP/IP-
                 based Internets", RFC 1155, May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J. Davin,
                 "Simple Network Management Protocol", RFC 1157, May
                 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps for use with
                 the SNMP", RFC 1215, March 1991.
  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Introduction to Community-based SNMPv2", RFC 1901,
                 January 1996.
  =20
   [RFC1902]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Structure of Management Information for Version 2 of
                 the Simple Network Management Protocol (SNMPv2)", RFC
                 1902, January 1996.
  =20
   [RFC1903]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Textual Conventions for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1903, SNMP
                 Research, Inc., Cisco Systems, Inc., January 1996.
  =20



Nadeau et al.             Expires February 2002             [Page 22]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   [RFC1904]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Conformance Statements for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1904,
                 January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Protocol Operations for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1905,
                 January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
                 "Transport Mappings for Version 2 of the Simple
                 Network Management Protocol (SNMPv2)", RFC 1906,
                 January 1996.
  =20
   [RFC2233]     McCloghrie, K. and F. Kastenholtz, "The Interface
                 Group MIB Using RFC1902", RFC 2233, November 1997.
  =20
   [RFC2271]     Harrington, D., Presuhn, R., and B. Wijnen, "An
                 Architecture for Describing SNMP Management
                 Frameworks", RFC 2271, January 1998.
  =20
   [RFC2272]     Case, J., Harrington D., Presuhn R., and B. Wijnen,
                 "Message Processing and Dispatching for the Simple
                 Network Management Protocol (SNMP)", RFC 2272, January
                 1998.
  =20
   [RFC2273]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2273, January 1998
  =20
   [RFC2274]     Blumenthal, U., and B. Wijnen, "User-based Security
                 Model (USM) for version 3 of the Simple Network
                 Management Protocol (SNMPv3)", RFC 2274, January 1998.
  =20
   [RFC2275]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
                 based Access Control Model (VACM) for the Simple
                 Network Management Protocol (SNMP)", RFC 2275, January
                 1998.
  =20
   [RFC2851]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwaelder, "Textual Conventions for Internet
                 Network Addresses", RFC 2851, June 2000.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC
                 3031, January 2001.


11.   Authors' Addresses




Nadeau et al.             Expires February 2002             [Page 23]
=0C
Internet Draft                MPLS FTN MIB                August 2001



  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051
  Email: tnadeau@cisco.com

  Cheenu Srinivasan
  Alphion Corp.
  4 Industrial Way West
  Eatontown, NJ 07724
  Phone: +1-732-676-7066
  Email: cheenu@alphion.com

  Arun Viswanathan
  Force10 Networks, Inc.
  1440 McCarthy Blvd
  Milpitas, CA 95035
  Phone: +1-408-571-3516
  Email: arun@force10networks.com


12.   Acknowledgements
  =20
   We would like to thank Joan Cucchiara and Adrian Grise for their
   insightful comments and additions to this draft.


13.   Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights Reserved.
  =20
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
  =20
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK



Nadeau et al.             Expires February 2002             [Page 24]
=0C
Internet Draft                MPLS FTN MIB                August 2001



   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















































Nadeau et al.             Expires February 2002             [Page 25]

------=_NextPart_000_0012_01C12644.A3918860--



From owner-mpls@UU.NET  Fri Aug 17 18:45:06 2001
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 SAA16519
	for <mpls-archive@lists.ietf.org>; Fri, 17 Aug 2001 18:45:06 -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 QQlcnj21997;
	Fri, 17 Aug 2001 22:46:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcnj29911
	for mpls-outgoing; Fri, 17 Aug 2001 22:45:21 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 QQlcnj29894
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 17 Aug 2001 22:45:10 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 QQlcni29809
	for <mpls@uu.net>; Fri, 17 Aug 2001 22:44:48 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQlcni24651
	for <mpls@uu.net>; Fri, 17 Aug 2001 22:44:47 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id <PKB297T4>; Fri, 17 Aug 2001 19:44:07 -0300
Message-ID: <72702AB72C89D511A9E70008C7917368010636EC@MSTELEFONICA3>
From: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
To: mpls@UU.NET
Subject: interconnection
Date: Fri, 17 Aug 2001 16:29:20 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

When Traffic Engineering is used in an MPLS network, 
LSP is signaled, and labels are distributed between the 
Ingress LSR and the egress LSR.

Now, if there are two networks N1 and N2 interconnected:

1) Is the signaling made at both network separately?
If this is fact. How is paquet routed from network N1 to N2?

2)Could be the signaling made from N1 ingress LSR to N2 egress LSR?


Thanks.

Sergio Fabris




From owner-mpls@UU.NET  Sat Aug 18 04:50:18 2001
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 EAA09723
	for <mpls-archive@lists.ietf.org>; Sat, 18 Aug 2001 04:50:18 -0400 (EDT)
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 QQlcox04269;
	Sat, 18 Aug 2001 08:51:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcox27625
	for mpls-outgoing; Sat, 18 Aug 2001 08:51:04 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 QQlcox27592
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 08:50:58 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 QQlcox07292
	for <mpls@UU.NET>; Sat, 18 Aug 2001 08:50:40 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 QQlcox03304
	for <mpls@UU.NET>; Sat, 18 Aug 2001 08:50:39 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7I8ob088958;
	Sat, 18 Aug 2001 01:50:38 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id BAA27407; Sat, 18 Aug 2001 01:50:37 -0700 (PDT)
Date: Sat, 18 Aug 2001 01:50:37 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200108180850.BAA27407@kummer.juniper.net>
To: mpls@UU.NET, mpour@celoxnetworks.com
Subject: Re: Interworking between CR-LDP and RSVP-TE
In-Reply-To: <6F2719D5300C624BBC5F69424EC0C2060FED81@celox-stl-ems2.celoxnetworks.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> What am I missing?

IS-IS OSPF interworking?

Kireeti.


From owner-mpls@UU.NET  Sat Aug 18 12:01:02 2001
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 MAA13616
	for <mpls-archive@lists.ietf.org>; Sat, 18 Aug 2001 12:01:02 -0400 (EDT)
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 QQlcqa10114;
	Sat, 18 Aug 2001 16:02:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcqa18704
	for mpls-outgoing; Sat, 18 Aug 2001 16:01:46 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 QQlcqa18528
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 16:01: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 QQlcqa06949
	for <mpls@uu.net>; Sat, 18 Aug 2001 16:00:29 GMT
Received: from polaris.lgsi.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.13.206])
	id QQlcqa07976
	for <mpls@uu.net>; Sat, 18 Aug 2001 16:00:28 GMT
Received: from lgsi.co.in ([202.54.13.195]) by
          polaris.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP
          id GI9U7300.MT2 for <mpls@uu.net>; Sat, 18 Aug 2001 21:39:03 +0530 
Message-ID: <3B7E91F3.F378212A@lgsi.co.in>
Date: Sat, 18 Aug 2001 21:34:03 +0530
From: "punithan" <punithan@lgsi.co.in>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Difference between LIB and FIB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
I have one doubt.What is the difference between LIB(Label Information
Base) and FIB(Forwarding Information Base).I will be thankful if
somebody helps me.
with regds,
MXJPunithan



From owner-mpls@UU.NET  Sat Aug 18 14:12:03 2001
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 OAA14498
	for <mpls-archive@lists.ietf.org>; Sat, 18 Aug 2001 14:12: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 QQlcqi21402;
	Sat, 18 Aug 2001 18:13:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcqi20936
	for mpls-outgoing; Sat, 18 Aug 2001 18:12:30 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 QQlcqi20931
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 18:12:28 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 QQlcqi00675
	for <mpls@uu.net>; Sat, 18 Aug 2001 18:12:09 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcqi19713
	for <mpls@uu.net>; Sat, 18 Aug 2001 18:12:09 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA05995 for mpls@uu.net; Sat, 18 Aug 2001 14:12:08 -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 QQlcqi20816
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 18:11:44 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 QQlcqi20536
	for <mpls@UU.NET>; Sat, 18 Aug 2001 18:11:29 GMT
Received: from che-cse-104.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQlcqi18476
	for <mpls@UU.NET>; Sat, 18 Aug 2001 18:11:29 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f7IIBLf24588; Sat, 18 Aug 2001 14:11:21 -0400 (EDT)
Date: Sat, 18 Aug 2001 14:11:21 -0400
From: Eric Osborne <eosborne@cisco.com>
To: punithan <punithan@lgsi.co.in>
Cc: mpls@UU.NET
Subject: Re: Difference between LIB and FIB
Message-ID: <20010818141121.C22583@che-cse-104.cisco.com>
References: <3B7E91F3.F378212A@lgsi.co.in>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <3B7E91F3.F378212A@lgsi.co.in>; from punithan@lgsi.co.in on Sat, Aug 18, 2001 at 09:34:03PM +0530
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Sat, Aug 18, 2001 at 09:34:03PM +0530, punithan wrote:
> Hi,
> I have one doubt.What is the difference between LIB(Label Information
> Base) and FIB(Forwarding Information Base).I will be thankful if
> somebody helps me.
> with regds,
> MXJPunithan

LIB = the thing you look up labels with (a labeled packet comes in,
you go to the LIB)

FIB = the thing you look up IP routes in (an unlabeled packet comes
in, you go to the FIB)




eric 



From owner-mpls@UU.NET  Sat Aug 18 16:07:01 2001
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 QAA15261
	for <mpls-archive@lists.ietf.org>; Sat, 18 Aug 2001 16:07:00 -0400 (EDT)
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 QQlcqq21762;
	Sat, 18 Aug 2001 20:07:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcqq04050
	for mpls-outgoing; Sat, 18 Aug 2001 20:07: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 QQlcqq03199
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 20:07:11 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 QQlcqq21794
	for <mpls@uu.net>; Sat, 18 Aug 2001 20:06:54 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcqq20594
	for <mpls@uu.net>; Sat, 18 Aug 2001 20:06:54 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA09748 for mpls@uu.net; Sat, 18 Aug 2001 16:06:52 -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 QQlcqq00793
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 20:06:31 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 QQlcqq22959
	for <mpls@UU.NET>; Sat, 18 Aug 2001 20:06:21 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 QQlcqq19898
	for <mpls@UU.NET>; Sat, 18 Aug 2001 20:06:21 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7IK4ND21175;
	Sat, 18 Aug 2001 13:04:23 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-130.cisco.com [144.254.46.131])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AAH08898;
	Sat, 18 Aug 2001 13:06:11 -0700 (PDT)
Message-ID: <3B7ECA2E.FC5A2A11@cisco.com>
Date: Sat, 18 Aug 2001 13:03:58 -0700
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: Eric Osborne <eosborne@cisco.com>
CC: punithan <punithan@lgsi.co.in>, mpls@UU.NET
Subject: Re: Difference between LIB and FIB
References: <3B7E91F3.F378212A@lgsi.co.in> <20010818141121.C22583@che-cse-104.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,

> the thing you look up labels with (a labeled packet comes in,
> you go to the LIB)

Not quite. That would be the LFIB.

LIB is just a control plane database where all received label binding
are being kept and maintained. In other words the question was tricky as
the author is asking about not comparable and not related elements next
to each other :).

R.

> Eric Osborne wrote:
> 
> On Sat, Aug 18, 2001 at 09:34:03PM +0530, punithan wrote:
> > Hi,
> > I have one doubt.What is the difference between LIB(Label Information
> > Base) and FIB(Forwarding Information Base).I will be thankful if
> > somebody helps me.
> > with regds,
> > MXJPunithan
> 
> LIB = the thing you look up labels with (a labeled packet comes in,
> you go to the LIB)
> 
> FIB = the thing you look up IP routes in (an unlabeled packet comes
> in, you go to the FIB)
> 
> eric



From owner-mpls@UU.NET  Sun Aug 19 00:03:57 2001
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 AAA20356
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 00:03:57 -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 QQlcrw20823;
	Sun, 19 Aug 2001 04:04:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcrw09042
	for mpls-outgoing; Sun, 19 Aug 2001 04:04: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 QQlcrw09025
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 04:04:11 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 QQlcrw20635
	for <mpls@uu.net>; Sun, 19 Aug 2001 04:03:48 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcrw19229
	for <mpls@uu.net>; Sun, 19 Aug 2001 04:03:47 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA26709
	for <mpls@uu.net>; Sun, 19 Aug 2001 00:03:46 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA12552 for mpls@uu.net; Sun, 19 Aug 2001 00:03:21 -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 QQlcps15960
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 18 Aug 2001 14:11:47 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 QQlcps22705
	for <mpls@UU.NET>; Sat, 18 Aug 2001 14:11:28 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 QQlcps23168
	for <mpls@UU.NET>; Sat, 18 Aug 2001 14:11:28 GMT
Received: from cs.columbia.edu ([172.16.167.235])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7IEBK099023;
	Sat, 18 Aug 2001 07:11:21 -0700 (PDT)
	(envelope-from pingpan@cs.columbia.edu)
Message-ID: <3B7E77C7.8030103@cs.columbia.edu>
Date: Sat, 18 Aug 2001 07:12:23 -0700
From: Ping Pan <pingpan@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; m18) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en
MIME-Version: 1.0
To: Alia Atlas <aatlas@avici.com>
CC: Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: draft minutes from London meeting
References: <4.1.20010817141518.00ae27e0@mailhost.avici.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

> 
> 
>> 
>> Ping Pan said his draft does support local repair. 
> 
Just saw this... did I say that? :-) The detour draft does support local 
repair.

- Ping



From owner-mpls@UU.NET  Sun Aug 19 02:10:15 2001
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 CAA07110
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 02:10:15 -0400 (EDT)
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 QQlcse17174;
	Sun, 19 Aug 2001 06:11:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcse05319
	for mpls-outgoing; Sun, 19 Aug 2001 06:10: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 QQlcse05312
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 06:10:40 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 QQlcse02414
	for <mpls@UU.NET>; Sun, 19 Aug 2001 06:10:18 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQlcse15705
	for <mpls@UU.NET>; Sun, 19 Aug 2001 06:10:17 GMT
Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7J6AGS19266
	for <mpls@UU.NET>; Sun, 19 Aug 2001 02:10:16 -0400 (EDT)
Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21)
	id <3XWZ5GBA>; Sun, 19 Aug 2001 02:10:08 -0400
Message-ID: <BD842AF47D98D311BFC400508B5EBB8D01CD2FB7@md6370exch003u.nse.lucent.com>
From: "Natale, Robert C (Bob)" <bnatale@lucent.com>
To: Cheenu Srinivasan <cheenu@alphion.com>
Cc: "MPLS Mailing List (E-mail)" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-ftn-mib-02.txt posted
Date: Sun, 19 Aug 2001 02:10:05 -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

Hi,

> I have just posted an update to the FTN MIB and it should appear
> on the IETF site shortly. A copy is attached.

The SNMP boilerplate you are using in Section 3 is out-of-date.
You can obtain the current text from:

   http://www.ops.ietf.org/mib-boilerplate.html

And you have at least one out-of-date SNMP ref in the Security
section (9) -- namely, 2271 should now be 2571.

These are both just editorial nits, I know.

Thanks,

BobN


From owner-mpls@UU.NET  Sun Aug 19 09:48:19 2001
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 JAA13000
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 09:48:19 -0400 (EDT)
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 QQlctj07507;
	Sun, 19 Aug 2001 13:48:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlctj24587
	for mpls-outgoing; Sun, 19 Aug 2001 13:48:30 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 QQlctj24582
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 13:48: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 QQlctj18201
	for <mpls@UU.NET>; Sun, 19 Aug 2001 13:47:06 GMT
Received: from polaris.lgsi.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.13.206])
	id QQlctj04930
	for <mpls@UU.NET>; Sun, 19 Aug 2001 13:47:04 GMT
Received: from lgsi.co.in ([202.54.13.195]) by
          polaris.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP
          id GIBIOP00.SIL for <mpls@UU.NET>; Sun, 19 Aug 2001 19:25:37 +0530 
Message-ID: <3B7FC436.948F0610@lgsi.co.in>
Date: Sun, 19 Aug 2001 19:20:46 +0530
From: "punithan" <punithan@lgsi.co.in>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mpls@UU.NET" <mpls@UU.NET>
Subject: RFCs 3034 and 3035
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
I would like to clarify a doubt. If  i am having only Ethernet and  POS
for my router.The  is there any need to implement the following RFCs
RFC 3034 - Use of Label Switching on Frame Relay Networks Specification
RFC 3035 - MPLS using LDP and ATM VC Switching
thanks and regds,
MXJPunithan




From owner-mpls@UU.NET  Sun Aug 19 10:21:27 2001
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 KAA13400
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 10:21:27 -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 QQlctl09908;
	Sun, 19 Aug 2001 14:22:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlctl16039
	for mpls-outgoing; Sun, 19 Aug 2001 14:21:50 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 QQlctl16031
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 14:21: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 QQlctl21009
	for <mpls@UU.NET>; Sun, 19 Aug 2001 14:21:03 GMT
Received: from polaris.lgsi.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.13.206])
	id QQlctl20588
	for <mpls@UU.NET>; Sun, 19 Aug 2001 14:21:01 GMT
Received: from lgsi.co.in ([202.54.13.195]) by
          polaris.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP
          id GIBK9900.Q03 for <mpls@UU.NET>; Sun, 19 Aug 2001 19:59:33 +0530 
Message-ID: <3B7FCC2B.48BF5BDA@lgsi.co.in>
Date: Sun, 19 Aug 2001 19:54:43 +0530
From: "punithan" <punithan@lgsi.co.in>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mpls@UU.NET" <mpls@UU.NET>
Subject: TE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
Can't we support TE with LDP(without implementing CR-LDP and RSVP-TE)?
with regds,
MXJPunithan



From owner-mpls@UU.NET  Sun Aug 19 14:12:45 2001
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 OAA15339
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 14:12:45 -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 QQlcua04247;
	Sun, 19 Aug 2001 18:13:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcua19886
	for mpls-outgoing; Sun, 19 Aug 2001 18:12: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 QQlcua19881
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 18:12:52 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 QQlcua13676
	for <mpls@uu.net>; Sun, 19 Aug 2001 18:12:34 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcua08285
	for <mpls@uu.net>; Sun, 19 Aug 2001 18:12:33 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA20922 for mpls@uu.net; Sun, 19 Aug 2001 14:12:32 -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 QQlcua19763
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 18:12:12 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 QQlcua01232
	for <mpls@UU.NET>; Sun, 19 Aug 2001 18:10:41 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQlcua00964
	for <mpls@UU.NET>; Sun, 19 Aug 2001 18:10:41 GMT
Received: from YHASAN-W2K5.cisco.com (yhasan-dsl3.cisco.com [10.21.182.52])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA04293;
	Sun, 19 Aug 2001 11:10:36 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010819110438.0255f950@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 19 Aug 2001 11:10:35 -0700
To: "punithan" <punithan@lgsi.co.in>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: Re: TE
Cc: "mpls@UU.NET" <mpls@UU.NET>
In-Reply-To: <3B7FCC2B.48BF5BDA@lgsi.co.in>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

No can't use LDP only as the label distribution protocol for TE. RSVP (or CR-LDP) is the only way with TE implementations to distribute labels (orederd control) & maintain LSP state.

You may use LDP on the TE tunnels  in addition
Thanks

-Yousuf

At 07:54 PM 8/19/2001 +0530, punithan wrote:
>Hi,
>Can't we support TE with LDP(without implementing CR-LDP and RSVP-TE)?
>with regds,
>MXJPunithan 



From owner-mpls@UU.NET  Sun Aug 19 15:29:26 2001
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 PAA15851
	for <mpls-archive@lists.ietf.org>; Sun, 19 Aug 2001 15:29:26 -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 QQlcuf10083;
	Sun, 19 Aug 2001 19:29:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcuf15291
	for mpls-outgoing; Sun, 19 Aug 2001 19:29:13 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 QQlcuf15286
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 19:29: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 QQlcuf06359
	for <mpls@uu.net>; Sun, 19 Aug 2001 19:28:57 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcuf11071
	for <mpls@uu.net>; Sun, 19 Aug 2001 19:28:57 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA23675 for mpls@uu.net; Sun, 19 Aug 2001 15:28:56 -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 QQlcuf15254
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 19: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 QQlcuf03536
	for <mpls@UU.NET>; Sun, 19 Aug 2001 19:28:37 GMT
Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlcuf13844
	for <mpls@UU.NET>; Sun, 19 Aug 2001 19:28:36 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7JJQiD21617;
	Sun, 19 Aug 2001 12:26:44 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-238.cisco.com [144.254.46.239])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AAH12986;
	Sun, 19 Aug 2001 12:28:32 -0700 (PDT)
Message-ID: <3B8012DB.4B9ECDFB@cisco.com>
Date: Sun, 19 Aug 2001 12:26:19 -0700
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: punithan <punithan@lgsi.co.in>
CC: "mpls@UU.NET" <mpls@UU.NET>
Subject: Re: RFCs 3034 and 3035
References: <3B7FC436.948F0610@lgsi.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


No.

R.

> punithan wrote:
> 
> Hi,
> I would like to clarify a doubt. If  i am having only Ethernet and  POS
> for my router.The  is there any need to implement the following RFCs
> RFC 3034 - Use of Label Switching on Frame Relay Networks Specification
> RFC 3035 - MPLS using LDP and ATM VC Switching
> thanks and regds,
> MXJPunithan



From owner-mpls@UU.NET  Mon Aug 20 07:09:37 2001
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 HAA10982
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 07:09:36 -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 QQlcwq05017;
	Mon, 20 Aug 2001 11:10:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcwq28999
	for mpls-outgoing; Mon, 20 Aug 2001 11:10: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 QQlcwq28982
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 11:10:02 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 QQlcwq22052
	for <mpls@uu.net>; Mon, 20 Aug 2001 11:09:41 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcwq15000
	for <mpls@uu.net>; Mon, 20 Aug 2001 11:09:40 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA23432 for mpls@uu.net; Mon, 20 Aug 2001 07:09:39 -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 QQlcwq28872
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 11:09:25 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 QQlcwq05337
	for <mpls@uu.net>; Mon, 20 Aug 2001 11:09:02 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 QQlcwq02916
	for <mpls@uu.net>; Mon, 20 Aug 2001 11:09:02 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10840;
	Mon, 20 Aug 2001 07:07:45 -0400 (EDT)
Message-Id: <200108201107.HAA10840@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-ftn-mib-02.txt
Date: Mon, 20 Aug 2001 07:07:45 -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) FEC-To-NHLFE 
                          (FTN) Management Information Base
	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
	Filename	: draft-ietf-mpls-ftn-mib-02.txt
	Pages		: 25
	Date		: 17-Aug-01
	
This memo defines an experimental portion of the Management
Information Base  (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for defining FEC-to-NHLFE mapping and corresponding actions for use
with Multiprotocol Label Switching (MPLS).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-ftn-mib-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-ftn-mib-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:	<20010817144801.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ftn-mib-02.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Mon Aug 20 09:50:40 2001
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 JAA20654
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 09:50:40 -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 QQlcxb00966;
	Mon, 20 Aug 2001 13:51:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxb18828
	for mpls-outgoing; Mon, 20 Aug 2001 13:51: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 QQlcxb18823
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 13:51: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 QQlcxb26681
	for <mpls@uu.net>; Mon, 20 Aug 2001 13:51:21 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcxb09596
	for <mpls@uu.net>; Mon, 20 Aug 2001 13:51:21 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA01735 for mpls@uu.net; Mon, 20 Aug 2001 09:51:20 -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 QQlcxb18803
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 13:50:58 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 QQlcxb10008
	for <mpls@UU.NET>; Mon, 20 Aug 2001 13:50:14 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcxb14581
	for <mpls@UU.NET>; Mon, 20 Aug 2001 13:50:14 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA16127; Mon, 20 Aug 2001 09:50:14 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AGM01162;
	Mon, 20 Aug 2001 09:50:12 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010820095104.01993ee8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 20 Aug 2001 09:51:36 -0700
To: "Natale, Robert C (Bob)" <bnatale@lucent.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: draft-ietf-mpls-ftn-mib-02.txt posted
Cc: Cheenu Srinivasan <cheenu@alphion.com>,
        "MPLS Mailing List (E-mail)" <mpls@UU.NET>
In-Reply-To: <BD842AF47D98D311BFC400508B5EBB8D01CD2FB7@md6370exch003u.ns
 e.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:10 AM 8/19/2001 -0400, Natale, Robert C (Bob) wrote:
>Hi,
>
> > I have just posted an update to the FTN MIB and it should appear
> > on the IETF site shortly. A copy is attached.
>
>The SNMP boilerplate you are using in Section 3 is out-of-date.
>You can obtain the current text from:
>
>    http://www.ops.ietf.org/mib-boilerplate.html
>
>And you have at least one out-of-date SNMP ref in the Security
>section (9) -- namely, 2271 should now be 2571.
>
>These are both just editorial nits, I know.

         Hi Bob,

         No problem; they are appreciated. We will fix these and
re-post the corrected version shortly with only these changes.

         --Tom




>Thanks,
>
>BobN



From owner-mpls@UU.NET  Mon Aug 20 09:52:20 2001
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 JAA20733
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 09:52:20 -0400 (EDT)
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 QQlcxb18099;
	Mon, 20 Aug 2001 13:53:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxb18956
	for mpls-outgoing; Mon, 20 Aug 2001 13:53:09 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 QQlcxb18950
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 13:52: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 QQlcxb18254
	for <mpls@UU.NET>; Mon, 20 Aug 2001 13:52:35 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQlcxb02548
	for <mpls@UU.NET>; Mon, 20 Aug 2001 13:52:34 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KDpAp20476
	for <mpls@UU.NET>; Mon, 20 Aug 2001 09:51:10 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 20 Aug 2001 09:51:14 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RABF0R0L>; Mon, 20 Aug 2001 09:51:15 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431077C9242@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Vijay Srinivasan <Vijay.Srinivasan@cosinecom.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: draft minutes from London meeting
Date: Mon, 20 Aug 2001 09:51:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1297F.2CB661A0"
X-Orig: <dwfedyk@americasm01.nt.com>
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_01C1297F.2CB661A0
Content-Type: text/plain;
	charset="iso-8859-1"

I had asked George about the last call for the Feedback draft and the CR-LDP
Query draft. At the end of the meeting I recall George saying that both were
ready for last call.
 
Don

------_=_NextPart_001_01C1297F.2CB661A0
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>draft minutes from London meeting</TITLE>

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=970415113-20082001><FONT face=Arial color=#0000ff size=2>I had 
asked George about the last call for the Feedback draft and the CR-LDP Query 
draft. At the end of the meeting I recall George saying that both were ready for 
last call.</FONT></SPAN></DIV>
<DIV><SPAN class=970415113-20082001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=970415113-20082001><FONT face=Arial color=#0000ff 
size=2>Don</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C1297F.2CB661A0--


From owner-mpls@UU.NET  Mon Aug 20 10:46:35 2001
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 KAA22552
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 10:46: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 QQlcxf28906;
	Mon, 20 Aug 2001 14:47:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxf11797
	for mpls-outgoing; Mon, 20 Aug 2001 14:47: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 QQlcxf11762
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 14:46:56 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 QQlcxf12582
	for <mpls@uu.net>; Mon, 20 Aug 2001 14:45:22 GMT
Received: from chimera.elec.qmul.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQlcxf16409
	for <mpls@uu.net>; Mon, 20 Aug 2001 14:45:21 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15YqIr-0006kj-00
	for mpls@uu.net; Mon, 20 Aug 2001 15:45:21 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <mpls@UU.NET>
Subject: How to know that egress router is reached?
Date: Mon, 20 Aug 2001 15:52:59 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOIECECFAA.hongwei.zhou@elec.qmul.ac.uk>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello everyone,

In LSP set up, how to know that the egress router has been reached and the
label mapping process should begin then?

Thanks and regards,

Hongwei



From owner-mpls@UU.NET  Mon Aug 20 11:08:44 2001
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 LAA23314
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 11:08:44 -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 QQlcxg12580;
	Mon, 20 Aug 2001 15:09:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxg01705
	for mpls-outgoing; Mon, 20 Aug 2001 15:09:18 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 QQlcxg01625
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 15:09:14 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 QQlcxg02588
	for <mpls@UU.NET>; Mon, 20 Aug 2001 15:08:01 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 QQlcxg09570
	for <mpls@UU.NET>; Mon, 20 Aug 2001 15:08:00 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 LAA19347
	for <mpls@UU.NET>; Mon, 20 Aug 2001 11:07:57 -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 LAA00798
	for <mpls@UU.NET>; Mon, 20 Aug 2001 11:07:56 -0400 (EDT)
Message-ID: <3B8127E3.D4B4859E@marconi.com>
Date: Mon, 20 Aug 2001 11:08:19 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: How to know that egress router is reached?
References: <MEEJLEKIFLLBNABPKDAOIECECFAA.hongwei.zhou@elec.qmul.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hongwei wrote:
> 
> In LSP set up, how to know that the egress router has been reached
> and the label mapping process should begin then?

There are only two possible ways:

1: The FEC describes an address or address range that the router is
   directly connected to.

2: The next-hop to the FEC is not an LDP peer.

-- David


From owner-mpls@UU.NET  Mon Aug 20 12:22:12 2001
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 MAA25608
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 12:22:11 -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 QQlcxl16014;
	Mon, 20 Aug 2001 16:23:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxl26680
	for mpls-outgoing; Mon, 20 Aug 2001 16:22:46 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 QQlcxl26675
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 16:22:41 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 QQlcxl09926
	for <mpls@uu.net>; Mon, 20 Aug 2001 16:22:11 GMT
Received: from crag.netrotech.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: swh-host229.dsl.visi.com [208.42.101.229])
	id QQlcxl14468
	for <mpls@uu.net>; Mon, 20 Aug 2001 16:22:04 GMT
Received: (from jmuston@localhost)
	by crag.netrotech.com (8.9.3/8.9.3/Debian 8.9.3-21) id LAA27837
	for mpls@uu.net; Mon, 20 Aug 2001 11:22:05 -0500
From: John Muston <jmuston@netrotech.com>
Date: Mon, 20 Aug 2001 11:22:05 -0500
To: mpls@UU.NET
Subject: if-stack and link bundling
Message-ID: <20010820112205.A27814@netrotech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-mpls@UU.NET
Precedence: bulk

I'm curious when stacking for link bundling, if a physical interface
might have an mpls interface layered above it in addition to the teLink
interface.

Adapting a picture from section 9.2 of draft-dubuc-mpls-bundle-mib-02.txt,
if a physical interface supports MPLS, might the stack table look
as follows?


           +---------------+
           | mpls          |
           +---------------+
                   |
+-------+  +---------------+  +-------+
| mpls  |  | teLink        |  | mpls  |
+-------+  +---------------+  +-------+
    |          |        |         |
+-----------------+ +-------------------+   
|     oTrans      | |    oTrans         |
+-----------------+ +-------------------+


The idea being either that a physical interface can have LSPs
even if it is participating in a link bundle (if this is possible)
or that joining a link bundle implicitly admin-down's but does
not delete the overlying MPLS interface.



From owner-mpls@UU.NET  Mon Aug 20 15:49:54 2001
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 PAA01527
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 15:49:54 -0400 (EDT)
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 QQlcxz28617;
	Mon, 20 Aug 2001 19:50:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxz07293
	for mpls-outgoing; Mon, 20 Aug 2001 19:50: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 QQlcxz07288
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 19:50:20 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 QQlcxz11821
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:49:25 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcxz25611
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:49: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 PAA03784 for <mpls@uu.net>; Mon, 20 Aug 2001 15:49:24 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13605 for mpls@uu.net; Mon, 20 Aug 2001 15:48:58 -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 QQlcsd15306
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 05:48:27 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 QQlcsd01047
	for <mpls@uu.net>; Sun, 19 Aug 2001 05:46:49 GMT
Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailsrv.acc.com [129.192.64.128])
	id QQlcsd08408
	for <mpls@uu.net>; Sun, 19 Aug 2001 05:46:47 GMT
Received: from topgun (tig-98-01.acc.com [129.192.98.1])
	by acc.com (8.11.1/8.11.1) with SMTP id f7J5gim10853;
	Sat, 18 Aug 2001 22:42:45 -0700 (PDT)
Message-ID: <002e01c12872$8d9c5460$0162c081@mshome.net>
From: "kishan" <harikishan.desineni@ericsson.com>
To: <mpls@UU.NET>
Cc: <kishan@acc.am.ericsson.se>
Subject: Questions on Loop Detection (Cra.1, etc.,)
Date: Sat, 18 Aug 2001 22:45:40 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002B_01C12837.819C48E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C12837.819C48E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Q1::

Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message =

is received with a pathvector TLV and loop is detected, the LSR should =
transmit
 a label release message carrying a Status TLV to the sending LSR to =
signal
"Loop Detected".

 But,the Label release message(3.5.11) does not include a status TLV in =
it's
optional List of TLVs? So, what is the way to inform downstream that the =

label release was a result of loop detected by the upstream??

*****

Q2::

    Check_Received_Attributes (A.2.6) algorithm is in such a way that =
the=20
 Path Vector TLV will be processed only when HopCount TLV is present=20
in the Label Request/Mapping message. ( CRa.1)

Does that mean Loop Detection can be used only along with HopCount
and it can't be used independently ( without HopCount )?? I know that
sometimes (for ATM/FR LSRs) HopCount is a MUST in Label Request
messages and HC may or may not be present in Label mapping messages
based on the Merge type of the LSR.

The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
loop detection capabilities.
" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE

SYNTAX INTEGER {

none(1),

other(2),

hopCount(3),

pathVector(4),

hopCountAndPathVector(5)

}"



which implies that pathVector(4) should be configurable independent=20

of anyother loop detection mechanism ( like HopCount). This contradicts

with the description of Check_Received_Attributes (Cra.1) Algorithm=20

in RFC 3036 which states that PathVector TLV will not be processed

if there is no HopCount TLV in the received message.



*******

Thanks,
HariKishan

------=_NextPart_000_002B_01C12837.819C48E0
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 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Q1::</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 3.4.5.1.2 LDP RFC 3036 states =
that, when a=20
label mapping message </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>is received w</FONT><FONT face=3DArial =
size=3D2>ith a=20
pathvector TLV and loop is detected, the LSR should =
transmit</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;a label </FONT><FONT face=3DArial =

size=3D2>release message carrying a Status TLV to the sending LSR to=20
signal</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"Loop Detected".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;But,the Label release =
message(3.5.11) does=20
not include a status TLV in it's</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>optional List of TLVs? So, what is the =
way to=20
inform downstream that the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>label release was a result of =
loop&nbsp;detected by=20
the upstream??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>*****</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Q2::</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Check_Received_Attributes=20
(A.2.6) algorithm is in such a way that the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;Path Vector TLV will be processed =
only when=20
HopCount TLV is present </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in the Label Request/Mapping message. ( =

CRa.1)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does that mean Loop Detection can be =
used only=20
along with HopCount</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and it can't be used independently ( =
without=20
HopCount )?? I know that</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>sometimes (for ATM/FR LSRs) HopCount is =
a MUST in=20
Label Request</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>messages and HC may or may not be =
present in Label=20
mapping messages</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>based on the Merge type of the =
LSR.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The LDP MIB&nbsp; "<FONT=20
size=3D2>draft-ietf-mpls-ldp-mib-07.txt"&nbsp;has&nbsp;the=20
following</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>loop detection =
capabilities.</FONT></DIV>
<DIV><FONT size=3D2>
<P>" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE</P>
<P>SYNTAX INTEGER {</P>
<P>none(1),</P>
<P>other(2),</P>
<P>hopCount(3),</P>
<P>pathVector(4),</P>
<P>hopCountAndPathVector(5)</P>
<P>}"</P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial>which implies that pathVector(4) should be =
configurable=20
independent </FONT></P>
<P><FONT face=3DArial>of anyother loop detection mechanism ( like =
HopCount). This=20
contradicts</FONT></P>
<P><FONT face=3DArial>with the description=20
of&nbsp;Check_Received_Attributes&nbsp;(Cra.1) Algorithm </FONT></P>
<P><FONT face=3DArial>in RFC 3036 which states that PathVector TLV will =
not be=20
processed</FONT></P>
<P><FONT face=3DArial>if there is no HopCount TLV in the received=20
message.</FONT></P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial>*******</FONT></FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>HariKishan</FONT></DIV></BODY></HTML>

------=_NextPart_000_002B_01C12837.819C48E0--



From owner-mpls@UU.NET  Mon Aug 20 15:52:02 2001
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 PAA01635
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 15:52: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 QQlcxz01405;
	Mon, 20 Aug 2001 19:52:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxz07384
	for mpls-outgoing; Mon, 20 Aug 2001 19:51: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 QQlcxz07379
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 19:51:56 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 QQlcxz17108
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:51:22 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcxz26992
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:51:18 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA23172
	for <mpls@uu.net>; Mon, 20 Aug 2001 15:51:17 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13651 for mpls@uu.net; Mon, 20 Aug 2001 15:50:51 -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 QQlcxd09598
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 14:21:04 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 QQlcxd21514
	for <mpls@UU.NET>; Mon, 20 Aug 2001 14:19:04 GMT
Received: from nwds0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQlcxd19197
	for <mpls@UU.NET>; Mon, 20 Aug 2001 14:19:03 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Mon, 20 Aug 2001 10:14:13 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Natale, Robert C \(Bob\)'" <bnatale@lucent.com>
Cc: "MPLS Mailing List \(E-mail\)" <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-ftn-mib-02.txt posted
Date: Mon, 20 Aug 2001 10:31:10 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB0F3@OPTONT>
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <BD842AF47D98D311BFC400508B5EBB8D01CD2FB7@md6370exch003u.nse.lucent.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> The SNMP boilerplate you are using in Section 3 is out-of-date.
> You can obtain the current text from:
> 
>    http://www.ops.ietf.org/mib-boilerplate.html
> 
> And you have at least one out-of-date SNMP ref in the Security
> section (9) -- namely, 2271 should now be 2571.

Bob,

Thanks for catching these. We'll post an update with these fixes.

Cheenu



From owner-mpls@UU.NET  Mon Aug 20 15:52:50 2001
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 PAA01658
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 15:52:50 -0400 (EDT)
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 QQlcxz09653;
	Mon, 20 Aug 2001 19:53:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxz07511
	for mpls-outgoing; Mon, 20 Aug 2001 19:53: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 QQlcxz07502
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 19:53: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 QQlcxz18714
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:51:52 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlcxz00734
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:51:34 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 PAA04088 for <mpls@uu.net>; Mon, 20 Aug 2001 15:51:32 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13655 for mpls@uu.net; Mon, 20 Aug 2001 15:51:06 -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 QQlcxo01824
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 17:00:35 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 QQlcxo07388
	for <mpls@uu.net>; Mon, 20 Aug 2001 17:00:30 GMT
Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailsrv.acc.com [129.192.64.128])
	id QQlcxo03383
	for <mpls@uu.net>; Mon, 20 Aug 2001 17:00:29 GMT
Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11])
	by acc.com (8.11.1/8.11.1) with SMTP id f7KGujm06498
	for <mpls@uu.net>; Mon, 20 Aug 2001 09:56:45 -0700 (PDT)
Reply-To: <harikishan.desineni@ericsson.com>
From: "HariKishan" <harikishan.desineni@ericsson.com>
To: <mpls@UU.NET>
Subject: Questions on Loop Detection (Cra.1, etc.,)
Date: Mon, 20 Aug 2001 09:55:16 -0700
Message-ID: <NFBBIBMLMBKPNKKDJEGGGEBBCGAA.harikishan.desineni@ericsson.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.00.2919.6600
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Q1::

Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping
message
is received with a path vector TLV and loop is detected, the LSR
should transmit
 a label release message carrying a Status TLV to the sending LSR to
signal
"Loop Detected".

 But, the Label release message(3.5.11) does not include a status TLV
in it's
optional List of TLVs? So, what is the way to inform downstream that
the
label release was a result of loop detected by the upstream??

*****

Q2::

    Check_Received Attributes (A.2.6) algorithm is in such a way that
the
 Path Vector TLV will be processed only when Hop Count TLV is present
in the Label Request/Mapping message. ( CRa.1)

Does that mean Loop Detection can be used only along with Hop Count
and it can't be used independently ( without Hop Count )?? I know that
sometimes (for ATM/FR LSRs) Hop Count is a MUST in Label Request
messages and HC may or may not be present in Label mapping messages
based on the Merge type of the LSR.

The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
loop detection capabilities.
" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE

SYNTAX INTEGER {

none(1),

other(2),

hopCount(3),

pathVector(4),

hopCountAndPathVector(5)

}"



which implies that pathVector(4) should be configurable independent

of any other loop detection mechanism ( like Hop Count). This
contradicts

with the description of Check_Received_Attributes (Cra.1) Algorithm

in RFC 3036 which states that Path Vector TLV will not be processed

if there is no Hop Count TLV in the received message.



*******

Thanks,
HariKishan

---------------------------------
HariKishan Desineni,
Ericsson Inc,
Data Backbone & Optical Division,
Santabarbara,
California - 93117
Office:(805) 562 6419
Home:(805) 562 8841



From owner-mpls@UU.NET  Mon Aug 20 15:52:52 2001
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 PAA01670
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 15:52:52 -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 QQlcxz04801;
	Mon, 20 Aug 2001 19:53:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcxz07494
	for mpls-outgoing; Mon, 20 Aug 2001 19:53:13 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 QQlcxz07487
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 19:53: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 QQlcxz26799
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:50:26 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlcxz23910
	for <mpls@uu.net>; Mon, 20 Aug 2001 19:50:15 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA23072
	for <mpls@uu.net>; Mon, 20 Aug 2001 15:50:14 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13614 for mpls@uu.net; Mon, 20 Aug 2001 15:49:48 -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 QQlcty28943
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 19 Aug 2001 17:42:39 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 QQlcty24198
	for <mpls@UU.NET>; Sun, 19 Aug 2001 17:42:36 GMT
Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailsrv.acc.com [129.192.64.128])
	id QQlcty23313
	for <mpls@UU.NET>; Sun, 19 Aug 2001 17:42:36 GMT
Received: from topgun (tig-98-10.acc.com [129.192.98.10])
	by acc.com (8.11.1/8.11.1) with SMTP id f7JHcqm06924
	for <mpls@UU.NET>; Sun, 19 Aug 2001 10:38:52 -0700 (PDT)
Message-ID: <002101c128d6$98907180$0a62c081@mshome.net>
Reply-To: "kishan" <harikishan.desineni@ericsson.com>
From: "kishan" <harikishan.desineni@ericsson.com>
To: <mpls@UU.NET>
Subject:  Questions on Loop Detection (Cra.1, etc.,)
Date: Sun, 19 Aug 2001 10:44:27 -0700
Organization: Ericsson, Santa Barbara, California, USA
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C1289B.EB7156C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

Q1::

Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message =

is received with a pathvector TLV and loop is detected, the LSR should =
transmit
 a label release message carrying a Status TLV to the sending LSR to =
signal
"Loop Detected".

 But,the Label release message(3.5.11) does not include a status TLV in =
it's
optional List of TLVs? So, what is the way to inform downstream that the =

label release was a result of loop detected by the upstream??

*****

Q2::

    Check_Received_Attributes (A.2.6) algorithm is in such a way that =
the=20
 Path Vector TLV will be processed only when HopCount TLV is present=20
in the Label Request/Mapping message. ( CRa.1)

Does that mean Loop Detection can be used only along with HopCount
and it can't be used independently ( without HopCount )?? I know that
sometimes (for ATM/FR LSRs) HopCount is a MUST in Label Request
messages and HC may or may not be present in Label mapping messages
based on the Merge type of the LSR.

The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
loop detection capabilities.
" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE

SYNTAX INTEGER {

none(1),

other(2),

hopCount(3),

pathVector(4),

hopCountAndPathVector(5)

}"



which implies that pathVector(4) should be configurable independent=20

of anyother loop detection mechanism ( like HopCount). This contradicts

with the description of Check_Received_Attributes (Cra.1) Algorithm=20

in RFC 3036 which states that PathVector TLV will not be processed

if there is no HopCount TLV in the received message.



*******

Thanks,
HariKishan

------=_NextPart_000_001E_01C1289B.EB7156C0
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 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Q1::</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 3.4.5.1.2 LDP RFC 3036 states =
that, when a=20
label mapping message </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>is received w</FONT><FONT face=3DArial =
size=3D2>ith a=20
pathvector TLV and loop is detected, the LSR should =
transmit</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;a label </FONT><FONT face=3DArial =

size=3D2>release message carrying a Status TLV to the sending LSR to=20
signal</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"Loop Detected".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;But,the Label release =
message(3.5.11) does=20
not include a status TLV in it's</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>optional List of TLVs? So, what is the =
way to=20
inform downstream that the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>label release was a result of =
loop&nbsp;detected by=20
the upstream??</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>*****</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Q2::</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
Check_Received_Attributes=20
(A.2.6) algorithm is in such a way that the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;Path Vector TLV will be processed =
only when=20
HopCount TLV is present </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in the Label Request/Mapping message. ( =

CRa.1)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does that mean Loop Detection can be =
used only=20
along with HopCount</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and it can't be used independently ( =
without=20
HopCount )?? I know that</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>sometimes (for ATM/FR LSRs) HopCount is =
a MUST in=20
Label Request</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>messages and HC may or may not be =
present in Label=20
mapping messages</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>based on the Merge type of the =
LSR.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The LDP MIB&nbsp; "<FONT=20
size=3D2>draft-ietf-mpls-ldp-mib-07.txt"&nbsp;has&nbsp;the=20
following</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>loop detection =
capabilities.</FONT></DIV>
<DIV><FONT size=3D2>
<P>" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE</P>
<P>SYNTAX INTEGER {</P>
<P>none(1),</P>
<P>other(2),</P>
<P>hopCount(3),</P>
<P>pathVector(4),</P>
<P>hopCountAndPathVector(5)</P>
<P>}"</P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial>which implies that pathVector(4) should be =
configurable=20
independent </FONT></P>
<P><FONT face=3DArial>of anyother loop detection mechanism ( like =
HopCount). This=20
contradicts</FONT></P>
<P><FONT face=3DArial>with the description=20
of&nbsp;Check_Received_Attributes&nbsp;(Cra.1) Algorithm </FONT></P>
<P><FONT face=3DArial>in RFC 3036 which states that PathVector TLV will =
not be=20
processed</FONT></P>
<P><FONT face=3DArial>if there is no HopCount TLV in the received=20
message.</FONT></P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial>*******</FONT></FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>HariKishan</FONT></DIV></BODY></HTML>

------=_NextPart_000_001E_01C1289B.EB7156C0--



From owner-mpls@UU.NET  Mon Aug 20 16:02:31 2001
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 QAA01953
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 16:02:31 -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 QQlcya22606;
	Mon, 20 Aug 2001 20:03:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcya13149
	for mpls-outgoing; Mon, 20 Aug 2001 20:02:46 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 QQlcya13063
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 20:02: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 QQlcya05515
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:01:59 GMT
Received: from dtctxexchims04.ins.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.164.93.14])
	id QQlcya26219
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:01:57 GMT
Received: from KENTYU (135.119.77.191 [135.119.77.191]) by dtctxexchims04.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RJPN8C1A; Mon, 20 Aug 2001 15:01:55 -0500
Message-ID: <037b01c129b3$0e6501f0$bf4d7787@KENTYU>
Reply-To: "Kent Yu" <yux@lucent.com>
From: "Kent Yu" <yux@lucent.com>
To: <mpls@UU.NET>
References: <MEEJLEKIFLLBNABPKDAOIECECFAA.hongwei.zhou@elec.qmul.ac.uk>
Subject: MPLS VPN provider?
Date: Mon, 20 Aug 2001 16:02:12 -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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I would like to know the updated number of service providers offering MPLS
VPN service.

Any pointer of pricing information will be a big help.

Thanks

kent






From owner-mpls@UU.NET  Mon Aug 20 16:21:50 2001
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 QAA02837
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 16:21: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 QQlcyb25076;
	Mon, 20 Aug 2001 20:22:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcyb28590
	for mpls-outgoing; Mon, 20 Aug 2001 20:22:06 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 QQlcyb28583
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 20:21:55 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 QQlcyb03035
	for <mpls@uu.net>; Mon, 20 Aug 2001 20:21:34 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcyb23777
	for <mpls@uu.net>; Mon, 20 Aug 2001 20:21:33 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA04753 for mpls@uu.net; Mon, 20 Aug 2001 16:21:32 -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 QQlcyb28512
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 20:21:07 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 QQlcyb23739
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:19:27 GMT
Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlcyb15856
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:19:27 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KKJSQ17100;
	Mon, 20 Aug 2001 13:19:28 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA00664; Mon, 20 Aug 2001 16:19:17 -0400 (EDT)
Message-Id: <200108202019.QAA00664@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: "kishan" <harikishan.desineni@ericsson.com>
cc: mpls@UU.NET, kishan@acc.am.ericsson.se
Subject: Re: Questions on Loop Detection (Cra.1, etc.,) 
In-reply-to: Your message of "Sat, 18 Aug 2001 22:45:40 PDT."
             <002e01c12872$8d9c5460$0162c081@mshome.net> 
Date: Mon, 20 Aug 2001 16:19:17 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Harikishan,

> Q1::
> 
> Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message =
> 
> is received with a pathvector TLV and loop is detected, the LSR should =
> transmit
>  a label release message carrying a Status TLV to the sending LSR to =
> signal
> "Loop Detected".
> 
>  But,the Label release message(3.5.11) does not include a status TLV in =
> it's
> optional List of TLVs? So, what is the way to inform downstream that the =
> 
> label release was a result of loop detected by the upstream??

Please refer to RFC3036, Section 3.4.6 - Status TLV, page 45:

   Note that use of the Status TLV is not limited to Notification
   messages.  A message other than a Notification message may carry a
   Status TLV as an Optional Parameter.  When a message other than a
   Notification carries a Status TLV the U-bit of the Status TLV should
   be set to 1 to indicate that the receiver should silently discard the
   TLV if unprepared to handle it.


> Q2::
> 
>     Check_Received_Attributes (A.2.6) algorithm is in such a way that =
> the=20
>  Path Vector TLV will be processed only when HopCount TLV is present=20
> in the Label Request/Mapping message. ( CRa.1)
> 
> Does that mean Loop Detection can be used only along with HopCount
> and it can't be used independently ( without HopCount )?? I know that

Yes.

Please refer to RFC 3035, Section 2.8 - Loop Detction, particularly
the bullets in Section 2.8.1 - Label Request Message, pages 24 and 25, and
Section 2.8.2 - Label Mapping Message, page 26:

   The rules that govern use of the Hop Count TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  The Label Request message MUST include a Hop Count TLV.

and

   The rules that govern the use of the Hop Count TLV in Label Mapping
   messages sent by an LSR R when Loop Detection is enabled are the
   following:

   -  R MUST include a Hop Count TLV.


Bob



> sometimes (for ATM/FR LSRs) HopCount is a MUST in Label Request
> messages and HC may or may not be present in Label mapping messages
> based on the Merge type of the LSR.
> 
> The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
> loop detection capabilities.
> " mplsLdpLsrLoopDetectionCapable OBJECT-TYPE
> 
> SYNTAX INTEGER {
> 
> none(1),
> 
> other(2),
> 
> hopCount(3),
> 
> pathVector(4),
> 
> hopCountAndPathVector(5)
> 
> }"
> 
> 
> 
> which implies that pathVector(4) should be configurable independent=20
> 
> of anyother loop detection mechanism ( like HopCount). This contradicts
> 
> with the description of Check_Received_Attributes (Cra.1) Algorithm=20
> 
> in RFC 3036 which states that PathVector TLV will not be processed
> 
> if there is no HopCount TLV in the received message.
> 
> 
> 
> *******
> 
> Thanks,
> HariKishan



From owner-mpls@UU.NET  Mon Aug 20 16:36:03 2001
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 QAA03183
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 16:36: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 QQlcyc19066;
	Mon, 20 Aug 2001 20:36:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcyc29768
	for mpls-outgoing; Mon, 20 Aug 2001 20:36:11 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 QQlcyc29744
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 20:36: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 QQlcyc09310
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:35:43 GMT
Received: from bgslc02.TBG.COM by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host2.tbg.com [63.99.125.2] (may be forged))
	id QQlcyc17483
	for <mpls@UU.NET>; Mon, 20 Aug 2001 20:35:43 GMT
Received: by host2.tbg.com with Internet Mail Service (5.5.2653.19)
	id <QQ78A3M3>; Mon, 20 Aug 2001 14:31:53 -0600
Message-ID: <0C875DC28791D21192CD00104B95BFE7025A5B13@host2.tbg.com>
From: Irwin Lazar <ILazar@tbg.com>
To: "'Kent Yu'" <yux@lucent.com>, mpls@UU.NET
Subject: RE: MPLS VPN provider?
Date: Mon, 20 Aug 2001 14:31:45 -0600
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

A fairly complete list of service providers that have deployed MPLS can be
found in the MPLS FAQ on www.mplsrc.com

I'd check with the MPLS Forum to obtain additional information on which of
those providers are actually offering VPN services (as opposed to those that
are using MPLS for TE).

Irwin

> -----Original Message-----
> From: Kent Yu [mailto:yux@lucent.com]
> Sent: Monday, August 20, 2001 4:02 PM
> To: mpls@UU.NET
> Subject: MPLS VPN provider?
> 
> 
> Hi all,
> 
> I would like to know the updated number of service providers 
> offering MPLS
> VPN service.
> 
> Any pointer of pricing information will be a big help.
> 
> Thanks
> 
> kent
> 
> 
> 
> 


From owner-mpls@UU.NET  Mon Aug 20 18:03:56 2001
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 SAA05448
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 18:03:56 -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 QQlcyi11841;
	Mon, 20 Aug 2001 22:05:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcyi04820
	for mpls-outgoing; Mon, 20 Aug 2001 22:04:46 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 QQlcyi04625
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 20 Aug 2001 22:04:39 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 QQlcyi21368
	for <mpls@UU.NET>; Mon, 20 Aug 2001 22:03:33 GMT
Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQlcyi08986
	for <mpls@UU.NET>; Mon, 20 Aug 2001 22:03:33 GMT
Received: from mail1.tellium.com (mail1 [151.198.92.140])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f7KM0fg14730;
	Mon, 20 Aug 2001 18:00:41 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <RHDAYYMW>; Mon, 20 Aug 2001 18:03:35 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D0220404029D8717@mail1.tellium.com>
From: Vasanthi Thirumalai <Vasanthi@tellium.com>
To: "'kishan'" <harikishan.desineni@ericsson.com>, mpls@UU.NET
Subject: RE: Questions on Loop Detection (Cra.1, etc.,)
Date: Mon, 20 Aug 2001 18:03: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

Harikishan,
The Status TLV in this case is carried as an optional parameter in the Label
release message. In such a usage, the U-bit of the Status TLV should be set
to 1 to indicate that the receiver should silently discard the TLV if
unprepared to handle it.
-Vasanthi


-----Original Message-----
From: kishan [mailto:harikishan.desineni@ericsson.com]
Sent: Sunday, August 19, 2001 1:44 PM
To: mpls@UU.NET
Subject: Questions on Loop Detection (Cra.1, etc.,)


Q1::
 
Section 3.4.5.1.2 LDP RFC 3036 states that, when a label mapping message 
is received with a pathvector TLV and loop is detected, the LSR should
transmit
 a label release message carrying a Status TLV to the sending LSR to signal
"Loop Detected".
 
 But,the Label release message(3.5.11) does not include a status TLV in it's
optional List of TLVs? So, what is the way to inform downstream that the 
label release was a result of loop detected by the upstream??
 
*****
 
Q2::
 
    Check_Received_Attributes (A.2.6) algorithm is in such a way that the 
 Path Vector TLV will be processed only when HopCount TLV is present 
in the Label Request/Mapping message. ( CRa.1)
 
Does that mean Loop Detection can be used only along with HopCount
and it can't be used independently ( without HopCount )?? I know that
sometimes (for ATM/FR LSRs) HopCount is a MUST in Label Request
messages and HC may or may not be present in Label mapping messages
based on the Merge type of the LSR.
 
The LDP MIB  "draft-ietf-mpls-ldp-mib-07.txt" has the following
loop detection capabilities.
" mplsLdpLsrLoopDetectionCapable OBJECT-TYPE

SYNTAX INTEGER {

none(1),

other(2),

hopCount(3),

pathVector(4),

hopCountAndPathVector(5)

}"

 

which implies that pathVector(4) should be configurable independent 

of anyother loop detection mechanism ( like HopCount). This contradicts

with the description of Check_Received_Attributes (Cra.1) Algorithm 

in RFC 3036 which states that PathVector TLV will not be processed

if there is no HopCount TLV in the received message.

 

*******

Thanks,
HariKishan



From owner-mpls@UU.NET  Mon Aug 20 20:03:53 2001
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 UAA07873
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 20:03:52 -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 QQlcyq09330;
	Tue, 21 Aug 2001 00:04:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcyq19293
	for mpls-outgoing; Tue, 21 Aug 2001 00:04:27 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 QQlcyq19284
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 00:04:11 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 QQlcyq19102
	for <mpls@UU.NET>; Tue, 21 Aug 2001 00:04:04 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f18.law3.hotmail.com [209.185.241.18])
	id QQlcyq27439
	for <mpls@UU.NET>; Tue, 21 Aug 2001 00:04:04 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 20 Aug 2001 17:04:03 -0700
Received: from 38.186.47.9 by lw3fd.law3.hotmail.msn.com with HTTP;	Tue, 21 Aug 2001 00:04:03 GMT
X-Originating-IP: [38.186.47.9]
From: "Gangadharan Ramakrishnan" <gangadharanr@hotmail.com>
To: mpls@UU.NET
Cc: morekonda@hotmail.com, muthu@coronanetworks.com
Subject: What is the diferrence between LDP tunnel and MPLS LSP tunnel.
Date: Tue, 21 Aug 2001 00:04:03 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F18B5Q91FeUbXD6iebG0001092b@hotmail.com>
X-OriginalArrivalTime: 21 Aug 2001 00:04:03.0477 (UTC) FILETIME=[C9936450:01C129D4]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I can understand LSP tunnel. But, i don't understand LDP tunnel? Is there 
anything called LDP tunnel? If, there can anyone expalin it in breif. Note: 
Juniper is using terminology.

Cheers,
ganges....

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Mon Aug 20 21:43:40 2001
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 VAA09979
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 21:43:39 -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 QQlcyw23492;
	Tue, 21 Aug 2001 01:44:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcyw23181
	for mpls-outgoing; Tue, 21 Aug 2001 01:44: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 QQlcyw23176
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 01:44:18 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 QQlcyw16648
	for <mpls@uu.net>; Tue, 21 Aug 2001 01:43:48 GMT
Received: from cnhon1imr4.i.wcom.com.hk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.130.178.68])
	id QQlcyw07444
	for <mpls@uu.net>; Tue, 21 Aug 2001 01:43:47 GMT
X-Internal-ID: 3B789B8600021489
Received: from cnhon1imr4.i.wcom.com.hk (166.45.172.22) by cnhon1imr4.i.wcom.com.hk (NPlex 3.0.036) for mpls@uu.net; Tue, 21 Aug 2001 02:42:59 +0100
Received: from cnhon1gw0.i.wcom.com.hk (cnhon1gw0.i.wcom.com.hk [166.45.172.46]) by cnhon1imr4.i.wcom.com.hk with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Tue, 21 Aug 2001 02:42:58 +0100
Received: by cnhon1gw0.i.wcom.com.hk with Internet Mail Service (5.5.2653.19)
	id <R2X7SG7S>; Tue, 21 Aug 2001 09:43:39 +0800
Message-ID: <8D9BE231086DD41181EF00508B69805201989A10@cnhon1ex1.i.wcom.com.hk>
From: "Tsang, Fatima" <tsang.fatima@wcom.com.hk>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Integrating 2 MPLS network
Date: Tue, 21 Aug 2001 09:43:40 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-SMTP-HELO: cnhon1gw0.i.wcom.com.hk
X-SMTP-MAIL-FROM: tsang.fatima@wcom.com.hk
X-SMTP-PEER-INFO: cnhon1gw0.i.wcom.com.hk [166.45.172.46]
Sender: owner-mpls@UU.NET
Precedence: bulk

Dear All,

I am new at this, hope you can provide some assistance.

I have the following situation:

City A, City B, City C
City A and City B are on one unique MPLS network by ISP A
City B and City C are on another unique MPLS network by ISP B

Is there any way that City A can talk to City C via City B through the
router B?  If so, is there anything required to be done on the PE's for this
customer?

Thanks.

Greatly appreciated.

Thanks,
Fatima


From owner-mpls@UU.NET  Mon Aug 20 22:41:09 2001
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 WAA11513
	for <mpls-archive@lists.ietf.org>; Mon, 20 Aug 2001 22:41:09 -0400 (EDT)
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 QQlcza13733;
	Tue, 21 Aug 2001 02:42:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlcza15959
	for mpls-outgoing; Tue, 21 Aug 2001 02:41: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 QQlcza15952
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 02:41:48 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 QQlcza09895
	for <mpls@uu.net>; Tue, 21 Aug 2001 02:40:55 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlcza11637
	for <mpls@uu.net>; Tue, 21 Aug 2001 02:40:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA25846 for mpls@uu.net; Mon, 20 Aug 2001 22:40:54 -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 QQlcza15800
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 02:40:33 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 QQlcza02753
	for <mpls@UU.NET>; Tue, 21 Aug 2001 02:38:58 GMT
Received: from che-cse-104.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQlcza08662
	for <mpls@UU.NET>; Tue, 21 Aug 2001 02:38:57 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f7L2cqr02812; Mon, 20 Aug 2001 22:38:52 -0400 (EDT)
Date: Mon, 20 Aug 2001 22:38:52 -0400
From: Eric Osborne <eosborne@cisco.com>
To: "Tsang, Fatima" <tsang.fatima@wcom.com.hk>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Integrating 2 MPLS network
Message-ID: <20010820223852.D2197@che-cse-104.cisco.com>
References: <8D9BE231086DD41181EF00508B69805201989A10@cnhon1ex1.i.wcom.com.hk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <8D9BE231086DD41181EF00508B69805201989A10@cnhon1ex1.i.wcom.com.hk>; from tsang.fatima@wcom.com.hk on Tue, Aug 21, 2001 at 09:43:40AM +0800
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, Aug 21, 2001 at 09:43:40AM +0800, Tsang, Fatima wrote:
> Dear All,
> 
> I am new at this, hope you can provide some assistance.
> 
> I have the following situation:
> 
> City A, City B, City C
> City A and City B are on one unique MPLS network by ISP A
> City B and City C are on another unique MPLS network by ISP B
> 
> Is there any way that City A can talk to City C via City B through the
> router B?  If so, is there anything required to be done on the PE's for this
> customer?

Depends on what the carriers do.  If both ISP A and ISP B are talking
to each other, they could run inter-provider MPLS BGP VPN.  But that
requires a lot to line up between ISP A and ISP B.

Another way to do this is a full mesh of GRE tunnels between cities A, 
B, and C.  Disadvantage is that it's harder to scale to lots of
cities; advantage is that there's nothing the provider needs to do to
let this happen.




eric  

> 
> Thanks.
> 
> Greatly appreciated.
> 
> Thanks,
> Fatima



From owner-mpls@UU.NET  Tue Aug 21 03:34:55 2001
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 DAA02091
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 03:34:55 -0400 (EDT)
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 QQlczu02772;
	Tue, 21 Aug 2001 07:36:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlczu08207
	for mpls-outgoing; Tue, 21 Aug 2001 07:35: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 QQlczu08186
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 07:35: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 QQlczu22258
	for <mpls@uu.net>; Tue, 21 Aug 2001 07:35:20 GMT
Received: from relay.COLTINTERNET.COM by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: bunny.server.COLT.NET [212.74.64.43])
	id QQlczu29254
	for <mpls@uu.net>; Tue, 21 Aug 2001 07:35:19 GMT
Received: (qmail 5562 invoked from network); 21 Aug 2001 07:34:32 -0000
Received: from dhcp-219.noc.colt.net (HELO james) (212.74.95.219)
  by relay.COLT.NET with SMTP; 21 Aug 2001 07:34:32 -0000
From: "James Cumming" <james@cumming.org>
To: "Gangadharan Ramakrishnan" <gangadharanr@hotmail.com>
Cc: <mpls@UU.NET>
Subject: RE: What is the diferrence between LDP tunnel and MPLS LSP tunnel.
Date: Tue, 21 Aug 2001 08:36:09 +0100
Message-ID: <NFBBICPAMLJKCCGEMBJPAEHOCAAA.james@cumming.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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006
Importance: Normal
In-Reply-To: <F18B5Q91FeUbXD6iebG0001092b@hotmail.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hiya,

For LDP tunnel read "dynamic LSP".  Basically when Juniper refer to an LSP
they mean a statically defined LSP created using RSVP.  By LDP tunnel they
mean "stick LDP on the interfaces and let it create LSPs following the IGP".

James


--
___ ___ ___ ___
\C/ \O/ \L/ \T/ James Cumming (james@colt.net) IP Engineering
 V   V   V   V  European Networks & Services   Tel: TBA


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> Gangadharan Ramakrishnan
> Sent: 21 August 2001 01:04
> To: mpls@UU.NET
> Cc: morekonda@hotmail.com; muthu@coronanetworks.com
> Subject: What is the diferrence between LDP tunnel and MPLS LSP tunnel.
>
>
> Hi,
>
> I can understand LSP tunnel. But, i don't understand LDP tunnel? Is there
> anything called LDP tunnel? If, there can anyone expalin it in
> breif. Note:
> Juniper is using terminology.
>
> Cheers,
> ganges....
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>



From owner-mpls@UU.NET  Tue Aug 21 03:43:06 2001
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 DAA02209
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 03:43:06 -0400 (EDT)
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 QQlczu10902;
	Tue, 21 Aug 2001 07:44:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlczu08720
	for mpls-outgoing; Tue, 21 Aug 2001 07:43: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 QQlczu08715
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 07:43:48 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 QQlczu10247
	for <mpls@uu.net>; Tue, 21 Aug 2001 07:43:35 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlczu14404
	for <mpls@uu.net>; Tue, 21 Aug 2001 07:43:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA08836 for mpls@uu.net; Tue, 21 Aug 2001 03:43:33 -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 QQlczu08692
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 07:43:17 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 QQlczu07798
	for <mpls@UU.NET>; Tue, 21 Aug 2001 07:42:20 GMT
Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQlczu12117
	for <mpls@UU.NET>; Tue, 21 Aug 2001 07:42:19 GMT
Received: from YHASAN-W2K5.cisco.com (yhasan-dsl3.cisco.com [10.21.182.52])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA28113;
	Tue, 21 Aug 2001 00:42:18 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010821003851.05bbd0c0@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 21 Aug 2001 00:42:17 -0700
To: "Gangadharan Ramakrishnan" <gangadharanr@hotmail.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: Re: What is the diferrence between LDP tunnel and MPLS LSP
  tunnel.
Cc: mpls@UU.NET, morekonda@hotmail.com, muthu@coronanetworks.com
In-Reply-To: <F18B5Q91FeUbXD6iebG0001092b@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Think it's the same notation as an LDP LSP which will follow the IGP as opposed to the TE "tunnel" which will be setup based on constraints like Bandwidth

You can run LDP over a tunnel though
Thanks

-Yousuf


At 12:04 AM 8/21/2001 +0000, Gangadharan Ramakrishnan wrote:
>Hi,
>
>I can understand LSP tunnel. But, i don't understand LDP tunnel? Is there anything called LDP tunnel? If, there can anyone expalin it in breif. Note: Juniper is using terminology.
>
>Cheers,
>ganges....
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Tue Aug 21 07:29:07 2001
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 HAA05254
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 07:29:07 -0400 (EDT)
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 QQldak18774;
	Tue, 21 Aug 2001 11:30:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldaj07870
	for mpls-outgoing; Tue, 21 Aug 2001 11:29: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 QQldaj07865
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 11:29: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 QQldaj25910
	for <mpls@uu.net>; Tue, 21 Aug 2001 11:28:57 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldaj27303
	for <mpls@uu.net>; Tue, 21 Aug 2001 11:28:56 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA17358 for mpls@uu.net; Tue, 21 Aug 2001 07:28:55 -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 QQldaj07822
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 11:28:48 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 QQldaj28367
	for <mpls@uu.net>; Tue, 21 Aug 2001 11:28:02 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 QQldaj26042
	for <mpls@uu.net>; Tue, 21 Aug 2001 11:28:02 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05085;
	Tue, 21 Aug 2001 07:26:44 -0400 (EDT)
Message-Id: <200108211126.HAA05085@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-mib-08.txt
Date: Tue, 21 Aug 2001 07:26:44 -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		: Definitions of Managed Objects for the Multiprotocol 
                          Label Switching, Label Distribution Protocol (LDP)
	Author(s)	: J. Cucchiara, H. Sjostrand, J. Luciani
	Filename	: draft-ietf-mpls-ldp-mib-08.txt
	Pages		: 83
	Date		: 20-Aug-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for the Multiprotocol
Label Switching, Label Distribution Protocol (LDP).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-ldp-mib-08.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-mib-08.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:	<20010820135755.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ldp-mib-08.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Aug 21 09:29:15 2001
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 JAA11622
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 09:29:14 -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 QQldas22278;
	Tue, 21 Aug 2001 13:30:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldar24972
	for mpls-outgoing; Tue, 21 Aug 2001 13:29: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 QQldar24965
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 13:29: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 QQldar19054
	for <mpls@uu.net>; Tue, 21 Aug 2001 13:25:31 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQldar06731
	for <mpls@uu.net>; Tue, 21 Aug 2001 13:25:31 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 21 Aug 2001 09:25:31 -0400
Message-ID: <00ec01c12a44$bff2d5f0$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <petera@nortelnetworks.com>
Cc: <jamoussi@nortelnetworks.com>, <darek@nortelnetworks.com>,
        <dwfedyk@nortelnetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Small comment on draft-ietf-mpls-te-feed-02.txt
Date: Tue, 21 Aug 2001 09:25:30 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00E9_01C12A23.38870800"
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 Aug 2001 13:25:31.0071 (UTC) FILETIME=[C003ECF0:01C12A44]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

Peter,

Thanks for this draft which looks stable to me.

Would it be possible to add a reference to LDP FT procedures =
(draft-ietf-ldp-ft) in section 5?  I think the third paragraph should =
have the following text appended...

  Where LDP FT procedures [LDP-FT] are in use, LSPs that are protected
  by FT procedures should not be torn down until after session re-
  establishment has failed.  Further, feedback TLVs should not report
  zero bandwidth availability on the link until after session re-
  establishment has failed.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com

------=_NextPart_000_00E9_01C12A23.38870800
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 bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>Peter,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks for this draft which looks =
stable to=20
me.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Would it be possible to add a =
reference to LDP FT=20
procedures (draft-ietf-ldp-ft) in section 5?&nbsp; I think the third =
paragraph=20
should have the following text appended...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; Where LDP FT procedures =
[LDP-FT] are in=20
use, LSPs that are protected</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; by FT procedures should not be =
torn down=20
until after session re-</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; establishment has =
failed.&nbsp; Further,=20
feedback TLVs should not report</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; zero bandwidth availability on =
the link=20
until after session re-</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; establishment has =
failed.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Movaz Networks =
Inc.<BR><A=20
href=3D"mailto:afarrel@movaz.com">afarrel@movaz.com</A></FONT></DIV></BOD=
Y></HTML>

------=_NextPart_000_00E9_01C12A23.38870800--



From owner-mpls@UU.NET  Tue Aug 21 12:21:25 2001
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 MAA22695
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:21:25 -0400 (EDT)
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 QQldbd19711;
	Tue, 21 Aug 2001 16:22:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbd09131
	for mpls-outgoing; Tue, 21 Aug 2001 16:21:09 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 QQldbd09055
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:20:52 GMT
Received: from dgismtp01.wcomnet.com by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dgismtp01.wcomnet.com [166.38.58.141])
	id QQldbd16704
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:19:02 GMT
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0GIF00H01ENORE@dgismtp01.wcomnet.com> for mpls@UU.NET; Tue,
 21 Aug 2001 16:19:01 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GIF00H01ENBMK@dgismtp01.wcomnet.com> for
 mpls@UU.NET; Tue, 21 Aug 2001 16:18:48 +0000 (GMT)
Received: from ws107v7414a ([166.35.146.46])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0GIF00GF7EMYGM@dgismtp01.wcomnet.com> for mpls@UU.NET; Tue,
 21 Aug 2001 16:18:34 +0000 (GMT)
Date: Tue, 21 Aug 2001 11:18:34 -0500
From: David Escobar <c-david.escobar@wcom.com>
Subject: Time to live
To: mpls@UU.NET
Message-id: <004f01c12a5c$ed71caa0$2e9223a6@wcomnet.com>
Organization: Worldcom
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <0C875DC28791D21192CD00104B95BFE7025A5AF6@host2.tbg.com>
 <3B7D271F.847A41F6@marconi.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi;
What happens to the TTL field in the IP header when a labeled packet goes
through an LSP? Is it decreased at each router or stay the same?



From owner-mpls@UU.NET  Tue Aug 21 12:27:09 2001
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 MAA22831
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:27:09 -0400 (EDT)
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 QQldbd29735;
	Tue, 21 Aug 2001 16:27:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbd09855
	for mpls-outgoing; Tue, 21 Aug 2001 16:27:29 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 QQldbd09847
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:27:25 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 QQldbd07302
	for <mpls@uu.net>; Tue, 21 Aug 2001 16:26:52 GMT
From: Asim.Khan@vf.vodafone.co.uk
Received: from igate2.vodafone.co.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: igate2.vodafone.co.uk [194.62.232.66])
	id QQldbd19390
	for <mpls@uu.net>; Tue, 21 Aug 2001 16:26:51 GMT
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id RAA31973; Tue, 21 Aug 2001 17:26:50 +0100 (BST)
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0009291033@mimesweeper1.vfl.vodafone>;
 Tue, 21 Aug 2001 17:27:02 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <QF0KB5TC>; Tue, 21 Aug 2001 17:22:29 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F530B812BC8@HAMPSTEAD>
To: c-david.escobar@wcom.com
Cc: mpls@UU.NET
Subject: RE: Time to live
Date: Tue, 21 Aug 2001 17:22:28 +0100
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

It stays the same. The routers only look at the label value not the IP
header. When the packet leaves MPLS domain then the normal operation would
apply.

Asim

-----Original Message-----
From: David Escobar [mailto:c-david.escobar@wcom.com]
Sent: 21 August 2001 17:19
To: mpls@UU.NET
Subject: Time to live


Hi;
What happens to the TTL field in the IP header when a labeled packet goes
through an LSP? Is it decreased at each router or stay the same?


From owner-mpls@UU.NET  Tue Aug 21 12:44:21 2001
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 MAA23397
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:44:21 -0400 (EDT)
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 QQldbf23695;
	Tue, 21 Aug 2001 16:45:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbe11403
	for mpls-outgoing; Tue, 21 Aug 2001 16:44:35 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 QQldbe11385
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:44:30 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 QQldbe29043
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:43:34 GMT
Received: from mail.marhold.at by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.marhold.at [194.152.126.85])
	id QQldbe21965
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:43:33 GMT
Received: from AMARHOLD ([192.168.1.33]) by mail.marhold.at
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with SMTP id at; Tue, 21 Aug 2001 18:54:54 +0200
From: "Alexander Marhold" <alexander@marhold.at>
To: <Asim.Khan@vf.vodafone.co.uk>, <c-david.escobar@wcom.com>
Cc: <mpls@UU.NET>
Subject: RE: Time to live
Date: Tue, 21 Aug 2001 18:44:07 +0200
Message-ID: <AFEPKBDEDEAGNIBJKNPJAEFMCNAA.alexander@marhold.at>
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <DDC3D921FB67D211AAD100A0C9E58F530B812BC8@HAMPSTEAD>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello
I want to explain the mechanism a little bit more in detail

FRAME based general:
1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
the label header.
2. the label-TTL is decremented at each hop by 1
3. when it reaches 0 the labelled packet will be dropped and a
TTL-exceeded-ICMP message will be sent if possible
4. at the egress the label-TTL is copied back into the IP-TTL

CELL based general:
1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
the label header.
1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
1b		or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
LSP-setup using downstream on demand label allocation and ordered
lsp-control label setup)
2. then the packet is chopped into cells
3. the egress reassembles the packet and copies the label ttl back into the
IP-TTL

if 1a is used then the ATM-MPLS cloud looks like a 1-hop network

special features:
a) on cisco LSRs there is the possibility to disable the copying of the
IP-TTL to the label-TTL and the label-TTL again starts at 255.
on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
used for the IP-TTL
then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
network

with best regards

Alexander

__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
     __/
    __/   Dipl.Ing. Alexander Marhold MBA
   __/   CCIE #3324, CCNP, CCDP, CCSI #20642
  __/   Core & IP Services <Senior Consultant>
 __/   Mobile: ++43-(0)664-16 28 234
__/   PRO IN http://www.proin.com


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
Asim.Khan@vf.vodafone.co.uk
Sent: Tuesday, August 21, 2001 6:22 PM
To: c-david.escobar@wcom.com
Cc: mpls@UU.NET
Subject: RE: Time to live


It stays the same. The routers only look at the label value not the IP
header. When the packet leaves MPLS domain then the normal operation would
apply.

Asim

-----Original Message-----
From: David Escobar [mailto:c-david.escobar@wcom.com]
Sent: 21 August 2001 17:19
To: mpls@UU.NET
Subject: Time to live


Hi;
What happens to the TTL field in the IP header when a labeled packet goes
through an LSP? Is it decreased at each router or stay the same?



From owner-mpls@UU.NET  Tue Aug 21 12:50:34 2001
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 MAA23561
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:50:34 -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 QQldbf23721;
	Tue, 21 Aug 2001 16:51:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbf12186
	for mpls-outgoing; Tue, 21 Aug 2001 16:50:48 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 QQldbf12175
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:50:42 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 QQldbf18704
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:49:45 GMT
Received: from chmls20.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls20.mediaone.net [24.147.1.156])
	id QQldbf08049
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:49:45 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LGnWx18588;
	Tue, 21 Aug 2001 12:49:32 -0400 (EDT)
Message-ID: <3B82909C.3B4C9E68@mindspring.com>
Date: Tue, 21 Aug 2001 12:47:24 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Asim.Khan@vf.vodafone.co.uk
CC: c-david.escobar@wcom.com, mpls@UU.NET
Subject: Re: Time to live
References: <DDC3D921FB67D211AAD100A0C9E58F530B812BC8@HAMPSTEAD>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sort of.

Yes, the IP header is ignored within the LSP.  But the TTL is
transferred to the label encapsulation where (for Ethernet and
PPP at least) it is decremented at each LSR.  On egress, the
TTL is then transferred back to the IP header.

Where TTL is not included in the label encapsulation (ATM
and FR), TTL is decremented at the LSP ingress (by some
amount between 1 and the number of hops for the LSP - as
determined by 'hop count' in LSP setup, for instance) in the
IP header before encapsulation and forwarding via ATM/FR.

Read RFCs 3031 and 3032.

--
Eric Gray

Asim.Khan@vf.vodafone.co.uk wrote:

> It stays the same. The routers only look at the label value not the IP
> header. When the packet leaves MPLS domain then the normal operation would
> apply.
>
> Asim
>
> -----Original Message-----
> From: David Escobar [mailto:c-david.escobar@wcom.com]
> Sent: 21 August 2001 17:19
> To: mpls@UU.NET
> Subject: Time to live
>
> Hi;
> What happens to the TTL field in the IP header when a labeled packet goes
> through an LSP? Is it decreased at each router or stay the same?



From owner-mpls@UU.NET  Tue Aug 21 12:56:35 2001
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 MAA23697
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:56:34 -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 QQldbf18929;
	Tue, 21 Aug 2001 16:57:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbf12980
	for mpls-outgoing; Tue, 21 Aug 2001 16:56:50 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 QQldbf12973
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:56: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 QQldbf06337
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:55:32 GMT
Received: from chmls20.mediaone.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls20.mediaone.net [24.147.1.156])
	id QQldbf07723
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:55:32 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LGtPx26821;
	Tue, 21 Aug 2001 12:55:26 -0400 (EDT)
Message-ID: <3B829201.4EDA494@mindspring.com>
Date: Tue, 21 Aug 2001 12:53:21 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Alexander Marhold <alexander@marhold.at>
CC: MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
References: <AFEPKBDEDEAGNIBJKNPJAEFMCNAA.alexander@marhold.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Alexander,

    No cigar.  The distinction is not cell verses frame, but rather
whether or not it is possible to incorporate the label in the L2
encapsulation.  Where this is possible, ATM and FR, there is
no TTL capability in the L2 encapsulation.  Not that Frame
Relay is Frame based...

--
Eric Gray

You wrote:

> Hello
> I want to explain the mechanism a little bit more in detail
>
> FRAME based general:
> 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> the label header.
> 2. the label-TTL is decremented at each hop by 1
> 3. when it reaches 0 the labelled packet will be dropped and a
> TTL-exceeded-ICMP message will be sent if possible
> 4. at the egress the label-TTL is copied back into the IP-TTL
>
> CELL based general:
> 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> the label header.
> 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
> 1b              or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
> LSP-setup using downstream on demand label allocation and ordered
> lsp-control label setup)
> 2. then the packet is chopped into cells
> 3. the egress reassembles the packet and copies the label ttl back into the
> IP-TTL
>
> if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
>
> special features:
> a) on cisco LSRs there is the possibility to disable the copying of the
> IP-TTL to the label-TTL and the label-TTL again starts at 255.
> on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
> used for the IP-TTL
> then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> network
>
> with best regards
>
> Alexander
>
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
>      __/
>     __/   Dipl.Ing. Alexander Marhold MBA
>    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
>   __/   Core & IP Services <Senior Consultant>
>  __/   Mobile: ++43-(0)664-16 28 234
> __/   PRO IN http://www.proin.com
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> Asim.Khan@vf.vodafone.co.uk
> Sent: Tuesday, August 21, 2001 6:22 PM
> To: c-david.escobar@wcom.com
> Cc: mpls@UU.NET
> Subject: RE: Time to live
>
> It stays the same. The routers only look at the label value not the IP
> header. When the packet leaves MPLS domain then the normal operation would
> apply.
>
> Asim
>
> -----Original Message-----
> From: David Escobar [mailto:c-david.escobar@wcom.com]
> Sent: 21 August 2001 17:19
> To: mpls@UU.NET
> Subject: Time to live
>
> Hi;
> What happens to the TTL field in the IP header when a labeled packet goes
> through an LSP? Is it decreased at each router or stay the same?



From owner-mpls@UU.NET  Tue Aug 21 12:58:24 2001
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 MAA23770
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 12:58:24 -0400 (EDT)
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 QQldbf13628;
	Tue, 21 Aug 2001 16:59:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbf13114
	for mpls-outgoing; Tue, 21 Aug 2001 16:58:48 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 QQldbf13101
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 16:58:43 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 QQldbf13887
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:57:58 GMT
Received: from harrier.mail.pas.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: harrier.mail.pas.earthlink.net [207.217.121.12])
	id QQldbf20434
	for <mpls@UU.NET>; Tue, 21 Aug 2001 16:57:57 GMT
Received: from jlucianilaptop (mumble.crescentnetworks.com [64.64.148.40])
	by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA09027
	for <mpls@UU.NET>; Tue, 21 Aug 2001 09:57:55 -0700 (PDT)
Message-ID: <029101c12a62$c68151d0$db1da8c0@in.crescentnets.com>
From: "James Luciani" <james_luciani@mindspring.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
References: <8D9BE231086DD41181EF00508B69805201989A10@cnhon1ex1.i.wcom.com.hk> <20010820223852.D2197@che-cse-104.cisco.com>
Subject: Re: Integrating 2 MPLS network
Date: Tue, 21 Aug 2001 13:00:23 -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 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

Depending on your assumptions about the underlying networks and address
spaces, taking a routed hop between ISP-A and ISP-B works just fine.  Of
course, if you are playing games with overlapping address spaces in VPNs you
need NAT-like functionality but if all addresses are globally routable you
are fine.

----- Original Message -----
From: "Eric Osborne" <eosborne@cisco.com>
To: "Tsang, Fatima" <tsang.fatima@wcom.com.hk>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Sent: Monday, August 20, 2001 10:38 PM
Subject: Re: Integrating 2 MPLS network


> On Tue, Aug 21, 2001 at 09:43:40AM +0800, Tsang, Fatima wrote:
> > Dear All,
> >
> > I am new at this, hope you can provide some assistance.
> >
> > I have the following situation:
> >
> > City A, City B, City C
> > City A and City B are on one unique MPLS network by ISP A
> > City B and City C are on another unique MPLS network by ISP B
> >
> > Is there any way that City A can talk to City C via City B through the
> > router B?  If so, is there anything required to be done on the PE's for
this
> > customer?
>
> Depends on what the carriers do.  If both ISP A and ISP B are talking
> to each other, they could run inter-provider MPLS BGP VPN.  But that
> requires a lot to line up between ISP A and ISP B.
>
> Another way to do this is a full mesh of GRE tunnels between cities A,
> B, and C.  Disadvantage is that it's harder to scale to lots of
> cities; advantage is that there's nothing the provider needs to do to
> let this happen.
>
>
>
>
> eric
>
> >
> > Thanks.
> >
> > Greatly appreciated.
> >
> > Thanks,
> > Fatima
>



From owner-mpls@UU.NET  Tue Aug 21 13:04:46 2001
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 NAA24001
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:04:46 -0400 (EDT)
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 QQldbg23840;
	Tue, 21 Aug 2001 17:05:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbg23708
	for mpls-outgoing; Tue, 21 Aug 2001 17:05: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 QQldbg23701
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:05:07 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 QQldbg04110
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:04:53 GMT
From: Satish_Amara@3com.com
Received: from topaz.3com.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: topaz.3com.com [192.156.136.158])
	id QQldbg00057
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:04:52 GMT
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7LH2LG25724;
	Tue, 21 Aug 2001 10:02:21 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104])
	by opal.3com.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f7LH4l709127;
	Tue, 21 Aug 2001 10:04:47 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256AAF.005DCEDB ; Tue, 21 Aug 2001 10:04:38 -0700
X-Lotus-FromDomain: 3COM
To: Asim.Khan@vf.vodafone.co.uk
cc: c-david.escobar@wcom.com, mpls@UU.NET
Message-ID: <88256AAF.005DCAD1.00@hqoutbound.ops.3com.com>
Date: Tue, 21 Aug 2001 12:05:07 -0500
Subject: RE: Time to live
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



The ingress router copies the TTL field from IP  header. After that the
intermediate label
switch routers decrement TTL in label field. If TTL is zero packet is dropped.

Satish Amara




Asim.Khan@vf.vodafone.co.uk on 08/21/2001 11:22:28 AM

Sent by:  Asim.Khan@vf.vodafone.co.uk


To:   c-david.escobar@wcom.com
cc:   mpls@UU.NET (Satish Amara/MW/US/3Com)
Subject:  RE: Time to live



It stays the same. The routers only look at the label value not the IP
header. When the packet leaves MPLS domain then the normal operation would
apply.

Asim

-----Original Message-----
From: David Escobar [mailto:c-david.escobar@wcom.com]
Sent: 21 August 2001 17:19
To: mpls@UU.NET
Subject: Time to live


Hi;
What happens to the TTL field in the IP header when a labeled packet goes
through an LSP? Is it decreased at each router or stay the same?






From owner-mpls@UU.NET  Tue Aug 21 13:08:01 2001
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 NAA24143
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:08: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 QQldbg18953;
	Tue, 21 Aug 2001 17:08:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbg26911
	for mpls-outgoing; Tue, 21 Aug 2001 17:08:07 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 QQldbg26313
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:07:55 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 QQldbg09022
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:07:00 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbg03061
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:06:59 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA11575 for mpls@uu.net; Tue, 21 Aug 2001 13:06:58 -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 QQldbg23925
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:06:33 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 QQldbg05263
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:04:59 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQldbg00206
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:04:59 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7LH4vQ23290;
	Tue, 21 Aug 2001 10:04:57 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-53.cisco.com [144.254.46.54])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AAH47436;
	Tue, 21 Aug 2001 10:04:52 -0700 (PDT)
Message-ID: <3B82942E.481A1A45@cisco.com>
Date: Tue, 21 Aug 2001 10:02:38 -0700
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: Yousuf Hasan <yhasan@cisco.com>
CC: Gangadharan Ramakrishnan <gangadharanr@hotmail.com>, mpls@UU.NET,
        morekonda@hotmail.com, muthu@coronanetworks.com
Subject: Re: What is the diferrence between LDP tunnel and MPLS LSPtunnel.
References: <4.3.2.7.2.20010821003851.05bbd0c0@ce-nfs-1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Some time back following one of the references from Lou I started to use
terms prefix-LSPs to refer to LSPs build with LDP and TE-LSPs for those
LSPs build with RSVP-TE. It makes clear distinction. Otherwise using the
term mpls LSP is very confusing as their characteristics are very
different.

R.

> Yousuf Hasan wrote:
> 
> Think it's the same notation as an LDP LSP which will follow the IGP as opposed to the TE "tunnel" which will be setup based on constraints like Bandwidth
> 
> You can run LDP over a tunnel though
> Thanks
> 
> -Yousuf
> 
> At 12:04 AM 8/21/2001 +0000, Gangadharan Ramakrishnan wrote:
> >Hi,
> >
> >I can understand LSP tunnel. But, i don't understand LDP tunnel? Is there anything called LDP tunnel? If, there can anyone expalin it in breif. Note: Juniper is using terminology.
> >
> >Cheers,
> >ganges....
> >
> >_________________________________________________________________
> >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Tue Aug 21 13:13:22 2001
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 NAA24301
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:13:22 -0400 (EDT)
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 QQldbg07651;
	Tue, 21 Aug 2001 17:14:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbg03028
	for mpls-outgoing; Tue, 21 Aug 2001 17:13: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 QQldbg02996
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:13:16 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 QQldbg27638
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:12:23 GMT
Received: from chmls20.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls20.mediaone.net [24.147.1.156])
	id QQldbg10979
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:12:23 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LHCMx21389;
	Tue, 21 Aug 2001 13:12:22 -0400 (EDT)
Message-ID: <3B8295F9.64BF16CB@mindspring.com>
Date: Tue, 21 Aug 2001 13:10:17 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
References: <AFEPKBDEDEAGNIBJKNPJAEFMCNAA.alexander@marhold.at> <3B829201.4EDA494@mindspring.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Below, the last sentence was supposed to be "Note that Frame
Relay ..."

--
Eric Gray

Eric W Gray wrote:

> Alexander,
>
>     No cigar.  The distinction is not cell verses frame, but rather
> whether or not it is possible to incorporate the label in the L2
> encapsulation.  Where this is possible, ATM and FR, there is
> no TTL capability in the L2 encapsulation.  Not that Frame
> Relay is Frame based...
>
> --
> Eric Gray
>
> You wrote:
>
> > Hello
> > I want to explain the mechanism a little bit more in detail
> >
> > FRAME based general:
> > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > the label header.
> > 2. the label-TTL is decremented at each hop by 1
> > 3. when it reaches 0 the labelled packet will be dropped and a
> > TTL-exceeded-ICMP message will be sent if possible
> > 4. at the egress the label-TTL is copied back into the IP-TTL
> >
> > CELL based general:
> > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > the label header.
> > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
> > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
> > LSP-setup using downstream on demand label allocation and ordered
> > lsp-control label setup)
> > 2. then the packet is chopped into cells
> > 3. the egress reassembles the packet and copies the label ttl back into the
> > IP-TTL
> >
> > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> >
> > special features:
> > a) on cisco LSRs there is the possibility to disable the copying of the
> > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
> > used for the IP-TTL
> > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > network
> >
> > with best regards
> >
> > Alexander
> >
> > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> >      __/
> >     __/   Dipl.Ing. Alexander Marhold MBA
> >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> >   __/   Core & IP Services <Senior Consultant>
> >  __/   Mobile: ++43-(0)664-16 28 234
> > __/   PRO IN http://www.proin.com
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > Asim.Khan@vf.vodafone.co.uk
> > Sent: Tuesday, August 21, 2001 6:22 PM
> > To: c-david.escobar@wcom.com
> > Cc: mpls@UU.NET
> > Subject: RE: Time to live
> >
> > It stays the same. The routers only look at the label value not the IP
> > header. When the packet leaves MPLS domain then the normal operation would
> > apply.
> >
> > Asim
> >
> > -----Original Message-----
> > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > Sent: 21 August 2001 17:19
> > To: mpls@UU.NET
> > Subject: Time to live
> >
> > Hi;
> > What happens to the TTL field in the IP header when a labeled packet goes
> > through an LSP? Is it decreased at each router or stay the same?



From owner-mpls@UU.NET  Tue Aug 21 13:16:20 2001
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 NAA24375
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:16:19 -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 QQldbh01389;
	Tue, 21 Aug 2001 17:16:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbh03547
	for mpls-outgoing; Tue, 21 Aug 2001 17:16: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 QQldbh03536
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:16:18 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 QQldbh28342
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:15:46 GMT
Received: from chmls20.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls20.mediaone.net [24.147.1.156])
	id QQldbh15730
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:15:46 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LHFix26362;
	Tue, 21 Aug 2001 13:15:44 -0400 (EDT)
Message-ID: <3B8296C0.6A34821E@mindspring.com>
Date: Tue, 21 Aug 2001 13:13:36 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: raszuk@cisco.com
CC: Yousuf Hasan <yhasan@cisco.com>,
        Gangadharan Ramakrishnan <gangadharanr@hotmail.com>, mpls@UU.NET,
        morekonda@hotmail.com, muthu@coronanetworks.com
Subject: Re: What is the diferrence between LDP tunnel and MPLS LSPtunnel.
References: <4.3.2.7.2.20010821003851.05bbd0c0@ce-nfs-1.cisco.com> <3B82942E.481A1A45@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Also, some time back, Tony Li pointed out that it is possible to use
RSVP-TE to create prefix LSPs.  So this is not sufficient distinction.

--
Eric Gray

Robert Raszuk wrote:

> Some time back following one of the references from Lou I started to use
> terms prefix-LSPs to refer to LSPs build with LDP and TE-LSPs for those
> LSPs build with RSVP-TE. It makes clear distinction. Otherwise using the
> term mpls LSP is very confusing as their characteristics are very
> different.
>
> R.
>
> > Yousuf Hasan wrote:
> >
> > Think it's the same notation as an LDP LSP which will follow the IGP as opposed to the TE "tunnel" which will be setup based on constraints like Bandwidth
> >
> > You can run LDP over a tunnel though
> > Thanks
> >
> > -Yousuf
> >
> > At 12:04 AM 8/21/2001 +0000, Gangadharan Ramakrishnan wrote:
> > >Hi,
> > >
> > >I can understand LSP tunnel. But, i don't understand LDP tunnel? Is there anything called LDP tunnel? If, there can anyone expalin it in breif. Note: Juniper is using terminology.
> > >
> > >Cheers,
> > >ganges....
> > >
> > >_________________________________________________________________
> > >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Tue Aug 21 13:30:55 2001
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 NAA24756
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:30:54 -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 QQldbi08739;
	Tue, 21 Aug 2001 17:32:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbi05197
	for mpls-outgoing; Tue, 21 Aug 2001 17:31: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 QQldbi05180
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:31:18 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 QQldbi02892
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:30:58 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbi07216
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:30:58 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA14357 for mpls@uu.net; Tue, 21 Aug 2001 13:30:56 -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 QQldbi05039
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:30:46 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 QQldbi02114
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:30:23 GMT
Received: from ray.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldbi21065
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:30:22 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7LHQ6S01270;
	Tue, 21 Aug 2001 10:26:06 -0700
Date: Tue, 21 Aug 2001 10:26:06 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Eric W Gray <ewgray@mindspring.com>
cc: Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
In-Reply-To: <3B8295F9.64BF16CB@mindspring.com>
Message-ID: <Pine.LNX.4.33.0108211024470.1223-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

There is also an option that we don't copy the MPLS TTL back to IP TTL.
It makes IP think the MPLS LSP is only one hop.

Thanks,
Ray

On Tue, 21 Aug 2001, Eric W Gray wrote:

> Date: Tue, 21 Aug 2001 13:10:17 -0400
> From: Eric W Gray <ewgray@mindspring.com>
> To: Alexander Marhold <alexander@marhold.at>,
>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: Re: Time to live
>
> Below, the last sentence was supposed to be "Note that Frame
> Relay ..."
>
> --
> Eric Gray
>
> Eric W Gray wrote:
>
> > Alexander,
> >
> >     No cigar.  The distinction is not cell verses frame, but rather
> > whether or not it is possible to incorporate the label in the L2
> > encapsulation.  Where this is possible, ATM and FR, there is
> > no TTL capability in the L2 encapsulation.  Not that Frame
> > Relay is Frame based...
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > Hello
> > > I want to explain the mechanism a little bit more in detail
> > >
> > > FRAME based general:
> > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > the label header.
> > > 2. the label-TTL is decremented at each hop by 1
> > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > TTL-exceeded-ICMP message will be sent if possible
> > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > >
> > > CELL based general:
> > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > the label header.
> > > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
> > > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
> > > LSP-setup using downstream on demand label allocation and ordered
> > > lsp-control label setup)
> > > 2. then the packet is chopped into cells
> > > 3. the egress reassembles the packet and copies the label ttl back into the
> > > IP-TTL
> > >
> > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > >
> > > special features:
> > > a) on cisco LSRs there is the possibility to disable the copying of the
> > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
> > > used for the IP-TTL
> > > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > > network
> > >
> > > with best regards
> > >
> > > Alexander
> > >
> > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > >      __/
> > >     __/   Dipl.Ing. Alexander Marhold MBA
> > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > >   __/   Core & IP Services <Senior Consultant>
> > >  __/   Mobile: ++43-(0)664-16 28 234
> > > __/   PRO IN http://www.proin.com
> > >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > Asim.Khan@vf.vodafone.co.uk
> > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > To: c-david.escobar@wcom.com
> > > Cc: mpls@UU.NET
> > > Subject: RE: Time to live
> > >
> > > It stays the same. The routers only look at the label value not the IP
> > > header. When the packet leaves MPLS domain then the normal operation would
> > > apply.
> > >
> > > Asim
> > >
> > > -----Original Message-----
> > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > Sent: 21 August 2001 17:19
> > > To: mpls@UU.NET
> > > Subject: Time to live
> > >
> > > Hi;
> > > What happens to the TTL field in the IP header when a labeled packet goes
> > > through an LSP? Is it decreased at each router or stay the same?
>



From owner-mpls@UU.NET  Tue Aug 21 13:58:59 2001
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 NAA25656
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 13:58:59 -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 QQldbj03807;
	Tue, 21 Aug 2001 17:59:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbj07506
	for mpls-outgoing; Tue, 21 Aug 2001 17:59:10 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 QQldbj07498
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 17:59:06 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 QQldbj06698
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:58:15 GMT
Received: from chmls06.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls06.mediaone.net [24.147.1.144])
	id QQldbj15612
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:58:13 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LHwCm07724;
	Tue, 21 Aug 2001 13:58:13 -0400 (EDT)
Message-ID: <3B82A0BB.427572F3@mindspring.com>
Date: Tue, 21 Aug 2001 13:56:11 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Ray Qiu <rayq@riverstonenet.com>
CC: MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
References: <Pine.LNX.4.33.0108211024470.1223-100000@ray.riverstonenet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes, that has been suggested as a logical extension of the 'Pipe'
model in DiffServ.  I don't recall where that effort is at right now
but I don't think the work has been adopted by either the MPLS
or CCAMP working groups.  Do you know?

--
Eric Gray

Ray Qiu wrote:

> There is also an option that we don't copy the MPLS TTL back to IP TTL.
> It makes IP think the MPLS LSP is only one hop.
>
> Thanks,
> Ray
>
> On Tue, 21 Aug 2001, Eric W Gray wrote:
>
> > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > From: Eric W Gray <ewgray@mindspring.com>
> > To: Alexander Marhold <alexander@marhold.at>,
> >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > Subject: Re: Time to live
> >
> > Below, the last sentence was supposed to be "Note that Frame
> > Relay ..."
> >
> > --
> > Eric Gray
> >
> > Eric W Gray wrote:
> >
> > > Alexander,
> > >
> > >     No cigar.  The distinction is not cell verses frame, but rather
> > > whether or not it is possible to incorporate the label in the L2
> > > encapsulation.  Where this is possible, ATM and FR, there is
> > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > Relay is Frame based...
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Hello
> > > > I want to explain the mechanism a little bit more in detail
> > > >
> > > > FRAME based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > > the label header.
> > > > 2. the label-TTL is decremented at each hop by 1
> > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > TTL-exceeded-ICMP message will be sent if possible
> > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > >
> > > > CELL based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > > the label header.
> > > > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
> > > > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
> > > > LSP-setup using downstream on demand label allocation and ordered
> > > > lsp-control label setup)
> > > > 2. then the packet is chopped into cells
> > > > 3. the egress reassembles the packet and copies the label ttl back into the
> > > > IP-TTL
> > > >
> > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > > >
> > > > special features:
> > > > a) on cisco LSRs there is the possibility to disable the copying of the
> > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
> > > > used for the IP-TTL
> > > > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > > > network
> > > >
> > > > with best regards
> > > >
> > > > Alexander
> > > >
> > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > >      __/
> > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > >   __/   Core & IP Services <Senior Consultant>
> > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > __/   PRO IN http://www.proin.com
> > > >
> > > > -----Original Message-----
> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > Asim.Khan@vf.vodafone.co.uk
> > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > To: c-david.escobar@wcom.com
> > > > Cc: mpls@UU.NET
> > > > Subject: RE: Time to live
> > > >
> > > > It stays the same. The routers only look at the label value not the IP
> > > > header. When the packet leaves MPLS domain then the normal operation would
> > > > apply.
> > > >
> > > > Asim
> > > >
> > > > -----Original Message-----
> > > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > > Sent: 21 August 2001 17:19
> > > > To: mpls@UU.NET
> > > > Subject: Time to live
> > > >
> > > > Hi;
> > > > What happens to the TTL field in the IP header when a labeled packet goes
> > > > through an LSP? Is it decreased at each router or stay the same?
> >



From owner-mpls@UU.NET  Tue Aug 21 14:29:25 2001
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 OAA26775
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 14:29:24 -0400 (EDT)
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 QQldbm11207;
	Tue, 21 Aug 2001 18:30:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbl28792
	for mpls-outgoing; Tue, 21 Aug 2001 18:29:46 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 QQldbl28786
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:29: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 QQldbl11993
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:28:16 GMT
Received: from exchsrv2.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: proxy141.cosinecom.com [63.88.104.141])
	id QQldbl07694
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:28:09 GMT
Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19)
	id <Q6WXWC5C>; Tue, 21 Aug 2001 11:28:05 -0700
Message-ID: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng>
From: Anoop Ghanwani <anoop@cosinecom.com>
To: "'Ray Qiu'" <rayq@riverstonenet.com>,
        Eric W Gray
	 <ewgray@mindspring.com>
Cc: Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: RE: Time to live
Date: Tue, 21 Aug 2001 11:27:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12A6F.004801A0"
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_01C12A6F.004801A0
Content-Type: text/plain;
	charset="iso-8859-1"


I think that's a really bad idea.  TTL is there to
protect the network from packets that might be in a loop.
Nesting TTLs to that the outer one is used within the
tunnel while the inner one stays the same could
delay the time the it takes for TTL to protect the packet.

For instance, consider the following topology.

r1 -- r2 -- r3 -- r4 -- r5
       |                 |
      r9 -- r8 -- r7 -- r6

Let's say the path from r3 to r8 is implemented by a
tunnel (in pipe mode).  The packet first hits r2, enters
the tunnel at r3, and then gets to r8. r3-r8 is treated as 
a single hop because the TTL in the IP header is only 
decremented by 1.  In this example the looping packet 
gets to traverse the loop many more times than it 
would have if we were just operating on TTL as specified 
in RFC 3032 (> 60 times versus < 30 times). 

Thus far, the argument in favor of hiding TTL has been 
that it helps hide the network topology and gives the user
a perception of traversing fewer hops.  It seems like
a lame reason because the real measure of performance 
is actually latency.  

Just my $0.02 ;-)
-Anoop


> -----Original Message-----
> From: Ray Qiu [mailto:rayq@riverstonenet.com]
> Sent: Tuesday, August 21, 2001 10:26 AM
> To: Eric W Gray
> Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> Subject: Re: Time to live
> 
> 
> There is also an option that we don't copy the MPLS TTL back 
> to IP TTL.
> It makes IP think the MPLS LSP is only one hop.
> 
> Thanks,
> Ray
> 
> On Tue, 21 Aug 2001, Eric W Gray wrote:
> 
> > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > From: Eric W Gray <ewgray@mindspring.com>
> > To: Alexander Marhold <alexander@marhold.at>,
> >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > Subject: Re: Time to live
> >
> > Below, the last sentence was supposed to be "Note that Frame
> > Relay ..."
> >
> > --
> > Eric Gray
> >
> > Eric W Gray wrote:
> >
> > > Alexander,
> > >
> > >     No cigar.  The distinction is not cell verses frame, 
> but rather
> > > whether or not it is possible to incorporate the label in the L2
> > > encapsulation.  Where this is possible, ATM and FR, there is
> > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > Relay is Frame based...
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Hello
> > > > I want to explain the mechanism a little bit more in detail
> > > >
> > > > FRAME based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > the label header.
> > > > 2. the label-TTL is decremented at each hop by 1
> > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > TTL-exceeded-ICMP message will be sent if possible
> > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > >
> > > > CELL based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > the label header.
> > > > 1a. the ingress LSR to the ATM-MPLS cloud either 
> decrements the TTL by 1
> > > > 1b              or by the amount of ATM_MPLS hops of 
> the LSP ( this he knows from the
> > > > LSP-setup using downstream on demand label allocation 
> and ordered
> > > > lsp-control label setup)
> > > > 2. then the packet is chopped into cells
> > > > 3. the egress reassembles the packet and copies the 
> label ttl back into the
> > > > IP-TTL
> > > >
> > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > > >
> > > > special features:
> > > > a) on cisco LSRs there is the possibility to disable 
> the copying of the
> > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > on the egress the smaller of the 2 TTL-values ( label 
> and IP-header) will be
> > > > used for the IP-TTL
> > > > then for traceroute the MPLS cloud looks like a 1-hop 
> (2-hop with PHP)
> > > > network
> > > >
> > > > with best regards
> > > >
> > > > Alexander
> > > >
> > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > >      __/
> > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > >   __/   Core & IP Services <Senior Consultant>
> > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > __/   PRO IN http://www.proin.com
> > > >
> > > > -----Original Message-----
> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > Asim.Khan@vf.vodafone.co.uk
> > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > To: c-david.escobar@wcom.com
> > > > Cc: mpls@UU.NET
> > > > Subject: RE: Time to live
> > > >
> > > > It stays the same. The routers only look at the label 
> value not the IP
> > > > header. When the packet leaves MPLS domain then the 
> normal operation would
> > > > apply.
> > > >
> > > > Asim
> > > >
> > > > -----Original Message-----
> > > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > > Sent: 21 August 2001 17:19
> > > > To: mpls@UU.NET
> > > > Subject: Time to live
> > > >
> > > > Hi;
> > > > What happens to the TTL field in the IP header when a 
> labeled packet goes
> > > > through an LSP? Is it decreased at each router or stay the same?
> >
> 
############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

------_=_NextPart_001_01C12A6F.004801A0
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>RE: Time to live</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I think that's a really bad idea.&nbsp; TTL is there =
to</FONT>
<BR><FONT SIZE=3D2>protect the network from packets that might be in a =
loop.</FONT>
<BR><FONT SIZE=3D2>Nesting TTLs to that the outer one is used within =
the</FONT>
<BR><FONT SIZE=3D2>tunnel while the inner one stays the same =
could</FONT>
<BR><FONT SIZE=3D2>delay the time the it takes for TTL to protect the =
packet.</FONT>
</P>

<P><FONT SIZE=3D2>For instance, consider the following topology.</FONT>
</P>

<P><FONT SIZE=3D2>r1 -- r2 -- r3 -- r4 -- r5</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r9 -- r8 -- r7 -- =
r6</FONT>
</P>

<P><FONT SIZE=3D2>Let's say the path from r3 to r8 is implemented by =
a</FONT>
<BR><FONT SIZE=3D2>tunnel (in pipe mode).&nbsp; The packet first hits =
r2, enters</FONT>
<BR><FONT SIZE=3D2>the tunnel at r3, and then gets to r8. r3-r8 is =
treated as </FONT>
<BR><FONT SIZE=3D2>a single hop because the TTL in the IP header is =
only </FONT>
<BR><FONT SIZE=3D2>decremented by 1.&nbsp; In this example the looping =
packet </FONT>
<BR><FONT SIZE=3D2>gets to traverse the loop many more times than it =
</FONT>
<BR><FONT SIZE=3D2>would have if we were just operating on TTL as =
specified </FONT>
<BR><FONT SIZE=3D2>in RFC 3032 (&gt; 60 times versus &lt; 30 times). =
</FONT>
</P>

<P><FONT SIZE=3D2>Thus far, the argument in favor of hiding TTL has =
been </FONT>
<BR><FONT SIZE=3D2>that it helps hide the network topology and gives =
the user</FONT>
<BR><FONT SIZE=3D2>a perception of traversing fewer hops.&nbsp; It =
seems like</FONT>
<BR><FONT SIZE=3D2>a lame reason because the real measure of =
performance </FONT>
<BR><FONT SIZE=3D2>is actually latency.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Just my $0.02 ;-)</FONT>
<BR><FONT SIZE=3D2>-Anoop</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ray Qiu [<A =
HREF=3D"mailto:rayq@riverstonenet.com">mailto:rayq@riverstonenet.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, August 21, 2001 10:26 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Eric W Gray</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Alexander Marhold; MultiProtocol Label =
Switching Mailing List</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Time to live</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is also an option that we don't copy the =
MPLS TTL back </FONT>
<BR><FONT SIZE=3D2>&gt; to IP TTL.</FONT>
<BR><FONT SIZE=3D2>&gt; It makes IP think the MPLS LSP is only one =
hop.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Ray</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, 21 Aug 2001, Eric W Gray wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Date: Tue, 21 Aug 2001 13:10:17 =
-0400</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Eric W Gray =
&lt;ewgray@mindspring.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Alexander Marhold =
&lt;alexander@marhold.at&gt;,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
MultiProtocol Label Switching Mailing List &lt;mpls@UU.NET&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: Time to live</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Below, the last sentence was supposed to =
be &quot;Note that Frame</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Relay ...&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Eric Gray</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Eric W Gray wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Alexander,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; No =
cigar.&nbsp; The distinction is not cell verses frame, </FONT>
<BR><FONT SIZE=3D2>&gt; but rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; whether or not it is possible to =
incorporate the label in the L2</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; encapsulation.&nbsp; Where this is =
possible, ATM and FR, there is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; no TTL capability in the L2 =
encapsulation.&nbsp; Not that Frame</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Relay is Frame based...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Eric Gray</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; You wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Hello</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I want to explain the mechanism =
a little bit more in detail</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; FRAME based general:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 1. normally at the ingress LSR =
the IP-TTL is copied </FONT>
<BR><FONT SIZE=3D2>&gt; into the TTL-field of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; the label header.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 2. the label-TTL is decremented =
at each hop by 1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 3. when it reaches 0 the =
labelled packet will be dropped and a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; TTL-exceeded-ICMP message will =
be sent if possible</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 4. at the egress the label-TTL =
is copied back into the IP-TTL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; CELL based general:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 1. normally at the ingress LSR =
the IP-TTL is copied </FONT>
<BR><FONT SIZE=3D2>&gt; into the TTL-field of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; the label header.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 1a. the ingress LSR to the =
ATM-MPLS cloud either </FONT>
<BR><FONT SIZE=3D2>&gt; decrements the TTL by 1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
1b&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; or by the amount of ATM_MPLS hops of </FONT>
<BR><FONT SIZE=3D2>&gt; the LSP ( this he knows from the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; LSP-setup using downstream on =
demand label allocation </FONT>
<BR><FONT SIZE=3D2>&gt; and ordered</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; lsp-control label setup)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 2. then the packet is chopped =
into cells</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 3. the egress reassembles the =
packet and copies the </FONT>
<BR><FONT SIZE=3D2>&gt; label ttl back into the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; IP-TTL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; if 1a is used then the ATM-MPLS =
cloud looks like a 1-hop network</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; special features:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a) on cisco LSRs there is the =
possibility to disable </FONT>
<BR><FONT SIZE=3D2>&gt; the copying of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; IP-TTL to the label-TTL and the =
label-TTL again starts at 255.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; on the egress the smaller of the =
2 TTL-values ( label </FONT>
<BR><FONT SIZE=3D2>&gt; and IP-header) will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; used for the IP-TTL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; then for traceroute the MPLS =
cloud looks like a 1-hop </FONT>
<BR><FONT SIZE=3D2>&gt; (2-hop with PHP)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; network</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; with best regards</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Alexander</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
__/</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
__/&nbsp;&nbsp; Dipl.Ing. Alexander Marhold MBA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; =
__/&nbsp;&nbsp; CCIE #3324, CCNP, CCDP, CCSI #20642</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp; __/&nbsp;&nbsp; Core =
&amp; IP Services &lt;Senior Consultant&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp; __/&nbsp;&nbsp; Mobile: =
++43-(0)664-16 28 234</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; __/&nbsp;&nbsp; PRO IN <A =
HREF=3D"http://www.proin.com" =
TARGET=3D"_blank">http://www.proin.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: owner-mpls@UU.NET [<A =
HREF=3D"mailto:owner-mpls@UU.NET">mailto:owner-mpls@UU.NET</A>]On =
Behalf Of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
Asim.Khan@vf.vodafone.co.uk</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: Tuesday, August 21, 2001 =
6:22 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: =
c-david.escobar@wcom.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: RE: Time to live</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; It stays the same. The routers =
only look at the label </FONT>
<BR><FONT SIZE=3D2>&gt; value not the IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; header. When the packet leaves =
MPLS domain then the </FONT>
<BR><FONT SIZE=3D2>&gt; normal operation would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; apply.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Asim</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: David Escobar [<A =
HREF=3D"mailto:c-david.escobar@wcom.com">mailto:c-david.escobar@wcom.com=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: 21 August 2001 =
17:19</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: Time to live</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Hi;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; What happens to the TTL field in =
the IP header when a </FONT>
<BR><FONT SIZE=3D2>&gt; labeled packet goes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; through an LSP? Is it decreased =
at each router or stay the same?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>###############################################################=
####################################### This email communication may =
contain CONFIDENTIAL INFORMATION and is intended only for the use of =
the intended recipients identified above.&nbsp; If you are not the =
intended recipient of this communication, you must not use, disclose, =
distribute, copy or print this email. If you have received this =
communication in error, please immediately notify the sender by reply =
email, delete the communication and destroy all copies. =
########################################################################=
##############################</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A6F.004801A0--


From owner-mpls@UU.NET  Tue Aug 21 14:43:25 2001
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 OAA27365
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 14:43:25 -0400 (EDT)
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 QQldbm05651;
	Tue, 21 Aug 2001 18:44:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbm29997
	for mpls-outgoing; Tue, 21 Aug 2001 18:43: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 QQldbm29991
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:43:28 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 QQldbm11371
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:41:57 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbm20462
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:41:56 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA20385 for mpls@uu.net; Tue, 21 Aug 2001 14:41:55 -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 QQldbm29846
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:41:30 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 QQldbm14525
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:41:11 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 QQldbm00728
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:41:10 GMT
Received: (qmail 20516 invoked by uid 104); 21 Aug 2001 18:41:10 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.422712 secs); 21/08/2001 11:41:09
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 21 Aug 2001 18:41:09 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f7LIf9I09046;
	Tue, 21 Aug 2001 11:41:09 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <RBMNMB3K>; Tue, 21 Aug 2001 11:42:04 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CC99A@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric W Gray'" <ewgray@mindspring.com>,
        Ray Qiu
	 <rayq@riverstonenet.com>
Cc: MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: RE: Time to live
Date: Tue, 21 Aug 2001 11:42:03 -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,

A new draft by Bora Akyol and Puneet Agarwal will be published soon that covers this.

-Shahram

> -----Original Message-----
> From: Eric W Gray [mailto:ewgray@mindspring.com]
> Sent: Tuesday, August 21, 2001 1:56 PM
> To: Ray Qiu
> Cc: MultiProtocol Label Switching Mailing List
> Subject: Re: Time to live
> 
> 
> Yes, that has been suggested as a logical extension of the 'Pipe'
> model in DiffServ.  I don't recall where that effort is at right now
> but I don't think the work has been adopted by either the MPLS
> or CCAMP working groups.  Do you know?
> 
> --
> Eric Gray
> 
> Ray Qiu wrote:
> 
> > There is also an option that we don't copy the MPLS TTL 
> back to IP TTL.
> > It makes IP think the MPLS LSP is only one hop.
> >
> > Thanks,
> > Ray
> >
> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >
> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > > From: Eric W Gray <ewgray@mindspring.com>
> > > To: Alexander Marhold <alexander@marhold.at>,
> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > > Subject: Re: Time to live
> > >
> > > Below, the last sentence was supposed to be "Note that Frame
> > > Relay ..."
> > >
> > > --
> > > Eric Gray
> > >
> > > Eric W Gray wrote:
> > >
> > > > Alexander,
> > > >
> > > >     No cigar.  The distinction is not cell verses 
> frame, but rather
> > > > whether or not it is possible to incorporate the label in the L2
> > > > encapsulation.  Where this is possible, ATM and FR, there is
> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > > Relay is Frame based...
> > > >
> > > > --
> > > > Eric Gray
> > > >
> > > > You wrote:
> > > >
> > > > > Hello
> > > > > I want to explain the mechanism a little bit more in detail
> > > > >
> > > > > FRAME based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > > the label header.
> > > > > 2. the label-TTL is decremented at each hop by 1
> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > > TTL-exceeded-ICMP message will be sent if possible
> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > > >
> > > > > CELL based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied 
> into the TTL-field of
> > > > > the label header.
> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either 
> decrements the TTL by 1
> > > > > 1b              or by the amount of ATM_MPLS hops of 
> the LSP ( this he knows from the
> > > > > LSP-setup using downstream on demand label allocation 
> and ordered
> > > > > lsp-control label setup)
> > > > > 2. then the packet is chopped into cells
> > > > > 3. the egress reassembles the packet and copies the 
> label ttl back into the
> > > > > IP-TTL
> > > > >
> > > > > if 1a is used then the ATM-MPLS cloud looks like a 
> 1-hop network
> > > > >
> > > > > special features:
> > > > > a) on cisco LSRs there is the possibility to disable 
> the copying of the
> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > > on the egress the smaller of the 2 TTL-values ( label 
> and IP-header) will be
> > > > > used for the IP-TTL
> > > > > then for traceroute the MPLS cloud looks like a 1-hop 
> (2-hop with PHP)
> > > > > network
> > > > >
> > > > > with best regards
> > > > >
> > > > > Alexander
> > > > >
> > > > > 
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > > >      __/
> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > > >   __/   Core & IP Services <Senior Consultant>
> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > > __/   PRO IN http://www.proin.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > > Asim.Khan@vf.vodafone.co.uk
> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > > To: c-david.escobar@wcom.com
> > > > > Cc: mpls@UU.NET
> > > > > Subject: RE: Time to live
> > > > >
> > > > > It stays the same. The routers only look at the label 
> value not the IP
> > > > > header. When the packet leaves MPLS domain then the 
> normal operation would
> > > > > apply.
> > > > >
> > > > > Asim
> > > > >
> > > > > -----Original Message-----
> > > > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > > > Sent: 21 August 2001 17:19
> > > > > To: mpls@UU.NET
> > > > > Subject: Time to live
> > > > >
> > > > > Hi;
> > > > > What happens to the TTL field in the IP header when a 
> labeled packet goes
> > > > > through an LSP? Is it decreased at each router or 
> stay the same?
> > >
> 



From owner-mpls@UU.NET  Tue Aug 21 14:48:01 2001
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 OAA27572
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 14:48: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 QQldbn16149;
	Tue, 21 Aug 2001 18:48:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbn00802
	for mpls-outgoing; Tue, 21 Aug 2001 18:48: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 QQldbn00767
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:47:59 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 QQldbn21561
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:46:37 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbn27173
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:46:37 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA21155 for mpls@uu.net; Tue, 21 Aug 2001 14:46:35 -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 QQldbn00333
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:45: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 QQldbn02151
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:45:02 GMT
Received: from ray.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldbn24752
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:45:01 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7LIekk01409;
	Tue, 21 Aug 2001 11:40:46 -0700
Date: Tue, 21 Aug 2001 11:40:44 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Eric W Gray <ewgray@mindspring.com>
cc: MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
In-Reply-To: <3B82A0BB.427572F3@mindspring.com>
Message-ID: <Pine.LNX.4.33.0108211138440.1223-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

I think it is now a proprietary implementation.  Juniper and Riverstone
both support this feature.

Thanks,
Ray

On Tue, 21 Aug 2001, Eric W Gray wrote:

> Date: Tue, 21 Aug 2001 13:56:11 -0400
> From: Eric W Gray <ewgray@mindspring.com>
> To: Ray Qiu <rayq@riverstonenet.com>
> Cc: MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: Re: Time to live
>
> Yes, that has been suggested as a logical extension of the 'Pipe'
> model in DiffServ.  I don't recall where that effort is at right now
> but I don't think the work has been adopted by either the MPLS
> or CCAMP working groups.  Do you know?
>
> --
> Eric Gray
>
> Ray Qiu wrote:
>
> > There is also an option that we don't copy the MPLS TTL back to IP TTL.
> > It makes IP think the MPLS LSP is only one hop.
> >
> > Thanks,
> > Ray
> >
> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >
> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > > From: Eric W Gray <ewgray@mindspring.com>
> > > To: Alexander Marhold <alexander@marhold.at>,
> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > > Subject: Re: Time to live
> > >
> > > Below, the last sentence was supposed to be "Note that Frame
> > > Relay ..."
> > >
> > > --
> > > Eric Gray
> > >
> > > Eric W Gray wrote:
> > >
> > > > Alexander,
> > > >
> > > >     No cigar.  The distinction is not cell verses frame, but rather
> > > > whether or not it is possible to incorporate the label in the L2
> > > > encapsulation.  Where this is possible, ATM and FR, there is
> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > > Relay is Frame based...
> > > >
> > > > --
> > > > Eric Gray
> > > >
> > > > You wrote:
> > > >
> > > > > Hello
> > > > > I want to explain the mechanism a little bit more in detail
> > > > >
> > > > > FRAME based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > > > the label header.
> > > > > 2. the label-TTL is decremented at each hop by 1
> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > > TTL-exceeded-ICMP message will be sent if possible
> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > > >
> > > > > CELL based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field of
> > > > > the label header.
> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by 1
> > > > > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he knows from the
> > > > > LSP-setup using downstream on demand label allocation and ordered
> > > > > lsp-control label setup)
> > > > > 2. then the packet is chopped into cells
> > > > > 3. the egress reassembles the packet and copies the label ttl back into the
> > > > > IP-TTL
> > > > >
> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > > > >
> > > > > special features:
> > > > > a) on cisco LSRs there is the possibility to disable the copying of the
> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > > on the egress the smaller of the 2 TTL-values ( label and IP-header) will be
> > > > > used for the IP-TTL
> > > > > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > > > > network
> > > > >
> > > > > with best regards
> > > > >
> > > > > Alexander
> > > > >
> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > > >      __/
> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > > >   __/   Core & IP Services <Senior Consultant>
> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > > __/   PRO IN http://www.proin.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > > Asim.Khan@vf.vodafone.co.uk
> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > > To: c-david.escobar@wcom.com
> > > > > Cc: mpls@UU.NET
> > > > > Subject: RE: Time to live
> > > > >
> > > > > It stays the same. The routers only look at the label value not the IP
> > > > > header. When the packet leaves MPLS domain then the normal operation would
> > > > > apply.
> > > > >
> > > > > Asim
> > > > >
> > > > > -----Original Message-----
> > > > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > > > Sent: 21 August 2001 17:19
> > > > > To: mpls@UU.NET
> > > > > Subject: Time to live
> > > > >
> > > > > Hi;
> > > > > What happens to the TTL field in the IP header when a labeled packet goes
> > > > > through an LSP? Is it decreased at each router or stay the same?
> > >
>



From owner-mpls@UU.NET  Tue Aug 21 14:55:06 2001
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 OAA27862
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 14:55:05 -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 QQldbn12618;
	Tue, 21 Aug 2001 18:55:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbn01688
	for mpls-outgoing; Tue, 21 Aug 2001 18:55: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 QQldbn01679
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:55: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 QQldbn16090
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:54:56 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbn10960
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:54:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA22572 for mpls@uu.net; Tue, 21 Aug 2001 14:54:54 -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 QQldbn01458
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:54:34 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 QQldbn07986
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:53:47 GMT
Received: from ray.riverstonenet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldbn21937
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:53:46 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7LInUY01440;
	Tue, 21 Aug 2001 11:49:30 -0700
Date: Tue, 21 Aug 2001 11:49:30 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Anoop Ghanwani <anoop@cosinecom.com>
cc: Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: RE: Time to live
In-Reply-To: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng>
Message-ID: <Pine.LNX.4.33.0108211144150.1223-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Anoop,

The no-decrement-TTL option making the LSP appear as a one-hop router to
diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.

Also, you gave us a routing loop example, that should not happen all the
time, right?  :)  So I really don't think it will affect your network
performance.

Thanks,
Ray

On Tue, 21 Aug 2001, Anoop Ghanwani wrote:

> Date: Tue, 21 Aug 2001 11:27:57 -0700
> From: Anoop Ghanwani <anoop@cosinecom.com>
> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
> Cc: Alexander Marhold <alexander@marhold.at>,
>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: RE: Time to live
>
>
> I think that's a really bad idea.  TTL is there to
> protect the network from packets that might be in a loop.
> Nesting TTLs to that the outer one is used within the
> tunnel while the inner one stays the same could
> delay the time the it takes for TTL to protect the packet.
>
> For instance, consider the following topology.
>
> r1 -- r2 -- r3 -- r4 -- r5
>        |                 |
>       r9 -- r8 -- r7 -- r6
>
> Let's say the path from r3 to r8 is implemented by a
> tunnel (in pipe mode).  The packet first hits r2, enters
> the tunnel at r3, and then gets to r8. r3-r8 is treated as
> a single hop because the TTL in the IP header is only
> decremented by 1.  In this example the looping packet
> gets to traverse the loop many more times than it
> would have if we were just operating on TTL as specified
> in RFC 3032 (> 60 times versus < 30 times).
>
> Thus far, the argument in favor of hiding TTL has been
> that it helps hide the network topology and gives the user
> a perception of traversing fewer hops.  It seems like
> a lame reason because the real measure of performance
> is actually latency.
>
> Just my $0.02 ;-)
> -Anoop
>
>
> > -----Original Message-----
> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
> <mailto:rayq@riverstonenet.com> ]
> > Sent: Tuesday, August 21, 2001 10:26 AM
> > To: Eric W Gray
> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> > Subject: Re: Time to live
> >
> >
> > There is also an option that we don't copy the MPLS TTL back
> > to IP TTL.
> > It makes IP think the MPLS LSP is only one hop.
> >
> > Thanks,
> > Ray
> >
> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >
> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > > From: Eric W Gray <ewgray@mindspring.com>
> > > To: Alexander Marhold <alexander@marhold.at>,
> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > > Subject: Re: Time to live
> > >
> > > Below, the last sentence was supposed to be "Note that Frame
> > > Relay ..."
> > >
> > > --
> > > Eric Gray
> > >
> > > Eric W Gray wrote:
> > >
> > > > Alexander,
> > > >
> > > >     No cigar.  The distinction is not cell verses frame,
> > but rather
> > > > whether or not it is possible to incorporate the label in the L2
> > > > encapsulation.  Where this is possible, ATM and FR, there is
> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > > Relay is Frame based...
> > > >
> > > > --
> > > > Eric Gray
> > > >
> > > > You wrote:
> > > >
> > > > > Hello
> > > > > I want to explain the mechanism a little bit more in detail
> > > > >
> > > > > FRAME based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > into the TTL-field of
> > > > > the label header.
> > > > > 2. the label-TTL is decremented at each hop by 1
> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > > TTL-exceeded-ICMP message will be sent if possible
> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > > >
> > > > > CELL based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > into the TTL-field of
> > > > > the label header.
> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
> > decrements the TTL by 1
> > > > > 1b              or by the amount of ATM_MPLS hops of
> > the LSP ( this he knows from the
> > > > > LSP-setup using downstream on demand label allocation
> > and ordered
> > > > > lsp-control label setup)
> > > > > 2. then the packet is chopped into cells
> > > > > 3. the egress reassembles the packet and copies the
> > label ttl back into the
> > > > > IP-TTL
> > > > >
> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
>
> > > > >
> > > > > special features:
> > > > > a) on cisco LSRs there is the possibility to disable
> > the copying of the
> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > > on the egress the smaller of the 2 TTL-values ( label
> > and IP-header) will be
> > > > > used for the IP-TTL
> > > > > then for traceroute the MPLS cloud looks like a 1-hop
> > (2-hop with PHP)
> > > > > network
> > > > >
> > > > > with best regards
> > > > >
> > > > > Alexander
> > > > >
> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > > >      __/
> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > > >   __/   Core & IP Services <Senior Consultant>
> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
> <mailto:owner-mpls@UU.NET> ]On Behalf Of
> > > > > Asim.Khan@vf.vodafone.co.uk
> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > > To: c-david.escobar@wcom.com
> > > > > Cc: mpls@UU.NET
> > > > > Subject: RE: Time to live
> > > > >
> > > > > It stays the same. The routers only look at the label
> > value not the IP
> > > > > header. When the packet leaves MPLS domain then the
> > normal operation would
> > > > > apply.
> > > > >
> > > > > Asim
> > > > >
> > > > > -----Original Message-----
> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
> <mailto:c-david.escobar@wcom.com> ]
> > > > > Sent: 21 August 2001 17:19
> > > > > To: mpls@UU.NET
> > > > > Subject: Time to live
> > > > >
> > > > > Hi;
> > > > > What happens to the TTL field in the IP header when a
> > labeled packet goes
> > > > > through an LSP? Is it decreased at each router or stay the same?
>
> > >
> >
> ########################################################################
> ############################## This email communication may contain
> CONFIDENTIAL INFORMATION and is intended only for the use of the
> intended recipients identified above.  If you are not the intended
> recipient of this communication, you must not use, disclose, distribute,
> copy or print this email. If you have received this communication in
> error, please immediately notify the sender by reply email, delete the
> communication and destroy all copies.
> ########################################################################
> ##############################
>
>



From owner-mpls@UU.NET  Tue Aug 21 15:44:03 2001
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 PAA29516
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 15:44:03 -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 QQldbr08597;
	Tue, 21 Aug 2001 19:45:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbq26095
	for mpls-outgoing; Tue, 21 Aug 2001 19:44:48 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 QQldbq26086
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 19:44:38 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 QQldbq19020
	for <mpls@uu.net>; Tue, 21 Aug 2001 19:43:37 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbq12874
	for <mpls@uu.net>; Tue, 21 Aug 2001 19:43:37 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA26615 for mpls@uu.net; Tue, 21 Aug 2001 15:43:35 -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 QQldbq25989
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 19:43:14 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 QQldbq14824
	for <mpls@UU.NET>; Tue, 21 Aug 2001 19:40:51 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQldbq02434
	for <mpls@UU.NET>; Tue, 21 Aug 2001 19:40:51 GMT
Received: from YHASAN-W2K5.cisco.com (yhasan-dsl3.cisco.com [10.21.182.52])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA23624;
	Tue, 21 Aug 2001 12:40:39 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010821123848.01f959c8@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 21 Aug 2001 12:40:37 -0700
To: Ray Qiu <rayq@riverstonenet.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: RE: Time to live
Cc: Anoop Ghanwani <anoop@cosinecom.com>, Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
In-Reply-To: <Pine.LNX.4.33.0108211144150.1223-100000@ray.riverstonenet.
 com>
References: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

Also, the default is to decrement the MPLS TTL, so as pointed out by Anoop the feature to not decrement MPLS TTL to make the LSP look like a single-hop is a knob only
Thanks

-Yousuf


At 11:49 AM 8/21/2001 -0700, Ray Qiu wrote:
>Anoop,
>
>The no-decrement-TTL option making the LSP appear as a one-hop router to
>diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.
>
>Also, you gave us a routing loop example, that should not happen all the
>time, right?  :)  So I really don't think it will affect your network
>performance.
>
>Thanks,
>Ray
>
>On Tue, 21 Aug 2001, Anoop Ghanwani wrote:
>
>> Date: Tue, 21 Aug 2001 11:27:57 -0700
>> From: Anoop Ghanwani <anoop@cosinecom.com>
>> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
>> Cc: Alexander Marhold <alexander@marhold.at>,
>>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
>> Subject: RE: Time to live
>>
>>
>> I think that's a really bad idea.  TTL is there to
>> protect the network from packets that might be in a loop.
>> Nesting TTLs to that the outer one is used within the
>> tunnel while the inner one stays the same could
>> delay the time the it takes for TTL to protect the packet.
>>
>> For instance, consider the following topology.
>>
>> r1 -- r2 -- r3 -- r4 -- r5
>>        |                 |
>>       r9 -- r8 -- r7 -- r6
>>
>> Let's say the path from r3 to r8 is implemented by a
>> tunnel (in pipe mode).  The packet first hits r2, enters
>> the tunnel at r3, and then gets to r8. r3-r8 is treated as
>> a single hop because the TTL in the IP header is only
>> decremented by 1.  In this example the looping packet
>> gets to traverse the loop many more times than it
>> would have if we were just operating on TTL as specified
>> in RFC 3032 (> 60 times versus < 30 times).
>>
>> Thus far, the argument in favor of hiding TTL has been
>> that it helps hide the network topology and gives the user
>> a perception of traversing fewer hops.  It seems like
>> a lame reason because the real measure of performance
>> is actually latency.
>>
>> Just my $0.02 ;-)
>> -Anoop
>>
>>
>> > -----Original Message-----
>> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
>> <mailto:rayq@riverstonenet.com> ]
>> > Sent: Tuesday, August 21, 2001 10:26 AM
>> > To: Eric W Gray
>> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
>> > Subject: Re: Time to live
>> >
>> >
>> > There is also an option that we don't copy the MPLS TTL back
>> > to IP TTL.
>> > It makes IP think the MPLS LSP is only one hop.
>> >
>> > Thanks,
>> > Ray
>> >
>> > On Tue, 21 Aug 2001, Eric W Gray wrote:
>> >
>> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
>> > > From: Eric W Gray <ewgray@mindspring.com>
>> > > To: Alexander Marhold <alexander@marhold.at>,
>> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
>> > > Subject: Re: Time to live
>> > >
>> > > Below, the last sentence was supposed to be "Note that Frame
>> > > Relay ..."
>> > >
>> > > --
>> > > Eric Gray
>> > >
>> > > Eric W Gray wrote:
>> > >
>> > > > Alexander,
>> > > >
>> > > >     No cigar.  The distinction is not cell verses frame,
>> > but rather
>> > > > whether or not it is possible to incorporate the label in the L2
>> > > > encapsulation.  Where this is possible, ATM and FR, there is
>> > > > no TTL capability in the L2 encapsulation.  Not that Frame
>> > > > Relay is Frame based...
>> > > >
>> > > > --
>> > > > Eric Gray
>> > > >
>> > > > You wrote:
>> > > >
>> > > > > Hello
>> > > > > I want to explain the mechanism a little bit more in detail
>> > > > >
>> > > > > FRAME based general:
>> > > > > 1. normally at the ingress LSR the IP-TTL is copied
>> > into the TTL-field of
>> > > > > the label header.
>> > > > > 2. the label-TTL is decremented at each hop by 1
>> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
>> > > > > TTL-exceeded-ICMP message will be sent if possible
>> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
>> > > > >
>> > > > > CELL based general:
>> > > > > 1. normally at the ingress LSR the IP-TTL is copied
>> > into the TTL-field of
>> > > > > the label header.
>> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
>> > decrements the TTL by 1
>> > > > > 1b              or by the amount of ATM_MPLS hops of
>> > the LSP ( this he knows from the
>> > > > > LSP-setup using downstream on demand label allocation
>> > and ordered
>> > > > > lsp-control label setup)
>> > > > > 2. then the packet is chopped into cells
>> > > > > 3. the egress reassembles the packet and copies the
>> > label ttl back into the
>> > > > > IP-TTL
>> > > > >
>> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
>>
>> > > > >
>> > > > > special features:
>> > > > > a) on cisco LSRs there is the possibility to disable
>> > the copying of the
>> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
>> > > > > on the egress the smaller of the 2 TTL-values ( label
>> > and IP-header) will be
>> > > > > used for the IP-TTL
>> > > > > then for traceroute the MPLS cloud looks like a 1-hop
>> > (2-hop with PHP)
>> > > > > network
>> > > > >
>> > > > > with best regards
>> > > > >
>> > > > > Alexander
>> > > > >
>> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
>> > > > >      __/
>> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
>> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
>> > > > >   __/   Core & IP Services <Senior Consultant>
>> > > > >  __/   Mobile: ++43-(0)664-16 28 234
>> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
>> <mailto:owner-mpls@UU.NET> ]On Behalf Of
>> > > > > Asim.Khan@vf.vodafone.co.uk
>> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
>> > > > > To: c-david.escobar@wcom.com
>> > > > > Cc: mpls@UU.NET
>> > > > > Subject: RE: Time to live
>> > > > >
>> > > > > It stays the same. The routers only look at the label
>> > value not the IP
>> > > > > header. When the packet leaves MPLS domain then the
>> > normal operation would
>> > > > > apply.
>> > > > >
>> > > > > Asim
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
>> <mailto:c-david.escobar@wcom.com> ]
>> > > > > Sent: 21 August 2001 17:19
>> > > > > To: mpls@UU.NET
>> > > > > Subject: Time to live
>> > > > >
>> > > > > Hi;
>> > > > > What happens to the TTL field in the IP header when a
>> > labeled packet goes
>> > > > > through an LSP? Is it decreased at each router or stay the same?
>>
>> > >
>> >
>> ########################################################################
>> ############################## This email communication may contain
>> CONFIDENTIAL INFORMATION and is intended only for the use of the
>> intended recipients identified above.  If you are not the intended
>> recipient of this communication, you must not use, disclose, distribute,
>> copy or print this email. If you have received this communication in
>> error, please immediately notify the sender by reply email, delete the
>> communication and destroy all copies.
>> ########################################################################
>> ##############################
>>
>> 



From owner-mpls@UU.NET  Tue Aug 21 16:30:53 2001
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 QAA00508
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 16:30:48 -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 QQldbu06200;
	Tue, 21 Aug 2001 20:31:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbu19693
	for mpls-outgoing; Tue, 21 Aug 2001 20:31: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 QQldbu19609
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 20:31: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 QQldbu04877
	for <mpls@UU.NET>; Tue, 21 Aug 2001 20:30:47 GMT
Received: from chmls06.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls06.mediaone.net [24.147.1.144])
	id QQldbu23266
	for <mpls@UU.NET>; Tue, 21 Aug 2001 20:30:46 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f7LKT4m07268;
	Tue, 21 Aug 2001 16:29:04 -0400 (EDT)
Message-ID: <3B82C3A3.C8D3FE7F@sandburst.com>
Date: Tue, 21 Aug 2001 16:25:07 -0400
From: Eric Gray <eric.gray@sandburst.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Yousuf Hasan <yhasan@cisco.com>
CC: Ray Qiu <rayq@riverstonenet.com>, Anoop Ghanwani <anoop@cosinecom.com>,
        Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
References: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng> <4.3.2.7.2.20010821123848.01f959c8@ce-nfs-1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yousuf,

    Actually, this is not a 'no-decrement-TTL' option in the strictest
sense - which should alleviate a lot of concerns.  TTL is decremented
at the ingress LSR (possibly even before it knows it is an ingress LSR)
before a label is pushed onto the stack (creating the stack if necessary).
The as-decremented TTL may then be copied to the new label stack entry
as a starting point for the LSP itself.  Note that this is the expected
behavior, but the actual value used is not important if the egress will
ignore the final TTL value for the LSP when packets are egressed.  In
the 'pipe' analog the as-decremented TTL is then unchanged at the egress
while, in the 'uniform' analog, the as-decremented TTL is over-written by
the further decremented TTL in the encapsulation being popped.

    Note that, as far as TTL is concerned, the only currently defined
behavior is the 'uniform' analog.  People who do not wish to support it
need do (and should do) nothing.  Those people who wish to support the
'pipe' analog will need to define how the ingress and egress can be in
synchronization about how TTL will be processed at the egress.  This can
be done via configuration at each end of every affected LSP, or it may
be accomplished by configuration at the ingress and signaling.  Last time
I heard from Bora and Puneet, their proposal included signaling.

--
Eric Gray

You wrote:

> Also, the default is to decrement the MPLS TTL, so as pointed out by Anoop the feature to not decrement MPLS TTL to make the LSP look like a single-hop is a knob only
> Thanks
>
> -Yousuf
>
> At 11:49 AM 8/21/2001 -0700, Ray Qiu wrote:
> >Anoop,
> >
> >The no-decrement-TTL option making the LSP appear as a one-hop router to
> >diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.
> >
> >Also, you gave us a routing loop example, that should not happen all the
> >time, right?  :)  So I really don't think it will affect your network
> >performance.
> >
> >Thanks,
> >Ray
> >
> >On Tue, 21 Aug 2001, Anoop Ghanwani wrote:
> >
> >> Date: Tue, 21 Aug 2001 11:27:57 -0700
> >> From: Anoop Ghanwani <anoop@cosinecom.com>
> >> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
> >> Cc: Alexander Marhold <alexander@marhold.at>,
> >>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> >> Subject: RE: Time to live
> >>
> >>
> >> I think that's a really bad idea.  TTL is there to
> >> protect the network from packets that might be in a loop.
> >> Nesting TTLs to that the outer one is used within the
> >> tunnel while the inner one stays the same could
> >> delay the time the it takes for TTL to protect the packet.
> >>
> >> For instance, consider the following topology.
> >>
> >> r1 -- r2 -- r3 -- r4 -- r5
> >>        |                 |
> >>       r9 -- r8 -- r7 -- r6
> >>
> >> Let's say the path from r3 to r8 is implemented by a
> >> tunnel (in pipe mode).  The packet first hits r2, enters
> >> the tunnel at r3, and then gets to r8. r3-r8 is treated as
> >> a single hop because the TTL in the IP header is only
> >> decremented by 1.  In this example the looping packet
> >> gets to traverse the loop many more times than it
> >> would have if we were just operating on TTL as specified
> >> in RFC 3032 (> 60 times versus < 30 times).
> >>
> >> Thus far, the argument in favor of hiding TTL has been
> >> that it helps hide the network topology and gives the user
> >> a perception of traversing fewer hops.  It seems like
> >> a lame reason because the real measure of performance
> >> is actually latency.
> >>
> >> Just my $0.02 ;-)
> >> -Anoop
> >>
> >>
> >> > -----Original Message-----
> >> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
> >> <mailto:rayq@riverstonenet.com> ]
> >> > Sent: Tuesday, August 21, 2001 10:26 AM
> >> > To: Eric W Gray
> >> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> >> > Subject: Re: Time to live
> >> >
> >> >
> >> > There is also an option that we don't copy the MPLS TTL back
> >> > to IP TTL.
> >> > It makes IP think the MPLS LSP is only one hop.
> >> >
> >> > Thanks,
> >> > Ray
> >> >
> >> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >> >
> >> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> >> > > From: Eric W Gray <ewgray@mindspring.com>
> >> > > To: Alexander Marhold <alexander@marhold.at>,
> >> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> >> > > Subject: Re: Time to live
> >> > >
> >> > > Below, the last sentence was supposed to be "Note that Frame
> >> > > Relay ..."
> >> > >
> >> > > --
> >> > > Eric Gray
> >> > >
> >> > > Eric W Gray wrote:
> >> > >
> >> > > > Alexander,
> >> > > >
> >> > > >     No cigar.  The distinction is not cell verses frame,
> >> > but rather
> >> > > > whether or not it is possible to incorporate the label in the L2
> >> > > > encapsulation.  Where this is possible, ATM and FR, there is
> >> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> >> > > > Relay is Frame based...
> >> > > >
> >> > > > --
> >> > > > Eric Gray
> >> > > >
> >> > > > You wrote:
> >> > > >
> >> > > > > Hello
> >> > > > > I want to explain the mechanism a little bit more in detail
> >> > > > >
> >> > > > > FRAME based general:
> >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> >> > into the TTL-field of
> >> > > > > the label header.
> >> > > > > 2. the label-TTL is decremented at each hop by 1
> >> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> >> > > > > TTL-exceeded-ICMP message will be sent if possible
> >> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> >> > > > >
> >> > > > > CELL based general:
> >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> >> > into the TTL-field of
> >> > > > > the label header.
> >> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
> >> > decrements the TTL by 1
> >> > > > > 1b              or by the amount of ATM_MPLS hops of
> >> > the LSP ( this he knows from the
> >> > > > > LSP-setup using downstream on demand label allocation
> >> > and ordered
> >> > > > > lsp-control label setup)
> >> > > > > 2. then the packet is chopped into cells
> >> > > > > 3. the egress reassembles the packet and copies the
> >> > label ttl back into the
> >> > > > > IP-TTL
> >> > > > >
> >> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> >>
> >> > > > >
> >> > > > > special features:
> >> > > > > a) on cisco LSRs there is the possibility to disable
> >> > the copying of the
> >> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> >> > > > > on the egress the smaller of the 2 TTL-values ( label
> >> > and IP-header) will be
> >> > > > > used for the IP-TTL
> >> > > > > then for traceroute the MPLS cloud looks like a 1-hop
> >> > (2-hop with PHP)
> >> > > > > network
> >> > > > >
> >> > > > > with best regards
> >> > > > >
> >> > > > > Alexander
> >> > > > >
> >> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> >> > > > >      __/
> >> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> >> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> >> > > > >   __/   Core & IP Services <Senior Consultant>
> >> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> >> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> >> > > > >
> >> > > > > -----Original Message-----
> >> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
> >> <mailto:owner-mpls@UU.NET> ]On Behalf Of
> >> > > > > Asim.Khan@vf.vodafone.co.uk
> >> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> >> > > > > To: c-david.escobar@wcom.com
> >> > > > > Cc: mpls@UU.NET
> >> > > > > Subject: RE: Time to live
> >> > > > >
> >> > > > > It stays the same. The routers only look at the label
> >> > value not the IP
> >> > > > > header. When the packet leaves MPLS domain then the
> >> > normal operation would
> >> > > > > apply.
> >> > > > >
> >> > > > > Asim
> >> > > > >
> >> > > > > -----Original Message-----
> >> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
> >> <mailto:c-david.escobar@wcom.com> ]
> >> > > > > Sent: 21 August 2001 17:19
> >> > > > > To: mpls@UU.NET
> >> > > > > Subject: Time to live
> >> > > > >
> >> > > > > Hi;
> >> > > > > What happens to the TTL field in the IP header when a
> >> > labeled packet goes
> >> > > > > through an LSP? Is it decreased at each router or stay the same?
> >>
> >> > >
> >> >
> >> ########################################################################
> >> ############################## This email communication may contain
> >> CONFIDENTIAL INFORMATION and is intended only for the use of the
> >> intended recipients identified above.  If you are not the intended
> >> recipient of this communication, you must not use, disclose, distribute,
> >> copy or print this email. If you have received this communication in
> >> error, please immediately notify the sender by reply email, delete the
> >> communication and destroy all copies.
> >> ########################################################################
> >> ##############################
> >>
> >>




From owner-mpls@UU.NET  Tue Aug 21 16:37:31 2001
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 QAA00659
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 16:37:30 -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 QQldbu03374;
	Tue, 21 Aug 2001 20:38:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbu21255
	for mpls-outgoing; Tue, 21 Aug 2001 20:37:49 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 QQldbu21218
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 20:37:38 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 QQldbu23912
	for <mpls@uu.net>; Tue, 21 Aug 2001 20:36:59 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbu01642
	for <mpls@uu.net>; Tue, 21 Aug 2001 20:36:59 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA01121 for mpls@uu.net; Tue, 21 Aug 2001 16:36:58 -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 QQldbu20960
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 20:36:31 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 QQldbu22882
	for <mpls@UU.NET>; Tue, 21 Aug 2001 20:35:35 GMT
Received: from ray.riverstonenet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldbu13502
	for <mpls@UU.NET>; Tue, 21 Aug 2001 20:35:35 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7LKU9Z01535;
	Tue, 21 Aug 2001 13:30:09 -0700
Date: Tue, 21 Aug 2001 13:30:09 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Eric Gray <eric.gray@sandburst.com>
cc: Yousuf Hasan <yhasan@cisco.com>, Anoop Ghanwani <anoop@cosinecom.com>,
        Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: Time to live
In-Reply-To: <3B82C3A3.C8D3FE7F@sandburst.com>
Message-ID: <Pine.LNX.4.33.0108211327370.1223-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Yes.  I think the signaling is preferred if we want to be able to change
the TTL behavior at the egress point.  The ingress needs to know it
should put 255 as the MPLS TTL instead of the real IP TTL.  This prevent
the packets from being dropped in the LSP path.

Thanks,
Ray

On Tue, 21 Aug 2001, Eric Gray wrote:

> Date: Tue, 21 Aug 2001 16:25:07 -0400
> From: Eric Gray <eric.gray@sandburst.com>
> To: Yousuf Hasan <yhasan@cisco.com>
> Cc: Ray Qiu <rayq@riverstonenet.com>, Anoop Ghanwani <anoop@cosinecom.com>,
>      Eric W Gray <ewgray@mindspring.com>,
>      Alexander Marhold <alexander@marhold.at>,
>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: Re: Time to live
>
> Yousuf,
>
>     Actually, this is not a 'no-decrement-TTL' option in the strictest
> sense - which should alleviate a lot of concerns.  TTL is decremented
> at the ingress LSR (possibly even before it knows it is an ingress LSR)
> before a label is pushed onto the stack (creating the stack if necessary).
> The as-decremented TTL may then be copied to the new label stack entry
> as a starting point for the LSP itself.  Note that this is the expected
> behavior, but the actual value used is not important if the egress will
> ignore the final TTL value for the LSP when packets are egressed.  In
> the 'pipe' analog the as-decremented TTL is then unchanged at the egress
> while, in the 'uniform' analog, the as-decremented TTL is over-written by
> the further decremented TTL in the encapsulation being popped.
>
>     Note that, as far as TTL is concerned, the only currently defined
> behavior is the 'uniform' analog.  People who do not wish to support it
> need do (and should do) nothing.  Those people who wish to support the
> 'pipe' analog will need to define how the ingress and egress can be in
> synchronization about how TTL will be processed at the egress.  This can
> be done via configuration at each end of every affected LSP, or it may
> be accomplished by configuration at the ingress and signaling.  Last time
> I heard from Bora and Puneet, their proposal included signaling.
>
> --
> Eric Gray
>
> You wrote:
>
> > Also, the default is to decrement the MPLS TTL, so as pointed out by Anoop the feature to not decrement MPLS TTL to make the LSP look like a single-hop is a knob only
> > Thanks
> >
> > -Yousuf
> >
> > At 11:49 AM 8/21/2001 -0700, Ray Qiu wrote:
> > >Anoop,
> > >
> > >The no-decrement-TTL option making the LSP appear as a one-hop router to
> > >diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.
> > >
> > >Also, you gave us a routing loop example, that should not happen all the
> > >time, right?  :)  So I really don't think it will affect your network
> > >performance.
> > >
> > >Thanks,
> > >Ray
> > >
> > >On Tue, 21 Aug 2001, Anoop Ghanwani wrote:
> > >
> > >> Date: Tue, 21 Aug 2001 11:27:57 -0700
> > >> From: Anoop Ghanwani <anoop@cosinecom.com>
> > >> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
> > >> Cc: Alexander Marhold <alexander@marhold.at>,
> > >>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > >> Subject: RE: Time to live
> > >>
> > >>
> > >> I think that's a really bad idea.  TTL is there to
> > >> protect the network from packets that might be in a loop.
> > >> Nesting TTLs to that the outer one is used within the
> > >> tunnel while the inner one stays the same could
> > >> delay the time the it takes for TTL to protect the packet.
> > >>
> > >> For instance, consider the following topology.
> > >>
> > >> r1 -- r2 -- r3 -- r4 -- r5
> > >>        |                 |
> > >>       r9 -- r8 -- r7 -- r6
> > >>
> > >> Let's say the path from r3 to r8 is implemented by a
> > >> tunnel (in pipe mode).  The packet first hits r2, enters
> > >> the tunnel at r3, and then gets to r8. r3-r8 is treated as
> > >> a single hop because the TTL in the IP header is only
> > >> decremented by 1.  In this example the looping packet
> > >> gets to traverse the loop many more times than it
> > >> would have if we were just operating on TTL as specified
> > >> in RFC 3032 (> 60 times versus < 30 times).
> > >>
> > >> Thus far, the argument in favor of hiding TTL has been
> > >> that it helps hide the network topology and gives the user
> > >> a perception of traversing fewer hops.  It seems like
> > >> a lame reason because the real measure of performance
> > >> is actually latency.
> > >>
> > >> Just my $0.02 ;-)
> > >> -Anoop
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
> > >> <mailto:rayq@riverstonenet.com> ]
> > >> > Sent: Tuesday, August 21, 2001 10:26 AM
> > >> > To: Eric W Gray
> > >> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> > >> > Subject: Re: Time to live
> > >> >
> > >> >
> > >> > There is also an option that we don't copy the MPLS TTL back
> > >> > to IP TTL.
> > >> > It makes IP think the MPLS LSP is only one hop.
> > >> >
> > >> > Thanks,
> > >> > Ray
> > >> >
> > >> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> > >> >
> > >> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > >> > > From: Eric W Gray <ewgray@mindspring.com>
> > >> > > To: Alexander Marhold <alexander@marhold.at>,
> > >> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > >> > > Subject: Re: Time to live
> > >> > >
> > >> > > Below, the last sentence was supposed to be "Note that Frame
> > >> > > Relay ..."
> > >> > >
> > >> > > --
> > >> > > Eric Gray
> > >> > >
> > >> > > Eric W Gray wrote:
> > >> > >
> > >> > > > Alexander,
> > >> > > >
> > >> > > >     No cigar.  The distinction is not cell verses frame,
> > >> > but rather
> > >> > > > whether or not it is possible to incorporate the label in the L2
> > >> > > > encapsulation.  Where this is possible, ATM and FR, there is
> > >> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> > >> > > > Relay is Frame based...
> > >> > > >
> > >> > > > --
> > >> > > > Eric Gray
> > >> > > >
> > >> > > > You wrote:
> > >> > > >
> > >> > > > > Hello
> > >> > > > > I want to explain the mechanism a little bit more in detail
> > >> > > > >
> > >> > > > > FRAME based general:
> > >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > >> > into the TTL-field of
> > >> > > > > the label header.
> > >> > > > > 2. the label-TTL is decremented at each hop by 1
> > >> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > >> > > > > TTL-exceeded-ICMP message will be sent if possible
> > >> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > >> > > > >
> > >> > > > > CELL based general:
> > >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > >> > into the TTL-field of
> > >> > > > > the label header.
> > >> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
> > >> > decrements the TTL by 1
> > >> > > > > 1b              or by the amount of ATM_MPLS hops of
> > >> > the LSP ( this he knows from the
> > >> > > > > LSP-setup using downstream on demand label allocation
> > >> > and ordered
> > >> > > > > lsp-control label setup)
> > >> > > > > 2. then the packet is chopped into cells
> > >> > > > > 3. the egress reassembles the packet and copies the
> > >> > label ttl back into the
> > >> > > > > IP-TTL
> > >> > > > >
> > >> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > >>
> > >> > > > >
> > >> > > > > special features:
> > >> > > > > a) on cisco LSRs there is the possibility to disable
> > >> > the copying of the
> > >> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > >> > > > > on the egress the smaller of the 2 TTL-values ( label
> > >> > and IP-header) will be
> > >> > > > > used for the IP-TTL
> > >> > > > > then for traceroute the MPLS cloud looks like a 1-hop
> > >> > (2-hop with PHP)
> > >> > > > > network
> > >> > > > >
> > >> > > > > with best regards
> > >> > > > >
> > >> > > > > Alexander
> > >> > > > >
> > >> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > >> > > > >      __/
> > >> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > >> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > >> > > > >   __/   Core & IP Services <Senior Consultant>
> > >> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> > >> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> > >> > > > >
> > >> > > > > -----Original Message-----
> > >> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
> > >> <mailto:owner-mpls@UU.NET> ]On Behalf Of
> > >> > > > > Asim.Khan@vf.vodafone.co.uk
> > >> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > >> > > > > To: c-david.escobar@wcom.com
> > >> > > > > Cc: mpls@UU.NET
> > >> > > > > Subject: RE: Time to live
> > >> > > > >
> > >> > > > > It stays the same. The routers only look at the label
> > >> > value not the IP
> > >> > > > > header. When the packet leaves MPLS domain then the
> > >> > normal operation would
> > >> > > > > apply.
> > >> > > > >
> > >> > > > > Asim
> > >> > > > >
> > >> > > > > -----Original Message-----
> > >> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
> > >> <mailto:c-david.escobar@wcom.com> ]
> > >> > > > > Sent: 21 August 2001 17:19
> > >> > > > > To: mpls@UU.NET
> > >> > > > > Subject: Time to live
> > >> > > > >
> > >> > > > > Hi;
> > >> > > > > What happens to the TTL field in the IP header when a
> > >> > labeled packet goes
> > >> > > > > through an LSP? Is it decreased at each router or stay the same?
> > >>
> > >> > >
> > >> >
> > >> ########################################################################
> > >> ############################## This email communication may contain
> > >> CONFIDENTIAL INFORMATION and is intended only for the use of the
> > >> intended recipients identified above.  If you are not the intended
> > >> recipient of this communication, you must not use, disclose, distribute,
> > >> copy or print this email. If you have received this communication in
> > >> error, please immediately notify the sender by reply email, delete the
> > >> communication and destroy all copies.
> > >> ########################################################################
> > >> ##############################
> > >>
> > >>
>



From owner-mpls@UU.NET  Tue Aug 21 17:31:53 2001
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 RAA01592
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 17:31:52 -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 QQldby22562;
	Tue, 21 Aug 2001 21:33:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldby15931
	for mpls-outgoing; Tue, 21 Aug 2001 21:32:31 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 QQldby15924
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 21:32: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 QQldby09702
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:31:36 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldby06876
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:31:36 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA04786 for mpls@uu.net; Tue, 21 Aug 2001 17:31:34 -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 QQldby15861
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 21:31: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 QQldby10247
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:31:17 GMT
Received: from fncomr02.fnc.fujitsu.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fncomr02.fnc.fujitsu.com [167.254.105.20])
	id QQldby20106
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:31:17 GMT
Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13])
	by fncomr02.fnc.fujitsu.com (Mirapoint)
	with ESMTP id ADE87549;
	Tue, 21 Aug 2001 16:31:16 -0500 (GMT+5)
Received: by RCHSEMX2.fnc.fujitsu.com with Internet Mail Service (5.5.2653.19)
	id <QT48T07S>; Tue, 21 Aug 2001 16:31:16 -0500
Message-ID: <F78F1A77A51F8B47A4B9F9891A6B23C20DF3A4@rchemx05>
From: "Cheng, Dalton" <Dalton.CHENG@fnc.fujitsu.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Sender FLOWSPEC
Date: Tue, 21 Aug 2001 16:31:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

RSVP specifies the receiver based reservation using FLOWSPEC object. The Sender initiates the setup with a service blind RSVP SENDER_TSPEC object. Knowing that  the only differences in format between the sender initiated SEND_TSPEC and the Receiver initiated FLOWSPEC is the Service Number field, the realization is that the SENDER_TSPEC carries a general traffic descriptor while the FLOWSPEC is service specific traffic descriptor. 

The question raised here is: can the sender initiated FLOWSPEC (service specific SENDER_TSPEC) if the reservation is to be source based instead of receiver based?  Also, It appear that although this may be achieved with a more sophisticated signaling, that is, SENDER_TSPEC+ADSPEC. But if one has no concerns about ctot, dtot, csum and dsum carried in ADSPEC, then wouldn't the FLOWSPEC initiated by the sender be more efficient? but is it valid?

Thanks in advance for your advice.

Dalton Cheng
IPT System Engineering
Fujitsu Network Communication
(972)-479-6416
Dalton.Cheng@fnc.fujitsu.com





From owner-mpls@UU.NET  Tue Aug 21 17:46:27 2001
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 RAA02085
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 17:46:27 -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 QQldbz14504;
	Tue, 21 Aug 2001 21:47:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbz17222
	for mpls-outgoing; Tue, 21 Aug 2001 21:47: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 QQldbz17211
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 21:47:07 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 QQldbz24506
	for <mpls@UU.NET>; Tue, 21 Aug 2001 21:46:18 GMT
Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQldbz27137
	for <mpls@UU.NET>; Tue, 21 Aug 2001 21:46:14 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 RAA06022
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:44:37 -0400 (EDT)
Subject: RSVPTE questions
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF770380B6.2EFCD770-ON85256AAF.0075E25D@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 21 Aug 2001 17:44:34 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/21/2001 05:44:33 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

For the rsvp-lsp-tunnel-08, section 4.2.5,

An RSVP router that recognizes the LABEL_REQUEST object but
   does not recognize the C_Type sends a PathErr with the error code
   "Unknown object C_Type" toward the sender.

so I have path msg sent out with correct LRO class, and length, but it has
unknown ctype, such as '0F'H,
but receiver will not send out patherr from it.

So can anyone tell me why?

Thanks,

Julia




From owner-mpls@UU.NET  Tue Aug 21 17:46:39 2001
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 RAA02096
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 17:46:39 -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 QQldbz29484;
	Tue, 21 Aug 2001 21:47:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbz17221
	for mpls-outgoing; Tue, 21 Aug 2001 21:47: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 QQldbz17212
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 21:47: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 QQldbz24825
	for <mpls@UU.NET>; Tue, 21 Aug 2001 21:46: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 QQldbz12761
	for <mpls@UU.NET>; Tue, 21 Aug 2001 21:46: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 RAA10215
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:46:18 -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 RAA16698
	for <mpls@UU.NET>; Tue, 21 Aug 2001 17:46:19 -0400 (EDT)
Message-ID: <3B82D6C6.52EFBC34@marconi.com>
Date: Tue, 21 Aug 2001 17:46:46 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Sender FLOWSPEC
References: <F78F1A77A51F8B47A4B9F9891A6B23C20DF3A4@rchemx05>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Cheng, Dalton" wrote:
> 
> RSVP specifies the receiver based reservation using FLOWSPEC object.
> The Sender initiates the setup with a service blind RSVP
> SENDER_TSPEC object. Knowing that the only differences in format
> between the sender initiated SEND_TSPEC and the Receiver initiated
> FLOWSPEC is the Service Number field, the realization is that the
> SENDER_TSPEC carries a general traffic descriptor while the
> FLOWSPEC is service specific traffic descriptor.
> 
> The question raised here is: can the sender initiated FLOWSPEC
> (service specific SENDER_TSPEC) if the reservation is to be source
> based instead of receiver based?  Also, It appear that although
> this may be achieved with a more sophisticated signaling, that is,
> SENDER_TSPEC+ADSPEC. But if one has no concerns about ctot, dtot,
> csum and dsum carried in ADSPEC, then wouldn't the FLOWSPEC
> initiated by the sender be more efficient? but is it valid?

What you ask is theoretically possible, but it would involve a
fundamental change to the entire architecture of RSVP.  If you're going
to change something that fundamental, why bother using RSVP at all? 
IMO, at that point, you'd be better off inventing something completely
new.  I would object to naming any ingress-driven protocol RSVP.

Now, if you just want routers to make reservations during Path
processing, that's a different story.  There's no reason why it can't
happen - I think Cisco's implementation does just that.  There are good
reasons why you might want to do this, and good reasons against it.

But your suggestion - of including a FLOWSPEC in the Path message -
changes far more than the reservation behavior on a switch.  This is not
something you could casually slip into an existing implementation, and
it is not something that willl easily interoperate with other RSVP
implementations.

I'm not saying that your suggestion is a bad idea, but I don't think it
belongs as an extension to RSVP.  It would create an incompatibility
large enough that it would be better to create a new signaling protocol
based on RSVP plus this change (and many other changes that people would
love to make to RSVP as well.)  The only argument against this is that
there are already three MPLS signaling protocols, and I don't think many
vendors will be keen on having to implement a fourth.

-- David


From owner-mpls@UU.NET  Tue Aug 21 17:54:46 2001
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 RAA02318
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 17:54:46 -0400 (EDT)
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 QQldbz18400;
	Tue, 21 Aug 2001 21:55:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbz17849
	for mpls-outgoing; Tue, 21 Aug 2001 21:55: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 QQldbz17843
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 21:55: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 QQldbz22536
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:55: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 QQldbz17864
	for <mpls@uu.net>; Tue, 21 Aug 2001 21:55: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 RAA11047
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:55: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 RAA18905
	for <mpls@uu.net>; Tue, 21 Aug 2001 17:55:22 -0400 (EDT)
Message-ID: <3B82D8E5.7735CCBB@marconi.com>
Date: Tue, 21 Aug 2001 17:55:49 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE questions
References: <OF770380B6.2EFCD770-ON85256AAF.0075E25D@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:
> 
> For the rsvp-lsp-tunnel-08, section 4.2.5,
> 
> An RSVP router that recognizes the LABEL_REQUEST object but
>    does not recognize the C_Type sends a PathErr with the error code
>    "Unknown object C_Type" toward the sender.
> 
> so I have path msg sent out with correct LRO class, and length, but
> it has unknown ctype, such as '0F'H,
> but receiver will not send out patherr from it.

Assuming that everything else in the packet is well-formed, then this is
probably a bug in the implementation.  You may want to contact your
vendor in order to let them know so that they can fix it.

Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid. 
An invalid checksum will cause the router to drop the message without
generating any errors.

-- David


From owner-mpls@UU.NET  Tue Aug 21 18:05:13 2001
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 SAA02406
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 18:05:13 -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 QQldca11259;
	Tue, 21 Aug 2001 22:06:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldca28669
	for mpls-outgoing; Tue, 21 Aug 2001 22:05:52 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 QQldca28663
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:05:50 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 QQldca21782
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:05:31 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldca25473
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:05:31 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA07810 for mpls@uu.net; Tue, 21 Aug 2001 18:05:29 -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 QQldca28594
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:04:49 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 QQldca18912
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:03:52 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldca07822
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:03:52 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA15718; Tue, 21 Aug 2001 18:03:49 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id SAA28209; Tue, 21 Aug 2001 18:03:49 -0400 (EDT)
Message-Id: <200108212203.SAA28209@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Cc: vijay@cosinecom.com
Subject: Last call on recovery framework
Date: Tue, 21 Aug 2001 18:03:49 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a last call on

      Framework for MPLS-based Recovery                     
      <draft-ietf-mpls-recovery-frmwrk-02.txt>  

The last call ends on Sept 5 at midnight GMT.

...George


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




From owner-mpls@UU.NET  Tue Aug 21 18:12:56 2001
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 SAA02529
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 18:12:56 -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 QQldca07678;
	Tue, 21 Aug 2001 22:14:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldca08038
	for mpls-outgoing; Tue, 21 Aug 2001 22:13: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 QQldca08032
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:13:39 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 QQldca01376
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:13:21 GMT
Received: from chimera.elec.qmul.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQldca07684
	for <mpls@uu.net>; Tue, 21 Aug 2001 22:13:21 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15ZJlw-0002Wr-00; Tue, 21 Aug 2001 23:13:20 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <mpls@UU.NET>
Cc: <david.charlap@marconi.com>
Subject: RE: How to know that egress router is reached?
Date: Tue, 21 Aug 2001 23:21:03 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOCEDJCFAA.hongwei.zhou@elec.qmul.ac.uk>
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3B813B5E.71D4F720@marconi.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

First thank David very much.  In RFC 3036, the basic discovery mechanism is:
To engage in LDP Basic Discovery on an interface an LSR periodically sends
LDP Link Hellos out the interface.  LDP Link Hellos are sent as
UDP packets addressed to the well-known LDP discovery port for the "all
routers on this subnet" group multicast address.

here I have something not understood:
1. what does the term "interface" mean? is it a physical port to which a
link is connected to? if a router has four transimitters, it has four
interfaces. am I right?
2. what is the "all routers on this subnet" group multicast address?
3. if a LSR's neighbour router is not LSR, it doesn't understand the LDP
Link Hellos, should it ignore the message or send a notification message
back? if it sends a notification
message back to the LSR,then how to make sure that the LSR understands the
notification message? it seems like a dead loop.

I appreciate help from every one.

--Hongwei

-----Original Message-----
From: David Charlap [mailto:david.charlap@marconi.com]
Sent: 20 August 2001 17:31
To: Hongwei
Subject: Re: How to know that egress router is reached?


Hongwei wrote:
>
> Thank you David. I still feel some confused about a problem:
>
> how does a LSR know that the next hop router is an LDP peer or not?
> does the router administrator configure this information?

A box running LDP will have a TCP connection to each of its peers.  The
LDP discovery mechanism is used to establish these connections.

If the next hop is a router that you don't have such a connection to,
then it is not an LDP peer.

-- David



From owner-mpls@UU.NET  Tue Aug 21 18:23:51 2001
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 SAA02783
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 18:23:51 -0400 (EDT)
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 QQldcb20015;
	Tue, 21 Aug 2001 22:24:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcb09144
	for mpls-outgoing; Tue, 21 Aug 2001 22:24:27 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 QQldcb09125
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:24:23 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 QQldcb16510
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:24:03 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 QQldcb21813
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:24:02 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 SAA13005
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:24:00 -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 SAA23858
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:24:01 -0400 (EDT)
Message-ID: <3B82DF9C.B1524CC1@marconi.com>
Date: Tue, 21 Aug 2001 18:24:28 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: How to know that egress router is reached?
References: <MEEJLEKIFLLBNABPKDAOCEDJCFAA.hongwei.zhou@elec.qmul.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hongwei wrote:
> 
> First thank David very much.  In RFC 3036, the basic discovery
> mechanism is:
> To engage in LDP Basic Discovery on an interface an LSR periodically
> sends LDP Link Hellos out the interface.  LDP Link Hellos are sent
> as UDP packets addressed to the well-known LDP discovery port for
> the "all routers on this subnet" group multicast address.
> 
> here I have something not understood:
> 1. what does the term "interface" mean? is it a physical port to
> which a link is connected to? if a router has four transimitters,
> it has four interfaces. am I right?

If they are four independantly addressible (not necessarily via IP
address), then yes.

I mention this qualifier to distinguish it from ports that are all
electrically identical.  For instance, you might have a multi-port
Ethernet card where all the ports are bridged together and therefore act
as a single layer-3 interface as far as the routing infrastructure is
concerned.

> 2. what is the "all routers on this subnet" group multicast address?

Multicast 101.  It is a well-known multicast IP address.  Its behavior
is similar to broadcast addresses, except that only routers should
process the packets - hosts should not.

> 3. if a LSR's neighbour router is not LSR, it doesn't understand
> the LDP Link Hellos, should it ignore the message or send a
> notification message back? if it sends a notification message back
> to the LSR,then how to make sure that the LSR understands the
> notification message? it seems like a dead loop.

The LDP Hello messages are sent to a specific wel-known UDP port.  If
the receiving router isn't running LDP (the only legitimate reason to
not understand an LDP Hello packet), then it won't be listening on that
port, and the packet will get ignored.

An LDP router sends its hello packets to the all-routers address on each
interface.  If there are no other LDP routers attached, then it will get
no answers.  If there are any LDP routers attached, then each one will
get the Hello, and each will respond.  Then the TCP sessions will be
created according to the RFC.  Once the TCP sessions are established,
the routers can be considered "LDP Peers", since they are now able to
send state-changing messages to each other.

-- David


From owner-mpls@UU.NET  Tue Aug 21 18:37:11 2001
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 SAA02876
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 18:37:11 -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 QQldcc26440;
	Tue, 21 Aug 2001 22:38:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcc10386
	for mpls-outgoing; Tue, 21 Aug 2001 22:37:54 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 QQldcc10381
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:37:53 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 QQldcc23970
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:37:10 GMT
Received: from dnsmx2pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQldcc24687
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:37:09 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 SAA05198
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:33:16 -0400 (EDT)
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF83920DCD.D7F74E61-ON85256AAF.0079B901@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 21 Aug 2001 18:33:14 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/21/2001 06:33:13 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

>>Assuming that everything else in the packet is well-formed, then this is
probably a bug in the implementation.  You may want to contact your
vendor in order to let them know so that they can fix it.

>>Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid.
An invalid checksum will cause the router to drop the message without
generating any errors.

Thanks for your reply.

Yes, I use the valid the rsvp path msg, and just give an unknown ctype for
the LRO, I can see from the router statistics, it does receive the path
msg(it does not drop the pkt), but it does not generate the patherr as
draft said.

what could be the problem?

Thanks,

Julia




From owner-mpls@UU.NET  Tue Aug 21 18:46:42 2001
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 SAA02935
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 18:46:42 -0400 (EDT)
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 QQldcd14692;
	Tue, 21 Aug 2001 22:47:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcd11364
	for mpls-outgoing; Tue, 21 Aug 2001 22:47: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 QQldcd11355
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 22:47:12 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 QQldcd22642
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:46:11 GMT
Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQldcd21677
	for <mpls@UU.NET>; Tue, 21 Aug 2001 22:46:11 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 SAA14246
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:45:16 -0400 (EDT)
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF0D7E1972.B5DE5FF1-ON85256AAF.007CB4E1@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 21 Aug 2001 18:45:13 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/21/2001 06:45:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

>>>>Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid.
An invalid checksum will cause the router to drop the message without
generating any errors.

[]  But even that is the case,  --bad checksum, the Router should send back
the path error msg with error code 23.

----------   spec 2205.
 Error Code = 23: RSVP System error


o    Wrong-length message: RSVP Length field does not match message
        length.

   o    Unknown or unsupported RSVP version.

   o    Bad RSVP checksum

   o    INTEGRITY failure

Julia




From owner-mpls@UU.NET  Tue Aug 21 19:11:48 2001
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 TAA03158
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 19:11:48 -0400 (EDT)
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 QQldce09989;
	Tue, 21 Aug 2001 23:12:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldce01939
	for mpls-outgoing; Tue, 21 Aug 2001 23:12: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 QQldce01932
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:12: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 QQldce12147
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:11:51 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldce09014
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:11:50 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA12796 for mpls@uu.net; Tue, 21 Aug 2001 19:11:49 -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 QQldce01816
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:11: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 QQldce08647
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:10:17 GMT
Received: from scaup.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: scaup.mail.pas.earthlink.net [207.217.121.49])
	id QQldce07471
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:10:17 GMT
Received: from computer.mplsrc.com (dialup-64.157.50.54.Dial1.Washington1.Level3.net [64.157.50.54])
	by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA11486
	for <mpls@uu.net>; Tue, 21 Aug 2001 16:10:15 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010821191031.01e545d0@mail.earthlink.net>
X-Sender: mplsrc12@mplsrc.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 Aug 2001 19:11:21 -0400
To: mpls@UU.NET
From: MPLS Resource Center <admin@mplsrc.com>
Subject: MPLS-OPS Mailing List
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

On August 21st we suffered a loss of the MPLS-OPS mailing list subscriber 
data file.  As of the evening of 8/21, we have only been able to restore a 
portion of the file.

If you were a member of the MPLS-OPS mailing list, we ask that you visit 
our MPLS-OPS page to re-subscribe at :
http://www.mplsrc.com/mplsops.shtml.

We apologize for any inconvenience this might have caused.



From owner-mpls@UU.NET  Tue Aug 21 19:24:19 2001
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 TAA03269
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 19:24:18 -0400 (EDT)
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 QQldcf22690;
	Tue, 21 Aug 2001 23:25:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcf03246
	for mpls-outgoing; Tue, 21 Aug 2001 23:25:01 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 QQldcf03235
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:24:59 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 QQldcf23519
	for <mpls@UU.NET>; Tue, 21 Aug 2001 23:23:30 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQldcf13869
	for <mpls@UU.NET>; Tue, 21 Aug 2001 23:23:29 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7LNN6p06291
	for <mpls@UU.NET>; Tue, 21 Aug 2001 19:23:06 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 21 Aug 2001 19:23:27 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RABGARTL>; Tue, 21 Aug 2001 19:23:28 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431077C9E0B@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Adrian Farrel <afarrel@movaz.com>,
        "Peter Ashwood-Smith" <petera@nortelnetworks.com>
Cc: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>,
        "Darek Skalecki" <dareks@nortelnetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Small comment on draft-ietf-mpls-te-feed-02.txt
Date: Tue, 21 Aug 2001 19:23:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12A98.46747F40"
X-Orig: <dwfedyk@americasm01.nt.com>
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_01C12A98.46747F40
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Adrian 

This seems like a reasonable request. We can add text around this.

There is one point though, that the reporting zero bandwidth is 
logically independent to the node going down or the removal of LSPs.
Actually, we use zero feedback to mean temporarily avoid this 
link as a default case from situations like this. It is important to 
remember the adjacent node sees the real bandwidth but due to LDP 
being in an indeterminate state his option is to report the link 
as being full (zero bandwidth). The restaging of the LDP adjacencies 
should trigger corresponding link LSA to reaffirm the actual bandwidth 
in these cases. 

Regards,
Don

Adrian Farrel wrote:

Peter,

Thanks for this draft which looks stable to me.

Would it be possible to add a reference to LDP FT procedures
(draft-ietf-ldp-ft) in section 5?  I think the third paragraph should have
the following text appended...

  Where LDP FT procedures [LDP-FT] are in use, LSPs that are protected
  by FT procedures should not be torn down until after session re-
  establishment has failed.  Further, feedback TLVs should not report
  zero bandwidth availability on the link until after session re-
  establishment has failed.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com

------_=_NextPart_001_01C12A98.46747F40
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.2654.89">
<TITLE>RE: Small comment on draft-ietf-mpls-te-feed-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Adrian </FONT>
</P>

<P><FONT SIZE=3D2>This seems like a reasonable request. We can add text =
around this.</FONT>
</P>

<P><FONT SIZE=3D2>There is one point though, that the reporting zero =
bandwidth is </FONT>
<BR><FONT SIZE=3D2>logically independent to the node going down or the =
removal of LSPs.</FONT>
<BR><FONT SIZE=3D2>Actually, we use zero feedback to mean temporarily =
avoid this </FONT>
<BR><FONT SIZE=3D2>link as a default case from situations like this. It =
is important to </FONT>
<BR><FONT SIZE=3D2>remember the adjacent node sees the real bandwidth =
but due to LDP </FONT>
<BR><FONT SIZE=3D2>being in an indeterminate state his option is to =
report the link </FONT>
<BR><FONT SIZE=3D2>as being full (zero bandwidth). The restaging of the =
LDP adjacencies </FONT>
<BR><FONT SIZE=3D2>should trigger corresponding link LSA to reaffirm =
the actual bandwidth </FONT>
<BR><FONT SIZE=3D2>in these cases. </FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Don</FONT>
</P>

<P><FONT SIZE=3D2>Adrian Farrel wrote:</FONT>
</P>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for this draft which looks stable to =
me.</FONT>
</P>

<P><FONT SIZE=3D2>Would it be possible to add a reference to LDP FT =
procedures (draft-ietf-ldp-ft) in section 5?&nbsp; I think the third =
paragraph should have the following text appended...</FONT></P>

<P><FONT SIZE=3D2>&nbsp; Where LDP FT procedures [LDP-FT] are in use, =
LSPs that are protected</FONT>
<BR><FONT SIZE=3D2>&nbsp; by FT procedures should not be torn down =
until after session re-</FONT>
<BR><FONT SIZE=3D2>&nbsp; establishment has failed.&nbsp; Further, =
feedback TLVs should not report</FONT>
<BR><FONT SIZE=3D2>&nbsp; zero bandwidth availability on the link until =
after session re-</FONT>
<BR><FONT SIZE=3D2>&nbsp; establishment has failed.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Adrian</FONT>
<BR><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>Movaz Networks Inc.</FONT>
<BR><FONT SIZE=3D2>afarrel@movaz.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A98.46747F40--


From owner-mpls@UU.NET  Tue Aug 21 20:51:24 2001
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 UAA03983
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 20:51:23 -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 QQldcl15598;
	Wed, 22 Aug 2001 00:52:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcl29300
	for mpls-outgoing; Wed, 22 Aug 2001 00:52: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 QQldcl29294
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 00:52:06 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 QQldcl25457
	for <mpls@UU.NET>; Wed, 22 Aug 2001 00:51:24 GMT
Received: from chmls06.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls06.mediaone.net [24.147.1.144])
	id QQldcl25969
	for <mpls@UU.NET>; Wed, 22 Aug 2001 00:51:24 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f7M0ojm21618;
	Tue, 21 Aug 2001 20:50:46 -0400 (EDT)
Message-ID: <3B830163.83624ED6@mindspring.com>
Date: Tue, 21 Aug 2001 20:48:35 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Hongwei Zhou <hongwei.zhou@elec.qmul.ac.uk>
CC: David Charlap <david.charlap@marconi.com>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: How to know that egress router is reached?
References: <MEEJLEKIFLLBNABPKDAOCEDJCFAA.hongwei.zhou@elec.qmul.ac.uk> <3B82DF9C.B1524CC1@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hongwei,

    I've added some comments WRT David's responses below.  Most are
nits.

David Charlap wrote:

> Hongwei wrote:
> >
> > First thank David very much.  In RFC 3036, the basic discovery
> > mechanism is:
> > To engage in LDP Basic Discovery on an interface an LSR periodically
> > sends LDP Link Hellos out the interface.  LDP Link Hellos are sent
> > as UDP packets addressed to the well-known LDP discovery port for
> > the "all routers on this subnet" group multicast address.
> >
> > here I have something not understood:
> > 1. what does the term "interface" mean? is it a physical port to
> > which a link is connected to? if a router has four transimitters,
> > it has four interfaces. am I right?
>
> If they are four independantly addressible (not necessarily via IP
> address), then yes.
>
> I mention this qualifier to distinguish it from ports that are all
> electrically identical.  For instance, you might have a multi-port
> Ethernet card where all the ports are bridged together and therefore act
> as a single layer-3 interface as far as the routing infrastructure is
> concerned.

Interfaces can be anything that the local box is configured to treat as an
interface.  Specifically, an LSP or (possibly bidirectional) set of LSPs can

be treated as an interface.  As David points out multiple physical
interfaces
may be treated as a single logical 'interface'.  Also, one physical
interface
can be treated as multiple logical interfaces.

This is not always a good idea and should not be done without some good
reason since it adds complexity.  For example, two adjacent LSRs should
be in agreement as to what each thinks are the interfaces connecting them or

you can get interesting behavior.

This points to the 'independently addressable' aspect of an interface as
David mentions - as long as both ends are in agreement as to what an
interface consists of each can independently address the interface of the
other.

>
>
> > 2. what is the "all routers on this subnet" group multicast address?
>
> Multicast 101.  It is a well-known multicast IP address.  Its behavior
> is similar to broadcast addresses, except that only routers should
> process the packets - hosts should not.

It is 0xe0000002 (224.0.0.2).

>
>
> > 3. if a LSR's neighbour router is not LSR, it doesn't understand
> > the LDP Link Hellos, should it ignore the message or send a
> > notification message back? if it sends a notification message back
> > to the LSR,then how to make sure that the LSR understands the
> > notification message? it seems like a dead loop.
>
> The LDP Hello messages are sent to a specific wel-known UDP port.  If
> the receiving router isn't running LDP (the only legitimate reason to
> not understand an LDP Hello packet), then it won't be listening on that
> port, and the packet will get ignored.

LDP TCP/UDP well known ports are explicitly listed in RFC 3036 and in
assigned numbers. They are both 646.

>
>
> An LDP router sends its hello packets to the all-routers address on each
> interface.  If there are no other LDP routers attached, then it will get
> no answers.  If there are any LDP routers attached, then each one will
> get the Hello, and each will respond.

Each will be sending its own Hello messages (as opposed to responding to
those sent by the other).  The response to a hello message depends on the
determination of transport address as described in RFC 3036.

> Then the TCP sessions will be
> created according to the RFC.  Once the TCP sessions are established,
> the routers can be considered "LDP Peers", since they are now able to
> send state-changing messages to each other.

A really minor nit - they are peers from the moment that they discover
each other.  At least that is how the RFC is worded.  An LSR cannot
establish a session with a peer if the session must exist before the other
LSR is a peer.

>
>
> -- David



From owner-mpls@UU.NET  Tue Aug 21 21:29:26 2001
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 VAA04339
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 21:29:26 -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 QQldco18148;
	Wed, 22 Aug 2001 01:30:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldco21120
	for mpls-outgoing; Wed, 22 Aug 2001 01:30: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 QQldco21114
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 01:30: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 QQldcn19216
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:28:38 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldcn25186
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:28:38 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA20369 for mpls@uu.net; Tue, 21 Aug 2001 21:28:36 -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 QQldcn20987
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 01:28:23 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 QQldcn15498
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:27:02 GMT
Received: from hafnium.mcis.singnet.com.sg by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hafnium.singnet.com.sg [165.21.74.90])
	id QQldcn12896
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:27:01 GMT
Received: from mail pickup service by hafnium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 09:25:35 +0800
Received: from mx11.singnet.com.sg ([165.21.74.121]) by hafnium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 22 Aug 2001 07:13:43 +0800
Received: from mta572.mail.yahoo.com (mta572.mail.yahoo.com [216.136.172.101])
	by mx11.singnet.com.sg (8.11.5/8.11.5) with SMTP id f7LNDeh14758
	for <ncc49a@singnet.com.sg>; Wed, 22 Aug 2001 07:13:41 +0800
Received: from mta572.mail.yahoo.com for ncc49a@singnet.com.sg; Aug 21 16:13:39 2001 -0700
X-Track: 8: 40
X-Yahoo-Forwarded: from paulngtp@yahoo.com.sg to ncc49a@singnet.com.sg
Received: from cmr0.ash.ops.us.uu.net (198.5.241.38)
  by mta572.mail.yahoo.com with SMTP; 21 Aug 2001 16:13:39 -0700 (PDT)
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 QQldce11008;
	Tue, 21 Aug 2001 23:13:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldce01939
	for mpls-outgoing; Tue, 21 Aug 2001 23:12: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 QQldce01932
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:12: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 QQldce12147
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:11:51 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldce09014
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:11:50 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA12796 for mpls@uu.net; Tue, 21 Aug 2001 19:11:49 -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 QQldce01816
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:11: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 QQldce08647
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:10:17 GMT
Received: from scaup.mail.pas.earthlink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: scaup.mail.pas.earthlink.net [207.217.121.49])
	id QQldce07471
	for <mpls@uu.net>; Tue, 21 Aug 2001 23:10:17 GMT
Received: from computer.mplsrc.com (dialup-64.157.50.54.Dial1.Washington1.Level3.net [64.157.50.54])
	by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA11486
	for <mpls@uu.net>; Tue, 21 Aug 2001 16:10:15 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010821191031.01e545d0@mail.earthlink.net>
X-Sender: mplsrc12@mplsrc.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 21 Aug 2001 19:11:21 -0400
To: mpls@UU.NET
From: MPLS Resource Center <admin@mplsrc.com>
Subject: MPLS-OPS Mailing List
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

On August 21st we suffered a loss of the MPLS-OPS mailing list subscriber 
data file.  As of the evening of 8/21, we have only been able to restore a 
portion of the file.

If you were a member of the MPLS-OPS mailing list, we ask that you visit 
our MPLS-OPS page to re-subscribe at :
http://www.mplsrc.com/mplsops.shtml.

We apologize for any inconvenience this might have caused.



From owner-mpls@UU.NET  Tue Aug 21 21:38:00 2001
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 VAA05389
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 21:38:00 -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 QQldco01854;
	Wed, 22 Aug 2001 01:39:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldco22944
	for mpls-outgoing; Wed, 22 Aug 2001 01:38: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 QQldco22938
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 01:38: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 QQldco00730
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:38:32 GMT
Received: from tellurium.mcis.singnet.com.sg by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tellurium.singnet.com.sg [165.21.74.71])
	id QQldco07696
	for <mpls@uu.net>; Wed, 22 Aug 2001 01:38:31 GMT
Received: from mail pickup service by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 09:35:41 +0800
Received: from mx15.singnet.com.sg ([165.21.74.115]) by tellurium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 22 Aug 2001 07:26:10 +0800
Received: from mta542.mail.yahoo.com (mta542.mail.yahoo.com [216.136.131.24])
	by mx15.singnet.com.sg (8.11.5/8.11.5) with SMTP id f7LNNE102577
	for <ncc49a@singnet.com.sg>; Wed, 22 Aug 2001 07:23:14 +0800
Received: from mta542.mail.yahoo.com for ncc49a@singnet.com.sg; Aug 21 16:26:09 2001 -0700
X-Track: 11: 40
X-Yahoo-Forwarded: from paulngtp@yahoo.com.sg to ncc49a@singnet.com.sg
Received: from cmr0.ash.ops.us.uu.net (198.5.241.38)
  by mta542.mail.yahoo.com with SMTP; 21 Aug 2001 16:26:09 -0700 (PDT)
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 QQldcf23798;
	Tue, 21 Aug 2001 23:26:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcf03246
	for mpls-outgoing; Tue, 21 Aug 2001 23:25:01 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 QQldcf03235
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 23:24:59 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 QQldcf23519
	for <mpls@UU.NET>; Tue, 21 Aug 2001 23:23:30 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQldcf13869
	for <mpls@UU.NET>; Tue, 21 Aug 2001 23:23:29 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7LNN6p06291
	for <mpls@UU.NET>; Tue, 21 Aug 2001 19:23:06 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 21 Aug 2001 19:23:27 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RABGARTL>; Tue, 21 Aug 2001 19:23:28 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431077C9E0B@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Adrian Farrel <afarrel@movaz.com>,
        "Peter Ashwood-Smith" <petera@nortelnetworks.com>
Cc: "Bilel Jamoussi" <jamoussi@nortelnetworks.com>,
        "Darek Skalecki" <dareks@nortelnetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Small comment on draft-ietf-mpls-te-feed-02.txt
Date: Tue, 21 Aug 2001 19:23:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12A98.46747F40"
X-Orig: <dwfedyk@americasm01.nt.com>
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_01C12A98.46747F40
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Adrian 

This seems like a reasonable request. We can add text around this.

There is one point though, that the reporting zero bandwidth is 
logically independent to the node going down or the removal of LSPs.
Actually, we use zero feedback to mean temporarily avoid this 
link as a default case from situations like this. It is important to 
remember the adjacent node sees the real bandwidth but due to LDP 
being in an indeterminate state his option is to report the link 
as being full (zero bandwidth). The restaging of the LDP adjacencies 
should trigger corresponding link LSA to reaffirm the actual bandwidth 
in these cases. 

Regards,
Don

Adrian Farrel wrote:

Peter,

Thanks for this draft which looks stable to me.

Would it be possible to add a reference to LDP FT procedures
(draft-ietf-ldp-ft) in section 5?  I think the third paragraph should have
the following text appended...

  Where LDP FT procedures [LDP-FT] are in use, LSPs that are protected
  by FT procedures should not be torn down until after session re-
  establishment has failed.  Further, feedback TLVs should not report
  zero bandwidth availability on the link until after session re-
  establishment has failed.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com

------_=_NextPart_001_01C12A98.46747F40
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.2654.89">
<TITLE>RE: Small comment on draft-ietf-mpls-te-feed-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Adrian </FONT>
</P>

<P><FONT SIZE=3D2>This seems like a reasonable request. We can add text =
around this.</FONT>
</P>

<P><FONT SIZE=3D2>There is one point though, that the reporting zero =
bandwidth is </FONT>
<BR><FONT SIZE=3D2>logically independent to the node going down or the =
removal of LSPs.</FONT>
<BR><FONT SIZE=3D2>Actually, we use zero feedback to mean temporarily =
avoid this </FONT>
<BR><FONT SIZE=3D2>link as a default case from situations like this. It =
is important to </FONT>
<BR><FONT SIZE=3D2>remember the adjacent node sees the real bandwidth =
but due to LDP </FONT>
<BR><FONT SIZE=3D2>being in an indeterminate state his option is to =
report the link </FONT>
<BR><FONT SIZE=3D2>as being full (zero bandwidth). The restaging of the =
LDP adjacencies </FONT>
<BR><FONT SIZE=3D2>should trigger corresponding link LSA to reaffirm =
the actual bandwidth </FONT>
<BR><FONT SIZE=3D2>in these cases. </FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Don</FONT>
</P>

<P><FONT SIZE=3D2>Adrian Farrel wrote:</FONT>
</P>

<P><FONT SIZE=3D2>Peter,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for this draft which looks stable to =
me.</FONT>
</P>

<P><FONT SIZE=3D2>Would it be possible to add a reference to LDP FT =
procedures (draft-ietf-ldp-ft) in section 5?&nbsp; I think the third =
paragraph should have the following text appended...</FONT></P>

<P><FONT SIZE=3D2>&nbsp; Where LDP FT procedures [LDP-FT] are in use, =
LSPs that are protected</FONT>
<BR><FONT SIZE=3D2>&nbsp; by FT procedures should not be torn down =
until after session re-</FONT>
<BR><FONT SIZE=3D2>&nbsp; establishment has failed.&nbsp; Further, =
feedback TLVs should not report</FONT>
<BR><FONT SIZE=3D2>&nbsp; zero bandwidth availability on the link until =
after session re-</FONT>
<BR><FONT SIZE=3D2>&nbsp; establishment has failed.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Adrian</FONT>
<BR><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>Movaz Networks Inc.</FONT>
<BR><FONT SIZE=3D2>afarrel@movaz.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A98.46747F40--


From owner-mpls@UU.NET  Tue Aug 21 22:23:05 2001
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 WAA05746
	for <mpls-archive@lists.ietf.org>; Tue, 21 Aug 2001 22:23:04 -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 QQldcr22132;
	Wed, 22 Aug 2001 02:24:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcr15691
	for mpls-outgoing; Wed, 22 Aug 2001 02:23:47 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 QQldcr15684
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 02:23: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 QQldcr08502
	for <mpls@uu.net>; Wed, 22 Aug 2001 02:23:35 GMT
Received: from selenium.mcis.singnet.com.sg by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: selenium.singnet.com.sg [165.21.74.70])
	id QQldcr26063
	for <mpls@uu.net>; Wed, 22 Aug 2001 02:23:34 GMT
Received: from mail pickup service by selenium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 10:23:06 +0800
Received: from mx13.singnet.com.sg ([165.21.74.113]) by thorium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 22 Aug 2001 08:53:25 +0800
Received: from mta512.mail.yahoo.com (mta512.mail.yahoo.com [216.136.131.251])
	by mx13.singnet.com.sg (8.11.5/8.11.5) with SMTP id f7M0rN010605
	for <ncc49a@singnet.com.sg>; Wed, 22 Aug 2001 08:53:23 +0800
Received: from mta512.mail.yahoo.com for ncc49a@singnet.com.sg; Aug 21 17:53:21 2001 -0700
X-Track: 13: 40
X-Yahoo-Forwarded: from paulngtp@yahoo.com.sg to ncc49a@singnet.com.sg
Received: from cmr2.ash.ops.us.uu.net (198.5.241.40)
  by mta512.mail.yahoo.com with SMTP; 21 Aug 2001 17:53:20 -0700 (PDT)
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 QQldcl16964;
	Wed, 22 Aug 2001 00:53:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldcl29300
	for mpls-outgoing; Wed, 22 Aug 2001 00:52: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 QQldcl29294
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 00:52:06 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 QQldcl25457
	for <mpls@UU.NET>; Wed, 22 Aug 2001 00:51:24 GMT
Received: from chmls06.mediaone.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chmls06.mediaone.net [24.147.1.144])
	id QQldcl25969
	for <mpls@UU.NET>; Wed, 22 Aug 2001 00:51:24 GMT
Received: from mindspring.com (h00a0ccd1a9ec.ne.mediaone.net [24.128.219.249])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f7M0ojm21618;
	Tue, 21 Aug 2001 20:50:46 -0400 (EDT)
Message-ID: <3B830163.83624ED6@mindspring.com>
Date: Tue, 21 Aug 2001 20:48:35 -0400
From: Eric W Gray <ewgray@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Hongwei Zhou <hongwei.zhou@elec.qmul.ac.uk>
CC: David Charlap <david.charlap@marconi.com>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: Re: How to know that egress router is reached?
References: <MEEJLEKIFLLBNABPKDAOCEDJCFAA.hongwei.zhou@elec.qmul.ac.uk> <3B82DF9C.B1524CC1@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hongwei,

    I've added some comments WRT David's responses below.  Most are
nits.

David Charlap wrote:

> Hongwei wrote:
> >
> > First thank David very much.  In RFC 3036, the basic discovery
> > mechanism is:
> > To engage in LDP Basic Discovery on an interface an LSR periodically
> > sends LDP Link Hellos out the interface.  LDP Link Hellos are sent
> > as UDP packets addressed to the well-known LDP discovery port for
> > the "all routers on this subnet" group multicast address.
> >
> > here I have something not understood:
> > 1. what does the term "interface" mean? is it a physical port to
> > which a link is connected to? if a router has four transimitters,
> > it has four interfaces. am I right?
>
> If they are four independantly addressible (not necessarily via IP
> address), then yes.
>
> I mention this qualifier to distinguish it from ports that are all
> electrically identical.  For instance, you might have a multi-port
> Ethernet card where all the ports are bridged together and therefore act
> as a single layer-3 interface as far as the routing infrastructure is
> concerned.

Interfaces can be anything that the local box is configured to treat as an
interface.  Specifically, an LSP or (possibly bidirectional) set of LSPs can

be treated as an interface.  As David points out multiple physical
interfaces
may be treated as a single logical 'interface'.  Also, one physical
interface
can be treated as multiple logical interfaces.

This is not always a good idea and should not be done without some good
reason since it adds complexity.  For example, two adjacent LSRs should
be in agreement as to what each thinks are the interfaces connecting them or

you can get interesting behavior.

This points to the 'independently addressable' aspect of an interface as
David mentions - as long as both ends are in agreement as to what an
interface consists of each can independently address the interface of the
other.

>
>
> > 2. what is the "all routers on this subnet" group multicast address?
>
> Multicast 101.  It is a well-known multicast IP address.  Its behavior
> is similar to broadcast addresses, except that only routers should
> process the packets - hosts should not.

It is 0xe0000002 (224.0.0.2).

>
>
> > 3. if a LSR's neighbour router is not LSR, it doesn't understand
> > the LDP Link Hellos, should it ignore the message or send a
> > notification message back? if it sends a notification message back
> > to the LSR,then how to make sure that the LSR understands the
> > notification message? it seems like a dead loop.
>
> The LDP Hello messages are sent to a specific wel-known UDP port.  If
> the receiving router isn't running LDP (the only legitimate reason to
> not understand an LDP Hello packet), then it won't be listening on that
> port, and the packet will get ignored.

LDP TCP/UDP well known ports are explicitly listed in RFC 3036 and in
assigned numbers. They are both 646.

>
>
> An LDP router sends its hello packets to the all-routers address on each
> interface.  If there are no other LDP routers attached, then it will get
> no answers.  If there are any LDP routers attached, then each one will
> get the Hello, and each will respond.

Each will be sending its own Hello messages (as opposed to responding to
those sent by the other).  The response to a hello message depends on the
determination of transport address as described in RFC 3036.

> Then the TCP sessions will be
> created according to the RFC.  Once the TCP sessions are established,
> the routers can be considered "LDP Peers", since they are now able to
> send state-changing messages to each other.

A really minor nit - they are peers from the moment that they discover
each other.  At least that is how the RFC is worded.  An LSR cannot
establish a session with a peer if the session must exist before the other
LSR is a peer.

>
>
> -- David


From owner-mpls@UU.NET  Wed Aug 22 04:20:31 2001
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 EAA27519
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 04:20:30 -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 QQlddp28526;
	Wed, 22 Aug 2001 08:21:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlddp08404
	for mpls-outgoing; Wed, 22 Aug 2001 08:20: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 QQlddp08396
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 08:20:51 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 QQlddp04364
	for <mpls@uu.net>; Wed, 22 Aug 2001 08:20:11 GMT
Received: from shixun.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [211.100.17.156])
	id QQlddp27306
	for <mpls@uu.net>; Wed, 22 Aug 2001 08:20:10 GMT
Received: from gaohong.mail [202.108.105.131] by shixun.net with ESMTP
  (SMTPD32-6.04) id AA1B63700EE; Wed, 22 Aug 2001 16:15:23 +0800
Received: from zhoukui [192.216.224.88] by gaohong.mail [192.216.228.109]
	with SMTP (MDaemon.v2.83.R)
	for <mpls@uu.net>; Wed, 22 Aug 2001 16:24:54 +0800
Date: Wed, 22 Aug 2001 16:18:22 +0800
From: =?ISO-8859-1?Q?=D6=DC=BF=FB?= <zhoukui@gaohong.com.cn>
Reply-To: zhoukui@gaohong.com.cn
To: "mpls@uu.net" <mpls@UU.NET>
Subject: has ietf completed Specifying MPLS-specific recovery mechanisms ?
X-mailer: FoxMail 3.11 Release [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: mpls@uu.net
X-Return-Path: zhoukui@gaohong.com.cn
Message-Id: <200108221615312.SM00952@gaohong.mail>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

	hi, does anyone know whether ietf has completed Specifying MPLS-specific recovery mechanisms which allow one label-switched path to be used as backup for a set of other label-switched paths, including cases which permit local repair?
	thanks a lot!

            zhoukui@gaohong.com.cn




From owner-mpls@UU.NET  Wed Aug 22 06:31:15 2001
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 GAA28862
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 06:31:15 -0400 (EDT)
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 QQlddy07329;
	Wed, 22 Aug 2001 10:32:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlddy26886
	for mpls-outgoing; Wed, 22 Aug 2001 10:31: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 QQlddy26881
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 10:31:48 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 QQlddy19615
	for <mpls@UU.NET>; Wed, 22 Aug 2001 10:31:43 GMT
Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQlddy20891
	for <mpls@UU.NET>; Wed, 22 Aug 2001 10:31:42 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7MAVfu27442
	for <mpls@UU.NET>; Wed, 22 Aug 2001 06:31:41 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <P8WVJ11S>; Wed, 22 Aug 2001 12:31:30 +0200
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D49FBE6@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: George Swallow <swallow@cisco.com>, mpls@UU.NET
Cc: vijay@cosinecom.com
Subject: RE: Last call on recovery framework
Date: Wed, 22 Aug 2001 12:31:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

You probably mean
   draft-ietf-mpls-recovery-frmwrk-03.txt

I.e. revision 03 instead of 02 ??


Bert 

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: woensdag 22 augustus 2001 0:04
> To: mpls@UU.NET
> Cc: vijay@cosinecom.com
> Subject: Last call on recovery framework
> 
> 
> This message begins a last call on
> 
>       Framework for MPLS-based Recovery                     
>       <draft-ietf-mpls-recovery-frmwrk-02.txt>  
> 
> The last call ends on Sept 5 at midnight GMT.
> 
> ...George
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 


From owner-mpls@UU.NET  Wed Aug 22 07:03:57 2001
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 HAA29517
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 07:03: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 QQldea27039;
	Wed, 22 Aug 2001 11:05:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldea09740
	for mpls-outgoing; Wed, 22 Aug 2001 11:04:44 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 QQldea09481
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 11:04: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 QQldea29115
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:03:17 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldea07768
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:03:17 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA26494 for mpls@uu.net; Wed, 22 Aug 2001 07:03:15 -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 QQldea09181
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 11:02:57 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 QQldea03889
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:02:52 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 QQldea24019
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:02:52 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29417;
	Wed, 22 Aug 2001 07:01:34 -0400 (EDT)
Message-Id: <200108221101.HAA29417@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-ftn-mib-03.txt
Date: Wed, 22 Aug 2001 07:01:33 -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) FEC-To-NHLFE 
                          (FTN) Management Information Base
	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
	Filename	: draft-ietf-mpls-ftn-mib-03.txt
	Pages		: 25
	Date		: 21-Aug-01
	
This memo defines an experimental portion of the Management
Information Base  (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for defining FEC-to-NHLFE mapping and corresponding actions for use
with Multiprotocol Label Switching (MPLS).

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-ftn-mib-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-ftn-mib-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:	<20010821104704.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ftn-mib-03.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 22 07:04:08 2001
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 HAA29528
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 07:04:07 -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 QQldea27443;
	Wed, 22 Aug 2001 11:05:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldea09797
	for mpls-outgoing; Wed, 22 Aug 2001 11:04: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 QQldea09737
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 11:04:43 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 QQldea17405
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:03:37 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldea08059
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:03:37 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA26514 for mpls@uu.net; Wed, 22 Aug 2001 07:03:35 -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 QQldea09198
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 11:03:16 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 QQldea25676
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:02:57 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 QQldea24125
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:02:57 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29433;
	Wed, 22 Aug 2001 07:01:38 -0400 (EDT)
Message-Id: <200108221101.HAA29433@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-tc-mib-02.txt
Date: Wed, 22 Aug 2001 07:01:38 -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		: Definitions of Textual Conventions and 
                          OBJECT-IDENTITIES for Multi-Protocol Label Switching 
                          (MPLS)Management
	Author(s)	: T. Nadeau et al.
	Filename	: draft-ietf-mpls-tc-mib-02.txt
	Pages		: 13
	Date		: 21-Aug-01
	
This memo describes Textual Conventions and OBJECT-IDENTITIES used
for managing MPLS networks

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-tc-mib-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-tc-mib-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:	<20010821104729.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-tc-mib-02.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 22 08:57:53 2001
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 IAA04678
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 08:57:53 -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 QQldeh08728;
	Wed, 22 Aug 2001 12:58:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldeh14382
	for mpls-outgoing; Wed, 22 Aug 2001 12:58: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 QQldeh14377
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 12:58:25 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 QQldeh15770
	for <mpls@UU.NET>; Wed, 22 Aug 2001 12:58:16 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 QQldeh00155
	for <mpls@UU.NET>; Wed, 22 Aug 2001 12:58:16 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 IAA03383
	for <mpls@UU.NET>; Wed, 22 Aug 2001 08:53:45 -0400 (EDT)
Subject: RSVP questions
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF4AAA415E.3BAA8EF1-ON85256AB0.0046B79A@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Wed, 22 Aug 2001 08:53:41 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/22/2001 08:53:41 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

>>Assuming that everything else in the packet is well-formed, then this is
probably a bug in the implementation.  You may want to contact your
vendor in order to let them know so that they can fix it.

>>Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid.
An invalid checksum will cause the router to drop the message without
generating any errors.

Thanks for your reply.

Yes, I use the valid the rsvp path msg, and just give an unknown ctype for
the LRO, I can see from the router statistics, it does receive the path
msg(it does not drop the pkt), but it does not generate the patherr as
draft said.

what could be the problem?


[]  But even that is the case,  --bad checksum, the Router should send back
the path error msg with error code 23.

----------   spec 2205.
 Error Code = 23: RSVP System error


o    Wrong-length message: RSVP Length field does not match message
        length.

   o    Unknown or unsupported RSVP version.

   o    Bad RSVP checksum

   o    INTEGRITY failure

Thanks,

Julia



From owner-mpls@UU.NET  Wed Aug 22 11:35:41 2001
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 LAA13759
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 11:35:41 -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 QQldes22684;
	Wed, 22 Aug 2001 15:36:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldes26426
	for mpls-outgoing; Wed, 22 Aug 2001 15:36:14 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 QQldes26356
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 15:36:00 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 QQldes04897
	for <mpls@uu.net>; Wed, 22 Aug 2001 15:35:09 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f214.law10.hotmail.com [64.4.15.214])
	id QQldes04221
	for <mpls@uu.net>; Wed, 22 Aug 2001 15:35:09 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 08:35:08 -0700
Received: from 12.125.43.134 by lw10fd.law10.hotmail.msn.com with HTTP;	Wed, 22 Aug 2001 15:35:08 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: mpls@UU.NET
Subject: LLC/SNAP encapsulation over ATM interface for control connection
Date: Wed, 22 Aug 2001 15:35:08 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F214B5Rw1SSfWXWzRPT00004306@hotmail.com>
X-OriginalArrivalTime: 22 Aug 2001 15:35:08.0924 (UTC) FILETIME=[0663DBC0:01C12B20]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Could somebody, please, clarify LLC/SNAP encapsulation issue for non-MPLS 
connection between peers connected via ATM interface? (Rfc3035, MPLS over 
ATM, section "7. Use of VPI/VCIs")
Such connection must use LLC/SNAP encapsulation. Is this connection used for 
unlabeled traffic only? Can this connection carry MPLS labeled packets in 
case PHP and original packet has more than one label on stack? Can LSR send 
labeled packet over this control connection without PHP in case two peers 
are BGP speakers with VPN capability (two labels on label stack – bottom 
label is BGP/VPN label, possibly missing top label is for tunnel between BGP 
speakers).

Thank you,
Igor


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 22 12:00:13 2001
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 MAA14721
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 12:00:13 -0400 (EDT)
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 QQldeu03353;
	Wed, 22 Aug 2001 16:01:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldeu01139
	for mpls-outgoing; Wed, 22 Aug 2001 16: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 QQldeu01085
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 16:00:47 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 QQldeu28134
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:00:25 GMT
Received: from web13302.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web13302.mail.yahoo.com [216.136.175.38])
	id QQldeu02249
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:00:25 GMT
Message-ID: <20010822160025.74612.qmail@web13302.mail.yahoo.com>
Received: from [202.54.115.162] by web13302.mail.yahoo.com; Wed, 22 Aug 2001 09:00:25 PDT
Date: Wed, 22 Aug 2001 09:00:25 -0700 (PDT)
From: Ramyanshu Datta <romidatta@yahoo.com>
Subject: Diff. bet. FIB and RIB
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2083695899-998496025=:74524"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-2083695899-998496025=:74524
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,


     I have got a doubt. What is the difference
between Forward Information Base (FIB)and Routing
Information Base (RIB).

      Please let me know. 

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--0-2083695899-998496025=:74524--


From owner-mpls@UU.NET  Wed Aug 22 12:12:15 2001
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 MAA15160
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 12:12:14 -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 QQldeu14657;
	Wed, 22 Aug 2001 16:13:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldeu17311
	for mpls-outgoing; Wed, 22 Aug 2001 16:13: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 QQldeu17274
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 16:12:55 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 QQldeu22366
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:12:44 GMT
Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQldeu16193
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:12:44 GMT
Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7MGChF28107;
	Wed, 22 Aug 2001 12:12:43 -0400 (EDT)
Received: from bandito.inse.lucent.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr)
	id MAA10629 for ; Wed, 22 Aug 2001 12:12:41 -0400 (EDT)
Received: by bandito.inse.lucent.com with Internet Mail Service (5.5.2650.21)
	id <Q62MDMBX>; Wed, 22 Aug 2001 12:12:42 -0400
Message-ID: <BAC9CCF04FEED311BD1D00062950ABB10184A10B@bandito.inse.lucent.com>
From: Feihong Chen <fchen6@lucent.com>
To: dkatz@juniper.net, kireeti@juniper.net
Cc: mpls@UU.NET
Subject: question about the traffic engineering extensions to OSPF
Date: Wed, 22 Aug 2001 12:12:41 -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

Hi, 

I just realized that the new version of the "Traffic Engineering Extensions
to OSPF (draft-katz-yeung-ospf-traffic-05.txt)" made some changes on the
Sec2.4.2 (Link TLV). Unlike the previous version of the draft, this version
proposed that "The Link Type and Link ID sub-TLVs are mandatory, i.e., must
appear exactly once. All other sub-TLVs defined here may occur at most
once." (Note, other sub-TLVs includes traffic engineering metric,
local/remote interface ip address, bandwidth information, class/color).

The question that I have here is, if the LSA only advertise the Link Type
and Link ID as mandatory, then I don't see the capability of OSPF being a
"traffic engineering helper" because the Traffic Engineering Database build
from these two information ( which is the worst case ) simply is not able to
calculate the ERO (i.e. the list of ip addresses), nor the bandwidth for an
attempted LSP. 

In another word, if the proposed extensions to OSPF is mainly for traffic
engineering, shouldn't some or all of  "other sub-TLVs" (e.g. bandwidth, ip
address, color) be necessarily advertised besides the Link Type and Link ID?
Otherwise, it will end up the traditional OSPF not for TE purpose? 

Maybe I miss something here, looking forward to a clarify to better
understand the purpose of this updated changes.

Thanks a lot,
Feihong Chen

 



From owner-mpls@UU.NET  Wed Aug 22 12:44:58 2001
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 MAA16191
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 12:44:58 -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 QQldex01268;
	Wed, 22 Aug 2001 16:46:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldex21127
	for mpls-outgoing; Wed, 22 Aug 2001 16:45: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 QQldex21121
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 16:45: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 QQldew24730
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:44:27 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 QQldew22019
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:44:27 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 MAA14699
	for <mpls@UU.NET>; Wed, 22 Aug 2001 12:44:24 -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 MAA18051
	for <mpls@UU.NET>; Wed, 22 Aug 2001 12:44:26 -0400 (EDT)
Message-ID: <3B83E188.E941B23F@marconi.com>
Date: Wed, 22 Aug 2001 12:44:56 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: 
References: <OF0D7E1972.B5DE5FF1-ON85256AAF.007CB4E1@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:
> 
> []  But even that is the case,  --bad checksum, the Router should
> send back the path error msg with error code 23.
> 
> ----------   spec 2205.
>  Error Code = 23: RSVP System error
> 
> o    Wrong-length message: RSVP Length field does not match message
>         length.
> 
>    o    Unknown or unsupported RSVP version.
> 
>    o    Bad RSVP checksum
> 
>    o    INTEGRITY failure

You deleted four paragraphs of text between the line "Error Code = 23"
and the list of conditions.  Among other things, those four paragraphs
contain:

	... Should a programming error allow an RSVP to create a
	malformed message, the error is not generally reported to
	end systems in an ERROR_SPEC object; instead, the error is
	simply logged locally, and perhaps reported through network
	management mechanisms.

	The only message formatting errors that are reported to end
	systems are those that may reflect version mismatches, and
	which the end system might be able to circumvent, e.g., by
	falling back to a previous CType for an object; see code 13
	and 14 above.

	The choice of message formatting errors that an RSVP may
	detect and log locally is implementation-specific, but it
	will typically include the following:

	...  (list of conditions)

The RFC explicitly states that conditions like wrong-length message,
unknown RSVP version, bad checksum and INTEGRITY failure do _NOT_ cause
the generation of error messages.  The packets are dropped.  The error
condition may be logged or reported through network management.

-- David


From owner-mpls@UU.NET  Wed Aug 22 12:55:10 2001
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 MAA16466
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 12:55:09 -0400 (EDT)
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 QQldex06181;
	Wed, 22 Aug 2001 16:56:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldex22279
	for mpls-outgoing; Wed, 22 Aug 2001 16:55:50 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 QQldex22272
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 16:55:47 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 QQldex27668
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:55:23 GMT
Received: from nwds0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQldex14856
	for <mpls@UU.NET>; Wed, 22 Aug 2001 16:55:23 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Wed, 22 Aug 2001 12:50:26 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: <mpls@UU.NET>
Cc: "Thomas D. Nadeau \(E-mail\)" <tnadeau@cisco.com>,
        "Arun Viswanathan \(E-mail\)" <arun@force10networks.com>,
        "George Swallow" <swallow@cisco.com>,
        "Vijay Srinivasan" <vijay@cosinecom.com>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Date: Wed, 22 Aug 2001 13:07:28 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB110@OPTONT>
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.2911.0)
Importance: Normal
In-Reply-To: <200108221101.HAA29417@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

Version 03 of the FTN MIB I-D is now available on the IETF
website (see below). We (the authors) believe its ready
for last call at this point. Please email your comments
to the list. Thanks.

Cheenu

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, August 22, 2001 7:02 AM
> To: IETF-Announce
> Cc: mpls@UU.NET
> Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
> 
> 
> 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) 
> FEC-To-NHLFE 
>                           (FTN) Management Information Base
> 	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
> 	Filename	: draft-ietf-mpls-ftn-mib-03.txt
> 	Pages		: 25
> 	Date		: 21-Aug-01
> 	
> This memo defines an experimental portion of the Management
> Information Base  (MIB) for use with network management protocols in
> the Internet community.  In particular, it describes managed objects
> for defining FEC-to-NHLFE mapping and corresponding actions for use
> with Multiprotocol Label Switching (MPLS).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-mpls-ftn-mib-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-ftn-mib-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  Wed Aug 22 13:37:48 2001
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 NAA17940
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 13:37:47 -0400 (EDT)
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 QQldfa25087;
	Wed, 22 Aug 2001 17:38:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfa15051
	for mpls-outgoing; Wed, 22 Aug 2001 17:38:28 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 QQldfa15045
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 17:38:26 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 QQldfa17998
	for <mpls@uu.net>; Wed, 22 Aug 2001 17:36:31 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldfa07822
	for <mpls@uu.net>; Wed, 22 Aug 2001 17:36:30 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA24222 for mpls@uu.net; Wed, 22 Aug 2001 13:36:29 -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 QQldfa14867
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 17:35:59 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 QQldfa18240
	for <mpls@UU.NET>; Wed, 22 Aug 2001 17:33:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldfa07812
	for <mpls@UU.NET>; Wed, 22 Aug 2001 17:33:01 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA06474; Wed, 22 Aug 2001 13:27:41 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA15921; Wed, 22 Aug 2001 13:27:41 -0400 (EDT)
Message-Id: <200108221727.NAA15921@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: George Swallow <swallow@cisco.com>, mpls@UU.NET, vijay@cosinecom.com,
        swallow@cisco.com
Subject: Re: Last call on recovery framework 
In-reply-to: Your message of "Wed, 22 Aug 2001 12:31:28 +0200."
             <2413FED0DFE6D111B3F90008C7FA61FB0D49FBE6@nl0006exch002u.nl.lucent.com> 
Date: Wed, 22 Aug 2001 13:27:41 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> You probably mean
>    draft-ietf-mpls-recovery-frmwrk-03.txt
> 
> I.e. revision 03 instead of 02 ??

Yes.  Thanks for the correction.

...George

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



From owner-mpls@UU.NET  Wed Aug 22 13:58:45 2001
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 NAA18528
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 13:58:45 -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 QQldfb17310;
	Wed, 22 Aug 2001 17:59:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfb16841
	for mpls-outgoing; Wed, 22 Aug 2001 17:59: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 QQldfb16808
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 17:59:20 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 QQldfb05149
	for <mpls@UU.NET>; Wed, 22 Aug 2001 17:58:07 GMT
Received: from mail.krioukov.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [24.15.191.36])
	id QQldfb14581
	for <mpls@UU.NET>; Wed, 22 Aug 2001 17:58:06 GMT
Received: from DIMA1 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id NAA05352;
	Wed, 22 Aug 2001 13:58:01 -0400
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
Cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>,
        "Awduche, Daniel" <awduche@movaz.com>,
        "Ramesh Bhandari" <bhandari@hotair.hobl.lucent.com>
Subject: RE: [IP-Optical] Re: An algorithm for calculating all paths between an s-d pair
Date: Wed, 22 Aug 2001 13:58:02 -0400
Message-ID: <NCBBIKACLKNMKDHKKKNFCEPKFPAA.dima@krioukov.net>
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)
Importance: Normal
In-Reply-To: <A6B096B65978D148BB1B313B18CECC80195B891B@exchange01.movaz.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

There is yet another excellent book on the subject:
"Network Optimization: Continuous and Discrete Models"
by Dimitri Bertsekas, but goes well beyond the both
topics.
--
dima.

> -----Original Message-----
> From: ip-optical-admin@lists.bell-labs.com
> [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Awduche,
> Daniel
> Sent: Thursday, August 16, 2001 11:43 AM
> To: Ramesh Bhandari; Chrysostomos Tziouvaras
> Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com;
> Awduche, Daniel
> Subject: RE: [IP-Optical] Re: An algorithm for calculating all paths
> between an s-d pair
> 
> 
> The 'K-Shortest Path' problem is well known and
> well studied (dating back to the late 1950's).
> Many different versions of this problem exist, 
> subject to various types of restrictions.
> 
> There are solution techniques based on improvements
> to Dijkstra's algorithm, and many others based 
> on network flows and dynamic programming methods.
> Some approaches involve elegant graph transformations
> (as was the case, for example, in Ramesh's book on 
> diverse routing).
> 
> In addition to the references mentioned by Ramesh, 
> the works of David Eppstein (and the references
> therein) may be of interest:
> <http://www.ics.uci.edu/~eppstein/pubs/all.html>. 
> 
> CAVEAT:-- Many theoretical versions of the K-Shortest
> Path problem do not require the paths to be simple 
> (i.e. loop-free). 
> 
> Yes, the K-Shortest Path problem may have relevance in
> optical connection routing, especially when considering
> wavelength assignment, optical impairments, and other
> constraints.
> 
> Cheers,
> /Dan  
> 
> 
> > -----Original Message-----
> > From: Ramesh Bhandari [mailto:bhandari@hotair.hobl.lucent.com]
> > Sent: Tuesday, August 14, 2001 1:37 PM
> > To: Chrysostomos Tziouvaras
> > Cc: mpls-ops@mplsrc.com; mpls@UU.NET; IP-Optical@lists.bell-labs.com
> > Subject: [IP-Optical] Re: An algorithm for calculating all 
> > paths between
> > an s-d pair
> > 
> > 
> > Hi Chrysostomos,
> > 
> > I believe you are searching for the K-shortest path algorithm, which
> > provides paths for a given pair of nodes in ascending order of their
> > lengths. An example website for information on this is
> > http://www.mat.uc.pt/~eqvm/cientificos/investigacao/r_papers.html#mps.
> > 
> > But, if you are looking for algorithms for K-disjoint paths, these can
> > be found in my book: "Survivable Networks: Algorithms for Diverse
> > Routing", Kluwer Academic Publishers (1999).
> > 
> > Regards,
> > 
> > Ramesh
> > 
> > Chrysostomos Tziouvaras wrote:
> > > 
> > > Hi,
> > > I am searching for an algorithm for calculating all paths 
> > between an s-d
> > > pair. Can you provide me pointers to books or URLs?
> > > 
> > > Thanks
> > > Chrysostomos
> > 
> > _______________________________________________
> > IP-Optical mailing list
> > IP-Optical@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > 
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical


From owner-mpls@UU.NET  Wed Aug 22 14:49:37 2001
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 OAA20252
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 14:49: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 QQldff04755;
	Wed, 22 Aug 2001 18:50:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldff10558
	for mpls-outgoing; Wed, 22 Aug 2001 18:50:21 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 QQldff10547
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 18:50: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 QQldff19771
	for <mpls@uu.net>; Wed, 22 Aug 2001 18:50:15 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldff23013
	for <mpls@uu.net>; Wed, 22 Aug 2001 18:50:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA00207 for mpls@uu.net; Wed, 22 Aug 2001 14:50:13 -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 QQldff10402
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 18:49:59 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 QQldff27578
	for <mpls@uu.net>; Wed, 22 Aug 2001 18:48:48 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 QQldff06097
	for <mpls@uu.net>; Wed, 22 Aug 2001 18:48:43 GMT
Received: (qmail 21010 invoked by uid 104); 22 Aug 2001 18:48:42 -0000
Received: from yadavnav@mailhub.pmc-sierra.bc.ca by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.627734 secs); 22/08/2001 11:48:41
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 22 Aug 2001 18:48:41 -0000
Received: from moonlight.pmc-sierra.bc.ca (moonlight.pmc-sierra.bc.ca [209.68.182.22])
	by hymir.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f7MImal18324
	for <mpls@uu.net>; Wed, 22 Aug 2001 11:48:36 -0700 (PDT)
Received: (from yadavnav@localhost)
	by moonlight.pmc-sierra.bc.ca (6.6.6/6.6.6) id LAA15486
	for mpls@uu.net; Wed, 22 Aug 2001 11:48:27 -0700 (PDT)
Date: Wed, 22 Aug 2001 11:48:27 -0700
From: Navneet Yadav <navneet_yadav@pmc-sierra.com>
To: mpls@UU.NET
Message-ID: <20010822114827.B15142@pmc-sierra.com>
Reply-To: navneet_yadav@pmc-sierra.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-mpls@UU.NET
Precedence: bulk

subscribe



From owner-mpls@UU.NET  Wed Aug 22 15:04:35 2001
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 PAA20891
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:04:35 -0400 (EDT)
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 QQldfg17474;
	Wed, 22 Aug 2001 19:05:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfg22497
	for mpls-outgoing; Wed, 22 Aug 2001 19:05: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 QQldfg22218
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:05:11 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 QQldfg25868
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:01:51 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldfg11739
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:01:50 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA02154 for mpls@uu.net; Wed, 22 Aug 2001 15:01:49 -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 QQldff11025
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 18:55: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 QQldff15914
	for <mpls@UU.NET>; Wed, 22 Aug 2001 18:54:43 GMT
Received: from viva1.vivacenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQldff00446
	for <mpls@UU.NET>; Wed, 22 Aug 2001 18:54:43 GMT
Received: from viva.vivacenet.com (viva.vivacenetworks.com [10.2.0.5]) by viva1.vivacenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RHHN65WR; Wed, 22 Aug 2001 11:54:37 -0700
Received: from amirlpc [10.5.10.22] by viva.vivacenet.com
  (SMTPD32-5.05) id A050235600EE; Wed, 22 Aug 2001 11:56:16 -0700
Message-ID: <037401c12b3c$6eb25e60$160a050a@vivacenet.com>
From: "Amir Lehavot" <amir.lehavot@vivacenetworks.com>
To: <mpls@UU.NET>
Date: Wed, 22 Aug 2001 11:58:29 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0371_01C12B01.C248D800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

unsubscribe

------=_NextPart_000_0371_01C12B01.C248D800
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0371_01C12B01.C248D800--



From owner-mpls@UU.NET  Wed Aug 22 15:04:43 2001
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 PAA20906
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:04:43 -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 QQldfg26599;
	Wed, 22 Aug 2001 19:05:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfg23172
	for mpls-outgoing; Wed, 22 Aug 2001 19:05: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 QQldfg22528
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:05: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 QQldfg29871
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:03:40 GMT
Received: from wench.telica.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [209.6.93.30])
	id QQldfg23555
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:03:35 GMT
Received: by wench with Internet Mail Service (5.5.2653.19)
	id <Q7DFLC76>; Wed, 22 Aug 2001 15:03:35 -0400
Message-ID: <7AC90049E901D511A8CA009027289AEAD5AFA8@wench>
From: Abhishek Gupta <agupta@telica.com>
To: "'Ray Qiu'" <rayq@riverstonenet.com>,
        Eric W Gray
	 <ewgray@mindspring.com>
Cc: Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: RE: Time to live
Date: Wed, 22 Aug 2001 15:03:35 -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,
When we say MPLS TTL this means the TTL value in the label stack
entry (Rfc 3032) and which is used for only generic labels. Is that right?
thanks
-Abhi

-----Original Message-----
From: Ray Qiu [mailto:rayq@riverstonenet.com]
Sent: Tuesday, August 21, 2001 1:26 PM
To: Eric W Gray
Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
Subject: Re: Time to live


There is also an option that we don't copy the MPLS TTL back to IP TTL.
It makes IP think the MPLS LSP is only one hop.

Thanks,
Ray

On Tue, 21 Aug 2001, Eric W Gray wrote:

> Date: Tue, 21 Aug 2001 13:10:17 -0400
> From: Eric W Gray <ewgray@mindspring.com>
> To: Alexander Marhold <alexander@marhold.at>,
>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: Re: Time to live
>
> Below, the last sentence was supposed to be "Note that Frame
> Relay ..."
>
> --
> Eric Gray
>
> Eric W Gray wrote:
>
> > Alexander,
> >
> >     No cigar.  The distinction is not cell verses frame, but rather
> > whether or not it is possible to incorporate the label in the L2
> > encapsulation.  Where this is possible, ATM and FR, there is
> > no TTL capability in the L2 encapsulation.  Not that Frame
> > Relay is Frame based...
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > Hello
> > > I want to explain the mechanism a little bit more in detail
> > >
> > > FRAME based general:
> > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field
of
> > > the label header.
> > > 2. the label-TTL is decremented at each hop by 1
> > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > TTL-exceeded-ICMP message will be sent if possible
> > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > >
> > > CELL based general:
> > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field
of
> > > the label header.
> > > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by
1
> > > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he
knows from the
> > > LSP-setup using downstream on demand label allocation and ordered
> > > lsp-control label setup)
> > > 2. then the packet is chopped into cells
> > > 3. the egress reassembles the packet and copies the label ttl back
into the
> > > IP-TTL
> > >
> > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > >
> > > special features:
> > > a) on cisco LSRs there is the possibility to disable the copying of
the
> > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > on the egress the smaller of the 2 TTL-values ( label and IP-header)
will be
> > > used for the IP-TTL
> > > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > > network
> > >
> > > with best regards
> > >
> > > Alexander
> > >
> > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > >      __/
> > >     __/   Dipl.Ing. Alexander Marhold MBA
> > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > >   __/   Core & IP Services <Senior Consultant>
> > >  __/   Mobile: ++43-(0)664-16 28 234
> > > __/   PRO IN http://www.proin.com
> > >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > Asim.Khan@vf.vodafone.co.uk
> > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > To: c-david.escobar@wcom.com
> > > Cc: mpls@UU.NET
> > > Subject: RE: Time to live
> > >
> > > It stays the same. The routers only look at the label value not the IP
> > > header. When the packet leaves MPLS domain then the normal operation
would
> > > apply.
> > >
> > > Asim
> > >
> > > -----Original Message-----
> > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > Sent: 21 August 2001 17:19
> > > To: mpls@UU.NET
> > > Subject: Time to live
> > >
> > > Hi;
> > > What happens to the TTL field in the IP header when a labeled packet
goes
> > > through an LSP? Is it decreased at each router or stay the same?
>


From owner-mpls@UU.NET  Wed Aug 22 15:12:40 2001
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 PAA21139
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:12:39 -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 QQldfg08443;
	Wed, 22 Aug 2001 19:13:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfg00953
	for mpls-outgoing; Wed, 22 Aug 2001 19:13:27 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 QQldfg00948
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:13:24 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 QQldfg20799
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:13:18 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldfg29762
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:13:18 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA03631 for mpls@uu.net; Wed, 22 Aug 2001 15:13:16 -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 QQldfg00911
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:12: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 QQldfg17786
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:12:20 GMT
Received: from viva1.vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQldfg06426
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:12:19 GMT
Received: from viva.vivacenet.com (viva.vivacenetworks.com [10.2.0.5]) by viva1.vivacenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RHHN657V; Wed, 22 Aug 2001 12:12:11 -0700
Received: from dwightmpc [10.5.10.19] by viva.vivacenet.com
  (SMTPD32-5.05) id A46E7C960092; Wed, 22 Aug 2001 12:13:50 -0700
From: "Dwight McConn" <dwight.mcconn@vivacenetworks.com>
To: <mpls@UU.NET>
Subject: unsubscribe
Date: Wed, 22 Aug 2001 12:12:40 -0700
Message-ID: <NEBBKIOOIMLONLAMIEIBMEGHCJAA.dwight.mcconn@vivacenetworks.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

unsubscribe



From owner-mpls@UU.NET  Wed Aug 22 15:18:32 2001
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 PAA21294
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:18:32 -0400 (EDT)
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 QQldfh07115;
	Wed, 22 Aug 2001 19:19:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfh01686
	for mpls-outgoing; Wed, 22 Aug 2001 19:19: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 QQldfh01681
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:19: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 QQldfh25661
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:17:21 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldfh04365
	for <mpls@uu.net>; Wed, 22 Aug 2001 19:17:21 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 PAA22052 for <mpls@uu.net>; Wed, 22 Aug 2001 15:17:20 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA17576 for mpls@uu.net; Wed, 22 Aug 2001 15:16:53 -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 QQlder25603
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 15:27:16 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 QQlder01204
	for <mpls@uu.net>; Wed, 22 Aug 2001 15:27:04 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f62.law10.hotmail.com [64.4.15.62])
	id QQlder25298
	for <mpls@uu.net>; Wed, 22 Aug 2001 15:27:04 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 08:27:03 -0700
Received: from 12.125.43.134 by lw10fd.law10.hotmail.msn.com with HTTP;	Wed, 22 Aug 2001 15:27:03 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: mpls@UU.NET
Subject: LLC/SNAP encapsulation over ATM interface for control connection
Date: Wed, 22 Aug 2001 15:27:03 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F62O5SjMKtWNymWzAKb0000eaf1@hotmail.com>
X-OriginalArrivalTime: 22 Aug 2001 15:27:03.0997 (UTC) FILETIME=[E559DED0:01C12B1E]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Could somebody, please, clarify LLC/SNAP encapsulation issue for non-MPLS 
connection between peers connected via ATM interface? (Rfc3035, MPLS over 
ATM, section "7. Use of VPI/VCIs")
Such connection must use LLC/SNAP encapsulation. Is this connection used for 
unlabeled traffic only? Can this connection carry MPLS labeled packets in 
case PHP and original packet has more than one label on stack? Can LSR send 
labeled packet over this control connection without PHP in case two peers 
are BGP speakers with VPN capability (two labels on label stack – bottom 
label is BGP/VPN label, possibly missing top label is for tunnel between BGP 
speakers).

Thank you,
Igor


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 22 15:45:01 2001
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 PAA22110
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:44:52 -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 QQldfj26946;
	Wed, 22 Aug 2001 19:46:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfj03929
	for mpls-outgoing; Wed, 22 Aug 2001 19:45: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 QQldfj03924
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:45: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 QQldfj26126
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:45:16 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 QQldfj05005
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:45:16 GMT
Message-ID: <3B840BC5.92A59288@sandburst.com>
Date: Wed, 22 Aug 2001 15:45:09 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Abhishek Gupta <agupta@telica.com>
Cc: "'Ray Qiu'" <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MPLS Mailing List <mpls@UU.NET>
Subject: Re: Time to live
References: <7AC90049E901D511A8CA009027289AEAD5AFA8@wench>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Abhi,

    The label stack is normally present regardless of whether or not a
generic label is in use.  In those currently defined modes where the
generic label is not used, the label bits in the top level label stack
entry are not meaningful, but the TTL and S bits are and the EXP
bits may be.  As with the IP header itself, however, these bits are
not consulted at each hop in the LSP and can only have meaning at
the egress.

    There is an attempt to discuss the issues with not including a
label stack in RFC 3035.  This discussion shows how this can be
done, but is intended to show why no reasonable person would want
to do it, rather than to describe how it is expected to be done.

--
Eric Gray

You wrote:

> Hi,
> When we say MPLS TTL this means the TTL value in the label stack
> entry (Rfc 3032) and which is used for only generic labels. Is that right?
> thanks
> -Abhi
>
> -----Original Message-----
> From: Ray Qiu [mailto:rayq@riverstonenet.com]
> Sent: Tuesday, August 21, 2001 1:26 PM
> To: Eric W Gray
> Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> Subject: Re: Time to live
>
> There is also an option that we don't copy the MPLS TTL back to IP TTL.
> It makes IP think the MPLS LSP is only one hop.
>
> Thanks,
> Ray
>
> On Tue, 21 Aug 2001, Eric W Gray wrote:
>
> > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > From: Eric W Gray <ewgray@mindspring.com>
> > To: Alexander Marhold <alexander@marhold.at>,
> >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > Subject: Re: Time to live
> >
> > Below, the last sentence was supposed to be "Note that Frame
> > Relay ..."
> >
> > --
> > Eric Gray
> >
> > Eric W Gray wrote:
> >
> > > Alexander,
> > >
> > >     No cigar.  The distinction is not cell verses frame, but rather
> > > whether or not it is possible to incorporate the label in the L2
> > > encapsulation.  Where this is possible, ATM and FR, there is
> > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > Relay is Frame based...
> > >
> > > --
> > > Eric Gray
> > >
> > > You wrote:
> > >
> > > > Hello
> > > > I want to explain the mechanism a little bit more in detail
> > > >
> > > > FRAME based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field
> of
> > > > the label header.
> > > > 2. the label-TTL is decremented at each hop by 1
> > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > TTL-exceeded-ICMP message will be sent if possible
> > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > >
> > > > CELL based general:
> > > > 1. normally at the ingress LSR the IP-TTL is copied into the TTL-field
> of
> > > > the label header.
> > > > 1a. the ingress LSR to the ATM-MPLS cloud either decrements the TTL by
> 1
> > > > 1b              or by the amount of ATM_MPLS hops of the LSP ( this he
> knows from the
> > > > LSP-setup using downstream on demand label allocation and ordered
> > > > lsp-control label setup)
> > > > 2. then the packet is chopped into cells
> > > > 3. the egress reassembles the packet and copies the label ttl back
> into the
> > > > IP-TTL
> > > >
> > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> > > >
> > > > special features:
> > > > a) on cisco LSRs there is the possibility to disable the copying of
> the
> > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > on the egress the smaller of the 2 TTL-values ( label and IP-header)
> will be
> > > > used for the IP-TTL
> > > > then for traceroute the MPLS cloud looks like a 1-hop (2-hop with PHP)
> > > > network
> > > >
> > > > with best regards
> > > >
> > > > Alexander
> > > >
> > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > >      __/
> > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > >   __/   Core & IP Services <Senior Consultant>
> > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > __/   PRO IN http://www.proin.com
> > > >
> > > > -----Original Message-----
> > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > Asim.Khan@vf.vodafone.co.uk
> > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > To: c-david.escobar@wcom.com
> > > > Cc: mpls@UU.NET
> > > > Subject: RE: Time to live
> > > >
> > > > It stays the same. The routers only look at the label value not the IP
> > > > header. When the packet leaves MPLS domain then the normal operation
> would
> > > > apply.
> > > >
> > > > Asim
> > > >
> > > > -----Original Message-----
> > > > From: David Escobar [mailto:c-david.escobar@wcom.com]
> > > > Sent: 21 August 2001 17:19
> > > > To: mpls@UU.NET
> > > > Subject: Time to live
> > > >
> > > > Hi;
> > > > What happens to the TTL field in the IP header when a labeled packet
> goes
> > > > through an LSP? Is it decreased at each router or stay the same?
> >



From owner-mpls@UU.NET  Wed Aug 22 15:48:57 2001
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 PAA22220
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 15:48:56 -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 QQldfj12156;
	Wed, 22 Aug 2001 19:50:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfj04308
	for mpls-outgoing; Wed, 22 Aug 2001 19:49: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 QQldfj04300
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 19:49:39 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 QQldfj10410
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:49:37 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQldfj14025
	for <mpls@UU.NET>; Wed, 22 Aug 2001 19:49:35 GMT
Received: from vkapil (vkapil.netbrahma.com [172.16.72.84]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RMXY1ZBX; Thu, 23 Aug 2001 01:16:37 +0530
Date: Thu, 23 Aug 2001 01:26:37 +0530
From: Kapil Vuthoo <kapilvuthoo@netbrahma.com>
To: "Igor Achkinazi" <achkinazi@hotmail.com>
Cc: mpls@UU.NET
Subject: Re: LLC/SNAP encapsulation over ATM interface for control connection
Message-Id: <20010823012637.5cf768d5.kapilvuthoo@netbrahma.com>
In-Reply-To: <F62O5SjMKtWNymWzAKb0000eaf1@hotmail.com>
References: <F62O5SjMKtWNymWzAKb0000eaf1@hotmail.com>
X-Mailer: Sylpheed version 0.4.66 (GTK+ 1.2.6; i686-pc-linux-gnu)
Organization: NBT
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit




hi , 

to carry multiple protocols on an atm connection one has to use either LLC/SNAP 
encapsulation or VC multiplexing. It is specified in sec 7 RFC 3035 that all labeled packets MUST use VC multiplexing, ragardless of the encoding technique u r using(SVC, SVP or SVP multipoint encoding).
Further, the non -MPLS connection which is being talked about in RFC3035 sec7,
is the connection which must be there for ldp peers to communicate. This connection uses LLC/SNAP encap. & this connection may be used for other unlabeled packets also.
PHP is not possible in ATM as the label has to go in the vpi/vci field.  
ihope i am clear
  \kapil




On Wed, 22 Aug 2001 15:27:03 
"Igor Achkinazi" <achkinazi@hotmail.com> wrote:

> Hi,
> 
> Could somebody, please, clarify LLC/SNAP encapsulation issue for non-MPLS 
> connection between peers connected via ATM interface? (Rfc3035, MPLS over 
> ATM, section "7. Use of VPI/VCIs")
> Such connection must use LLC/SNAP encapsulation. Is this connection used for 
> unlabeled traffic only? Can this connection carry MPLS labeled packets in 
> case PHP and original packet has more than one label on stack? Can LSR send 
> labeled packet over this control connection without PHP in case two peers 
> are BGP speakers with VPN capability (two labels on label stack – bottom 
> label is BGP/VPN label, possibly missing top label is for tunnel between BGP 
> speakers).
> 
> Thank you,
> Igor
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


From owner-mpls@UU.NET  Wed Aug 22 16:00:58 2001
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 QAA22527
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 16:00:58 -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 QQldfk01647;
	Wed, 22 Aug 2001 20:02:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfk08769
	for mpls-outgoing; Wed, 22 Aug 2001 20:01: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 QQldfk08602
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 20:01:36 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 QQldfk15207
	for <mpls@uu.net>; Wed, 22 Aug 2001 20:01:22 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldfk22032
	for <mpls@uu.net>; Wed, 22 Aug 2001 20:01:21 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08549 for mpls@uu.net; Wed, 22 Aug 2001 16:01:20 -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 QQldfk07918
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 20:00:57 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 QQldfk08866
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:00:38 GMT
Received: from che-cse-104.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQldfk27361
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:00:38 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f7MK0ZL10373; Wed, 22 Aug 2001 16:00:35 -0400 (EDT)
Date: Wed, 22 Aug 2001 16:00:35 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Feihong Chen <fchen6@lucent.com>
Cc: dkatz@juniper.net, kireeti@juniper.net, mpls@UU.NET
Subject: Re: question about the traffic engineering extensions to OSPF
Message-ID: <20010822160034.A9703@che-cse-104.cisco.com>
References: <BAC9CCF04FEED311BD1D00062950ABB10184A10B@bandito.inse.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <BAC9CCF04FEED311BD1D00062950ABB10184A10B@bandito.inse.lucent.com>; from fchen6@lucent.com on Wed, Aug 22, 2001 at 12:12:41PM -0400
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

Not having this info makes online path calculation of an ERO more
difficult, but an offline tool can certainly calculate paths and give
them to a LSR, which just dumbly signals what it's told.




eric

On Wed, Aug 22, 2001 at 12:12:41PM -0400, Feihong Chen wrote:
> Hi, 
> 
> I just realized that the new version of the "Traffic Engineering Extensions
> to OSPF (draft-katz-yeung-ospf-traffic-05.txt)" made some changes on the
> Sec2.4.2 (Link TLV). Unlike the previous version of the draft, this version
> proposed that "The Link Type and Link ID sub-TLVs are mandatory, i.e., must
> appear exactly once. All other sub-TLVs defined here may occur at most
> once." (Note, other sub-TLVs includes traffic engineering metric,
> local/remote interface ip address, bandwidth information, class/color).
> 
> The question that I have here is, if the LSA only advertise the Link Type
> and Link ID as mandatory, then I don't see the capability of OSPF being a
> "traffic engineering helper" because the Traffic Engineering Database build
> from these two information ( which is the worst case ) simply is not able to
> calculate the ERO (i.e. the list of ip addresses), nor the bandwidth for an
> attempted LSP. 
> 
> In another word, if the proposed extensions to OSPF is mainly for traffic
> engineering, shouldn't some or all of  "other sub-TLVs" (e.g. bandwidth, ip
> address, color) be necessarily advertised besides the Link Type and Link ID?
> Otherwise, it will end up the traditional OSPF not for TE purpose? 
> 
> Maybe I miss something here, looking forward to a clarify to better
> understand the purpose of this updated changes.
> 
> Thanks a lot,
> Feihong Chen
> 
>  



From owner-mpls@UU.NET  Wed Aug 22 16:28:26 2001
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 QAA23161
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 16:28:26 -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 QQldfl04162;
	Wed, 22 Aug 2001 20:29:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfl26912
	for mpls-outgoing; Wed, 22 Aug 2001 20:29:10 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 QQldfl26905
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 20:29:05 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 QQldfl02398
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:26:18 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQldfl28978
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:26:18 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id <39P7FJYQ>; Wed, 22 Aug 2001 15:25:09 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FED90@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" <mpour@celoxnetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Path protection
Date: Wed, 22 Aug 2001 15:25:03 -0500
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,
Is anybody implementing the extensions to CR-LDP and RSVP-TE for path
protection?
If not how is fast failure notification implemented?
Thanks
Mort 


From owner-mpls@UU.NET  Wed Aug 22 17:38:50 2001
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 RAA24575
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 17:38: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 QQldfq14455;
	Wed, 22 Aug 2001 21:39:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfq22241
	for mpls-outgoing; Wed, 22 Aug 2001 21:39:40 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 QQldfq22234
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 21:39: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 QQldfq20979
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:38:36 GMT
Received: from web11207.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web11207.mail.yahoo.com [216.136.131.189])
	id QQldfq12487
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:38:36 GMT
Message-ID: <20010822213836.31772.qmail@web11207.mail.yahoo.com>
Received: from [12.144.37.227] by web11207.mail.yahoo.com; Wed, 22 Aug 2001 14:38:36 PDT
Date: Wed, 22 Aug 2001 14:38:36 -0700 (PDT)
From: Anil Yelundur <ayelund@yahoo.com>
Subject: Re: Path protection
To: "Pour, Mort" <mpour@celoxnetworks.com>, "'mpls@UU.NET'" <mpls@UU.NET>
In-Reply-To: <6F2719D5300C624BBC5F69424EC0C2060FED90@celox-stl-ems2.celoxnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Mort,
   They may also be notified by proprietary messages
like failure indicators. It does not always have to be
via extensions to CR-LDP / RSVP-TE since these
indications my also take the path through backward LSP
i.e. data channel towards the source (if possible).

Regards,
Anil Yelundur

--- "Pour, Mort" <mpour@celoxnetworks.com> wrote:
> Hi,
> Is anybody implementing the extensions to CR-LDP and
> RSVP-TE for path
> protection?
> If not how is fast failure notification implemented?
> Thanks
> Mort 


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Wed Aug 22 17:45:22 2001
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 RAB24726
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 17:45:22 -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 QQldfr23815;
	Wed, 22 Aug 2001 21:46:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfr23108
	for mpls-outgoing; Wed, 22 Aug 2001 21:46:10 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 QQldfr23078
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 21:46:05 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 QQldfr23487
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:45:45 GMT
Received: from web14302.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14302.mail.yahoo.com [216.136.173.78])
	id QQldfr03419
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:45:45 GMT
Message-ID: <20010822214545.51688.qmail@web14302.mail.yahoo.com>
Received: from [63.77.213.2] by web14302.mail.yahoo.com; Wed, 22 Aug 2001 14:45:45 PDT
Date: Wed, 22 Aug 2001 14:45:45 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: e-lsp & l - lsp
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
    Can anybody explain what is e-lsp ,l-lsp and
difference between them.


Thanks,
Srini


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Wed Aug 22 17:55:43 2001
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 RAA24857
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 17:55:43 -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 QQldfr16528;
	Wed, 22 Aug 2001 21:56:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfr23740
	for mpls-outgoing; Wed, 22 Aug 2001 21:56:26 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 QQldfr23735
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 21:56:22 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 QQldfr29653
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:55:28 GMT
Received: from basmail.basystems.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: basmail.basystems.com [209.211.220.7])
	id QQldfr14661
	for <mpls@UU.NET>; Wed, 22 Aug 2001 21:55:28 GMT
Received: from B10.basystems.com.adc.com ([146.71.195.216])
          by basmail.basystems.com (Netscape Messaging Server 3.62)
           with ESMTP id 328; Wed, 22 Aug 2001 17:58:30 -0400
From: Igor Lasic <igor_lasic@adc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15236.10958.665450.787827@B10.basystems.com>
Date: Wed, 22 Aug 2001 17:57:34 -0400
To: "Cheenu Srinivasan" <cheenu@alphion.com>
Cc: <mpls@UU.NET>, "Thomas D. Nadeau \(E-mail\)" <tnadeau@cisco.com>,
        "Arun Viswanathan \(E-mail\)" <arun@force10networks.com>,
        "George Swallow" <swallow@cisco.com>,
        "Vijay Srinivasan" <vijay@cosinecom.com>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
In-Reply-To: <176689DD1922D511ABE10001022E4DF20AB110@OPTONT>
References: <200108221101.HAA29417@ietf.org>
	<176689DD1922D511ABE10001022E4DF20AB110@OPTONT>
X-Mailer: VM 6.92 under Emacs 20.7.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


       I have some fundamental question/issues with the MIB as it is
  defined today.  

  In networking Access Lists are a general and well understood
  concept. Access lists give one ability to collect matching information
  and then "bind" it to a entity.

  For example:

  acl 1
      10 ip dest address 1.1.0.0 255.255.0.0
      20 ip src address 2.1.0.0 255.255.0.0
      30 allow all

  Where 10, 20 and 30 are priorities for matching criteria. 

  Then one just binds 1 (the acl index) to entity (in this case it could
  be an outsegment entry.) Using the mplsFTNMapTable (I don't think prev
  and curr would be neccessary.)

  Secondly, in the mplsFTNEntry ranges used for matching ip addresses
  are very uncommon way of matching ip routes. In general people use ip
  address/prefix concept.

  I had to make this comments just for my own sake.

  Thanks,

  Igor
      
      

Cheenu Srinivasan writes:
 > Folks,
 > 
 > Version 03 of the FTN MIB I-D is now available on the IETF
 > website (see below). We (the authors) believe its ready
 > for last call at this point. Please email your comments
 > to the list. Thanks.
 > 
 > Cheenu
 > 
 > > -----Original Message-----
 > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
 > > Sent: Wednesday, August 22, 2001 7:02 AM
 > > To: IETF-Announce
 > > Cc: mpls@UU.NET
 > > Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
 > > 
 > > 
 > > 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) 
 > > FEC-To-NHLFE 
 > >                           (FTN) Management Information Base
 > > 	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
 > > 	Filename	: draft-ietf-mpls-ftn-mib-03.txt
 > > 	Pages		: 25
 > > 	Date		: 21-Aug-01
 > > 	
 > > This memo defines an experimental portion of the Management
 > > Information Base  (MIB) for use with network management protocols in
 > > the Internet community.  In particular, it describes managed objects
 > > for defining FEC-to-NHLFE mapping and corresponding actions for use
 > > with Multiprotocol Label Switching (MPLS).
 > > 
 > > A URL for this Internet-Draft is:
 > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt
 > > 
 > > Internet-Drafts are also available by anonymous FTP. Login 
 > > with the username
 > > "anonymous" and a password of your e-mail address. After logging in,
 > > type "cd internet-drafts" and then
 > > 	"get draft-ietf-mpls-ftn-mib-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-ftn-mib-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  Wed Aug 22 18:06:18 2001
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 SAA25024
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 18:06:17 -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 QQldfs22677;
	Wed, 22 Aug 2001 22:07:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfs12404
	for mpls-outgoing; Wed, 22 Aug 2001 22:07: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 QQldfs12381
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:06:57 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 QQldfs19583
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:06:54 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldfs27411
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:06:55 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GYJ7>; Wed, 22 Aug 2001 18:02:28 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A445@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'Srinivas T M'" <srini_tm@yahoo.com>, mpls@UU.NET
Subject: RE: e-lsp & l - lsp
Date: Wed, 22 Aug 2001 18:02:27 -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

Hi srinivas ,
These are two techiniques to implement packet treatment in  MPLS cloud ,
with diffserv inferred information.
The diffserv information from the packet can be encapsulated into label/exp
field of  "MPLS labelled packet "(this will be happened between
diffservcloud and mpls cloud ),
so that we will be making sure that diffserv information will be used in
MPLS cloud to treat the packets according to that information.
Cisco is implementing this concept with the name : MPLS  DIFFSERV AWARE TE
 e-lsp intended for carrying single OA for single LSP.
l-lsp is intended for carrying multiple OA s for LSP.


 OA  :      Ordered Aggregate. The set of Behavior Aggregates which
               share an ordering constraint.

Any comments are welcome.


Reference draft : draft-ietf-mpls-diff-ext-09.txt  


Regards
Ravikumar Kota
978  263 0094 (extn  8157 )(work)   
978 869 3314(cell)
            



-----Original Message-----
From: Srinivas T M [mailto:srini_tm@yahoo.com]
Sent: Wednesday, August 22, 2001 5:46 PM
To: mpls@UU.NET
Subject: e-lsp & l - lsp


Hi,
    Can anybody explain what is e-lsp ,l-lsp and
difference between them.


Thanks,
Srini


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Wed Aug 22 18:09:56 2001
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 SAA25108
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 18:09:56 -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 QQldfs28289;
	Wed, 22 Aug 2001 22:11:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfs13238
	for mpls-outgoing; Wed, 22 Aug 2001 22:10:33 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 QQldfs13218
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:10:29 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 QQldfs17066
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:09:48 GMT
Received: from nwds0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQldfs04718
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:09:48 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Wed, 22 Aug 2001 18:04:50 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Igor Lasic'" <igor_lasic@adc.com>
Cc: <mpls@UU.NET>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Date: Wed, 22 Aug 2001 18:21:56 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB116@OPTONT>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <15236.10958.665450.787827@B10.basystems.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Igor Lasic wrote:
>
>   In networking Access Lists are a general and well understood
>   concept. Access lists give one ability to collect matching 
> information
>   and then "bind" it to a entity.
> 
>   For example:
> 
>   acl 1
>       10 ip dest address 1.1.0.0 255.255.0.0
>       20 ip src address 2.1.0.0 255.255.0.0
>       30 allow all
> 
>   Where 10, 20 and 30 are priorities for matching criteria. 
> 
>   Then one just binds 1 (the acl index) to entity (in this 
> case it could
>   be an outsegment entry.) Using the mplsFTNMapTable (I don't 
> think prev
>   and curr would be neccessary.)

We introduced the linked-list structure in this MIB specifically
to overcome a problem with what you describe - everytime an
entry needs to be inserted into an existing list the ids/"priorities"
of existing items may need to be changed. Either that or one
has to think ahead and leave big enough "holes" in the ids to
allow insertion at a later point (which over time still does not
avoid the above issue).

Implementation wise, one could
continue to internally assign IDs/priorities/whatever and renumber
behind the scenes and save the administrator this pain.

>   Secondly, in the mplsFTNEntry ranges used for matching ip addresses
>   are very uncommon way of matching ip routes. In general 
> people use ip
>   address/prefix concept.

Ranges are a superset of prefixes; implementors who choose 
to restrict their implementation to prefixes only can still do so
by restricting the type of ranges thay accept.

Cheenu



From owner-mpls@UU.NET  Wed Aug 22 18:44:30 2001
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 SAA25687
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 18:44:30 -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 QQldfv15386;
	Wed, 22 Aug 2001 22:45:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfu16018
	for mpls-outgoing; Wed, 22 Aug 2001 22:44:57 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 QQldfu15995
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:44:44 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 QQldfu05311
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:44:43 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldfu08786
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:44:44 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GYK7>; Wed, 22 Aug 2001 18:40:23 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A446@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'Mark Seery'" <mark@bravara.com>,
        "Kota, Ravikumar"
	 <RKota@cratosnetworks.com>,
        "'Srinivas T M'" <srini_tm@yahoo.com>, mpls@UU.NET
Subject: RE: e-lsp & l - lsp
Date: Wed, 22 Aug 2001 18:40:22 -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


Hi Mark

Thanks for ur correction.
That is mistake in hurry typing.
Thanks alot
Regards
Ravikumar Kota
978  263 0094 (extn  8157 )(work)
978 869 3314(cell)
 
-----Original Message-----
From: Mark Seery [mailto:mark@bravara.com]
Sent: Wednesday, August 22, 2001 6:33 PM
To: Kota, Ravikumar; 'Srinivas T M'; mpls@UU.NET
Subject: RE: e-lsp & l - lsp


>>  e-lsp intended for carrying single OA for single LSP. l-lsp is intended
for carrying multiple OA s for LSP.

I believe it is the other way.

From the below mentioned draft:

"1.2 EXP-Inferred-PSC LSPs (E-LSP)

   A single LSP can be used to support one or more OAs. Such LSPs can
   support up to eight BAs of a given FEC, regardless of how many OAs
   these BAs span. With such LSPs, the EXP field of the MPLS Shim
   Header is used by the LSR to determine the PHB to be applied to the
   packet. This includes both the PSC and the drop preference......."

"1.3 Label-Only-Inferred-PSC LSPs (L-LSP)

   A separate LSP can be established for a single <FEC, OA> pair.
   With such LSPs, the PSC is explicitly signaled at label
   establishment time so that, after label establishment, the LSR can
   infer exclusively from the label value the PSC to be applied to a
   labeled packet. When the Shim Header is used, the Drop Precedence to
   be applied by the LSR to the labeled packet, is conveyed inside the
   labeled packet MPLS Shim Header using the EXP field. When the Shim
   Header is not used (e.g. MPLS Over ATM), the Drop Precedence to be
   applied by the LSR to the labeled packet is conveyed inside the link
   layer header encapsulation using link layer specific drop precedence
   fields (e.g. ATM CLP)....."

Additional comments:

A number of existing layer 2 technologies (e.g. ATM) can only support L-LSP
because of their inability to carry the equivalent of a full EXP field (drop
precedence can be indicated).

Some people have argued that in the context of diffserv/traffic engineering
support only L-LSPs would be used - I leave this argument as an exercise for
the reader.

E-LSPs represent an approach most similar to diffserv TOS treatment.

-mark

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kota,
Ravikumar
Sent: Wednesday, August 22, 2001 3:02 PM
To: 'Srinivas T M'; mpls@UU.NET
Subject: RE: e-lsp & l - lsp


Hi srinivas ,
These are two techiniques to implement packet treatment in  MPLS cloud ,
with diffserv inferred information.
The diffserv information from the packet can be encapsulated into label/exp
field of  "MPLS labelled packet "(this will be happened between
diffservcloud and mpls cloud ),
so that we will be making sure that diffserv information will be used in
MPLS cloud to treat the packets according to that information.
Cisco is implementing this concept with the name : MPLS  DIFFSERV AWARE TE
 e-lsp intended for carrying single OA for single LSP.
l-lsp is intended for carrying multiple OA s for LSP.


 OA  :      Ordered Aggregate. The set of Behavior Aggregates which
               share an ordering constraint.

Any comments are welcome.


Reference draft : draft-ietf-mpls-diff-ext-09.txt


Regards
Ravikumar Kota
978  263 0094 (extn  8157 )(work)
978 869 3314(cell)




-----Original Message-----
From: Srinivas T M [mailto:srini_tm@yahoo.com]
Sent: Wednesday, August 22, 2001 5:46 PM
To: mpls@UU.NET
Subject: e-lsp & l - lsp


Hi,
    Can anybody explain what is e-lsp ,l-lsp and
difference between them.


Thanks,
Srini


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Wed Aug 22 18:48:03 2001
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 SAA25714
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 18:47:59 -0400 (EDT)
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 QQldfv13575;
	Wed, 22 Aug 2001 22:49:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfv16499
	for mpls-outgoing; Wed, 22 Aug 2001 22:48:50 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 QQldfv16487
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:48:47 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 QQldfv15374
	for <mpls@uu.net>; Wed, 22 Aug 2001 22:48:27 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldfv26804
	for <mpls@uu.net>; Wed, 22 Aug 2001 22:48:27 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA21579 for mpls@uu.net; Wed, 22 Aug 2001 18:48: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 QQldfv16372
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:48: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 QQldfv21017
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:46:57 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQldfv11202
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:46:57 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7MMktQ26011;
	Wed, 22 Aug 2001 15:46:55 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-207.cisco.com [144.254.46.208])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AAH83865;
	Wed, 22 Aug 2001 15:46:52 -0700 (PDT)
Message-ID: <3B8435D5.51D32925@cisco.com>
Date: Wed, 22 Aug 2001 15:44:38 -0700
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: Ramyanshu Datta <romidatta@yahoo.com>
CC: mpls@UU.NET
Subject: Re: Diff. bet. FIB and RIB
References: <20010822160025.74612.qmail@web13302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Pls excuse my question but how is this related to MPLS protocol
architecture ?

R.

> Ramyanshu Datta wrote:
> 
> Hi,
> 
>      I have got a doubt. What is the difference
> between Forward Information Base (FIB)and Routing
> Information Base (RIB).
> 
>       Please let me know.
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Wed Aug 22 20:40:17 2001
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 UAA27125
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 20:40:16 -0400 (EDT)
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 QQldfn04482;
	Wed, 22 Aug 2001 20:55:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldfn29691
	for mpls-outgoing; Wed, 22 Aug 2001 20:55:09 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 QQldfn29665
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 20:55: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 QQldfn01863
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:54:45 GMT
Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQldfn03556
	for <mpls@UU.NET>; Wed, 22 Aug 2001 20:54:45 GMT
Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7MKshA27293;
	Wed, 22 Aug 2001 16:54:43 -0400 (EDT)
Received: from bandito.inse.lucent.com by horh1.emsr.lucent.com (8.9.3+Sun/EMS-1.5 Solaris/emsr)
	id QAA11608 for ; Wed, 22 Aug 2001 16:54:41 -0400 (EDT)
Received: by bandito.inse.lucent.com with Internet Mail Service (5.5.2650.21)
	id <Q62MDM8F>; Wed, 22 Aug 2001 16:54:42 -0400
Message-ID: <BAC9CCF04FEED311BD1D00062950ABB10184A1EF@bandito.inse.lucent.com>
From: Feihong Chen <fchen6@lucent.com>
To: Eric Osborne <eosborne@cisco.com>, Feihong Chen <fchen6@lucent.com>
Cc: dkatz@juniper.net, kireeti@juniper.net, mpls@UU.NET
Subject: RE: question about the traffic engineering extensions to OSPF
Date: Wed, 22 Aug 2001 16:54:41 -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


Still a little bit confuse here. What's the difference if ERO 
is calculated online or offline in terms of the information
database that CSPF refer to? 

If all of the sub-TLVs are mandatory, TED has enough information 
for CSPF to calculate a TE path and return a ERO list. Also, 
TED can be implemented independently from the traditional LSDB 
that OSPF currently uses. 

But, if only Link Type and Link ID are mandatory, unless CSPF is 
designed to be able to access TED as well as traditional LSDB, I am
wondering how CSPF can return a ERO (if local/remote ip addresses 
are not advertised) even for a simple path request to an egress LSR 
without any color or bandwidth constrains. 

Actually, it's back to my original question, shouldn't we put some or
all of the link sub-TLVs as mandatory since the extension to OSPF is for
traffic engineering. 

Thanks,
Feihong 



-----Original Message-----
From: Eric Osborne [mailto:eosborne@cisco.com]
Sent: Wednesday, August 22, 2001 4:01 PM
To: Feihong Chen
Cc: dkatz@juniper.net; kireeti@juniper.net; mpls@UU.NET
Subject: Re: question about the traffic engineering extensions to OSPF


Not having this info makes online path calculation of an ERO more
difficult, but an offline tool can certainly calculate paths and give
them to a LSR, which just dumbly signals what it's told.




eric

On Wed, Aug 22, 2001 at 12:12:41PM -0400, Feihong Chen wrote:
> Hi, 
> 
> I just realized that the new version of the "Traffic Engineering
Extensions
> to OSPF (draft-katz-yeung-ospf-traffic-05.txt)" made some changes on the
> Sec2.4.2 (Link TLV). Unlike the previous version of the draft, this
version
> proposed that "The Link Type and Link ID sub-TLVs are mandatory, i.e.,
must
> appear exactly once. All other sub-TLVs defined here may occur at most
> once." (Note, other sub-TLVs includes traffic engineering metric,
> local/remote interface ip address, bandwidth information, class/color).
> 
> The question that I have here is, if the LSA only advertise the Link Type
> and Link ID as mandatory, then I don't see the capability of OSPF being a
> "traffic engineering helper" because the Traffic Engineering Database
build
> from these two information ( which is the worst case ) simply is not able
to
> calculate the ERO (i.e. the list of ip addresses), nor the bandwidth for
an
> attempted LSP. 
> 
> In another word, if the proposed extensions to OSPF is mainly for traffic
> engineering, shouldn't some or all of  "other sub-TLVs" (e.g. bandwidth,
ip
> address, color) be necessarily advertised besides the Link Type and Link
ID?
> Otherwise, it will end up the traditional OSPF not for TE purpose? 
> 
> Maybe I miss something here, looking forward to a clarify to better
> understand the purpose of this updated changes.
> 
> Thanks a lot,
> Feihong Chen
> 
>  


From owner-mpls@UU.NET  Wed Aug 22 21:05:37 2001
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 VAA27356
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 21:05: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 QQldge07160;
	Thu, 23 Aug 2001 01:06:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldge20591
	for mpls-outgoing; Thu, 23 Aug 2001 01:06: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 QQldge20576
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 01:06:20 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 QQldge22289
	for <mpls@UU.NET>; Thu, 23 Aug 2001 01:06:15 GMT
Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [210.32.131.2])
	id QQldge27223
	for <mpls@UU.NET>; Thu, 23 Aug 2001 01:06:11 GMT
Received: (qmail 881 invoked from network); 23 Aug 2001 01:07:59 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 23 Aug 2001 01:07:59 -0000
Message-ID: <3B8456FF.6D9F8485@cad.zju.edu.cn>
Date: Thu, 23 Aug 2001 09:06:07 +0800
From: shen jing <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: zhoukui@gaohong.com.cn
CC: "mpls@uu.net" <mpls@UU.NET>
Subject: Re: has ietf completed Specifying MPLS-specific recovery mechanisms ?
References: <200108221615312.SM00952@gaohong.mail>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

There  has been proposals for fast reroute and path protections for LSP.

Please refer to :


draft-ietf-mpls-recovery-frmwrk-03.txt
draft-kini-restoration-shared-backup-00.txt
draft-chang-mpls-rsvpte-path-protection-ext-01.txt

Jing Shen



>         hi, does anyone know whether ietf has completed Specifying MPLS-specific recovery mechanisms which allow one label-switched path to be used as backup for a set of other label-switched paths, including cases which permit local repair?
>         thanks a lot!
>
>             zhoukui@gaohong.com.cn



From owner-mpls@UU.NET  Wed Aug 22 22:07:37 2001
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 WAA29029
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 22:07:37 -0400 (EDT)
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 QQldgi12742;
	Thu, 23 Aug 2001 02:08:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldgi13608
	for mpls-outgoing; Thu, 23 Aug 2001 02:08: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 QQldgi13593
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 02:08: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 QQldgi26288
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:07:42 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldgi27821
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:07:42 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA02186 for mpls@uu.net; Wed, 22 Aug 2001 22:07:40 -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 QQldgi13139
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 02:06:51 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 QQldgi18957
	for <mpls@UU.NET>; Thu, 23 Aug 2001 02:06:49 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldgi17302
	for <mpls@UU.NET>; Thu, 23 Aug 2001 02:06:49 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA27181; Wed, 22 Aug 2001 22:06:41 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AGQ01436;
	Wed, 22 Aug 2001 22:06:38 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010822220417.038ea350@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 22 Aug 2001 22:08:03 -0700
To: Igor Lasic <igor_lasic@adc.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Cc: "Cheenu Srinivasan" <cheenu@alphion.com>, <mpls@UU.NET>,
        "Arun Viswanathan \(E-mail\)" <arun@force10networks.com>,
        "George Swallow" <swallow@cisco.com>,
        "Vijay Srinivasan" <vijay@cosinecom.com>
In-Reply-To: <15236.10958.665450.787827@B10.basystems.com>
References: <176689DD1922D511ABE10001022E4DF20AB110@OPTONT>
 <200108221101.HAA29417@ietf.org>
 <176689DD1922D511ABE10001022E4DF20AB110@OPTONT>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:57 PM 8/22/2001 -0400, Igor Lasic wrote:

>        I have some fundamental question/issues with the MIB as it is
>   defined today.
>
>   In networking Access Lists are a general and well understood
>   concept. Access lists give one ability to collect matching information
>   and then "bind" it to a entity.
>
>   For example:
>
>   acl 1
>       10 ip dest address 1.1.0.0 255.255.0.0
>       20 ip src address 2.1.0.0 255.255.0.0
>       30 allow all
>
>   Where 10, 20 and 30 are priorities for matching criteria.
>
>   Then one just binds 1 (the acl index) to entity (in this case it could
>   be an outsegment entry.) Using the mplsFTNMapTable (I don't think prev
>   and curr would be neccessary.)

         I don't really understand what your question is here. Are you
asking whether or not it is possible/not possible to bind ACLs
to a particular FTN entry, or are you asking weather or not
it is possible to order FTN entries? In either case, it is possible to
do this with the MIB as it is currently written.

>   Secondly, in the mplsFTNEntry ranges used for matching ip addresses
>   are very uncommon way of matching ip routes. In general people use ip
>   address/prefix concept.

         The MIB allows matching of ip address prefixes, or ranges
of prefixes, or other attributes such as port number or TOS bits.
It is general enough to allow the matching of any (or all) of these
things in any order (of preference) that you would like.

         --Tom




>   I had to make this comments just for my own sake.
>
>   Thanks,
>
>   Igor
>
>
>
>Cheenu Srinivasan writes:
>  > Folks,
>  >
>  > Version 03 of the FTN MIB I-D is now available on the IETF
>  > website (see below). We (the authors) believe its ready
>  > for last call at this point. Please email your comments
>  > to the list. Thanks.
>  >
>  > Cheenu
>  >
>  > > -----Original Message-----
>  > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>  > > Sent: Wednesday, August 22, 2001 7:02 AM
>  > > To: IETF-Announce
>  > > Cc: mpls@UU.NET
>  > > Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
>  > >
>  > >
>  > > 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)
>  > > FEC-To-NHLFE
>  > >                           (FTN) Management Information Base
>  > >    Author(s)       : T. Nadeau, C. Srinivasan, A. Viswanathan
>  > >    Filename        : draft-ietf-mpls-ftn-mib-03.txt
>  > >    Pages           : 25
>  > >    Date            : 21-Aug-01
>  > >
>  > > This memo defines an experimental portion of the Management
>  > > Information Base  (MIB) for use with network management protocols in
>  > > the Internet community.  In particular, it describes managed objects
>  > > for defining FEC-to-NHLFE mapping and corresponding actions for use
>  > > with Multiprotocol Label Switching (MPLS).
>  > >
>  > > A URL for this Internet-Draft is:
>  > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt
>  > >
>  > > Internet-Drafts are also available by anonymous FTP. Login
>  > > with the username
>  > > "anonymous" and a password of your e-mail address. After logging in,
>  > > type "cd internet-drafts" and then
>  > >    "get draft-ietf-mpls-ftn-mib-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-ftn-mib-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  Wed Aug 22 22:18:37 2001
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 WAA29179
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 22:18:37 -0400 (EDT)
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 QQldgj24196;
	Thu, 23 Aug 2001 02:19:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldgj14767
	for mpls-outgoing; Thu, 23 Aug 2001 02:19:23 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 QQldgj14760
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 02:19:13 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 QQldgj26683
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:17:49 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldgj11143
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:17:49 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA02845 for mpls@uu.net; Wed, 22 Aug 2001 22:17:47 -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 QQldgj14676
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 02:16:57 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 QQldgi16756
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:14:17 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldgi18703
	for <mpls@uu.net>; Thu, 23 Aug 2001 02:14:17 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA27690; Wed, 22 Aug 2001 22:14:17 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AGQ01479;
	Wed, 22 Aug 2001 22:14:15 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010822221528.019d9870@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 22 Aug 2001 22:15:40 -0700
To: Igor Lasic <igor_lasic@adc.com>, mpls@UU.NET
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 05:57 PM 8/22/2001 -0400, Igor Lasic wrote:

>        I have some fundamental question/issues with the MIB as it is
>   defined today.
>
>   In networking Access Lists are a general and well understood
>   concept. Access lists give one ability to collect matching information
>   and then "bind" it to a entity.
>
>   For example:
>
>   acl 1
>       10 ip dest address 1.1.0.0 255.255.0.0
>       20 ip src address 2.1.0.0 255.255.0.0
>       30 allow all
>
>   Where 10, 20 and 30 are priorities for matching criteria.
>
>   Then one just binds 1 (the acl index) to entity (in this case it could
>   be an outsegment entry.) Using the mplsFTNMapTable (I don't think prev
>   and curr would be neccessary.)

         I don't really understand what your question is here. Are you
asking whether or not it is possible/not possible to bind ACLs
to a particular FTN entry, or are you asking weather or not
it is possible to order FTN entries? In either case, it is possible to
do this with the MIB as it is currently written.

>   Secondly, in the mplsFTNEntry ranges used for matching ip addresses
>   are very uncommon way of matching ip routes. In general people use ip
>   address/prefix concept.

         The MIB allows matching of ip address prefixes, or ranges
of prefixes, or other attributes such as port number or TOS bits.
It is general enough to allow the matching of any (or all) of these
things in any order (of preference) that you would like.

         --Tom




>   I had to make this comments just for my own sake.
>
>   Thanks,
>
>   Igor
>
>
>
>Cheenu Srinivasan writes:
>  > Folks,
>  >
>  > Version 03 of the FTN MIB I-D is now available on the IETF
>  > website (see below). We (the authors) believe its ready
>  > for last call at this point. Please email your comments
>  > to the list. Thanks.
>  >
>  > Cheenu
>  >
>  > > -----Original Message-----
>  > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>  > > Sent: Wednesday, August 22, 2001 7:02 AM
>  > > To: IETF-Announce
>  > > Cc: mpls@UU.NET
>  > > Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
>  > >
>  > >
>  > > 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)
>  > > FEC-To-NHLFE
>  > >                           (FTN) Management Information Base
>  > >    Author(s)       : T. Nadeau, C. Srinivasan, A. Viswanathan
>  > >    Filename        : draft-ietf-mpls-ftn-mib-03.txt
>  > >    Pages           : 25
>  > >    Date            : 21-Aug-01
>  > >
>  > > This memo defines an experimental portion of the Management
>  > > Information Base  (MIB) for use with network management protocols in
>  > > the Internet community.  In particular, it describes managed objects
>  > > for defining FEC-to-NHLFE mapping and corresponding actions for use
>  > > with Multiprotocol Label Switching (MPLS).
>  > >
>  > > A URL for this Internet-Draft is:
>  > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt
>  > >
>  > > Internet-Drafts are also available by anonymous FTP. Login
>  > > with the username
>  > > "anonymous" and a password of your e-mail address. After logging in,
>  > > type "cd internet-drafts" and then
>  > >    "get draft-ietf-mpls-ftn-mib-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-ftn-mib-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  Wed Aug 22 23:24:17 2001
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 XAA01129
	for <mpls-archive@lists.ietf.org>; Wed, 22 Aug 2001 23:24:17 -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 QQldgn00595;
	Thu, 23 Aug 2001 03:25:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldgn08220
	for mpls-outgoing; Thu, 23 Aug 2001 03:25:03 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 QQldgn08207
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 03:24:57 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 QQldgn19659
	for <mpls@uu.net>; Thu, 23 Aug 2001 03:24:53 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldgn29728
	for <mpls@uu.net>; Thu, 23 Aug 2001 03:24:47 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA06148 for mpls@uu.net; Wed, 22 Aug 2001 23:24:46 -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 QQldgn08172
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 03:24:13 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 QQldgn27361
	for <mpls@UU.NET>; Thu, 23 Aug 2001 03:24:11 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 QQldgn28975
	for <mpls@UU.NET>; Thu, 23 Aug 2001 03:24:12 GMT
Received: from ASIMHA-HP.cisco.com (rtp-vpn1-66.cisco.com [10.82.224.66])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA18064;
	Wed, 22 Aug 2001 23:23:35 -0400 (EDT)
Date: Wed, 22 Aug 2001 23:31:56 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: shen jing <jshen@cad.zju.edu.cn>
cc: <zhoukui@gaohong.com.cn>, "mpls@uu.net" <mpls@UU.NET>
Subject: Re: has ietf completed Specifying MPLS-specific recovery mechanisms
 ?
In-Reply-To: <3B8456FF.6D9F8485@cad.zju.edu.cn>
Message-ID: <Pine.WNT.4.33.0108222328260.1056-100000@ASIMHA-HP.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, 23 Aug 2001, shen jing wrote:

> There  has been proposals for fast reroute and path protections for LSP.
>
> Please refer to :
>
>
> draft-ietf-mpls-recovery-frmwrk-03.txt
> draft-kini-restoration-shared-backup-00.txt
> draft-chang-mpls-rsvpte-path-protection-ext-01.txt

also look at the draft-swallow-rsvp-bypass-label-01.txt

-ajay
>
> Jing Shen
>
>
>
> > hi, does anyone know whether ietf has completed Specifying MPLS-specific
> recovery mechanisms which allow one label-switched path to be used as
> backup for a set of other label-switched paths, including cases which
> permit local repair? > thanks a lot! > > zhoukui@gaohong.com.cn
>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Thu Aug 23 02:10:18 2001
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 CAA18031
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 02:10:18 -0400 (EDT)
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 QQldgy16149;
	Thu, 23 Aug 2001 06:11:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldgy14557
	for mpls-outgoing; Thu, 23 Aug 2001 06:11:03 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 QQldgy14518
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 06:10:59 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 QQldgy15427
	for <mpls@uu.net>; Thu, 23 Aug 2001 06:10:28 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldgy15209
	for <mpls@uu.net>; Thu, 23 Aug 2001 06:10:28 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA14165 for mpls@uu.net; Thu, 23 Aug 2001 02:10:27 -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 QQldgy14452
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 06:10:08 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 QQldgy06626
	for <mpls@uu.net>; Thu, 23 Aug 2001 06:09:52 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f93.law10.hotmail.com [64.4.15.93])
	id QQldgy14520
	for <mpls@uu.net>; Thu, 23 Aug 2001 06:09:53 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 22 Aug 2001 23:09:51 -0700
Received: from 63.27.22.192 by lw10fd.law10.hotmail.msn.com with HTTP;	Thu, 23 Aug 2001 06:09:51 GMT
X-Originating-IP: [63.27.22.192]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: mpls@UU.NET
Subject: RSVP Hello 
Date: Wed, 22 Aug 2001 23:09:51 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F93bgssmCix4DZVeHir0000f7e0@hotmail.com>
X-OriginalArrivalTime: 23 Aug 2001 06:09:51.0968 (UTC) FILETIME=[38B8D600:01C12B9A]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
         The RSVP-TE draft states that the RSVP Hellos should be transmitted 
when there is a RSVP state between the neighbors i.e. when there is 
Path/Resv state. In other words, if there is a RSVP session between two 
nodes then the RSVP hellos need to be exchanged. If the RSVP session is to 
be released (i.e. graceful termination), does this mean that RSVP hellos 
should not be exchanged between the RSVP neighbors as long as there is no 
RSVP session between them ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 23 03:07:16 2001
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 DAA19657
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 03:07:16 -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 QQldhc01217;
	Thu, 23 Aug 2001 07:08:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldhc06924
	for mpls-outgoing; Thu, 23 Aug 2001 07:08: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 QQldhc06915
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 07:07:52 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 QQldhc19275
	for <mpls@UU.NET>; Thu, 23 Aug 2001 07:07:12 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQldhc29557
	for <mpls@UU.NET>; Thu, 23 Aug 2001 07:07:12 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id DAA09310; Thu, 23 Aug 2001 03:07:35 -0400
Date: Thu, 23 Aug 2001 03:07:34 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Subject: LDP refreshes.
Message-ID: <Pine.SUN.3.96.1010823030336.8557A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
This is a preliminary doubt regarding LDP (RFC:3037). At one place
(Section 3, 2nd paragraph)it says that "distributed labels and state
information associated with LSPs need not to be refreshed periodically."
The doubt is,what exactly "distributed label information" means ? Is it
the available label range at an instance or something else ? Or it means,
the labels in use by one LSR ?

Regards,
Hemant



From owner-mpls@UU.NET  Thu Aug 23 08:30:32 2001
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 IAA22542
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 08:30:32 -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 QQldhy12255;
	Thu, 23 Aug 2001 12:31:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldhy01524
	for mpls-outgoing; Thu, 23 Aug 2001 12:31:05 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 QQldhy01499
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 12:30:56 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 QQldhx29855
	for <mpls@UU.NET>; Thu, 23 Aug 2001 12:28:33 GMT
Received: from ext1.ics.forth.gr by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2])
	id QQldhx05966
	for <mpls@UU.NET>; Thu, 23 Aug 2001 12:28:32 GMT
Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51])
	by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id PAA25676;
	Thu, 23 Aug 2001 15:28:20 +0300 (EET DST)
Received: from crete.csi.forth.gr (crete.ics.forth.gr [139.91.190.10]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id PAA10426; Thu, 23 Aug 2001 15:28:23 +0300 (EET DST)
Posted-Date: Thu, 23 Aug 2001 15:28:23 +0300 (EET DST)
Received: from localhost (tziou@localhost)
	by crete.csi.forth.gr (8.9.3/ICS-FORTH/V8.1-NULL) with ESMTP id PAA22699;
	Thu, 23 Aug 2001 15:17:50 +0300 (EET DST)
Organization:   
X-Authentication-Warning: crete.csi.forth.gr: tziou owned process doing -bs
Date: Thu, 23 Aug 2001 15:17:50 +0300 (EET DST)
From: Chrysostomos Tziouvaras <tziou@ics.forth.gr>
To: <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>
Subject: A question on optical path establishment wrt overlay model
In-Reply-To: <022A2DBC40A6D411967000D0B78892A61C4461@srnex01.sd.osicom.com>
Message-ID: <Pine.GSO.4.33.0108231512530.22694-100000@crete.csi.forth.gr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,
I would like to ask you the following question:
in the overlay model, if a client network that is attached to an optical
network asks for an optical path, how can it specify that this path must
be
exclusively used by it and no other client network that is attached to the
same edge device of the client network?

Regards
Tziouvaras Chrysostomos
ICS-FORTH Researcher





From owner-mpls@UU.NET  Thu Aug 23 09:26:17 2001
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 JAA23160
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 09:26:17 -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 QQldib02624;
	Thu, 23 Aug 2001 13:27:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldib25708
	for mpls-outgoing; Thu, 23 Aug 2001 13:26: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 QQldib25700
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 13:26:40 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 QQldib22468
	for <mpls@uu.net>; Thu, 23 Aug 2001 13:26:30 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQldib11865
	for <mpls@uu.net>; Thu, 23 Aug 2001 13:26:31 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Thu, 23 Aug 2001 09:26:30 -0400
Message-ID: <020d01c12bd7$384b5a70$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Ajay Simha" <asimha@cisco.com>, "shen jing" <jshen@cad.zju.edu.cn>
Cc: <zhoukui@gaohong.com.cn>, "mpls@uu.net" <mpls@UU.NET>
References: <Pine.WNT.4.33.0108222328260.1056-100000@ASIMHA-HP.cisco.com>
Subject: Re: has ietf completed Specifying MPLS-specific recovery mechanisms?
Date: Thu, 23 Aug 2001 09:26:30 -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: 23 Aug 2001 13:26:30.0667 (UTC) FILETIME=[385D0DB0:01C12BD7]
Sender: owner-mpls@UU.NET
Precedence: bulk

You may find draft-lang-ccamp-recovery-01.txt relevant if you're prepared to
encompass GMPLS.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Ajay Simha" <asimha@cisco.com>
To: "shen jing" <jshen@cad.zju.edu.cn>
Cc: <zhoukui@gaohong.com.cn>; "mpls@uu.net" <mpls@UU.NET>
Sent: Wednesday, August 22, 2001 11:31 PM
Subject: Re: has ietf completed Specifying MPLS-specific recovery mechanisms?


> On Thu, 23 Aug 2001, shen jing wrote:
>
> > There  has been proposals for fast reroute and path protections for LSP.
> >
> > Please refer to :
> >
> >
> > draft-ietf-mpls-recovery-frmwrk-03.txt
> > draft-kini-restoration-shared-backup-00.txt
> > draft-chang-mpls-rsvpte-path-protection-ext-01.txt
>
> also look at the draft-swallow-rsvp-bypass-label-01.txt
>
> -ajay
> >
> > Jing Shen
> >
> >
> >
> > > hi, does anyone know whether ietf has completed Specifying MPLS-specific
> > recovery mechanisms which allow one label-switched path to be used as
> > backup for a set of other label-switched paths, including cases which
> > permit local repair? > thanks a lot! > > zhoukui@gaohong.com.cn
> >
>
> --
> Ajay Simha
> MPLS Deployment Engineer
> IOS Technology Division
> (919) 392-3141
>
> "Study as if you were to live forever
>  Live as if you were to die tomorrow"
>
>  - Mahatma Gandhi
>




From owner-mpls@UU.NET  Thu Aug 23 09:30:50 2001
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 JAA23243
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 09:30: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 QQldic15459;
	Thu, 23 Aug 2001 13:31:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldic26288
	for mpls-outgoing; Thu, 23 Aug 2001 13:31:24 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 QQldic26228
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 13:31: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 QQldic01391
	for <mpls@UU.NET>; Thu, 23 Aug 2001 13:30:41 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQldic17135
	for <mpls@UU.NET>; Thu, 23 Aug 2001 13:30:41 GMT
Message-ID: <3B85057E.A87DB8F5@sandburst.com>
Date: Thu, 23 Aug 2001 09:30:38 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Hemant P. Kelkar" <hemant@cyberspace.org>
Cc: mpls-ops@mplsrc.com, mpls@UU.NET, Bob Thomas <rhthomas@cisco.com>
Subject: Re: LDP refreshes.
References: <Pine.SUN.3.96.1010823030336.8557A-100000@grex.cyberspace.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hemant,

    Nothing magical, mystical or even complicated.  Distributed label
information is just label information (label mappings) that has been
distributed (as in Label Distribution Protocol).

    Note that RFC 3037 is just LDP Applicability - for information on
LDP itself, you need to look at RFC 3036.

--
Eric Gray

You wrote:

> Hi,
> This is a preliminary doubt regarding LDP (RFC:3037). At one place
> (Section 3, 2nd paragraph)it says that "distributed labels and state
> information associated with LSPs need not to be refreshed periodically."
> The doubt is,what exactly "distributed label information" means ? Is it
> the available label range at an instance or something else ? Or it means,
> the labels in use by one LSR ?
>
> Regards,
> Hemant



From owner-mpls@UU.NET  Thu Aug 23 09:51:18 2001
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 JAA23488
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 09:51:18 -0400 (EDT)
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 QQldid13121;
	Thu, 23 Aug 2001 13:52:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldid28498
	for mpls-outgoing; Thu, 23 Aug 2001 13:52:01 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 QQldid28474
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 13:52: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 QQldid20151
	for <mpls@uu.net>; Thu, 23 Aug 2001 13:51:35 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldid07137
	for <mpls@uu.net>; Thu, 23 Aug 2001 13:51:34 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 JAA01032 for <mpls@uu.net>; Thu, 23 Aug 2001 09:51:34 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA18136 for mpls@uu.net; Thu, 23 Aug 2001 09: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 QQldfu15508
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 22 Aug 2001 22:37:26 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 QQldfu20238
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:37:02 GMT
Received: from mailhost.bravara.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailhost.bravidacorp.com [38.168.15.229])
	id QQldfu11013
	for <mpls@UU.NET>; Wed, 22 Aug 2001 22:37:02 GMT
Received: from MSeerypc (user-38lc10d.dialup.mindspring.com [209.86.4.13])
	by mailhost.bravara.com (Mirapoint)
	with ESMTP id AAA35690 (AUTH mark);
	Wed, 22 Aug 2001 15:36:50 -0700 (PDT)
From: "Mark Seery" <mark@bravara.com>
To: "Kota, Ravikumar" <RKota@cratosnetworks.com>,
        "'Srinivas T M'" <srini_tm@yahoo.com>, <mpls@UU.NET>
Subject: RE: e-lsp & l - lsp
Date: Wed, 22 Aug 2001 15:32:37 -0700
Message-ID: <KIECKNDNBENPBBGCDFIDAEIICOAA.mark@bravara.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <95F30C6F1B56D4118F9200508BC75B3A31A445@yn-server1.yodanetworks.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

>>  e-lsp intended for carrying single OA for single LSP. l-lsp is intended
for carrying multiple OA s for LSP.

I believe it is the other way.

From the below mentioned draft:

"1.2 EXP-Inferred-PSC LSPs (E-LSP)

   A single LSP can be used to support one or more OAs. Such LSPs can
   support up to eight BAs of a given FEC, regardless of how many OAs
   these BAs span. With such LSPs, the EXP field of the MPLS Shim
   Header is used by the LSR to determine the PHB to be applied to the
   packet. This includes both the PSC and the drop preference......."

"1.3 Label-Only-Inferred-PSC LSPs (L-LSP)

   A separate LSP can be established for a single <FEC, OA> pair.
   With such LSPs, the PSC is explicitly signaled at label
   establishment time so that, after label establishment, the LSR can
   infer exclusively from the label value the PSC to be applied to a
   labeled packet. When the Shim Header is used, the Drop Precedence to
   be applied by the LSR to the labeled packet, is conveyed inside the
   labeled packet MPLS Shim Header using the EXP field. When the Shim
   Header is not used (e.g. MPLS Over ATM), the Drop Precedence to be
   applied by the LSR to the labeled packet is conveyed inside the link
   layer header encapsulation using link layer specific drop precedence
   fields (e.g. ATM CLP)....."

Additional comments:

A number of existing layer 2 technologies (e.g. ATM) can only support L-LSP
because of their inability to carry the equivalent of a full EXP field (drop
precedence can be indicated).

Some people have argued that in the context of diffserv/traffic engineering
support only L-LSPs would be used - I leave this argument as an exercise for
the reader.

E-LSPs represent an approach most similar to diffserv TOS treatment.

-mark

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kota,
Ravikumar
Sent: Wednesday, August 22, 2001 3:02 PM
To: 'Srinivas T M'; mpls@UU.NET
Subject: RE: e-lsp & l - lsp


Hi srinivas ,
These are two techiniques to implement packet treatment in  MPLS cloud ,
with diffserv inferred information.
The diffserv information from the packet can be encapsulated into label/exp
field of  "MPLS labelled packet "(this will be happened between
diffservcloud and mpls cloud ),
so that we will be making sure that diffserv information will be used in
MPLS cloud to treat the packets according to that information.
Cisco is implementing this concept with the name : MPLS  DIFFSERV AWARE TE
 e-lsp intended for carrying single OA for single LSP.
l-lsp is intended for carrying multiple OA s for LSP.


 OA  :      Ordered Aggregate. The set of Behavior Aggregates which
               share an ordering constraint.

Any comments are welcome.


Reference draft : draft-ietf-mpls-diff-ext-09.txt


Regards
Ravikumar Kota
978  263 0094 (extn  8157 )(work)
978 869 3314(cell)




-----Original Message-----
From: Srinivas T M [mailto:srini_tm@yahoo.com]
Sent: Wednesday, August 22, 2001 5:46 PM
To: mpls@UU.NET
Subject: e-lsp & l - lsp


Hi,
    Can anybody explain what is e-lsp ,l-lsp and
difference between them.


Thanks,
Srini


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Thu Aug 23 10:06:07 2001
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 KAA23728
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:06:07 -0400 (EDT)
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 QQldie01674;
	Thu, 23 Aug 2001 14:07:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldie10190
	for mpls-outgoing; Thu, 23 Aug 2001 14:06:46 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 QQldie10181
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:06: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 QQldie29958
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:04:51 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldie28952
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:04:52 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GYTA>; Thu, 23 Aug 2001 10:00:25 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A447@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'manoj juneja'" <manojkumarjuneja@hotmail.com>, mpls@UU.NET
Subject: RE: RSVP Hello 
Date: Thu, 23 Aug 2001 10:00:24 -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

Hi Manoj ,

RSVP hellos will be useful to discover/make adjancies in MPLS cloud.
As these messages will be useful to session initialization/establishment,
hello messages should be exchanged irrespective of session .

Regards
Ravikumar Kota
978 869 3314 (cell)
978 263 0094 (x 8157)(work)



-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Thursday, August 23, 2001 2:10 AM
To: mpls@UU.NET
Subject: RSVP Hello 


Hi All,
         The RSVP-TE draft states that the RSVP Hellos should be transmitted

when there is a RSVP state between the neighbors i.e. when there is 
Path/Resv state. In other words, if there is a RSVP session between two 
nodes then the RSVP hellos need to be exchanged. If the RSVP session is to 
be released (i.e. graceful termination), does this mean that RSVP hellos 
should not be exchanged between the RSVP neighbors as long as there is no 
RSVP session between them ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


From owner-mpls@UU.NET  Thu Aug 23 10:10:13 2001
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 KAA23802
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:10:12 -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 QQldie05195;
	Thu, 23 Aug 2001 14:11:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldie16922
	for mpls-outgoing; Thu, 23 Aug 2001 14:11: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 QQldie15571
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:10:48 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 QQldie26202
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:10:46 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldie04391
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:10:46 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 KAA03433 for <mpls@uu.net>; Thu, 23 Aug 2001 10:10:46 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18388 for mpls@uu.net; Thu, 23 Aug 2001 10:10:18 -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 QQldid29399
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 13:57: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 QQldid25508
	for <mpls@UU.NET>; Thu, 23 Aug 2001 13:57:09 GMT
From: rpapneja@gmu.edu
Received: from portal.gmu.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: portalknot.gmu.edu [129.174.0.8])
	id QQldid19484
	for <mpls@UU.NET>; Thu, 23 Aug 2001 13:57:09 GMT
Received: from gmu.edu (mail02.gmu.edu [129.174.0.10])
	by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA01351;
	Thu, 23 Aug 2001 09:56:44 -0400 (EDT)
To: "Adrian Farrel" <afarrel@movaz.com>
Cc: "Ajay Simha" <asimha@cisco.com>, "shen jing"
 <jshen@cad.zju.edu.cn>,
        <zhoukui@gaohong.com.cn>, "mpls@uu.net"
 <mpls@UU.NET>
Message-ID: <5d1565d67b.5d67b5d156@gmu.edu>
Date: Thu, 23 Aug 2001 09:56:44 -0400
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: en
Subject: Re: has ietf completed Specifying MPLS-specific recovery
 mechanisms?
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Also, refer to the following draft:
    draft-atlas-rsvp-local-protect-interop-01.txt.

 -Rajiv

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
Tel: 703.993.4703
******************************** 

----- Original Message -----
From: "Adrian Farrel" <afarrel@movaz.com>
Date: Thursday, August 23, 2001 9:26 am
Subject: Re: has ietf completed Specifying MPLS-specific recovery 
mechanisms?

> You may find draft-lang-ccamp-recovery-01.txt relevant if you're 
> prepared to
> encompass GMPLS.
> 
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> afarrel@movaz.com
> ----- Original Message -----
> From: "Ajay Simha" <asimha@cisco.com>
> To: "shen jing" <jshen@cad.zju.edu.cn>
> Cc: <zhoukui@gaohong.com.cn>; "mpls@uu.net" <mpls@UU.NET>
> Sent: Wednesday, August 22, 2001 11:31 PM
> Subject: Re: has ietf completed Specifying MPLS-specific recovery 
> mechanisms?
> 
> > On Thu, 23 Aug 2001, shen jing wrote:
> >
> > > There  has been proposals for fast reroute and path 
> protections for LSP.
> > >
> > > Please refer to :
> > >
> > >
> > > draft-ietf-mpls-recovery-frmwrk-03.txt
> > > draft-kini-restoration-shared-backup-00.txt
> > > draft-chang-mpls-rsvpte-path-protection-ext-01.txt
> >
> > also look at the draft-swallow-rsvp-bypass-label-01.txt
> >
> > -ajay
> > >
> > > Jing Shen
> > >
> > >
> > >
> > > > hi, does anyone know whether ietf has completed Specifying 
> MPLS-specific
> > > recovery mechanisms which allow one label-switched path to be 
> used as
> > > backup for a set of other label-switched paths, including 
> cases which
> > > permit local repair? > thanks a lot! > > zhoukui@gaohong.com.cn
> > >
> >
> > --
> > Ajay Simha
> > MPLS Deployment Engineer
> > IOS Technology Division
> > (919) 392-3141
> >
> > "Study as if you were to live forever
> >  Live as if you were to die tomorrow"
> >
> >  - Mahatma Gandhi
> >
> 
> 
> 



From owner-mpls@UU.NET  Thu Aug 23 10:36:47 2001
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 KAA24415
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:36:47 -0400 (EDT)
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 QQldig07930;
	Thu, 23 Aug 2001 14:37:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldig22063
	for mpls-outgoing; Thu, 23 Aug 2001 14:37:21 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 QQldig22049
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:37: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 QQldig17919
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:37:02 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldig06720
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:37:02 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GY4D>; Thu, 23 Aug 2001 10:32:40 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A3D79BF@yn-server1.yodanetworks.com>
From: "Prabakaran, Thirumali" <tprabakaran@cratosnetworks.com>
To: "Kota, Ravikumar" <RKota@cratosnetworks.com>,
        "'manoj juneja'"
	 <manojkumarjuneja@hotmail.com>, mpls@UU.NET
Subject: RE: RSVP Hello 
Date: Thu, 23 Aug 2001 10:32:39 -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

Hello Ravikumar Kota,

I added my views and comments,
Please see my inlined comments with [Prabakaran].
Further clarifications/corrections and comments, I am pleased to recv it.


Thanks and regards,
Prabakaran TS.
Software Engineer,
Cratos Networks, Inc.,
100 Nagog Park
Acton, MA  01720
978-263-0094 - Extn:8159

-----Original Message-----
From: Kota, Ravikumar [mailto:RKota@cratosnetworks.com]
Sent: Thursday, August 23, 2001 10:00 AM
To: 'manoj juneja'; mpls@UU.NET
Subject: RE: RSVP Hello 


Hi Manoj ,

RSVP hellos will be useful to discover/make adjancies in MPLS cloud.

[Prabakaran] As per draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, In section 5,
the Hello message in RSVP-TE is a optional message, and I think
it is not used for discover/make adjacencies in MPLS cloud, it 
is a mechanism which provides node to node failure detection.  
When such a failure is detected it is handled much the same 
as a link layer communication failure.  

As these messages will be useful to session initialization/establishment,

[Prabakaran]The RSVP Hello message is not used for session
initialization/establishment
in RSVP TE extension, it's purpose is to detect node failures.


hello messages should be exchanged irrespective of session .

[Prabakaran]If two nodes are supporting Hello message and which is enabled
in both
node for node failure detection, then the Hellos can be exchanged between
the nodes.

Also please refer the following paragraph from the Section 5 of the draft
for
more understanding.

"  The Hello extension is specifically designed so that one side can use
   the mechanism while the other side does not.  Neighbor failure
   detection may be initiated at any time.  This includes when neighbors
   first learn about each other, or just when neighbors are sharing Resv
   or Path state "


Regards
Ravikumar Kota
978 869 3314 (cell)
978 263 0094 (x 8157)(work)



-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Thursday, August 23, 2001 2:10 AM
To: mpls@UU.NET
Subject: RSVP Hello 


Hi All,
         The RSVP-TE draft states that the RSVP Hellos should be transmitted

when there is a RSVP state between the neighbors i.e. when there is 
Path/Resv state. In other words, if there is a RSVP session between two 
nodes then the RSVP hellos need to be exchanged. If the RSVP session is to 
be released (i.e. graceful termination), does this mean that RSVP hellos 
should not be exchanged between the RSVP neighbors as long as there is no 
RSVP session between them ?

[Prabakaran ] In my understanding, once Hello message exchange is started
until, the protocol is disabled 
on an interface, the messages should be keep on exchanging for node failure
detection, since
in your case after the graceful termination of the the sessions(I think all
the sessions associated
with respect to that link), then there will not be any PSB/RSB associated
with that interface, in that
case what is the use of having hello messages exchanged in between the
nodes, even if the node fails, 
which is detected by Hello message which is of no use to the PSB/RSB, I
think it is a protocol implementation
specific and how the node failure notification is handled when there is no
PSB/RSB associated with it..??


Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


From owner-mpls@UU.NET  Thu Aug 23 10:41:08 2001
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 KAA24530
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:41:08 -0400 (EDT)
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 QQldig13362;
	Thu, 23 Aug 2001 14:42:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldig22434
	for mpls-outgoing; Thu, 23 Aug 2001 14:41: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 QQldig22425
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:41:34 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 QQldig15138
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:41:31 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldig20385
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:41:30 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA11157 for mpls@uu.net; Thu, 23 Aug 2001 10:41:29 -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 QQldig22351
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:41: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 QQldig13195
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:40:52 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQldig11652
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:40:52 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5ATG7>; Thu, 23 Aug 2001 10:40:26 -0400
Message-ID: <87009604743AD411B1F600508BA0F959D1C5DB@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'Kota, Ravikumar'" <RKota@cratosnetworks.com>,
        "'manoj juneja'"
	 <manojkumarjuneja@hotmail.com>, mpls@UU.NET
Subject: RE: RSVP Hello 
Date: Thu, 23 Aug 2001 10:40:16 -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

Ravi, 

I thought that when an RSVP LSP was up that RSVP Hellos were sent because a
session was established. How can you send RSVP Hellos without or
irrespective of a session?

Isn't the whole concept of RSVP Hellos link detection failure and not
discovery?

-----Original Message-----
From: Kota, Ravikumar [mailto:RKota@cratosnetworks.com]
Sent: Thursday, August 23, 2001 10:00 AM
To: 'manoj juneja'; mpls@UU.NET
Subject: RE: RSVP Hello 


Hi Manoj ,

RSVP hellos will be useful to discover/make adjancies in MPLS cloud.
As these messages will be useful to session initialization/establishment,
hello messages should be exchanged irrespective of session .

Regards
Ravikumar Kota
978 869 3314 (cell)
978 263 0094 (x 8157)(work)



-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Thursday, August 23, 2001 2:10 AM
To: mpls@UU.NET
Subject: RSVP Hello 


Hi All,
         The RSVP-TE draft states that the RSVP Hellos should be transmitted

when there is a RSVP state between the neighbors i.e. when there is 
Path/Resv state. In other words, if there is a RSVP session between two 
nodes then the RSVP hellos need to be exchanged. If the RSVP session is to 
be released (i.e. graceful termination), does this mean that RSVP hellos 
should not be exchanged between the RSVP neighbors as long as there is no 
RSVP session between them ?

Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 23 10:49:00 2001
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 KAA24639
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:49:00 -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 QQldih03134;
	Thu, 23 Aug 2001 14:50:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldih23268
	for mpls-outgoing; Thu, 23 Aug 2001 14:49: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 QQldih23245
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:49:09 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 QQldih05988
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:48:32 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldih00713
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:48:31 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA12058 for mpls@uu.net; Thu, 23 Aug 2001 10:48:30 -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 QQldih23146
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:48: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 QQldih03224
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:47:36 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 QQldih20238
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:47:36 GMT
Received: from JVASSEUR-W2K.cisco.com (jvasseur-isdn-home.cisco.com [10.49.88.162])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA19421;
	Thu, 23 Aug 2001 16:47:20 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20010823164441.05736dc0@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 16:46:53 +0200
To: "Kota, Ravikumar" <RKota@cratosnetworks.com>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: RE: RSVP Hello 
Cc: "'manoj juneja'" <manojkumarjuneja@hotmail.com>, mpls@UU.NET
In-Reply-To: <95F30C6F1B56D4118F9200508BC75B3A31A447@yn-server1.yodanetw
 orks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Ravikumar,

At 10:00 23/08/2001 -0400, Kota, Ravikumar wrote:
>Hi Manoj ,
>
>RSVP hellos will be useful to discover/make adjancies in MPLS cloud.

This is not the purpose of hello messages. Hellos message can be used to 
detect node failure. Can be an asymmetric process.

JP.

>As these messages will be useful to session initialization/establishment,
>hello messages should be exchanged irrespective of session .
>Regards
>Ravikumar Kota
>978 869 3314 (cell)
>978 263 0094 (x 8157)(work)
>
>
>
>-----Original Message-----
>From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
>Sent: Thursday, August 23, 2001 2:10 AM
>To: mpls@UU.NET
>Subject: RSVP Hello
>
>
>Hi All,
>          The RSVP-TE draft states that the RSVP Hellos should be transmitted
>
>when there is a RSVP state between the neighbors i.e. when there is
>Path/Resv state. In other words, if there is a RSVP session between two
>nodes then the RSVP hellos need to be exchanged. If the RSVP session is to
>be released (i.e. graceful termination), does this mean that RSVP hellos
>should not be exchanged between the RSVP neighbors as long as there is no
>RSVP session between them ?
>
>Regards,
>manoj.
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 23 10:55:29 2001
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 KAA24763
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 10:55:29 -0400 (EDT)
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 QQldih01819;
	Thu, 23 Aug 2001 14:56:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldih24010
	for mpls-outgoing; Thu, 23 Aug 2001 14:56:04 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 QQldih24005
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:56:04 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 QQldih28384
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:55:56 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldih12102
	for <mpls@uu.net>; Thu, 23 Aug 2001 14:55:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA12869 for mpls@uu.net; Thu, 23 Aug 2001 10:55:54 -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 QQldih23976
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 14:55: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 QQldih23864
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:54:22 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQldih28830
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:54:22 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AT27>; Thu, 23 Aug 2001 10:53:56 -0400
Message-ID: <87009604743AD411B1F600508BA0F959D1C5DD@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'Kota, Ravikumar'" <RKota@cratosnetworks.com>,
        "'manoj juneja'"
	 <manojkumarjuneja@hotmail.com>, mpls@UU.NET
Subject: RE: RSVP Hello 
Date: Thu, 23 Aug 2001 10:53:48 -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

Also, if there aren't any RSVP LSPs setup between neighbors, then their is
no session, thus there are no Hellos being sent.

-----Original Message-----
From: Kota, Ravikumar [mailto:RKota@cratosnetworks.com]
Sent: Thursday, August 23, 2001 10:00 AM
To: 'manoj juneja'; mpls@UU.NET
Subject: RE: RSVP Hello 


Hi Manoj ,

RSVP hellos will be useful to discover/make adjancies in MPLS cloud.
As these messages will be useful to session initialization/establishment,
hello messages should be exchanged irrespective of session .

Regards
Ravikumar Kota
978 869 3314 (cell)
978 263 0094 (x 8157)(work)



From owner-mpls@UU.NET  Thu Aug 23 11:10:55 2001
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 LAA25288
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 11:10: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 QQldii17989;
	Thu, 23 Aug 2001 15:12:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldii07307
	for mpls-outgoing; Thu, 23 Aug 2001 15:11: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 QQldii07266
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:11: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 QQldii01649
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:10:44 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldii22204
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:10:45 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2GYVY>; Thu, 23 Aug 2001 11:06:18 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A448@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "Prabakaran, Thirumali" <tprabakaran@cratosnetworks.com>,
        "Kota, Ravikumar" <RKota@cratosnetworks.com>,
        "'manoj juneja'"
	 <manojkumarjuneja@hotmail.com>, mpls@UU.NET
Subject: RE: RSVP Hello 
Date: Thu, 23 Aug 2001 11:06:17 -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

Hi ,

By mistake i have given explanation for discovery message exchange (with
hello message s) which are helpful
for session initialization/establishment in LDP protocol.(udp based exchange
for learning about neighbours and their label spaces )
But the actual question is related to  "hello" message exchange in RSVP.

From RFC 3036 :LDP Specification
1.2. LDP Message Exchange

   There are four categories of LDP messages:

      1. Discovery messages, used to announce and maintain the presence
         of an LSR in a network.

      2. Session messages, used to establish, maintain, and terminate
         sessions between LDP peers.

      3. Advertisement messages, used to create, change, and delete
         label mappings for FECs.

      4. Notification messages, used to provide advisory information and
         to signal error information.

   

   Discovery messages provide a mechanism whereby LSRs indicate their
   presence in a network by sending a Hello message periodically.  This
   is transmitted as a UDP packet to the LDP port at the `all routers on
   this subnet' group multicast address.  When an LSR chooses to
   establish a session with another LSR learned via the Hello message,
   it uses the LDP initialization procedure over TCP transport.  Upon
   successful completion of the initialization procedure, the two LSRs
   are LDP peers, and may exchange advertisement messages.

   When to request a label or advertise a label mapping to a peer is
   largely a local decision made by an LSR.  In general, the LSR
   requests a label mapping from a neighboring LSR when it needs one,
   and advertises a label mapping to a neighboring LSR when it wishes
   the neighbor to use a label.
-------------------------------------------------------------------------

2.5. Establishing and Maintaining LDP Sessions

2.5.1. LDP Session Establishment

   The exchange of LDP Discovery Hellos between two LSRs triggers LDP
   session establishment.  Session establishment is a two step process:

            -  Transport connection establishment.
            -  Session initialization

   The following describes establishment of an LDP session between LSRs
   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
   for LSR2.

Regards
Ravikumar Kota

-----Original Message-----
From: Prabakaran, Thirumali [mailto:tprabakaran@cratosnetworks.com]
Sent: Thursday, August 23, 2001 10:33 AM
To: Kota, Ravikumar; 'manoj juneja'; mpls@UU.NET
Subject: RE: RSVP Hello 


Hello Ravikumar Kota,

I added my views and comments,
Please see my inlined comments with [Prabakaran].
Further clarifications/corrections and comments, I am pleased to recv it.


Thanks and regards,
Prabakaran TS.
Software Engineer,
Cratos Networks, Inc.,
100 Nagog Park
Acton, MA  01720
978-263-0094 - Extn:8159

-----Original Message-----
From: Kota, Ravikumar [mailto:RKota@cratosnetworks.com]
Sent: Thursday, August 23, 2001 10:00 AM
To: 'manoj juneja'; mpls@UU.NET
Subject: RE: RSVP Hello 


Hi Manoj ,

RSVP hellos will be useful to discover/make adjancies in MPLS cloud.

[Prabakaran] As per draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, In section 5,
the Hello message in RSVP-TE is a optional message, and I think
it is not used for discover/make adjacencies in MPLS cloud, it 
is a mechanism which provides node to node failure detection.  
When such a failure is detected it is handled much the same 
as a link layer communication failure.  

As these messages will be useful to session initialization/establishment,

[Prabakaran]The RSVP Hello message is not used for session
initialization/establishment
in RSVP TE extension, it's purpose is to detect node failures.


hello messages should be exchanged irrespective of session .

[Prabakaran]If two nodes are supporting Hello message and which is enabled
in both
node for node failure detection, then the Hellos can be exchanged between
the nodes.

Also please refer the following paragraph from the Section 5 of the draft
for
more understanding.

"  The Hello extension is specifically designed so that one side can use
   the mechanism while the other side does not.  Neighbor failure
   detection may be initiated at any time.  This includes when neighbors
   first learn about each other, or just when neighbors are sharing Resv
   or Path state "


Regards
Ravikumar Kota
978 869 3314 (cell)
978 263 0094 (x 8157)(work)



-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Thursday, August 23, 2001 2:10 AM
To: mpls@UU.NET
Subject: RSVP Hello 


Hi All,
         The RSVP-TE draft states that the RSVP Hellos should be transmitted

when there is a RSVP state between the neighbors i.e. when there is 
Path/Resv state. In other words, if there is a RSVP session between two 
nodes then the RSVP hellos need to be exchanged. If the RSVP session is to 
be released (i.e. graceful termination), does this mean that RSVP hellos 
should not be exchanged between the RSVP neighbors as long as there is no 
RSVP session between them ?

[Prabakaran ] In my understanding, once Hello message exchange is started
until, the protocol is disabled 
on an interface, the messages should be keep on exchanging for node failure
detection, since
in your case after the graceful termination of the the sessions(I think all
the sessions associated
with respect to that link), then there will not be any PSB/RSB associated
with that interface, in that
case what is the use of having hello messages exchanged in between the
nodes, even if the node fails, 
which is detected by Hello message which is of no use to the PSB/RSB, I
think it is a protocol implementation
specific and how the node failure notification is handled when there is no
PSB/RSB associated with it..??


Regards,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


From owner-mpls@UU.NET  Thu Aug 23 11:21:37 2001
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 LAA25601
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 11:21:37 -0400 (EDT)
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 QQldij09447;
	Thu, 23 Aug 2001 15:22:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldij15038
	for mpls-outgoing; Thu, 23 Aug 2001 15:22:06 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 QQldij15022
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:21:52 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 QQldij18218
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:21:42 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 QQldij05231
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:21: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 LAA10362
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:21:40 -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 LAA06588
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:21:41 -0400 (EDT)
Message-ID: <3B851F7F.D7B9DEF9@marconi.com>
Date: Thu, 23 Aug 2001 11:21:35 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <F93bgssmCix4DZVeHir0000f7e0@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

manoj juneja wrote:
> 
>          The RSVP-TE draft states that the RSVP Hellos should be
> transmitted when there is a RSVP state between the neighbors i.e.
> when there is Path/Resv state. In other words, if there is a RSVP
> session between two nodes then the RSVP hellos need to be exchanged.
> If the RSVP session is to be released (i.e. graceful termination),
> does this mean that RSVP hellos should not be exchanged between the
> RSVP neighbors as long as there is no RSVP session between them ?

I don't think anything in there prohibits the exchange of Hello messages
in the absence of established Path/Resv state.  But it's not very
useful, either - since any detected failures will not result in changing
any state.

-- David


From owner-mpls@UU.NET  Thu Aug 23 11:22:18 2001
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 LAA25621
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 11:22:18 -0400 (EDT)
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 QQldij11114;
	Thu, 23 Aug 2001 15:23:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldij15091
	for mpls-outgoing; Thu, 23 Aug 2001 15:22:52 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 QQldij15078
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:22: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 QQldij20926
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:22:33 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 QQldij25427
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:22:33 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 LAA10429
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:22:30 -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 LAA06741
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:22:32 -0400 (EDT)
Message-ID: <3B851FB1.4AE579DE@marconi.com>
Date: Thu, 23 Aug 2001 11:22:25 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <87009604743AD411B1F600508BA0F959D1C5DB@XOVER.dedham.mindspeed.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Sanford, Bill" wrote:
> 
> Isn't the whole concept of RSVP Hellos link detection failure and
> not discovery?

Yes.  LDP uses hellos for discovery.  RSVP only uses them for failure
detection.

-- David


From owner-mpls@UU.NET  Thu Aug 23 11:39:59 2001
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 LAA26026
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 11:39:58 -0400 (EDT)
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 QQldik04465;
	Thu, 23 Aug 2001 15:40:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldik16924
	for mpls-outgoing; Thu, 23 Aug 2001 15:40: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 QQldik16915
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:40: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 QQldik23453
	for <mpls@uu.net>; Thu, 23 Aug 2001 15:39:56 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldik24164
	for <mpls@uu.net>; Thu, 23 Aug 2001 15:39:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA17578 for mpls@uu.net; Thu, 23 Aug 2001 11:39:55 -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 QQldik16864
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:39:37 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 QQldik07559
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:38:25 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQldik01011
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:38:24 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AT3A>; Thu, 23 Aug 2001 11:37:57 -0400
Message-ID: <87009604743AD411B1F600508BA0F959D1C5E1@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'David Charlap'" <david.charlap@marconi.com>, mpls@UU.NET
Subject: RE: RSVP Hello
Date: Thu, 23 Aug 2001 11:37:55 -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

>>manoj juneja wrote:
>> 
>>          The RSVP-TE draft states that the RSVP Hellos should be
>> transmitted when there is a RSVP state between the neighbors i.e.
>> when there is Path/Resv state. In other words, if there is a RSVP
>> session between two nodes then the RSVP hellos need to be exchanged.
>> If the RSVP session is to be released (i.e. graceful termination),
>> does this mean that RSVP hellos should not be exchanged between the
>> RSVP neighbors as long as there is no RSVP session between them ?
>
>I don't think anything in there prohibits the exchange of Hello messages
>in the absence of established Path/Resv state.  But it's not very
>useful, either - since any detected failures will not result in changing
>any state.
>
>-- David

David, wouldn't the lack of information from the absence if the RSVP LSP
establishment almost guarantee that the RSVP Hellos can't be sent?

Bill



From owner-mpls@UU.NET  Thu Aug 23 11:46:38 2001
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 LAA26163
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 11:46: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 QQldil07443;
	Thu, 23 Aug 2001 15:47:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldil17680
	for mpls-outgoing; Thu, 23 Aug 2001 15:47:23 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 QQldil17666
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 15:47: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 QQldil02062
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:46:05 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 QQldil11519
	for <mpls@UU.NET>; Thu, 23 Aug 2001 15:46: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 LAA13301
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:46:03 -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 LAA15469
	for <mpls@UU.NET>; Thu, 23 Aug 2001 11:46:04 -0400 (EDT)
Message-ID: <3B852535.FA5A7FB7@marconi.com>
Date: Thu, 23 Aug 2001 11:45:57 -0400
From: David Charlap <david.charlap@marconi.com>
Reply-To: mpls@UU.NET
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <87009604743AD411B1F600508BA0F959D1C5E1@XOVER.dedham.mindspeed.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Sanford, Bill" wrote:
> 
> David, wouldn't the lack of information from the absence if the
> RSVP LSP establishment almost guarantee that the RSVP Hellos can't
> be sent?

Why?  All you need to send Hellos is a destination address and an
interface.  If you have a point to point link, then you know your
neighbor's address - either from configuration or from routing
protocols.

If the interface is a broadcast-type interface, then you would obviously
need some other mechanism to learn the neighbor address(es).  If you
know them, however, there is no reason why you couldn't send Hellos as
well.

-- David


From owner-mpls@UU.NET  Thu Aug 23 14:00:52 2001
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 OAA28322
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 14:00:51 -0400 (EDT)
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 QQldiu25766;
	Thu, 23 Aug 2001 18:01:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldiu11608
	for mpls-outgoing; Thu, 23 Aug 2001 18:01:30 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 QQldiu11570
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 18:01:27 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 QQldit10053
	for <mpls@uu.net>; Thu, 23 Aug 2001 17:59:36 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f97.law11.hotmail.com [64.4.17.97])
	id QQldit23102
	for <mpls@uu.net>; Thu, 23 Aug 2001 17:59:36 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 23 Aug 2001 10:59:35 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Thu, 23 Aug 2001 17:59:35 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: mpls@UU.NET
Subject: Link Bundling drafts
Date: Thu, 23 Aug 2001 13:59:35 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F97qYW8BYXifWoqFXfy000000ec@hotmail.com>
X-OriginalArrivalTime: 23 Aug 2001 17:59:35.0318 (UTC) FILETIME=[5E606360:01C12BFD]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I am unable to appreciate the difference between
draft-kompella-ospf-gmpls-extensions-01.txt
and
draft-rs-optical-bundling-01.txt
with reference to optical link bundling concept presented
in both of them. Can someone clarify in brief.

I know that draft-kompella has draft-dubuc-mpls-bundle-mib-02.txt
as the supporting MIB.
Is there any MIB associated with draft-rs-*.

Appreciate any comments.

Regards,
Irfan Lateef


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 23 14:18:32 2001
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 OAA28645
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 14:18:32 -0400 (EDT)
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 QQldiv16601;
	Thu, 23 Aug 2001 18:19:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldiv28092
	for mpls-outgoing; Thu, 23 Aug 2001 18:19: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 QQldiv28084
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 18:19: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 QQldiv05002
	for <mpls@uu.net>; Thu, 23 Aug 2001 18:19:06 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldiv15868
	for <mpls@uu.net>; Thu, 23 Aug 2001 18:19:06 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA01021 for mpls@uu.net; Thu, 23 Aug 2001 14:18:59 -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 QQldiv28040
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 18:18:38 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 QQldiv03409
	for <mpls@UU.NET>; Thu, 23 Aug 2001 18:18:30 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQldiv15170
	for <mpls@UU.NET>; Thu, 23 Aug 2001 18:18:29 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AT5J>; Thu, 23 Aug 2001 14:18:00 -0400
Message-ID: <87009604743AD411B1F600508BA0F959D1C5E3@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RSVP Hello
Date: Thu, 23 Aug 2001 14:17:55 -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

>"Sanford, Bill" wrote:
>> 
>> David, wouldn't the lack of information from the absence if the
>> RSVP LSP establishment almost guarantee that the RSVP Hellos can't
>> be sent?
>
>Why?  All you need to send Hellos is a destination address and an
>interface.  If you have a point to point link, then you know your
>neighbor's address - either from configuration or from routing
>protocols.
>
>If the interface is a broadcast-type interface, then you would obviously
>need some other mechanism to learn the neighbor address(es).  If you
>know them, however, there is no reason why you couldn't send Hellos as
>well.
>
>-- David

Then if have to have "some other mechanism" learn them, then we are out of
the RSVP scope. 

I think we got the initial point accross. ;-]

Bill



From owner-mpls@UU.NET  Thu Aug 23 14:58:06 2001
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 OAA29296
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 14:58:06 -0400 (EDT)
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 QQldix05418;
	Thu, 23 Aug 2001 18:59:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldix01770
	for mpls-outgoing; Thu, 23 Aug 2001 18:58: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 QQldix01765
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 18:58: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 QQldix25828
	for <mpls@UU.NET>; Thu, 23 Aug 2001 18:57:58 GMT
Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQldix03831
	for <mpls@UU.NET>; Thu, 23 Aug 2001 18:57:59 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 OAA19851
	for <mpls@UU.NET>; Thu, 23 Aug 2001 14:50:00 -0400 (EDT)
Subject: Re: 
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFF875A19E.3494ED42-ON85256AB0.005DA880@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 23 Aug 2001 14:49:54 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/23/2001 02:49:55 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


You are right, that is what I observed from the router.

Actually I sent out the path msg with correct checksum and wrong ctype, but
I did not get the PathErr msg back, I think the Vender did not implement it
properly.

Thanks,

Julia



>>Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid.
An invalid checksum will cause the router to drop the message without
generating any errors.


then how can I let router generate this patherr for the following scenario?

> An RSVP router that recognizes the LABEL_REQUEST object but
>    does not recognize the C_Type sends a PathErr with the error code
>    "Unknown object C_Type" toward the sender.
>
> so I have path msg sent out with correct LRO class, and length, but
> it has unknown ctype, such as '0F'H,
> but receiver will not send out patherr from it.



Thanks,

Julia



                                                                                                         
                    David Charlap                                                                        
                    <david.charlap@ma        To:     mpls@UU.NET                                         
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                          
                                             Subject:     Re:                                            
                    08/22/01 12:44 PM                                                                    
                                                                                                         
                                                                                                         





Hong Liao wrote:
>
> []  But even that is the case,  --bad checksum, the Router should
> send back the path error msg with error code 23.
>
> ----------   spec 2205.
>  Error Code = 23: RSVP System error
>
> o    Wrong-length message: RSVP Length field does not match message
>         length.
>
>    o    Unknown or unsupported RSVP version.
>
>    o    Bad RSVP checksum
>
>    o    INTEGRITY failure

You deleted four paragraphs of text between the line "Error Code = 23"
and the list of conditions.  Among other things, those four paragraphs
contain:

     ... Should a programming error allow an RSVP to create a
     malformed message, the error is not generally reported to
     end systems in an ERROR_SPEC object; instead, the error is
     simply logged locally, and perhaps reported through network
     management mechanisms.

     The only message formatting errors that are reported to end
     systems are those that may reflect version mismatches, and
     which the end system might be able to circumvent, e.g., by
     falling back to a previous CType for an object; see code 13
     and 14 above.

     The choice of message formatting errors that an RSVP may
     detect and log locally is implementation-specific, but it
     will typically include the following:

     ...  (list of conditions)

The RFC explicitly states that conditions like wrong-length message,
unknown RSVP version, bad checksum and INTEGRITY failure do _NOT_ cause
the generation of error messages.  The packets are dropped.  The error
condition may be logged or reported through network management.

-- David





From owner-mpls@UU.NET  Thu Aug 23 16:12:42 2001
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 QAA00593
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 16:12:42 -0400 (EDT)
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 QQldjc08032;
	Thu, 23 Aug 2001 20:13:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjc15835
	for mpls-outgoing; Thu, 23 Aug 2001 20:13: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 QQldjc15812
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 20:13: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 QQldjc15900
	for <mpls@uu.net>; Thu, 23 Aug 2001 20:12:43 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldjc06847
	for <mpls@uu.net>; Thu, 23 Aug 2001 20:12:43 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA10683 for mpls@uu.net; Thu, 23 Aug 2001 16:12:41 -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 QQldjc15298
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 20:12:22 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 QQldjc22353
	for <mpls@uu.net>; Thu, 23 Aug 2001 20:12:03 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQldjc06067
	for <mpls@uu.net>; Thu, 23 Aug 2001 20:12:04 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA03288
	for <mpls@uu.net>; Thu, 23 Aug 2001 20:12:02 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082313105212790
 for <mpls@uu.net>; Thu, 23 Aug 2001 13:10:52 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RJ8VKGXR>; Thu, 23 Aug 2001 13:11:53 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D5009AE2DF9@FMSMSX37>
From: "Sharma, Prem" <p_sharma@trillium.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: some queries on mpls-ftn-mib-03
Date: Thu, 23 Aug 2001 13:11:20 -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,

I was trying to see if some consensus has been reached on the following
outstanding issues w.r.t. mpls-ftn-mib:
*	Keeping mapping of DSCP values to LSPs/Tunnels 
*	Use of CIDR prefixes instead of Address ranges.
*	Keeping IPv6 flow label also. 

Aforementioned pertain to the mplsFTNEntry in the MIB.
One more comment: I'll be better if the relation of this draft with diffserv
mib could be clarified too.

Thanks.
Prem



From owner-mpls@UU.NET  Thu Aug 23 18:41:54 2001
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 SAA03292
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 18:41:53 -0400 (EDT)
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 QQldjm02232;
	Thu, 23 Aug 2001 22:43:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjm05856
	for mpls-outgoing; Thu, 23 Aug 2001 22:42:38 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 QQldjm05851
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 22:42:35 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 QQldjm29585
	for <mpls@UU.NET>; Thu, 23 Aug 2001 22:42:12 GMT
Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: entmail.gnilink.net [199.45.47.10])
	id QQldjm01323
	for <mpls@UU.NET>; Thu, 23 Aug 2001 22:42:13 GMT
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <RPCT0JZT>; Thu, 23 Aug 2001 18:42:12 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDD77@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'Sanford, Bill'" <bill.sanford@netplane.com>,
        "'mpls@UU.NET'"
	 <mpls@UU.NET>
Subject: RE: RSVP Hello
Date: Thu, 23 Aug 2001 18:42:12 -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 I may comment here from an operational perspective...

I think the Hello mechanism, as specified, could be extended to occur upon
link initialization.  One of my most frustrating experiences with RSVP state
was when a new link was turned up with a fat-fingered authentication key.
Since there is no initial RSVP state acorss the link until a PATH message
needs to be sent, I was unaware of it until I had to troubleshoot a label
request across 13 routers.  Were it part of the specification to send
Hello's and build an adjaceny during link intialization, it would have been
something detectable during configuration.

Perhaps the draft can be extended to address this operational need?  How
difficult would it be to add:

"Upon link initialization, an interface MAY/SHOULD immediately send an RSVP
hello to the all routers multicast address on broadcast media, or to its
direct neighbor on ptp media.  For each RSVP hello received, record the
source IP address in the RSVP adjacency table.  Transmit hello's every
configurable interval."

Of course, this example discusses authenticated RSVP messages, but other
types of issues can impair RSVP without easy detection.  As it is today, you
can either send a test PATH message across the network to build state, or
you can hope it works when you need it.  Neither is operationally
acceptable, IMHO.

Regards,
 -chris


> >"Sanford, Bill" wrote:
> >> 
> >> David, wouldn't the lack of information from the absence if the
> >> RSVP LSP establishment almost guarantee that the RSVP Hellos can't
> >> be sent?
> >
> >Why?  All you need to send Hellos is a destination address and an
> >interface.  If you have a point to point link, then you know your
> >neighbor's address - either from configuration or from routing
> >protocols.
> >
> >If the interface is a broadcast-type interface, then you 
> would obviously
> >need some other mechanism to learn the neighbor address(es).  If you
> >know them, however, there is no reason why you couldn't send 
> Hellos as
> >well.
> >
> >-- David
> 
> Then if have to have "some other mechanism" learn them, then 
> we are out of
> the RSVP scope. 
> 
> I think we got the initial point accross. ;-]
> 
> Bill
> 


From owner-mpls@UU.NET  Thu Aug 23 19:12:58 2001
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 TAA03708
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 19:12:58 -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 QQldjo27235;
	Thu, 23 Aug 2001 23:14:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjo27204
	for mpls-outgoing; Thu, 23 Aug 2001 23:13:37 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 QQldjo27180
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 23:13:24 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 QQldjo24029
	for <mpls@UU.NET>; Thu, 23 Aug 2001 23:11:49 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQldjo05378
	for <mpls@UU.NET>; Thu, 23 Aug 2001 23:11:48 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <RQD3LDAX>; Thu, 23 Aug 2001 20:10:12 -0300
Message-ID: <72702AB72C89D511A9E70008C791736801172F2E@MSTELEFONICA3>
From: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
To: "Kota, Ravikumar" <RKota@cratosnetworks.com>,
        "'Srinivas T M'"
	 <srini_tm@yahoo.com>, mpls@UU.NET
Subject: RE: e-lsp & l - lsp
Date: Thu, 23 Aug 2001 09:24:35 -0300
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 TAA03708

Correction:

You can have DiffServ over MPLS without implementing DF-TE.

MPLS DiffServ Aware TE or DF-TE adds:

-Constraint Based Routing per Class with different bandwidth constraints.
-Admision Control per Class over different bandwith pools (ie bandwith
allocated to class queue)

E-LSP intented for carring multiple OA for single LSP
L-LSP is intented por carrying single OA for LSP

For more details see:

http://www.cisco.com/warp/public/732/Tech/mpls/mpls_presentations.shtml


regards,

Sergio Fabris


> -----Mensaje original-----
> De:	Kota, Ravikumar [SMTP:RKota@cratosnetworks.com]
> Enviado el:	Miércoles 22 de Agosto de 2001 7:02 PM
> Para:	'Srinivas T M'; mpls@UU.NET
> Asunto:	RE: e-lsp & l - lsp
> 
> Hi srinivas ,
> These are two techiniques to implement packet treatment in  MPLS cloud ,
> with diffserv inferred information.
> The diffserv information from the packet can be encapsulated into
> label/exp
> field of  "MPLS labelled packet "(this will be happened between
> diffservcloud and mpls cloud ),
> so that we will be making sure that diffserv information will be used in
> MPLS cloud to treat the packets according to that information.
> Cisco is implementing this concept with the name : MPLS  DIFFSERV AWARE TE
>  e-lsp intended for carrying single OA for single LSP.
> l-lsp is intended for carrying multiple OA s for LSP.
> 
> 
>  OA  :      Ordered Aggregate. The set of Behavior Aggregates which
>                share an ordering constraint.
> 
> Any comments are welcome.
> 
> 
> Reference draft : draft-ietf-mpls-diff-ext-09.txt  
> 
> 
> Regards
> Ravikumar Kota
> 978  263 0094 (extn  8157 )(work)   
> 978 869 3314(cell)
>             
> 
> 
> 
> -----Original Message-----
> From: Srinivas T M [mailto:srini_tm@yahoo.com]
> Sent: Wednesday, August 22, 2001 5:46 PM
> To: mpls@UU.NET
> Subject: e-lsp & l - lsp
> 
> 
> Hi,
>     Can anybody explain what is e-lsp ,l-lsp and
> difference between them.
> 
> 
> Thanks,
> Srini
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Thu Aug 23 19:24:14 2001
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 TAB03873
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 19:24:14 -0400 (EDT)
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 QQldjp21535;
	Thu, 23 Aug 2001 23:25:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjp28672
	for mpls-outgoing; Thu, 23 Aug 2001 23:25:01 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 QQldjp28660
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 23:24:58 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 QQldjp14249
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:24:51 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQldjp29257
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:24:50 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA03048
	for <mpls@uu.net>; Thu, 23 Aug 2001 19:24:50 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA19437 for mpls@uu.net; Thu, 23 Aug 2001 19:24:22 -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 QQldit07463
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 17:57:59 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 QQldit21926
	for <mpls@UU.NET>; Thu, 23 Aug 2001 17:56:37 GMT
Received: from racerx.ixiacom.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 64-60-75-69-cust.telepacific.net [64.60.75.69])
	id QQldit19820
	for <mpls@UU.NET>; Thu, 23 Aug 2001 17:56:37 GMT
Received: by racerx.ixiacom.com with Internet Mail Service (5.5.2653.19)
	id <RH93LQHT>; Thu, 23 Aug 2001 10:56:36 -0700
Message-ID: <9A9C83C019F35D47A570460E87D5D8ABFCC13C@racerx.ixiacom.com>
From: Maciek Arkuszewski <markuszewski@ixiacom.com>
To: mpls@UU.NET
Subject: MPLS frames over Ethernet
Date: Thu, 23 Aug 2001 10:56:34 -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.

How exactly is a proper MAC address picked for outgoing frame? Is there an
additional mapping maintained between labels and ARP table on LSR? 

Maciek Arkuszewski
Senior Software Engineer
Ixia
<mailto:maciek@ixiacom.com>
Tel: (818)444-2305

      Ixia...
             When the test really counts.
 



From owner-mpls@UU.NET  Thu Aug 23 19:25:44 2001
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 TAA03888
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 19:25:44 -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 QQldjp02058;
	Thu, 23 Aug 2001 23:26:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjp28886
	for mpls-outgoing; Thu, 23 Aug 2001 23:26: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 QQldjp28881
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 23:26:20 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 QQldjp15252
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:25:23 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldjp29995
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:25:22 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 TAA11991 for <mpls@uu.net>; Thu, 23 Aug 2001 19:25:22 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA19447 for mpls@uu.net; Thu, 23 Aug 2001 19:24:54 -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 QQldjg10074
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 21:14:18 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 QQldjg00313
	for <mpls@uu.net>; Thu, 23 Aug 2001 21:14:10 GMT
Received: from BRSPOMAIL01.br.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gw.attla.com.br [200.173.132.130] (may be forged))
	id QQldjg21399
	for <mpls@uu.net>; Thu, 23 Aug 2001 21:14:11 GMT
Received: by BRSPOMAIL01.br.attla.corp with Internet Mail Service (5.5.2653.19)
	id <RN87FQV4>; Thu, 23 Aug 2001 18:13:57 -0300
Message-ID: <C6FBB67DF697F84980770AC75B485058442084@brspomail02.br.attla.corp>
From: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question
Date: Thu, 23 Aug 2001 18:13:56 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12C18.84FFD300"
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_01C12C18.84FFD300
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

A have a question regarding the VPNv4 address space and the BGP decision
algorithm. 

Suppose that i have two VPNv4 prefixes in a VRF, with the same ipv4 prefix
but different RDs. How does BGP decision algorithm face it ? 
I think that one and just one ipv4 prefix should be chosen in order to
populate the forwarding component, but how can BGP decide it if the prefixes
are different in the VPNv4 point of view ?

Also, imagine that i have an inter-as VPN/MPLS interconnection. Suppose that
i have an extranet transversing the two providers and that all VPN sites are
connected to both providers for redundancy. Each site advertises the same
prefix to both providers and the prefixes are imported in the inter-as
connection. How will BGP decide between the two prefixes inside one of the
providers ?



Thanks,
--

Rodrigo Loureiro 



------_=_NextPart_001_01C12C18.84FFD300
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>Question</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">A have a question regarding the VPNv4 =
address space and the BGP decision algorithm. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Suppose that i have two VPNv4 prefixes =
in a VRF, with the same ipv4 prefix but different RDs. How does BGP =
decision algorithm face it ? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think that one and just one ipv4 =
prefix should be chosen in order to populate the forwarding component, =
but how can BGP decide it if the prefixes are different in the VPNv4 =
point of view ?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, imagine that i have an inter-as =
VPN/MPLS interconnection. Suppose that i have an extranet transversing =
the two providers and that all VPN sites are connected to both =
providers for redundancy. Each site advertises the same prefix to both =
providers and the prefixes are imported in the inter-as connection. How =
will BGP decide between the two prefixes inside one of the providers =
?</FONT></P>
<BR>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Rodrigo Loureiro</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12C18.84FFD300--



From owner-mpls@UU.NET  Thu Aug 23 19:26:21 2001
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 TAA03901
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 19:26:21 -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 QQldjp03165;
	Thu, 23 Aug 2001 23:27:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjp28947
	for mpls-outgoing; Thu, 23 Aug 2001 23:27:00 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 QQldjp28941
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 23:26:58 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 QQldjp03162
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:25:12 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQldjp29757
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:25:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA03079
	for <mpls@uu.net>; Thu, 23 Aug 2001 19:25:11 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA19441 for mpls@uu.net; Thu, 23 Aug 2001 19:24:44 -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 QQldjb26089
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 19:57:58 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 QQldjb20612
	for <mpls@UU.NET>; Thu, 23 Aug 2001 19:56:50 GMT
Received: from qlink.queensu.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: Qlink.QueensU.CA [130.15.129.2])
	id QQldjb17626
	for <mpls@UU.NET>; Thu, 23 Aug 2001 19:56:50 GMT
Received: from Arthur (d141-159-32.home.cgocable.net [24.141.159.32])
	by qlink.queensu.ca (8.10.1/8.10.1) with SMTP id f7NJumc06492;
	Thu, 23 Aug 2001 15:56:49 -0400 (EDT)
Message-ID: <016801c12c1f$9df3bf50$209f8d18@Arthur>
From: "Pin-Han Ho" <8ph5@qlink.queensu.ca>
To: <mpls@UU.NET>, <IP-Optical@lists.bell-labs.com>
References: <Pine.GSO.4.33.0108231512530.22694-100000@crete.csi.forth.gr>
Subject: Re: [IP-Optical] A question on optical path establishment wrt overlay model
Date: Thu, 23 Aug 2001 15:04:43 -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 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

In terms of Overlay model, signaling is exchanged in the upper client layer
and transportation layer separately. An interface is defined between the
client layer and the transportation layer below, in order to achieve the
control and management efforts.

     The client network can not know the dynamic traffic condition in the
optical domain, however, the interface is equipped with some primitives for
the clients so that they can submit SLAs to the optical networks, or inquery
some of the traffic information if it is allowed. The overlay model is
designed for protecting the public transportation layer shared by hundreds
or thousands of clients.

     Clients do not have to know the exactly lightpaths they are taking,
since the control plane in the optical domain takes it over.

Pin-Han


----- Original Message -----
From: "Chrysostomos Tziouvaras" <tziou@ics.forth.gr>
To: <mpls@UU.NET>; <IP-Optical@lists.bell-labs.com>
Sent: Thursday, August 23, 2001 5:17 AM
Subject: [IP-Optical] A question on optical path establishment wrt overlay
model


Hi all,
I would like to ask you the following question:
in the overlay model, if a client network that is attached to an optical
network asks for an optical path, how can it specify that this path must
be
exclusively used by it and no other client network that is attached to the
same edge device of the client network?

Regards
Tziouvaras Chrysostomos
ICS-FORTH Researcher








From owner-mpls@UU.NET  Thu Aug 23 19:38:03 2001
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 TAA04004
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 19:38:03 -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 QQldjq03092;
	Thu, 23 Aug 2001 23:39:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjq00208
	for mpls-outgoing; Thu, 23 Aug 2001 23:38:49 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 QQldjq00199
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 23 Aug 2001 23:38: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 QQldjq10279
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:37:53 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQldjq06199
	for <mpls@uu.net>; Thu, 23 Aug 2001 23:37:52 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <RQD3LFQ1>; Thu, 23 Aug 2001 20:32:44 -0300
Message-ID: <72702AB72C89D511A9E70008C791736801172FE1@MSTELEFONICA3>
From: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
To: mpls@UU.NET
Subject: RSVP-TE packet loss
Date: Thu, 23 Aug 2001 10:38:34 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

.....RSVP-TE runs over UDP so it is less reliable 
than CR-LDP who runs over TCP......

I read about some enhancements to RSVP-TE 
for allowing it to recover from packet loss in time 
frame comparable with those of TCP.

Could someone tell me about this enhancements??

Regards,

Sergio Fabris



From owner-mpls@UU.NET  Thu Aug 23 21:50:07 2001
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 VAA06061
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 21:50:07 -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 QQldjz03617;
	Fri, 24 Aug 2001 01:51:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldjz17243
	for mpls-outgoing; Fri, 24 Aug 2001 01:50: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 QQldjz17238
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 01:50:50 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 QQldjz02846
	for <mpls@UU.NET>; Fri, 24 Aug 2001 01:50:18 GMT
Received: from TYO201.gate.nec.co.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: TYO201.gate.nec.co.jp [202.32.8.214])
	id QQldjz19413
	for <mpls@UU.NET>; Fri, 24 Aug 2001 01:50:17 GMT
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO201.gate.nec.co.jp (8.11.3/3.7W01080315) with ESMTP id f7O1nrs27609;
	Fri, 24 Aug 2001 10:49:53 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP
	id f7O1np617387; Fri, 24 Aug 2001 10:49:52 +0900 (JST)
Received: from tomato.nwk.cl.nec.co.jp (tomato.nwk.cl.nec.co.jp [10.56.32.1]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f7O1nm827672; Fri, 24 Aug 2001 10:49:50 +0900 (JST)
Received: from tea.nwk.cl.nec.co.jp by tomato.nwk.cl.nec.co.jp (8.11.3/NWKM20000322) with ESMTP
	id f7O1ncn85948; Fri, 24 Aug 2001 10:49:39 +0900 (JST)
Received: from iwata-pc2.nwk.cl.nec.co.jp (iwata-pc2.nwk.cl.nec.co.jp [10.56.32.77])
	by tea.nwk.cl.nec.co.jp (8.9.0/3.7W) with ESMTP id KAA21177;
	Fri, 24 Aug 2001 10:49:36 +0900 (JST)
Message-Id: <4.3.2-J.20010824105139.03d37b90@tea.nwk.cl.nec.co.jp>
X-Sender: iwata@tea.nwk.cl.nec.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Fri, 24 Aug 2001 10:55:50 +0900
To: <zhoukui@gaohong.com.cn>
From: Atsushi Iwata <iwata@ccm.CL.nec.co.jp>
Subject: Re: has ietf completed Specifying MPLS-specific
  recoverymechanisms?
Cc: "Adrian Farrel" <afarrel@movaz.com>, "Ajay Simha" <asimha@cisco.com>,
        "shen jing"<jshen@cad.zju.edu.cn>, "mpls@uu.net"<mpls@UU.NET>,
        rpapneja@gmu.edu
In-Reply-To: <5d1565d67b.5d67b5d156@gmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

You may also refer to the following draft:

draft-iwata-mpls-shared-fastreroute-00.txt

Thanks.


At 09:56 01/08/23 -0400, rpapneja@gmu.edu wrote:
>Also, refer to the following draft:
>    draft-atlas-rsvp-local-protect-interop-01.txt.
>
> -Rajiv
>
>********************************
>Rajiv Papneja (GRA)
>Advanced Internet Laboratory
>Tel: 703.993.4703
>******************************** 
>
>----- Original Message -----
>From: "Adrian Farrel" <afarrel@movaz.com>
>Date: Thursday, August 23, 2001 9:26 am
>Subject: Re: has ietf completed Specifying MPLS-specific recovery 
>mechanisms?
>
>> You may find draft-lang-ccamp-recovery-01.txt relevant if you're 
>> prepared to
>> encompass GMPLS.
>> 
>> Adrian
>> --
>> Adrian Farrel
>> Movaz Networks Inc.
>> afarrel@movaz.com
>> ----- Original Message -----
>> From: "Ajay Simha" <asimha@cisco.com>
>> To: "shen jing" <jshen@cad.zju.edu.cn>
>> Cc: <zhoukui@gaohong.com.cn>; "mpls@uu.net" <mpls@UU.NET>
>> Sent: Wednesday, August 22, 2001 11:31 PM
>> Subject: Re: has ietf completed Specifying MPLS-specific recovery 
>> mechanisms?
>> 
>> > On Thu, 23 Aug 2001, shen jing wrote:
>> >
>> > > There  has been proposals for fast reroute and path 
>> protections for LSP.
>> > >
>> > > Please refer to :
>> > >
>> > >
>> > > draft-ietf-mpls-recovery-frmwrk-03.txt
>> > > draft-kini-restoration-shared-backup-00.txt
>> > > draft-chang-mpls-rsvpte-path-protection-ext-01.txt
>> >
>> > also look at the draft-swallow-rsvp-bypass-label-01.txt
>> >
>> > -ajay
>> > >
>> > > Jing Shen
>> > >
>> > >
>> > >
>> > > > hi, does anyone know whether ietf has completed Specifying 
>> MPLS-specific
>> > > recovery mechanisms which allow one label-switched path to be 
>> used as
>> > > backup for a set of other label-switched paths, including 
>> cases which
>> > > permit local repair? > thanks a lot! > > zhoukui@gaohong.com.cn
>> > >
>> >
>> > --
>> > Ajay Simha
>> > MPLS Deployment Engineer
>> > IOS Technology Division
>> > (919) 392-3141
>> >
>> > "Study as if you were to live forever
>> >  Live as if you were to die tomorrow"
>> >
>> >  - Mahatma Gandhi
>> >
>> 
>> 
>> 
>
----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Principal Researcher
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     a-iwata@ah.jp.nec.com
NEC-internal E-mail: iwata@ccm.CL.nec.co.jp

*** Organization has been a bit changed since Apr.2001 ***



From owner-mpls@UU.NET  Thu Aug 23 22:08:44 2001
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 WAA06281
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 22:08:44 -0400 (EDT)
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 QQldka12267;
	Fri, 24 Aug 2001 02:09:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldka06839
	for mpls-outgoing; Fri, 24 Aug 2001 02:09:21 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 QQldka06822
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 02:09:19 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 QQldka06229
	for <mpls@uu.net>; Fri, 24 Aug 2001 02:08:39 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldka00437
	for <mpls@uu.net>; Fri, 24 Aug 2001 02:08:38 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA02816 for mpls@uu.net; Thu, 23 Aug 2001 22:08:37 -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 QQldka06686
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 02:08:25 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 QQldka03523
	for <mpls@UU.NET>; Fri, 24 Aug 2001 02:07:59 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sword.cisco.com [161.44.208.100])
	id QQldka24765
	for <mpls@UU.NET>; Fri, 24 Aug 2001 02:07:59 GMT
Received: from mwollen-w2k.cisco.com (ott-b1-dhcp-10-85-31-107.cisco.com [10.85.31.107])
	by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id WAA25589
	for <mpls@UU.NET>; Thu, 23 Aug 2001 22:07:58 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010823220901.01afcdb8@sword.cisco.com>
X-Sender: mwollen@sword.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 22:09:43 -0400
To: mpls@UU.NET
From: Martin Wollensak <mwollen@cisco.com>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

unsubscribe



From owner-mpls@UU.NET  Thu Aug 23 23:12:03 2001
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 XAA07750
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 23:12:03 -0400 (EDT)
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 QQldke28531;
	Fri, 24 Aug 2001 03:13:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldke00523
	for mpls-outgoing; Fri, 24 Aug 2001 03:12: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 QQldke00383
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 03:12: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 QQldke18993
	for <mpls@uu.net>; Fri, 24 Aug 2001 03:12:23 GMT
Received: from china.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [61.135.144.48])
	id QQldke27435
	for <mpls@uu.net>; Fri, 24 Aug 2001 03:12:23 GMT
Received: from china.com([10.1.7.103]) by china.com(AIMC 2.9.5.2)
	with SMTP id jm43b85beb0; Fri, 24 Aug 2001 03:08:51 +0800
Received: from host.secure4-hosting.net([209.239.41.31]) by china.com(AIMC 2.9.5.2)
	with SMTP id jm1803b7d450c; Fri, 17 Aug 2001 22:19:22 +0800
Received: (from mplsrc12@localhost)
	by host.secure4-hosting.net (8.10.2/8.10.2) id f7HEGg800806;
	Fri, 17 Aug 2001 10:16:42 -0400
X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
Message-ID: <751B6DD7A243D511AB9F0002557C5687B55B98@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: RE: Traffic Engineering TLV
Date: Fri, 17 Aug 2001 19:27:08 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12728.B220BE70"
X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/2322
X-Loop: mpls-ops@mplsrc.com
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_01C12728.B220BE70
Content-Type: text/plain;
	charset="iso-8859-1"


Dear Naidu

 I couldn't find the draft-kompella-tewg-bw-acct-00.txt draft can you please
 tell me where can i get this draft ?

Thanks & regds
Ashwin


-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Thursday, August 16, 2001 7:12 PM
To: 'Ashwin C. Prabhu'; Naidu, Venkata; mpls@UU.NET; mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV


Ashwin:

   Please look at my inline comments...

-> The priority/preemption is a task of MPLS Management 
-> module. I would like to know why the 8 priority levels 
-> are provided in the OSPF Extension? 

   OSPF (for that matter any IGP) job is to flood the TE
   information throughout the area (at present) for TE
   purpose. The 8 priority levels for unreserved bw is 
   nothing to do with OSPF calculations. Just flood the info!

-> What i was thinking is this 8 priority levels is used by 
-> the CSPF for the computation of the routes. If so, why 
-> is it Unreservable Bandwidth for the 8 priority levels ? 

   Yes! After flooding the TE information, ingress LERs do 
   CSPF to prune links (which are not met the requested 
   bw, priority, preemption etc) to find the best path to egress.

-> does it mean that on a link we configure the Bandwidth 
-> for different priority levels ? 
->        (Like Priority 0 -> 30 % bandwidth etc ) 
->        Or this is ment for some other purpose ? 

   It is not that simple, please look at Kompella's paper
   draft-kompella-tewg-bw-acct-00.txt (and nested references)

->        As i found the draft draft-katz-yeung-ospf-traffic-04 
-> not mentioning it clearly. 

   As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do
   with configuration of priority levels. 

--Venkata Naidu


-> -----Original Message----- 
-> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] 
-> Sent: Tuesday, August 14, 2001 7:37 PM 
-> To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com 
-> Subject: FW: Traffic Engineering TLV 
-> 
-> 
-> Prabhu: 
-> ->             Can anyone please tell me what are these 8 
-> -> priority levels and what for these 
-> ->             used ? 
->   There are no set of semantics for each priority level. 
->   The different levels provide an ordering that can be 
->   used to determine preemption during the establishment 
->   of LSPs. They can also be used by an implementation 
->   as a means of ordering LSP computation and setup. 
->   How to use these priority levels? Look at: 
->   CR-LDP draft-ietf-mpls-cr-ldp-05.txt and 
->   RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 
-> -> why we need this. 
->   The need for priority levels is specified in 
->   RFC 2702. There is a consensus of eight protocols 
->   being sufficient.  
->   In Dan's terms... 
->   "The priority attribute defines the relative importance of traffic 
->    trunks.  If a constraint-based routing framework is used 
-> with MPLS, 
->    then priorities become very important because they can be used to 
->    determine the order in which path selection is done for traffic 
->    trunks at connection establishment and under fault scenarios. 
->    Priorities are also important in implementations  permitting 
->    preemption because they can be used to impose a partial 
-> order on the 
->    set of traffic trunks according to which preemptive 
-> policies can be 
->    actualized." 
-> --Venkata Naidu 
-> 

------_=_NextPart_001_01C12728.B220BE70
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.2653.12">
<TITLE>RE: Traffic Engineering TLV</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Dear Naidu</FONT>
</P>

<P><FONT SIZE=2>&nbsp;I couldn't find the draft-kompella-tewg-bw-acct-00.txt draft can you please</FONT>
<BR><FONT SIZE=2>&nbsp;tell me where can i get this draft ?</FONT>
</P>

<P><FONT SIZE=2>Thanks &amp; regds</FONT>
<BR><FONT SIZE=2>Ashwin</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Naidu, Venkata [<A HREF="mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, August 16, 2001 7:12 PM</FONT>
<BR><FONT SIZE=2>To: 'Ashwin C. Prabhu'; Naidu, Venkata; mpls@UU.NET; mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=2>Subject: FW: Traffic Engineering TLV</FONT>
</P>
<BR>

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

<P><FONT SIZE=2>&nbsp;&nbsp; Please look at my inline comments...</FONT>
</P>

<P><FONT SIZE=2>-&gt; The priority/preemption is a task of MPLS Management </FONT>
<BR><FONT SIZE=2>-&gt; module. I would like to know why the 8 priority levels </FONT>
<BR><FONT SIZE=2>-&gt; are provided in the OSPF Extension? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; OSPF (for that matter any IGP) job is to flood the TE</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; information throughout the area (at present) for TE</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; purpose. The 8 priority levels for unreserved bw is </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; nothing to do with OSPF calculations. Just flood the info!</FONT>
</P>

<P><FONT SIZE=2>-&gt; What i was thinking is this 8 priority levels is used by </FONT>
<BR><FONT SIZE=2>-&gt; the CSPF for the computation of the routes. If so, why </FONT>
<BR><FONT SIZE=2>-&gt; is it Unreservable Bandwidth for the 8 priority levels ? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Yes! After flooding the TE information, ingress LERs do </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; CSPF to prune links (which are not met the requested </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; bw, priority, preemption etc) to find the best path to egress.</FONT>
</P>

<P><FONT SIZE=2>-&gt; does it mean that on a link we configure the Bandwidth </FONT>
<BR><FONT SIZE=2>-&gt; for different priority levels ? </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Like Priority 0 -&gt; 30 % bandwidth etc ) </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Or this is ment for some other purpose ? </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; It is not that simple, please look at Kompella's paper</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; draft-kompella-tewg-bw-acct-00.txt (and nested references)</FONT>
</P>

<P><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As i found the draft draft-katz-yeung-ospf-traffic-04 </FONT>
<BR><FONT SIZE=2>-&gt; not mentioning it clearly. </FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; with configuration of priority levels. </FONT>
</P>

<P><FONT SIZE=2>--Venkata Naidu</FONT>
</P>
<BR>

<P><FONT SIZE=2>-&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=2>-&gt; From: Naidu, Venkata [<A HREF="mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.com</A>] </FONT>
<BR><FONT SIZE=2>-&gt; Sent: Tuesday, August 14, 2001 7:37 PM </FONT>
<BR><FONT SIZE=2>-&gt; To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com </FONT>
<BR><FONT SIZE=2>-&gt; Subject: FW: Traffic Engineering TLV </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
<BR><FONT SIZE=2>-&gt; Prabhu: </FONT>
<BR><FONT SIZE=2>-&gt; -&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can anyone please tell me what are these 8 </FONT>
<BR><FONT SIZE=2>-&gt; -&gt; priority levels and what for these </FONT>
<BR><FONT SIZE=2>-&gt; -&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used ? </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; There are no set of semantics for each priority level. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; The different levels provide an ordering that can be </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; used to determine preemption during the establishment </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; of LSPs. They can also be used by an implementation </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; as a means of ordering LSP computation and setup. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; How to use these priority levels? Look at: </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; CR-LDP draft-ietf-mpls-cr-ldp-05.txt and </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt </FONT>
<BR><FONT SIZE=2>-&gt; -&gt; why we need this. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; The need for priority levels is specified in </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; RFC 2702. There is a consensus of eight protocols </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; being sufficient.&nbsp; </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; In Dan's terms... </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp; &quot;The priority attribute defines the relative importance of traffic </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; trunks.&nbsp; If a constraint-based routing framework is used </FONT>
<BR><FONT SIZE=2>-&gt; with MPLS, </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; then priorities become very important because they can be used to </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; determine the order in which path selection is done for traffic </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; trunks at connection establishment and under fault scenarios. </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; Priorities are also important in implementations&nbsp; permitting </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; preemption because they can be used to impose a partial </FONT>
<BR><FONT SIZE=2>-&gt; order on the </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; set of traffic trunks according to which preemptive </FONT>
<BR><FONT SIZE=2>-&gt; policies can be </FONT>
<BR><FONT SIZE=2>-&gt;&nbsp;&nbsp;&nbsp; actualized.&quot; </FONT>
<BR><FONT SIZE=2>-&gt; --Venkata Naidu </FONT>
<BR><FONT SIZE=2>-&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12728.B220BE70--

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


From owner-mpls@UU.NET  Thu Aug 23 23:20:52 2001
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 XAA07837
	for <mpls-archive@lists.ietf.org>; Thu, 23 Aug 2001 23:20:52 -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 QQldkf21715;
	Fri, 24 Aug 2001 03:21:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldkf01206
	for mpls-outgoing; Fri, 24 Aug 2001 03:21: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 QQldkf01201
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 03:21: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 QQldkf18237
	for <mpls@uu.net>; Fri, 24 Aug 2001 03:21:10 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldkf24276
	for <mpls@uu.net>; Fri, 24 Aug 2001 03:21:10 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA06375 for mpls@uu.net; Thu, 23 Aug 2001 23:21:08 -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 QQldkf01066
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 03:20:50 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 QQldkf13497
	for <mpls@UU.NET>; Fri, 24 Aug 2001 03:19:55 GMT
Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251])
	id QQldkf06740
	for <mpls@UU.NET>; Fri, 24 Aug 2001 03:19:55 GMT
Received: from MMOIZUDD-W2K.cisco.com (muali-dsl2.cisco.com [10.21.176.91])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA09115;
	Thu, 23 Aug 2001 20:19:51 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010823201049.029286b8@ce-nfs-1.cisco.com>
X-Sender: mmoizudd@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 23 Aug 2001 20:19:43 -0700
To: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>
From: Moiz Moizuddin <mmoizudd@cisco.com>
Subject: Re: Question
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <C6FBB67DF697F84980770AC75B485058442084@brspomail02.br.attl
 a.corp>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_111313089==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_111313089==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Loureiro
According to RFC 2547 Sec 4.1

"A given per-site forwarding table will only have one VPN-IPv4 route for 
any given IPv4 address prefix. When a packet's destination address is 
matched against a VPN-IPv4 route, only the IPv4 part is actually matched. "

So if we were to install two prefixes in a particular vrf  we will do the 
normal ipv4 bgp selection process

Thx
Moiz


At 06:13 PM 8/23/2001 -0300, Loureiro, Rodrigo - (Bra) wrote:

>Hi all,
>
>A have a question regarding the VPNv4 address space and the BGP decision 
>algorithm.
>
>Suppose that i have two VPNv4 prefixes in a VRF, with the same ipv4 prefix 
>but different RDs. How does BGP decision algorithm face it ?
>
>I think that one and just one ipv4 prefix should be chosen in order to 
>populate the forwarding component, but how can BGP decide it if the 
>prefixes are different in the VPNv4 point of view ?
>
>Also, imagine that i have an inter-as VPN/MPLS interconnection. Suppose 
>that i have an extranet transversing the two providers and that all VPN 
>sites are connected to both providers for redundancy. Each site advertises 
>the same prefix to both providers and the prefixes are imported in the 
>inter-as connection. How will BGP decide between the two prefixes inside 
>one of the providers ?
>
>
>Thanks,
>--
>
>Rodrigo Loureiro

--=====================_111313089==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Loureiro<br>
According to RFC 2547 Sec 4.1<br>
<br>
&quot;A given per-site forwarding table will only have one VPN-IPv4 route
for any given IPv4 address prefix. When a packet's destination address is
matched against a VPN-IPv4 route, only the IPv4 part is actually matched.
&quot;<br>
<br>
So if we were to install two prefixes in a particular vrf&nbsp; we  will
do the normal ipv4 bgp selection process<br>
<br>
Thx<br>
Moiz<br>
<br>
<br>
At 06:13 PM 8/23/2001 -0300, Loureiro, Rodrigo - (Bra) wrote:<br>
<br>
<blockquote type=cite cite><font size=2>Hi all,</font> <br>
<br>
<font size=2>A have a question regarding the VPNv4 address space and the
BGP decision algorithm. <br>
</font><br>
<font size=2>Suppose that i have two VPNv4 prefixes in a VRF, with the
same ipv4 prefix but different RDs. How does BGP decision algorithm face
it ? <br>
</font><br>
<font size=2>I think that one and just one ipv4 prefix should be chosen
in order to populate the forwarding component, but how can BGP decide it
if the prefixes are different in the VPNv4 point of view ?<br>
</font><br>
<font size=2>Also, imagine that i have an inter-as VPN/MPLS
interconnection. Suppose that i have an extranet transversing the two
providers and that all VPN sites are connected to both providers for
redundancy. Each site advertises the same prefix to both providers and
the prefixes are imported in the inter-as connection. How will BGP decide
between the two prefixes inside one of the providers ?<br>
</font><br>
<br>
<font size=2>Thanks,</font> <br>
<font size=2>--</font> <br>
<br>
<font size=2>Rodrigo Loureiro</font></blockquote></html>

--=====================_111313089==_.ALT--



From owner-mpls@UU.NET  Fri Aug 24 04:25:32 2001
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 EAA27192
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 04:25:32 -0400 (EDT)
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 QQldkz06978;
	Fri, 24 Aug 2001 08:26:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldkz23802
	for mpls-outgoing; Fri, 24 Aug 2001 08: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 QQldkz23751
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 08:25: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 QQldkz08676
	for <mpls@UU.NET>; Fri, 24 Aug 2001 08:25:17 GMT
Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.120.127.220])
	id QQldkz20455
	for <mpls@UU.NET>; Fri, 24 Aug 2001 08:25:12 GMT
Received: from xyx ([202.120.127.81])
	by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id QAA14541
	for <mpls@UU.NET>; Fri, 24 Aug 2001 16:29:01 +0800 (CST)
Message-ID: <003d01c12c76$ecc9dd60$517f78ca@xyx>
From: "Xu Yingxiao" <xyx@yc.shu.edu.cn>
To: <mpls@UU.NET>
References: <72702AB72C89D511A9E70008C791736801172FE1@MSTELEFONICA3>
Subject: MPLS, Active Network and Active routing
Date: Fri, 24 Aug 2001 16:29:27 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA27192

I am studying on MPLS and Active Network.
I think, broadly speeking, MPLS is a kind of active network as it is active in processing packets.
But it is not active network as we normally thought of, as MPLS Nodes was not designed with structure of Active network.

And active routing is selecting routes actively. It can be realized in Active network, also it can be realized using MPLS.

Any idea is welcome.



From owner-mpls@UU.NET  Fri Aug 24 07:01:12 2001
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 HAA28689
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 07:01:12 -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 QQldlk06224;
	Fri, 24 Aug 2001 11:02:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldlk19883
	for mpls-outgoing; Fri, 24 Aug 2001 11:02:00 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 QQldlk18323
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 11:01:48 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 QQldlk25559
	for <mpls@UU.NET>; Fri, 24 Aug 2001 11:00:20 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQldlk19305
	for <mpls@UU.NET>; Fri, 24 Aug 2001 11:00:20 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id HAA10682; Fri, 24 Aug 2001 07:00:33 -0400
Date: Fri, 24 Aug 2001 07:00:32 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: xyx@yc.shu.edu.cn
cc: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Re:  MPLS, Active Network and Active routing
Message-ID: <Pine.SUN.3.96.1010824065408.10055A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Xu,
Active Networks allow their "clients" to inject customized programs into
the nodes (routers/switches) of the network, e.g. packets are more
"generic capsules or program fragments" that are executed at each network
router/switch they traverse. 
In one sense the "label" values in the MPLS packet, is an "information
piece" which is interpreted wisely at any node(here MPLS LSR). But this
"intelligence" at LSR which enables it to determine label swapping and
forwarding operation, has been known at the time of LDP sessions. Only one
label determines the QoS treatment, the next hop, the TE decisions. In
this sense we can see MPLS to be somewhat "active". The basic idea behind
MPLS was to make the FR/ATM switches more "intelligent" using the IP
routing software.
MPLS also incorporates strong OAM, QoS and Traffic Engineering
capabilities. Any network which minimizes the complexity of the "End user"
and maximizes intelligence in "core" is active network.
Any thoughts or suggestions, if I am going in wrong direction ?

Regards,
Hemant


Date: Fri, 24 Aug 2001 16:29:27 +0800
From: Xu Yingxiao <xyx@yc.shu.edu.cn>
To: mpls@UU.NET

I am studying on MPLS and Active Network.
I think, broadly speeking, MPLS is a kind of active network as it is
active in processing packets.
But it is not active network as we normally thought of, as MPLS Nodes was
not designed with structure of Active network.

And active routing is selecting routes actively. It can be realized in
Active network, also it can be realized using MPLS.

Any idea is welcome.



From owner-mpls@UU.NET  Fri Aug 24 08:28:11 2001
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 IAA02725
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 08:28:11 -0400 (EDT)
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 QQldlp20755;
	Fri, 24 Aug 2001 12:29:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldlp24094
	for mpls-outgoing; Fri, 24 Aug 2001 12:29: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 QQldlp24089
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 12:28:50 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 QQldlp08389
	for <mpls@uu.net>; Fri, 24 Aug 2001 12:28:37 GMT
Received: from china.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [61.135.144.48])
	id QQldlp06713
	for <mpls@uu.net>; Fri, 24 Aug 2001 12:28:31 GMT
Received: from china.com([10.1.7.103]) by china.com(AIMC 2.9.5.2)
	with SMTP id jm23b86b20b; Fri, 24 Aug 2001 20:27:10 +0800
Received: from host.secure4-hosting.net([209.239.41.31]) by china.com(AIMC 2.9.5.2)
	with SMTP id jm1ee3b7c07dd; Thr, 16 Aug 2001 23:35:51 +0800
Received: (from mplsrc12@localhost)
	by host.secure4-hosting.net (8.10.2/8.10.2) id f7GEaH709888;
	Thu, 16 Aug 2001 10:36:17 -0400
X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
Message-ID: <39469E08BD83D411A3D900204840EC5554C6E4@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ashwin C. Prabhu'" <Ashwinp@in.huawei.com>,
        "Naidu, Venkata"
	 <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: FW: Traffic Engineering TLV
Date: Thu, 16 Aug 2001 10:12:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/2310
X-Loop: mpls-ops@mplsrc.com
Sender: owner-mpls@UU.NET
Precedence: bulk

Ashwin:

   Please look at my inline comments...

-> The priority/preemption is a task of MPLS Management 
-> module. I would like to know why the 8 priority levels 
-> are provided in the OSPF Extension? 

   OSPF (for that matter any IGP) job is to flood the TE
   information throughout the area (at present) for TE
   purpose. The 8 priority levels for unreserved bw is 
   nothing to do with OSPF calculations. Just flood the info!

-> What i was thinking is this 8 priority levels is used by 
-> the CSPF for the computation of the routes. If so, why 
-> is it Unreservable Bandwidth for the 8 priority levels ? 

   Yes! After flooding the TE information, ingress LERs do 
   CSPF to prune links (which are not met the requested 
   bw, priority, preemption etc) to find the best path to egress.

-> does it mean that on a link we configure the Bandwidth 
-> for different priority levels ? 
->        (Like Priority 0 -> 30 % bandwidth etc ) 
->        Or this is ment for some other purpose ? 

   It is not that simple, please look at Kompella's paper
   draft-kompella-tewg-bw-acct-00.txt (and nested references)

->        As i found the draft draft-katz-yeung-ospf-traffic-04 
-> not mentioning it clearly. 

   As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do
   with configuration of priority levels. 

--Venkata Naidu


-> -----Original Message----- 
-> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] 
-> Sent: Tuesday, August 14, 2001 7:37 PM 
-> To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com 
-> Subject: FW: Traffic Engineering TLV 
-> 
-> 
-> Prabhu: 
-> ->             Can anyone please tell me what are these 8 
-> -> priority levels and what for these 
-> ->             used ? 
->   There are no set of semantics for each priority level. 
->   The different levels provide an ordering that can be 
->   used to determine preemption during the establishment 
->   of LSPs. They can also be used by an implementation 
->   as a means of ordering LSP computation and setup. 
->   How to use these priority levels? Look at: 
->   CR-LDP draft-ietf-mpls-cr-ldp-05.txt and 
->   RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 
-> -> why we need this. 
->   The need for priority levels is specified in 
->   RFC 2702. There is a consensus of eight protocols 
->   being sufficient.  
->   In Dan's terms... 
->   "The priority attribute defines the relative importance of traffic 
->    trunks.  If a constraint-based routing framework is used 
-> with MPLS, 
->    then priorities become very important because they can be used to 
->    determine the order in which path selection is done for traffic 
->    trunks at connection establishment and under fault scenarios. 
->    Priorities are also important in implementations  permitting 
->    preemption because they can be used to impose a partial 
-> order on the 
->    set of traffic trunks according to which preemptive 
-> policies can be 
->    actualized." 
-> --Venkata Naidu 
-> 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


From owner-mpls@UU.NET  Fri Aug 24 08:55:30 2001
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 IAA03869
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 08:55:30 -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 QQldlr18768;
	Fri, 24 Aug 2001 12:56:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldlr26733
	for mpls-outgoing; Fri, 24 Aug 2001 12:56: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 QQldlr26677
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 12:56:12 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 QQldlr09006
	for <mpls@UU.NET>; Fri, 24 Aug 2001 12:55:57 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 QQldlr26953
	for <mpls@UU.NET>; Fri, 24 Aug 2001 12:55:57 GMT
Message-ID: <3B864EDB.264291B2@sandburst.com>
Date: Fri, 24 Aug 2001 08:55:55 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
Cc: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: Re: Traffic Engineering TLV
References: <751B6DD7A243D511AB9F0002557C5687B55B98@HUAWEIMAIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Try http://www.ietf.org/internet-drafts/draft-kompella-tewg-bw-acct-00.txt


"Ashwin C. Prabhu" wrote:

>
>
> Dear Naidu
>
>  I couldn't find the draft-kompella-tewg-bw-acct-00.txt draft can you please
>  tell me where can i get this draft ?
>
> Thanks & regds
> Ashwin
>
> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Thursday, August 16, 2001 7:12 PM
> To: 'Ashwin C. Prabhu'; Naidu, Venkata; mpls@UU.NET; mpls-ops@mplsrc.com
> Subject: FW: Traffic Engineering TLV
>
> Ashwin:
>
>    Please look at my inline comments...
>
> -> The priority/preemption is a task of MPLS Management
> -> module. I would like to know why the 8 priority levels
> -> are provided in the OSPF Extension?
>
>    OSPF (for that matter any IGP) job is to flood the TE
>    information throughout the area (at present) for TE
>    purpose. The 8 priority levels for unreserved bw is
>    nothing to do with OSPF calculations. Just flood the info!
>
> -> What i was thinking is this 8 priority levels is used by
> -> the CSPF for the computation of the routes. If so, why
> -> is it Unreservable Bandwidth for the 8 priority levels ?
>
>    Yes! After flooding the TE information, ingress LERs do
>    CSPF to prune links (which are not met the requested
>    bw, priority, preemption etc) to find the best path to egress.
>
> -> does it mean that on a link we configure the Bandwidth
> -> for different priority levels ?
> ->        (Like Priority 0 -> 30 % bandwidth etc )
> ->        Or this is ment for some other purpose ?
>
>    It is not that simple, please look at Kompella's paper
>    draft-kompella-tewg-bw-acct-00.txt (and nested references)
>
> ->        As i found the draft draft-katz-yeung-ospf-traffic-04
> -> not mentioning it clearly.
>
>    As I said, draft-katz-yeung-ospf-traffic-04 is nothing to do
>    with configuration of priority levels.
>
> --Venkata Naidu
>
> -> -----Original Message-----
> -> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> -> Sent: Tuesday, August 14, 2001 7:37 PM
> -> To: 'Ashwin C. Prabhu'; mpls@UU.NET; mpls-ops@mplsrc.com
> -> Subject: FW: Traffic Engineering TLV
> ->
> ->
> -> Prabhu:
> -> ->             Can anyone please tell me what are these 8
> -> -> priority levels and what for these
> -> ->             used ?
> ->   There are no set of semantics for each priority level.
> ->   The different levels provide an ordering that can be
> ->   used to determine preemption during the establishment
> ->   of LSPs. They can also be used by an implementation
> ->   as a means of ordering LSP computation and setup.
> ->   How to use these priority levels? Look at:
> ->   CR-LDP draft-ietf-mpls-cr-ldp-05.txt and
> ->   RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> -> -> why we need this.
> ->   The need for priority levels is specified in
> ->   RFC 2702. There is a consensus of eight protocols
> ->   being sufficient.
> ->   In Dan's terms...
> ->   "The priority attribute defines the relative importance of traffic
> ->    trunks.  If a constraint-based routing framework is used
> -> with MPLS,
> ->    then priorities become very important because they can be used to
> ->    determine the order in which path selection is done for traffic
> ->    trunks at connection establishment and under fault scenarios.
> ->    Priorities are also important in implementations  permitting
> ->    preemption because they can be used to impose a partial
> -> order on the
> ->    set of traffic trunks according to which preemptive
> -> policies can be
> ->    actualized."
> -> --Venkata Naidu
> ->



From owner-mpls@UU.NET  Fri Aug 24 09:02:31 2001
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 JAA04078
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 09:02:31 -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 QQldls29868;
	Fri, 24 Aug 2001 13:03:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldls03223
	for mpls-outgoing; Fri, 24 Aug 2001 13:03:20 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 QQldls03101
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 13:03: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 QQldls19832
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:02:31 GMT
From: neil.2.harrison@bt.com
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 QQldls28321
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:02:32 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <RL28S7RL>; Fri, 24 Aug 2001 14:02:44 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891649@mbddmknt01.hc.bt.com>
To: hemant@cyberspace.org
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: RE: MPLS, Active Network and Active routing
Date: Fri, 24 Aug 2001 14:01:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hemant P. Kelkar wrote 24 August 2001 12:01 (see line delimited by ** below)
<snipped>
> **MPLS also incorporates strong OAM**, QoS and Traffic Engineering
> capabilities.
<snipped>
NH=> I would be interested to know why you think MPLS currently incorporates
strong OAM.  I hope others are as concerned as I am that there are
activities in PWE3 and PPVPNs WGs and lots of IDs that refer to
prot-sw/restoration functionality, each of which depends on satisfatory OAM
capabilities being present, but MPLS OAM is not even in any WGs charter.  So
there is nowhere that MPLS data-plane defects are even defined.....let alone
the diagnostics and consequent actions which would be required for
carrier-class fault-management.

Neil
 


From owner-mpls@UU.NET  Fri Aug 24 09:28:43 2001
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 JAA04535
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 09:28:43 -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 QQldlt17766;
	Fri, 24 Aug 2001 13:29:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldlt18562
	for mpls-outgoing; Fri, 24 Aug 2001 13:29:27 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 QQldlt18554
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 13:29: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 QQldlt05774
	for <mpls@uu.net>; Fri, 24 Aug 2001 13:28:35 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldlt28181
	for <mpls@uu.net>; Fri, 24 Aug 2001 13:28:35 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA04873 for mpls@uu.net; Fri, 24 Aug 2001 09:28:33 -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 QQldlt18460
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 13:28:13 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 QQldlt09016
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:27:21 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQldlt26876
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:27:21 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21)
	id <QAH5AVMC>; Fri, 24 Aug 2001 09:26:53 -0400
Message-ID: <87009604743AD411B1F600508BA0F959D1C5F0@XOVER.dedham.mindspeed.com>
From: "Sanford, Bill" <bill.sanford@netplane.com>
To: "'Martin, Christian'" <cmartin@gnilink.net>,
        "Sanford, Bill"
	 <bill.sanford@netplane.com>,
        "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RSVP Hello
Date: Fri, 24 Aug 2001 09:26:52 -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

> -----Original Message-----
> From: Martin, Christian [mailto:cmartin@gnilink.net]
> Sent: Thursday, August 23, 2001 6:42 PM
> To: 'Sanford, Bill'; 'mpls@UU.NET'
> Subject: RE: RSVP Hello
> 
> 
> If I may comment here from an operational perspective...
> 
> I think the Hello mechanism, as specified, could be extended 
> to occur upon
> link initialization.  One of my most frustrating experiences 
> with RSVP state
> was when a new link was turned up with a fat-fingered 
> authentication key.
> Since there is no initial RSVP state acorss the link until a 
> PATH message
> needs to be sent, I was unaware of it until I had to 
> troubleshoot a label
> request across 13 routers.  Were it part of the specification to send
> Hello's and build an adjaceny during link intialization, it 
> would have been
> something detectable during configuration.

That sounds like a RSVP-TE that wants to be LDP. RSVP doesn't do this. Why
have LDP if RSVP is going to behave like it.

> Perhaps the draft can be extended to address this operational 
> need?  How
> difficult would it be to add:
> 
> "Upon link initialization, an interface MAY/SHOULD 
> immediately send an RSVP
> hello to the all routers multicast address on broadcast 
> media, or to its
> direct neighbor on ptp media.  For each RSVP hello received, 
> record the
> source IP address in the RSVP adjacency table.  Transmit hello's every
> configurable interval."

Adding more confusion to who is going to do what, when, and how it will
interoperate with RSVP (not-TE) and the omnipotent "cloud" brings another
level of frustration to the already miniscule timelines of project
completion. But, maybe it's just me. I cringe every time I hear "It will be
easy to add this fuctionality" or "how hard can this be?" 

> Of course, this example discusses authenticated RSVP 
> messages, but other
> types of issues can impair RSVP without easy detection.  As 
> it is today, you
> can either send a test PATH message across the network to 
> build state, or
> you can hope it works when you need it.  Neither is operationally
> acceptable, IMHO.

You can always submit a draft. ;-)

Regards,
Bill



From owner-mpls@UU.NET  Fri Aug 24 10:19:28 2001
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 KAA05516
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 10:19:28 -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 QQldlx04368;
	Fri, 24 Aug 2001 14:20:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldlx11901
	for mpls-outgoing; Fri, 24 Aug 2001 14:20: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 QQldlx11896
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 14:20: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 QQldlx16788
	for <mpls@uu.net>; Fri, 24 Aug 2001 14:19:07 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldlx02578
	for <mpls@uu.net>; Fri, 24 Aug 2001 14:19:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA08900 for mpls@uu.net; Fri, 24 Aug 2001 10:19:05 -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 QQldlx11737
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 14:18:41 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 QQldlx16025
	for <mpls@UU.NET>; Fri, 24 Aug 2001 14:18:34 GMT
Received: from fncomr02.fnc.fujitsu.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fncomr02.fnc.fujitsu.com [167.254.105.20])
	id QQldlx26638
	for <mpls@UU.NET>; Fri, 24 Aug 2001 14:18:33 GMT
Received: from timor.tddny.fujitsu.com (timor.tddny.fujitsu.com [167.254.240.106])
	by fncomr02.fnc.fujitsu.com (Mirapoint)
	with ESMTP id ADF01880;
	Fri, 24 Aug 2001 09:18:31 -0500 (GMT+5)
Received: from pearl340.tddny.fujitsu.com ([167.254.241.86])
          by timor.tddny.fujitsu.com (Netscape Messaging Server 3.6)
           with ESMTP id AAA6AC0; Fri, 24 Aug 2001 10:18:30 -0400
Received: from fnc.fujitsu.com by pearl340.tddny.fujitsu.com (8.8.8+Sun) id KAA29869; Fri, 24 Aug 2001 10:17:43 -0400 (EDT)
Message-ID: <3B866207.151B796C@fnc.fujitsu.com>
Date: Fri, 24 Aug 2001 10:17:43 -0400
From: Ajay Sahai <Ajay.Sahai@fnc.fujitsu.com>
Organization: Fujitsu Network Communications
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Maciek Arkuszewski <markuszewski@ixiacom.com>
CC: mpls@UU.NET
Subject: Re: MPLS frames over Ethernet
References: <9A9C83C019F35D47A570460E87D5D8ABFCC13C@racerx.ixiacom.com>
Content-Type: multipart/alternative;
 boundary="------------FFEDC5AF1AE4882037C5908D"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------FFEDC5AF1AE4882037C5908D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maciek

You could maintain the mapping you are referring to. However in most
scenarios
that I can think of, the MAC address needed by an outgoing frame on a given
interface
will be that of the next node.  So I would guess that an interface to
MAC mapping would suffice.


-Ajay

> Hello.
>
> How exactly is a proper MAC address picked for outgoing frame? Is there an
> additional mapping maintained between labels and ARP table on LSR?
>
> Maciek Arkuszewski
> Senior Software Engineer
> Ixia
> <mailto:maciek@ixiacom.com>
> Tel: (818)444-2305
>
>       Ixia...
>              When the test really counts.
>

--
Ajay Sahai, Fujitsu Network Communication Inc.,
Two Blue Hill Plaza, P.O. Box 1609, Pearl River, NY 10965
Tel: +845-731-2023 (W) Fax: +845-731-2011
E-Mail: Ajay.Sahai@fnc.fujitsu.com



--------------FFEDC5AF1AE4882037C5908D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Maciek
<p>You could maintain the mapping you are referring to. However in most
scenarios
<br>that I can think of, the MAC address needed by an outgoing frame on
a given interface
<br>will be that of the next node.&nbsp; So I would guess that an interface
to MAC&nbsp;mapping would suffice.
<br>&nbsp;
<p>-Ajay
<blockquote TYPE=CITE>Hello.
<p>How exactly is a proper MAC address picked for outgoing frame? Is there
an
<br>additional mapping maintained between labels and ARP table on LSR?
<p>Maciek Arkuszewski
<br>Senior Software Engineer
<br>Ixia
<br>&lt;<a href="mailto:maciek@ixiacom.com">mailto:maciek@ixiacom.com</a>>
<br>Tel: (818)444-2305
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ixia...
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
When the test really counts.
<br>&nbsp;</blockquote>

<pre>--&nbsp;
Ajay Sahai, Fujitsu Network Communication Inc.,&nbsp;
Two Blue Hill Plaza, P.O. Box 1609, Pearl River, NY 10965&nbsp;
Tel: +845-731-2023 (W) Fax: +845-731-2011
E-Mail: Ajay.Sahai@fnc.fujitsu.com</pre>
&nbsp;</html>

--------------FFEDC5AF1AE4882037C5908D--



From owner-mpls@UU.NET  Fri Aug 24 12:04:32 2001
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 MAA08192
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 12:04:32 -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 QQldme18377;
	Fri, 24 Aug 2001 16:05:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldme19359
	for mpls-outgoing; Fri, 24 Aug 2001 16:05:18 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 QQldme19350
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 16:05: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 QQldme23488
	for <mpls@UU.NET>; Fri, 24 Aug 2001 16:05:04 GMT
Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: entmail.gnilink.net [199.45.47.10])
	id QQldme13121
	for <mpls@UU.NET>; Fri, 24 Aug 2001 16:05:05 GMT
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <RPCT0KT0>; Fri, 24 Aug 2001 12:05:04 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDD82@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'Sanford, Bill'" <bill.sanford@netplane.com>,
        "Martin, Christian"
	 <cmartin@gnilink.net>,
        "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: RSVP Hello
Date: Fri, 24 Aug 2001 12:05:03 -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


> That sounds like a RSVP-TE that wants to be LDP. RSVP doesn't 
> do this. Why
> have LDP if RSVP is going to behave like it.

Bill, I'm not sure I'd go that far. ;)  Adding neighbor discovery does not
completely warp the protocol.  Some may say (read: me) that it enhances it.

> Adding more confusion to who is going to do what, when, and 
> how it will
> interoperate with RSVP (not-TE) and the omnipotent "cloud" 
> brings another
> level of frustration to the already miniscule timelines of project
> completion. But, maybe it's just me. I cringe every time I 
> hear "It will be
> easy to add this fuctionality" or "how hard can this be?" 

I apologize for trivializing the complexity of implementing _anything_ that
adds functionality outside the original spirit of the protocol.  I agree
that this is often the cause of many problems with software stability on
today's implementations - hacks for customers that aren't properly thought
out by those who haven't followed the implementation and design of the
protocol from the beginning.  But we are talking about RSVP-TE here, which
has been extended to support new functionality that was outside the scope of
its original design.

Perhaps this has been discussed before (I need to review the archives -
apologies if it has), but IMHO, a distributed control plane that is
non-verifiable during configuration is inadvisable.  Imagine IP without
ICMP, on an Dual IS-IS network.  The core of the network could be IP-less,
and in theory, the IP-enabled edges would have  a path to each other.  But
packets would not flow.  Just having an end-to-end IP path does not mean
that RSVP messages can get through the network end-to-end, and there is no
easy way to detect the location of the hole.

> 
> You can always submit a draft. ;-)

Good idea!

> 
> Regards,
> Bill
> 


From owner-mpls@UU.NET  Fri Aug 24 12:57:42 2001
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 MAA09510
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 12:57:42 -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 QQldmh27275;
	Fri, 24 Aug 2001 16:58:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldmh04426
	for mpls-outgoing; Fri, 24 Aug 2001 16:58:30 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 QQldmh04398
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 16:58: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 QQldmh25282
	for <mpls@UU.NET>; Fri, 24 Aug 2001 16:57:49 GMT
From: neil.2.harrison@bt.com
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 QQldmh12518
	for <mpls@UU.NET>; Fri, 24 Aug 2001 16:57:49 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <RL28THRM>; Fri, 24 Aug 2001 17:58:02 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E89164B@mbddmknt01.hc.bt.com>
To: bill.sanford@netplane.com, cmartin@gnilink.net, mpls@UU.NET
Subject: RE: RSVP Hello
Date: Fri, 24 Aug 2001 17:57:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bill/Martin,

Noting your comment (Bill) on cringing when you hear "It will be easy to add
this fuctionality" or "how hard can this be?", I cringe myself when I see
architectural kludges, and this thread has more than a whiff of these.....so
let me add my 2 cents (with a slightly different slant...so please bear with
me):

Each protocol provides specific functionality (otherwise why have it?).
Hence, by inference, each protocol will have it own specific failure modes,
and thus require its own specific OAM mechanism.  So whether we are talking
about RSVP, LDP, OSPF, BGP4, etc this applies, and the RFCs that specify
these protocols do indeed have such OAM functionality defined in them.

Now each of these protocols gets transported between the nodes (and their
respective functional processes therein) via data-plane trails of some
description, eg SDH VC-4s, ATM VPs/VCs, MPLS LSPs, etc as appropriate for
the network situation considered.

In the case of a true cnls-only layer network then all the above protocols
go hop-by-hop via IP.  So, since one can say there is always topological
congruence between the data-plane and the control-plane protocols in this
case, then one could allow control-plane protocols to proxy for detecting
data-plane failures.......but there will still be (more general) nodal or
specific protocol failure modes where the specific control-protocol OAM is
needed anyway.

When we consider co fabrics one cannot always guarantee there will be
data-plane and control-plane protocol topological congruence.  Indeed, it is
usually far more efficient if they are not topologically congruent.  This
should be obvious to those working on GMPLS, as indeed it has been obvious
to those in the Telecoms industry for a long time.  Hence, the data-plane
that carries the customer traffic is likely to be different topologically
(and maybe even technologically) to the data-plane that carries the
control-plane protocols (or indeed the management-plane protocols...and
there is actually no need for these to use the same data-plane as the
control-plane protocols;  especially if one wants a very robust network
architecture such that the management-plane is completely isolated from the
control-plane protocols, eg to protect against some pathological failure
mode of a control-plane protocol).  A further point here is that the
data-plane OAM is relevant only to the layer network considered (ie SDH/VC4
OAM functionality is different to ATM/VP OAM functionality is different to
MPLS/LSP OAM functionality, is different to IP/ICMP OAM functionality,
etc.), and it must never be dependent of some other specific client or
server layer network OAM. 

The above is really common sense, but we need this architectural discipline
in order to allow:
(i) configuration flexibility (eg data/control/management plane config or
the protocol choices therein);
(ii) consistent data-plane interworking with operational support systems
irrespective of control-plane protocols used (eg consistent fault
management, SLA verification, billing);
(iii) future development independence of data/control/management-plane
protocols (ie add/change/remove).

So, for example, whether I run layer network technology 'X' using RSVP-TE,
CR-LDP, PNNI, sig_prot_Y or indeed *no* signalling protocols I want the OAM
for the data-plane trails that carry the customer traffic to be independent
of the signalling protocol choice. This will be true in the case of SDH VC-4
trails say, but it is unfortunately not true for MPLS LSPs since we don't
have any decent MPLS data-plane OAM agreed yet.

This mail thread is mixing different signalling protocol functionality as
proxies for data-plane failures, and a previous discussion on the
draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
principle by binding specific client/server layer OAM functionality to a
specific control-plane signalling protocol.

During the discussion of the Ping draft, I know Yakov described what I have
discussed above as 'working on LTSFGTC' (long-term solutions for generations
to come)...or something like that......but if we want MPLS itself to be a
LTSFGTC (and hopefully also give some solid foundation for those working in
the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
architectural tenets right at the outset.  Proper data-plane OAM, and its
decoupling from other client/server layer data-planes and/or specific
control (or management) plane protocols is not a 'luxury item', its just
plain common sense to avoid problems down the road.

regards, Neil
> -----Original Message-----
> From: Sanford, Bill [mailto:bill.sanford@netplane.com]
> Sent: 24 August 2001 14:27
> To: 'Martin, Christian'; Sanford, Bill; 'mpls@UU.NET'
> Subject: RE: RSVP Hello
> 
> 
> > -----Original Message-----
> > From: Martin, Christian [mailto:cmartin@gnilink.net]
> > Sent: Thursday, August 23, 2001 6:42 PM
> > To: 'Sanford, Bill'; 'mpls@UU.NET'
> > Subject: RE: RSVP Hello
> > 
> > 
> > If I may comment here from an operational perspective...
> > 
> > I think the Hello mechanism, as specified, could be extended 
> > to occur upon
> > link initialization.  One of my most frustrating experiences 
> > with RSVP state
> > was when a new link was turned up with a fat-fingered 
> > authentication key.
> > Since there is no initial RSVP state acorss the link until a 
> > PATH message
> > needs to be sent, I was unaware of it until I had to 
> > troubleshoot a label
> > request across 13 routers.  Were it part of the 
> specification to send
> > Hello's and build an adjaceny during link intialization, it 
> > would have been
> > something detectable during configuration.
> 
> That sounds like a RSVP-TE that wants to be LDP. RSVP doesn't 
> do this. Why
> have LDP if RSVP is going to behave like it.
> 
> > Perhaps the draft can be extended to address this operational 
> > need?  How
> > difficult would it be to add:
> > 
> > "Upon link initialization, an interface MAY/SHOULD 
> > immediately send an RSVP
> > hello to the all routers multicast address on broadcast 
> > media, or to its
> > direct neighbor on ptp media.  For each RSVP hello received, 
> > record the
> > source IP address in the RSVP adjacency table.  Transmit 
> hello's every
> > configurable interval."
> 
> Adding more confusion to who is going to do what, when, and 
> how it will
> interoperate with RSVP (not-TE) and the omnipotent "cloud" 
> brings another
> level of frustration to the already miniscule timelines of project
> completion. But, maybe it's just me. I cringe every time I 
> hear "It will be
> easy to add this fuctionality" or "how hard can this be?" 
> 
> > Of course, this example discusses authenticated RSVP 
> > messages, but other
> > types of issues can impair RSVP without easy detection.  As 
> > it is today, you
> > can either send a test PATH message across the network to 
> > build state, or
> > you can hope it works when you need it.  Neither is operationally
> > acceptable, IMHO.
> 
> You can always submit a draft. ;-)
> 
> Regards,
> Bill
> 


From owner-mpls@UU.NET  Fri Aug 24 13:53:43 2001
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 NAA10890
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 13:53:43 -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 QQldml00935;
	Fri, 24 Aug 2001 17:54:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldml28439
	for mpls-outgoing; Fri, 24 Aug 2001 17:54: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 QQldml28433
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 17:54:25 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 QQldml17440
	for <mpls@UU.NET>; Fri, 24 Aug 2001 17:52:26 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 QQldml15489
	for <mpls@UU.NET>; Fri, 24 Aug 2001 17:52:26 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 NAA29147
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:52:23 -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 NAA06878
	for <mpls@UU.NET>; Fri, 24 Aug 2001 13:52:25 -0400 (EDT)
Message-ID: <3B869457.44C2C080@marconi.com>
Date: Fri, 24 Aug 2001 13:52:23 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: MPLS frames over Ethernet
References: <9A9C83C019F35D47A570460E87D5D8ABFCC13C@racerx.ixiacom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Maciek Arkuszewski wrote:
> 
> How exactly is a proper MAC address picked for outgoing frame? Is
> there an additional mapping maintained between labels and ARP table
> on LSR?

Obviously, the MAC address chosen would have to be the address of the
next-hop router.  The IP address of this router should already be known
(learned as a part of signaling), so an ARP should easily be doable if
the address is unknown.

-- David


From owner-mpls@UU.NET  Fri Aug 24 15:30:40 2001
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 PAA13388
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 15:30:39 -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 QQldms11471;
	Fri, 24 Aug 2001 19:31:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldms16699
	for mpls-outgoing; Fri, 24 Aug 2001 19:31: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 QQldms16692
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 19:31:10 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 QQldms00021
	for <mpls@uu.net>; Fri, 24 Aug 2001 19:30:55 GMT
Received: from nwds0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwds0102a.jc.digitran.com [165.251.28.23])
	id QQldms10232
	for <mpls@uu.net>; Fri, 24 Aug 2001 19:30:56 GMT
Received: from csrinivasan [12.34.209.74] by nwds0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Fri, 24 Aug 2001 15:25:55 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'MPLS Mailing List \(E-mail\)'" <mpls@UU.NET>
Subject: draft-ietf-mpls-te-mib-07.txt posted
Date: Fri, 24 Aug 2001 15:43:25 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB124@OPTONT>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0003_01C12CB1.E1BCE0D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <176689DD1922D511ABE10001022E4DF20AB0E9@OPTONT>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C12CB1.E1BCE0D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have just posted draft-ietf-mpls-te-mib-07.txt and it
should appear on the IETF site shortly. A copy is attached.

Cheenu Srinivasan


------=_NextPart_000_0003_01C12CB1.E1BCE0D0
Content-Type: text/plain;
	name="draft-ietf-mpls-te-mib-07.txt"
Content-Disposition: attachment;
	filename="draft-ietf-mpls-te-mib-07.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                               Cheenu Srinivasan
Internet Draft                                          Alphion Corp.
Expires: February 2002                                              =20
                                                     Arun Viswanathan
                                               Force10 Networks, Inc.
                                                                    =20
                                                     Thomas D. Nadeau
                                                  Cisco Systems, Inc.
                                                                    =20
                                                          August 2001
                              =20
                              =20
   Multiprotocol Label Switching (MPLS) Traffic Engineering
                  Management Information Base
                              =20
                 draft-ietf-mpls-te-mib-07.txt


Status of this Memo
  =20
   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026
   [RFC2026].
  =20
   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.


Table of Contents

   Abstract ................................................ 2
   1. Introduction ......................................... 2
   2. Terminology .......................................... 2
   3. The SNMP Management Framework ........................ 3
   4. Feature List ......................................... 4
   5. Outline .............................................. 4
    5.1. Summary of Traffic Engineering MIB ................ 5
   6. Brief Description of MIB Objects ..................... 5
    6.1. mplsTunnelTable ................................... 5
    6.2. mplsTunnelResourceTable ........................... 6



Srinivasan et al.            Expires February 2002           [Page 1]
=0C
Internet Draft                 MPLS TE MIB                August 2001



    6.3. mplsTunnelHopTable ................................ 6
    6.4. mplsTunnelARHopTable .............................. 6
    6.5. mplsTunnelCHoptable ............................... 6
    6.6. mplsTunnelPerfTable ............................... 6
    6.7. mplsTunnelCRLDPResTable ........................... 7
   7. Application of the Interface Group to MPLS Tunnels ... 7
    7.1. Support of the MPLS Tunnel Interface by ifTable ... 8
   8. Example of Tunnel Setup .............................. 9
   9. The Use of RowPointer ............................... 11
   10. MPLS Traffic Engineering MIB Definitions ........... 11
   11. Security Considerations ............................ 60
   12. Acknowledgments .................................... 61
   13. References ......................................... 61
   14. Authors' Addresses ................................. 64
   15. Full Copyright Statement ........................... 64
  =20


Abstract
  =20
   This memo defines an experimental portion of the Management
   Information Base  (MIB) for use with network management
   protocols in the Internet community.  In particular, it
   describes managed objects for Multi-Protocol Label
   Switching (MPLS) [RFC3031] based traffic engineering.


1. Introduction
  =20
   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management
   protocols in the Internet community. In particular, it
   describes managed objects for modeling a Multi-Protocol
   Label Switching (MPLS) [RFC3031] based traffic engineering.
   This MIB should be used in conjunction with the companion
   document [LSRMIB] for MPLS based traffic engineering
   configuration and management.
  =20
   Comments should be made directly to the MPLS mailing list
   at mpls@uu.net.
  =20
   This memo does not, in its draft form, specify a standard
   for the Internet community.


2. Terminology
  =20
   This document uses terminology from the MPLS architecture
   document [RFC3031] and MPLS Label Switch Router MIB
   [LSRMIB]. Some frequently used terms are described next.



Srinivasan et al.            Expires February 2002           [Page 2]
=0C
Internet Draft                 MPLS TE MIB                August 2001



  =20
   An explicitly routed LSP (ERLSP) is referred to as an MPLS
   tunnel.  It consists of one in-segment and/or one out-
   segment at the ingress/egress LSRs, each segment being
   associated with one MPLS interface.  These are also
   referred to as tunnel segments.  Additionally, at an
   intermediate LSR, we model a connection as consisting of
   one or more in-segments and/or one or more out-segments.
   The binding or interconnection between in-segments and out-
   segments in performed using a cross-connect. These objects
   are defined in the MPLS Label Switch Router MIB [LSRMIB].


3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five
   major components:
  =20
   -  An overall architecture, described in RFC 2571
      [RFC2571].
  =20
   -  Mechanisms for describing and naming objects and events
      for the purpose of management.  The first version of
      this Structure of Management Information (SMI) is
      called SMIv1 and described in STD 16, RFC 1155
      [RFC1155], STD 16, RFC 1212 [RFC1212] and STD 16, RFC
      1215 [RFC1215].  The second version, called SMIv2, is
      described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
      2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
  =20
   -  Message protocols for transferring management
      information.  The first version of the SNMP message
      protocol is called SNMPv1 and described in STD 15, RFC
      1157 [RFC1157].  A second version of the SNMP message
      protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901
      [RFC1901] and RFC 1906 [RFC1906].  The third version of
      the message protocol is called SNMPv3 and described in
      RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
      [RFC2574].
  =20
   -  Protocol operations for accessing management
      information.  The first set of protocol operations and
      associated PDU formats is described in STD 15, RFC 1157
      [RFC1157].  A second set of protocol operations and
      associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2573
      [RFC2573] and the view-based access control mechanism



Srinivasan et al.            Expires February 2002           [Page 3]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      described in RFC 2575 [RFC2575].
  =20
   A more detailed introduction to the current SNMP Management
   Framework can be found in RFC 2570 [RFC2570].
  =20
   Managed objects are accessed via a virtual information
   store, termed the Management Information Base or MIB.
   Objects in the MIB are defined using the mechanisms defined
   in the SMI.
  =20
   This memo specifies a MIB module that is compliant to the
   SMIv2.  A MIB conforming to the SMIv1 can be produced
   through the appropriate translations.  The resulting
   translated MIB must be semantically equivalent, except
   where objects or events are omitted because no translation
   is possible (use of Counter64).  Some machine-readable
   information in SMIv2 will be converted into textual
   descriptions in SMIv1 during the translation process.
   However, this loss of machine-readable information is not
   considered to change the semantics of the MIB.


4. Feature List
  =20
   The MPLS traffic engineering MIB is designed to satisfy the
   following requirements and constraints.
  =20
   -  The MIB supports configuration of point-to-point
      unidirectional tunnels.
  =20
   -  MPLS tunnels need not be interfaces, but it is possible
      to configure a tunnel as an interface.
  =20
   -  The MIB supports manually configured MPLS tunnels as
      well as those set up via an MPLS signaling protocol.
  =20
   -  The MIB supports persistent as well as non-persistent
      tunnels.


5. Outline
  =20
   Traffic engineering support for MPLS tunnels requires the
   following configuration.
  =20
   -  Setting up MPLS tunnels along with appropriate
      configuration parameters.
  =20
   -  Configuring tunnel loose and strict source routed hops.
  =20



Srinivasan et al.            Expires February 2002           [Page 4]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   These actions may need to be accompanied with corresponding
   actions using [LSRMIB] to establish and configure tunnel
   segments, if this is done manually. Also, the in-segment
   and out-segment performance tables, mplsInSegmentPerfTable
   and mplsOutSegmentPerfTable [LSRMIB], should be used to
   determine performance of the tunnels and tunnel segments.


5.1.  Summary of Traffic Engineering MIB
  =20
   The MIB objects for performing these actions consist of the
   following tables.
  =20
   -  Tunnel table (mplsTunnelTable) for setting up MPLS
      tunnels.
  =20
   -  Resource table (mplsTunnelResourceTable) for setting up
      the tunnel resources.
  =20
   -  Tunnel specified, actual, and computed hop tables
      (mplsTunnelHopTable, mplsTunnelARHopTable, and
      mplsTunnelCHopTable) for strict and loose source routed
      MPLS tunnel hops.
  =20
   -  CRLDP resource table (mplsTunnelCRLDPResTable) for
      specifying resource objects applicable to tunnels
      signaled using CRLDP.
  =20
   These tables are described in the subsequent sections.


6. Brief Description of MIB Objects
  =20
   The objects described in this section support the
   functionality described in documents [RSVPTE] and [CRLDP].
   The tables support both manually configured and signaled
   tunnels.


6.1.  mplsTunnelTable
  =20
   The mplsTunnelTable allows new MPLS tunnels to be created
   between an MPLS LSR and a remote endpoint, and existing
   tunnels to be reconfigured or removed.  Note that we only
   support point-to-point tunnel segments, although multi-
   point-to-point and point-to-multi-point connections are
   supported by an LSR acting as a cross-connect.  Each MPLS
   tunnel can thus have one out-segment originating at an LSR
   and/or one in-segment terminating at that LSR.
  =20



Srinivasan et al.            Expires February 2002           [Page 5]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   mplsTunnelTable does not define the in and out segments
   forming the tunnel.  Instead, these are defined by creating
   rows in the in-segment and out-segment tables, defining
   relationships in the cross-connect table and referring to
   these rows in the mplsTunnelTable using a cross-connect
   index, mplsTunnelXCIndex. These segment and cross-connect
   related objects are defined in [LSRMIB].


6.2.  mplsTunnelResourceTable
  =20
   mplsTunnelResourceTable is used to indicate the resources
   required for a tunnel. Multiple tunnels may share the same
   resources by pointing to the same entry in this table.
   Tunnels that do not share resources must point to separate
   entries in this table.


6.3.  mplsTunnelHopTable
  =20
   mplsTunnelHopTable is used to indicate the hops, strict or
   loose, for an MPLS tunnel defined in mplsTunnelTable, when
   it is established via signaling.  Multiple tunnels may
   share the same hops by pointing to the same entry in this
   table. Each row also has a secondary index,
   mplsTunnelHopIndex, corresponding to the next hop of this
   tunnel.  The scalar mplsTunnelMaxHops indicates the maximum
   number of hops that can be specified on each tunnel
   supported by this LSR.


6.4.  mplsTunnelARHopTable
  =20
   mplsTunnelARHopTable is used to indicate the actual hops
   traversed by a tunnel as reported by the MPLS signaling
   protocol after the tunnel is setup.  The support of this
   table is optional since not all MPLS signaling protocol may
   support this feature.


6.5.  mplsTunnelCHoptable
  =20
   mplsTunnelCHopTable lists the actual hops computed by a
   constraint-based routing algorithm based on the
   mplsTunnelHopTable.  The support of this table is optional
   since not all implementations may support computation of
   hop list using a constraint-based routing protocol.


6.6.  mplsTunnelPerfTable



Srinivasan et al.            Expires February 2002           [Page 6]
=0C
Internet Draft                 MPLS TE MIB                August 2001



  =20
   mplsTunnelPerfTable provides several counters to measure
   the performance of the MPLS tunnels.  This table augments
   mplsTunnelTable.


6.7.  mplsTunnelCRLDPResTable
  =20
   mplsTunnelCRLDPResTable contains resource information for
   those tunnels that are signaled using CRLDP [CRLDP]. This
   is a sparse extension to mplsTunnelResourceTable and is
   also indexed by mplsTunnelResourceIndex. As with
   mplsTunnelResourceTable, multiple tunnels may share the
   same resources by pointing to the same entry in this table.
   Tunnels that do not share resources must point to separate
   entries in this table.


7. Application of the Interface Group to MPLS Tunnels
  =20
   The Interfaces Group of MIB II defines generic managed
   objects for managing interfaces.  This memo contains the
   media-specific extensions to the Interfaces Group for
   managing MPLS Tunnels as logical interfaces.
  =20
   This memo assumes the interpretation of the Interfaces
   Group to be in accordance with [RFC2233] which states that
   the interfaces table (ifTable) contains information on the
   managed resource's interfaces and that each sub-layer below
   the internetwork layer of a network interface is considered
   an interface.  Thus, the MPLS interface is represented as
   an entry in the ifTable.  The interrelation of entries in
   the ifTable is defined by the Interfaces Stack Group
   defined in [RFC2233].
  =20
   When using MPLS Tunnels as interfaces, the interface stack
   table might appear as follows:
  =20
        +------------------------------------------------+
        | MPLS tunnel interface ifType =3D mplsTunnel(150) |
        +------------------------------------------------+
        |        MPLS interface ifType =3D mpls(166)       |
        +------------------------------------------------+
        |               Underlying layer                 |
        +------------------------------------------------+
  =20
  =20
   In the above diagram, "Underlying Layer" refers to the
   ifIndex of any interface type, which has been defined for
   MPLS interworking.  Examples include ATM, Frame Relay, and



Srinivasan et al.            Expires February 2002           [Page 7]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   Ethernet.


7.1.  Support of the MPLS Tunnel Interface by ifTable
  =20
   Some specific interpretations of ifTable for those MPLS
   tunnels represented as interfaces follow:
  =20
   Object             Use for the MPLS tunnel.
  =20
   ifIndex            Each MPLS tunnel is represented by an
                      ifEntry.
  =20
   ifDescr            Description of the MPLS tunnel.
  =20
   ifType             The value that is allocated for MPLS
                      tunnel is 150.
  =20
   ifSpeed            The total bandwidth in bits per second
                      for use by the MPLS tunnel.
  =20
   ifPhysAddress      Unused.
  =20
   ifAdminStatus      See [RFC2233].
  =20
   ifOperStatus       Assumes the value down(2) if the MPLS
                      tunnel  is down.
  =20
   ifLastChange       See [RFC2233].
  =20
   ifInOctets         The number of octets received over the
                      MPLS tunnel.
  =20
   ifOutOctets        The number of octets transmitted over
                      the MPLS tunnel.
  =20
   ifInErrors         The number of labeled packets dropped
                      due to uncorrectable errors.
  =20
   ifInUnknownProtos  The number of received packets
                      discarded during packet header
                      validation, including packets with
                      unrecognized label values.
  =20
   ifOutErrors        See [RFC2233].
  =20
   ifName             Textual name (unique on this system) of
                      the MPLS tunnel or an octet string of
                      zero length.
  =20



Srinivasan et al.            Expires February 2002           [Page 8]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   ifLinkUpDownTrapEnable
                      Default is disabled (2).
  =20
   ifConnectorPresent Set to false (2).
  =20
   ifHighSpeed        See [RFC2233].
  =20
   ifHCInOctets       The 64-bit version of ifInOctets;
                      supported if required by the compliance
                      statements in [RFC2233].
  =20
   ifHCOutOctets      The 64-bit version of ifOutOctets;
                      supported if required by the compliance
                      statements in [RFC2233].
  =20
   ifAlias            The non-volatile 'alias' name for the
                      MPLS tunnel as specified by a network
                      manager.


8. Example of Tunnel Setup

   This section contains an example of which MIB objects
   should be modified if one would like to create a best
   effort, loosely routed, unidirectional traffic engineered
   tunnel, which spans two hops of a simple network. Note
   that these objects should be created on the "head-end"
   LSR.
  =20
   In mplsTunnelTable:
   {
     mplsTunnelIndex              =3D 1,
     mplsTunnelInstance           =3D 1,
     mplsTunnelIngressLSRId       =3D 123.123.125.1,
     mplsTunnelEgressLSRId        =3D 123.123.126.1,
     mplsTunnelName               =3D "My first tunnel",
     mplsTunnelDescr              =3D "Here to there",
     mplsTunnelIsIf               =3D true (1),
     mplsTunnelXCPointer          =3D mplsXCIndex.2.0.0.15,
     mplsTunnelSignallingProto    =3D none (1),
     mplsTunnelSetupPrio          =3D 0,
     mplsTunnelHoldingPrio        =3D 0,
     mplsTunnelSessionAttributes  =3D 0,
     mplsTunnelOwner              =3D snmp (1),
     mplsTunnelLocalProtectInUse  =3D false (0),
     mplsTunnelResourcePointer    =3D mplsTunnelResourceIndex.5,
     mplsTunnelInstancePriority   =3D 1,
     mplsTunnelHopTableIndex      =3D 1,
     mplsTunnelPrimaryInstance    =3D 0,
     mplsTunnelIncludeAnyAffinity =3D 0,



Srinivasan et al.            Expires February 2002           [Page 9]
=0C
Internet Draft                 MPLS TE MIB                August 2001



     mplsTunnelIncludeAllAffinity =3D 0,
     mplsTunnelExcludeAllAffinity =3D 0,
     mplsTunnelPathInUse          =3D 1,
     mplsTunnelRole               =3D head(1),
     mplsTunnelRowStatus          =3D createAndGo (4)
   }
  =20
   In mplsTunnelResourceTable:
   {
     mplsTunnelResourceIndex           =3D 5,
     mplsTunnelResourceMaxRate         =3D 0,
     mplsTunnelResourceMeanRate        =3D 0,
     mplsTunnelResourceMaxBurstSize    =3D 0,
     mplsTunnelResourceRowStatus       =3D createAndGo (4)
   }
  =20
   The next two instances of mplsTunnelHopEntry are used to
   denote the hops this tunnel will take across the network.
  =20
   The following denotes the beginning of the network, or the
   first hop. We have used the fictitious LSR identified by
   "123.123.125.1" as our example head-end router.
  =20
   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex          =3D 1,
     mplsTunnelPathOptionIndex       =3D 1,
     mplsTunnelHopIndex              =3D 1,
     mplsTunnelHopAddrType           =3D 1,
     mplsTunnelHopIpv4Addr           =3D 123.123.125.1,
     mplsTunnelHopIpv4PrefixLen      =3D 9,
     mplsTunnelHopType               =3D loose (2),
     mplsTunnelHopRowStatus          =3D createAndGo (4)
   }
  =20
   The following denotes the end of the network, or the last
   hop in our example. We have used the fictitious LSR
   identified by "123.123.126.1" as our end router.
  =20
   In mplsTunnelHopTable:
   {
     mplsTunnelHopListIndex          =3D 1,
     mplsTunnelPathOptionIndex       =3D 1,
     mplsTunnelHopIndex              =3D 2,
     mplsTunnelHopAddrType           =3D 1,
     mplsTunnelHopIpv4Addr           =3D 123.123.126.1,
     mplsTunnelHopIpv4PrefixLen      =3D 9,
     mplsTunnelHopType               =3D loose (2),
     mplsTunnelHopRowStatus          =3D createAndGo (4)
   }



Srinivasan et al.           Expires February 2002           [Page 10]
=0C
Internet Draft                 MPLS TE MIB                August 2001





9. The Use of RowPointer
  =20
   RowPointer is a textual convention used to identify a
   conceptual row in an SNMP Table by pointing to one of its
   objects.  In this MIB, in mplsTunnelTable, the objects
   mplsTunnelXCPointer and mplsTunnelResourcePointer are of
   type RowPointer.  The object mplsTunnelXCPointer points to
   a specific entry in the mplsXCTable [LSRMIB].  This entry
   in the mplsXCTable is the associated LSP for the given MPLS
   tunnel entry.  The object mplsTunnelResourcePointer points
   to a specific entry in a traffic parameter table.  An
   example of such a traffic parameter table is
   mplsTunnelResourceTable.  It indicates a specific instance
   of a traffic parameter entry that is associated with a
   given MPLS tunnel entry.


10.   MPLS Traffic Engineering MIB Definitions

MPLS-TE-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   experimental, Integer32, Unsigned32, Counter32,
   Counter64, TimeTicks
      FROM SNMPv2-SMI
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
      FROM SNMPv2-CONF
   TEXTUAL-CONVENTION, TruthValue, RowStatus, RowPointer,
   StorageType, DisplayString, TimeStamp
      FROM SNMPv2-TC
   InterfaceIndexOrZero
      FROM IF-MIB
   MplsBitRate, MplsBurstSize, MplsLSPID,
   MplsTunnelIndex, MplsTunnelInstanceIndex,
   MplsTunnelAffinity, MplsLsrIdentifier, MplsPathIndex,
   MplsPathIndexOrZero
      FROM MPLS-TC-MIB
   InetAddressIPv4, InetAddressIPv6
      FROM INET-ADDRESS-MIB
   ;

mplsTeMIB MODULE-IDENTITY
   LAST-UPDATED
      "200108241200Z" -- August 24, 2001 12:00:00 GMT
   ORGANIZATION
      "Multiprotocol Label Switching (MPLS) Working Group"
   CONTACT-INFO



Srinivasan et al.           Expires February 2002           [Page 11]
=0C
Internet Draft                 MPLS TE MIB                August 2001



        "
                 Cheenu Srinivasan
         Postal: Alphion Corp.
                 4 Industrial Way West
                 Eatontown, NJ 07724
         Tel:    +1-732-676-7066
         Email:  cheenu@alphion.com
       =20
                 Arun Viswanathan
         Postal: Force10 Networks, Inc.
                 1440 McCarthy Blvd
                 Milpitas, CA 95035
         Tel:    +1-408-571-3516
         Email:  arun@force10networks.com
       =20
                 Thomas D. Nadeau
         Postal: Cisco Systems, Inc.
                 250 Apollo Drive
                 Chelmsford, MA 01824
         Tel:    +1-978-244-3051
         Email:  tnadeau@cisco.com
       =20
        "
   DESCRIPTION
        "This MIB module contains managed object definitions
          for MPLS Traffic Engineering (TE) as defined in:
         1. Extensions to RSVP for LSP Tunnels, Awduche et
          al, Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-
          08.txt>, February 2001
         2. Constraint-Based LSP Setup using LDP, B. Jamoussi
          (Editor), Internet Draft <draft-ietf-mpls-cr-ldp-
          05.txt>, February 2001
         3. Requirements for Traffic Engineering Over MPLS,
          Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.,
          and J. McManus, RFC 2702, September 1999"
       =20
  =20
   -- Revision history.
  =20
   REVISION
        "200108241200Z"  -- 24 August 2001 12:00:00 GMT
   DESCRIPTION
        "Removed SMIv2 from title. Upgraded SNMP boilerplate.
          Updated references to reflect this change. Removed
          TCs; Updated IMPORTS clause to import them from
          MPLS TC MIB. Updated author contact information.
          Introduced a TOC."
   REVISION
        "200103021200Z"  -- 2 March 2001 12:00:00 GMT
   DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 12]
=0C
Internet Draft                 MPLS TE MIB                August 2001



        "Updates based on MPLS WG last call feedback."
   REVISION
        "200011211200Z"  -- 21 November 2000 12:00:00 GMT
   DESCRIPTION
        "Updates based on MPLS WG feedback."
   REVISION
        "200007141200Z"  -- 14 July 2000 12:00:00 GMT
   DESCRIPTION
        "Updates based on MPLS WG feedback."
   REVISION
        "200005261200Z"  -- 26 May 2000 12:00:00 GMT
   DESCRIPTION
        "Updates based on MPLS WG feedback."
   REVISION
        "200003031200Z"  -- 3 March 2000 12:00:00 GMT
   DESCRIPTION
        "Updates based on MPLS WG feedback."
   REVISION
        "199907161200Z"  -- 16 July 1999 12:00:00 GMT
   DESCRIPTION
        "Initial draft version."
  =20
   ::=3D { experimental 95 }

-- Top level components of this MIB.

-- tables, scalars
mplsTeScalars       OBJECT IDENTIFIER ::=3D { mplsTeMIB 1 }
mplsTeObjects       OBJECT IDENTIFIER ::=3D { mplsTeMIB 2 }

-- traps
mplsTeNotifications OBJECT IDENTIFIER ::=3D { mplsTeMIB 3 }
mplsTeNotifyPrefix  OBJECT IDENTIFIER ::=3D { mplsTeNotifications 0 }

-- conformance
mplsTeConformance   OBJECT IDENTIFIER ::=3D { mplsTeMIB 4 }


-- MPLS Tunnel scalars.

mplsTunnelConfigured OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "The number of tunnels configured on this device. A
          tunnel is considered configured if the
          mplsTunnelRowStatus is active(1)."
   ::=3D { mplsTeScalars 1 }




Srinivasan et al.           Expires February 2002           [Page 13]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelActive OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "The number of tunnels active on this device. A
          tunnel is considered active if the
          mplsTunnelOperStatus is up(1)."
   ::=3D { mplsTeScalars 2 }

mplsTunnelTEDistProto OBJECT-TYPE
   SYNTAX        BITS {
          other (0),
          ospf (1),
          isis (2)
      }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "The traffic engineering distribution protocol(s)
          used by this LSR. Note that an LSR may support more
          than one distribution protocol simultaneously."
   ::=3D { mplsTeScalars 3 }

mplsTunnelMaxHops OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "The maximum number of hops that can be specified for
          a tunnel on this device."
   ::=3D { mplsTeScalars 4 }

-- End of MPLS Tunnel scalars.


-- MPLS tunnel table.

mplsTunnelIndexNext OBJECT-TYPE
   SYNTAX        Integer32 (0..65535)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "This object contains the next appropriate value to
          be used for mplsTunnelIndex when creating entries
          in  mplsTunnelTable. If the number of unassigned
          entries is exhausted, a retrival operation will
          return a value of 0.  This object may also return a
          value of 0 when the LSR is unable to accept
          conceptual row creation, for example, if the



Srinivasan et al.           Expires February 2002           [Page 14]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          mplsTunnelTable is implemented as read-only. To
          obtain the value of mplsTunnelIndex for a new
          entry, the manager must first issue a management
          protocol retrieval operation to obtain the current
          value of this object. The agent should modify the
          value to reflect the next unassigned index after
          each retrieval operation. After a manager retrieves
          a value the agent will determine through its local
          policy when this index value will be made available
          for reuse."
   ::=3D { mplsTeObjects 1 }

mplsTunnelTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The mplsTunnelTable allows new MPLS tunnels to be
          created between an LSR and a remote endpoint, and
          existing tunnels to be reconfigured or removed.
          Note that only point-to-point tunnel segments are
          supported, although multi-point-to-point and point-
          to-multi-point connections are supported by an LSR
          acting as a cross-connect.  Each MPLS tunnel can
          thus have one out-segment originating at this LSR
          and/or one in-segment terminating at this LSR."
   ::=3D { mplsTeObjects 2 }

mplsTunnelEntry OBJECT-TYPE
   SYNTAX        MplsTunnelEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents an MPLS tunnel.
          An entry can be created by a network administrator
          or by an SNMP agent as instructed by an MPLS
          signaling protocol. Whenever a new entry is created
          with mplsTunnelIsIf set to true(1), then a
          corresponding entry is created in ifTable as well
          (see RFC 2233). The ifType of this entry is
          mplsTunnel(150)."
   REFERENCE
        "1. RFC 2233 - The Interfaces Group MIB using SMIv2,
          McCloghrie, K., and F. Kastenholtz, Nov. 1997
         2. RFC 1700 - Assigned Numbers, Reynolds, J. and J.
          Postel, Oct. 1994"
   INDEX {
      mplsTunnelIndex,
      mplsTunnelInstance,
      mplsTunnelIngressLSRId,



Srinivasan et al.           Expires February 2002           [Page 15]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      mplsTunnelEgressLSRId
   }
   ::=3D { mplsTunnelTable 1 }

MplsTunnelEntry ::=3D SEQUENCE {
      mplsTunnelIndex              MplsTunnelIndex,
      mplsTunnelInstance           MplsTunnelInstanceIndex,
      mplsTunnelIngressLSRId       MplsLsrIdentifier,
      mplsTunnelEgressLSRId        MplsLsrIdentifier,
      mplsTunnelName               DisplayString,
      mplsTunnelDescr              DisplayString,
      mplsTunnelIsIf               TruthValue,
      mplsTunnelIfIndex            InterfaceIndexOrZero,
      mplsTunnelXCPointer          RowPointer,
      mplsTunnelSignallingProto    INTEGER,
      mplsTunnelSetupPrio          INTEGER,
      mplsTunnelHoldingPrio        INTEGER,
      mplsTunnelSessionAttributes  BITS,
      mplsTunnelOwner              INTEGER,
      mplsTunnelLocalProtectInUse  TruthValue,
      mplsTunnelResourcePointer    RowPointer,
      mplsTunnelInstancePriority   Unsigned32,
      mplsTunnelHopTableIndex      MplsPathIndexOrZero,
      mplsTunnelARHopTableIndex    MplsPathIndexOrZero,
      mplsTunnelCHopTableIndex     MplsPathIndexOrZero,
      mplsTunnelPrimaryInstance    MplsTunnelInstanceIndex,
      mplsTunnelPrimaryTimeUp      TimeTicks,
      mplsTunnelPathChanges        Counter32,
      mplsTunnelLastPathChange     TimeTicks,
      mplsTunnelCreationTime       TimeStamp,
      mplsTunnelStateTransitions   Counter32,
      mplsTunnelIncludeAnyAffinity MplsTunnelAffinity,
      mplsTunnelIncludeAllAffinity MplsTunnelAffinity,
      mplsTunnelExcludeAllAffinity MplsTunnelAffinity,
      mplsTunnelPathInUse          MplsPathIndexOrZero,
      mplsTunnelRole               INTEGER,
      mplsTunnelTotalUpTime        TimeTicks,
      mplsTunnelInstanceUpTime     TimeTicks,
      mplsTunnelAdminStatus        INTEGER,
      mplsTunnelOperStatus         INTEGER,
      mplsTunnelRowStatus          RowStatus,
      mplsTunnelStorageType        StorageType
   }

mplsTunnelIndex OBJECT-TYPE
   SYNTAX        MplsTunnelIndex
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "Uniquely identifies this row."



Srinivasan et al.           Expires February 2002           [Page 16]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   ::=3D { mplsTunnelEntry 1 }

mplsTunnelInstance OBJECT-TYPE
   SYNTAX        MplsTunnelInstanceIndex
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "Uniquely identifies an instance of a tunnel. It is
          useful to identify multiple instances of tunnels
          for the purposes of backup and parallel tunnels."
   ::=3D { mplsTunnelEntry 2 }

mplsTunnelIngressLSRId OBJECT-TYPE
   SYNTAX        MplsLsrIdentifier
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "The purpose of this object is to uniquely identity a
          tunnel within a network. When the MPLS signalling
          protoocol is rsvp(2) this value SHOULD mimic the
          Extended Tunnel Id field in the SESSION object.
          When the MPLS signalling protoocol is crldp(3) this
          value SHOULD mimic the Ingress LSR Router ID field
          in the LSPID TLV object."
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-08.txt>, February 2001.,
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          Internet Draft <draft-ietf-mpls-cr-ldp-05.txt>,
          February 2001."
   ::=3D { mplsTunnelEntry 3 }

mplsTunnelEgressLSRId OBJECT-TYPE
   SYNTAX        MplsLsrIdentifier
   MAX-ACCESS    accessible-for-notify
   STATUS        current
   DESCRIPTION
        "Specifies the egress LSR ID."
   ::=3D { mplsTunnelEntry 4 }

mplsTunnelName OBJECT-TYPE
   SYNTAX        DisplayString
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The canonical name assigned to the tunnel. This name
          can be used to refer to the tunnel on the LSR=92s
          console port.  If mplsTunnelIsIf is set to true
          then the ifName of the interface corresponding to



Srinivasan et al.           Expires February 2002           [Page 17]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          this tunnel should have a value equal to
          mplsTunnelName.  Also see the description of ifName
          in RFC 2233."
   REFERENCE
        "RFC 2233 - The Interfaces Group MIB using SMIv2,
          McCloghrie, K., and F. Kastenholtz, Nov. 1997"
   ::=3D { mplsTunnelEntry 5 }

mplsTunnelDescr OBJECT-TYPE
   SYNTAX        DisplayString
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "A textual string containing information about the
          tunnel.  If there is no description this object
          contains a zero length string."
   ::=3D { mplsTunnelEntry 6 }

mplsTunnelIsIf OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes whether or not this tunnel corresponds to an
          interface represented in the interfaces group
          table. Note that if this variable is set to true
          then the ifName of the interface corresponding to
          this tunnel should have a value equal to
          mplsTunnelName.  Also see the description of ifName
          in RFC 2233."
   REFERENCE
        "RFC 2233 - The Interfaces Group MIB using SMIv2,
          McCloghrie, K., and F. Kastenholtz, Nov. 1997"
   DEFVAL        { false }
   ::=3D { mplsTunnelEntry 7 }

mplsTunnelIfIndex OBJECT-TYPE
   SYNTAX        InterfaceIndexOrZero
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelIsIf is set to true, then this value
          contains the LSR-assigned ifIndex which corresponds
          to an entry in the interfaces table.  Otherwise
          this variable should contain the value of zero
          indicating that a valid ifIndex was not assigned to
          this tunnel interface."
   REFERENCE
        "RFC 2233 - The Interfaces Group MIB using SMIv2,
          McCloghrie, K., and F. Kastenholtz, Nov. 1997"



Srinivasan et al.           Expires February 2002           [Page 18]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   ::=3D { mplsTunnelEntry 8 }

mplsTunnelXCPointer OBJECT-TYPE
   SYNTAX        RowPointer
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable points to a row in the mplsXCTable.
          This table identifies the segments that compose
          this tunnel, their characteristics, and
          relationships to each other. A value of zeroDotZero
          indicates that no LSP has been associated with this
          tunnel yet."
   REFERENCE
        "Srinivasan, C., Viswanathan, A., and T. Nadeau, MPLS
          Label Switch Router Management Information Base
          Using SMIv2, Internet Draft <draft-ietf-mpls-lsr-
          mib-06.txt>, July 2000."
   ::=3D { mplsTunnelEntry 9 }

mplsTunnelSignallingProto OBJECT-TYPE
   SYNTAX       INTEGER {
                     none(1),
                     rsvp(2),
                     crldp(3),
                     other(4)
                     }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The signaling protocol, if any, which was used to
          setup this tunnel."
   DEFVAL        { none }
   ::=3D { mplsTunnelEntry 10 }

mplsTunnelSetupPrio OBJECT-TYPE
   SYNTAX        INTEGER (0..7)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates the setup priority of this tunnel."
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000.,
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          Internet Draft <draft-ietf-mpls-cr-ldp-04.txt>,
          July 2000."
   ::=3D { mplsTunnelEntry 11 }




Srinivasan et al.           Expires February 2002           [Page 19]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelHoldingPrio OBJECT-TYPE
   SYNTAX        INTEGER (0..7)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates the holding priority for this tunnel."
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000.,
         2. Constraint-Based LSP Setup using LDP, Jamoussi,
          Internet Draft <draft-ietf-mpls-cr-ldp-04.txt>,
          July 2000."
   ::=3D { mplsTunnelEntry 12 }

mplsTunnelSessionAttributes OBJECT-TYPE
   SYNTAX      BITS {
                  fastReroute (0),
                  mergingPermitted (1),
                  isPersistent (2),
                  isPinned (3),
                  recordRoute(4)
                 }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This bitmask indicates optional session values for
          this tunnel. The following describes these
          bitfields:
       =20
        fastRerouteThis flag indicates that the any tunnel
          hop may choose to reroute this tunnel without
          tearing it down.  This flag permits transit routers
          to use a local repair mechanism which may result in
          violation of the explicit routing of this tunnel.
          When a fault is detected on an adjacent downstream
          link or node, a transit router can reroute traffic
          for fast service restoration.
       =20
        mergingPermitted This flag permits transit routers
          to merge this session with other RSVP sessions for
          the purpose of reducing resource overhead on
          downstream transit routers, thereby providing
          better network scalability.
       =20
        isPersistent  Indicates whether this tunnel should
          be restored automatically after a failure occurs.
       =20
        isPinned   This flag indicates whether the loose-
          routed hops of this tunnel are to be pinned.



Srinivasan et al.           Expires February 2002           [Page 20]
=0C
Internet Draft                 MPLS TE MIB                August 2001



       =20
        recordRouteThis flag indicates whether or not the
          signaling protocol should remember the tunnel path
          after it has been signaled."
       =20
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000."
   DEFVAL        { 0 }
   ::=3D { mplsTunnelEntry 13 }

mplsTunnelOwner OBJECT-TYPE
   SYNTAX        INTEGER {
      admin(1), -- represents all management entities
      rsvp(2),
      crldp(3),
      policyAgent(4),
      other(5)
   }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates which protocol created and is responsible
          for managing this tunnel. Values rsvp(2) and
          crldp(3) should not be used at the head-end of a
          MPLS tunnel."
   ::=3D { mplsTunnelEntry 14 }

mplsTunnelLocalProtectInUse  OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates that the local repair mechanism is in use
          to maintain this tunnel (usually in the face of an
          outage of the link it was previously routed over)."
   ::=3D { mplsTunnelEntry 15 }

mplsTunnelResourcePointer OBJECT-TYPE
   SYNTAX        RowPointer
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable represents a pointer to the traffic
          parameter specification for this tunnel.  This
          value may point at an entry in the
          mplsTunnelResourceEntry to indicate which
          mplsTunnelResourceEntry is to be assigned to this
          segment.  This value may optionally point at an



Srinivasan et al.           Expires February 2002           [Page 21]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          externally defined traffic parameter specification
          table.  A value of zeroDotZero indicates best-
          effort treatment.  By having the same value of this
          object, two or more segments can indicate resource
          sharing."
   ::=3D { mplsTunnelEntry 16 }

mplsTunnelInstancePriority OBJECT-TYPE
   SYNTAX        Unsigned32
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value indicates which priority, in descending
          order, with 0 indicating the lowest priority,
          within a group of tunnel instances. A group of
          tunnel instances is defined as a set of tunnels
          with the same mplsTunnelIndex in this table, but
          with a different mplsTunnelInstance. Tunnel group
          priorities are used to denote the priority at which
          a particular tunnel instance will supercede
          another. Instances of tunnels containing the same
          mplsTunnelInstancePriority will be used for load
          sharing."
   DEFVAL        { 0 }
   ::=3D { mplsTunnelEntry 17 }

mplsTunnelHopTableIndex OBJECT-TYPE
   SYNTAX         MplsPathIndexOrZero
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Index into the mplsTunnelHopTable entry that
          specifies the explicit route hops for this tunnel."
   ::=3D { mplsTunnelEntry 18 }

mplsTunnelARHopTableIndex OBJECT-TYPE
   SYNTAX        MplsPathIndexOrZero
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Index into the mplsTunnelARHopTable entry that
          specifies the actual hops traversed by the tunnel."
   ::=3D { mplsTunnelEntry 19 }

mplsTunnelCHopTableIndex OBJECT-TYPE
   SYNTAX        MplsPathIndexOrZero
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Index into the mplsTunnelCHopTable entry that



Srinivasan et al.           Expires February 2002           [Page 22]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          specifies the computed hops traversed by the
          tunnel."
   ::=3D { mplsTunnelEntry 20 }

mplsTunnelPrimaryInstance OBJECT-TYPE
   SYNTAX         MplsTunnelInstanceIndex
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the instance index of the primary instance
          of this tunnel."
   ::=3D { mplsTunnelEntry 21 }

mplsTunnelPrimaryTimeUp OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the total time the primary instance of
          this tunnel has been active. The primary instance
          of this tunnel is defined in
          mplsTunnelPrimaryInstance."
   ::=3D { mplsTunnelEntry 22 }

mplsTunnelPathChanges OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the number of times the paths has changed
          for this tunnel."
   ::=3D { mplsTunnelEntry 23 }

mplsTunnelLastPathChange OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the time since the last path change for
          this tunnel."
   ::=3D { mplsTunnelEntry 24 }

mplsTunnelCreationTime OBJECT-TYPE
   SYNTAX        TimeStamp
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the value of SysUpTime when the first
          instance of this tunnel came into existence."
   ::=3D { mplsTunnelEntry 25 }



Srinivasan et al.           Expires February 2002           [Page 23]
=0C
Internet Draft                 MPLS TE MIB                August 2001




mplsTunnelStateTransitions OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Specifies the number of times the state of this
          tunnel instance has changed."
   ::=3D { mplsTunnelEntry 26 }

mplsTunnelIncludeAnyAffinity OBJECT-TYPE
   SYNTAX        MplsTunnelAffinity
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "A link satisfies the include-any constraint if and
          only if the constraint is zero, or the link and the
          constraint have a resource class in common."
        REFERENCE "RSVP-TE: Extensions to RSVP for LSP
          Tunnels,
                   draft-ietf-mpls-rsvp-lsp-tunnel-07.txt"
   ::=3D { mplsTunnelEntry 27 }

mplsTunnelIncludeAllAffinity OBJECT-TYPE
   SYNTAX        MplsTunnelAffinity
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "A link satisfies the include-all constraint if and
          only if the link contains all of the adminstrative
          groups specified in the constraint."
        REFERENCE "RSVP-TE: Extensions to RSVP for LSP
          Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt"
   ::=3D { mplsTunnelEntry 28 }

mplsTunnelExcludeAllAffinity OBJECT-TYPE
   SYNTAX        MplsTunnelAffinity
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "A link satisfies the exclude-all constraint if and
          only if the link contains none of the adminstrative
          groups specifie in the constraint."
        REFERENCE "RSVP-TE: Extensions to RSVP for LSP
          Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt"
   ::=3D { mplsTunnelEntry 29 }

mplsTunnelPathInUse OBJECT-TYPE
   SYNTAX        MplsPathIndexOrZero
   MAX-ACCESS    read-create



Srinivasan et al.           Expires February 2002           [Page 24]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   STATUS        current
   DESCRIPTION
        "This value denotes the configured path that was
          chosen for this tunnel. This value reflects the
          secondary index into the TunnelHopTable. This path
          may not exactly match the one in the ARHopTable due
          to the fact that some CSPF modification may have
          taken place. See the ARHopTable for the actual path
          being taken by the tunnel. A value of zero denotes
          that no path is currently in use or available."
   ::=3D { mplsTunnelEntry 30 }

mplsTunnelRole OBJECT-TYPE
   SYNTAX        INTEGER { head(1), transit(2), tail(3) }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value signifies the role that this tunnel
          entry/instance represents. This value MUST be set
          to head(1) at the originating point of the tunnel.
          This value MUST be set to transit(2) at transit
          points along the tunnel, if transit points are
          supported. This value MUST be set to tail(3) at the
          terminating point of the tunnel if tunnel tails are
          supported."
      ::=3D { mplsTunnelEntry 31 }

mplsTunnelTotalUpTime OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value represents the aggregate up time for all
          instances of this tunnel, if available. If this
          value is unavailable, it MUST return a value of 0."
      ::=3D { mplsTunnelEntry 32 }

mplsTunnelInstanceUpTime OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value identifies the total time that this
          tunnel instance's operStatus has been Up(1)."
      ::=3D { mplsTunnelEntry 33 }

mplsTunnelAdminStatus OBJECT-TYPE
   SYNTAX     INTEGER {
                   -- ready to pass packets
                   up(1),



Srinivasan et al.           Expires February 2002           [Page 25]
=0C
Internet Draft                 MPLS TE MIB                August 2001



                   down(2),
                   -- in some test mode
                   testing(3)
             }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates the desired operational status of this
          tunnel."
   ::=3D { mplsTunnelEntry 34 }

mplsTunnelOperStatus OBJECT-TYPE
   SYNTAX     INTEGER {
               -- ready to pass packets
               up(1),
               down(2),
               -- in some test mode
               testing(3),
               -- status cannot be determined
               unknown(4),
               dormant(5),
               -- some component is missing
               notPresent(6),
               -- down due to the state of
               -- lower layer interfaces
               lowerLayerDown(7)
             }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Indicates the actual operational status of this
          tunnel, which is typically but not limited to, a
          function of the state of individual segments of
          this tunnel."
   ::=3D { mplsTunnelEntry 35 }

mplsTunnelRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::=3D { mplsTunnelEntry 36 }

mplsTunnelStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 26]
=0C
Internet Draft                 MPLS TE MIB                August 2001



        "This variable indicates the storage type for this
          object."
   ::=3D { mplsTunnelEntry 37 }

-- End of mplsTunnelTable


mplsTunnelHopListIndexNext OBJECT-TYPE
   SYNTAX        Unsigned32 (0..2147483647)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "This object contains an appropriate value to be used
          for mplsTunnelHopListIndex when creating entries in
          the mplsTunnelHopTable.  If the number of
          unassigned entries is exhausted, a retrival
          operation will return a value of 0.  This object
          may also return a value of 0 when the LSR is unable
          to accept conceptual row creation, for example, if
          the mplsTunnelHopTable is implemented as read-only.
          To obtain the value of mplsTunnelHopListIndex for a
          new entry in the mplsTunnelHopTable, the manager
          issues a management protocol retrieval operation to
          obtain the current value of mplsTunnelHopIndex.
          After each retrieval operation, the agent should
          modify the value to reflect the next unassigned
          index.  After a manager retrieves a value the agent
          will determine through its local policy when this
          index value will be made available for reuse."
   ::=3D { mplsTeObjects 3 }

mplsTunnelHopTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The mplsTunnelHopTable is used to indicate the hops,
          strict or loose, for an MPLS tunnel defined in
          mplsTunnelTable, when it is established via
          signaling, for the outgoing direction of the
          tunnel.  Each row in this table is indexed by
          mplsTunnelHopListIndex.  Each row also has a
          secondary index mplsTunnelHopIndex corresponding to
          the next hop that this row corresponds to.  The
          first row in the table is the first hop after the
          origination point of the tunnel.  In case we want
          to specify a particular interface on the
          originating LSR of an outgoing tunnel by which we
          want packets to exit the LSR, we specify this as
          the first hop for this tunnel in



Srinivasan et al.           Expires February 2002           [Page 27]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          mplsTunnelHopTable."
   ::=3D { mplsTeObjects 4 }

mplsTunnelHopEntry  OBJECT-TYPE
   SYNTAX        MplsTunnelHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents a tunnel hop.  An
          entry is created by a network administrator for
          signaled ERLSP set up by an MPLS signaling
          protocol."
   INDEX {
      mplsTunnelHopListIndex,
      mplsTunnelHopPathOptionIndex,
      mplsTunnelHopIndex
   }
   ::=3D { mplsTunnelHopTable 1 }

MplsTunnelHopEntry ::=3D SEQUENCE {
      mplsTunnelHopListIndex          MplsPathIndex,
      mplsTunnelHopPathOptionIndex    MplsPathIndex,
      mplsTunnelHopIndex              MplsPathIndex,
      mplsTunnelHopAddrType           INTEGER,
      mplsTunnelHopIpv4Addr           InetAddressIPv4,
      mplsTunnelHopIpv4PrefixLen      Unsigned32,
      mplsTunnelHopIpv6Addr           InetAddressIPv6,
      mplsTunnelHopIpv6PrefixLen      Unsigned32,
      mplsTunnelHopAsNumber           Unsigned32,
      mplsTunnelHopLspId              MplsLSPID,
      mplsTunnelHopType               INTEGER,
      mplsTunnelHopIncludeExclude     INTEGER,
      mplsTunnelHopPathOptionName     DisplayString,
      mplsTunnelHopEntryPathComp      INTEGER,
      mplsTunnelHopRowStatus          RowStatus,
      mplsTunnelHopStorageType        StorageType
   }

mplsTunnelHopListIndex OBJECT-TYPE
   SYNTAX         MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Primary index into this table identifying a
          particular explicit route object."
   ::=3D { mplsTunnelHopEntry 1 }

mplsTunnelHopPathOptionIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible



Srinivasan et al.           Expires February 2002           [Page 28]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   STATUS        current
   DESCRIPTION
        "Secondary index into this table identifying a
          particular group of hops representing a particular
          configured path. This is otherwise known as a path
          option."
   ::=3D { mplsTunnelHopEntry 2 }

mplsTunnelHopIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Secondary index into this table identifying a
          particular hop."
   ::=3D { mplsTunnelHopEntry 3 }

mplsTunnelHopAddrType OBJECT-TYPE
   SYNTAX        INTEGER {
                       ipV4(1),
                       ipV6(2),
                       asNumber(3),
                       lspid(4)
                     }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes the address type of this tunnel hop."
   DEFVAL        { ipV4 }
   ::=3D { mplsTunnelHopEntry 4 }

mplsTunnelHopIpv4Addr OBJECT-TYPE
   SYNTAX        InetAddressIPv4
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If mplsTunnelHopAddrType is set to ipV4(1), then
          this value will contain the IPv4 address of this
          hop. If mplsTunnelHopAddrType is set to lspid(4),
          then this value will contain the Ingress LSR Router
          ID of the Tunnel. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelHopEntry 5 }

mplsTunnelHopIpv4PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..32)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If mplsTunnelHopAddrType is ipV4(1), then the prefix



Srinivasan et al.           Expires February 2002           [Page 29]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          length for this hop's IPv4 address is contained
          herein. This object is otherwise insignificant and
          should contain a value of 0."
   ::=3D { mplsTunnelHopEntry 6 }

mplsTunnelHopIpv6Addr OBJECT-TYPE
   SYNTAX        InetAddressIPv6
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If the mplsTunnelHopAddrType is set to ipV6(2), then
          this variable contains the IPv6 address of this
          hop.  This object is otherwise insignificant and
          should contain a value of 0."
   ::=3D { mplsTunnelHopEntry 7 }

mplsTunnelHopIpv6PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..128)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If mplsTunnelHopAddrType is set to ipV6(2), this
          value will contain the prefix length for this hop's
          IPv6 address. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelHopEntry 8 }

mplsTunnelHopAsNumber OBJECT-TYPE
   SYNTAX        Unsigned32 (0..65535)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If mplsTunnelHopAddrType is set to asNumber(3), then
          this value will contain the AS number of this hop.
          This object is otherwise insignificant and should
          contain a value of 0 to indicate this fact."
   ::=3D { mplsTunnelHopEntry 9 }

mplsTunnelHopLspId OBJECT-TYPE
   SYNTAX        MplsLSPID
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If mplsTunnelHopAddrType is set to lspid(4), then
          this value will contain the LSPID of a tunnel of
          this hop. The present tunnel being configured is
          =91tunneled=92 through this hop (using label stacking).
          This object is otherwise insignificant and should
          contain a value of 0 to indicate this fact."
   ::=3D { mplsTunnelHopEntry 10 }



Srinivasan et al.           Expires February 2002           [Page 30]
=0C
Internet Draft                 MPLS TE MIB                August 2001




mplsTunnelHopType OBJECT-TYPE
   SYNTAX        INTEGER {
                      strict(1),
                      loose(2)
                     }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes whether this tunnel hop is routed in a
          strict or loose fashion."
   ::=3D { mplsTunnelHopEntry 11 }

mplsTunnelHopIncludeExclude OBJECT-TYPE
   SYNTAX        INTEGER {
                      include(1),
                      exclude(2)
                 }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "If this value is set to include(1), then this
          indicates that this hop must be included in the
          tunnel's path. If this value is set to exclude(2),
          then this hop must be avoided when calculating the
          path for this tunnel. The default value of this
          object is include(1), so that by default all
          indicated hops are included in the CSPF path
          computation."
   DEFVAL { include }
   ::=3D { mplsTunnelHopEntry 12 }

mplsTunnelHopPathOptionName OBJECT-TYPE
   SYNTAX        DisplayString
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The description of this series of hops as they
          relate to the
        specified path option."
   ::=3D { mplsTunnelHopEntry 13 }

mplsTunnelHopEntryPathComp OBJECT-TYPE
   SYNTAX        INTEGER {
                      dynamic(1),    -- CSPF computed
                      explicit(2)    -- strict hop
                  }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 31]
=0C
Internet Draft                 MPLS TE MIB                August 2001



        "If this value is set to dynamic, then the user
          should only specify the source and destination of
          the path and expect that the CSPF will calculate
          the remainder of the path.  If this value is set to
          explicit, the user should specify the entire path
          for the tunnel to take.  This path may contain
          strict or loose hops.  Each hop along a specific
          path should have this object set to the same value"
   ::=3D { mplsTunnelHopEntry 14 }

mplsTunnelHopRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::=3D { mplsTunnelHopEntry 15 }

mplsTunnelHopStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable indicates the storage type for this
          object."
   ::=3D { mplsTunnelHopEntry 16 }

-- End of mplsTunnelHopTable

-- Begin of mplsTunnelResourceTable

mplsTunnelResourceIndexNext OBJECT-TYPE
   SYNTAX        Unsigned32 (0.. 2147483647)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "This object contains the next appropriate value to
          be used for mplsTunnelResourceIndex when creating
          entries in the mplsTunnelResourceTable. If the
          number of unassigned entries is exhausted, a
          retrival operation will return a value of 0.  This
          object may also return a value of 0 when the LSR is
          unable to accept conceptual row creation, for
          example, if the mplsTunnelTable is implemented as
          read-only.  To obtain the mplsTunnelResourceIndex
          value for a new entry, the manager must first issue
          a management protocol retrieval operation to obtain
          the current value of this object. The agent should
          modify the value to reflect the next unassigned



Srinivasan et al.           Expires February 2002           [Page 32]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          index after each retrieval operation. After a
          manager retrieves a value the agent will determine
          through its local policy when this index value will
          be made available for reuse."
   ::=3D { mplsTeObjects 5 }

mplsTunnelResourceTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelResourceEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The mplsTunnelResourceTable allows a manager to
          specify which resources are desired for an MPLS
          tunnel.  This table also allows several tunnels to
          point to a single entry in this table, implying
          that these tunnels should share resources."
   ::=3D { mplsTeObjects 6 }

mplsTunnelResourceEntry OBJECT-TYPE
   SYNTAX        MplsTunnelResourceEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents a set of resources
          for an MPLS tunnel.  An entry can be created by a
          network administrator or by an SNMP agent as
          instructed by any MPLS signaling protocol."
   INDEX         { mplsTunnelResourceIndex }
   ::=3D { mplsTunnelResourceTable 1 }

MplsTunnelResourceEntry ::=3D SEQUENCE {
      mplsTunnelResourceIndex                Unsigned32,
      mplsTunnelResourceMaxRate              MplsBitRate,
      mplsTunnelResourceMeanRate             MplsBitRate,
      mplsTunnelResourceMaxBurstSize         MplsBurstSize,
      mplsTunnelResourceMeanBurstSize        MplsBurstSize,
      mplsTunnelResourceExcessBurstSize      MplsBurstSize,
      mplsTunnelResourceFrequency            INTEGER,
      mplsTunnelResourceWeight               Unsigned32,
      mplsTunnelResourceRowStatus            RowStatus,
      mplsTunnelResourceStorageType          StorageType
   }

mplsTunnelResourceIndex OBJECT-TYPE
   SYNTAX        Unsigned32 (1..2147483647)
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Uniquely identifies this row."
   ::=3D { mplsTunnelResourceEntry 1 }



Srinivasan et al.           Expires February 2002           [Page 33]
=0C
Internet Draft                 MPLS TE MIB                August 2001




mplsTunnelResourceMaxRate OBJECT-TYPE
   SYNTAX        MplsBitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The maximum rate in bits/second.  Note that setting
          mplsTunnelResourceMaxRate,
          mplsTunnelResourceMeanRate, and
          mplsTunnelResourceMaxBurstSize to 0 indicates best-
          effort treatment.
         This object is copied to an instance of
          mplsTrafficParamMaxRate in mplsTrafficParamTable
          the OID of which is copied into the corresponding
          mplsInSegmentTrafficParamPtr."
   REFERENCE
        "Srinivasan, C., Viswanathan, A., and T. Nadeau, MPLS
          Label Switch Router Management Information Base
          Using SMIv2, Internet Draft <draft-ietf-mpls-lsr-
          mib-06.txt>, July 2000."
   ::=3D { mplsTunnelResourceEntry 2 }

mplsTunnelResourceMeanRate OBJECT-TYPE
   SYNTAX        MplsBitRate
   UNITS         "bits per second"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This object is copied into an instance of
          mplsTrafficParamMeanRate in the
          mplsTrafficParamTable. The OID of this table entry
          is then copied into the corresponding
          mplsInSegmentTrafficParamPtr.
       =20
         When resource allocation is performed as requested
          by this TSpec object, it is copied into an entry in
          mplsTrafficParamTable [LSRMIB]:
          mplsTunnelInMeanRate to mplsTrafficParamMeanRate.
          The OID of this entry is copied to
          mplsInSegmentTrafficParamPtr of the corresponding
          in-segment entry."
         =20
   REFERENCE
        "Srinivasan, C., Viswanathan, A., and T. Nadeau, MPLS
          Label Switch Router Management Information Base
          Using SMIv2, Internet Draft <draft-ietf-mpls-lsr-
          mib-06.txt>, July 2000."
   ::=3D { mplsTunnelResourceEntry 3 }




Srinivasan et al.           Expires February 2002           [Page 34]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelResourceMaxBurstSize OBJECT-TYPE
   SYNTAX        MplsBurstSize
   UNITS         "bytes"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The maximum burst size in bytes.  This object is
          copied to mplsInSegmentMaxBurstSize of the
          corresponding in-segment.
       =20
         When resource allocation is performed as requested
          by this TSpec object, it is copied into an entry in
          mplsTrafficParamTable [LSRMIB]:
          mplsTunnelInMaxBurstSize to
          mplsTrafficParamMaxBurstSize. The OID of this entry
          is copied to mplsInSegmentTrafficParamPtr of the
          corresponding in-segment entry."
   REFERENCE
        "Srinivasan, C., Viswanathan, A., and T. Nadeau, MPLS
          Label Switch Router Management Information Base
          Using SMIv2, Internet Draft <draft-ietf-mpls-lsr-
          mib-06.txt>, July 2000."
   ::=3D { mplsTunnelResourceEntry 4 }

mplsTunnelResourceMeanBurstSize OBJECT-TYPE
   SYNTAX       MplsBurstSize
   UNITS        "bytes"
   MAX-ACCESS   read-create
   STATUS       current
   DESCRIPTION
        "The mean burst size in bytes.  The implementations
          which do not implement this variable must return 0
          for this value and must not allow a user to set
          this value."
   ::=3D { mplsTunnelResourceEntry 5 }

mplsTunnelResourceExcessBurstSize OBJECT-TYPE
   SYNTAX       MplsBurstSize
   UNITS        "bytes"
   MAX-ACCESS   read-create
   STATUS       current
   DESCRIPTION
        "The Excess burst size in bytes.  The implementations
          which do not implement this variable must return 0
          for this value and must not allow a user to set
          this value."
   REFERENCE
        "CR-LDP Specification, Section 4.3."
   ::=3D { mplsTunnelResourceEntry 6 }




Srinivasan et al.           Expires February 2002           [Page 35]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelResourceFrequency  OBJECT-TYPE
   SYNTAX       INTEGER {
                     unspecified(1),
                     frequent(2),
                     veryFrequent(3)
                 }
   MAX-ACCESS   read-create
   STATUS       current
   DESCRIPTION
        "The granularity of the availability of committed
          rate.  The implementations which do not implement
          this variable must return unspecified(1) for this
          value and must not allow a user to set this value."
   REFERENCE
        "CR-LDP Specification, Section 4.3."
   ::=3D { mplsTunnelResourceEntry 7 }

mplsTunnelResourceWeight    OBJECT-TYPE
   SYNTAX       Unsigned32(0..255)
   MAX-ACCESS   read-create
   STATUS       current
   DESCRIPTION
        "The relative weight for using excess bandwidth above
          its committed rate.  The value of 0 means that
          weight is not applicable for the CR-LSP."
   REFERENCE
        "CR-LDP Specification, Section 4.3."
   ::=3D { mplsTunnelResourceEntry 8 }

mplsTunnelResourceRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::=3D { mplsTunnelResourceEntry 9 }

mplsTunnelResourceStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable indicates the storage type for this
          object."
   ::=3D { mplsTunnelResourceEntry 10 }


-- End mplsTunnelResourceTable




Srinivasan et al.           Expires February 2002           [Page 36]
=0C
Internet Draft                 MPLS TE MIB                August 2001



-- Tunnel Actual Route Hop table.

mplsTunnelARHopTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelARHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The mplsTunnelARHopTable is used to indicate the
          hops, strict or loose, for an MPLS tunnel defined
          in mplsTunnelTable, as reported by the MPLS
          signaling protocol, for the outgoing direction of
          the tunnel.  Each row in this table is indexed by
          mplsTunnelARHopListIndex.  Each row also has a
          secondary index mplsTunnelARHopIndex, corresponding
          to the next hop that this row corresponds to.  The
          first row in the table is the first hop after the
          origination point of the tunnel.  In case we want
          to specify a particular interface on the
          originating LSR of an outgoing tunnel by which we
          want packets to exit the LSR, we specify this as
          the first hop for this tunnel in
          mplsTunnelARHopTable.
       =20
         Please note that since the information necessary to
          build entries within this table are not provided by
          some MPLS signaling protocols, implementation of
          this table is optional. Furthermore, since the
          information in this table is actually provided by
          the MPLS signaling protocol after the path has been
          set-up, the entries in this table are provided only
          for observation, and hence, all variables in this
          table are accessible exclusively as read-only."
   ::=3D { mplsTeObjects 7 }

mplsTunnelARHopEntry  OBJECT-TYPE
   SYNTAX        MplsTunnelARHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents a tunnel hop.  An
          entry is created by a network administrator for
          signaled ERLSP set up by an MPLS signaling
          protocol."
   INDEX { mplsTunnelARHopListIndex, mplsTunnelARHopIndex }
   ::=3D { mplsTunnelARHopTable 1 }

MplsTunnelARHopEntry ::=3D SEQUENCE {
      mplsTunnelARHopListIndex          MplsPathIndex,
      mplsTunnelARHopIndex              MplsPathIndex,
      mplsTunnelARHopAddrType           INTEGER,



Srinivasan et al.           Expires February 2002           [Page 37]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      mplsTunnelARHopIpv4Addr           InetAddressIPv4,
      mplsTunnelARHopIpv4PrefixLen      Unsigned32,
      mplsTunnelARHopIpv6Addr           InetAddressIPv6,
      mplsTunnelARHopIpv6PrefixLen      Unsigned32,
      mplsTunnelARHopAsNumber           Unsigned32,
      mplsTunnelARHopLspId              MplsLSPID
   }

mplsTunnelARHopListIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Primary index into this table identifying a
          particular recorded hop list."
   ::=3D { mplsTunnelARHopEntry 1 }

mplsTunnelARHopIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Secondary index into this table identifying the
          particular hop."
   ::=3D { mplsTunnelARHopEntry 2 }

mplsTunnelARHopAddrType OBJECT-TYPE
   SYNTAX        INTEGER {
                      ipV4(1),
                      ipV6(2),
                      asNumber(3)
                   }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Denotes the address type of this tunnel hop."
   DEFVAL        { ipV4 }
   ::=3D { mplsTunnelARHopEntry 3 }

mplsTunnelARHopIpv4Addr OBJECT-TYPE
   SYNTAX        InetAddressIPv4
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelARHopAddrType is set to ipV4(1), then
          this value will contain the IPv4 address of this
          hop. This object is otherwise insignificant and
          should contain a value of 0."
   ::=3D { mplsTunnelARHopEntry 4 }




Srinivasan et al.           Expires February 2002           [Page 38]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelARHopIpv4PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..32)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelARHopAddrType is ipV4(1), then the
          prefix length for this hop's IPv4 address is
          contained herein. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelARHopEntry 5 }

mplsTunnelARHopIpv6Addr OBJECT-TYPE
   SYNTAX        InetAddressIPv6
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If the mplsTunnelARHopAddrType is set to ipV6(2),
          then this variable contains the IPv6 address of
          this hop.  This object is otherwise insignificant
          and should contain a value of 0."
   ::=3D { mplsTunnelARHopEntry 6 }

mplsTunnelARHopIpv6PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..128)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelARHopAddrType is set to ipV6(2), this
          value will contain the prefix length for this hop's
          IPv6 address. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelARHopEntry 7 }

mplsTunnelARHopAsNumber OBJECT-TYPE
   SYNTAX        Unsigned32 (0..65535)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelARHopAddrType is set to asNumber(3),
          then this value will contain the AS number of this
          hop. This object is otherwise insignificant and
          should contain a value of 0 to indicate this fact."
   ::=3D { mplsTunnelARHopEntry 8 }

mplsTunnelARHopLspId OBJECT-TYPE
   SYNTAX        MplsLSPID
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelARHopAddrType is set to lspid(4), then



Srinivasan et al.           Expires February 2002           [Page 39]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          this value will contain the LSP ID of this hop.
          This object is otherwise insignificant and should
          contain a value of 0 to indicate this fact."
   ::=3D { mplsTunnelARHopEntry 9 }


-- End of mplsTunnelARHopTable


-- Tunnel Computed Hop table.

mplsTunnelCHopTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelCHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "The mplsTunnelCHopTable is used to indicate the
          hops, strict or loose, for an MPLS tunnel defined
          in mplsTunnelTable, as computed by a constraint-
          based routing protocol, based on the
          mplsTunnelHopTable for the outgoing direction of
          the tunnel.  Each row in this table is indexed by
          mplsTunnelCHopListIndex.  Each row also has a
          secondary index mplsTunnelCHopIndex, corresponding
          to the next hop that this row corresponds to.  The
          first row in the table is the first hop after the
          origination point of the tunnel.  In case we want
          to specify a particular interface on the
          originating LSR of an outgoing tunnel by which we
          want packets to exit the LSR, we specify this as
          the first hop for this tunnel in
          mplsTunnelCHopTable.
       =20
         Please note that since the information necessary to
          build entries within this table may not be
          supported by some LSRs, implementation of this
          table is optional. Furthermore, since the
          information in this table is actually provided by
          routing protocol after the path has been computed,
          the entries in this table are provided only for
          observation, and hence, all variables in this table
          are accessible exclusively as read-only."
   ::=3D { mplsTeObjects 8 }

mplsTunnelCHopEntry  OBJECT-TYPE
   SYNTAX        MplsTunnelCHopEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents a tunnel hop.  An



Srinivasan et al.           Expires February 2002           [Page 40]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          entry in this table is created by a constraint-
          based routing protocol based on the hops specified
          in the corresponding mplsTunnelHopTable."
   INDEX { mplsTunnelCHopListIndex, mplsTunnelCHopIndex }
   ::=3D { mplsTunnelCHopTable 1 }

MplsTunnelCHopEntry ::=3D SEQUENCE {
      mplsTunnelCHopListIndex          MplsPathIndex,
      mplsTunnelCHopIndex              MplsPathIndex,
      mplsTunnelCHopAddrType           INTEGER,
      mplsTunnelCHopIpv4Addr           InetAddressIPv4,
      mplsTunnelCHopIpv4PrefixLen      Unsigned32,
      mplsTunnelCHopIpv6Addr           InetAddressIPv6,
      mplsTunnelCHopIpv6PrefixLen      Unsigned32,
      mplsTunnelCHopAsNumber           Unsigned32,
      mplsTunnelCHopType               INTEGER
   }

mplsTunnelCHopListIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Primary index into this table identifying a
          particular computed hop list."
   ::=3D { mplsTunnelCHopEntry 1 }

mplsTunnelCHopIndex OBJECT-TYPE
   SYNTAX        MplsPathIndex
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "Secondary index into this table identifying the
          particular hop."
   ::=3D { mplsTunnelCHopEntry 2 }

mplsTunnelCHopAddrType OBJECT-TYPE
   SYNTAX        INTEGER {
                     ipV4(1),
                     ipV6(2),
                     asNumber(3)
                  }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Denotes the address type of this tunnel hop."
   DEFVAL        { ipV4 }
   ::=3D { mplsTunnelCHopEntry 3 }

mplsTunnelCHopIpv4Addr OBJECT-TYPE



Srinivasan et al.           Expires February 2002           [Page 41]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   SYNTAX        InetAddressIPv4
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelCHopAddrType is set to ipV4(1), then
          this value will contain the IPv4 address of this
          hop. This object is otherwise insignificant and
          should contain a value of 0."
   ::=3D { mplsTunnelCHopEntry 4 }

mplsTunnelCHopIpv4PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..32)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelCHopAddrType is ipV4(1), then the
          prefix length for this hop's IPv4 address is
          contained herein. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelCHopEntry 5 }

mplsTunnelCHopIpv6Addr OBJECT-TYPE
   SYNTAX        InetAddressIPv6
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If the mplsTunnelCHopAddrType is set to ipV6(2),
          then this variable contains the IPv6 address of
          this hop.  This object is otherwise insignificant
          and should contain a value of 0."
   ::=3D { mplsTunnelCHopEntry 6 }

mplsTunnelCHopIpv6PrefixLen OBJECT-TYPE
   SYNTAX        Unsigned32 (0..128)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelCHopAddrType is set to ipV6(2), this
          value will contain the prefix length for this hop's
          IPv6 address. This object is otherwise
          insignificant and should contain a value of 0."
   ::=3D { mplsTunnelCHopEntry 7 }

mplsTunnelCHopAsNumber OBJECT-TYPE
   SYNTAX        Unsigned32 (0..65535)
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "If mplsTunnelCHopAddrType is set to asNumber(3),
          then this value will contain the AS number of this



Srinivasan et al.           Expires February 2002           [Page 42]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          hop. This object is otherwise insignificant and
          should contain a value of 0 to indicate this fact."
   ::=3D { mplsTunnelCHopEntry 8 }

mplsTunnelCHopType OBJECT-TYPE
   SYNTAX        INTEGER {
          strict(1),
          loose(2)
      }
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Denotes whether this is tunnel hop is routed in a
          strict or loose fashion."
   ::=3D { mplsTunnelCHopEntry 9 }
  =20
-- End of mplsTunnelCHopTable


-- MPLS Tunnel Performance Table.

mplsTunnelPerfTable  OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelPerfEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "This table provides per-tunnel MPLS performance
          information."
   ::=3D { mplsTeObjects 9 }

mplsTunnelPerfEntry OBJECT-TYPE
   SYNTAX        MplsTunnelPerfEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table is created by the LSR for
          every tunnel.  Its is an extension to
          mplsTunnelEntry."
   AUGMENTS { mplsTunnelEntry }
   ::=3D { mplsTunnelPerfTable 1 }
  =20
MplsTunnelPerfEntry ::=3D SEQUENCE {
      mplsTunnelPerfPackets           Counter32,
      mplsTunnelPerfHCPackets         Counter64,
      mplsTunnelPerfErrors            Counter32,
      mplsTunnelPerfBytes             Counter32,
      mplsTunnelPerfHCBytes           Counter64
   }

mplsTunnelPerfPackets OBJECT-TYPE



Srinivasan et al.           Expires February 2002           [Page 43]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Number of packets forwarded by the tunnel."
   ::=3D { mplsTunnelPerfEntry 1 }

mplsTunnelPerfHCPackets OBJECT-TYPE
   SYNTAX        Counter64
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "High capacity counter for number of packets
          forwarded by the tunnel."
   ::=3D { mplsTunnelPerfEntry 2 }

mplsTunnelPerfErrors OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Number of errored packets."
   ::=3D { mplsTunnelPerfEntry 3 }

mplsTunnelPerfBytes OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "Number of bytes forwarded by the tunnel."
   ::=3D { mplsTunnelPerfEntry 4 }

mplsTunnelPerfHCBytes OBJECT-TYPE
   SYNTAX        Counter64
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
        "High capacity counter for number of bytes forwarded
          by the tunnel."
   ::=3D { mplsTunnelPerfEntry 5 }

-- End of mplsTunnelPerfTable


-- CR-LDP Tunnel Resource Table

mplsTunnelCRLDPResTable OBJECT-TYPE
   SYNTAX        SEQUENCE OF MplsTunnelCRLDPResEntry
   MAX-ACCESS    not-accessible
   STATUS        current



Srinivasan et al.           Expires February 2002           [Page 44]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   DESCRIPTION
        "The mplsTunnelCRLDPResTable allows a manager to
          specify which CR-LDP-specific resources are desired
          for an MPLS tunnel if that tunnel is signaled using
          CR-LDP. Note that these attributes are in addition
          to those specified in mplsTunnelResourceTable. This
          table also allows several tunnels to point to a
          single entry in this table, implying that these
          tunnels should share resources."
   ::=3D { mplsTeObjects 10 }

mplsTunnelCRLDPResEntry OBJECT-TYPE
   SYNTAX        MplsTunnelCRLDPResEntry
   MAX-ACCESS    not-accessible
   STATUS        current
   DESCRIPTION
        "An entry in this table represents a set of resources
          for an MPLS tunnel established using CRLDP
          (mplsTunnelSignallingProto equal to crldp (3)). An
          entry can be created by a network administrator or
          by an SNMP agent as instructed by any MPLS
          signaling protocol."
   INDEX { mplsTunnelResourceIndex }
   ::=3D { mplsTunnelCRLDPResTable 1 }

MplsTunnelCRLDPResEntry ::=3D SEQUENCE {
      mplsTunnelCRLDPResMeanBurstSize   MplsBurstSize,
      mplsTunnelCRLDPResExcessBurstSize MplsBurstSize,
      mplsTunnelCRLDPResFrequency       Integer32,
      mplsTunnelCRLDPResWeight          Unsigned32,
      mplsTunnelCRLDPResFlags           Unsigned32,
      mplsTunnelCRLDPResRowStatus       RowStatus,
      mplsTunnelCRLDPResStorageType     StorageType
   }

mplsTunnelCRLDPResMeanBurstSize OBJECT-TYPE
   SYNTAX        MplsBurstSize
   UNITS         "bytes"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The mean burst size in bytes."
   ::=3D { mplsTunnelCRLDPResEntry 2 }

mplsTunnelCRLDPResExcessBurstSize OBJECT-TYPE
   SYNTAX        MplsBurstSize
   UNITS         "bytes"
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 45]
=0C
Internet Draft                 MPLS TE MIB                August 2001



     "The Excess burst size in bytes."
   REFERENCE
     "CR-LDP Specification, Section 4.3."
   ::=3D { mplsTunnelCRLDPResEntry 3 }

mplsTunnelCRLDPResFrequency OBJECT-TYPE
   SYNTAX  INTEGER {
         unspecified(1),
         frequent(2),
         veryFrequent(3)
      }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The granularity of the availability of committed
          rate."
   REFERENCE
        "CR-LDP Specification, Section 4.3."
   ::=3D { mplsTunnelCRLDPResEntry 4 }

mplsTunnelCRLDPResWeight OBJECT-TYPE
   SYNTAX        Unsigned32(0..255)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The relative weight for using excess bandwidth above
          its committed rate.  The value of 0 means that
          weight is not applicable for the CR-LSP."
   REFERENCE
        "CR-LDP Specification, Section 4.3."
   DEFVAL { 0 }
   ::=3D { mplsTunnelCRLDPResEntry 5 }

mplsTunnelCRLDPResFlags OBJECT-TYPE
   SYNTAX        Unsigned32 (0..63)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "The value of the 1 byte Flags conveyed as part of
          the traffic parameters during the establishment of
          the CRLSP. The bits in this object are to be
          interpreted as follows.
       =20
          +--+--+--+--+--+--+--+--+
          | Res |F6|F5|F4|F3|F2|F1|
          +--+--+--+--+--+--+--+--+
       =20
        Res - These bits are reserved. Zero on transmission.
          Ignored on receipt.
        F1 - Corresponds to the PDR.



Srinivasan et al.           Expires February 2002           [Page 46]
=0C
Internet Draft                 MPLS TE MIB                August 2001



        F2 - Corresponds to the PBS.
        F3 - Corresponds to the CDR.
        F4 - Corresponds to the CBS.
        F5 - Corresponds to the EBS.
        F6 - Corresponds to the Weight.
       =20
        Each flag if is a Negotiable Flag corresponding to a
          Traffic Parameter. The Negotiable Flag value zero
          denotes Not Negotiable and value one denotes
          Negotiable."
    REFERENCE
        "Section 4.3, Constraint-Based LSP Setup using LDP,
          Jamoussi, et. al,<draft-ietf-mpls-crldp-04.txt>,
          July 2000."
    DEFVAL { 0 }
    ::=3D { mplsTunnelCRLDPResEntry 6 }

mplsTunnelCRLDPResRowStatus OBJECT-TYPE
   SYNTAX        RowStatus
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable is used to create, modify, and/or
          delete a row in this table."
   ::=3D { mplsTunnelCRLDPResEntry 7 }

mplsTunnelCRLDPResStorageType OBJECT-TYPE
   SYNTAX        StorageType
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This variable indicates the storage type for this
          object."
   ::=3D { mplsTunnelCRLDPResEntry 8 }


-- Notifications.

mplsTunnelTrapEnable OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
        "If this object is true, then it enables the
          generation of mplsTunnelUp and mplsTunnelDown
          traps, otherwise these traps are not emitted."
   DEFVAL { false }
   ::=3D { mplsTeObjects 11 }

mplsTunnelUp NOTIFICATION-TYPE



Srinivasan et al.           Expires February 2002           [Page 47]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   OBJECTS     {
      mplsTunnelIndex,
      mplsTunnelInstance,
      mplsTunnelIngressLSRId,
      mplsTunnelEgressLSRId,
      mplsTunnelAdminStatus,
      mplsTunnelOperStatus
   }
   STATUS      current
   DESCRIPTION
        "This notification is generated when a
          mplsTunnelOperStatus object for one of the
          configured tunnels is about to leave the down state
          and transition into some other state (but not into
          the notPresent state).  This other state is
          indicated by the included value of
          mplsTunnelOperStatus."
   ::=3D { mplsTeNotifyPrefix 1 }

mplsTunnelDown NOTIFICATION-TYPE
   OBJECTS     {
      mplsTunnelIndex,
      mplsTunnelInstance,
      mplsTunnelIngressLSRId,
      mplsTunnelEgressLSRId,
      mplsTunnelAdminStatus,
      mplsTunnelOperStatus
   }
   STATUS      current
   DESCRIPTION
        "This notification is generated when a
          mplsTunnelOperStatus object for one of the
          configured tunnels is about to enter the down state
          from some other state (but not from the notPresent
          state).  This other state is indicated by the
          included value of mplsTunnelOperStatus."
   ::=3D { mplsTeNotifyPrefix 2 }

mplsTunnelRerouted NOTIFICATION-TYPE
   OBJECTS     {
      mplsTunnelIndex,
      mplsTunnelInstance,
      mplsTunnelIngressLSRId,
      mplsTunnelEgressLSRId,
      mplsTunnelAdminStatus,
      mplsTunnelOperStatus
   }
   STATUS      current
   DESCRIPTION
        "This notification is generated when a tunnel is



Srinivasan et al.           Expires February 2002           [Page 48]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          rerouted. If the actual path is used, then this
          object MAY contain the new path for this tunnel
          some time after this trap is issued by the agent."
    ::=3D { mplsTeNotifyPrefix 3 }

mplsTunnelReoptimized NOTIFICATION-TYPE
   OBJECTS     {
      mplsTunnelIndex,
      mplsTunnelInstance,
      mplsTunnelIngressLSRId,
      mplsTunnelEgressLSRId,
      mplsTunnelAdminStatus,
      mplsTunnelOperStatus
   }
   STATUS      current
   DESCRIPTION
        "This notification is generated when a tunnel is
          reoptimized. If the actual path is used, then this
          object MAY contain the new path for this tunnel
          some time after this trap is issued by the agent."
    ::=3D { mplsTeNotifyPrefix 4 }

-- End of notifications.


-- Module compliance.

mplsTeGroups
   OBJECT IDENTIFIER ::=3D { mplsTeConformance 1 }

mplsTeCompliances
   OBJECT IDENTIFIER ::=3D { mplsTeConformance 2 }

mplsTeModuleCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
        "Compliance statement for agents that support the
          MPLS TE MIB."
   MODULE -- this module

      -- The mandatory group has to be implemented by all
      -- LSRs that originate/terminate ESLSPs/tunnels.
      -- In addition, depending on the type of tunnels
      -- supported, other groups become mandatory as
      -- explained below.

      MANDATORY-GROUPS    {
         mplsTunnelGroup,
         mplsTunnelScalarGroup
      }



Srinivasan et al.           Expires February 2002           [Page 49]
=0C
Internet Draft                 MPLS TE MIB                August 2001




      GROUP mplsTunnelManualGroup
      DESCRIPTION
          "This group is mandatory for devices which support
           manual configuration of tunnels, in addition to
           mplsTunnelGroup.  The following constraints apply:
           mplsTunnelSignallingProto should be at least read-
           only with a value of none(1)."

      GROUP mplsTunnelSignaledGroup
      DESCRIPTION
          "This group is mandatory for devices which support
           signaled tunnel set up, in addition to
           mplsTunnelGroup.  The following constraints apply:
           mplsTunnelSignallingProto should be at least read-
           only returning a value of ldp(2), or rsvp(3)."

      GROUP mplsTunnelIsNotIntfcGroup
      DESCRIPTION
          "This group is mandatory for devices which support
           tunnels that are not interfaces, in addition to
           mplsTunnelGroup.  The following constraints apply:
           mplsTunnelIsIf must at least be read-only
           returning false(1)."

      GROUP mplsTunnelIsIntfcGroup
      DESCRIPTION
          "This group is mandatory for devices which support
           tunnels that are interfaces, in addition to
           mplsTunnelGroup.  The following constraints apply:
           mplsTunnelIsIf must at least be read-only
           returning true(2)."

      GROUP mplsTunnelOptionalGroup
      DESCRIPTION
          "Objects in this group are optional."

      -- mplsTunnelTable
     =20
      OBJECT      mplsTunnelName
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelDescr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelIsIf



Srinivasan et al.           Expires February 2002           [Page 50]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelIfIndex
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelXCPointer
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelSignallingProto
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelSetupPrio
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHoldingPrio
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelSessionAttributes
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelOwner
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelLocalProtectInUse
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourcePointer
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
         =20
      OBJECT      mplsTunnelInstancePriority
      MIN-ACCESS  read-only



Srinivasan et al.           Expires February 2002           [Page 51]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      DESCRIPTION
          "Write access is not required."
         =20
      OBJECT      mplsTunnelHopTableIndex
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT   mplsTunnelPrimaryInstance
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelPrimaryTimeUp
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelPathChanges
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelLastPathChange
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelCreationTime
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelStateTransitions
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelARHopTableIndex
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelCHopTableIndex
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelAdminStatus
      SYNTAX      INTEGER { up (1), down (2) }
      MIN-ACCESS  read-only
      DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 52]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          "Only up and down states must be supported. Write
           access is not required."
     =20
      OBJECT      mplsTunnelOperStatus
      SYNTAX      INTEGER { up (1), down (2) }
      DESCRIPTION
          "Only up and down states must be supported. Write
           access is not required."
     =20
      OBJECT      mplsTunnelRowStatus
      SYNTAX      INTEGER {
         active(1),
         notInService(2),
         createAndGo(4),
         destroy(6)
      }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The notReady(3) and createAndWait(5) states need
           not be supported. Write access is not required."
     =20
      OBJECT      mplsTunnelStorageType
      SYNTAX      INTEGER { other(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only other (1) needs to be supported."
         =20
      OBJECT      mplsTunnelPathInUse
      MIN-ACCESS  read-only
      DESCRIPTION
          "Read-only support is required."
         =20
      OBJECT      mplsTunnelRole
      SYNTAX      INTEGER { head(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only support for head is required."
         =20
      OBJECT       mplsTunnelTotalUpTime
      MIN-ACCESS  read-only
      DESCRIPTION
          "Read-only support is required."
         =20
      OBJECT       mplsTunnelInstanceUpTime
      MIN-ACCESS  read-only
      DESCRIPTION
          "Read-only support is required."
         =20
      -- mplsTunnelHopTable
     =20



Srinivasan et al.           Expires February 2002           [Page 53]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      OBJECT      mplsTunnelHopAddrType
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopIpv4Addr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopIpv4PrefixLen
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopIpv6Addr
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopIpv6PrefixLen
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopAsNumber
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopLspId
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopType
      SYNTAX      INTEGER { strict(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "loose(2) need not be supported. Write access is
           not required."
     =20
      OBJECT      mplsTunnelHopIncludeExclude
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopPathOptionName
      MIN-ACCESS  read-only
      DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 54]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopEntryPathComp
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelHopRowStatus
      SYNTAX      INTEGER {
         active(1),
         notInService(2),
         createAndGo(4),
         destroy(6)
      }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The notReady(3) and createAndWait(5) states need
           not be supported. Write access is not required."
     =20
      OBJECT      mplsTunnelHopStorageType
      SYNTAX      INTEGER { other(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only other (1) needs to be supported."

      -- mplsTunnelResourceTable
     =20
      OBJECT      mplsTunnelResourceMaxRate
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceMeanRate
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceMaxBurstSize
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceMeanBurstSize
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceExcessBurstSize
      MIN-ACCESS  read-only
      DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 55]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceFrequency
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceWeight
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelResourceRowStatus
      SYNTAX      INTEGER {
         active(1),
         notInService(2),
         createAndGo(4),
         destroy(6)
      }
      MIN-ACCESS  read-only
      DESCRIPTION
          "The notReady(3) and createAndWait(5) states need
           not be supported. Write access is not required."
     =20
      OBJECT      mplsTunnelResourceStorageType
      SYNTAX      INTEGER { other(1) }
      MIN-ACCESS  read-only
      DESCRIPTION
          "Only other (1) needs to be supported."

      -- mplsTunnelPerfTable
     =20
      OBJECT      mplsTunnelPerfPackets
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelPerfHCPackets
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelPerfErrors
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
      OBJECT      mplsTunnelPerfBytes
      MIN-ACCESS  read-only
      DESCRIPTION



Srinivasan et al.           Expires February 2002           [Page 56]
=0C
Internet Draft                 MPLS TE MIB                August 2001



          "Write access is not required."
     =20
      OBJECT      mplsTunnelPerfHCBytes
      MIN-ACCESS  read-only
      DESCRIPTION
          "Write access is not required."
     =20
   ::=3D { mplsTeCompliances 1 }


-- Units of conformance.

mplsTunnelGroup OBJECT-GROUP
   OBJECTS {
      mplsTunnelIndexNext,
      mplsTunnelName,
      mplsTunnelDescr,
      mplsTunnelOwner,
      mplsTunnelXCPointer,
      mplsTunnelIfIndex,
      mplsTunnelHopTableIndex,
      mplsTunnelARHopTableIndex,
      mplsTunnelCHopTableIndex,
      mplsTunnelAdminStatus,
      mplsTunnelOperStatus,
      mplsTunnelRowStatus,
      mplsTunnelTrapEnable,
      mplsTunnelStorageType,
      mplsTunnelConfigured,
      mplsTunnelActive,
      mplsTunnelPrimaryInstance,
      mplsTunnelPrimaryTimeUp,
      mplsTunnelPathChanges,
      mplsTunnelLastPathChange,
      mplsTunnelCreationTime,
      mplsTunnelStateTransitions,
      mplsTunnelEgressLSRId,
      mplsTunnelIncludeAnyAffinity,
      mplsTunnelIncludeAllAffinity,
      mplsTunnelExcludeAllAffinity,
      mplsTunnelPerfPackets,
      mplsTunnelPerfHCPackets,
      mplsTunnelPerfErrors,
      mplsTunnelPerfBytes,
      mplsTunnelPerfHCBytes,
      mplsTunnelResourcePointer,
      mplsTunnelInstancePriority,
      mplsTunnelPathInUse,
      mplsTunnelRole,
      mplsTunnelTotalUpTime,



Srinivasan et al.           Expires February 2002           [Page 57]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      mplsTunnelInstanceUpTime
   }
   STATUS  current
   DESCRIPTION
        "Necessary, but not sufficient, set of objects to
          implement tunnels.  In addition, depending on the
          type of the tunnels supported (for example,
          manually configured or signaled, persistent or non-
          persistent, etc.), the following other groups
          defined below are mandatory: mplsTunnelManualGroup
          and/or mplsTunnelSignaledGroup,
          mplsTunnelIsNotIntfcGroup and/or
          mplsTunnelIsIntfcGroup."
   ::=3D { mplsTeGroups 1 }

mplsTunnelManualGroup  OBJECT-GROUP
   OBJECTS { mplsTunnelSignallingProto }
   STATUS  current
   DESCRIPTION
        "Object(s) needed to implement manually configured
          tunnels."
   ::=3D { mplsTeGroups 2 }

mplsTunnelSignaledGroup OBJECT-GROUP
   OBJECTS {
      mplsTunnelSetupPrio,
      mplsTunnelHoldingPrio,
      mplsTunnelSignallingProto,
      mplsTunnelLocalProtectInUse,
      mplsTunnelSessionAttributes,
      mplsTunnelHopListIndexNext,
      mplsTunnelHopAddrType,
      mplsTunnelHopIpv4Addr,
      mplsTunnelHopIpv4PrefixLen,
      mplsTunnelHopIpv6Addr,
      mplsTunnelHopIpv6PrefixLen,
      mplsTunnelHopAsNumber,
      mplsTunnelHopLspId,
      mplsTunnelHopType,
      mplsTunnelHopIncludeExclude,
      mplsTunnelHopPathOptionName,
      mplsTunnelHopEntryPathComp,
      mplsTunnelHopRowStatus,
      mplsTunnelHopStorageType
   }
   STATUS  current
   DESCRIPTION
        "Object needed to implement signaled tunnels."
   ::=3D { mplsTeGroups 3 }




Srinivasan et al.           Expires February 2002           [Page 58]
=0C
Internet Draft                 MPLS TE MIB                August 2001



mplsTunnelScalarGroup OBJECT-GROUP
   OBJECTS {
      mplsTunnelConfigured,
      mplsTunnelActive,
      mplsTunnelTEDistProto,
      mplsTunnelMaxHops
   }
   STATUS  current
   DESCRIPTION
        "Scalar object needed to implement MPLS tunnels."
   ::=3D { mplsTeGroups 4 }

mplsTunnelIsIntfcGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsIf }
   STATUS  current
   DESCRIPTION
        "Objects needed to implement tunnels that are
          interfaces."
   ::=3D { mplsTeGroups 5 }

mplsTunnelIsNotIntfcGroup OBJECT-GROUP
   OBJECTS { mplsTunnelIsIf }
   STATUS  current
   DESCRIPTION
        "Objects needed to implement tunnels that are not
          interfaces."
   ::=3D { mplsTeGroups 6 }

mplsTunnelOptionalGroup OBJECT-GROUP
   OBJECTS {
      mplsTunnelResourceIndexNext,
      mplsTunnelResourceMaxRate,
      mplsTunnelResourceMeanRate,
      mplsTunnelResourceMaxBurstSize,
      mplsTunnelResourceMeanBurstSize,
      mplsTunnelResourceExcessBurstSize,
      mplsTunnelResourceFrequency,
      mplsTunnelResourceWeight,
      mplsTunnelResourceRowStatus,
      mplsTunnelResourceStorageType,
      mplsTunnelARHopAddrType,
      mplsTunnelARHopIpv4Addr,
      mplsTunnelARHopIpv4PrefixLen,
      mplsTunnelARHopIpv6Addr,
      mplsTunnelARHopIpv6PrefixLen,
      mplsTunnelARHopAsNumber,
      mplsTunnelCHopAddrType,
      mplsTunnelCHopIpv4Addr,
      mplsTunnelCHopIpv4PrefixLen,
      mplsTunnelCHopIpv6Addr,



Srinivasan et al.           Expires February 2002           [Page 59]
=0C
Internet Draft                 MPLS TE MIB                August 2001



      mplsTunnelCHopIpv6PrefixLen,
      mplsTunnelCHopAsNumber,
      mplsTunnelCHopType
   }
   STATUS  current
   DESCRIPTION
        "The objects in this group are optional."
   ::=3D { mplsTeGroups 7 }
  =20
mplsTunnelCRLDPResOptionalGroup OBJECT-GROUP
   OBJECTS {
      mplsTunnelCRLDPResMeanBurstSize,
      mplsTunnelCRLDPResExcessBurstSize,
      mplsTunnelCRLDPResFrequency,
      mplsTunnelCRLDPResWeight,
      mplsTunnelCRLDPResFlags,
      mplsTunnelCRLDPResRowStatus,
      mplsTunnelCRLDPResStorageType
   }
   STATUS  current
   DESCRIPTION
        "Set of objects implemented for resources applicable
          for tunnels signaled using CR-LDP."
   ::=3D { mplsTeGroups 8 }

mplsTeNotificationGroup NOTIFICATION-GROUP
   NOTIFICATIONS {
      mplsTunnelUp,
      mplsTunnelDown,
      mplsTunnelRerouted,
      mplsTunnelReoptimized
   }
   STATUS  current
   DESCRIPTION
        "Set of notifications implemented in this module.
          None is mandatory."
   ::=3D { mplsTeGroups 9 }

-- End of MPLS-TE-MIB
END


11.   Security Considerations
  =20
   There are a number of management objects defined in this
   MIB that have a MAX-ACCESS clause of read-write and/or
   read-create. Such objects may be considered sensitive or
   vulnerable in some network environments. The support for
   SET operations in a non-secure environment without proper
   protection can have a negative effect on network



Srinivasan et al.           Expires February 2002           [Page 60]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   operations.
  =20
   It is thus important to control even GET access to these
   objects and possibly to even encrypt the values of these
   object when sending them over the network via SNMP. Not
   all versions of SNMP provide features for such a secure
   environment.
  =20
   SNMPv1 by itself is not a secure environment. Even if the
   network itself is secure (for example by using IPSec
   [RFC2401]), there is no control as to who on the secure
   network is allowed to access and GET/SET
   (read/change/create/delete) the objects in this MIB. It is
   recommended that the implementers consider the security
   features as provided by the SNMPv3 framework.
   Specifically, the use of the User-based Security Model
   [RFC2574] and the View- based Access Control [RFC2575] is
   recommended. It is then a customer/user responsibility to
   ensure that the SNMP entity giving access to an instance
   of this MIB, is properly configured to give access to the
   objects only to those principals (users) that have
   legitimate rights to indeed GET or SET
   (change/create/delete) them.


12.   Acknowledgments
  =20
   We wish to thank Adrian Farrel, Eric Gray, Joan Cucchiara,
   Patrick Kerharo, Paul Langille and Mike Piecuch for their
   comments on this draft.


13.   References
  =20
   [Assigned]    Reynolds, J., and J. Postel, "Assigned
                 Numbers", RFC 1700, October 1994. See also:
                 http://www.isi.edu/in-
                 notes/iana/assignments/smi-numbers
  =20
   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C,
                 Viswanathan, A. and H. Sjostrand,
                 "Definition of Textual Conventions and
                 OBJECT-IDENTITIES for Multi-Protocol Label
                 Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-02.txt>, August
                 2001.
  =20
   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switch Router Management
                 Information Base Using SMIv2", Internet



Srinivasan et al.           Expires February 2002           [Page 61]
=0C
Internet Draft                 MPLS TE MIB                August 2001



                 Draft <draft-ietf-mpls-lsr-mib-07.txt>,
                 January 2001.
  =20
   [RSVPTE]      Awaduche, D., Berger, L., Der-Haw, G., Li,
                 T., Swallow, G., and V. Srinivasan,
                 "Extensions to RSVP for LSP Tunnels",
                 Internet Draft <draft-mpls-rsvp-lsp-tunnel-
                 08.txt>, February 2001.
  =20
   [CRLDP]       B. Jamoussi (Editor), "Constraint-Based LSP
                 Setup using LDP", Internet Draft <draft-ietf-
                 mpls-cr-ldp-05.txt>, February 2001.
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for
                 TCP/IP-based Internets", RFC 1155, May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J.
                 Davin, "Simple Network Management Protocol",
                 RFC 1157, May 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps
                 for use with the SNMP", RFC 1215, March
                 1991.
  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Introduction to Community-based
                 SNMPv2", RFC 1901, January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Protocol Operations for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1905, January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Transport Mappings for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1906, January 1996.
  =20
   [RFC2026]     S. Bradner, "The Internet Standards Process
                 -- Revision 3", RFC 2026, October 1996.
  =20
   [RFC2233]     McCloghrie, K. and F. Kastenholtz, "The
                 Interface Group MIB Using SMIv2", RFC 2233,
                 November 1997.
  =20
   [RFC2401]     Kent, S., and Atkinson, R., "Security



Srinivasan et al.           Expires February 2002           [Page 62]
=0C
Internet Draft                 MPLS TE MIB                August 2001



                 Architecture for the Internet Protocol", RFC
                 2401, November 1998.
  =20
   [RFC2570]     Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction to Version 3 of the
                 Internet-standard Network Management
                 Framework", RFC 2570, April 1999.
  =20
   [RFC2571]     Harrington, D., Presuhn, R., and B. Wijnen,
                 "An Architecture for Describing SNMP
                 Management Frameworks", RFC 2571, April
                 1999.
  =20
   [RFC2572]     Case, J., Harrington D., Presuhn R., and B.
                 Wijnen, "Message Processing and Dispatching
                 for the Simple Network Management Protocol
                 (SNMP)", RFC 2572, April 1999.
  =20
   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2573, April 1999.
  =20
   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based
                 Security Model (USM) for version 3 of the
                 Simple Network Management Protocol
                 (SNMPv3)", RFC 2574, April 1999.
  =20
   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie,
                 "View-based Access Control Model (VACM) for
                 the Simple Network Management Protocol
                 (SNMP)", RFC 2575, April 1999.
  =20
   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Structure of Management Information Version
                 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  =20
   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Textual Conventions for SMIv2", STD 58, RFC
                 2579, April 1999.
  =20
   [RFC2702]     Awduche, D., Malcolm, J., Agogbua, J.,
                 O'Dell, M., and J. McManus, "Requirements
                 for Traffic Engineering Over MPLS", RFC
                 2702, September 1999.
  =20
   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Conformance Statements for SMIv2", STD 58,
                 RFC 2580, April 1999.



Srinivasan et al.           Expires February 2002           [Page 63]
=0C
Internet Draft                 MPLS TE MIB                August 2001



  =20
   [RFC2851]     Daniele, M., Haberman, B., Routhier, S., and
                 J. Schoenwaelder, "Textual Conventions for
                 Internet Network Addresses", RFC 2851, June
                 2000.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching
                 Architecture", RFC 3031, January 2001.


14.   Authors' Addresses

  Cheenu Srinivasan
  Alphion Corp.
  4 Industrial Way West
  Eatontown, NJ 07724
  Phone: +1-732-676-7066
  Email: cheenu@alphion.com

  Arun Viswanathan
  Force10 Networks, Inc.
  1440 McCarthy Blvd
  Milpitas, CA 95035
  Phone: +1-408-571-3516
  Email: arun@force10networks.com

  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051
  Email: tnadeau@cisco.com


15.   Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights
   Reserved.
  =20
   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed



Srinivasan et al.           Expires February 2002           [Page 64]
=0C
Internet Draft                 MPLS TE MIB                August 2001



   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.
  =20
   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.






































Srinivasan et al.           Expires February 2002           [Page 65]

------=_NextPart_000_0003_01C12CB1.E1BCE0D0--



From owner-mpls@UU.NET  Fri Aug 24 15:47:54 2001
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 PAA13796
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 15:47:54 -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 QQldmt09831;
	Fri, 24 Aug 2001 19:48:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldmt17952
	for mpls-outgoing; Fri, 24 Aug 2001 19:48:38 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 QQldmt17945
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 19:48:28 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 QQldmt23864
	for <mpls@UU.NET>; Fri, 24 Aug 2001 19:46:01 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 QQldmt05314
	for <mpls@UU.NET>; Fri, 24 Aug 2001 19:46:01 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 PAA10330
	for <mpls@UU.NET>; Fri, 24 Aug 2001 15:45:57 -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 PAA03785
	for <mpls@UU.NET>; Fri, 24 Aug 2001 15:45:58 -0400 (EDT)
Message-ID: <3B86AEF3.14FFA0B3@marconi.com>
Date: Fri, 24 Aug 2001 15:45:55 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE packet loss
References: <72702AB72C89D511A9E70008C791736801172FE1@MSTELEFONICA3>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> .....RSVP-TE runs over UDP so it is less reliable than CR-LDP who
> runs over TCP......

This is completely untrue.

1: RSVP runs as raw IP (protocol 46), not over UDP.  UDP
   encapsulation is only supposed to be used by nodes that are
   incapable of generating or receiving the raw IP datagrams.

2: Not using TCP does not make RSVP unreliable.  By this logic you
   might as well claim that IS-IS is an unreliable routing protocol
   because it doesn't use TCP either.  It doesn't even use IP, for
   that matter.

   Not using TCP simply means that RSVP must implement its own
   mechanisms for reliability.  The use of soft-state is one such
   mechanism.  The message ID/ack components of the refresh reduction
   extensions are another.

   Use of TCP simply means that LDP is offloading its reliability
   features onto the OS's protocol stack.  This has some benefits
   and it has some drawbacks.

> I read about some enhancements to RSVP-TE for allowing it to
> recover from packet loss in time frame comparable with those of
> TCP.

Read RFC 2961: RSVP Refresh Overhead Reduction Extension.

Among its components, this extension has a mechanism for reliable RSVP
message delivery that greatly improves (over just using soft state) the
recovery time due to packet loss.

-- David


From owner-mpls@UU.NET  Fri Aug 24 16:44:20 2001
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 QAA15106
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 16:44:20 -0400 (EDT)
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 QQldmx19405;
	Fri, 24 Aug 2001 20:45:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldmw10716
	for mpls-outgoing; Fri, 24 Aug 2001 20: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 QQldmw10709
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 20:44:28 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 QQldmw09162
	for <mpls@uu.net>; Fri, 24 Aug 2001 20:44:05 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.telefonica.com.ar [168.226.49.11])
	id QQldmw17978
	for <mpls@uu.net>; Fri, 24 Aug 2001 20:44:05 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <RRN1QB4C>; Fri, 24 Aug 2001 17:43:01 -0300
Message-ID: <72702AB72C89D511A9E70008C7917368012603A1@MSTELEFONICA3>
From: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
To: mpls@UU.NET
Subject: rsvp paquet loss
Date: Fri, 24 Aug 2001 17:42:24 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

......RSVP-TE runs over UDP so its said to be less 
reliable than CR-LDP who runs over TCP........

Is there some enhancements that allow RSVP-TE 
to recover from packet loss in time frame comparable
with those of TCP?????

Regards.

Sergio Fabris


From owner-mpls@UU.NET  Fri Aug 24 17:23:54 2001
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 RAA15788
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 17:23:54 -0400 (EDT)
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 QQldmz06137;
	Fri, 24 Aug 2001 21:24:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldmz02584
	for mpls-outgoing; Fri, 24 Aug 2001 21:24:21 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 QQldmz02577
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 21:24: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 QQldmz25595
	for <mpls@uu.net>; Fri, 24 Aug 2001 21:23:01 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldmz04072
	for <mpls@uu.net>; Fri, 24 Aug 2001 21:23:02 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10190 for mpls@uu.net; Fri, 24 Aug 2001 17:23:00 -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 QQldmz02480
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 24 Aug 2001 21:22: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 QQldmz20363
	for <mpls@UU.NET>; Fri, 24 Aug 2001 21:21:02 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQldmz01789
	for <mpls@UU.NET>; Fri, 24 Aug 2001 21:21:02 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA13711;
	Fri, 24 Aug 2001 17:21:01 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA03947; Fri, 24 Aug 2001 17:21:00 -0400 (EDT)
Message-Id: <200108242121.RAA03947@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: Fabris Sergio <fabriss@TELEFONICA.COM.AR>
cc: mpls@UU.NET
Subject: Re: rsvp paquet loss 
In-reply-to: Your message of "Fri, 24 Aug 2001 17:42:24 -0300."
             <72702AB72C89D511A9E70008C7917368012603A1@MSTELEFONICA3> 
Date: Fri, 24 Aug 2001 17:21:00 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

And I might add that unlike TCP, RFC 2961, allows other messages to
flow while the lost message is recovered.  Since RSVP is idempotent,
the other messages can be safely processed.  So at a time of heavy
load and message lost, I would expect RSVP / RFC 2961 to be able to
perform better than CR-LDP (but so far that's just a gadunken(sp?)
experiment.)

...George


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



From owner-mpls@UU.NET  Fri Aug 24 20:52:27 2001
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 UAA17577
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 20:52: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 QQldnn04068;
	Sat, 25 Aug 2001 00:53:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldnn11383
	for mpls-outgoing; Sat, 25 Aug 2001 00:53: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 QQldnn11378
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 00:53:09 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 QQldnn16758
	for <mpls@UU.NET>; Sat, 25 Aug 2001 00:53:06 GMT
Received: from zaprlpro-pop3-1.icommand.co.za by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: zaprlpro-pop3-1.icommand.co.za [196.14.176.6])
	id QQldnn20470
	for <mpls@UU.NET>; Sat, 25 Aug 2001 00:53:02 GMT
Received: (qmail 192475 invoked from network); 25 Aug 2001 00:53:34 -0000
Received: from unknown (HELO zaprlpro-sm-1) (172.17.2.240)
  by zaprlpro-pop3-1.conexys.co.za with SMTP; 25 Aug 2001 00:53:34 -0000
Received: from host.secure4-hosting.net (host.secure4-hosting.net [209.239.41.31])
	by zaprlpro-pop3-1.icommand.co.za (Postfix) with ESMTP id 6C93FA33
	for <navin@xsinet.co.za>; Tue, 14 Aug 2001 08:01:13 -0200 (GMT+2)
Received: (from mplsrc12@localhost)
	by host.secure4-hosting.net (8.10.2/8.10.2) id f7E5xOH09995;
	Tue, 14 Aug 2001 01:59:24 -0400
X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
Message-ID: <751B6DD7A243D511AB9F0002557C5687ACC6A9@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Traffic Engineering TLV
Date: Tue, 14 Aug 2001 11:32:22 +0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1248A.E01872F0"
X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/2244
X-Loop: mpls-ops@mplsrc.com
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_01C1248A.E01872F0
Content-Type: text/plain;
	charset="iso-8859-1"



Hello 

         The draft-katz-yeung-ospf-traffic-04.txt section 2.5.8 specifies 

          2.5.8. Unreserved Bandwidth

   	The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
   	not yet reserved at each of the eight priority levels, in IEEE
   	floating point format.  Each value will be less than or equal to the
  	 maximum reservable bandwidth.  The units are bytes per second.

   	The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in
   	length.


            Can anyone please tell me what are these 8 priority levels and
what for these 
            used ? why we need this.
          
Thanks in Advance
Ashwin





------_=_NextPart_001_01C1248A.E01872F0
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>Traffic Engineering TLV</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
draft-katz-yeung-ospf-traffic-04.txt section 2.5.8 specifies </FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2.5.8. Unreserved Bandwidth</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
The Unreserved Bandwidth sub-TLV<B> specifies the amount of =
bandwidth</B></FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp; not yet reserved at each of the eight priority =
levels,</FONT></B> <FONT SIZE=3D2 FACE=3D"Arial">in IEEE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
floating point format.&nbsp; Each value will be less than or equal to =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maximum reservable =
bandwidth.&nbsp; The units are bytes per second.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets =
in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; =
length.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Can anyone please tell me what are these 8 priority levels =
and what for these </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; used ? why we need this.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks in Advance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ashwin</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1248A.E01872F0--

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml




From owner-mpls@UU.NET  Fri Aug 24 20:52:36 2001
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 UAA17588
	for <mpls-archive@lists.ietf.org>; Fri, 24 Aug 2001 20:52:36 -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 QQldnn21422;
	Sat, 25 Aug 2001 00:53:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldnn11394
	for mpls-outgoing; Sat, 25 Aug 2001 00:53: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 QQldnn11389
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 00:53:20 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 QQldnn08969
	for <mpls@UU.NET>; Sat, 25 Aug 2001 00:53:03 GMT
Received: from zaprlpro-pop3-1.icommand.co.za by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: zaprlpro-pop3-1.icommand.co.za [196.14.176.6])
	id QQldnn20394
	for <mpls@UU.NET>; Sat, 25 Aug 2001 00:53:00 GMT
Received: (qmail 192468 invoked from network); 25 Aug 2001 00:53:30 -0000
Received: from unknown (HELO zaprlpro-sm-1) (172.17.2.240)
  by zaprlpro-pop3-1.conexys.co.za with SMTP; 25 Aug 2001 00:53:30 -0000
Received: from host.secure4-hosting.net (host.secure4-hosting.net [209.239.41.31])
	by zaprlpro-pop3-1.icommand.co.za (Postfix) with ESMTP id 9F9981359
	for <navin@xsinet.co.za>; Mon, 13 Aug 2001 16:56:27 -0200 (GMT+2)
Received: (from mplsrc12@localhost)
	by host.secure4-hosting.net (8.10.2/8.10.2) id f7DEx6M20472;
	Mon, 13 Aug 2001 10:59:06 -0400
X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
Message-ID: <3B77EB76.735DA1E8@sasken.com>
Date: Mon, 13 Aug 2001 20:30:07 +0530
From: Rajesh P Jain <rpjain@sasken.com>
Organization: SASKEN Communication Technologies Ltd
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS UUNET Mailing List <mpls@UU.NET>, mpls-ops@mplsrc.com
Subject: Doubt on Make Before Break Concept
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/2233
X-Loop: mpls-ops@mplsrc.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
                    I have some doubts on Smooth Re-Routing of LSP
Tunnels.

1. As I understand the draft, the make-before-break (Smooth Re-Routing)
should be initiated by the Sender Node (Path Message is sent new with
new ERO object and ofcourse with a different LSP ID in the
SENDER_TEMPLATE ). The receiver receives this Path Message.

2. Now, the receiver HAS to send a RESERVE message with SE reservation
style (Of course with Filter spec list containing the SENDER_TEMPLATE of
the old Path Message and SENDER_TEMPLATE of new Path Message i.e they
differ only in their LSP ID's, and of course ERO's).

3. Now, the New Path Message received  is AS GOOD AS A New Sender for
this receiver and hence it MAY NOT send a RESERVE Message for this
sender (The receiver sends only if it wants some reservation for this
sender).

4. In case, if the receiver chooses not to send the reserve message,
then Smooth Re-Route WILL NOT happen.

                    So, can anyone explain whether the Smooth Re-Routing
is Sender-Based  or Receiver -Based (Who has the control of Re-Routing
the traffic ??) ???

                    In case of Increase in Band-width (For a particular
LSP), the Sender indicates the increase in band-width BUT still the
Receiver HAS to send the Reserve message for this increase in the
Band-width. So, the same problem holds good for this case also????

                    Am I missing something???? Please throw light on
this issue possibly with an example.

TIA
        Rajesh P Jain



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml




From owner-mpls@UU.NET  Sat Aug 25 08:57:53 2001
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 IAA10787
	for <mpls-archive@lists.ietf.org>; Sat, 25 Aug 2001 08:57:52 -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 QQldpj04851;
	Sat, 25 Aug 2001 12:58:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldpj08712
	for mpls-outgoing; Sat, 25 Aug 2001 12:58: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 QQldpj08706
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 12:58:31 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 QQldpj16097
	for <mpls@UU.NET>; Sat, 25 Aug 2001 12:57:25 GMT
Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.120.127.220])
	id QQldpj28321
	for <mpls@UU.NET>; Sat, 25 Aug 2001 12:57:25 GMT
Received: from xyx ([202.120.127.81])
	by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id VAA10707;
	Sat, 25 Aug 2001 21:01:09 +0800 (CST)
Message-ID: <001501c12d65$ff508b60$517f78ca@xyx>
From: "Xu Yingxiao" <xyx@yc.shu.edu.cn>
To: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
References: <Pine.SUN.3.96.1010824065408.10055A-100000@grex.cyberspace.org>
Subject: Re: MPLS, Active Network and Active routing
Date: Sat, 25 Aug 2001 21:00:48 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA10787


----- Original Message ----- 
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: <xyx@yc.shu.edu.cn>
Cc: <mpls@UU.NET>; <mpls-ops@mplsrc.com>
Sent: Friday, August 24, 2001 7:00 PM
Subject: Re: MPLS, Active Network and Active routing


> Hi Xu,
> Active Networks allow their "clients" to inject customized programs into
> the nodes (routers/switches) of the network, e.g. packets are more
> "generic capsules or program fragments" that are executed at each network
> router/switch they traverse. 
> In one sense the "label" values in the MPLS packet, is an "information
> piece" which is interpreted wisely at any node(here MPLS LSR). But this
> "intelligence" at LSR which enables it to determine label swapping and
> forwarding operation, has been known at the time of LDP sessions. Only one
> label determines the QoS treatment, the next hop, the TE decisions. In
> this sense we can see MPLS to be somewhat "active". The basic idea behind
> MPLS was to make the FR/ATM switches more "intelligent" using the IP
> routing software.
> MPLS also incorporates strong OAM, QoS and Traffic Engineering
> capabilities. Any network which minimizes the complexity of the "End user"
> and maximizes intelligence in "core" is active network.
> Any thoughts or suggestions, if I am going in wrong direction ?
> 
> Regards,
> Hemant
> 
> 
> Date: Fri, 24 Aug 2001 16:29:27 +0800
> From: Xu Yingxiao <xyx@yc.shu.edu.cn>
> To: mpls@UU.NET
> 
> I am studying on MPLS and Active Network.
> I think, broadly speeking, MPLS is a kind of active network as it is
> active in processing packets.
> But it is not active network as we normally thought of, as MPLS Nodes was
> not designed with structure of Active network.
> 
> And active routing is selecting routes actively. It can be realized in
> Active network, also it can be realized using MPLS.
> 
> Any idea is welcome.
> 


From owner-mpls@UU.NET  Sat Aug 25 08:58:23 2001
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 IAA10816
	for <mpls-archive@lists.ietf.org>; Sat, 25 Aug 2001 08:58:23 -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 QQldpj01590;
	Sat, 25 Aug 2001 12:59:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldpj08732
	for mpls-outgoing; Sat, 25 Aug 2001 12:59: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 QQldpj08727
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 12:59:05 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 QQldpj07033
	for <mpls@uu.net>; Sat, 25 Aug 2001 12:58:54 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldpj04776
	for <mpls@uu.net>; Sat, 25 Aug 2001 12:58:53 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA17755 for mpls@uu.net; Sat, 25 Aug 2001 08:58:52 -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 QQldpj08707
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 12:58:31 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 QQldpj16114
	for <mpls@uu.net>; Sat, 25 Aug 2001 12:57:25 GMT
Received: from 8848.net by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [211.99.202.115])
	id QQldpj01902
	for <mpls@uu.net>; Sat, 25 Aug 2001 12:57:23 GMT
Received: from 8848.net([10.1.0.100]) by 8848.net(JetMail 2.5.3.0)
	with SMTP id jmc3b880d04; Sat, 25 Aug 2001 12:55:31 -0000
Received: from cmr1.ash.ops.us.uu.net([198.5.241.39]) by 8848.net(JetMail 2.5.3.0)
	with SMTP id jm1a3b82b2bb; Tue, 21 Aug 2001 18:55:21 -0000
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 QQldbn14034;
	Tue, 21 Aug 2001 18:56:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldbn01688
	for mpls-outgoing; Tue, 21 Aug 2001 18:55: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 QQldbn01679
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:55: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 QQldbn16090
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:54:56 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldbn10960
	for <mpls@uu.net>; Tue, 21 Aug 2001 18:54:55 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA22572 for mpls@uu.net; Tue, 21 Aug 2001 14:54:54 -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 QQldbn01458
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 21 Aug 2001 18:54:34 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 QQldbn07986
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:53:47 GMT
Received: from ray.riverstonenet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldbn21937
	for <mpls@UU.NET>; Tue, 21 Aug 2001 18:53:46 GMT
Received: from localhost (root@localhost)
	by ray.riverstonenet.com (8.11.2/8.11.2) with ESMTP id f7LInUY01440;
	Tue, 21 Aug 2001 11:49:30 -0700
Date: Tue, 21 Aug 2001 11:49:30 -0700 (PDT)
From: Ray Qiu <rayq@riverstonenet.com>
X-X-Sender:  <root@ray.riverstonenet.com>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
To: Anoop Ghanwani <anoop@cosinecom.com>
cc: Eric W Gray <ewgray@mindspring.com>,
        Alexander Marhold <alexander@marhold.at>,
        MultiProtocol Label Switching Mailing List <mpls@UU.NET>
Subject: RE: Time to live
In-Reply-To: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng>
Message-ID: <Pine.LNX.4.33.0108211144150.1223-100000@ray.riverstonenet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Anoop,

The no-decrement-TTL option making the LSP appear as a one-hop router to
diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.

Also, you gave us a routing loop example, that should not happen all the
time, right?  :)  So I really don't think it will affect your network
performance.

Thanks,
Ray

On Tue, 21 Aug 2001, Anoop Ghanwani wrote:

> Date: Tue, 21 Aug 2001 11:27:57 -0700
> From: Anoop Ghanwani <anoop@cosinecom.com>
> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
> Cc: Alexander Marhold <alexander@marhold.at>,
>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> Subject: RE: Time to live
>
>
> I think that's a really bad idea.  TTL is there to
> protect the network from packets that might be in a loop.
> Nesting TTLs to that the outer one is used within the
> tunnel while the inner one stays the same could
> delay the time the it takes for TTL to protect the packet.
>
> For instance, consider the following topology.
>
> r1 -- r2 -- r3 -- r4 -- r5
>        |                 |
>       r9 -- r8 -- r7 -- r6
>
> Let's say the path from r3 to r8 is implemented by a
> tunnel (in pipe mode).  The packet first hits r2, enters
> the tunnel at r3, and then gets to r8. r3-r8 is treated as
> a single hop because the TTL in the IP header is only
> decremented by 1.  In this example the looping packet
> gets to traverse the loop many more times than it
> would have if we were just operating on TTL as specified
> in RFC 3032 (> 60 times versus < 30 times).
>
> Thus far, the argument in favor of hiding TTL has been
> that it helps hide the network topology and gives the user
> a perception of traversing fewer hops.  It seems like
> a lame reason because the real measure of performance
> is actually latency.
>
> Just my $0.02 ;-)
> -Anoop
>
>
> > -----Original Message-----
> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
> <mailto:rayq@riverstonenet.com> ]
> > Sent: Tuesday, August 21, 2001 10:26 AM
> > To: Eric W Gray
> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> > Subject: Re: Time to live
> >
> >
> > There is also an option that we don't copy the MPLS TTL back
> > to IP TTL.
> > It makes IP think the MPLS LSP is only one hop.
> >
> > Thanks,
> > Ray
> >
> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >
> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> > > From: Eric W Gray <ewgray@mindspring.com>
> > > To: Alexander Marhold <alexander@marhold.at>,
> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> > > Subject: Re: Time to live
> > >
> > > Below, the last sentence was supposed to be "Note that Frame
> > > Relay ..."
> > >
> > > --
> > > Eric Gray
> > >
> > > Eric W Gray wrote:
> > >
> > > > Alexander,
> > > >
> > > >     No cigar.  The distinction is not cell verses frame,
> > but rather
> > > > whether or not it is possible to incorporate the label in the L2
> > > > encapsulation.  Where this is possible, ATM and FR, there is
> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> > > > Relay is Frame based...
> > > >
> > > > --
> > > > Eric Gray
> > > >
> > > > You wrote:
> > > >
> > > > > Hello
> > > > > I want to explain the mechanism a little bit more in detail
> > > > >
> > > > > FRAME based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > into the TTL-field of
> > > > > the label header.
> > > > > 2. the label-TTL is decremented at each hop by 1
> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> > > > > TTL-exceeded-ICMP message will be sent if possible
> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> > > > >
> > > > > CELL based general:
> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> > into the TTL-field of
> > > > > the label header.
> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
> > decrements the TTL by 1
> > > > > 1b              or by the amount of ATM_MPLS hops of
> > the LSP ( this he knows from the
> > > > > LSP-setup using downstream on demand label allocation
> > and ordered
> > > > > lsp-control label setup)
> > > > > 2. then the packet is chopped into cells
> > > > > 3. the egress reassembles the packet and copies the
> > label ttl back into the
> > > > > IP-TTL
> > > > >
> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
>
> > > > >
> > > > > special features:
> > > > > a) on cisco LSRs there is the possibility to disable
> > the copying of the
> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> > > > > on the egress the smaller of the 2 TTL-values ( label
> > and IP-header) will be
> > > > > used for the IP-TTL
> > > > > then for traceroute the MPLS cloud looks like a 1-hop
> > (2-hop with PHP)
> > > > > network
> > > > >
> > > > > with best regards
> > > > >
> > > > > Alexander
> > > > >
> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> > > > >      __/
> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> > > > >   __/   Core & IP Services <Senior Consultant>
> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> > > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
> <mailto:owner-mpls@UU.NET> ]On Behalf Of
> > > > > Asim.Khan@vf.vodafone.co.uk
> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> > > > > To: c-david.escobar@wcom.com
> > > > > Cc: mpls@UU.NET
> > > > > Subject: RE: Time to live
> > > > >
> > > > > It stays the same. The routers only look at the label
> > value not the IP
> > > > > header. When the packet leaves MPLS domain then the
> > normal operation would
> > > > > apply.
> > > > >
> > > > > Asim
> > > > >
> > > > > -----Original Message-----
> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
> <mailto:c-david.escobar@wcom.com> ]
> > > > > Sent: 21 August 2001 17:19
> > > > > To: mpls@UU.NET
> > > > > Subject: Time to live
> > > > >
> > > > > Hi;
> > > > > What happens to the TTL field in the IP header when a
> > labeled packet goes
> > > > > through an LSP? Is it decreased at each router or stay the same?
>
> > >
> >
> ########################################################################
> ############################## This email communication may contain
> CONFIDENTIAL INFORMATION and is intended only for the use of the
> intended recipients identified above.  If you are not the intended
> recipient of this communication, you must not use, disclose, distribute,
> copy or print this email. If you have received this communication in
> error, please immediately notify the sender by reply email, delete the
> communication and destroy all copies.
> ########################################################################
> ##############################
>
>



From owner-mpls@UU.NET  Sat Aug 25 09:03:52 2001
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 JAA10900
	for <mpls-archive@lists.ietf.org>; Sat, 25 Aug 2001 09:03:52 -0400 (EDT)
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 QQldpk19770;
	Sat, 25 Aug 2001 13:05:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldpk19615
	for mpls-outgoing; Sat, 25 Aug 2001 13:04:43 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 QQldpk19586
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 25 Aug 2001 13:04:41 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 QQldpk17960
	for <mpls@UU.NET>; Sat, 25 Aug 2001 13:04:31 GMT
Received: from yc.shu.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.120.127.220])
	id QQldpk09911
	for <mpls@UU.NET>; Sat, 25 Aug 2001 13:04:13 GMT
Received: from xyx ([202.120.127.81])
	by yc.shu.edu.cn (8.9.3+Sun/8.9.1) with SMTP id VAA10826;
	Sat, 25 Aug 2001 21:08:09 +0800 (CST)
Message-ID: <002e01c12d66$eee3b8a0$517f78ca@xyx>
From: "Xu Yingxiao" <xyx@yc.shu.edu.cn>
To: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
References: <Pine.SUN.3.96.1010824065408.10055A-100000@grex.cyberspace.org> <001501c12d65$ff508b60$517f78ca@xyx>
Subject: Re: MPLS, Active Network and Active routing
Date: Sat, 25 Aug 2001 21:07:45 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA10900

I think the key of active network is not minimizes the complexity of the 
"End user", but only intelligence in "core" .

In this point, MPLS is active because of its ability in explictit routing.
In active network with programmable hardware level, active package 
take different ID to indicate the switch/router how to deal with it.
In MPLS, package using lable to indicate the LSR how to forward it( LSP, QoS etc.)

The only confusing problem is that, in active network with either package level or
 programmable hardware level ,  active nodes can accept code sent by user. 
But MPLS LSR can't.

And, the defacto standard of active network is ANEP, while no MPLS document ever
mention of ANEP.


----- Original Message ----- 
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: <xyx@yc.shu.edu.cn>
Cc: <mpls@UU.NET>; <mpls-ops@mplsrc.com>
Sent: Friday, August 24, 2001 7:00 PM
Subject: Re: MPLS, Active Network and Active routing


> Hi Xu,
> Active Networks allow their "clients" to inject customized programs into
> the nodes (routers/switches) of the network, e.g. packets are more
> "generic capsules or program fragments" that are executed at each network
> router/switch they traverse. 
> In one sense the "label" values in the MPLS packet, is an "information
> piece" which is interpreted wisely at any node(here MPLS LSR). But this
> "intelligence" at LSR which enables it to determine label swapping and
> forwarding operation, has been known at the time of LDP sessions. Only one
> label determines the QoS treatment, the next hop, the TE decisions. In
> this sense we can see MPLS to be somewhat "active". The basic idea behind
> MPLS was to make the FR/ATM switches more "intelligent" using the IP
> routing software.
> MPLS also incorporates strong OAM, QoS and Traffic Engineering
> capabilities. Any network which minimizes the complexity of the "End user"
> and maximizes intelligence in "core" is active network.
> Any thoughts or suggestions, if I am going in wrong direction ?
> 
> Regards,
> Hemant
> 
> 
> Date: Fri, 24 Aug 2001 16:29:27 +0800
> From: Xu Yingxiao <xyx@yc.shu.edu.cn>
> To: mpls@UU.NET
> 
> I am studying on MPLS and Active Network.
> I think, broadly speeking, MPLS is a kind of active network as it is
> active in processing packets.
> But it is not active network as we normally thought of, as MPLS Nodes was
> not designed with structure of Active network.
> 
> And active routing is selecting routes actively. It can be realized in
> Active network, also it can be realized using MPLS.
> 
> Any idea is welcome.
> 



From owner-mpls@UU.NET  Sun Aug 26 02:02:33 2001
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 CAA29615
	for <mpls-archive@lists.ietf.org>; Sun, 26 Aug 2001 02:02:31 -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 QQldsa03496;
	Sun, 26 Aug 2001 06:03:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldsa13939
	for mpls-outgoing; Sun, 26 Aug 2001 06:03:06 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 QQldsa13927
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 26 Aug 2001 06:02:52 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 QQldsa12428
	for <mpls@UU.NET>; Sun, 26 Aug 2001 06:00:58 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 QQldsa11498
	for <mpls@UU.NET>; Sun, 26 Aug 2001 06:00:59 GMT
Received: from juniper.net ([172.16.167.235])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7Q601079798;
	Sat, 25 Aug 2001 23:00:05 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B8890AE.2090105@juniper.net>
Date: Sat, 25 Aug 2001 23:01:18 -0700
From: Ping Pan <pingpan@juniper.net>
Organization: Juniper Networks
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; m18) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
CC: bill.sanford@netplane.com, cmartin@gnilink.net, mpls@UU.NET
Subject: Here we go again (Re: RSVP Hello)
References: <B9571FDEBD3DD21181E500606DD5EE050E89164B@mbddmknt01.hc.bt.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

neil.2.harrison@bt.com wrote:


> So, for example, whether I run layer network technology 'X' using RSVP-TE,
> CR-LDP, PNNI, sig_prot_Y or indeed *no* signalling protocols I want the OAM
> for the data-plane trails that carry the customer traffic to be independent
> of the signalling protocol choice. This will be true in the case of SDH VC-4
> trails say, but it is unfortunately not true for MPLS LSPs since we don't
> have any decent MPLS data-plane OAM agreed yet.
> 
> This mail thread is mixing different signalling protocol functionality as
> proxies for data-plane failures, and a previous discussion on the
> draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
> principle by binding specific client/server layer OAM functionality to a
> specific control-plane signalling protocol.
> 

Sigh,,, after reading through this mail, I can relate to the feeling 
some people have on MPLS, that is, it's an ATM replacement. :-( I really 
hope not.

Normally, the buzzwords such as "layers", "principles" and 
"architectures" are defined to make it easier to describe things. They 
are not defined to create new religions. Sometimes, they are more useful 
to marketing than to engineering. So if something is useful to the 
Internet, we try to come up with a simple solution and just build it. 
There is no magic to this process. So instead of talking about how I 
have broken the layers, principles, architectures and religious rules in 
LSP-ping, tell me why it does not work for the purpose it was designed for.

> During the discussion of the Ping draft, I know Yakov described what I have
> discussed above as 'working on LTSFGTC' (long-term solutions for generations
> to come)...or something like that......but if we want MPLS itself to be a
> LTSFGTC (and hopefully also give some solid foundation for those working in
> the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
> architectural tenets right at the outset. 

If OAM is a great LTSFGTC, then there is nothing to be worried about on 
this "narrow-focused" LSP-ping. We do our work, and you do yours. What a 
beautiful thing!

> Proper data-plane OAM, and its
> decoupling from other client/server layer data-planes and/or specific
> control (or management) plane protocols is not a 'luxury item', its just
> plain common sense to avoid problems down the road.
> 

It's also a common sense that in order to make MPLS working in the 
Internet, we need to keep it simple.

Regards,

- Ping




From owner-mpls@UU.NET  Sun Aug 26 02:06:27 2001
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 CAA04051
	for <mpls-archive@lists.ietf.org>; Sun, 26 Aug 2001 02:06:27 -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 QQldsa11471;
	Sun, 26 Aug 2001 06:07:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldsa22494
	for mpls-outgoing; Sun, 26 Aug 2001 06:07: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 QQldsa22454
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 26 Aug 2001 06:07:01 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 QQldsa21762
	for <mpls@uu.net>; Sun, 26 Aug 2001 06:05:12 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldsa16727
	for <mpls@uu.net>; Sun, 26 Aug 2001 06:05:13 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA29502 for mpls@uu.net; Sun, 26 Aug 2001 02:05:10 -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 QQldsa14586
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 26 Aug 2001 06:04:56 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 QQldsa29624
	for <mpls@UU.NET>; Sun, 26 Aug 2001 06:04:28 GMT
Received: from tlv1.axerra.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [192.114.163.169])
	id QQldsa15873
	for <mpls@UU.NET>; Sun, 26 Aug 2001 06:04:29 GMT
Received: by TLV1 with Internet Mail Service (5.5.2653.19)
	id <P03KZQRJ>; Sun, 26 Aug 2001 09:02:27 +0200
Message-ID: <AF5018AC03D1D411ABB70002A50913263AD955@TLV1>
From: Sasha Vainshtein <Sasha@AXERRA.com>
To: "'Mark Seery'" <mark@bravara.com>,
        "Kota, Ravikumar"
	 <RKota@cratosnetworks.com>,
        "'Srinivas T M'" <srini_tm@yahoo.com>, mpls@UU.NET
Cc: Akiva Sadovski <akiva@AXERRA.com>, Alik Shimelmits <alik@AXERRA.com>,
        Israel Sasson <israel@AXERRA.com>
Subject: RE: e-lsp & l - lsp
Date: Sun, 26 Aug 2001 09:02:27 +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

IMHO, a very good justification for E-LSPs and L-LSPs is provided
in Appendix A "Example Deployment Scenarios" of the said draft.

Specifically, consider the use case when a SP upgrades a Diffserv-enabled IP
network to an MPLS-enabled one. Such a process should guarantee
at least backwards compatibility with minimal effort. Appendix A
sugests the following approach: 
* As far as connectivity is concerned, vanilla LDP (RFC 3036) guarantees
that
the upgraded network possesses at least the same connectivity as the
original one
* If a small (<= 8) number of OAs has been originally deployed, then
preconfigured EXP<-->PHB mapping would be sufficient to guarantee
complete backwards compatibility with the Diffserv behavior of the
original network by converting each hop-by-hop routed LSP into
an E-LSP for the specified OAs. While such a convertion is limited,
it may be quite practical for a network originally supporting only a
small number of OAs (including BE, at least one more class for separating
 CS-based OAs into two different groups and a small number of other PHBs)

Once the upgrade has been successfully completed, the SP can enhance
the network in two ways:
* Deploy MPLS-specific features (traffic engineering, fast reroute etc.)
while preserving its Diffserv behavior
* Deploy new OAs (e.g. miltiple AF instances with different markers,
thresholds etc.). This will be done by explicit engineering of L-LSPs
as the number of OAS supported by the network hrows.



With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axerra.com> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Mark Seery [mailto:mark@bravara.com]
> Sent: Thursday, August 23, 2001 12:33 AM
> To: Kota, Ravikumar; 'Srinivas T M'; mpls@UU.NET
> Subject: RE: e-lsp & l - lsp
> 
> 
> >>  e-lsp intended for carrying single OA for single LSP. 
> l-lsp is intended
> for carrying multiple OA s for LSP.
> 
> I believe it is the other way.
> 
> From the below mentioned draft:
> 
> "1.2 EXP-Inferred-PSC LSPs (E-LSP)
> 
>    A single LSP can be used to support one or more OAs. Such LSPs can
>    support up to eight BAs of a given FEC, regardless of how many OAs
>    these BAs span. With such LSPs, the EXP field of the MPLS Shim
>    Header is used by the LSR to determine the PHB to be applied to the
>    packet. This includes both the PSC and the drop preference......."
> 
> "1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
> 
>    A separate LSP can be established for a single <FEC, OA> pair.
>    With such LSPs, the PSC is explicitly signaled at label
>    establishment time so that, after label establishment, the LSR can
>    infer exclusively from the label value the PSC to be applied to a
>    labeled packet. When the Shim Header is used, the Drop 
> Precedence to
>    be applied by the LSR to the labeled packet, is conveyed inside the
>    labeled packet MPLS Shim Header using the EXP field. When the Shim
>    Header is not used (e.g. MPLS Over ATM), the Drop Precedence to be
>    applied by the LSR to the labeled packet is conveyed 
> inside the link
>    layer header encapsulation using link layer specific drop 
> precedence
>    fields (e.g. ATM CLP)....."
> 
> Additional comments:
> 
> A number of existing layer 2 technologies (e.g. ATM) can only 
> support L-LSP
> because of their inability to carry the equivalent of a full 
> EXP field (drop
> precedence can be indicated).
> 
> Some people have argued that in the context of 
> diffserv/traffic engineering
> support only L-LSPs would be used - I leave this argument as 
> an exercise for
> the reader.
> 
> E-LSPs represent an approach most similar to diffserv TOS treatment.
> 
> -mark
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kota,
> Ravikumar
> Sent: Wednesday, August 22, 2001 3:02 PM
> To: 'Srinivas T M'; mpls@UU.NET
> Subject: RE: e-lsp & l - lsp
> 
> 
> Hi srinivas ,
> These are two techiniques to implement packet treatment in  
> MPLS cloud ,
> with diffserv inferred information.
> The diffserv information from the packet can be encapsulated 
> into label/exp
> field of  "MPLS labelled packet "(this will be happened between
> diffservcloud and mpls cloud ),
> so that we will be making sure that diffserv information will 
> be used in
> MPLS cloud to treat the packets according to that information.
> Cisco is implementing this concept with the name : MPLS  
> DIFFSERV AWARE TE
>  e-lsp intended for carrying single OA for single LSP.
> l-lsp is intended for carrying multiple OA s for LSP.
> 
> 
>  OA  :      Ordered Aggregate. The set of Behavior Aggregates which
>                share an ordering constraint.
> 
> Any comments are welcome.
> 
> 
> Reference draft : draft-ietf-mpls-diff-ext-09.txt
> 
> 
> Regards
> Ravikumar Kota
> 978  263 0094 (extn  8157 )(work)
> 978 869 3314(cell)
> 
> 
> 
> 
> -----Original Message-----
> From: Srinivas T M [mailto:srini_tm@yahoo.com]
> Sent: Wednesday, August 22, 2001 5:46 PM
> To: mpls@UU.NET
> Subject: e-lsp & l - lsp
> 
> 
> Hi,
>     Can anybody explain what is e-lsp ,l-lsp and
> difference between them.
> 
> 
> Thanks,
> Srini
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger
> http://phonecard.yahoo.com/
> 



From owner-mpls@UU.NET  Sun Aug 26 07:12:49 2001
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 HAA10952
	for <mpls-archive@lists.ietf.org>; Sun, 26 Aug 2001 07:12:49 -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 QQldsu21684;
	Sun, 26 Aug 2001 11:13:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldsu16193
	for mpls-outgoing; Sun, 26 Aug 2001 11:13: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 QQldsu16184
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 26 Aug 2001 11:13:18 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 QQldsu06059
	for <mpls@uu.net>; Sun, 26 Aug 2001 11:13:01 GMT
Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [192.116.246.129])
	id QQldsu01825
	for <mpls@uu.net>; Sun, 26 Aug 2001 11:13:02 GMT
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: question about the traffic engineering extensions to OSPF
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Sun, 26 Aug 2001 14:12:59 +0300
Message-ID: <27E90AED3ADD2A4BA032397552A67B30015A0E1E@bart.cwnt.com>
Thread-Topic: question about the traffic engineering extensions to OSPF
Thread-Index: AcErMpVeVthXEFc7SS2BvCdm0eBcdQCLiDPg
From: "Amir Hermelin" <amir@cwnt.com>
To: "Feihong Chen" <fchen6@lucent.com>
Cc: "MPLS-wg (E-mail)" <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 HAA10952

Feihong,

It's enough to have one reason not to make a certain parameter
mandatory, in order to leave it optional. I'm sure there are other
reasons as well, but here are some:
* unreserved bw:  suppose your domain is only interested in Diffserv-TE
(whatever will come of it), and DS-TE advertises unres bw in different
TLVs. Then, there's no need to prevent turning (BE) unres-bw off.
* max bw and max reservable bw:  same as above.
* te metric:  suppose you don't want to use it (as some implementations
don't).
* color:  if a color hasn't been configured, there might not be a need
to advertise it.
* local and remote ip:  these can be inferred in other ways (although in
IS-IS the situation might be different).

So, in general, leaving them optional is really providing flexibility
(for the future, as well). I do agree, that advertising only LinkID and
LinkType TLVs (or, in the IS-IS case, advertising nothing) is useless to
TE (whether offline, online, or on the moon...).

Hope this helps...

--
Amir Hermelin                  <mailto:amir@cwnt.com>
Charlotte's Web Networks Inc.   <http://www.cwnt.com>


-----Original Message-----
From: Feihong Chen [mailto:fchen6@lucent.com]
Sent: Wednesday, August 22, 2001 7:13 PM
To: dkatz@juniper.net; kireeti@juniper.net
Cc: mpls@UU.NET
Subject: question about the traffic engineering extensions to OSPF


Hi, 

I just realized that the new version of the "Traffic Engineering
Extensions
to OSPF (draft-katz-yeung-ospf-traffic-05.txt)" made some changes on the
Sec2.4.2 (Link TLV). Unlike the previous version of the draft, this
version
proposed that "The Link Type and Link ID sub-TLVs are mandatory, i.e.,
must
appear exactly once. All other sub-TLVs defined here may occur at most
once." (Note, other sub-TLVs includes traffic engineering metric,
local/remote interface ip address, bandwidth information, class/color).

The question that I have here is, if the LSA only advertise the Link
Type
and Link ID as mandatory, then I don't see the capability of OSPF being
a
"traffic engineering helper" because the Traffic Engineering Database
build
from these two information ( which is the worst case ) simply is not
able to
calculate the ERO (i.e. the list of ip addresses), nor the bandwidth for
an
attempted LSP. 

In another word, if the proposed extensions to OSPF is mainly for
traffic
engineering, shouldn't some or all of  "other sub-TLVs" (e.g. bandwidth,
ip
address, color) be necessarily advertised besides the Link Type and Link
ID?
Otherwise, it will end up the traditional OSPF not for TE purpose? 

Maybe I miss something here, looking forward to a clarify to better
understand the purpose of this updated changes.

Thanks a lot,
Feihong Chen

 



From owner-mpls@UU.NET  Mon Aug 27 08:07:53 2001
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 IAA13154
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 08:07:52 -0400 (EDT)
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 QQldwq11331;
	Mon, 27 Aug 2001 12:09:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwq09995
	for mpls-outgoing; Mon, 27 Aug 2001 12:08:29 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 QQldwq09988
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 12:08:25 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 QQldwq14835
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:07:35 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 QQldwq00559
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:07:33 GMT
Received: from utfors.se ([10.58.0.94]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GIQ75F00.C39;
          Mon, 27 Aug 2001 14:10:27 +0200 
Message-ID: <3B8A37FE.701E91F3@utfors.se>
Date: Mon, 27 Aug 2001 14:07:26 +0200
From: Loa Andersson <loa.andersson@utfors.se>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: neil.2.harrison@bt.com, mpls@UU.NET
Subject: Re: Here we go again (Re: RSVP Hello)
References: <B9571FDEBD3DD21181E500606DD5EE050E89164B@mbddmknt01.hc.bt.com> <3B8890AE.2090105@juniper.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit


All,

would very much like to echo Pings sentiment in this, and also go
so far as to suggest (I know I'm at risk of being accused of bringing
the chinese Red Guards back to life) a correction movement within the 
WG, aiming at taking out everything that is not needed/useful.

/Loa


Ping Pan wrote:
> 
> neil.2.harrison@bt.com wrote:
> 
> > So, for example, whether I run layer network technology 'X' using RSVP-TE,
> > CR-LDP, PNNI, sig_prot_Y or indeed *no* signalling protocols I want the OAM
> > for the data-plane trails that carry the customer traffic to be independent
> > of the signalling protocol choice. This will be true in the case of SDH VC-4
> > trails say, but it is unfortunately not true for MPLS LSPs since we don't
> > have any decent MPLS data-plane OAM agreed yet.
> >
> > This mail thread is mixing different signalling protocol functionality as
> > proxies for data-plane failures, and a previous discussion on the
> > draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
> > principle by binding specific client/server layer OAM functionality to a
> > specific control-plane signalling protocol.
> >
> 
> Sigh,,, after reading through this mail, I can relate to the feeling
> some people have on MPLS, that is, it's an ATM replacement. :-( I really
> hope not.
> 
> Normally, the buzzwords such as "layers", "principles" and
> "architectures" are defined to make it easier to describe things. They
> are not defined to create new religions. Sometimes, they are more useful
> to marketing than to engineering. So if something is useful to the
> Internet, we try to come up with a simple solution and just build it.
> There is no magic to this process. So instead of talking about how I
> have broken the layers, principles, architectures and religious rules in
> LSP-ping, tell me why it does not work for the purpose it was designed for.
> 
> > During the discussion of the Ping draft, I know Yakov described what I have
> > discussed above as 'working on LTSFGTC' (long-term solutions for generations
> > to come)...or something like that......but if we want MPLS itself to be a
> > LTSFGTC (and hopefully also give some solid foundation for those working in
> > the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
> > architectural tenets right at the outset.
> 
> If OAM is a great LTSFGTC, then there is nothing to be worried about on
> this "narrow-focused" LSP-ping. We do our work, and you do yours. What a
> beautiful thing!
> 
> > Proper data-plane OAM, and its
> > decoupling from other client/server layer data-planes and/or specific
> > control (or management) plane protocols is not a 'luxury item', its just
> > plain common sense to avoid problems down the road.
> >
> 
> It's also a common sense that in order to make MPLS working in the
> Internet, we need to keep it simple.
> 
> Regards,
> 
> - Ping

-- 
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 Aug 27 09:10:33 2001
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 JAA16532
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 09:10:33 -0400 (EDT)
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 QQldwu21451;
	Mon, 27 Aug 2001 13:11:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwu03476
	for mpls-outgoing; Mon, 27 Aug 2001 13:11:14 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 QQldwu03451
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 13:11:10 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 QQldwu13320
	for <mpls@UU.NET>; Mon, 27 Aug 2001 13:10:53 GMT
Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQldwu05542
	for <mpls@UU.NET>; Mon, 27 Aug 2001 13:10:54 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 821E44CEB7; Mon, 27 Aug 2001 09:10:50 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA01927;
	Mon, 27 Aug 2001 09:10:49 -0400 (EDT)
Message-ID: <3B8A4840.DCF7230E@research.att.com>
Date: Mon, 27 Aug 2001 09:16:48 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ccamp@ops.ietf.org, mpls@UU.NET
Cc: gli@research.att.com
Subject: Question on GMPLS contentions resolution
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear GMPLS authors and all experts:

During GMPLS last call, I posted the same question on the mailing list
without response. Please somebody spend a little time and check with the
following example? Something seems not clear when the current GMPLS
contention resution schemes are applied on a framework with both
bi-directional and uni-directional LSPs. Your clarification is very much
appreciated.

Sincerely,

Guangzhi

--------------------------------------------------------------------------------------------------

The issue arises because contention is resolved between bi-directional
LSPs by the node with the higher node index while for uni-directional
LSPs, contention is resolved by the downstream node. Consider the
following example of two nodes with paired, bi-directional interfaces
(i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
node 2 with ID = 50.  Node 1 uses label 1 for the transmitter port and
label 2 for the receiver port; node 2 uses label 4 for the transmitter
port and label 3 for the receiver port.   We assume that a
bi-directional LSP requires a single I/O interface.

We consider two LSPs - a uni-directional LSP (LSP A) and a
bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2,
with the uni-directional LSP setup request arriving marginally before
the bi-directional LSP.  LSP A does not use a suggested label, and thus
is assigned a label (port) by node 2.  Label 3 is assigned,
corresponding to label 1 at node 1.  At the same time, for LSP B (the
bi-directional LSP) node 1 assigns label 2, with suggested label 1.
Because node 1 has the higher node ID, node 2 will assume (due to the
contention resolution rule for bi-directional LSPs) that LSP B wins the
contention and thus label 3 is assigned to LSP B.  Thus label 1 at node
1 (label 3 at node 2) has been assigned to two different LSPs.  Both
LSPs have “won” the contention.




From owner-mpls@UU.NET  Mon Aug 27 09:24:17 2001
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 JAA17267
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 09:24:17 -0400 (EDT)
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 QQldwv14476;
	Mon, 27 Aug 2001 13:25:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwv04646
	for mpls-outgoing; Mon, 27 Aug 2001 13:25:07 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 QQldwv04641
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 13:25:06 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 QQldwv17708
	for <mpls@uu.net>; Mon, 27 Aug 2001 13:24:55 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldwv10221
	for <mpls@uu.net>; Mon, 27 Aug 2001 13:24:47 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 JAA20920 for <mpls@uu.net>; Mon, 27 Aug 2001 09:24:48 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22581 for mpls@uu.net; Mon, 27 Aug 2001 09:24:18 -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 QQldwv04531
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 13:22: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 QQldwv12279
	for <mpls@uu.net>; Mon, 27 Aug 2001 13:22:37 GMT
Received: from brahma.roc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.125.87.14])
	id QQldwv29097
	for <mpls@uu.net>; Mon, 27 Aug 2001 13:22:26 GMT
Received: from linux (lsreddy.roc.com [172.16.1.82])
	by brahma.roc.com (8.9.3/8.8.7) with SMTP id SAA30096
	for <mpls@uu.net>; Mon, 27 Aug 2001 18:54:44 +0530
From: Srinivas Reddy <lsreddy@trinc.com>
Reply-To: lsreddy@trinc.com
Organization: ROC
To: mpls@UU.NET
Subject: a little bit off-topic
Date: Tue, 28 Aug 2001 00:16:34 +0530
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="us-ascii"
References: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng> <4.3.2.7.2.20010821123848.01f959c8@ce-nfs-1.cisco.com> <3B82C3A3.C8D3FE7F@sandburst.com>
In-Reply-To: <3B82C3A3.C8D3FE7F@sandburst.com>
MIME-Version: 1.0
Message-Id: <01082800163404.09022@linux>
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit


hi liwen and all

	sorry for discussing offtopic but i really need it.whare can i get the 
draft-wu-ldp-state-00.txt(i want to know about "Detecting the change in next 
hop"). if any body have better paper on this or algorithm please send me 
thanks in advance
regards
lonka vasu



From owner-mpls@UU.NET  Mon Aug 27 10:03:03 2001
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 KAA18953
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 10:03:03 -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 QQldwy21847;
	Mon, 27 Aug 2001 14:01:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwy10589
	for mpls-outgoing; Mon, 27 Aug 2001 14:00:48 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 QQldwy10405
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 14:00: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 QQldwy03023
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:00:16 GMT
Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQldwy17449
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:00:13 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7RDxlp04657
	for <mpls@UU.NET>; Mon, 27 Aug 2001 09:59:47 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 27 Aug 2001 09:59:45 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <R3TZAHLV>; Mon, 27 Aug 2001 09:59:51 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Ping Pan <pingpan@juniper.net>, neil.2.harrison@bt.com
Cc: bill.sanford@netplane.com, cmartin@gnilink.net, mpls@UU.NET
Subject: RE: Here we go again (Re: RSVP Hello)
Date: Mon, 27 Aug 2001 09:59:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12F00.8AE232F0"
X-Orig: <dallan@americasm01.nt.com>
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_01C12F00.8AE232F0
Content-Type: text/plain;
	charset="iso-8859-1"

Ping:

I think the disconncect as to what MPLS "is" needs to be resolved. I think
there is a large community that would be hard pressed to describe it as part
of IP, at least as large as the commnunity trying to avoid having it called
an ATM replacement (IMHO if we're looking for a monnicker; Frame relay in
IP's image is really probably closer ;-). 

From a functional point of view it does insert stuff into the stack, call it
a layer, helper or whatever, but to suggest it is not there, or is really an
appendage, or can be dealt with piecemeal means we're going to be fixing
this thing for a long time. This is where "architecture" is not religion but
a genuinely useful discipline.

I'm sure your proposal works for what it was designed to do, but IMHO it is
a subset of what is required, and would most likely be rendered to be
superfluous baggage by any LTSFGTC. Which means MPLS will not be simple.

rgds
Dave 

-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Sunday, August 26, 2001 2:01 AM
To: neil.2.harrison@bt.com
Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
Subject: Here we go again (Re: RSVP Hello)

<snip>

Sigh,,, after reading through this mail, I can relate to the feeling 
some people have on MPLS, that is, it's an ATM replacement. :-( I really 
hope not.

Normally, the buzzwords such as "layers", "principles" and 
"architectures" are defined to make it easier to describe things. They 
are not defined to create new religions. Sometimes, they are more useful 
to marketing than to engineering. So if something is useful to the 
Internet, we try to come up with a simple solution and just build it. 
There is no magic to this process. So instead of talking about how I 
have broken the layers, principles, architectures and religious rules in 
LSP-ping, tell me why it does not work for the purpose it was designed for.

> During the discussion of the Ping draft, I know Yakov described what I
have
> discussed above as 'working on LTSFGTC' (long-term solutions for
generations
> to come)...or something like that......but if we want MPLS itself to be a
> LTSFGTC (and hopefully also give some solid foundation for those working
in
> the PWE3 and PPVPNs WGs) then we really have to get some of the basic OAM
> architectural tenets right at the outset. 

If OAM is a great LTSFGTC, then there is nothing to be worried about on 
this "narrow-focused" LSP-ping. We do our work, and you do yours. What a 
beautiful thing!

> Proper data-plane OAM, and its
> decoupling from other client/server layer data-planes and/or specific
> control (or management) plane protocols is not a 'luxury item', its just
> plain common sense to avoid problems down the road.
> 

It's also a common sense that in order to make MPLS working in the 
Internet, we need to keep it simple.

Regards,

- Ping



------_=_NextPart_001_01C12F00.8AE232F0
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.2654.89">
<TITLE>RE: Here we go again (Re: RSVP Hello)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ping:</FONT>
</P>

<P><FONT SIZE=3D2>I think the disconncect as to what MPLS =
&quot;is&quot; needs to be resolved. I think there is a large community =
that would be hard pressed to describe it as part of IP, at least as =
large as the commnunity trying to avoid having it called an ATM =
replacement (IMHO if we're looking for a monnicker; Frame relay in IP's =
image is really probably closer ;-). </FONT></P>

<P><FONT SIZE=3D2>From a functional point of view it does insert stuff =
into the stack, call it a layer, helper or whatever, but to suggest it =
is not there, or is really an appendage, or can be dealt with piecemeal =
means we're going to be fixing this thing for a long time. This is =
where &quot;architecture&quot; is not religion but a genuinely useful =
discipline.</FONT></P>

<P><FONT SIZE=3D2>I'm sure your proposal works for what it was designed =
to do, but IMHO it is a subset of what is required, and would most =
likely be rendered to be superfluous baggage by any LTSFGTC. Which =
means MPLS will not be simple.</FONT></P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ping Pan [<A =
HREF=3D"mailto:pingpan@juniper.net">mailto:pingpan@juniper.net</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Sunday, August 26, 2001 2:01 AM</FONT>
<BR><FONT SIZE=3D2>To: neil.2.harrison@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: bill.sanford@netplane.com; cmartin@gnilink.net; =
mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Here we go again (Re: RSVP Hello)</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Sigh,,, after reading through this mail, I can relate =
to the feeling </FONT>
<BR><FONT SIZE=3D2>some people have on MPLS, that is, it's an ATM =
replacement. :-( I really </FONT>
<BR><FONT SIZE=3D2>hope not.</FONT>
</P>

<P><FONT SIZE=3D2>Normally, the buzzwords such as &quot;layers&quot;, =
&quot;principles&quot; and </FONT>
<BR><FONT SIZE=3D2>&quot;architectures&quot; are defined to make it =
easier to describe things. They </FONT>
<BR><FONT SIZE=3D2>are not defined to create new religions. Sometimes, =
they are more useful </FONT>
<BR><FONT SIZE=3D2>to marketing than to engineering. So if something is =
useful to the </FONT>
<BR><FONT SIZE=3D2>Internet, we try to come up with a simple solution =
and just build it. </FONT>
<BR><FONT SIZE=3D2>There is no magic to this process. So instead of =
talking about how I </FONT>
<BR><FONT SIZE=3D2>have broken the layers, principles, architectures =
and religious rules in </FONT>
<BR><FONT SIZE=3D2>LSP-ping, tell me why it does not work for the =
purpose it was designed for.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; During the discussion of the Ping draft, I know =
Yakov described what I have</FONT>
<BR><FONT SIZE=3D2>&gt; discussed above as 'working on LTSFGTC' =
(long-term solutions for generations</FONT>
<BR><FONT SIZE=3D2>&gt; to come)...or something like that......but if =
we want MPLS itself to be a</FONT>
<BR><FONT SIZE=3D2>&gt; LTSFGTC (and hopefully also give some solid =
foundation for those working in</FONT>
<BR><FONT SIZE=3D2>&gt; the PWE3 and PPVPNs WGs) then we really have to =
get some of the basic OAM</FONT>
<BR><FONT SIZE=3D2>&gt; architectural tenets right at the outset. =
</FONT>
</P>

<P><FONT SIZE=3D2>If OAM is a great LTSFGTC, then there is nothing to =
be worried about on </FONT>
<BR><FONT SIZE=3D2>this &quot;narrow-focused&quot; LSP-ping. We do our =
work, and you do yours. What a </FONT>
<BR><FONT SIZE=3D2>beautiful thing!</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Proper data-plane OAM, and its</FONT>
<BR><FONT SIZE=3D2>&gt; decoupling from other client/server layer =
data-planes and/or specific</FONT>
<BR><FONT SIZE=3D2>&gt; control (or management) plane protocols is not =
a 'luxury item', its just</FONT>
<BR><FONT SIZE=3D2>&gt; plain common sense to avoid problems down the =
road.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>It's also a common sense that in order to make MPLS =
working in the </FONT>
<BR><FONT SIZE=3D2>Internet, we need to keep it simple.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>- Ping</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C12F00.8AE232F0--


From owner-mpls@UU.NET  Mon Aug 27 10:04:10 2001
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 KAA19005
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 10:04:10 -0400 (EDT)
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 QQldwy25260;
	Mon, 27 Aug 2001 14:05:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwy17855
	for mpls-outgoing; Mon, 27 Aug 2001 14:05:01 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 QQldwy17677
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 14:04:54 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 QQldwy29640
	for <mpls@uu.net>; Mon, 27 Aug 2001 14:04:33 GMT
Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQldwy01744
	for <mpls@uu.net>; Mon, 27 Aug 2001 14:04:34 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA17266
	for <mpls@uu.net>; Mon, 27 Aug 2001 10:04:32 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22750 for mpls@uu.net; Mon, 27 Aug 2001 10: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 QQldww06463
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 13:44: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 QQldww14264
	for <mpls@UU.NET>; Mon, 27 Aug 2001 13:42:56 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQldww16566
	for <mpls@UU.NET>; Mon, 27 Aug 2001 13:42:55 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <RPDL1GQH>; Mon, 27 Aug 2001 19:31:53 +0530
Message-ID: <D11B30C7348BD511A40700010283497B06C856@GAYATRI>
From: Srinivasa Gopinath G <gopinathg@ctd.hcltech.com>
To: lsreddy@trinc.com, mpls@UU.NET
Subject: RE: a little bit off-topic
Date: Mon, 27 Aug 2001 19:10:55 +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 lonka

      I saw a logic  in draft-ietf-mpls-cr-ldp-05.txt but its related to
cr-ldp ,
I hope it will help u..............


--Gopinath.G.S


-----Original Message-----
From: Srinivas Reddy [mailto:lsreddy@trinc.com]
Sent: Tuesday, August 28, 2001 12:17 AM
To: mpls@UU.NET
Subject: a little bit off-topic



hi liwen and all

	sorry for discussing offtopic but i really need it.whare can i get
the 
draft-wu-ldp-state-00.txt(i want to know about "Detecting the change in next

hop"). if any body have better paper on this or algorithm please send me 
thanks in advance
regards
lonka vasu



From owner-mpls@UU.NET  Mon Aug 27 10:18:04 2001
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 KAA19641
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 10:18:04 -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 QQldwz28650;
	Mon, 27 Aug 2001 14:19:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwz28534
	for mpls-outgoing; Mon, 27 Aug 2001 14:18: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 QQldwz28527
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 14:18:52 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 QQldwz04291
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:18:44 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 QQldwz15443
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:18:46 GMT
Received: from utfors.se ([10.58.0.94]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GIQD8600.F5U;
          Mon, 27 Aug 2001 16:21:42 +0200 
Message-ID: <3B8A56C2.134BA1C9@utfors.se>
Date: Mon, 27 Aug 2001 16:18:42 +0200
From: Loa Andersson <loa.andersson@utfors.se>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
CC: David Allan <dallan@nortelnetworks.com>
Subject: Re: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

All,

I'll try to be even more to the point - the first and foremost 
requirement is simplicity. If MPLS is not simple, there will be no MPLS!

The second requirement is usefulness, if MPLS is not useful, there will
be no MPLS (even though it is simple).

Start looking at what is there and see if these requirements are met 
otherwise take it out.

BTW

What do our AD's/WG's chairs think about the statement that this is not 
part of the IP protocol suite, if you agree why are we doing this in 
IETF?

/Loa

> David Allan wrote:
> 
> Ping:
> 
> I think the disconncect as to what MPLS "is" needs to be resolved. I
> think there is a large community that would be hard pressed to
> describe it as part of IP, at least as large as the commnunity trying
> to avoid having it called an ATM replacement (IMHO if we're looking
> for a monnicker; Frame relay in IP's image is really probably closer
> ;-).
> 
> From a functional point of view it does insert stuff into the stack,
> call it a layer, helper or whatever, but to suggest it is not there,
> or is really an appendage, or can be dealt with piecemeal means we're
> going to be fixing this thing for a long time. This is where
> "architecture" is not religion but a genuinely useful discipline.
> 
> I'm sure your proposal works for what it was designed to do, but IMHO
> it is a subset of what is required, and would most likely be rendered
> to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> simple.
> 
> rgds
> Dave
> 
> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: Sunday, August 26, 2001 2:01 AM
> To: neil.2.harrison@bt.com
> Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> Subject: Here we go again (Re: RSVP Hello)
> 
> <snip>
> 
> Sigh,,, after reading through this mail, I can relate to the feeling
> some people have on MPLS, that is, it's an ATM replacement. :-( I
> really
> hope not.
> 
> Normally, the buzzwords such as "layers", "principles" and
> "architectures" are defined to make it easier to describe things. They
> 
> are not defined to create new religions. Sometimes, they are more
> useful
> to marketing than to engineering. So if something is useful to the
> Internet, we try to come up with a simple solution and just build it.
> There is no magic to this process. So instead of talking about how I
> have broken the layers, principles, architectures and religious rules
> in
> LSP-ping, tell me why it does not work for the purpose it was designed
> for.
> 
> > During the discussion of the Ping draft, I know Yakov described what
> I have
> > discussed above as 'working on LTSFGTC' (long-term solutions for
> generations
> > to come)...or something like that......but if we want MPLS itself to
> be a
> > LTSFGTC (and hopefully also give some solid foundation for those
> working in
> > the PWE3 and PPVPNs WGs) then we really have to get some of the
> basic OAM
> > architectural tenets right at the outset.
> 
> If OAM is a great LTSFGTC, then there is nothing to be worried about
> on
> this "narrow-focused" LSP-ping. We do our work, and you do yours. What
> a
> beautiful thing!
> 
> > Proper data-plane OAM, and its
> > decoupling from other client/server layer data-planes and/or
> specific
> > control (or management) plane protocols is not a 'luxury item', its
> just
> > plain common sense to avoid problems down the road.
> >
> 
> It's also a common sense that in order to make MPLS working in the
> Internet, we need to keep it simple.
> 
> Regards,
> 
> - Ping

-- 
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 Aug 27 10:28:29 2001
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 KAA20012
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 10:28:29 -0400 (EDT)
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 QQldwz04895;
	Mon, 27 Aug 2001 14:29:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldwz29655
	for mpls-outgoing; Mon, 27 Aug 2001 14:29: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 QQldwz29649
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 14:29:16 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 QQldwz03288
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:23:27 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 QQldwz23449
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:23:28 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 KAA05894
	for <mpls@UU.NET>; Mon, 27 Aug 2001 10:23:24 -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 KAA28544
	for <mpls@UU.NET>; Mon, 27 Aug 2001 10:23:25 -0400 (EDT)
Message-ID: <3B8A57E5.347876EB@marconi.com>
Date: Mon, 27 Aug 2001 10:23:33 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: a little bit off-topic
References: <69BCCDDC980B4641BFC908D7BF95F18410A80F@exchsrv-eng> <4.3.2.7.2.20010821123848.01f959c8@ce-nfs-1.cisco.com> <3B82C3A3.C8D3FE7F@sandburst.com> <01082800163404.09022@linux>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Srinivas Reddy wrote:
> 
>         sorry for discussing offtopic but i really need it.whare can
> i get the draft-wu-ldp-state-00.txt(i want to know about "Detecting
> the change in next hop"). if any body have better paper on this or
> algorithm please send me thanks in advance

1: The file you named does not exist.  You probably meant:

	draft-wu-mpls-ldp-state-00.txt

2: This draft has been accepted by the working group and has since
   been renamed.  The current version of the file is:

	draft-ietf-mpls-ldp-state-04.txt

3: All current IETF documents (including drafts and RFCs) may be
   downloaded from http://www.ietf.org/.  Follow the links to find
   the document(s) you want.

-- David


From owner-mpls@UU.NET  Mon Aug 27 10:31:54 2001
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 KAA20173
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 10:31:42 -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 QQldxa24790;
	Mon, 27 Aug 2001 14:32:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxa29924
	for mpls-outgoing; Mon, 27 Aug 2001 14:32:21 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 QQldxa29915
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 14:32:17 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 QQldxa20749
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:31:28 GMT
Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQldxa08170
	for <mpls@UU.NET>; Mon, 27 Aug 2001 14:31:29 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7REV4p10042
	for <mpls@UU.NET>; Mon, 27 Aug 2001 10:31:04 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Mon, 27 Aug 2001 10:31:06 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <R3TZA23A>; Mon, 27 Aug 2001 10:31:11 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3432DC69@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Loa Andersson <loa.andersson@utfors.se>, mpls@UU.NET
Subject: RE: Here we go again (Re: RSVP Hello)
Date: Mon, 27 Aug 2001 10:31:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12F04.EF8EEAA0"
X-Orig: <dallan@americasm01.nt.com>
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_01C12F04.EF8EEAA0
Content-Type: text/plain;
	charset="iso-8859-1"

Loa:

PPP and L2TP are examples of IETF defined protocols that carry IP (and other
things), would not be considered specifically part of IP, and are generally
self contained from a functional POV. I'd lump MPLS in the same category.

rgds
Dave

-----Original Message-----
From: Loa Andersson [mailto:loa.andersson@utfors.se]
Sent: Monday, August 27, 2001 10:19 AM
To: mpls@UU.NET
Cc: Allan, David [CAR:NS00:EXCH]
Subject: Re: Here we go again (Re: RSVP Hello)


All,

I'll try to be even more to the point - the first and foremost 
requirement is simplicity. If MPLS is not simple, there will be no MPLS!

The second requirement is usefulness, if MPLS is not useful, there will
be no MPLS (even though it is simple).

Start looking at what is there and see if these requirements are met 
otherwise take it out.

BTW

What do our AD's/WG's chairs think about the statement that this is not 
part of the IP protocol suite, if you agree why are we doing this in 
IETF?

/Loa

> David Allan wrote:
> 
> Ping:
> 
> I think the disconncect as to what MPLS "is" needs to be resolved. I
> think there is a large community that would be hard pressed to
> describe it as part of IP, at least as large as the commnunity trying
> to avoid having it called an ATM replacement (IMHO if we're looking
> for a monnicker; Frame relay in IP's image is really probably closer
> ;-).
> 
> From a functional point of view it does insert stuff into the stack,
> call it a layer, helper or whatever, but to suggest it is not there,
> or is really an appendage, or can be dealt with piecemeal means we're
> going to be fixing this thing for a long time. This is where
> "architecture" is not religion but a genuinely useful discipline.
> 
> I'm sure your proposal works for what it was designed to do, but IMHO
> it is a subset of what is required, and would most likely be rendered
> to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> simple.
> 
> rgds
> Dave
> 
> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: Sunday, August 26, 2001 2:01 AM
> To: neil.2.harrison@bt.com
> Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> Subject: Here we go again (Re: RSVP Hello)
> 
> <snip>
> 
> Sigh,,, after reading through this mail, I can relate to the feeling
> some people have on MPLS, that is, it's an ATM replacement. :-( I
> really
> hope not.
> 
> Normally, the buzzwords such as "layers", "principles" and
> "architectures" are defined to make it easier to describe things. They
> 
> are not defined to create new religions. Sometimes, they are more
> useful
> to marketing than to engineering. So if something is useful to the
> Internet, we try to come up with a simple solution and just build it.
> There is no magic to this process. So instead of talking about how I
> have broken the layers, principles, architectures and religious rules
> in
> LSP-ping, tell me why it does not work for the purpose it was designed
> for.
> 
> > During the discussion of the Ping draft, I know Yakov described what
> I have
> > discussed above as 'working on LTSFGTC' (long-term solutions for
> generations
> > to come)...or something like that......but if we want MPLS itself to
> be a
> > LTSFGTC (and hopefully also give some solid foundation for those
> working in
> > the PWE3 and PPVPNs WGs) then we really have to get some of the
> basic OAM
> > architectural tenets right at the outset.
> 
> If OAM is a great LTSFGTC, then there is nothing to be worried about
> on
> this "narrow-focused" LSP-ping. We do our work, and you do yours. What
> a
> beautiful thing!
> 
> > Proper data-plane OAM, and its
> > decoupling from other client/server layer data-planes and/or
> specific
> > control (or management) plane protocols is not a 'luxury item', its
> just
> > plain common sense to avoid problems down the road.
> >
> 
> It's also a common sense that in order to make MPLS working in the
> Internet, we need to keep it simple.
> 
> Regards,
> 
> - Ping

-- 
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

------_=_NextPart_001_01C12F04.EF8EEAA0
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.2654.89">
<TITLE>RE: Here we go again (Re: RSVP Hello)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa:</FONT>
</P>

<P><FONT SIZE=3D2>PPP and L2TP are examples of IETF defined protocols =
that carry IP (and other things), would not be considered specifically =
part of IP, and are generally self contained from a functional POV. I'd =
lump MPLS in the same category.</FONT></P>

<P><FONT SIZE=3D2>rgds</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Loa Andersson [<A =
HREF=3D"mailto:loa.andersson@utfors.se">mailto:loa.andersson@utfors.se</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 27, 2001 10:19 AM</FONT>
<BR><FONT SIZE=3D2>To: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Cc: Allan, David [CAR:NS00:EXCH]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Here we go again (Re: RSVP =
Hello)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I'll try to be even more to the point - the first and =
foremost </FONT>
<BR><FONT SIZE=3D2>requirement is simplicity. If MPLS is not simple, =
there will be no MPLS!</FONT>
</P>

<P><FONT SIZE=3D2>The second requirement is usefulness, if MPLS is not =
useful, there will</FONT>
<BR><FONT SIZE=3D2>be no MPLS (even though it is simple).</FONT>
</P>

<P><FONT SIZE=3D2>Start looking at what is there and see if these =
requirements are met </FONT>
<BR><FONT SIZE=3D2>otherwise take it out.</FONT>
</P>

<P><FONT SIZE=3D2>BTW</FONT>
</P>

<P><FONT SIZE=3D2>What do our AD's/WG's chairs think about the =
statement that this is not </FONT>
<BR><FONT SIZE=3D2>part of the IP protocol suite, if you agree why are =
we doing this in </FONT>
<BR><FONT SIZE=3D2>IETF?</FONT>
</P>

<P><FONT SIZE=3D2>/Loa</FONT>
</P>

<P><FONT SIZE=3D2>&gt; David Allan wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ping:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think the disconncect as to what MPLS =
&quot;is&quot; needs to be resolved. I</FONT>
<BR><FONT SIZE=3D2>&gt; think there is a large community that would be =
hard pressed to</FONT>
<BR><FONT SIZE=3D2>&gt; describe it as part of IP, at least as large as =
the commnunity trying</FONT>
<BR><FONT SIZE=3D2>&gt; to avoid having it called an ATM replacement =
(IMHO if we're looking</FONT>
<BR><FONT SIZE=3D2>&gt; for a monnicker; Frame relay in IP's image is =
really probably closer</FONT>
<BR><FONT SIZE=3D2>&gt; ;-).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From a functional point of view it does insert =
stuff into the stack,</FONT>
<BR><FONT SIZE=3D2>&gt; call it a layer, helper or whatever, but to =
suggest it is not there,</FONT>
<BR><FONT SIZE=3D2>&gt; or is really an appendage, or can be dealt with =
piecemeal means we're</FONT>
<BR><FONT SIZE=3D2>&gt; going to be fixing this thing for a long time. =
This is where</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;architecture&quot; is not religion but a =
genuinely useful discipline.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm sure your proposal works for what it was =
designed to do, but IMHO</FONT>
<BR><FONT SIZE=3D2>&gt; it is a subset of what is required, and would =
most likely be rendered</FONT>
<BR><FONT SIZE=3D2>&gt; to be superfluous baggage by any LTSFGTC. Which =
means MPLS will not be</FONT>
<BR><FONT SIZE=3D2>&gt; simple.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; rgds</FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ping Pan [<A =
HREF=3D"mailto:pingpan@juniper.net">mailto:pingpan@juniper.net</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Sunday, August 26, 2001 2:01 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: neil.2.harrison@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: bill.sanford@netplane.com; =
cmartin@gnilink.net; mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Here we go again (Re: RSVP =
Hello)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sigh,,, after reading through this mail, I can =
relate to the feeling</FONT>
<BR><FONT SIZE=3D2>&gt; some people have on MPLS, that is, it's an ATM =
replacement. :-( I</FONT>
<BR><FONT SIZE=3D2>&gt; really</FONT>
<BR><FONT SIZE=3D2>&gt; hope not.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Normally, the buzzwords such as =
&quot;layers&quot;, &quot;principles&quot; and</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;architectures&quot; are defined to make =
it easier to describe things. They</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; are not defined to create new religions. =
Sometimes, they are more</FONT>
<BR><FONT SIZE=3D2>&gt; useful</FONT>
<BR><FONT SIZE=3D2>&gt; to marketing than to engineering. So if =
something is useful to the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet, we try to come up with a simple =
solution and just build it.</FONT>
<BR><FONT SIZE=3D2>&gt; There is no magic to this process. So instead =
of talking about how I</FONT>
<BR><FONT SIZE=3D2>&gt; have broken the layers, principles, =
architectures and religious rules</FONT>
<BR><FONT SIZE=3D2>&gt; in</FONT>
<BR><FONT SIZE=3D2>&gt; LSP-ping, tell me why it does not work for the =
purpose it was designed</FONT>
<BR><FONT SIZE=3D2>&gt; for.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; During the discussion of the Ping draft, I =
know Yakov described what</FONT>
<BR><FONT SIZE=3D2>&gt; I have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; discussed above as 'working on LTSFGTC' =
(long-term solutions for</FONT>
<BR><FONT SIZE=3D2>&gt; generations</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to come)...or something like that......but =
if we want MPLS itself to</FONT>
<BR><FONT SIZE=3D2>&gt; be a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; LTSFGTC (and hopefully also give some =
solid foundation for those</FONT>
<BR><FONT SIZE=3D2>&gt; working in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the PWE3 and PPVPNs WGs) then we really =
have to get some of the</FONT>
<BR><FONT SIZE=3D2>&gt; basic OAM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; architectural tenets right at the =
outset.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If OAM is a great LTSFGTC, then there is =
nothing to be worried about</FONT>
<BR><FONT SIZE=3D2>&gt; on</FONT>
<BR><FONT SIZE=3D2>&gt; this &quot;narrow-focused&quot; LSP-ping. We do =
our work, and you do yours. What</FONT>
<BR><FONT SIZE=3D2>&gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; beautiful thing!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Proper data-plane OAM, and its</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; decoupling from other client/server layer =
data-planes and/or</FONT>
<BR><FONT SIZE=3D2>&gt; specific</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; control (or management) plane protocols is =
not a 'luxury item', its</FONT>
<BR><FONT SIZE=3D2>&gt; just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; plain common sense to avoid problems down =
the road.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It's also a common sense that in order to make =
MPLS working in the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet, we need to keep it simple.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Ping</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Loa Andersson</FONT>
<BR><FONT SIZE=3D2>Chief Architect,</FONT>
<BR><FONT SIZE=3D2>Utfors Research, Architecture and Future Lab =
(URAX)</FONT>
<BR><FONT SIZE=3D2>Utfors AB</FONT>
<BR><FONT SIZE=3D2>R=E5sundav=E4gen 12</FONT>
<BR><FONT SIZE=3D2>Box 525, 169 29 Solna</FONT>
<BR><FONT =
SIZE=3D2>Office&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+46 8 5270 2000</FONT>
<BR><FONT SIZE=3D2>Office direct&nbsp;&nbsp; +46 8 5270 5038</FONT>
<BR><FONT =
SIZE=3D2>Mobile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+46 70 848 5038</FONT>
<BR><FONT =
SIZE=3D2>Email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; loa.andersson@utfors.se</FONT>
<BR><FONT =
SIZE=3D2>WWW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; www.utfors.se</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12F04.EF8EEAA0--


From owner-mpls@UU.NET  Mon Aug 27 11:12:31 2001
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 LAA21248
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:12:31 -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 QQldxc07297;
	Mon, 27 Aug 2001 15:13:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxc21798
	for mpls-outgoing; Mon, 27 Aug 2001 15:13:11 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 QQldxc21785
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:13: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 QQldxc04702
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:12:38 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQldxc09876
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:12:39 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2G5GW>; Mon, 27 Aug 2001 11:08:14 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A450@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Can anybody  has  info about MPLS TE Tunnel configuration
Date: Mon, 27 Aug 2001 11:08:14 -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


Hi ,
Can anybody help me to find information on MPLS TE tunnel
create/delete/reconfigure  with some examples (with diagrams ).
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
limit/120st/120st14/te_mib14.htm
The above URL talks only  about the MPLS TE tunnel tables/scalars , but with
out any examples.
It will be really helpful , if somebody passes light on this.
Thanks 

Regards

RaviKumar Kota
Cratos Networks Inc
100 NAGOG PARK
ACTON , MA -01824
Phone: 978-263-0094 (8157)



From owner-mpls@UU.NET  Mon Aug 27 11:23:02 2001
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 LAA21537
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:23: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 QQldxd22903;
	Mon, 27 Aug 2001 15:24:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxd23121
	for mpls-outgoing; Mon, 27 Aug 2001 15:23: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 QQldxd23116
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:23:48 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 QQldxd18294
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:22:04 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldxd19767
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:22:03 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20742 for mpls@uu.net; Mon, 27 Aug 2001 11:22:03 -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 QQldxd22911
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:21:48 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 QQldxd20592
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:20:33 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 QQldxd18066
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:20:34 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-108.cisco.com [64.102.48.108])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA13003;
	Mon, 27 Aug 2001 11:19:59 -0400 (EDT)
Date: Mon, 27 Aug 2001 11:20:05 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: "Kota, Ravikumar" <RKota@cratosnetworks.com>
cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Can anybody  has  info about MPLS TE Tunnel configuration
In-Reply-To: <95F30C6F1B56D4118F9200508BC75B3A31A450@yn-server1.yodanetworks.com>
Message-ID: <Pine.WNT.4.33.0108271119000.1588-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 27 Aug 2001, Kota, Ravikumar wrote:

Ravi,

Configuring MPLS-TE (or anything for that matter) is usually vendor specific.
If you need it on Cisco routers please email me and I can help you.  Let us
take that off this alias.
-ajay

 >
> Hi ,
> Can anybody help me to find information on MPLS TE tunnel
> create/delete/reconfigure  with some examples (with diagrams ).
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
> limit/120st/120st14/te_mib14.htm
> The above URL talks only  about the MPLS TE tunnel tables/scalars , but with
> out any examples.
> It will be really helpful , if somebody passes light on this.
> Thanks
>
> Regards
>
> RaviKumar Kota
> Cratos Networks Inc
> 100 NAGOG PARK
> ACTON , MA -01824
> Phone: 978-263-0094 (8157)
>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Mon Aug 27 11:39:17 2001
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 LAA22078
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:39:17 -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 QQldxe20542;
	Mon, 27 Aug 2001 15:40:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxe24536
	for mpls-outgoing; Mon, 27 Aug 2001 15:40:07 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 QQldxe24525
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:39:58 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 QQldxe02023
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:38:31 GMT
Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: entmail.gnilink.net [199.45.47.10])
	id QQldxe15798
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:38:33 GMT
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <RS6XFCYX>; Mon, 27 Aug 2001 11:38:31 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDD91@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        bill.sanford@netplane.com, "Martin, Christian" <cmartin@gnilink.net>,
        mpls@UU.NET
Subject: RE: RSVP Hello
Date: Mon, 27 Aug 2001 11:38:24 -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

Neil,

Thanks for the well-thought response.  I am not quite sure if you have
chosen a side in this debate, so forgive me if I misunderstand your
position.  Comments inline.

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Friday, August 24, 2001 12:58 PM
> To: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> Subject: RE: RSVP Hello
> 
> 
> Bill/Martin,
> 
> Noting your comment (Bill) on cringing when you hear "It will 
> be easy to add
> this fuctionality" or "how hard can this be?", I cringe 
> myself when I see
> architectural kludges, and this thread has more than a whiff 
> of these.....so
> let me add my 2 cents (with a slightly different slant...so 
> please bear with
> me):

It could be said that RSVP-TE is an architectural kludge in that, RSVP was
specifically designed for signalling reservation state with any applicable
QoS parameters, congruent to the data plane that was built using control
plane protocols (routing), and not to act as a control plane protocol that
set up forwarding state.  Yet its usefulness is still clear and RSVP was the
best choice under the circumstances (time and monetary constraints and a
desperate need (perceived at least)).

> Each protocol provides specific functionality (otherwise why 
> have it?).
> Hence, by inference, each protocol will have it own specific 
> failure modes,
> and thus require its own specific OAM mechanism.  So whether 
> we are talking
> about RSVP, LDP, OSPF, BGP4, etc this applies, and the RFCs 
> that specify
> these protocols do indeed have such OAM functionality defined in them.

However, they are not independednt of other control and management planes.
They all rely on an IP control plane.  In fact BGP relies on three layered
control planes in many network designs (IGP and TCP/IP), which in fact
relies on some set of independent control planes as well (ATM VCs or PPP
over STS-nc/DS3).  The management planes in the protocols do not function
without the ones beneath them. 

<-snip->


> This mail thread is mixing different signalling protocol 
> functionality as
> proxies for data-plane failures, and a previous discussion on the
> draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
> principle by binding specific client/server layer OAM 
> functionality to a
> specific control-plane signalling protocol.

But, Neil, this isn't the PSTN/SS7N we are talking about.  We are talking
about the public Internet, where there is little separation between planes.
RSVP is useless without an IGP.  BGP is (in practice) useless without an
IGP.  IGP's are useless without an IP infrastructure.  The management planes
of these protocols are all interdependent.  We cannot decouple them now.

Each of these protocols has their own OAM functionality built in to some
degree.  BGP is not fully independent of its substrate, as in some cases, it
relies on TCP operations to detect failures.  This is the nature of TCP/IP
and sockets and cleint/server computing.  The point is, that, regardless of
the interdependence, there is an OAM capability that allows us (those
building networks) to determine the cause of a failure.  This is because
they are hard-state protocols.  Now we all agree that RSVP as a signalling
protocol is not scalable wrt thousands or millions of microflows in a
hard-state environment.  Neither is any protocol on that scale.  An internet
core router cannot support millions of BGP prefixes, IGPs cannot support
millions of links, etc.  Thus, the routing information they convey is
soft-state, but the framework they use to distribute this information is
hard-state (or firm-state) and hieracrhical.  This is the crux of my
problem.  RSVP is soft-state in both its distribution mechanism and its
framework for distribution.  So, although there is reservation state OAM,
there is no way to determine of the reservation messages are being delivered
properly in the first place, at least in the current vendor implementations.
We only ass-u-me that because there is IP connectivity that there is nodal
RSVP awareness end-to-end.

Using BGP as an example, which philosphically is in some ways like RSVP
(from a very abstract point of view), let us consider the following:

Two BGP peers are separated by n hops across an AS of arbitrary complexity.
A BGP session is being built, but it cannot be established.  Hrm.  We use
techniques to diagnose the problem - are the peers reachable via IP?  We use
pings and traceroutes to determine that.  OK, is there a configuration
issue?  We inspect the two configurations, troubleshoot the root cause, and
move on.  The distribution framework is built and now we can move on to the
distribution mechanism.  At this point, the BGP OAM functionality becomes
independent, and everyone is happy.

Back to RSVP-TE, let us do something similar.  Again, we have two RSVP-TE
endpoints that we wish to build an LSP between.  During the reservation
setup step, we discover that we are not receiving RESV or RESVERR messages
back.  Hrm.  Where is the problem?  We can do pings and traces, but that
does not inform us whether or not there is a nodal RSVP handling issue on
one or more processing devices in the path.  But what device?!  This is
where I see a problem.

What I am proposing is that we build some OAM into the RSVP-TE framework,
such that an operator can detect misconfigurations and nodal failures of the
RSVP processing subroutines.  The OAM mechanisms can be straightforward (by
building adjacency state and maintaining it), or can be more tool oriented,
like RSVP traceroute and RSVP ping.  We shouldn't have to break anything to
do this.  Hello's, the topic of this thread, are optional anyway.  

Of course this isn't a silver bullet.  All failure modes cannot be resolved
via OAM, but they can in most cases be _detected_ and thus, they can be
isolated.

I am by no means an RSVP expert.  That is for you guys!  I'm just an
ordinary plumber looking for a leak without the right tools.  
 
> During the discussion of the Ping draft, I know Yakov 
> described what I have
> discussed above as 'working on LTSFGTC' (long-term solutions 
> for generations
> to come)...or something like that......but if we want MPLS 
> itself to be a
> LTSFGTC (and hopefully also give some solid foundation for 
> those working in
> the PWE3 and PPVPNs WGs) then we really have to get some of 
> the basic OAM
> architectural tenets right at the outset.  Proper data-plane 
> OAM, and its
> decoupling from other client/server layer data-planes and/or specific
> control (or management) plane protocols is not a 'luxury 
> item', its just
> plain common sense to avoid problems down the road.

Unfortunately, we have already built and deployed a solution that has little
functional independence.  GMPLS attempts to do this, but this is because the
underlying network technology is new (like OXCs), and thus, can be designed
with GMPLS in mind.  As far as today's MPLS infrastructure, and the Internet
protocols as a whole, RSVP is the only state-building protocol without
robust OAM on the delivery mechanism itself.  It is akin to BGP without
nailed up neighbors.

Best Regards,
-chris
 



> 
> regards, Neil
> > -----Original Message-----
> > From: Sanford, Bill [mailto:bill.sanford@netplane.com]
> > Sent: 24 August 2001 14:27
> > To: 'Martin, Christian'; Sanford, Bill; 'mpls@UU.NET'
> > Subject: RE: RSVP Hello
> > 
> > 
> > 
> > > Of course, this example discusses authenticated RSVP 
> > > messages, but other
> > > types of issues can impair RSVP without easy detection.  As 
> > > it is today, you
> > > can either send a test PATH message across the network to 
> > > build state, or
> > > you can hope it works when you need it.  Neither is operationally
> > > acceptable, IMHO.
> > 
> > You can always submit a draft. ;-)
> > 
> > Regards,
> > Bill
> > 
> 


From owner-mpls@UU.NET  Mon Aug 27 11:41:05 2001
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 LAA22172
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:41:05 -0400 (EDT)
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 QQldxe21699;
	Mon, 27 Aug 2001 15:42:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxe24721
	for mpls-outgoing; Mon, 27 Aug 2001 15:41: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 QQldxe24715
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:41: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 QQldxe01566
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:40:35 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQldxe19585
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:40:37 GMT
Message-ID: <3B8A69F1.8DB5DE4F@sandburst.com>
Date: Mon, 27 Aug 2001 11:40:33 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: David Allan <dallan@nortelnetworks.com>,
        Loa Andersson <loa.andersson@utfors.se>,
        Ping Pan <pingpan@juniper.net>, Neil Harrison <neil.2.harrison@bt.com>
Cc: mpls@UU.NET
Subject: Re: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC69@zcard0ka.ca.nortel.com>
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 LAA22172

This seems like a noisy thread.  Some people (Neil and Dave) assert that
OAM must be part of a long term solution and - hence - anything that does
not contribute materially to this long term solution is going to be wasted
effort.  Others (Loa and Ping) assert that the immediate solution should
be simple and useful - or it will be irrelevant.

We're getting dangerously close to name calling from both sides - perhaps
we may already have crossed the line.  Probably the thing to do at this
point is to agree to disagree.  I suggest that people who are interested
and believe in the value of a long term solution work on that solution
while other people who are interested in and believe in a simple, useful,
immediate solution work on that solution.  Ultimately, each group may end
up borrowing from the other - possibly bettering both solutions - and, at
some point, it is likely that one solution or the other will be overcome
by events.

In the meantime, can we stop arguing which is better, a bolt or a cotter
pin?

Thanks in advance,
--
Eric Gray


>
>
> Loa:
>
> PPP and L2TP are examples of IETF defined protocols that carry IP (and other
> things),
> would not be considered specifically part of IP, and are generally self
> contained from
> a functional POV. I'd lump MPLS in the same category.
>
> rgds
> Dave
>
> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Monday, August 27, 2001 10:19 AM
> To: mpls@UU.NET
> Cc: Allan, David [CAR:NS00:EXCH]
> Subject: Re: Here we go again (Re: RSVP Hello)
>
> All,
>
> I'll try to be even more to the point - the first and foremost
> requirement is simplicity. If MPLS is not simple, there will be no MPLS!
>
> The second requirement is usefulness, if MPLS is not useful, there will
> be no MPLS (even though it is simple).
>
> Start looking at what is there and see if these requirements are met
> otherwise take it out.
>
> BTW
>
> What do our AD's/WG's chairs think about the statement that this is not
> part of the IP protocol suite, if you agree why are we doing this in
> IETF?
>
> /Loa
>
> > David Allan wrote:
> >
> > Ping:
> >
> > I think the disconncect as to what MPLS "is" needs to be resolved. I
> > think there is a large community that would be hard pressed to
> > describe it as part of IP, at least as large as the commnunity trying
> > to avoid having it called an ATM replacement (IMHO if we're looking
> > for a monnicker; Frame relay in IP's image is really probably closer
> > ;-).
> >
> > From a functional point of view it does insert stuff into the stack,
> > call it a layer, helper or whatever, but to suggest it is not there,
> > or is really an appendage, or can be dealt with piecemeal means we're
> > going to be fixing this thing for a long time. This is where
> > "architecture" is not religion but a genuinely useful discipline.
> >
> > I'm sure your proposal works for what it was designed to do, but IMHO
> > it is a subset of what is required, and would most likely be rendered
> > to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> > simple.
> >
> > rgds
> > Dave
> >
> > -----Original Message-----
> > From: Ping Pan [mailto:pingpan@juniper.net]
> > Sent: Sunday, August 26, 2001 2:01 AM
> > To: neil.2.harrison@bt.com
> > Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> > Subject: Here we go again (Re: RSVP Hello)
> >
> > <snip>
> >
> > Sigh,,, after reading through this mail, I can relate to the feeling
> > some people have on MPLS, that is, it's an ATM replacement. :-( I
> > really
> > hope not.
> >
> > Normally, the buzzwords such as "layers", "principles" and
> > "architectures" are defined to make it easier to describe things. They
> >
> > are not defined to create new religions. Sometimes, they are more
> > useful
> > to marketing than to engineering. So if something is useful to the
> > Internet, we try to come up with a simple solution and just build it.
> > There is no magic to this process. So instead of talking about how I
> > have broken the layers, principles, architectures and religious rules
> > in
> > LSP-ping, tell me why it does not work for the purpose it was designed
> > for.
> >
> > > During the discussion of the Ping draft, I know Yakov described what
> > I have
> > > discussed above as 'working on LTSFGTC' (long-term solutions for
> > generations
> > > to come)...or something like that......but if we want MPLS itself to
> > be a
> > > LTSFGTC (and hopefully also give some solid foundation for those
> > working in
> > > the PWE3 and PPVPNs WGs) then we really have to get some of the
> > basic OAM
> > > architectural tenets right at the outset.
> >
> > If OAM is a great LTSFGTC, then there is nothing to be worried about
> > on
> > this "narrow-focused" LSP-ping. We do our work, and you do yours. What
> > a
> > beautiful thing!
> >
> > > Proper data-plane OAM, and its
> > > decoupling from other client/server layer data-planes and/or
> > specific
> > > control (or management) plane protocols is not a 'luxury item', its
> > just
> > > plain common sense to avoid problems down the road.
> > >
> >
> > It's also a common sense that in order to make MPLS working in the
> > Internet, we need to keep it simple.
> >
> > Regards,
> >
> > - Ping
>
> --
> 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 Aug 27 11:47:55 2001
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 LAA22412
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:47:55 -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 QQldxf05824;
	Mon, 27 Aug 2001 15:49:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxf25289
	for mpls-outgoing; Mon, 27 Aug 2001 15:48: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 QQldxf25281
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:48: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 QQldxf19545
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:48:13 GMT
Received: from znsgs0ja.europe.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: znsgs0ja.nortelnetworks.com [47.165.25.40])
	id QQldxf04465
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:48:11 GMT
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7RFmBg17708
	for <mpls@uu.net>; Mon, 27 Aug 2001 16:48:11 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Mon, 27 Aug 2001 16:47:57 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <RPYZ806K>; Mon, 27 Aug 2001 16:47:51 +0100
Message-ID: <CF4991E8D749D411A8A30008C791861E01F31DEB@zvbnc0jb.europe.nortel.com>
From: "Marc Lamberton" <marc.lamberton@nortelnetworks.com>
To: "'Cheenu Srinivasan'" <cheenu@alphion.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Date: Mon, 27 Aug 2001 16:47:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C12F0F.9C8129D0"
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_01C12F0F.9C8129D0
Content-Type: text/plain;
	charset="iso-8859-1"

Cheenu,

the draft-ietf-mpls-ftn-mib-03.txt describes managed objects for defining
FEC-to-NHLFE mapping for L3 services. I mean 
the mplsFTNTable contains 6-tuple rules based on L3 and L4 header fields.
Several drafts are now proposed to provide L2 services on MPLS (e.g.
draft-martini-l2circuit-trans-mpls-07, draft-kompella-ppvpn-l2vpn-00,
draft-vkompella-ppvpn-vpsn-mpls-00,...)

Do you think it will make sense to extend the FTN MIB definition to support
such services, and is it planned for a future revision of
draft-ietf-mpls-ftn-mib ?

Marc

-----Original Message-----
From: Cheenu Srinivasan [mailto:cheenu@alphion.com]
Sent: Wednesday, August 22, 2001 7:07 PM
To: mpls
Cc: Thomas D. Nadeau (E-mail); Arun Viswanathan (E-mail); George
Swallow; Vijay Srinivasan
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt


Folks,

Version 03 of the FTN MIB I-D is now available on the IETF
website (see below). We (the authors) believe its ready
for last call at this point. Please email your comments
to the list. Thanks.

Cheenu

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, August 22, 2001 7:02 AM
> To: IETF-Announce
> Cc: mpls@UU.NET
> Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
> 
> 
> 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) 
> FEC-To-NHLFE 
>                           (FTN) Management Information Base
> 	Author(s)	: T. Nadeau, C. Srinivasan, A. Viswanathan
> 	Filename	: draft-ietf-mpls-ftn-mib-03.txt
> 	Pages		: 25
> 	Date		: 21-Aug-01
> 	
> This memo defines an experimental portion of the Management
> Information Base  (MIB) for use with network management protocols in
> the Internet community.  In particular, it describes managed objects
> for defining FEC-to-NHLFE mapping and corresponding actions for use
> with Multiprotocol Label Switching (MPLS).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-mpls-ftn-mib-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-ftn-mib-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_001_01C12F0F.9C8129D0
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.2654.89">
<TITLE>RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Cheenu,</FONT>
</P>

<P><FONT SIZE=3D2>the draft-ietf-mpls-ftn-mib-03.txt describes managed =
objects for defining FEC-to-NHLFE mapping for L3 services. I mean =
</FONT>
<BR><FONT SIZE=3D2>the mplsFTNTable contains 6-tuple rules based on L3 =
and L4 header fields. Several drafts are now proposed to provide L2 =
services on MPLS (e.g. draft-martini-l2circuit-trans-mpls-07, =
draft-kompella-ppvpn-l2vpn-00, =
draft-vkompella-ppvpn-vpsn-mpls-00,...)</FONT></P>

<P><FONT SIZE=3D2>Do you think it will make sense to extend the FTN MIB =
definition to support such services, and is it planned for a future =
revision of draft-ietf-mpls-ftn-mib ?</FONT></P>

<P><FONT SIZE=3D2>Marc</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Cheenu Srinivasan [<A =
HREF=3D"mailto:cheenu@alphion.com">mailto:cheenu@alphion.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Wednesday, August 22, 2001 7:07 PM</FONT>
<BR><FONT SIZE=3D2>To: mpls</FONT>
<BR><FONT SIZE=3D2>Cc: Thomas D. Nadeau (E-mail); Arun Viswanathan =
(E-mail); George</FONT>
<BR><FONT SIZE=3D2>Swallow; Vijay Srinivasan</FONT>
<BR><FONT SIZE=3D2>Subject: RE: I-D =
ACTION:draft-ietf-mpls-ftn-mib-03.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Folks,</FONT>
</P>

<P><FONT SIZE=3D2>Version 03 of the FTN MIB I-D is now available on the =
IETF</FONT>
<BR><FONT SIZE=3D2>website (see below). We (the authors) believe its =
ready</FONT>
<BR><FONT SIZE=3D2>for last call at this point. Please email your =
comments</FONT>
<BR><FONT SIZE=3D2>to the list. Thanks.</FONT>
</P>

<P><FONT SIZE=3D2>Cheenu</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Internet-Drafts@ietf.org [<A =
HREF=3D"mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, August 22, 2001 7:02 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: IETF-Announce</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: I-D =
ACTION:draft-ietf-mpls-ftn-mib-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; This draft is a work item of the Multiprotocol =
Label </FONT>
<BR><FONT SIZE=3D2>&gt; Switching Working Group of the IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Multiprotocol Label Switching (MPLS) </FONT>
<BR><FONT SIZE=3D2>&gt; FEC-To-NHLFE </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; (FTN) Management Information Base</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : T. Nadeau, C. =
Srinivasan, A. Viswanathan</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-ietf-mpls-ftn-mib-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
25</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
21-Aug-01</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This memo defines an experimental portion of =
the Management</FONT>
<BR><FONT SIZE=3D2>&gt; Information Base&nbsp; (MIB) for use with =
network management protocols in</FONT>
<BR><FONT SIZE=3D2>&gt; the Internet community.&nbsp; In particular, it =
describes managed objects</FONT>
<BR><FONT SIZE=3D2>&gt; for defining FEC-to-NHLFE mapping and =
corresponding actions for use</FONT>
<BR><FONT SIZE=3D2>&gt; with Multiprotocol Label Switching =
(MPLS).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.t=
xt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mpls-ft=
n-mib-03.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts are also available by anonymous =
FTP. Login </FONT>
<BR><FONT SIZE=3D2>&gt; with the username</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;anonymous&quot; and a password of your =
e-mail address. After logging in,</FONT>
<BR><FONT SIZE=3D2>&gt; type &quot;cd internet-drafts&quot; and =
then</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-ietf-mpls-ftn-mib-03.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A list of Internet-Drafts directories can be =
found in</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>&gt; or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Send a message to:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
mailserv@ietf.org.</FONT>
<BR><FONT SIZE=3D2>&gt; In the body type:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; NOTE: The mail server at ietf.org can return =
the document in</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded =
form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert =
the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; =
To decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant =
mail reader.&nbsp; Different MIME-compliant </FONT>
<BR><FONT SIZE=3D2>&gt; mail readers</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit =
different behavior, especially when dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages), so check your local documentation on</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to =
manipulate these messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Below is the data which will enable a MIME =
compliant mail reader</FONT>
<BR><FONT SIZE=3D2>&gt; implementation to automatically retrieve the =
ASCII version of the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12F0F.9C8129D0--


From owner-mpls@UU.NET  Mon Aug 27 11:58:28 2001
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 LAA22688
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:58:28 -0400 (EDT)
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 QQldxf17201;
	Mon, 27 Aug 2001 15:59:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxf25951
	for mpls-outgoing; Mon, 27 Aug 2001 15:59: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 QQldxf25943
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:59: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 QQldxf01394
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:58:55 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldxf23236
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:58:53 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA24945 for mpls@uu.net; Mon, 27 Aug 2001 11:58:53 -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 QQldxf25915
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 15:58:45 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 QQldxf16528
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:53:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldxf07326
	for <mpls@UU.NET>; Mon, 27 Aug 2001 15:53:05 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA11152; Mon, 27 Aug 2001 11:53:03 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AHB02587;
	Mon, 27 Aug 2001 11:53:01 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010827115311.036d6cb0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 11:54:22 -0700
To: "Marc Lamberton" <marc.lamberton@nortelnetworks.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
Cc: "'Cheenu Srinivasan'" <cheenu@alphion.com>, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <CF4991E8D749D411A8A30008C791861E01F31DEB@zvbnc0jb.europe.n
 ortel.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_186201633==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_186201633==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


         No, I don't think so. The l2->MPLS mappings that are proposed
are already satisfied using a combination of an L2 service-specific MIB
in cooperation with either the MPLS-LSR or MPLS-TE-MIBs (or both).

         --Tom


>the draft-ietf-mpls-ftn-mib-03.txt describes managed objects for defining 
>FEC-to-NHLFE mapping for L3 services. I mean
>the mplsFTNTable contains 6-tuple rules based on L3 and L4 header fields. 
>Several drafts are now proposed to provide L2 services on MPLS (e.g. 
>draft-martini-l2circuit-trans-mpls-07, draft-kompella-ppvpn-l2vpn-00, 
>draft-vkompella-ppvpn-vpsn-mpls-00,...)
>
>Do you think it will make sense to extend the FTN MIB definition to 
>support such services, and is it planned for a future revision of 
>draft-ietf-mpls-ftn-mib ?
>
>Marc
>
>-----Original Message-----
>From: Cheenu Srinivasan 
>[<mailto:cheenu@alphion.com>mailto:cheenu@alphion.com]
>Sent: Wednesday, August 22, 2001 7:07 PM
>To: mpls
>Cc: Thomas D. Nadeau (E-mail); Arun Viswanathan (E-mail); George
>Swallow; Vijay Srinivasan
>Subject: RE: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
>
>Folks,
>
>Version 03 of the FTN MIB I-D is now available on the IETF
>website (see below). We (the authors) believe its ready
>for last call at this point. Please email your comments
>to the list. Thanks.
>
>Cheenu
>
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org 
> [<mailto:Internet-Drafts@ietf.org>mailto:Internet-Drafts@ietf.org]
> > Sent: Wednesday, August 22, 2001 7:02 AM
> > To: IETF-Announce
> > Cc: mpls@UU.NET
> > Subject: I-D ACTION:draft-ietf-mpls-ftn-mib-03.txt
> >
> >
> > 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)
> > FEC-To-NHLFE
> >                           (FTN) Management Information Base
> >       Author(s)       : T. Nadeau, C. Srinivasan, A. Viswanathan
> >       Filename        : draft-ietf-mpls-ftn-mib-03.txt
> >       Pages           : 25
> >       Date            : 21-Aug-01
> >
> > This memo defines an experimental portion of the Management
> > Information Base  (MIB) for use with network management protocols in
> > the Internet community.  In particular, it describes managed objects
> > for defining FEC-to-NHLFE mapping and corresponding actions for use
> > with Multiprotocol Label Switching (MPLS).
> >
> > A URL for this Internet-Draft is:
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt>http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt 
>
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >       "get draft-ietf-mpls-ftn-mib-03.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> > or 
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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-ftn-mib-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.
> >

--=====================_186201633==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>No, I
don't think so. The l2-&gt;MPLS mappings that are proposed<br>
are already satisfied using a combination of an L2 service-specific
MIB<br>
in cooperation with either the MPLS-LSR or MPLS-TE-MIBs (or both).<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<blockquote type=cite cite><font size=2>the
draft-ietf-mpls-ftn-mib-03.txt describes managed objects for defining
FEC-to-NHLFE mapping for L3 services. I mean </font><br>
<font size=2>the mplsFTNTable contains 6-tuple rules based on L3 and L4
header fields. Several drafts are now proposed to provide L2 services on
MPLS (e.g. draft-martini-l2circuit-trans-mpls-07,
draft-kompella-ppvpn-l2vpn-00,
draft-vkompella-ppvpn-vpsn-mpls-00,...)<br>
</font><br>
<font size=2>Do you think it will make sense to extend the FTN MIB
definition to support such services, and is it planned for a future
revision of draft-ietf-mpls-ftn-mib ?<br>
</font><br>
<font size=2>Marc</font> <br>
<br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Cheenu Srinivasan
[<a href="mailto:cheenu@alphion.com">mailto:cheenu@alphion.com</a>]</font>
<br>
<font size=2>Sent: Wednesday, August 22, 2001 7:07 PM</font> <br>
<font size=2>To: mpls</font> <br>
<font size=2>Cc: Thomas D. Nadeau (E-mail); Arun Viswanathan (E-mail);
George</font> <br>
<font size=2>Swallow; Vijay Srinivasan</font> <br>
<font size=2>Subject: RE: I-D
ACTION:draft-ietf-mpls-ftn-mib-03.txt</font> <br>
<br>
<font size=2>Folks,</font> <br>
<br>
<font size=2>Version 03 of the FTN MIB I-D is now available on the
IETF</font> <br>
<font size=2>website (see below). We (the authors) believe its
ready</font> <br>
<font size=2>for last call at this point. Please email your
comments</font> <br>
<font size=2>to the list. Thanks.</font> <br>
<br>
<font size=2>Cheenu</font> <br>
<br>
<font size=2>&gt; -----Original Message-----</font> <br>
<font size=2>&gt; From: Internet-Drafts@ietf.org
[<a href="mailto:Internet-Drafts@ietf.org">mailto:Internet-Drafts@ietf.org</a>]</font>
<br>
<font size=2>&gt; Sent: Wednesday, August 22, 2001 7:02 AM</font> <br>
<font size=2>&gt; To: IETF-Announce</font> <br>
<font size=2>&gt; Cc: mpls@UU.NET</font> <br>
<font size=2>&gt; Subject: I-D
ACTION:draft-ietf-mpls-ftn-mib-03.txt</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; A New Internet-Draft is available from the on-line
</font><br>
<font size=2>&gt; Internet-Drafts directories.</font> <br>
<font size=2>&gt; This draft is a work item of the Multiprotocol Label
</font><br>
<font size=2>&gt; Switching Working Group of the IETF.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
Multiprotocol Label Switching (MPLS) </font><br>
<font size=2>&gt; FEC-To-NHLFE </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(FTN) Management Information Base</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : T. Nadeau, C. Srinivasan,
A. Viswanathan</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
draft-ietf-mpls-ftn-mib-03.txt</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
25</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
21-Aug-01</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>&gt; This memo defines an experimental portion of the
Management</font> <br>
<font size=2>&gt; Information Base&nbsp; (MIB) for use with network
management protocols in</font> <br>
<font size=2>&gt; the Internet community.&nbsp; In particular, it
describes managed objects</font> <br>
<font size=2>&gt; for defining FEC-to-NHLFE mapping and corresponding
actions for use</font> <br>
<font size=2>&gt; with Multiprotocol Label Switching (MPLS).</font> 
<br>
<font size=2>&gt; </font><br>
<font size=2>&gt; A URL for this Internet-Draft is:</font> <br>
<font size=2>&gt; <a href="http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-03.txt</a></font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Internet-Drafts are also available by anonymous FTP. Login </font><br>
<font size=2>&gt; with the username</font> <br>
<font size=2>&gt; &quot;anonymous&quot; and a password of your e-mail address. After logging in,</font> <br>
<font size=2>&gt; type &quot;cd internet-drafts&quot; and then</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get draft-ietf-mpls-ftn-mib-03.txt&quot;.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; A list of Internet-Drafts directories can be found in</font> <br>
<font size=2>&gt; <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> </font><br>
<font size=2>&gt; or <a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a></font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Internet-Drafts can also be obtained by e-mail.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Send a message to:</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv@ietf.org.</font> <br>
<font size=2>&gt; In the body type:</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE /internet-drafts/draft-ietf-mpls-ftn-mib-03.txt&quot;.</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>&gt; NOTE: The mail server at ietf.org can return the document in</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using the &quot;mpack&quot; utility.&nbsp; To use this</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command &quot;ENCODING mime&quot; before the &quot;FILE&quot;</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the response(s), you will need &quot;munpack&quot; or</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp; Different MIME-compliant </font><br>
<font size=2>&gt; mail readers</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, especially when dealing with</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME messages (i.e. documents which have been split</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), so check your local documentation on</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these messages.</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><br>
<font size=2>&gt; Below is the data which will enable a MIME compliant mail reader</font> <br>
<font size=2>&gt; implementation to automatically retrieve the ASCII version of the</font> <br>
<font size=2>&gt; Internet-Draft.</font> <br>
<font size=2>&gt; </font></blockquote></html>

--=====================_186201633==_.ALT--



From owner-mpls@UU.NET  Mon Aug 27 11:59:50 2001
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 LAA22742
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 11:59:50 -0400 (EDT)
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 QQldxg19832;
	Mon, 27 Aug 2001 16:01:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxg28553
	for mpls-outgoing; Mon, 27 Aug 2001 16:00: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 QQldxg28336
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 16:00:34 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 QQldxg06734
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:00:31 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 QQldxg24173
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:00:32 GMT
Message-ID: <3B8A6E9D.4E6FFCCA@sandburst.com>
Date: Mon, 27 Aug 2001 12:00:29 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Guangzhi Li <gli@research.att.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <3B8A4840.DCF7230E@research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Guangzhi,

    The thing I can't figure out, is where you're getting all of this from.
I can't help you with your issues, because - from where I sit - it looks
like you pulled them out of thin air.

    Could you provide more specific information about where you see the
these issues of contention being defined?

--
Eric Gray

You wrote:

> Dear GMPLS authors and all experts:
>
> During GMPLS last call, I posted the same question on the mailing list
> without response. Please somebody spend a little time and check with the
> following example? Something seems not clear when the current GMPLS
> contention resution schemes are applied on a framework with both
> bi-directional and uni-directional LSPs. Your clarification is very much
> appreciated.
>
> Sincerely,
>
> Guangzhi
>
> --------------------------------------------------------------------------------------------------
>
> The issue arises because contention is resolved between bi-directional
> LSPs by the node with the higher node index while for uni-directional
> LSPs, contention is resolved by the downstream node. Consider the
> following example of two nodes with paired, bi-directional interfaces
> (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> node 2 with ID = 50.  Node 1 uses label 1 for the transmitter port and
> label 2 for the receiver port; node 2 uses label 4 for the transmitter
> port and label 3 for the receiver port.   We assume that a
> bi-directional LSP requires a single I/O interface.
>
> We consider two LSPs - a uni-directional LSP (LSP A) and a
> bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2,
> with the uni-directional LSP setup request arriving marginally before
> the bi-directional LSP.  LSP A does not use a suggested label, and thus
> is assigned a label (port) by node 2.  Label 3 is assigned,
> corresponding to label 1 at node 1.  At the same time, for LSP B (the
> bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> Because node 1 has the higher node ID, node 2 will assume (due to the
> contention resolution rule for bi-directional LSPs) that LSP B wins the
> contention and thus label 3 is assigned to LSP B.  Thus label 1 at node
> 1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> LSPs have ?won? the contention.



From owner-mpls@UU.NET  Mon Aug 27 12:06:50 2001
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 MAA23064
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 12:06: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 QQldxg09709;
	Mon, 27 Aug 2001 16:07:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxg12600
	for mpls-outgoing; Mon, 27 Aug 2001 16:07: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 QQldxg11428
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 16:07:31 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 QQldxg08151
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:07:02 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 QQldxg04358
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:07:03 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 MAA19122
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:06:59 -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 MAA28370
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:06:59 -0400 (EDT)
Message-ID: <3B8A702D.1897E2CA@marconi.com>
Date: Mon, 27 Aug 2001 12:07:09 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <94B9091E1149D411A45C00508BACEB359CDD91@entmail.gnilink.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Martin, Christian" wrote:
> 
> RSVP is soft-state in both its distribution mechanism and its
> framework for distribution.  So, although there is reservation
> state OAM, there is no way to determine of the reservation messages
> are being delivered properly in the first place, at least in the
> current vendor implementations.

Implementation is the big deal.  There is the concept of a Resv Confirm
message in RSVP - part of RFC 2205.

When used, the end-to-end handshaking changes from two way (Path-Resv)
to three-way (Path-Resv-Confirm).  If there is a need for the egress to
know that the LSP has been set up, apart from simply receiving labeled
packets, it can use this mechanism.

But, as you say, not all implementations support this.

> Back to RSVP-TE, let us do something similar.  Again, we have two
> RSVP-TE endpoints that we wish to build an LSP between.  During the
> reservation setup step, we discover that we are not receiving RESV
> or RESVERR messages back.  Hrm.  Where is the problem?  We can do
> pings and traces, but that does not inform us whether or not there
> is a nodal RSVP handling issue on one or more processing devices in
> the path.  But what device?!  This is where I see a problem.

This is actually covered in the draft.  Admission control errors, which
in RFC 2205 cause the generation of ResvErr, in the RSVP-TE draft cause
the generation of PathErr.  See section 4.7.3 of the RSVP-TE draft.

In the case of a failure that takes place after the LSP is set up, RSVP
Hello will detect the failure and appropriate PathErr/ResvErr messages
should be sent to the endpoints of the LSP.  I don't know about GMPLS
(where data- and control-planes are separate) but I would assume that a
similar mechanism exists there.

In other words, the ingress node will be told about the failure.  It can
then try again with different parameters or report the failure to
management.

-- David


From owner-mpls@UU.NET  Mon Aug 27 12:23:03 2001
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 MAA23472
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 12:23:03 -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 QQldxh29506;
	Mon, 27 Aug 2001 16:24:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxh16752
	for mpls-outgoing; Mon, 27 Aug 2001 16:23:48 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 QQldxh16747
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 16:23:43 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 QQldxh18990
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:22:22 GMT
Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: entmail.gnilink.net [199.45.47.10])
	id QQldxh23403
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:22:24 GMT
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <RS6XFC72>; Mon, 27 Aug 2001 12:22:22 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDD96@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: mpls@UU.NET
Subject: RE: RSVP Hello
Date: Mon, 27 Aug 2001 12:22:17 -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

David,

Thanks for the reply.  Comments inline...

> 
> > Back to RSVP-TE, let us do something similar.  Again, we have two
> > RSVP-TE endpoints that we wish to build an LSP between.  During the
> > reservation setup step, we discover that we are not receiving RESV
> > or RESVERR messages back.  Hrm.  Where is the problem?  We can do
> > pings and traces, but that does not inform us whether or not there
> > is a nodal RSVP handling issue on one or more processing devices in
> > the path.  But what device?!  This is where I see a problem.
> 
> This is actually covered in the draft.  Admission control 
> errors, which
> in RFC 2205 cause the generation of ResvErr, in the RSVP-TE 
> draft cause
> the generation of PathErr.  See section 4.7.3 of the RSVP-TE draft.

A device (router) cannot send PathErr if it doesn't speak RSVP.  In 2205,
there is mention of Path messages passing through non-RSVP clouds.  For RSVP
flow reservations, this is fine, but for ERO/LRO's, this is not.  I would
think that the only response a router would take that isn't RSVP aware would
be to send an ICMP port unreachable message back to the source, as the UDP
port isn't awake.  I am trying to preemt this by knowing ahead of time that
a router is not listening to or processing RSVP messages.  There are
procedures for recongizing whether or not LRO is supported, but not whether
RSVP is supported.  Or am I missing something in the draft?


> 
> In the case of a failure that takes place after the LSP is 
> set up, RSVP
> Hello will detect the failure and appropriate PathErr/ResvErr messages
> should be sent to the endpoints of the LSP.  I don't know about GMPLS
> (where data- and control-planes are separate) but I would 
> assume that a
> similar mechanism exists there.

This is fine as it exists today.  I should also note that once a network has
built recervation state (and thus hello state), then everything is ok.  It
is the problems that occur while building the state that I am addressing.

-chris

> In other words, the ingress node will be told about the 
> failure.  It can
> then try again with different parameters or report the failure to
> management.
> 
> -- David
> 


From owner-mpls@UU.NET  Mon Aug 27 12:34:07 2001
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 MAA23838
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 12:34:07 -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 QQldxi16418;
	Mon, 27 Aug 2001 16:35:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxi17579
	for mpls-outgoing; Mon, 27 Aug 2001 16:34: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 QQldxi17565
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 16:34:43 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 QQldxi13297
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:34:35 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 QQldxi26563
	for <mpls@UU.NET>; Mon, 27 Aug 2001 16:34:34 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 MAA22244
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:34:33 -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 MAA04651
	for <mpls@UU.NET>; Mon, 27 Aug 2001 12:34:32 -0400 (EDT)
Message-ID: <3B8A76A3.F161A254@marconi.com>
Date: Mon, 27 Aug 2001 12:34:43 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <94B9091E1149D411A45C00508BACEB359CDD96@entmail.gnilink.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Martin, Christian" wrote:
> 
> A device (router) cannot send PathErr if it doesn't speak RSVP.  In
> 2205, there is mention of Path messages passing through non-RSVP
> clouds.

And this is made illegal in the RSVP-TE draft.  See sections 4.2.5 and
4.5.

If an RSVP router has a non-RSVP downstream neighbor, it must not send a
Path message with a label-request object.  Instead, it should send a
PathErr message.  Similarly, if a router receives a Path message with
label-request from a non-RSVP router, it should send back a PathErr
message.

The draft specifies the presence of a label-request object, because this
is the primary mechanism for differentiating an RSVP Path message from
an RSVP-TE Path message.  Within any reasonable kind of MPLS cloud, all
Path messages will be RSVP-TE and will have label-request objects.

-- David


From owner-mpls@UU.NET  Mon Aug 27 13:21:07 2001
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 NAA25123
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 13:21:06 -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 QQldxl26102;
	Mon, 27 Aug 2001 17:22:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxl09843
	for mpls-outgoing; Mon, 27 Aug 2001 17:21: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 QQldxl09835
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 17:21:53 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 QQldxl20477
	for <mpls@UU.NET>; Mon, 27 Aug 2001 17:21:04 GMT
Received: from tomp.smb.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQldxl01746
	for <mpls@UU.NET>; Mon, 27 Aug 2001 17:21:05 GMT
Received: from utfors.se ([10.58.0.94]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GIQLO200.97M;
          Mon, 27 Aug 2001 19:24:02 +0200 
Message-ID: <3B8A817E.46E525B0@utfors.se>
Date: Mon, 27 Aug 2001 19:21:02 +0200
From: Loa Andersson <loa.andersson@utfors.se>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <eric.gray@sandburst.com>
CC: David Allan <dallan@nortelnetworks.com>, Ping Pan <pingpan@juniper.net>,
        Neil Harrison <neil.2.harrison@bt.com>, mpls@UU.NET
Subject: Re: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC69@zcard0ka.ca.nortel.com> <3B8A69F1.8DB5DE4F@sandburst.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Eric,

it is always refreshing to have someone telling what I said. The way 
you summarize it fair - s long as the "long term" don't stop the work
on the "immediate and simple".

What I thought I said was that already the immediate is to complex and
has too many not needed bells and whistles.

I'll stop this thread here, but will go on arguing for further
simplicity
and usefulness where ever.

/Loa

Eric Gray wrote:
> 
> This seems like a noisy thread.  Some people (Neil and Dave) assert that
> OAM must be part of a long term solution and - hence - anything that does
> not contribute materially to this long term solution is going to be wasted
> effort.  Others (Loa and Ping) assert that the immediate solution should
> be simple and useful - or it will be irrelevant.
> 
> We're getting dangerously close to name calling from both sides - perhaps
> we may already have crossed the line.  Probably the thing to do at this
> point is to agree to disagree.  I suggest that people who are interested
> and believe in the value of a long term solution work on that solution
> while other people who are interested in and believe in a simple, useful,
> immediate solution work on that solution.  Ultimately, each group may end
> up borrowing from the other - possibly bettering both solutions - and, at
> some point, it is likely that one solution or the other will be overcome
> by events.
> 
> In the meantime, can we stop arguing which is better, a bolt or a cotter
> pin?
> 
> Thanks in advance,
> --
> Eric Gray
> 
> >
> >
> > Loa:
> >
> > PPP and L2TP are examples of IETF defined protocols that carry IP (and other
> > things),
> > would not be considered specifically part of IP, and are generally self
> > contained from
> > a functional POV. I'd lump MPLS in the same category.
> >
> > rgds
> > Dave
> >
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa.andersson@utfors.se]
> > Sent: Monday, August 27, 2001 10:19 AM
> > To: mpls@UU.NET
> > Cc: Allan, David [CAR:NS00:EXCH]
> > Subject: Re: Here we go again (Re: RSVP Hello)
> >
> > All,
> >
> > I'll try to be even more to the point - the first and foremost
> > requirement is simplicity. If MPLS is not simple, there will be no MPLS!
> >
> > The second requirement is usefulness, if MPLS is not useful, there will
> > be no MPLS (even though it is simple).
> >
> > Start looking at what is there and see if these requirements are met
> > otherwise take it out.
> >
> > BTW
> >
> > What do our AD's/WG's chairs think about the statement that this is not
> > part of the IP protocol suite, if you agree why are we doing this in
> > IETF?
> >
> > /Loa
> >
> > > David Allan wrote:
> > >
> > > Ping:
> > >
> > > I think the disconncect as to what MPLS "is" needs to be resolved. I
> > > think there is a large community that would be hard pressed to
> > > describe it as part of IP, at least as large as the commnunity trying
> > > to avoid having it called an ATM replacement (IMHO if we're looking
> > > for a monnicker; Frame relay in IP's image is really probably closer
> > > ;-).
> > >
> > > From a functional point of view it does insert stuff into the stack,
> > > call it a layer, helper or whatever, but to suggest it is not there,
> > > or is really an appendage, or can be dealt with piecemeal means we're
> > > going to be fixing this thing for a long time. This is where
> > > "architecture" is not religion but a genuinely useful discipline.
> > >
> > > I'm sure your proposal works for what it was designed to do, but IMHO
> > > it is a subset of what is required, and would most likely be rendered
> > > to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> > > simple.
> > >
> > > rgds
> > > Dave
> > >
> > > -----Original Message-----
> > > From: Ping Pan [mailto:pingpan@juniper.net]
> > > Sent: Sunday, August 26, 2001 2:01 AM
> > > To: neil.2.harrison@bt.com
> > > Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> > > Subject: Here we go again (Re: RSVP Hello)
> > >
> > > <snip>
> > >
> > > Sigh,,, after reading through this mail, I can relate to the feeling
> > > some people have on MPLS, that is, it's an ATM replacement. :-( I
> > > really
> > > hope not.
> > >
> > > Normally, the buzzwords such as "layers", "principles" and
> > > "architectures" are defined to make it easier to describe things. They
> > >
> > > are not defined to create new religions. Sometimes, they are more
> > > useful
> > > to marketing than to engineering. So if something is useful to the
> > > Internet, we try to come up with a simple solution and just build it.
> > > There is no magic to this process. So instead of talking about how I
> > > have broken the layers, principles, architectures and religious rules
> > > in
> > > LSP-ping, tell me why it does not work for the purpose it was designed
> > > for.
> > >
> > > > During the discussion of the Ping draft, I know Yakov described what
> > > I have
> > > > discussed above as 'working on LTSFGTC' (long-term solutions for
> > > generations
> > > > to come)...or something like that......but if we want MPLS itself to
> > > be a
> > > > LTSFGTC (and hopefully also give some solid foundation for those
> > > working in
> > > > the PWE3 and PPVPNs WGs) then we really have to get some of the
> > > basic OAM
> > > > architectural tenets right at the outset.
> > >
> > > If OAM is a great LTSFGTC, then there is nothing to be worried about
> > > on
> > > this "narrow-focused" LSP-ping. We do our work, and you do yours. What
> > > a
> > > beautiful thing!
> > >
> > > > Proper data-plane OAM, and its
> > > > decoupling from other client/server layer data-planes and/or
> > > specific
> > > > control (or management) plane protocols is not a 'luxury item', its
> > > just
> > > > plain common sense to avoid problems down the road.
> > > >
> > >
> > > It's also a common sense that in order to make MPLS working in the
> > > Internet, we need to keep it simple.
> > >
> > > Regards,
> > >
> > > - Ping
> >
> > --
> > 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

-- 
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 Aug 27 13:29:04 2001
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 NAA25315
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 13:29:03 -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 QQldxm11364;
	Mon, 27 Aug 2001 17:30:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxl10347
	for mpls-outgoing; Mon, 27 Aug 2001 17:29: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 QQldxl10340
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 17:29: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 QQldxl14423
	for <mpls@UU.NET>; Mon, 27 Aug 2001 17:29:02 GMT
Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQldxl05547
	for <mpls@UU.NET>; Mon, 27 Aug 2001 17:29:04 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 349374CEBC; Mon, 27 Aug 2001 13:29:02 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA03208;
	Mon, 27 Aug 2001 13:29:01 -0400 (EDT)
Message-ID: <3B8A84C4.E9A4A8C8@research.att.com>
Date: Mon, 27 Aug 2001 13:35:00 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Gray <eric.gray@sandburst.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <3B8A4840.DCF7230E@research.att.com> <3B8A6E9D.4E6FFCCA@sandburst.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eric:

In GMPLS functional specification:
(1) Two uni-directional LSPs establishment with label suggestion will result contention. Downstream node
label assignment policy solves the contention.
(2) Two bi-directional LSPs establishment with I/O pair restriction will result contention. LSP with
master node label assignment wins the contention.
(3) How about the contention between a uni-directional LSP and bi-directional LSP in the same framework?
The application is not clear currently. But if you draw figures by yourself, you may find the issue.

-- Guangzhi

Eric Gray wrote:

> Guangzhi,
>
>     The thing I can't figure out, is where you're getting all of this from.
> I can't help you with your issues, because - from where I sit - it looks
> like you pulled them out of thin air.
>
>     Could you provide more specific information about where you see the
> these issues of contention being defined?
>
> --
> Eric Gray
>
> You wrote:
>
> > Dear GMPLS authors and all experts:
> >
> > During GMPLS last call, I posted the same question on the mailing list
> > without response. Please somebody spend a little time and check with the
> > following example? Something seems not clear when the current GMPLS
> > contention resution schemes are applied on a framework with both
> > bi-directional and uni-directional LSPs. Your clarification is very much
> > appreciated.
> >
> > Sincerely,
> >
> > Guangzhi
> >
> > --------------------------------------------------------------------------------------------------
> >
> > The issue arises because contention is resolved between bi-directional
> > LSPs by the node with the higher node index while for uni-directional
> > LSPs, contention is resolved by the downstream node. Consider the
> > following example of two nodes with paired, bi-directional interfaces
> > (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > node 2 with ID = 50.  Node 1 uses label 1 for the transmitter port and
> > label 2 for the receiver port; node 2 uses label 4 for the transmitter
> > port and label 3 for the receiver port.   We assume that a
> > bi-directional LSP requires a single I/O interface.
> >
> > We consider two LSPs - a uni-directional LSP (LSP A) and a
> > bi-directional LSP (LSP B). Both LSPs are going from node 1 to node 2,
> > with the uni-directional LSP setup request arriving marginally before
> > the bi-directional LSP.  LSP A does not use a suggested label, and thus
> > is assigned a label (port) by node 2.  Label 3 is assigned,
> > corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > Because node 1 has the higher node ID, node 2 will assume (due to the
> > contention resolution rule for bi-directional LSPs) that LSP B wins the
> > contention and thus label 3 is assigned to LSP B.  Thus label 1 at node
> > 1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > LSPs have ?won? the contention.



From owner-mpls@UU.NET  Mon Aug 27 14:14:32 2001
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 OAA26391
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 14:14:30 -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 QQldxo04003;
	Mon, 27 Aug 2001 18:14:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxo01861
	for mpls-outgoing; Mon, 27 Aug 2001 18:14: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 QQldxo01856
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 18:14:01 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 QQldxo19574
	for <mpls@UU.NET>; Mon, 27 Aug 2001 18:13:48 GMT
Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: int.zaffire.com [63.121.21.2])
	id QQldxo14083
	for <mpls@UU.NET>; Mon, 27 Aug 2001 18:13:50 GMT
Received: by ICARIAN with Internet Mail Service (5.5.2653.19)
	id <QC910AGV>; Mon, 27 Aug 2001 11:13:51 -0700
Message-ID: <4611AD058694D4118FD5009027B0A6622B90DD@ICARIAN>
From: Fong Liaw <fliaw@zaffire.com>
To: "'Guangzhi Li'" <gli@research.att.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Mon, 27 Aug 2001 11:13:40 -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

Guangzhi

The GMPLS contention resolution applies to the scenario
that two Path messages cross each other.  Your example
have Resv and Path cross each other so the rule in the
contention resolution does not directly apply and is more
of a policy and implementation issue.

Here is one possible solution and is within the 
interpretation of the draft, IMHO. here it is.
If node 2 already sends Resv to node 1, LSP A should
be considered established and therefore LSP B should
be rejected by node 2. If node 2 hasn't sent back Resv, 
LSP A is still in establishing mode and node 2 can resolve
the contention internally by rejecting LSP A or LSP B, based
on their setting up priority or it can change LSP A's
label and reprogram the cross-connect without ever noticed
by any external node.  In both cases, node 2 is the one
that resolve this contention.  Hope this helps.

p.s. I think you meant to use LABEL_SET since 
Suggested label is a suggestion, not a hard binding.

Regards
-Fong


>  -----Original Message-----
>  From: Guangzhi Li [mailto:gli@research.att.com]
>  Sent: Monday, August 27, 2001 6:17 AM
>  To: ccamp@ops.ietf.org; mpls@UU.NET
>  Cc: gli@research.att.com
>  Subject: Question on GMPLS contentions resolution
>  
>  
>  Dear GMPLS authors and all experts:
>  
>  During GMPLS last call, I posted the same question on the 
>  mailing list
>  without response. Please somebody spend a little time and 
>  check with the
>  following example? Something seems not clear when the current GMPLS
>  contention resution schemes are applied on a framework with both
>  bi-directional and uni-directional LSPs. Your clarification 
>  is very much
>  appreciated.
>  
>  Sincerely,
>  
>  Guangzhi
>  
>  -------------------------------------------------------------
>  -------------------------------------
>  
>  The issue arises because contention is resolved between 
>  bi-directional
>  LSPs by the node with the higher node index while for uni-directional
>  LSPs, contention is resolved by the downstream node. Consider the
>  following example of two nodes with paired, bi-directional interfaces
>  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
>  node 2 with ID = 50.  Node 1 uses label 1 for the 
>  transmitter port and
>  label 2 for the receiver port; node 2 uses label 4 for the 
>  transmitter
>  port and label 3 for the receiver port.   We assume that a
>  bi-directional LSP requires a single I/O interface.
>  
>  We consider two LSPs - a uni-directional LSP (LSP A) and a
>  bi-directional LSP (LSP B). Both LSPs are going from node 1 
>  to node 2,
>  with the uni-directional LSP setup request arriving marginally before
>  the bi-directional LSP.  LSP A does not use a suggested 
>  label, and thus
>  is assigned a label (port) by node 2.  Label 3 is assigned,
>  corresponding to label 1 at node 1.  At the same time, for LSP B (the
>  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
>  Because node 1 has the higher node ID, node 2 will assume (due to the
>  contention resolution rule for bi-directional LSPs) that LSP 
>  B wins the
>  contention and thus label 3 is assigned to LSP B.  Thus 
>  label 1 at node
>  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
>  LSPs have "won" the contention.
>  
>  


From owner-mpls@UU.NET  Mon Aug 27 14:52:06 2001
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 OAA27059
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 14:52:05 -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 QQldxr03817;
	Mon, 27 Aug 2001 18:53:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxr05383
	for mpls-outgoing; Mon, 27 Aug 2001 18:52:48 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 QQldxr05375
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 18:52: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 QQldxr10328
	for <mpls@uu.net>; Mon, 27 Aug 2001 18:52:45 GMT
Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQldxr13465
	for <mpls@uu.net>; Mon, 27 Aug 2001 18:52:46 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA26959
	for <mpls@uu.net>; Mon, 27 Aug 2001 14:52:44 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA23853 for mpls@uu.net; Mon, 27 Aug 2001 14:52:14 -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 QQldxr05178
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 18:51:05 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 QQldxr00557
	for <mpls@uu.net>; Mon, 27 Aug 2001 18:49:29 GMT
Received: from elrond.trinicom.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [63.149.136.227])
	id QQldxr27524
	for <mpls@uu.net>; Mon, 27 Aug 2001 18:49:30 GMT
Received: (qmail 29299 invoked by uid 30); 27 Aug 2001 18:49:07 -0000
Date: 27 Aug 2001 18:49:07 -0000
Message-ID: <20010827184907.29296.qmail@elrond.trinicom.com>
To: cmartin@gnilink.net;, mpls@UU.NET
Subject: Re: RSVP Hello
From: Sean Crocker <crockers@trinicom.com>
X-Mailer: Postaci 1.1.0 (ftp://ftp.onar.com.tr/pub/linux/postaci)
X-Comment: This message was sent from 216.174.224.251
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary = b6b2311c0cda5c63046c2e42b8bdbbb5d
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a MIME encoded message.

--b6b2311c0cda5c63046c2e42b8bdbbb5d
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

> A device (router) cannot send PathErr if it doesn't speak RSVP.  In 2205,
> there is mention of Path messages passing through non-RSVP clouds.  For RSVP
> flow reservations, this is fine, but for ERO/LRO's, this is not.  I would
> think that the only response a router would take that isn't RSVP aware would
> be to send an ICMP port unreachable message back to the source, as the UDP
> port isn't awake.  I am trying to preemt this by knowing ahead of time that
> a router is not listening to or processing RSVP messages.  There are
> procedures for recongizing whether or not LRO is supported, but not whether
> RSVP is supported.  Or am I missing something in the draft?

Chris,

Here's one way to do it that's been covered before, at least for MPLS-TE.  Given the following topology:

Upstream---Non-RSVP---Downstream

Upstream sends PATH.  Non-RSVP looks at it due to Router Alert option set.  It's not configured for RSVP, but it *should* forward it on to the true destination instead of discarding it.  I'd say *must*, but RFC2113 isn't clear to me on what should happen.  This is just an observation from experience.

When Downstream receives the PATH, the downstream performs a sanity check.  If the IP header TTL is less than the RSVP header TTL, then it's probably safe to say there's a non-RSVP neighbor by sending error code 24, error value 8 back to the PATH originator.

Some implementations do this, some don't.  Folks, is this considered a reliable enough mechanism to be specified in the RSVP-TE draft?

Sean




---------------------------------------
This message was sent by www.trinicom.com Webmail.
--b6b2311c0cda5c63046c2e42b8bdbbb5d--





From owner-mpls@UU.NET  Mon Aug 27 15:24:08 2001
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 PAA27839
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 15:24:08 -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 QQldxt28613;
	Mon, 27 Aug 2001 19:25:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxt26472
	for mpls-outgoing; Mon, 27 Aug 2001 19:24: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 QQldxt26462
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 19:24:25 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 QQldxt09910
	for <mpls@uu.net>; Mon, 27 Aug 2001 19:23:09 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 QQldxt01860
	for <mpls@uu.net>; Mon, 27 Aug 2001 19:23:10 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 PAA10912
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:23:01 -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 PAA24984
	for <mpls@uu.net>; Mon, 27 Aug 2001 15:23:01 -0400 (EDT)
Message-ID: <3B8A9E20.287D91DB@marconi.com>
Date: Mon, 27 Aug 2001 15:23:12 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP Hello
References: <20010827184907.29296.qmail@elrond.trinicom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sean Crocker wrote:
> 
> Here's one way to do it that's been covered before, at least for
> MPLS-TE.  Given the following topology:
> 
> Upstream---Non-RSVP---Downstream
> 
> Upstream sends PATH.  Non-RSVP looks at it due to Router Alert
> option set.  It's not configured for RSVP, but it *should* forward
> it on to the true destination instead of discarding it.  I'd say
> *must*, but RFC2113 isn't clear to me on what should happen.  This
> is just an observation from experience.
> 
> When Downstream receives the PATH, the downstream performs a sanity
> check.  If the IP header TTL is less than the RSVP header TTL, then
> it's probably safe to say there's a non-RSVP neighbor by sending
> error code 24, error value 8 back to the PATH originator.
> 
> Some implementations do this, some don't.  Folks, is this
> considered a reliable enough mechanism to be specified in the
> RSVP-TE draft?

This is mandatory behavior.

This algorithm is described in RFC 2205.  In there, RSVP is supposed to
respond to a non-RSVP router by setting the "adspec break" bit in the
ADSPEC object.  This way, the egress router will know that the Path went
through a non-RSVP router, and that QoS reservations can not be
guaranteed.

In RSVP-TE, the PathErr for non-MPLS router was invented because MPLS
itself can't work if one or more node along the LSP doesn't participate
in the signaling.

-- David


From owner-mpls@UU.NET  Mon Aug 27 15:39:46 2001
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 PAA28159
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 15:39:46 -0400 (EDT)
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 QQldxu29997;
	Mon, 27 Aug 2001 19:40:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxu27728
	for mpls-outgoing; Mon, 27 Aug 2001 19:40:30 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 QQldxu27723
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 19:40: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 QQldxu28985
	for <mpls@uu.net>; Mon, 27 Aug 2001 19:40:05 GMT
Received: from exc-sc1.yagosys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQldxu28263
	for <mpls@uu.net>; Mon, 27 Aug 2001 19:40:06 GMT
Received: by exc-sc1 with Internet Mail Service (5.5.2653.19)
	id <QZL3RG7T>; Mon, 27 Aug 2001 12:40:33 -0700
Message-ID: <329F35B18824D511B9C30008C733955828F4FF@exc-sc1>
From: "Haridass, Govind" <gharidas@riverstonenet.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question in creating entries in ifStackTable...
Date: Mon, 27 Aug 2001 12:40:31 -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,

	"draft-ietf-mpls-lsr-mib-07.txt" says that the MPLS interface
	should be above an "Underlying Layer..."  in the ifStackTable.

	In our case we can start mpls over an IP interface.  Can the
	"Underlying layer..." be the IP interface ?

	Thanks and I appreciate all your help regarding this.

===
With Warm Regards,
Govind,
Riverstone Networks.
http://www.riverstonenet.com/



From owner-mpls@UU.NET  Mon Aug 27 16:13:47 2001
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 QAA28841
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 16:13: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 QQldxw19248;
	Mon, 27 Aug 2001 20:14:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxw18862
	for mpls-outgoing; Mon, 27 Aug 2001 20:14: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 QQldxw18857
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:14: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 QQldxw03417
	for <mpls@UU.NET>; Mon, 27 Aug 2001 20:13:56 GMT
Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: entmail.gnilink.net [199.45.47.10])
	id QQldxw19548
	for <mpls@UU.NET>; Mon, 27 Aug 2001 20:13:57 GMT
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19)
	id <RS6XFD32>; Mon, 27 Aug 2001 16:13:55 -0400
Message-ID: <94B9091E1149D411A45C00508BACEB359CDD9D@entmail.gnilink.com>
From: "Martin, Christian" <cmartin@gnilink.net>
To: mpls@UU.NET
Subject: RE: RSVP Hello
Date: Mon, 27 Aug 2001 16:13:46 -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

OK.  So we have a detection mechanism during the failure.  Looks as if the
vendors aren't reporting this in the debug output.  Either way, this is an
after the fact detection mechanism.  What I was looking for is a way to
determine if the path is RSVP-aware end-to-end before an LSP is being
established, or even worse yet, rerouted.  Thanks for clarifying this.

chris

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Monday, August 27, 2001 3:23 PM
> To: mpls@UU.NET
> Subject: Re: RSVP Hello
> 
> 
> Sean Crocker wrote:
> > 
> > Here's one way to do it that's been covered before, at least for
> > MPLS-TE.  Given the following topology:
> > 
> > Upstream---Non-RSVP---Downstream
> > 
> > Upstream sends PATH.  Non-RSVP looks at it due to Router Alert
> > option set.  It's not configured for RSVP, but it *should* forward
> > it on to the true destination instead of discarding it.  I'd say
> > *must*, but RFC2113 isn't clear to me on what should happen.  This
> > is just an observation from experience.
> > 
> > When Downstream receives the PATH, the downstream performs a sanity
> > check.  If the IP header TTL is less than the RSVP header TTL, then
> > it's probably safe to say there's a non-RSVP neighbor by sending
> > error code 24, error value 8 back to the PATH originator.
> > 
> > Some implementations do this, some don't.  Folks, is this
> > considered a reliable enough mechanism to be specified in the
> > RSVP-TE draft?
> 
> This is mandatory behavior.
> 
> This algorithm is described in RFC 2205.  In there, RSVP is 
> supposed to
> respond to a non-RSVP router by setting the "adspec break" bit in the
> ADSPEC object.  This way, the egress router will know that 
> the Path went
> through a non-RSVP router, and that QoS reservations can not be
> guaranteed.
> 
> In RSVP-TE, the PathErr for non-MPLS router was invented because MPLS
> itself can't work if one or more node along the LSP doesn't 
> participate
> in the signaling.
> 
> -- David
> 


From owner-mpls@UU.NET  Mon Aug 27 16:24:40 2001
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 QAA29073
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 16:24:39 -0400 (EDT)
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 QQldxx07588;
	Mon, 27 Aug 2001 20:25:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxx19736
	for mpls-outgoing; Mon, 27 Aug 2001 20:25: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 QQldxx19731
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:25: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 QQldxx08749
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:25:28 GMT
Received: from nwmq0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwmq0102a.jc.digitran.com [165.251.28.22])
	id QQldxx08445
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:25:29 GMT
Received: from csrinivasan [12.34.209.74] by nwmq0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Mon, 27 Aug 2001 16:20:22 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Haridass, Govind'" <gharidas@riverstonenet.com>
Cc: <mpls@UU.NET>
Subject: RE: Question in creating entries in ifStackTable...
Date: Mon, 27 Aug 2001 16:38:11 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB12B@OPTONT>
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <329F35B18824D511B9C30008C733955828F4FF@exc-sc1>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 	"draft-ietf-mpls-lsr-mib-07.txt" says that the MPLS interface
> 	should be above an "Underlying Layer..."  in the ifStackTable.
> 
> 	In our case we can start mpls over an IP interface.  Can the
> 	"Underlying layer..." be the IP interface ?

Underlying layer is the one that MPLS is running on. What do you mean
by "IP interface"?



From owner-mpls@UU.NET  Mon Aug 27 16:50:49 2001
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 QAA29971
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 16:50:49 -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 QQldxz17035;
	Mon, 27 Aug 2001 20:52:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxz21935
	for mpls-outgoing; Mon, 27 Aug 2001 20:51:28 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 QQldxz21928
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:51:18 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 QQldxz27102
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:50:06 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldxz14265
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:50:07 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 QAA20659 for <mpls@uu.net>; Mon, 27 Aug 2001 16:50:05 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA24385 for mpls@uu.net; Mon, 27 Aug 2001 16:49:35 -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 QQldxz21702
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:48:14 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 QQldxz25445
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:47:06 GMT
Received: from elrond.trinicom.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [63.149.136.227])
	id QQldxz10151
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:47:07 GMT
Received: (qmail 4047 invoked by uid 30); 27 Aug 2001 20:46:43 -0000
Date: 27 Aug 2001 20:46:43 -0000
Message-ID: <20010827204643.4046.qmail@elrond.trinicom.com>
To: mpls@UU.NET, david.charlap@marconi.com
Subject: RSVP Hello
From: Sean Crocker <crockers@trinicom.com>
X-Mailer: Postaci 1.1.0 (ftp://ftp.onar.com.tr/pub/linux/postaci)
X-Comment: This message was sent from 216.174.224.251
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary = b045dc628317dd02e45c4e44e060770ec
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a MIME encoded message.

--b045dc628317dd02e45c4e44e060770ec
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

>This is mandatory behavior.
>
>This algorithm is described in RFC 2205.  In there, RSVP is supposed to
>respond to a non-RSVP router by setting the "adspec break" bit in the
>ADSPEC object.  This way, the egress router will know that the Path went
>through a non-RSVP router, and that QoS reservations can not be
>guaranteed.
>
>In RSVP-TE, the PathErr for non-MPLS router was invented because MPLS
>itself can't work if one or more node along the LSP doesn't participate
>in the signaling.

David,

I agree with you that this is mandatory.  However, quoting section 4.2.5 of the RSVP-TE
draft:


   RSVP is designed to cope gracefully with non-RSVP routers anywhere
   between senders and receivers. However, obviously, non-RSVP routers
   cannot convey labels via RSVP. This means that if a router has a
   neighbor that is known to not be RSVP capable, the router MUST NOT
   advertise the LABEL_REQUEST object when sending messages that pass
   through the non-RSVP routers.  The router SHOULD send a PathErr back
   to the sender, with the error code "Routing problem" and the error
   value "MPLS being negotiated, but a non-RSVP capable router stands in
   the path."  This same message SHOULD be sent, if a router receives a
   LABEL_REQUEST object in a message from a non-RSVP capable router. See
   [1] for a description of how a downstream router can determine the
   presence of non-RSVP routers.

So I'm assuming the last sentence is a reference to the algorithm in the last paragraph of
RFC2205 section 3.8.  However, that reference seems to partially dismiss this (at least to
me it appears that way):

      With normal IP forwarding, RSVP can detect a non-RSVP hop by
      comparing the IP TTL with which a Path message is sent to the TTL
      with which it is received; for this purpose, the transmission TTL
      is placed in the common header.  However, the TTL is not always a
      reliable indicator of non-RSVP hops, and other means must
      sometimes be used.  

I'm thinking that if this is the best way to detect a non-RSVP upstream neighbor, then
perhaps the RSVP-TE draft should be reworded to explicitly include this mechanism to
prevent confusion.

Sean

>
>-- David






---------------------------------------
This message was sent by www.trinicom.com Webmail.
--b045dc628317dd02e45c4e44e060770ec--





From owner-mpls@UU.NET  Mon Aug 27 16:52:36 2001
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 QAA29998
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 16:52:36 -0400 (EDT)
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 QQldxz20327;
	Mon, 27 Aug 2001 20:53:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldxz22100
	for mpls-outgoing; Mon, 27 Aug 2001 20:53: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 QQldxz22095
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:53:28 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 QQldxz29475
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:53:15 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldxz18921
	for <mpls@uu.net>; Mon, 27 Aug 2001 20:53:16 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA22275 for mpls@uu.net; Mon, 27 Aug 2001 16:53:13 -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 QQldxz22047
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 20:52:51 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 QQldxz23226
	for <mpls@UU.NET>; Mon, 27 Aug 2001 20:51:09 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQldxz16137
	for <mpls@UU.NET>; Mon, 27 Aug 2001 20:51:08 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20784; Mon, 27 Aug 2001 16:51:08 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AHB07858;
	Mon, 27 Aug 2001 16:51:07 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010827164957.039e2e80@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 16:52:28 -0700
To: "Haridass, Govind" <gharidas@riverstonenet.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Question in creating entries in ifStackTable...
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <329F35B18824D511B9C30008C733955828F4FF@exc-sc1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>         "draft-ietf-mpls-lsr-mib-07.txt" says that the MPLS interface
>         should be above an "Underlying Layer..."  in the ifStackTable.
>
>         In our case we can start mpls over an IP interface.  Can the
>         "Underlying layer..." be the IP interface ?

         Yes.  The "underlying layer" refers to whatever
layer/interface MPLS runs over. Some implementations
conceptually run MPLS over the L2 interface, others
stack it over the IP interface.

         --tom



From owner-mpls@UU.NET  Mon Aug 27 17:08:31 2001
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 RAA00576
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 17:08:31 -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 QQldya14219;
	Mon, 27 Aug 2001 21:09:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldya11727
	for mpls-outgoing; Mon, 27 Aug 2001 21:09:09 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 QQldya11719
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 21:09: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 QQldya17279
	for <mpls@UU.NET>; Mon, 27 Aug 2001 21:07:27 GMT
Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQldya09940
	for <mpls@UU.NET>; Mon, 27 Aug 2001 21:07:29 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 477264CED8; Mon, 27 Aug 2001 17:07:27 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id RAA28466;
	Mon, 27 Aug 2001 17:07:26 -0400 (EDT)
Message-ID: <3B8AB7F4.2C91848D@research.att.com>
Date: Mon, 27 Aug 2001 17:13:24 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fong Liaw <fliaw@zaffire.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <4611AD058694D4118FD5009027B0A6622B90DD@ICARIAN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fong:

Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both
uni-directional and bi-directional together and uses the same port pool,
then a PATH and a RESV may cross each other. I think that it should be legal
based on current GMPLS specification. IF this scenario happens, GMPLS has to
provide one standard way to handle this situation.

Your suggestion works but it still involves the implementations of node 1
and node 2. Both nodes should interperate the same way. That means RESV
message always wins PATH message. No problem.

I assume that the I/O ports of bi-didrectional LSP are paired together, then
suggested_label = upstream_label and suggested_label is hard binding. Note
that contention happens in either this case or lack of resource. If
suggested_label could be different upstream_label, no contention problem at
all.

-- Guangzhi

Fong Liaw wrote:

> Guangzhi
>
> The GMPLS contention resolution applies to the scenario
> that two Path messages cross each other.  Your example
> have Resv and Path cross each other so the rule in the
> contention resolution does not directly apply and is more
> of a policy and implementation issue.
>
> Here is one possible solution and is within the
> interpretation of the draft, IMHO. here it is.
> If node 2 already sends Resv to node 1, LSP A should
> be considered established and therefore LSP B should
> be rejected by node 2. If node 2 hasn't sent back Resv,
> LSP A is still in establishing mode and node 2 can resolve
> the contention internally by rejecting LSP A or LSP B, based
> on their setting up priority or it can change LSP A's
> label and reprogram the cross-connect without ever noticed
> by any external node.  In both cases, node 2 is the one
> that resolve this contention.  Hope this helps.
>
> p.s. I think you meant to use LABEL_SET since
> Suggested label is a suggestion, not a hard binding.
>
> Regards
> -Fong
>
> >  -----Original Message-----
> >  From: Guangzhi Li [mailto:gli@research.att.com]
> >  Sent: Monday, August 27, 2001 6:17 AM
> >  To: ccamp@ops.ietf.org; mpls@UU.NET
> >  Cc: gli@research.att.com
> >  Subject: Question on GMPLS contentions resolution
> >
> >
> >  Dear GMPLS authors and all experts:
> >
> >  During GMPLS last call, I posted the same question on the
> >  mailing list
> >  without response. Please somebody spend a little time and
> >  check with the
> >  following example? Something seems not clear when the current GMPLS
> >  contention resution schemes are applied on a framework with both
> >  bi-directional and uni-directional LSPs. Your clarification
> >  is very much
> >  appreciated.
> >
> >  Sincerely,
> >
> >  Guangzhi
> >
> >  -------------------------------------------------------------
> >  -------------------------------------
> >
> >  The issue arises because contention is resolved between
> >  bi-directional
> >  LSPs by the node with the higher node index while for uni-directional
> >  LSPs, contention is resolved by the downstream node. Consider the
> >  following example of two nodes with paired, bi-directional interfaces
> >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> >  node 2 with ID = 50.  Node 1 uses label 1 for the
> >  transmitter port and
> >  label 2 for the receiver port; node 2 uses label 4 for the
> >  transmitter
> >  port and label 3 for the receiver port.   We assume that a
> >  bi-directional LSP requires a single I/O interface.
> >
> >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> >  to node 2,
> >  with the uni-directional LSP setup request arriving marginally before
> >  the bi-directional LSP.  LSP A does not use a suggested
> >  label, and thus
> >  is assigned a label (port) by node 2.  Label 3 is assigned,
> >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> >  Because node 1 has the higher node ID, node 2 will assume (due to the
> >  contention resolution rule for bi-directional LSPs) that LSP
> >  B wins the
> >  contention and thus label 3 is assigned to LSP B.  Thus
> >  label 1 at node
> >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> >  LSPs have "won" the contention.
> >
> >



From owner-mpls@UU.NET  Mon Aug 27 21:29:15 2001
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 VAA05869
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 21:29: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 QQldys04781;
	Tue, 28 Aug 2001 01:30:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldys14124
	for mpls-outgoing; Tue, 28 Aug 2001 01:30:06 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 QQldys14119
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 01:30: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 QQldyr20620
	for <mpls@uu.net>; Tue, 28 Aug 2001 01:29:40 GMT
Received: from smtp03.mrf.mail.rcn.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp03.mrf.mail.rcn.net [207.172.4.62])
	id QQldyr02846
	for <mpls@uu.net>; Tue, 28 Aug 2001 01:29:39 GMT
Received: from 66-44-66-203.s203.tnt7.lnhva.md.dialup.rcn.com ([66.44.66.203] helo=erols.com)
	by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.32 #2)
	id 15bXhB-0001Xq-00 ; Mon, 27 Aug 2001 21:29:38 -0400
Message-ID: <3B8A2149.7EBED033@erols.com>
Date: Mon, 27 Aug 2001 03:30:33 -0700
From: Sham Chakravorty <sc12@erols.com>
X-Mailer: Mozilla 4.74 [en]C-CCK-MCD {Starpower}  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Loa Andersson <loa.andersson@utfors.se>
CC: mpls@UU.NET
Subject: QoSRe: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com> <3B8A56C2.134BA1C9@utfors.se>
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 VAA05869

See comments inline -

> I'll try to be even more to the point - the first and foremost requirement
> is simplicity. If MPLS is not simple, there will be no MPLS!

In IMHO, MPLS is not simple.  Consider all the drafts that have been fielded
for the past four years - over 120 (?) or so to solve its many issues - not
withstanding mixed VC setup criteria of RSVP-TE and CR-LDP for a starter.
MPLS unfortunately does not meet the simplicity criterion. (You may have
prophesized something here in line with what is coming out in the press more
and more.  See Lightreading.com's recent article: "Poll: Is MPLS BS?"
Majority taking the poll seem have to said, yes. One would have been hung in
the broad day light to put out an article with such a title just a year
ago.)

> The second requirement is usefulness, if MPLS is not useful, there will be
> no MPLS (even though it is simple).

With no built-in framework for QoS deployment and no extensibility to
enterprise networks (over Ethernets, e.g.), its usefulness as many have
pointed out before, on this board and elsewhere, is at best very limited.

SC

> Start looking at what is there and see if these requirements are met
> otherwise take it out.
>
> BTW
>
> What do our AD's/WG's chairs think about the statement that this is not
> part of the IP protocol suite, if you agree why are we doing this in
> IETF?
>
> /Loa
>
> > David Allan wrote:
> >
> > Ping:
> >
> > I think the disconncect as to what MPLS "is" needs to be resolved. I
> > think there is a large community that would be hard pressed to
> > describe it as part of IP, at least as large as the commnunity trying
> > to avoid having it called an ATM replacement (IMHO if we're looking
> > for a monnicker; Frame relay in IP's image is really probably closer
> > ;-).
> >
> > From a functional point of view it does insert stuff into the stack,
> > call it a layer, helper or whatever, but to suggest it is not there,
> > or is really an appendage, or can be dealt with piecemeal means we're
> > going to be fixing this thing for a long time. This is where
> > "architecture" is not religion but a genuinely useful discipline.
> >
> > I'm sure your proposal works for what it was designed to do, but IMHO
> > it is a subset of what is required, and would most likely be rendered
> > to be superfluous baggage by any LTSFGTC. Which means MPLS will not be
> > simple.
> >
> > rgds
> > Dave
> >
> > -----Original Message-----
> > From: Ping Pan [mailto:pingpan@juniper.net]
> > Sent: Sunday, August 26, 2001 2:01 AM
> > To: neil.2.harrison@bt.com
> > Cc: bill.sanford@netplane.com; cmartin@gnilink.net; mpls@UU.NET
> > Subject: Here we go again (Re: RSVP Hello)
> >
> > <snip>
> >
> > Sigh,,, after reading through this mail, I can relate to the feeling
> > some people have on MPLS, that is, it's an ATM replacement. :-( I
> > really
> > hope not.
> >
> > Normally, the buzzwords such as "layers", "principles" and
> > "architectures" are defined to make it easier to describe things. They
> >
> > are not defined to create new religions. Sometimes, they are more
> > useful
> > to marketing than to engineering. So if something is useful to the
> > Internet, we try to come up with a simple solution and just build it.
> > There is no magic to this process. So instead of talking about how I
> > have broken the layers, principles, architectures and religious rules
> > in
> > LSP-ping, tell me why it does not work for the purpose it was designed
> > for.
> >
> > > During the discussion of the Ping draft, I know Yakov described what
> > I have
> > > discussed above as 'working on LTSFGTC' (long-term solutions for
> > generations
> > > to come)...or something like that......but if we want MPLS itself to
> > be a
> > > LTSFGTC (and hopefully also give some solid foundation for those
> > working in
> > > the PWE3 and PPVPNs WGs) then we really have to get some of the
> > basic OAM
> > > architectural tenets right at the outset.
> >
> > If OAM is a great LTSFGTC, then there is nothing to be worried about
> > on
> > this "narrow-focused" LSP-ping. We do our work, and you do yours. What
> > a
> > beautiful thing!
> >
> > > Proper data-plane OAM, and its
> > > decoupling from other client/server layer data-planes and/or
> > specific
> > > control (or management) plane protocols is not a 'luxury item', its
> > just
> > > plain common sense to avoid problems down the road.
> > >
> >
> > It's also a common sense that in order to make MPLS working in the
> > Internet, we need to keep it simple.
> >
> > Regards,
> >
> > - Ping
>
> --
> 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 Aug 27 22:45:51 2001
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 WAA09102
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 22:45:51 -0400 (EDT)
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 QQldyx23803;
	Tue, 28 Aug 2001 02:47:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldyx08279
	for mpls-outgoing; Tue, 28 Aug 2001 02:46: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 QQldyx08272
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 02:46:28 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 QQldyx29346
	for <mpls@UU.NET>; Tue, 28 Aug 2001 02:46:27 GMT
Received: from smtp.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [61.144.161.21])
	id QQldyx00622
	for <mpls@UU.NET>; Tue, 28 Aug 2001 02:46:24 GMT
Received: from zheng04822 ([10.110.9.131]) by smtp.huawei.com
          (Netscape Messaging Server 4.15) with SMTP id GIRBLW00.C3W for
          <mpls@UU.NET>; Tue, 28 Aug 2001 10:44:20 +0800 
Message-ID: <002201c12f6b$b41a1960$70040101@huawei.com>
Reply-To: "Paul Zheng" <zhengdaoqing@huawei.com>
From: "Paul Zheng" <zhengdaoqing@huawei.com>
To: <mpls@UU.NET>
Subject: Question about LDP use MD5 Signature
Date: Tue, 28 Aug 2001 10:46:56 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C12FAE.C1E96D00"
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

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C12FAE.C1E96D00
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGVsbG8sDQpJIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgIkxEUCBVc2Ugb2YgVENQIE1ENSBT
aWduYXR1cmUgT3B0aW9uIiBpbiBSRkMzMDM2IDIuOS4yOg0KMSkgV2hhdCBjb250ZW50cyBhcmUg
dXNlZCB0byBwcm9kdWNlIE1ENSBkaWdlc3Q/DQoyKSBXaGljaCBwb3NpdGlvbiBkb2VzIHRoZSBN
RDUgZGlnZXN0IGFwcGVhciBpbiBUQ1AgcGFja2V0Pw0KDQpSZWdhcmRzLA0KUGF1bCBaaGVuZw0K

------=_NextPart_000_001F_01C12FAE.C1E96D00
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41
MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhlbGxvLDxCUj48Rk9OVCBzaXplPTI+SSBoYXZl
IHNvbWUgcXVlc3Rpb25zIGFib3V0IDxGT05UIHNpemU9Mj4iTERQIFVzZSBvZiANClRDUCBNRDUg
U2lnbmF0dXJlIE9wdGlvbiImbmJzcDtpbiBSRkMzMDM2IDwvRk9OVD4yLjkuMjo8L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIHNpemU9Mj4xKSBXaGF0IGNvbnRlbnRzIGFyZSB1c2VkIHRvIHByb2R1
Y2UgPC9GT05UPjxGT05UIHNpemU9Mj5NRDUgDQpkaWdlc3Q/PC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+MikgV2hpY2ggcG9zaXRpb24mbmJzcDtkb2VzIHRoZSA8L0ZPTlQ+PEZPTlQg
c2l6ZT0zPk1ENSBkaWdlc3QgDQphcHBlYXIgaW4gVENQIHBhY2tldD88L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5S
ZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlBhdWwgWmhlbmc8L0ZPTlQ+
PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_001F_01C12FAE.C1E96D00--



From owner-mpls@UU.NET  Mon Aug 27 23:00:08 2001
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 XAA09286
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 23:00:07 -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 QQldyg20044;
	Mon, 27 Aug 2001 22:32:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldyg06653
	for mpls-outgoing; Mon, 27 Aug 2001 22:32:28 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 QQldyg06643
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 27 Aug 2001 22:32: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 QQldyg21109
	for <mpls@UU.NET>; Mon, 27 Aug 2001 22:31:56 GMT
Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radiant.calient.net [63.102.55.206])
	id QQldyg18474
	for <mpls@UU.NET>; Mon, 27 Aug 2001 22:31:58 GMT
Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RJNZ7MV4>; Mon, 27 Aug 2001 15:31:55 -0700
Message-ID: <A1AFE5CF886C5D439494D9D5DE84EEF373728E@radiant.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Guangzhi Li'" <gli@research.att.com>, Fong Liaw <fliaw@zaffire.com>
Cc: ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Mon, 27 Aug 2001 15:31:49 -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

Guangzhi,

In Fong's note she indicated that the contention can be completely resolved
by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
node 1 is told the result of node 2's decision making process.

Thanks,

John

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Monday, August 27, 2001 2:13 PM
To: Fong Liaw
Cc: ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


Fong:

Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both
uni-directional and bi-directional together and uses the same port pool,
then a PATH and a RESV may cross each other. I think that it should be legal
based on current GMPLS specification. IF this scenario happens, GMPLS has to
provide one standard way to handle this situation.

Your suggestion works but it still involves the implementations of node 1
and node 2. Both nodes should interperate the same way. That means RESV
message always wins PATH message. No problem.

I assume that the I/O ports of bi-didrectional LSP are paired together, then
suggested_label = upstream_label and suggested_label is hard binding. Note
that contention happens in either this case or lack of resource. If
suggested_label could be different upstream_label, no contention problem at
all.

-- Guangzhi

Fong Liaw wrote:

> Guangzhi
>
> The GMPLS contention resolution applies to the scenario
> that two Path messages cross each other.  Your example
> have Resv and Path cross each other so the rule in the
> contention resolution does not directly apply and is more
> of a policy and implementation issue.
>
> Here is one possible solution and is within the
> interpretation of the draft, IMHO. here it is.
> If node 2 already sends Resv to node 1, LSP A should
> be considered established and therefore LSP B should
> be rejected by node 2. If node 2 hasn't sent back Resv,
> LSP A is still in establishing mode and node 2 can resolve
> the contention internally by rejecting LSP A or LSP B, based
> on their setting up priority or it can change LSP A's
> label and reprogram the cross-connect without ever noticed
> by any external node.  In both cases, node 2 is the one
> that resolve this contention.  Hope this helps.
>
> p.s. I think you meant to use LABEL_SET since
> Suggested label is a suggestion, not a hard binding.
>
> Regards
> -Fong
>
> >  -----Original Message-----
> >  From: Guangzhi Li [mailto:gli@research.att.com]
> >  Sent: Monday, August 27, 2001 6:17 AM
> >  To: ccamp@ops.ietf.org; mpls@UU.NET
> >  Cc: gli@research.att.com
> >  Subject: Question on GMPLS contentions resolution
> >
> >
> >  Dear GMPLS authors and all experts:
> >
> >  During GMPLS last call, I posted the same question on the
> >  mailing list
> >  without response. Please somebody spend a little time and
> >  check with the
> >  following example? Something seems not clear when the current GMPLS
> >  contention resution schemes are applied on a framework with both
> >  bi-directional and uni-directional LSPs. Your clarification
> >  is very much
> >  appreciated.
> >
> >  Sincerely,
> >
> >  Guangzhi
> >
> >  -------------------------------------------------------------
> >  -------------------------------------
> >
> >  The issue arises because contention is resolved between
> >  bi-directional
> >  LSPs by the node with the higher node index while for uni-directional
> >  LSPs, contention is resolved by the downstream node. Consider the
> >  following example of two nodes with paired, bi-directional interfaces
> >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> >  node 2 with ID = 50.  Node 1 uses label 1 for the
> >  transmitter port and
> >  label 2 for the receiver port; node 2 uses label 4 for the
> >  transmitter
> >  port and label 3 for the receiver port.   We assume that a
> >  bi-directional LSP requires a single I/O interface.
> >
> >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> >  to node 2,
> >  with the uni-directional LSP setup request arriving marginally before
> >  the bi-directional LSP.  LSP A does not use a suggested
> >  label, and thus
> >  is assigned a label (port) by node 2.  Label 3 is assigned,
> >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> >  Because node 1 has the higher node ID, node 2 will assume (due to the
> >  contention resolution rule for bi-directional LSPs) that LSP
> >  B wins the
> >  contention and thus label 3 is assigned to LSP B.  Thus
> >  label 1 at node
> >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> >  LSPs have "won" the contention.
> >
> >


From owner-mpls@UU.NET  Mon Aug 27 23:12:12 2001
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 XAA09381
	for <mpls-archive@lists.ietf.org>; Mon, 27 Aug 2001 23:12:12 -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 QQldyy25847;
	Tue, 28 Aug 2001 03:13:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldyy28564
	for mpls-outgoing; Tue, 28 Aug 2001 03:12:49 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 QQldyy28459
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 03:12:38 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 QQldyy17915
	for <mpls@uu.net>; Tue, 28 Aug 2001 03:12:33 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQldyy24629
	for <mpls@uu.net>; Tue, 28 Aug 2001 03:12:35 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA14599 for mpls@uu.net; Mon, 27 Aug 2001 23:12:32 -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 QQldyy28422
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 03:12: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 QQldyy23027
	for <mpls@UU.NET>; Tue, 28 Aug 2001 03:11:24 GMT
Received: from che-cse-104.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: che-cse-104.cisco.com [161.44.140.37])
	id QQldyy11498
	for <mpls@UU.NET>; Tue, 28 Aug 2001 03:11:26 GMT
Received: (from eosborne@localhost) by che-cse-104.cisco.com (8.10.2+Sun/CA/950118) id f7S3BDu02000; Mon, 27 Aug 2001 23:11:13 -0400 (EDT)
Date: Mon, 27 Aug 2001 23:11:13 -0400
From: Eric Osborne <eosborne@cisco.com>
To: Sham Chakravorty <sc12@erols.com>
Cc: Loa Andersson <loa.andersson@utfors.se>, mpls@UU.NET
Subject: Re: QoSRe: Here we go again (Re: RSVP Hello)
Message-ID: <20010827231113.G28194@che-cse-104.cisco.com>
References: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com> <3B8A56C2.134BA1C9@utfors.se> <3B8A2149.7EBED033@erols.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <3B8A2149.7EBED033@erols.com>; from sc12@erols.com on Mon, Aug 27, 2001 at 03:30:33AM -0700
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Aug 27, 2001 at 03:30:33AM -0700, Sham Chakravorty wrote:
> See comments inline -
> 

I'm probably just fanning the flames of a religious war, but what the
hell...


> > I'll try to be even more to the point - the first and foremost requirement
> > is simplicity. If MPLS is not simple, there will be no MPLS!
> 
> In IMHO, MPLS is not simple.  Consider all the drafts that have been
> fielded for the past four years - over 120 (?) or so to solve its
> many issues - not withstanding mixed VC setup criteria of RSVP-TE
> and CR-LDP for a starter.

Sure, but consider also the number of large MPLS deployments.  One
would never add an additional control plane or two to a network if
there were no benefit to be gained from it; it seems obvious that at
least some people have decided the potential benefits of MPLS are
worth whatever hassle it brings.  

> MPLS unfortunately does not meet the simplicity criterion. (You may have
> prophesized something here in line with what is coming out in the press more
> and more.  See Lightreading.com's recent article: "Poll: Is MPLS BS?"
> Majority taking the poll seem have to said, yes. One would have been hung in
> the broad day light to put out an article with such a title just a year
> ago.)

Can you enumerate these 'simplicity criterion'?  And as you do so, try
to come up with rules that demonstrate that MPLS is not simple but
BGP, OSPF, IS-IS, IP, ATM, and/or SONET are.

And not that I want to start trashing prestigious on-line industry
trade rags, but lightreading strikes me as the Daily Star of the
Internet news industry.  But I suppose I'm biased; I work for Big
Brother...:)

> 
> > The second requirement is usefulness, if MPLS is not useful, there will be
> > no MPLS (even though it is simple).
> 
> With no built-in framework for QoS deployment and no extensibility to
> enterprise networks (over Ethernets, e.g.), its usefulness as many have
> pointed out before, on this board and elsewhere, is at best very limited.

I guess I don't understand the point about QoS.  Pretty much every
vendor I've ever dealt with treats the EXP bits as Precedence bits.
So there's no inherent *additional* QoS framework in MPLS, but it can
certainly be deployed in much the same way as IP QoS can.  And I
suspect that if MPLS had a built-in QoS framework, then the pundits
would use this to claim that MPLS was not simple.  However, ongoing
work (DS-TE and L-LSP) will give more granular control over QoS than
IP has, albeit at a price of complication.

As far as extensibility to enterprise networks, are you talking about
the various forms of L2 over MPLS?  It seems to me that these things
very much exist; we are shipping two different transport types, and at 
least 3 other vendors that I know of have some flavor of L2 over
MPLS.  And depending on how you define extensability, there's always
2547 and its ability to merge with the enterprise IGP at a L3 level.

'simple' != 'effortless'.  Nothing in networking is effortless.  A
better way to look at it, IMHO, is whether the tradeoff in deploying
MPLS to do whatever services you want (L2 transport, L3 VPNs, TE,
BGP-free core, whatever) is worth the work of an extra few control
planes, a new set of operational things to learn, and so forth.  if
it's worth it, use MPLS; if it's not, don't.



eric



From owner-mpls@UU.NET  Tue Aug 28 00:06:21 2001
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 AAA10384
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 00:06:21 -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 QQldzc09103;
	Tue, 28 Aug 2001 04:07:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldzc19912
	for mpls-outgoing; Tue, 28 Aug 2001 04:06: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 QQldzc19893
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 04:06: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 QQldzc10446
	for <mpls@uu.net>; Tue, 28 Aug 2001 04:06:04 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQldzc16618
	for <mpls@uu.net>; Tue, 28 Aug 2001 04:06:05 GMT
Received: from juniper.net ([172.16.167.238])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7S462062776;
	Mon, 27 Aug 2001 21:06:02 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3B8B18BA.5020201@juniper.net>
Date: Mon, 27 Aug 2001 21:06:18 -0700
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us, zh
MIME-Version: 1.0
To: Sham Chakravorty <sc12@erols.com>
CC: mpls@UU.NET
Subject: Re: QoSRe: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com> <3B8A56C2.134BA1C9@utfors.se> <3B8A2149.7EBED033@erols.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

Sham Chakravorty wrote:


> 
> In IMHO, MPLS is not simple.  Consider all the drafts that have been fielded
> for the past four years - over 120 (?) or so to solve its many issues - not
> withstanding mixed VC setup criteria of RSVP-TE and CR-LDP for a starter.


Would you please elaborate the relationship between simplicity and the 
number of drafts? Do you imply that the number of draft is more 
important than what's actually been implemented?


> MPLS unfortunately does not meet the simplicity criterion. (You may have
> prophesized something here in line with what is coming out in the press more
> and more.  See Lightreading.com's recent article: "Poll: Is MPLS BS?"
> Majority taking the poll seem have to said, yes. 


Sure. Let's have more chat room talks. I am sure this must be some 
in-depth technical conversation.





From owner-mpls@UU.NET  Tue Aug 28 03:30:00 2001
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 DAA28812
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 03:30:00 -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 QQldzq15427;
	Tue, 28 Aug 2001 07:30:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldzq00061
	for mpls-outgoing; Tue, 28 Aug 2001 07:30: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 QQldzq00056
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 07:30:02 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 QQldzp01015
	for <mpls@UU.NET>; Tue, 28 Aug 2001 07:29:56 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQldzp24888
	for <mpls@UU.NET>; Tue, 28 Aug 2001 07:29:55 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <RRR6S896>; Tue, 28 Aug 2001 12:56:44 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D75DCFCC@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: rsvp@ISI.EDU, mpls@UU.NET
Subject: RSVP over ATM
Date: Tue, 28 Aug 2001 12:56:43 +0530
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,

Over ATM, How does RSVP message travel on network, is it as IP packet broken
down in cells or as RSVP message itself broken down in cells.?

Is it required to use AAL5 sockets to send/receive RSVP  message?

Khuzema.
------------------------------------------------
Net Brahma Technologies Private Limited
Internext Networking Software
A Microland Group Company
777, 3rd 'a' cross, 18th Main 
Koramangala VI th block
Bangalore-95
Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
Fax no        - (080) 5537233 
email : khuzemap@netbrahma.com
www.netbrahma.com



From owner-mpls@UU.NET  Tue Aug 28 05:22:53 2001
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 FAA00366
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 05:22:53 -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 QQldzx13142;
	Tue, 28 Aug 2001 09:24:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQldzx14967
	for mpls-outgoing; Tue, 28 Aug 2001 09:23: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 QQldzx14962
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 09:23:33 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 QQldzx23746
	for <mpls@UU.NET>; Tue, 28 Aug 2001 09:23:10 GMT
Received: from tomp.smb.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tomp.smb.utfors.se [195.58.112.6])
	id QQldzx11080
	for <mpls@UU.NET>; Tue, 28 Aug 2001 09:23:10 GMT
Received: from utfors.se ([10.58.0.94]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GIRU7K00.E7F;
          Tue, 28 Aug 2001 11:26:08 +0200 
Message-ID: <3B8B62FB.47E319E4@utfors.se>
Date: Tue, 28 Aug 2001 11:23:07 +0200
From: Loa Andersson <loa.andersson@utfors.se>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Osborne <eosborne@cisco.com>
CC: Sham Chakravorty <sc12@erols.com>, mpls@UU.NET
Subject: Re: QoSRe: Here we go again (Re: RSVP Hello)
References: <3549C09B853DD5119B540002A52CDD3432DC34@zcard0ka.ca.nortel.com> <3B8A56C2.134BA1C9@utfors.se> <3B8A2149.7EBED033@erols.com> <20010827231113.G28194@che-cse-104.cisco.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

All,

promissed not to add to the noise un-necessarily, but since this is
one of those wonderfully unstructured threads where you can say 
anything and get flogged whether it is sensible or not.

I can't resist:

There seems to be at least four different views voiced on this 
thread.

1. "MPLS is níce and dandy, nothing needs to be done, just because it
   is not an ATN replcement"
2. "MPLS is níce and dandy, nothing needs to be done, just because it
   is not an ATN replcement"
3. MPLS is not nice and dandy, because it is ATM all over again.
4. MPLS is nice and dny, but there is a need to review what we ccome up
   with so far, we don't want to make the same misstakes all over again.

Understanding that there are an enormous potential make this far more 
granular, but won't just now.

I think that while recognizing that MPLS is useful and simple at the
core,
there is still a need to go back and asked ourselves if everything that 
has been added is needed.

/Loa


Eric Osborne wrote:
> 
> On Mon, Aug 27, 2001 at 03:30:33AM -0700, Sham Chakravorty wrote:
> > See comments inline -
> >
> 
> I'm probably just fanning the flames of a religious war, but what the
> hell...
> 
> > > I'll try to be even more to the point - the first and foremost requirement
> > > is simplicity. If MPLS is not simple, there will be no MPLS!
> >
> > In IMHO, MPLS is not simple.  Consider all the drafts that have been
> > fielded for the past four years - over 120 (?) or so to solve its
> > many issues - not withstanding mixed VC setup criteria of RSVP-TE
> > and CR-LDP for a starter.
> 
> Sure, but consider also the number of large MPLS deployments.  One
> would never add an additional control plane or two to a network if
> there were no benefit to be gained from it; it seems obvious that at
> least some people have decided the potential benefits of MPLS are
> worth whatever hassle it brings.
> 
> > MPLS unfortunately does not meet the simplicity criterion. (You may have
> > prophesized something here in line with what is coming out in the press more
> > and more.  See Lightreading.com's recent article: "Poll: Is MPLS BS?"
> > Majority taking the poll seem have to said, yes. One would have been hung in
> > the broad day light to put out an article with such a title just a year
> > ago.)
> 
> Can you enumerate these 'simplicity criterion'?  And as you do so, try
> to come up with rules that demonstrate that MPLS is not simple but
> BGP, OSPF, IS-IS, IP, ATM, and/or SONET are.
> 
> And not that I want to start trashing prestigious on-line industry
> trade rags, but lightreading strikes me as the Daily Star of the
> Internet news industry.  But I suppose I'm biased; I work for Big
> Brother...:)
> 
> >
> > > The second requirement is usefulness, if MPLS is not useful, there will be
> > > no MPLS (even though it is simple).
> >
> > With no built-in framework for QoS deployment and no extensibility to
> > enterprise networks (over Ethernets, e.g.), its usefulness as many have
> > pointed out before, on this board and elsewhere, is at best very limited.
> 
> I guess I don't understand the point about QoS.  Pretty much every
> vendor I've ever dealt with treats the EXP bits as Precedence bits.
> So there's no inherent *additional* QoS framework in MPLS, but it can
> certainly be deployed in much the same way as IP QoS can.  And I
> suspect that if MPLS had a built-in QoS framework, then the pundits
> would use this to claim that MPLS was not simple.  However, ongoing
> work (DS-TE and L-LSP) will give more granular control over QoS than
> IP has, albeit at a price of complication.
> 
> As far as extensibility to enterprise networks, are you talking about
> the various forms of L2 over MPLS?  It seems to me that these things
> very much exist; we are shipping two different transport types, and at
> least 3 other vendors that I know of have some flavor of L2 over
> MPLS.  And depending on how you define extensability, there's always
> 2547 and its ability to merge with the enterprise IGP at a L3 level.
> 
> 'simple' != 'effortless'.  Nothing in networking is effortless.  A
> better way to look at it, IMHO, is whether the tradeoff in deploying
> MPLS to do whatever services you want (L2 transport, L3 VPNs, TE,
> BGP-free core, whatever) is worth the work of an extra few control
> planes, a new set of operational things to learn, and so forth.  if
> it's worth it, use MPLS; if it's not, don't.
> 
> eric

-- 
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  Tue Aug 28 06:56:07 2001
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 GAA02237
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 06:56:07 -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 QQlead16092;
	Tue, 28 Aug 2001 10:57:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlead09774
	for mpls-outgoing; Tue, 28 Aug 2001 10:56: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 QQlead09769
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 10:56:55 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 QQlead21241
	for <mpls@uu.net>; Tue, 28 Aug 2001 10:56:40 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlead15025
	for <mpls@uu.net>; Tue, 28 Aug 2001 10:56:38 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA04882 for mpls@uu.net; Tue, 28 Aug 2001 06:56:38 -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 QQlead09749
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 10:56:24 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 QQlead19037
	for <mpls@UU.NET>; Tue, 28 Aug 2001 10:54:35 GMT
Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlead11849
	for <mpls@UU.NET>; Tue, 28 Aug 2001 10:54:37 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7SAscl13383;
	Tue, 28 Aug 2001 03:54:38 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id GAA23466; Tue, 28 Aug 2001 06:54:25 -0400 (EDT)
Message-Id: <200108281054.GAA23466@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: "Paul Zheng" <zhengdaoqing@huawei.com>
cc: mpls@UU.NET
Subject: Re: Question about LDP use MD5 Signature 
In-reply-to: Your message of "Tue, 28 Aug 2001 10:46:56 +0800."
             <002201c12f6b$b41a1960$70040101@huawei.com> 
Date: Tue, 28 Aug 2001 06:54:25 -0400
From: Bob Thomas <rhthomas@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Paul,

> I have some questions about "LDP Use of TCP MD5 Signature Option" in
> RFC3036 2.9.2:
> 1) What contents are used to produce MD5 digest?
> 2) Which position does the MD5 digest appear in TCP packet?

These questions are addressed by RFC2385, TCP MD5 Signature Option.

Bob


> Regards,
> Paul Zheng



From owner-mpls@UU.NET  Tue Aug 28 07:26:10 2001
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 HAA03868
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 07:26:10 -0400 (EDT)
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 QQleaf15571;
	Tue, 28 Aug 2001 11:27:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleaf00481
	for mpls-outgoing; Tue, 28 Aug 2001 11:26:53 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 QQleaf00471
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 11:26: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 QQleaf21167
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:26:33 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQleaf13261
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:26:32 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA06730 for mpls@uu.net; Tue, 28 Aug 2001 07:26:32 -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 QQleaf00401
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 11:26:17 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 QQleaf01270
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:25:40 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 QQleaf21321
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:25:42 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03735;
	Tue, 28 Aug 2001 07:24:19 -0400 (EDT)
Message-Id: <200108281124.HAA03735@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
CC: mpls@UU.NET, te-wg@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ash-mpls-diffserv-te-alternative-02.txt
Date: Tue, 28 Aug 2001 07:24:19 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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


	Title		: Alternative Technical Solution for MPLS DiffServ TE
	Author(s)	: J. Ash, L. Fang, W. Lai
	Filename	: draft-ash-mpls-diffserv-te-alternative-02.txt
	Pages		: 10
	Date		: 27-Aug-01
	
Service Provider requirements for support of DiffServ-aware MPLS
Traffic Engineering (DS-TE) are presented in [DS-TE-REQ].  [DS-TE-
SOLN] describes a proposed technical solution for meeting the DS-TE
requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-alternative-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ash-mpls-diffserv-te-alternative-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-ash-mpls-diffserv-te-alternative-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:	<20010827123042.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ash-mpls-diffserv-te-alternative-02.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Aug 28 07:26:22 2001
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 HAA03898
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 07:26:22 -0400 (EDT)
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 QQleaf16123;
	Tue, 28 Aug 2001 11:27:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleaf00496
	for mpls-outgoing; Tue, 28 Aug 2001 11:27: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 QQleaf00491
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 11:27:03 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 QQleaf19169
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:27:00 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQleaf13961
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:26:59 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA06764 for mpls@uu.net; Tue, 28 Aug 2001 07:26:59 -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 QQleaf00466
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 11:26: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 QQleaf17772
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:25:25 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 QQleaf21044
	for <mpls@uu.net>; Tue, 28 Aug 2001 11:25:26 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03640;
	Tue, 28 Aug 2001 07:23:55 -0400 (EDT)
Message-Id: <200108281123.HAA03640@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-mib-07.txt
Date: Tue, 28 Aug 2001 07:23:54 -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) Traffic 
                          Engineering Management Information Base 
	Author(s)	: C. Srinivasan, A. Viswanathan, T. Nadeau
	Filename	: draft-ietf-mpls-te-mib-07.txt
	Pages		: 65
	Date		: 27-Aug-01
	
This memo defines an experimental portion of the Management
Information Base  (MIB) for use with network management
protocols in the Internet community.  In particular, it
describes managed objects for Multi-Protocol Label
Switching (MPLS) [MPLSArch] based traffic engineering.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-te-mib-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-te-mib-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--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:	<20010827115935.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-te-mib-07.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Aug 28 08:22:52 2001
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 IAA06826
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 08:22:52 -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 QQleaj16051;
	Tue, 28 Aug 2001 12:24:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleaj22883
	for mpls-outgoing; Tue, 28 Aug 2001 12:23: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 QQleaj22878
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 12:23: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 QQleaj01318
	for <mpls@uu.net>; Tue, 28 Aug 2001 12:22:05 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQleaj16076
	for <mpls@uu.net>; Tue, 28 Aug 2001 12:22:07 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA10428 for mpls@uu.net; Tue, 28 Aug 2001 08:22:03 -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 QQleaj22796
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 12:21:43 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 QQleaj07626
	for <mpls@uu.net>; Tue, 28 Aug 2001 12:21:25 GMT
Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQleaj03030
	for <mpls@uu.net>; Tue, 28 Aug 2001 12:21:23 GMT
Received: from cbin3-mira-01.cisco.com (cbin3-mira-01.cisco.com [64.104.129.145])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7SCLXN27811
	for <mpls@uu.net>; Tue, 28 Aug 2001 05:21:33 -0700 (PDT)
Received: from cisco.com ([64.104.137.237])
	by cbin3-mira-01.cisco.com (Mirapoint)
	with ESMTP id AAM04711 (AUTH manojkgb);
	Tue, 28 Aug 2001 17:51:17 +0530 (IST)
Message-ID: <3B8B8C01.FED353AD@cisco.com>
Date: Tue, 28 Aug 2001 17:48:09 +0530
From: manoj garg <manojkgb@cisco.com>
Organization: cisco
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: subscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

subscribe



From owner-mpls@UU.NET  Tue Aug 28 09:29:37 2001
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 JAA09828
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 09:29: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 QQleao06954;
	Tue, 28 Aug 2001 13:30:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleao16257
	for mpls-outgoing; Tue, 28 Aug 2001 13:30: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 QQleao16244
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 13:30:15 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 QQleao14855
	for <mpls@UU.NET>; Tue, 28 Aug 2001 13:30:00 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 QQleao15673
	for <mpls@UU.NET>; Tue, 28 Aug 2001 13:30:02 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 JAA06707;
	Tue, 28 Aug 2001 09:29:54 -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 JAA13991;
	Tue, 28 Aug 2001 09:29:53 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <RD72DGM6>; Tue, 28 Aug 2001 09:29:53 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C761@VIE-MSGUSR-01>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Khuzema Pithewan'" <KhuzemaP@netbrahma.com>, rsvp@ISI.EDU, mpls@UU.NET
Subject: RE: RSVP over ATM
Date: Tue, 28 Aug 2001 09:29:51 -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

Khuzema:

   Look at my inline comments...

-> Over ATM, How does RSVP message travel on network, is it as 
-> IP packet broken
-> down in cells or as RSVP message itself broken down in cells.?

   RSVP over IP over AAL5 over ATM! (forget about some 
   proprietary implementations). If you don't encapsulate
   your RSVP messages on IP, how will the messages processed?
 
-> Is it required to use AAL5 sockets to send/receive RSVP  message?

   IP control (all defined MPLS protocols) and data (applications)
   will go as IP over AAL5 over ATM (if at all ATM is used as L2)
   except in some scenarios, where IP control protocols are used 
   over AAL5 and data flow will be on AAL2 over ATM (voice/video
   applications). Look more for "Voice over IP over MPLS" and 
   "Voice over MPLS"...

--Venkata Naidu


From owner-mpls@UU.NET  Tue Aug 28 09:46:40 2001
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 JAA10189
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 09:46:39 -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 QQleap16313;
	Tue, 28 Aug 2001 13:47:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleap17081
	for mpls-outgoing; Tue, 28 Aug 2001 13:47:21 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 QQleap17076
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 13:47: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 QQleap22896
	for <mpls@UU.NET>; Tue, 28 Aug 2001 13:46:14 GMT
Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQleap27276
	for <mpls@UU.NET>; Tue, 28 Aug 2001 13:46:16 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id C7A404CE2E; Tue, 28 Aug 2001 09:46:05 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA04025;
	Tue, 28 Aug 2001 09:46:05 -0400 (EDT)
Message-ID: <3B8BA205.7E1CDB3E@research.att.com>
Date: Tue, 28 Aug 2001 09:52:05 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Drake <jdrake@calient.net>
Cc: Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <A1AFE5CF886C5D439494D9D5DE84EEF373728E@radiant.chromisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

John:

No. Node 1 may send out the PATH message to node 2 as the same time as node 2
sends out the RESV message to node 1. If the contention resolution is a local
decision or policy implementation, node 1 may decide to fail LSP A since node 1
has the higher node ID. Then both LSP A and LSP B are failed. This is not what
we want. So, a consistent decision is required between these two nodes.

Thanks,

-- Guangzhi

John Drake wrote:

> Guangzhi,
>
> In Fong's note she indicated that the contention can be completely resolved
> by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> node 1 is told the result of node 2's decision making process.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Monday, August 27, 2001 2:13 PM
> To: Fong Liaw
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> Fong:
>
> Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs both
> uni-directional and bi-directional together and uses the same port pool,
> then a PATH and a RESV may cross each other. I think that it should be legal
> based on current GMPLS specification. IF this scenario happens, GMPLS has to
> provide one standard way to handle this situation.
>
> Your suggestion works but it still involves the implementations of node 1
> and node 2. Both nodes should interperate the same way. That means RESV
> message always wins PATH message. No problem.
>
> I assume that the I/O ports of bi-didrectional LSP are paired together, then
> suggested_label = upstream_label and suggested_label is hard binding. Note
> that contention happens in either this case or lack of resource. If
> suggested_label could be different upstream_label, no contention problem at
> all.
>
> -- Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > The GMPLS contention resolution applies to the scenario
> > that two Path messages cross each other.  Your example
> > have Resv and Path cross each other so the rule in the
> > contention resolution does not directly apply and is more
> > of a policy and implementation issue.
> >
> > Here is one possible solution and is within the
> > interpretation of the draft, IMHO. here it is.
> > If node 2 already sends Resv to node 1, LSP A should
> > be considered established and therefore LSP B should
> > be rejected by node 2. If node 2 hasn't sent back Resv,
> > LSP A is still in establishing mode and node 2 can resolve
> > the contention internally by rejecting LSP A or LSP B, based
> > on their setting up priority or it can change LSP A's
> > label and reprogram the cross-connect without ever noticed
> > by any external node.  In both cases, node 2 is the one
> > that resolve this contention.  Hope this helps.
> >
> > p.s. I think you meant to use LABEL_SET since
> > Suggested label is a suggestion, not a hard binding.
> >
> > Regards
> > -Fong
> >
> > >  -----Original Message-----
> > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > >  Sent: Monday, August 27, 2001 6:17 AM
> > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > >  Cc: gli@research.att.com
> > >  Subject: Question on GMPLS contentions resolution
> > >
> > >
> > >  Dear GMPLS authors and all experts:
> > >
> > >  During GMPLS last call, I posted the same question on the
> > >  mailing list
> > >  without response. Please somebody spend a little time and
> > >  check with the
> > >  following example? Something seems not clear when the current GMPLS
> > >  contention resution schemes are applied on a framework with both
> > >  bi-directional and uni-directional LSPs. Your clarification
> > >  is very much
> > >  appreciated.
> > >
> > >  Sincerely,
> > >
> > >  Guangzhi
> > >
> > >  -------------------------------------------------------------
> > >  -------------------------------------
> > >
> > >  The issue arises because contention is resolved between
> > >  bi-directional
> > >  LSPs by the node with the higher node index while for uni-directional
> > >  LSPs, contention is resolved by the downstream node. Consider the
> > >  following example of two nodes with paired, bi-directional interfaces
> > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > >  transmitter port and
> > >  label 2 for the receiver port; node 2 uses label 4 for the
> > >  transmitter
> > >  port and label 3 for the receiver port.   We assume that a
> > >  bi-directional LSP requires a single I/O interface.
> > >
> > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > >  to node 2,
> > >  with the uni-directional LSP setup request arriving marginally before
> > >  the bi-directional LSP.  LSP A does not use a suggested
> > >  label, and thus
> > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > >  contention resolution rule for bi-directional LSPs) that LSP
> > >  B wins the
> > >  contention and thus label 3 is assigned to LSP B.  Thus
> > >  label 1 at node
> > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > >  LSPs have "won" the contention.
> > >
> > >



From owner-mpls@UU.NET  Tue Aug 28 11:09:12 2001
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 LAA12573
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 11:09:11 -0400 (EDT)
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 QQleau29867;
	Tue, 28 Aug 2001 15:10:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleau29899
	for mpls-outgoing; Tue, 28 Aug 2001 15:09: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 QQleau29801
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 15:09:52 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 QQleau29891
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:08:30 GMT
Received: from bridge.axiowave.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.axiowave.com [209.6.34.2])
	id QQleau26788
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:08:31 GMT
Message-ID: <EB5FFC72F183D411B38200062957342976A99B@r2d2.axiowave.com>
From: Ling Li <lli@axiowave.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: A question on mpls-te-mib: mplsTunnelHopEntryPathComp 
Date: Tue, 28 Aug 2001 11:08:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I was confused by the description of mplsTunnelHopEntryPathComp as bellow:

mplsTunnelHopEntryPathComp OBJECT-TYPE
SYNTAX INTEGER {
	dynamic(1), -- CSPF computed
	explicit(2) -- strict hop
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this value is set to dynamic, then the user
should only specify the source and destination of
the path and expect that the CSPF will calculate
the remainder of the path. If this value is set to
explicit, the user should specify the entire path
for the tunnel to take. This path may contain
strict or loose hops. Each hop along a specific
path should have this object set to the same value"
::= { mplsTunnelHopEntry 14 }


My question is: what if a user want to use CSPF to find a route from Boston
to San Francisco, but specifically he/she wants the route to go through
Chicago.

The description seems suggesting that this operation is not allowed, because
1. The user specified not only the source and destination, but an extra
loose hop (Chicago). Therefore mplsTunnelHopEntryPathComp  cannot be dynamic
2. The user wanted to enable CSPF to calculate the path, so explicit is not
appropriate for mplsTunnelHopEntryPathComp.

Could anyone clarify on this doubt?



Thanks, 

Ling Li 

Axiowave Networks, Inc. 
Email: lli@axiowave.com 
======================== 


From owner-mpls@UU.NET  Tue Aug 28 11:25:28 2001
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 LAA12911
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 11:25:28 -0400 (EDT)
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 QQleav20917;
	Tue, 28 Aug 2001 15:26:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleav02130
	for mpls-outgoing; Tue, 28 Aug 2001 15:26: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 QQleav02106
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 15:25: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 QQleav01240
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:22:41 GMT
Received: from yn-server1.yodanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.253.26.147])
	id QQleav15446
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:22:43 GMT
Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21)
	id <QVB2G6AY>; Tue, 28 Aug 2001 11:18:13 -0400
Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A454@yn-server1.yodanetworks.com>
From: "Kota, Ravikumar" <RKota@cratosnetworks.com>
To: "'Ling Li'" <lli@axiowave.com>, "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: A question on mpls-te-mib: mplsTunnelHopEntryPathComp 
Date: Tue, 28 Aug 2001 11:18:06 -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

Hi Li,
in the draft draft_ietf_mpls_te_mib_07.txt

mplsTunnelHopEntryPathComp OBJECT-TYPE
   SYNTAX        INTEGER {
                      dynamic(1),    -- CSPF computed
                      explicit(2)    -- strict hop
                  }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
"If this value is set to dynamic, then the user
          should only specify the source and destination of
          the path and expect that the CSPF will calculate
          the remainder of the path.  If this value is set to
          explicit, the user should specify the entire path
          for the tunnel to take.  This path may contain
          strict or loose hops.  Each hop along a specific
          path should have this object set to the same value"
   ::= { mplsTunnelHopEntry 14 }


 So if u want to mention other location along with sourse and destination ,
u can not use 
dynamic option . U have to use "explicit" path option with sub option
"loose".
For this the object in the MIB is as follow:(from the same draft )

mplsTunnelHopType OBJECT-TYPE
   SYNTAX        INTEGER {
                      strict(1),
                      loose(2)
                     }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Denotes whether this tunnel hop is routed in a
          strict or loose fashion."
   ::= { mplsTunnelHopEntry 11 }


so with the option "explicit" and "loose" ur LSP will be established.
For the other LSR s which u have not mentioned explicity , i think CSPF will
calculate them based on the TUNNEL resource requirement.( caqn be corrected
if it is wrong ).


Regards
Ravikumar Kota



-----Original Message-----
From: Ling Li [mailto:lli@axiowave.com]
Sent: Tuesday, August 28, 2001 11:08 AM
To: 'mpls@UU.NET'
Subject: A question on mpls-te-mib: mplsTunnelHopEntryPathComp 


I was confused by the description of mplsTunnelHopEntryPathComp as bellow:

mplsTunnelHopEntryPathComp OBJECT-TYPE
SYNTAX INTEGER {
	dynamic(1), -- CSPF computed
	explicit(2) -- strict hop
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If this value is set to dynamic, then the user
should only specify the source and destination of
the path and expect that the CSPF will calculate
the remainder of the path. If this value is set to
explicit, the user should specify the entire path
for the tunnel to take. This path may contain
strict or loose hops. Each hop along a specific
path should have this object set to the same value"
::= { mplsTunnelHopEntry 14 }


My question is: what if a user want to use CSPF to find a route from Boston
to San Francisco, but specifically he/she wants the route to go through
Chicago.

The description seems suggesting that this operation is not allowed, because
1. The user specified not only the source and destination, but an extra
loose hop (Chicago). Therefore mplsTunnelHopEntryPathComp  cannot be dynamic
2. The user wanted to enable CSPF to calculate the path, so explicit is not
appropriate for mplsTunnelHopEntryPathComp.

Could anyone clarify on this doubt?



Thanks, 

Ling Li 

Axiowave Networks, Inc. 
Email: lli@axiowave.com 
======================== 


From owner-mpls@UU.NET  Tue Aug 28 11:30:27 2001
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 LAA13108
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 11:30:22 -0400 (EDT)
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 QQleaw27875;
	Tue, 28 Aug 2001 15:31:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleaw02526
	for mpls-outgoing; Tue, 28 Aug 2001 15:31: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 QQleaw02502
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 15:30:59 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 QQleaw06422
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:30:10 GMT
Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQleaw04685
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:30:12 GMT
Received: from mail1.tellium.com (mail1 [151.198.92.140])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f7SFRE905954;
	Tue, 28 Aug 2001 11:27:14 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <RTXTAD9X>; Tue, 28 Aug 2001 11:30:01 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D02204040208894F@mail1.tellium.com>
From: Hang Liu <hliu@tellium.com>
To: "'Guangzhi Li'" <gli@research.att.com>, John Drake <jdrake@calient.net>
Cc: Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Tue, 28 Aug 2001 11:29:59 -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

Guangzhi,

For this case, if Node 1 always maps the label in the RESV message and
creates RSB. LSP A will be set up. The suggested label in the PATH message
from Node 1 is only preference. LSP B will be rejected by Node 2.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 9:52 AM
To: John Drake
Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


John:

No. Node 1 may send out the PATH message to node 2 as the same time as node
2
sends out the RESV message to node 1. If the contention resolution is a
local
decision or policy implementation, node 1 may decide to fail LSP A since
node 1
has the higher node ID. Then both LSP A and LSP B are failed. This is not
what
we want. So, a consistent decision is required between these two nodes.

Thanks,

-- Guangzhi

John Drake wrote:

> Guangzhi,
>
> In Fong's note she indicated that the contention can be completely
resolved
> by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> node 1 is told the result of node 2's decision making process.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Monday, August 27, 2001 2:13 PM
> To: Fong Liaw
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> Fong:
>
> Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
both
> uni-directional and bi-directional together and uses the same port pool,
> then a PATH and a RESV may cross each other. I think that it should be
legal
> based on current GMPLS specification. IF this scenario happens, GMPLS has
to
> provide one standard way to handle this situation.
>
> Your suggestion works but it still involves the implementations of node 1
> and node 2. Both nodes should interperate the same way. That means RESV
> message always wins PATH message. No problem.
>
> I assume that the I/O ports of bi-didrectional LSP are paired together,
then
> suggested_label = upstream_label and suggested_label is hard binding. Note
> that contention happens in either this case or lack of resource. If
> suggested_label could be different upstream_label, no contention problem
at
> all.
>
> -- Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > The GMPLS contention resolution applies to the scenario
> > that two Path messages cross each other.  Your example
> > have Resv and Path cross each other so the rule in the
> > contention resolution does not directly apply and is more
> > of a policy and implementation issue.
> >
> > Here is one possible solution and is within the
> > interpretation of the draft, IMHO. here it is.
> > If node 2 already sends Resv to node 1, LSP A should
> > be considered established and therefore LSP B should
> > be rejected by node 2. If node 2 hasn't sent back Resv,
> > LSP A is still in establishing mode and node 2 can resolve
> > the contention internally by rejecting LSP A or LSP B, based
> > on their setting up priority or it can change LSP A's
> > label and reprogram the cross-connect without ever noticed
> > by any external node.  In both cases, node 2 is the one
> > that resolve this contention.  Hope this helps.
> >
> > p.s. I think you meant to use LABEL_SET since
> > Suggested label is a suggestion, not a hard binding.
> >
> > Regards
> > -Fong
> >
> > >  -----Original Message-----
> > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > >  Sent: Monday, August 27, 2001 6:17 AM
> > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > >  Cc: gli@research.att.com
> > >  Subject: Question on GMPLS contentions resolution
> > >
> > >
> > >  Dear GMPLS authors and all experts:
> > >
> > >  During GMPLS last call, I posted the same question on the
> > >  mailing list
> > >  without response. Please somebody spend a little time and
> > >  check with the
> > >  following example? Something seems not clear when the current GMPLS
> > >  contention resution schemes are applied on a framework with both
> > >  bi-directional and uni-directional LSPs. Your clarification
> > >  is very much
> > >  appreciated.
> > >
> > >  Sincerely,
> > >
> > >  Guangzhi
> > >
> > >  -------------------------------------------------------------
> > >  -------------------------------------
> > >
> > >  The issue arises because contention is resolved between
> > >  bi-directional
> > >  LSPs by the node with the higher node index while for uni-directional
> > >  LSPs, contention is resolved by the downstream node. Consider the
> > >  following example of two nodes with paired, bi-directional interfaces
> > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > >  transmitter port and
> > >  label 2 for the receiver port; node 2 uses label 4 for the
> > >  transmitter
> > >  port and label 3 for the receiver port.   We assume that a
> > >  bi-directional LSP requires a single I/O interface.
> > >
> > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > >  to node 2,
> > >  with the uni-directional LSP setup request arriving marginally before
> > >  the bi-directional LSP.  LSP A does not use a suggested
> > >  label, and thus
> > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > >  contention resolution rule for bi-directional LSPs) that LSP
> > >  B wins the
> > >  contention and thus label 3 is assigned to LSP B.  Thus
> > >  label 1 at node
> > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > >  LSPs have "won" the contention.
> > >
> > >



From owner-mpls@UU.NET  Tue Aug 28 13:11:33 2001
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 NAA16162
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 13:11:32 -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 QQlebc23675;
	Tue, 28 Aug 2001 17:12:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebc17708
	for mpls-outgoing; Tue, 28 Aug 2001 17:12:17 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 QQlebc17701
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 17:12: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 QQlebc01210
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:11:50 GMT
Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQlebc02542
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:11:52 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 21B1C4CE22; Tue, 28 Aug 2001 13:11:42 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA27064;
	Tue, 28 Aug 2001 13:11:41 -0400 (EDT)
Message-ID: <3B8BD235.88311B40@research.att.com>
Date: Tue, 28 Aug 2001 13:17:41 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hang Liu <hliu@tellium.com>
Cc: John Drake <jdrake@calient.net>, Fong Liaw <fliaw@zaffire.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <0CD7D73C734BD411AEE100B0D02204040208894F@mail1.tellium.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hang:

NO. The PATH message is bi-directional and the RESV is uni-directional. If there
is a contention,  the contention happens with LSP A and the upstream label of
LSP B.

In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve
it, such as Resv wins Path message in all cases, there is no problem. A simply
local decision is NOT enough.

Please draw pictures and apply current GMPLS contention resolution schemes ONLY.
You will see something needs to be fixed.

Guangzhi

Hang Liu wrote:

> Guangzhi,
>
> For this case, if Node 1 always maps the label in the RESV message and
> creates RSB. LSP A will be set up. The suggested label in the PATH message
> from Node 1 is only preference. LSP B will be rejected by Node 2.
>
> Hang
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Tuesday, August 28, 2001 9:52 AM
> To: John Drake
> Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> John:
>
> No. Node 1 may send out the PATH message to node 2 as the same time as node
> 2
> sends out the RESV message to node 1. If the contention resolution is a
> local
> decision or policy implementation, node 1 may decide to fail LSP A since
> node 1
> has the higher node ID. Then both LSP A and LSP B are failed. This is not
> what
> we want. So, a consistent decision is required between these two nodes.
>
> Thanks,
>
> -- Guangzhi
>
> John Drake wrote:
>
> > Guangzhi,
> >
> > In Fong's note she indicated that the contention can be completely
> resolved
> > by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> > node 1 is told the result of node 2's decision making process.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:gli@research.att.com]
> > Sent: Monday, August 27, 2001 2:13 PM
> > To: Fong Liaw
> > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > Fong:
> >
> > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
> both
> > uni-directional and bi-directional together and uses the same port pool,
> > then a PATH and a RESV may cross each other. I think that it should be
> legal
> > based on current GMPLS specification. IF this scenario happens, GMPLS has
> to
> > provide one standard way to handle this situation.
> >
> > Your suggestion works but it still involves the implementations of node 1
> > and node 2. Both nodes should interperate the same way. That means RESV
> > message always wins PATH message. No problem.
> >
> > I assume that the I/O ports of bi-didrectional LSP are paired together,
> then
> > suggested_label = upstream_label and suggested_label is hard binding. Note
> > that contention happens in either this case or lack of resource. If
> > suggested_label could be different upstream_label, no contention problem
> at
> > all.
> >
> > -- Guangzhi
> >
> > Fong Liaw wrote:
> >
> > > Guangzhi
> > >
> > > The GMPLS contention resolution applies to the scenario
> > > that two Path messages cross each other.  Your example
> > > have Resv and Path cross each other so the rule in the
> > > contention resolution does not directly apply and is more
> > > of a policy and implementation issue.
> > >
> > > Here is one possible solution and is within the
> > > interpretation of the draft, IMHO. here it is.
> > > If node 2 already sends Resv to node 1, LSP A should
> > > be considered established and therefore LSP B should
> > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > LSP A is still in establishing mode and node 2 can resolve
> > > the contention internally by rejecting LSP A or LSP B, based
> > > on their setting up priority or it can change LSP A's
> > > label and reprogram the cross-connect without ever noticed
> > > by any external node.  In both cases, node 2 is the one
> > > that resolve this contention.  Hope this helps.
> > >
> > > p.s. I think you meant to use LABEL_SET since
> > > Suggested label is a suggestion, not a hard binding.
> > >
> > > Regards
> > > -Fong
> > >
> > > >  -----Original Message-----
> > > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > > >  Cc: gli@research.att.com
> > > >  Subject: Question on GMPLS contentions resolution
> > > >
> > > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > >  During GMPLS last call, I posted the same question on the
> > > >  mailing list
> > > >  without response. Please somebody spend a little time and
> > > >  check with the
> > > >  following example? Something seems not clear when the current GMPLS
> > > >  contention resution schemes are applied on a framework with both
> > > >  bi-directional and uni-directional LSPs. Your clarification
> > > >  is very much
> > > >  appreciated.
> > > >
> > > >  Sincerely,
> > > >
> > > >  Guangzhi
> > > >
> > > >  -------------------------------------------------------------
> > > >  -------------------------------------
> > > >
> > > >  The issue arises because contention is resolved between
> > > >  bi-directional
> > > >  LSPs by the node with the higher node index while for uni-directional
> > > >  LSPs, contention is resolved by the downstream node. Consider the
> > > >  following example of two nodes with paired, bi-directional interfaces
> > > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > > >  transmitter port and
> > > >  label 2 for the receiver port; node 2 uses label 4 for the
> > > >  transmitter
> > > >  port and label 3 for the receiver port.   We assume that a
> > > >  bi-directional LSP requires a single I/O interface.
> > > >
> > > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > > >  to node 2,
> > > >  with the uni-directional LSP setup request arriving marginally before
> > > >  the bi-directional LSP.  LSP A does not use a suggested
> > > >  label, and thus
> > > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > > >  contention resolution rule for bi-directional LSPs) that LSP
> > > >  B wins the
> > > >  contention and thus label 3 is assigned to LSP B.  Thus
> > > >  label 1 at node
> > > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > > >  LSPs have "won" the contention.
> > > >
> > > >



From owner-mpls@UU.NET  Tue Aug 28 13:20:18 2001
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 NAA16335
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 13:20:17 -0400 (EDT)
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 QQlebd06110;
	Tue, 28 Aug 2001 17:21:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebd18603
	for mpls-outgoing; Tue, 28 Aug 2001 17:21:02 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 QQlebd18576
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 17:20:59 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 QQlebd24066
	for <mpls@uu.net>; Tue, 28 Aug 2001 17:19:55 GMT
Received: from nwmq0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwmq0102a.jc.digitran.com [165.251.28.22])
	id QQlebd12171
	for <mpls@uu.net>; Tue, 28 Aug 2001 17:19:56 GMT
Received: from csrinivasan [12.34.209.74] by nwmq0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Tue, 28 Aug 2001 13:14:47 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Haridass, Govind'" <gharidas@riverstonenet.com>
Cc: <mpls@UU.NET>
Subject: RE: Question in creating entries in ifStackTable...
Date: Tue, 28 Aug 2001 13:32:42 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB132@OPTONT>
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <329F35B18824D511B9C30008C733955828F500@exc-sc1>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Govind Haridass wrote:
>
> > >	"draft-ietf-mpls-lsr-mib-07.txt" says that the MPLS interface
> > >	should be above an "Underlying Layer..."  in the ifStackTable.
> > >
> > >	In our case we can start mpls over an IP interface.  Can the
> > >	"Underlying layer..." be the IP interface ?
> > 
> > Underlying layer is the one that MPLS is running on. What 
> do you mean
> > by "IP interface"?
> > 
> By IP interface I mean the ipForward interface (142).

You can layer the mpls interface over the ipForward layer.
Alternately, you could have layered it directly on top of the
underlying layer, for example ethernet.



From owner-mpls@UU.NET  Tue Aug 28 13:32:21 2001
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 NAA16570
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 13:32:21 -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 QQlebe00399;
	Tue, 28 Aug 2001 17:33:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebe19466
	for mpls-outgoing; Tue, 28 Aug 2001 17:32: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 QQlebe19457
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 17:32:50 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 QQlebe17904
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:32:31 GMT
Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQlebe21286
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:32:33 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 98AFD4CE06; Tue, 28 Aug 2001 13:32:30 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id NAA29599;
	Tue, 28 Aug 2001 13:32:30 -0400 (EDT)
Message-ID: <3B8BD716.1BBCE7D8@research.att.com>
Date: Tue, 28 Aug 2001 13:38:30 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hang Liu <hliu@tellium.com>, John Drake <jdrake@calient.net>,
        Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <0CD7D73C734BD411AEE100B0D02204040208894F@mail1.tellium.com> <3B8BD235.88311B40@research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hang:

I did not make it clear. I assume that the I/O ports of Bi-directional LSP are
paired. After node 1 configured the cross-connect with the upstream label (of course
suggested label) for LSP B,  node 1 received the uni-directional RESV message for
LSP A, is it obviously defined in GMPLS that node 1 should accept LSP A and give up
LSP B or simply is it a local decision/policy implementation?

-- Guangzhi

Guangzhi Li wrote:

> Hang:
>
> NO. The PATH message is bi-directional and the RESV is uni-directional. If there
> is a contention,  the contention happens with LSP A and the upstream label of
> LSP B.
>
> In your suggestion, you used IF. IF GMPLS specifies a consisten way to resolve
> it, such as Resv wins Path message in all cases, there is no problem. A simply
> local decision is NOT enough.
>
> Please draw pictures and apply current GMPLS contention resolution schemes ONLY.
> You will see something needs to be fixed.
>
> Guangzhi
>
> Hang Liu wrote:
>
> > Guangzhi,
> >
> > For this case, if Node 1 always maps the label in the RESV message and
> > creates RSB. LSP A will be set up. The suggested label in the PATH message
> > from Node 1 is only preference. LSP B will be rejected by Node 2.
> >
> > Hang
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:gli@research.att.com]
> > Sent: Tuesday, August 28, 2001 9:52 AM
> > To: John Drake
> > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > John:
> >
> > No. Node 1 may send out the PATH message to node 2 as the same time as node
> > 2
> > sends out the RESV message to node 1. If the contention resolution is a
> > local
> > decision or policy implementation, node 1 may decide to fail LSP A since
> > node 1
> > has the higher node ID. Then both LSP A and LSP B are failed. This is not
> > what
> > we want. So, a consistent decision is required between these two nodes.
> >
> > Thanks,
> >
> > -- Guangzhi
> >
> > John Drake wrote:
> >
> > > Guangzhi,
> > >
> > > In Fong's note she indicated that the contention can be completely
> > resolved
> > > by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> > > node 1 is told the result of node 2's decision making process.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Guangzhi Li [mailto:gli@research.att.com]
> > > Sent: Monday, August 27, 2001 2:13 PM
> > > To: Fong Liaw
> > > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > > Subject: Re: Question on GMPLS contentions resolution
> > >
> > > Fong:
> > >
> > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
> > both
> > > uni-directional and bi-directional together and uses the same port pool,
> > > then a PATH and a RESV may cross each other. I think that it should be
> > legal
> > > based on current GMPLS specification. IF this scenario happens, GMPLS has
> > to
> > > provide one standard way to handle this situation.
> > >
> > > Your suggestion works but it still involves the implementations of node 1
> > > and node 2. Both nodes should interperate the same way. That means RESV
> > > message always wins PATH message. No problem.
> > >
> > > I assume that the I/O ports of bi-didrectional LSP are paired together,
> > then
> > > suggested_label = upstream_label and suggested_label is hard binding. Note
> > > that contention happens in either this case or lack of resource. If
> > > suggested_label could be different upstream_label, no contention problem
> > at
> > > all.
> > >
> > > -- Guangzhi
> > >
> > > Fong Liaw wrote:
> > >
> > > > Guangzhi
> > > >
> > > > The GMPLS contention resolution applies to the scenario
> > > > that two Path messages cross each other.  Your example
> > > > have Resv and Path cross each other so the rule in the
> > > > contention resolution does not directly apply and is more
> > > > of a policy and implementation issue.
> > > >
> > > > Here is one possible solution and is within the
> > > > interpretation of the draft, IMHO. here it is.
> > > > If node 2 already sends Resv to node 1, LSP A should
> > > > be considered established and therefore LSP B should
> > > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > > LSP A is still in establishing mode and node 2 can resolve
> > > > the contention internally by rejecting LSP A or LSP B, based
> > > > on their setting up priority or it can change LSP A's
> > > > label and reprogram the cross-connect without ever noticed
> > > > by any external node.  In both cases, node 2 is the one
> > > > that resolve this contention.  Hope this helps.
> > > >
> > > > p.s. I think you meant to use LABEL_SET since
> > > > Suggested label is a suggestion, not a hard binding.
> > > >
> > > > Regards
> > > > -Fong
> > > >
> > > > >  -----Original Message-----
> > > > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > > > >  Cc: gli@research.att.com
> > > > >  Subject: Question on GMPLS contentions resolution
> > > > >
> > > > >
> > > > >  Dear GMPLS authors and all experts:
> > > > >
> > > > >  During GMPLS last call, I posted the same question on the
> > > > >  mailing list
> > > > >  without response. Please somebody spend a little time and
> > > > >  check with the
> > > > >  following example? Something seems not clear when the current GMPLS
> > > > >  contention resution schemes are applied on a framework with both
> > > > >  bi-directional and uni-directional LSPs. Your clarification
> > > > >  is very much
> > > > >  appreciated.
> > > > >
> > > > >  Sincerely,
> > > > >
> > > > >  Guangzhi
> > > > >
> > > > >  -------------------------------------------------------------
> > > > >  -------------------------------------
> > > > >
> > > > >  The issue arises because contention is resolved between
> > > > >  bi-directional
> > > > >  LSPs by the node with the higher node index while for uni-directional
> > > > >  LSPs, contention is resolved by the downstream node. Consider the
> > > > >  following example of two nodes with paired, bi-directional interfaces
> > > > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > > > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > > > >  transmitter port and
> > > > >  label 2 for the receiver port; node 2 uses label 4 for the
> > > > >  transmitter
> > > > >  port and label 3 for the receiver port.   We assume that a
> > > > >  bi-directional LSP requires a single I/O interface.
> > > > >
> > > > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > > > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > > > >  to node 2,
> > > > >  with the uni-directional LSP setup request arriving marginally before
> > > > >  the bi-directional LSP.  LSP A does not use a suggested
> > > > >  label, and thus
> > > > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > > > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > > > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > > > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > > > >  contention resolution rule for bi-directional LSPs) that LSP
> > > > >  B wins the
> > > > >  contention and thus label 3 is assigned to LSP B.  Thus
> > > > >  label 1 at node
> > > > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > > > >  LSPs have "won" the contention.
> > > > >
> > > > >



From owner-mpls@UU.NET  Tue Aug 28 14:22:21 2001
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 OAA17775
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 14:22:20 -0400 (EDT)
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 QQlebh07717;
	Tue, 28 Aug 2001 18:23:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebh12778
	for mpls-outgoing; Tue, 28 Aug 2001 18:22: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 QQlebh12749
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 18:22: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 QQlebh16835
	for <mpls@UU.NET>; Tue, 28 Aug 2001 18:19:55 GMT
Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQlebh10464
	for <mpls@UU.NET>; Tue, 28 Aug 2001 18:19:54 GMT
Received: from mail1.tellium.com (mail1 [151.198.92.140])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f7SIGe909850;
	Tue, 28 Aug 2001 14:16:41 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <RTXTA1Z4>; Tue, 28 Aug 2001 14:19:28 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D022040402088950@mail1.tellium.com>
From: Hang Liu <hliu@tellium.com>
To: "'Guangzhi Li'" <gli@research.att.com>, Hang Liu <hliu@tellium.com>,
        John Drake <jdrake@calient.net>, Fong Liaw <fliaw@zaffire.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Tue, 28 Aug 2001 14:19:24 -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

Guangzhi,

It is true that a consistent way is needed to handle this case. Otherwise,
as you mentioned,  both LSP A and LSP B may fail.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 1:39 PM
To: Hang Liu; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


Hang:

I did not make it clear. I assume that the I/O ports of Bi-directional LSP
are
paired. After node 1 configured the cross-connect with the upstream label
(of course
suggested label) for LSP B,  node 1 received the uni-directional RESV
message for
LSP A, is it obviously defined in GMPLS that node 1 should accept LSP A and
give up
LSP B or simply is it a local decision/policy implementation?

-- Guangzhi

Guangzhi Li wrote:

> Hang:
>
> NO. The PATH message is bi-directional and the RESV is uni-directional. If
there
> is a contention,  the contention happens with LSP A and the upstream label
of
> LSP B.
>
> In your suggestion, you used IF. IF GMPLS specifies a consisten way to
resolve
> it, such as Resv wins Path message in all cases, there is no problem. A
simply
> local decision is NOT enough.
>
> Please draw pictures and apply current GMPLS contention resolution schemes
ONLY.
> You will see something needs to be fixed.
>
> Guangzhi
>
> Hang Liu wrote:
>
> > Guangzhi,
> >
> > For this case, if Node 1 always maps the label in the RESV message and
> > creates RSB. LSP A will be set up. The suggested label in the PATH
message
> > from Node 1 is only preference. LSP B will be rejected by Node 2.
> >
> > Hang
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:gli@research.att.com]
> > Sent: Tuesday, August 28, 2001 9:52 AM
> > To: John Drake
> > Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > John:
> >
> > No. Node 1 may send out the PATH message to node 2 as the same time as
node
> > 2
> > sends out the RESV message to node 1. If the contention resolution is a
> > local
> > decision or policy implementation, node 1 may decide to fail LSP A since
> > node 1
> > has the higher node ID. Then both LSP A and LSP B are failed. This is
not
> > what
> > we want. So, a consistent decision is required between these two nodes.
> >
> > Thanks,
> >
> > -- Guangzhi
> >
> > John Drake wrote:
> >
> > > Guangzhi,
> > >
> > > In Fong's note she indicated that the contention can be completely
> > resolved
> > > by node 2, so I'm not sure that there's an interoperability issue.
I.e.,
> > > node 1 is told the result of node 2's decision making process.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Guangzhi Li [mailto:gli@research.att.com]
> > > Sent: Monday, August 27, 2001 2:13 PM
> > > To: Fong Liaw
> > > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > > Subject: Re: Question on GMPLS contentions resolution
> > >
> > > Fong:
> > >
> > > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network
runs
> > both
> > > uni-directional and bi-directional together and uses the same port
pool,
> > > then a PATH and a RESV may cross each other. I think that it should be
> > legal
> > > based on current GMPLS specification. IF this scenario happens, GMPLS
has
> > to
> > > provide one standard way to handle this situation.
> > >
> > > Your suggestion works but it still involves the implementations of
node 1
> > > and node 2. Both nodes should interperate the same way. That means
RESV
> > > message always wins PATH message. No problem.
> > >
> > > I assume that the I/O ports of bi-didrectional LSP are paired
together,
> > then
> > > suggested_label = upstream_label and suggested_label is hard binding.
Note
> > > that contention happens in either this case or lack of resource. If
> > > suggested_label could be different upstream_label, no contention
problem
> > at
> > > all.
> > >
> > > -- Guangzhi
> > >
> > > Fong Liaw wrote:
> > >
> > > > Guangzhi
> > > >
> > > > The GMPLS contention resolution applies to the scenario
> > > > that two Path messages cross each other.  Your example
> > > > have Resv and Path cross each other so the rule in the
> > > > contention resolution does not directly apply and is more
> > > > of a policy and implementation issue.
> > > >
> > > > Here is one possible solution and is within the
> > > > interpretation of the draft, IMHO. here it is.
> > > > If node 2 already sends Resv to node 1, LSP A should
> > > > be considered established and therefore LSP B should
> > > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > > LSP A is still in establishing mode and node 2 can resolve
> > > > the contention internally by rejecting LSP A or LSP B, based
> > > > on their setting up priority or it can change LSP A's
> > > > label and reprogram the cross-connect without ever noticed
> > > > by any external node.  In both cases, node 2 is the one
> > > > that resolve this contention.  Hope this helps.
> > > >
> > > > p.s. I think you meant to use LABEL_SET since
> > > > Suggested label is a suggestion, not a hard binding.
> > > >
> > > > Regards
> > > > -Fong
> > > >
> > > > >  -----Original Message-----
> > > > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > > > >  Cc: gli@research.att.com
> > > > >  Subject: Question on GMPLS contentions resolution
> > > > >
> > > > >
> > > > >  Dear GMPLS authors and all experts:
> > > > >
> > > > >  During GMPLS last call, I posted the same question on the
> > > > >  mailing list
> > > > >  without response. Please somebody spend a little time and
> > > > >  check with the
> > > > >  following example? Something seems not clear when the current
GMPLS
> > > > >  contention resution schemes are applied on a framework with both
> > > > >  bi-directional and uni-directional LSPs. Your clarification
> > > > >  is very much
> > > > >  appreciated.
> > > > >
> > > > >  Sincerely,
> > > > >
> > > > >  Guangzhi
> > > > >
> > > > >  -------------------------------------------------------------
> > > > >  -------------------------------------
> > > > >
> > > > >  The issue arises because contention is resolved between
> > > > >  bi-directional
> > > > >  LSPs by the node with the higher node index while for
uni-directional
> > > > >  LSPs, contention is resolved by the downstream node. Consider the
> > > > >  following example of two nodes with paired, bi-directional
interfaces
> > > > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100
and
> > > > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > > > >  transmitter port and
> > > > >  label 2 for the receiver port; node 2 uses label 4 for the
> > > > >  transmitter
> > > > >  port and label 3 for the receiver port.   We assume that a
> > > > >  bi-directional LSP requires a single I/O interface.
> > > > >
> > > > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > > > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > > > >  to node 2,
> > > > >  with the uni-directional LSP setup request arriving marginally
before
> > > > >  the bi-directional LSP.  LSP A does not use a suggested
> > > > >  label, and thus
> > > > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > > > >  corresponding to label 1 at node 1.  At the same time, for LSP B
(the
> > > > >  bi-directional LSP) node 1 assigns label 2, with suggested label
1.
> > > > >  Because node 1 has the higher node ID, node 2 will assume (due to
the
> > > > >  contention resolution rule for bi-directional LSPs) that LSP
> > > > >  B wins the
> > > > >  contention and thus label 3 is assigned to LSP B.  Thus
> > > > >  label 1 at node
> > > > >  1 (label 3 at node 2) has been assigned to two different LSPs.
Both
> > > > >  LSPs have "won" the contention.
> > > > >
> > > > >



From owner-mpls@UU.NET  Tue Aug 28 16:24:26 2001
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 QAA20496
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 16:24:26 -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 QQlebp25391;
	Tue, 28 Aug 2001 20:24:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebp01222
	for mpls-outgoing; Tue, 28 Aug 2001 20:24:21 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 QQlebp01211
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:24:18 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 QQlebp00174
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:22:19 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlebp20935
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:22:21 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA18934 for mpls@uu.net; Tue, 28 Aug 2001 16:22:17 -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 QQlebp01063
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:21:45 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 QQlebp24538
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:19:44 GMT
Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: netmail2.alcatel.com [128.251.168.51])
	id QQlebp16235
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:19:46 GMT
Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged))
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA15657
	for <mpls@UU.NET>; Tue, 28 Aug 2001 15:19:43 -0500 (CDT)
Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA3688
          for <mpls@UU.NET>; Tue, 28 Aug 2001 16:35:34 -0400
Message-ID: <3B8BFDA8.9544F7F3@usa.alcatel.com>
Date: Tue, 28 Aug 2001 16:23:04 -0400
From: Yuan Gu <Yuan.Gu@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls <mpls@UU.NET>
Subject: ASPEC and MTU
Content-Type: multipart/mixed;
 boundary="------------2A6764498964A7A34F83EEDF"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Hello, everyone:


According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt and
RFC2210, MTU should be getten from ASPEC if Integrated Services object
is presented in Path msg.

On the other hand, ASPEC is an OPTIONAL object according to section 3.1
of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.

My quesions are:

1. In the case of Integrated Service Tspec is presented in Path msg, is
ASPEC still OPTIONAL?
2. If the answer of above question is YES, how do we manage the Path MTU
if ASPEC is not presented in Path msg?

Thanks for your answer!

Best Regards!
Yuan Gu

--------------2A6764498964A7A34F83EEDF
Content-Type: text/x-vcard; charset=us-ascii;
 name="Yuan.Gu.vcf"
Content-Description: Card for Yuan Gu
Content-Disposition: attachment;
 filename="Yuan.Gu.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Gu;Yuan
tel;work:703-679-6474
x-mozilla-html:FALSE
org:Alcatel USA;CID
adr:;;15036 Conference Center Drive;Chantilly;VA;20151;
version:2.1
email;internet:Yuan.Gu@usa.alcatel.com
title:Software Engineer
fn:Yuan Gu
end:vcard

--------------2A6764498964A7A34F83EEDF--



From owner-mpls@UU.NET  Tue Aug 28 16:45:33 2001
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 QAA21016
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 16:45:33 -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 QQlebr18178;
	Tue, 28 Aug 2001 20:46:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebr03142
	for mpls-outgoing; Tue, 28 Aug 2001 20:45: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 QQlebr03134
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:45:23 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 QQlebq21922
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:44:29 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 QQlebq26050
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:44: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 QAA28760;
	Tue, 28 Aug 2001 16:44: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 QAA26024;
	Tue, 28 Aug 2001 16:44:21 -0400 (EDT)
Message-ID: <3B8C02B4.B0BD8799@marconi.com>
Date: Tue, 28 Aug 2001 16:44:36 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: Yuan Gu <Yuan.Gu@usa.alcatel.com>
CC: mpls <mpls@UU.NET>
Subject: Re: ASPEC and MTU
References: <3B8BFDA8.9544F7F3@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yuan Gu wrote:
> 
> According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> and RFC2210, MTU should be getten from ASPEC if Integrated Services
> object is presented in Path msg.

No.  ADSPEC is used by the transit routers to calculate the MTU along
the path.  It says nothing about what else should be done with this
value.

The MTU requested for the LSP is in the TSPEC object.

> On the other hand, ASPEC is an OPTIONAL object according to section
> 3.1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
> 
> My quesions are:
> 
> 1. In the case of Integrated Service Tspec is presented in Path
> msg, is ASPEC still OPTIONAL?

Yes.  The choice of service (controlled-load, guaranteed, or Null) is
determined by what services are present in the Adspec object.  If it is
missing, then it is up to the implementation of the egress router to
decide.

> 2. If the answer of above question is YES, how do we manage the
> Path MTU if ASPEC is not presented in Path msg?

In this case, path MTU is not computed.  The MTU requested in the TSPEC
should be used.  If it is no good, then a router somewhere will reject
the Resv with an admission control error.

-- David


From owner-mpls@UU.NET  Tue Aug 28 16:50:59 2001
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 QAA21158
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 16:50:59 -0400 (EDT)
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 QQlebr06982;
	Tue, 28 Aug 2001 20:51:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebr03746
	for mpls-outgoing; Tue, 28 Aug 2001 20:50: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 QQlebr03711
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:50: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 QQlebr29809
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:47:48 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlebr01359
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:47:50 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA14284
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:47:47 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082813464515926
 for <mpls@UU.NET>; Tue, 28 Aug 2001 13:46:45 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <R51VWCFL>; Tue, 28 Aug 2001 13:47:47 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA05F@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: mpls <mpls@UU.NET>
Subject: RE: ASPEC and MTU
Date: Tue, 28 Aug 2001 13:47:42 -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

ASPEC is optional. It is used by the receiver to get information about the
path, such as the MTU. It is used because there is no negotiation in RSVP.
If it is not present, the receiver can either get the information through
other mechanism, or make the reservation without knowledge of the path, and
risk having the reservation request rejected, due to factors like path MTU.

ASPEC is to collect information along the path only. The decision for QoS,
and what you refer to in the mail, should be derived from the FLOWSPEC.

- Mark

> -----Original Message-----
> From: Yuan Gu [mailto:Yuan.Gu@usa.alcatel.com]
> Sent: Tuesday, August 28, 2001 1:23 PM
> To: mpls
> Subject: ASPEC and MTU
> 
> 
> Hello, everyone:
> 
> 
> According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt and
> RFC2210, MTU should be getten from ASPEC if Integrated Services object
> is presented in Path msg.
> 
> On the other hand, ASPEC is an OPTIONAL object according to 
> section 3.1
> of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
> 
> My quesions are:
> 
> 1. In the case of Integrated Service Tspec is presented in 
> Path msg, is
> ASPEC still OPTIONAL?
> 2. If the answer of above question is YES, how do we manage 
> the Path MTU
> if ASPEC is not presented in Path msg?
> 
> Thanks for your answer!
> 
> Best Regards!
> Yuan Gu
> 


From owner-mpls@UU.NET  Tue Aug 28 16:54:55 2001
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 QAA21279
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 16:54:55 -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 QQlebr19674;
	Tue, 28 Aug 2001 20:55:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebr04208
	for mpls-outgoing; Tue, 28 Aug 2001 20:55: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 QQlebr04190
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:54:58 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 QQlebr09401
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:51:51 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlebr07438
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:51:53 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA21657 for mpls@uu.net; Tue, 28 Aug 2001 16:51:49 -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 QQlebr03792
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:51: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 QQlebr06310
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:50:35 GMT
Received: from radiant.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radiant.calient.net [63.102.55.206])
	id QQlebr10811
	for <mpls@UU.NET>; Tue, 28 Aug 2001 20:50:34 GMT
Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RJNZ7386>; Tue, 28 Aug 2001 13:50:35 -0700
Message-ID: <A1AFE5CF886C5D439494D9D5DE84EEF3BEAD8E@radiant.chromisys.com>
From: Karthik Subramanian <karthik@calient.net>
To: "'Hang Liu'" <hliu@tellium.com>, "'Guangzhi Li'" <gli@research.att.com>,
        John Drake <jdrake@calient.net>, Fong Liaw <fliaw@zaffire.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Tue, 28 Aug 2001 13:50:34 -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

Guangzhi,
Let me try to understand what you are suggesting here. Please correct me if
I'm wrong.

                   m------------>n
               N1                   N2
                   o<------------p

m,n,o,p are the labels for a bidirectional port. 
LSP A is an uni-directional LSP whose direction is from N1 to N2
LSP B is a bi-directional LSP whose direction is from N1 to N2.

The sequence of operations is

1. N1 suggests 'n' for LSP A.
2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve
'n' yet.
3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to
N1.
   Simultaneously, for LSP B, N1 allocates 'o' as upstream label,
       suggests 'n' for the forward direction and forwards the PATH.

The problem is caused due to N1 suggesting the same label 'n' for 2 lsps.
With regard to suggested labels you can take 2 approaches.

1. Suggested Label is reserved by the upstream node when the PATH is
forwarded:
      In this case, the problem won't arise, since during step 1, the link
(m,n) is reserved and hence for LSP B, this port is unavailable (since the
I/O ports of a bi-directional LSP are paired).

2. Suggested Label is NOT reserved by the upstream node until RESV comes:
      In this case, during step 3, you are contradicting yourself by making
the cross-connect in N1 and hence reserving the port. I understand that the
I/O port pairing for bi-directional lsp might be a hardware restriction, but
its a contradiction nonetheless.

You need to decide which approach to take and no violations must be made.
The first approach seems logical to me.

Karthik


> From: Guangzhi Li [mailto:gli@research.att.com]
> 
> I did not make it clear. I assume that the I/O ports of 
> Bi-directional LSP
> are
> paired. After node 1 configured the cross-connect with the 
> upstream label
> (of course
> suggested label) for LSP B,  node 1 received the uni-directional RESV
> message for
> LSP A, is it obviously defined in GMPLS that node 1 should 
> accept LSP A and
> give up
> LSP B or simply is it a local decision/policy implementation?
> 
> -- Guangzhi
> 
> Guangzhi Li wrote:
> 
> > Hang:
> >
> > NO. The PATH message is bi-directional and the RESV is 
> uni-directional. If
> there
> > is a contention,  the contention happens with LSP A and the 
> upstream label
> of
> > LSP B.
> >
> > In your suggestion, you used IF. IF GMPLS specifies a 
> consisten way to
> resolve
> > it, such as Resv wins Path message in all cases, there is 
> no problem. A
> simply
> > local decision is NOT enough.
> >
> > Please draw pictures and apply current GMPLS contention 
> resolution schemes
> ONLY.
> > You will see something needs to be fixed.
> >
> > Guangzhi



From owner-mpls@UU.NET  Tue Aug 28 16:58:53 2001
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 QAB21360
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 16:58:53 -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 QQlebr14002;
	Tue, 28 Aug 2001 20:59:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebr04545
	for mpls-outgoing; Tue, 28 Aug 2001 20:59: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 QQlebr04519
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 20:58:53 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 QQlebr25953
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:58:31 GMT
Received: from baucis.sc.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns3.intel.com [143.183.152.22])
	id QQlebr12383
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:58:33 GMT
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA04200
	for <mpls@uu.net>; Tue, 28 Aug 2001 20:58:30 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 28 Aug 2001 20:58:29 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RR4199Z7>; Tue, 28 Aug 2001 13:58:29 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA062@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: ASPEC and MTU
Date: Tue, 28 Aug 2001 13:58:24 -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

ASPEC is optional. It is used by the receiver to get information about the
path, such as the MTU. It is used because there is no negotiation in RSVP.
If it is not present, the receiver can either get the information through
other mechanism, or make the reservation without knowledge of the path, and
risk having the reservation request rejected, due to factors like path MTU.

ASPEC is to collect information along the path only. The decision for QoS,
and what you refer to in the mail, should be derived from the FLOWSPEC.

 - Mark

> -----Original Message-----
> From: Yuan Gu [mailto:Yuan.Gu@usa.alcatel.com]
> Sent: Tuesday, August 28, 2001 1:23 PM
> To: mpls
> Subject: ASPEC and MTU
>
>
> Hello, everyone:
>
>
> According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt and
> RFC2210, MTU should be getten from ASPEC if Integrated Services object
> is presented in Path msg.
>
> On the other hand, ASPEC is an OPTIONAL object according to
> section 3.1
> of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
>
> My quesions are:
>
> 1. In the case of Integrated Service Tspec is presented in
> Path msg, is
> ASPEC still OPTIONAL?
> 2. If the answer of above question is YES, how do we manage
> the Path MTU
> if ASPEC is not presented in Path msg?
>
> Thanks for your answer!
>
> Best Regards!
> Yuan Gu
>




From owner-mpls@UU.NET  Tue Aug 28 17:02:53 2001
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 RAA21456
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:02:53 -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 QQlebs20273;
	Tue, 28 Aug 2001 21:03:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebs08823
	for mpls-outgoing; Tue, 28 Aug 2001 21:03:04 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 QQlebs08799
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:03: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 QQlebs11438
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:02:20 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 QQlebs18409
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:02: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 RAA00797
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:02: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 RAA01568
	for <mpls@UU.NET>; Tue, 28 Aug 2001 17:02:17 -0400 (EDT)
Message-ID: <3B8C06E7.EA1BE7CB@marconi.com>
Date: Tue, 28 Aug 2001 17:02:31 -0400
From: David Charlap <david.charlap@marconi.com>
Reply-To: mpls <mpls@UU.NET>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls <mpls@UU.NET>
Subject: Re: ASPEC and MTU
References: <F1CE15E08172D4119247009027AE9D500C7CA05F@FMSMSX37>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Feng, Mark" wrote:
> 
> ASPEC is to collect information along the path only. The decision
> for QoS, and what you refer to in the mail, should be derived from
> the FLOWSPEC.

FLOWSPEC is provided by the egress router.  It _IS_ the QoS request.

The egress router chooses a FLOWSPEC based on anything it wants. 
Typically, the TSPEC and ADSPEC that exist in the incoming Path message
will be used to compute this.

The TSPEC represents the QoS that the ingress router wants.  The ADSPEC
represents what the network is capable of providing.  Between the two,
and maybe also some local policy decisions, the egress router has enough
information to choose a FLOWSPEC.

-- David


From owner-mpls@UU.NET  Tue Aug 28 17:09:59 2001
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 RAA21571
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:09:59 -0400 (EDT)
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 QQlebs07804;
	Tue, 28 Aug 2001 21:10:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebs15259
	for mpls-outgoing; Tue, 28 Aug 2001 21:10:11 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 QQlebs15231
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:10:09 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 QQlebs17717
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:10:06 GMT
Received: from web14305.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14305.mail.yahoo.com [216.136.173.81])
	id QQlebs01871
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:10:08 GMT
Message-ID: <20010828211005.1066.qmail@web14305.mail.yahoo.com>
Received: from [63.77.213.2] by web14305.mail.yahoo.com via HTTP; Tue, 28 Aug 2001 14:10:05 PDT
Date: Tue, 28 Aug 2001 14:10:05 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: draft-ietf-mpls-ldp-mib
To: mpls@UU.NET, cheenu@alphion.com
In-Reply-To: <F1CE15E08172D4119247009027AE9D500C7CA062@FMSMSX37>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
    Where can I get draft-ietf-mpls-ldp-mib document ?
I couldn't able to find  draft-ietf-mpls-ldp-mib.txt
document in IETF internet draft site.
Can anybody give location of that document?

Thanks,
Srini.


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-mpls@UU.NET  Tue Aug 28 17:15:21 2001
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 RAA21650
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:15:21 -0400 (EDT)
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 QQlebt15613;
	Tue, 28 Aug 2001 21:16:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebt16880
	for mpls-outgoing; Tue, 28 Aug 2001 21:15:30 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 QQlebt16844
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:15: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 QQlebt08849
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:15:07 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlebt14365
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:15:09 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA24563 for mpls@uu.net; Tue, 28 Aug 2001 17:15:05 -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 QQlebs16123
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:14:22 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 QQlebs03328
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:13:16 GMT
Received: from netmail2.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: netmail2.alcatel.com [128.251.168.51])
	id QQlebs19850
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:13:15 GMT
Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged))
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA23516
	for <mpls@UU.NET>; Tue, 28 Aug 2001 16:13:15 -0500 (CDT)
Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA4052;
          Tue, 28 Aug 2001 17:29:06 -0400
Message-ID: <3B8C0A34.5983C5E0@usa.alcatel.com>
Date: Tue, 28 Aug 2001 17:16:36 -0400
From: Yuan Gu <Yuan.Gu@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap <david.charlap@marconi.com>
CC: mpls <mpls@UU.NET>
Subject: Re: ASPEC and MTU
References: <3B8BFDA8.9544F7F3@usa.alcatel.com> <3B8C02B4.B0BD8799@marconi.com>
Content-Type: multipart/mixed;
 boundary="------------0CAA47FD8009E211146285D8"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

David:

Could you explain detailly what's the diffrent between TSPEC MTU and ASPEC
MTU? And what's the diffrent between LSP requested MTU and Path MTU?

Best Regards!
Yuan

David Charlap wrote:

> Yuan Gu wrote:
> >
> > According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> > and RFC2210, MTU should be getten from ASPEC if Integrated Services
> > object is presented in Path msg.
>
> No.  ADSPEC is used by the transit routers to calculate the MTU along
> the path.  It says nothing about what else should be done with this
> value.
>
> The MTU requested for the LSP is in the TSPEC object.
>
> > On the other hand, ASPEC is an OPTIONAL object according to section
> > 3.1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
> >
> > My quesions are:
> >
> > 1. In the case of Integrated Service Tspec is presented in Path
> > msg, is ASPEC still OPTIONAL?
>
> Yes.  The choice of service (controlled-load, guaranteed, or Null) is
> determined by what services are present in the Adspec object.  If it is
> missing, then it is up to the implementation of the egress router to
> decide.
>
> > 2. If the answer of above question is YES, how do we manage the
> > Path MTU if ASPEC is not presented in Path msg?
>
> In this case, path MTU is not computed.  The MTU requested in the TSPEC
> should be used.  If it is no good, then a router somewhere will reject
> the Resv with an admission control error.
>
> -- David

--------------0CAA47FD8009E211146285D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="Yuan.Gu.vcf"
Content-Description: Card for Yuan Gu
Content-Disposition: attachment;
 filename="Yuan.Gu.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Gu;Yuan
tel;work:703-679-6474
x-mozilla-html:FALSE
org:Alcatel USA;CID
adr:;;15036 Conference Center Drive;Chantilly;VA;20151;
version:2.1
email;internet:Yuan.Gu@usa.alcatel.com
title:Software Engineer
fn:Yuan Gu
end:vcard

--------------0CAA47FD8009E211146285D8--



From owner-mpls@UU.NET  Tue Aug 28 17:16:00 2001
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 RAA21674
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:16:00 -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 QQlebt26025;
	Tue, 28 Aug 2001 21:16:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebt17284
	for mpls-outgoing; Tue, 28 Aug 2001 21:16: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 QQlebt17071
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:15:49 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 QQlebt05017
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:15:35 GMT
Received: from nwmq0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwmq0102a.jc.digitran.com [165.251.28.22])
	id QQlebt11946
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:15:37 GMT
Received: from csrinivasan [12.34.209.74] by nwmq0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Tue, 28 Aug 2001 17:10:32 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Srinivas T M'" <srini_tm@yahoo.com>
Cc: <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-ldp-mib
Date: Tue, 28 Aug 2001 17:28:23 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB137@OPTONT>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20010828211005.1066.qmail@web14305.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

>     Where can I get draft-ietf-mpls-ldp-mib document ?
> I couldn't able to find  draft-ietf-mpls-ldp-mib.txt
> document in IETF internet draft site.
> Can anybody give location of that document?

Try:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-08.txt 



From owner-mpls@UU.NET  Tue Aug 28 17:17:42 2001
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 RAA21712
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:17:40 -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 QQlebt16015;
	Tue, 28 Aug 2001 21:18:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebt18424
	for mpls-outgoing; Tue, 28 Aug 2001 21:17:48 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 QQlebt18182
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:17:33 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 QQlebt18823
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:17:07 GMT
Received: from thalia.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlebt26896
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:17:05 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA04168
	for <mpls@UU.NET>; Tue, 28 Aug 2001 21:17:06 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082814164611847
 for <mpls@UU.NET>; Tue, 28 Aug 2001 14:16:46 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RR41X07T>; Tue, 28 Aug 2001 14:18:05 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA063@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls'" <mpls@UU.NET>
Subject: RE: ASPEC and MTU
Date: Tue, 28 Aug 2001 14:17:04 -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

Sorry for the bad wording. What I am tring to say is that, in the TE draft,
path MTU is used during transmission of data (Seciont 2.6). That path MTU
should be derived from the FLOWSPEC, not the ADSPEC. 

- Mark

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, August 28, 2001 2:03 PM
> To: mpls
> Subject: Re: ASPEC and MTU
> 
> 
> "Feng, Mark" wrote:
> > 
> > ASPEC is to collect information along the path only. The decision
> > for QoS, and what you refer to in the mail, should be derived from
> > the FLOWSPEC.
> 
> FLOWSPEC is provided by the egress router.  It _IS_ the QoS request.
> 
> The egress router chooses a FLOWSPEC based on anything it wants. 
> Typically, the TSPEC and ADSPEC that exist in the incoming 
> Path message
> will be used to compute this.
> 
> The TSPEC represents the QoS that the ingress router wants.  
> The ADSPEC
> represents what the network is capable of providing.  Between the two,
> and maybe also some local policy decisions, the egress router 
> has enough
> information to choose a FLOWSPEC.
> 
> -- David
> 


From owner-mpls@UU.NET  Tue Aug 28 17:18:21 2001
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 RAA21723
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 17:18:21 -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 QQlebt17351;
	Tue, 28 Aug 2001 21:19:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebt19103
	for mpls-outgoing; Tue, 28 Aug 2001 21:18:28 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 QQlebt18701
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 21:18: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 QQlebt14649
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:17:00 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 QQlebt17797
	for <mpls@uu.net>; Tue, 28 Aug 2001 21:17:02 GMT
Received: from TIMETRANZVCSJA ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 28 Aug 2001 14:12:21 -0700
From: "Vach Kompella" <vkompella@timetra.com>
To: "Srinivas T M" <srini_tm@yahoo.com>, <mpls@UU.NET>
Subject: RE: draft-ietf-mpls-ldp-mib
Date: Tue, 28 Aug 2001 14:15:52 -0700
Message-ID: <FNEFIPCNJKDDONJGBCNEAEDACFAA.vkompella@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
In-Reply-To: <20010828211005.1066.qmail@web14305.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 28 Aug 2001 21:12:21.0378 (UTC) FILETIME=[2059D620:01C13006]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Try starting at the MPLS WG page
(http://www.ietf.org/html.charters/mpls-charter.html).

Here's the LDP MIB link.
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-08.txt

-Vach

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Srinivas
> T M
> Sent: Tuesday, August 28, 2001 2:10 PM
> To: mpls@UU.NET; cheenu@alphion.com
> Subject: draft-ietf-mpls-ldp-mib
>
>
> Hi,
>     Where can I get draft-ietf-mpls-ldp-mib document ?
> I couldn't able to find  draft-ietf-mpls-ldp-mib.txt
> document in IETF internet draft site.
> Can anybody give location of that document?
>
> Thanks,
> Srini.
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/



From owner-mpls@UU.NET  Tue Aug 28 18:16:18 2001
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 SAA22594
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 18:16:17 -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 QQlebx19067;
	Tue, 28 Aug 2001 22:16:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebx11773
	for mpls-outgoing; Tue, 28 Aug 2001 22:16: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 QQlebx11644
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 22:16: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 QQlebx09846
	for <mpls@UU.NET>; Tue, 28 Aug 2001 22:15:41 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 QQlebx10071
	for <mpls@UU.NET>; Tue, 28 Aug 2001 22:15: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 SAA06494
	for <mpls@UU.NET>; Tue, 28 Aug 2001 18:15:33 -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 SAA15687
	for <mpls@UU.NET>; Tue, 28 Aug 2001 18:15:34 -0400 (EDT)
Message-ID: <3B8C1815.A214D8C1@marconi.com>
Date: Tue, 28 Aug 2001 18:15:49 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls <mpls@UU.NET>
Subject: Re: ADSPEC and MTU
References: <3B8BFDA8.9544F7F3@usa.alcatel.com> <3B8C02B4.B0BD8799@marconi.com> <3B8C0A34.5983C5E0@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yuan Gu wrote:
> 
> Could you explain detailly what's the diffrent between TSPEC MTU
> and ASPEC MTU? And what's the diffrent between LSP requested MTU
> and Path MTU?

These are really basic questions.  You should read the IntServ RFCs more
closely.

TSPEC MTU is the MTU size in the SENDER_TSPEC object that is included in
Path messages.  It is the MTU size that the ingress router is requesting
for the LSP.

ADSPEC MTU is the MTU size in the ADSPEC object that is included in Path
messages.  It is either in the general parameters service fragment or in
the null service fragment, depending on which is used.  It is initialize
to the TSPEC MTU by the ingress router.  As the Path message propagates
through the network, the ADSPEC MTU may be reduced by routers whose MTU
values are smaller.

When the Path message finally arrives at the egress router, the MTU in
the TSPEC object (which has not changed) contains the MTU size that the
sender wants to use.  The MTU in the ADSPEC object (which was reduced by
the various transit routers) contains the path-MTU along the route that
the Path message followed.

During Resv processing, the egress router can include an MTU size in the
FLOWSPEC object.  (Zero means "don't care").  As the Resv message
propagates back to the ingress router, each transit router will compare
the MTU size of the FLOWSPEC with its own capabilities.  If the
requested MTU is beyond the router's capabilities, then it will fail the
reservation and generate an admission-control failure (delivered to the
ingress via PathErr in the case of RSVP-TE.)

If the reservation doesn't fail, then the ingress router will know the
maximum MTU value for the LSP by looking at the MTU value in the
received FLOWSPEC object.  It now has enough information to fragment
incoming IP datagrams such that they will not have to be further
fragmented by transit routers along the LSP.

-- David


From owner-mpls@UU.NET  Tue Aug 28 18:27:56 2001
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 SAA22781
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 18:27:56 -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 QQlebx00701;
	Tue, 28 Aug 2001 22:28:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlebx18984
	for mpls-outgoing; Tue, 28 Aug 2001 22:28:09 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 QQlebx18974
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 22:28:06 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 QQlebx17080
	for <mpls@uu.net>; Tue, 28 Aug 2001 22:27:59 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlebx06763
	for <mpls@uu.net>; Tue, 28 Aug 2001 22:28:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA00869 for mpls@uu.net; Tue, 28 Aug 2001 18:27: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 QQlebx18950
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 22:27:31 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 QQlebx17795
	for <mpls@uu.net>; Tue, 28 Aug 2001 22:26:43 GMT
Received: from baucis.sc.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns3.intel.com [143.183.152.22])
	id QQlebx06868
	for <mpls@uu.net>; Tue, 28 Aug 2001 22:26:41 GMT
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA14858
	for <mpls@uu.net>; Tue, 28 Aug 2001 22:26:42 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 28 Aug 2001 22:26:42 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RR410BBP>; Tue, 28 Aug 2001 15:26:40 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D5009AE2E21@FMSMSX37>
From: "Sharma, Prem" <p_sharma@trillium.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: FW: some queries on mpls-ftn-mib-03
Date: Tue, 28 Aug 2001 15:26:38 -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

Re-sending the mail I sent few days back. Authors, pls. respond.

Prem

>  -----Original Message-----
> From: 	Sharma, Prem  
> Sent:	Thursday, August 23, 2001 1:11 PM
> To:	'mpls@uu.net'
> Subject:	some queries on mpls-ftn-mib-03
> 
> Hi,
> 
> I was trying to see if some consensus has been reached on the following
> outstanding issues w.r.t. mpls-ftn-mib:
> *	Keeping mapping of DSCP values to LSPs/Tunnels 
> *	Use of CIDR prefixes instead of Address ranges.
> *	Keeping IPv6 flow label also. 
> 
> Aforementioned pertain to the mplsFTNEntry in the MIB.
> One more comment: I'll be better if the relation of this draft with
> diffserv mib could be clarified too.
> 
> Thanks.
> Prem



From owner-mpls@UU.NET  Tue Aug 28 19:31:43 2001
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 TAA23877
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 19:31:43 -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 QQlecc22354;
	Tue, 28 Aug 2001 23:32:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlecc13421
	for mpls-outgoing; Tue, 28 Aug 2001 23:31: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 QQlecc13413
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 23:31:25 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 QQlecc17865
	for <mpls@UU.NET>; Tue, 28 Aug 2001 23:30:56 GMT
Received: from basmail.basystems.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: basmail.basystems.com [209.211.220.7])
	id QQlecc07152
	for <mpls@UU.NET>; Tue, 28 Aug 2001 23:30:58 GMT
Received: from B10.basystems.com.adc.com ([146.71.194.72])
          by basmail.basystems.com (Netscape Messaging Server 3.62)
           with ESMTP id 217; Tue, 28 Aug 2001 19:34:05 -0400
From: Igor Lasic <igor_lasic@adc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15244.10850.600484.708378@B10.basystems.com>
Date: Tue, 28 Aug 2001 19:33:54 -0400
To: "Sharma, Prem" <p_sharma@trillium.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: FW: some queries on mpls-ftn-mib-03
In-Reply-To: <F1CE15E08172D4119247009027AE9D5009AE2E21@FMSMSX37>
References: <F1CE15E08172D4119247009027AE9D5009AE2E21@FMSMSX37>
X-Mailer: VM 6.92 under Emacs 20.7.1
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I had a similar question:

 > > *	Use of CIDR prefixes instead of Address ranges. 

  Authors seem to feel stronly that ranges are the way to go. In
  practice (from implementation point of view) if one would like to use
  FTN table to insert entries into a forwarding table that does not
  work. Also I question whether people are more used to using ranges vs
  prefix/len (or mask) concept.
  
  My opinion is that FTN table is usable if MPLS has a matching database
  that is outside of IP forwarding and is "sits" logically before IP
  lookup. I am not sure how many people are doing it that way. In our
  case we are not doing it that way (completely.)

  Another FTN feature I question is mapping table. In general when
  filtering is used (which the FTN database implies) people use access
  list concept where matching criteria is organized into lists and lists
  and matching criteria are prioritized. Then there is a mapping between
  the interface and the list not the individual matching criteria.

 I understand that it is possible to reorganize the database better by
  using the FTN implementation but it is not the common industry way of
  doing matching database.

  Please do not take this as an attack, I am trying to be constructive
  and align the FTN mib more with what are common practices in the
  field. After considering FTN mib we have decided not to use it because
  of the above two issues (ranges vs prefix/len and matching criteria vs
  access list.) 

  I promise this is the last time I bring this up. If MPLS community
  does not feel these are valid points that is fine. 

  My $0.02,

  Igor

  Disclaimer: oppinions are my own, I do not speak for the company.

Sharma, Prem writes:
 > Re-sending the mail I sent few days back. Authors, pls. respond.
 > 
 > Prem
 > 
 > >  -----Original Message-----
 > > From: 	Sharma, Prem  
 > > Sent:	Thursday, August 23, 2001 1:11 PM
 > > To:	'mpls@uu.net'
 > > Subject:	some queries on mpls-ftn-mib-03
 > > 
 > > Hi,
 > > 
 > > I was trying to see if some consensus has been reached on the following
 > > outstanding issues w.r.t. mpls-ftn-mib:
 > > *	Keeping mapping of DSCP values to LSPs/Tunnels 
 > > *	Use of CIDR prefixes instead of Address ranges.
 > > *	Keeping IPv6 flow label also. 
 > > 
 > > Aforementioned pertain to the mplsFTNEntry in the MIB.
 > > One more comment: I'll be better if the relation of this draft with
 > > diffserv mib could be clarified too.
 > > 
 > > Thanks.
 > > Prem



From owner-mpls@UU.NET  Tue Aug 28 19:39:00 2001
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 TAA23940
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 19:39:00 -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 QQlecc06140;
	Tue, 28 Aug 2001 23:39:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlecc14104
	for mpls-outgoing; Tue, 28 Aug 2001 23:39:08 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 QQlecc14092
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 28 Aug 2001 23:38:51 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 QQlecc18217
	for <mpls@UU.NET>; Tue, 28 Aug 2001 23:38:47 GMT
Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQlecc03228
	for <mpls@UU.NET>; Tue, 28 Aug 2001 23:38:48 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id AC93D4CE3F; Tue, 28 Aug 2001 19:38:46 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id TAA05183;
	Tue, 28 Aug 2001 19:38:45 -0400 (EDT)
Message-ID: <3B8C2CED.526B20E8@research.att.com>
Date: Tue, 28 Aug 2001 19:44:45 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Karthik Subramanian <karthik@calient.net>
Cc: "'Hang Liu'" <hliu@tellium.com>, John Drake <jdrake@calient.net>,
        Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <A1AFE5CF886C5D439494D9D5DE84EEF3BEAD8E@radiant.chromisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Karthik:

I understand your argument. But
(1) It it legal not to suggest a label in PATH for a uni-directional LSP but to
suggest a label for a bi-directional LSP especially I/O ports are paired.
(2) If this is too weak, then assume another scenario: the PATH message of LSP A
suggested a label but was rejected by N2 due to race condition of other LSPs,
(such as a bi-directional LSP C from N2 to N1), then it is up to the RESV
message of LSP A to assign the label. At this time, the condition happens
between LSP A and LSP B.

You may say why LSP A is so unlucky and it may not happen two race conditions in
a short time. But it may although the probability is very small :=)

If you draw pictures, you may find other scenarios.

-- Guangzhi


Karthik Subramanian wrote:

> Guangzhi,
> Let me try to understand what you are suggesting here. Please correct me if
> I'm wrong.
>
>                    m------------>n
>                N1                   N2
>                    o<------------p
>
> m,n,o,p are the labels for a bidirectional port.
> LSP A is an uni-directional LSP whose direction is from N1 to N2
> LSP B is a bi-directional LSP whose direction is from N1 to N2.
>
> The sequence of operations is
>
> 1. N1 suggests 'n' for LSP A.
> 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve
> 'n' yet.
> 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to
> N1.
>    Simultaneously, for LSP B, N1 allocates 'o' as upstream label,
>        suggests 'n' for the forward direction and forwards the PATH.
>
> The problem is caused due to N1 suggesting the same label 'n' for 2 lsps.
> With regard to suggested labels you can take 2 approaches.
>
> 1. Suggested Label is reserved by the upstream node when the PATH is
> forwarded:
>       In this case, the problem won't arise, since during step 1, the link
> (m,n) is reserved and hence for LSP B, this port is unavailable (since the
> I/O ports of a bi-directional LSP are paired).
>
> 2. Suggested Label is NOT reserved by the upstream node until RESV comes:
>       In this case, during step 3, you are contradicting yourself by making
> the cross-connect in N1 and hence reserving the port. I understand that the
> I/O port pairing for bi-directional lsp might be a hardware restriction, but
> its a contradiction nonetheless.
>
> You need to decide which approach to take and no violations must be made.
> The first approach seems logical to me.
>
> Karthik
>
> > From: Guangzhi Li [mailto:gli@research.att.com]
> >
> > I did not make it clear. I assume that the I/O ports of
> > Bi-directional LSP
> > are
> > paired. After node 1 configured the cross-connect with the
> > upstream label
> > (of course
> > suggested label) for LSP B,  node 1 received the uni-directional RESV
> > message for
> > LSP A, is it obviously defined in GMPLS that node 1 should
> > accept LSP A and
> > give up
> > LSP B or simply is it a local decision/policy implementation?
> >
> > -- Guangzhi
> >
> > Guangzhi Li wrote:
> >
> > > Hang:
> > >
> > > NO. The PATH message is bi-directional and the RESV is
> > uni-directional. If
> > there
> > > is a contention,  the contention happens with LSP A and the
> > upstream label
> > of
> > > LSP B.
> > >
> > > In your suggestion, you used IF. IF GMPLS specifies a
> > consisten way to
> > resolve
> > > it, such as Resv wins Path message in all cases, there is
> > no problem. A
> > simply
> > > local decision is NOT enough.
> > >
> > > Please draw pictures and apply current GMPLS contention
> > resolution schemes
> > ONLY.
> > > You will see something needs to be fixed.
> > >
> > > Guangzhi



From owner-mpls@UU.NET  Tue Aug 28 20:23:14 2001
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 UAA24448
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 20:23:14 -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 QQlecf25390;
	Wed, 29 Aug 2001 00:23:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlecf06076
	for mpls-outgoing; Wed, 29 Aug 2001 00:23: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 QQlecf06037
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 00:22:55 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 QQlecf26803
	for <mpls@UU.NET>; Wed, 29 Aug 2001 00:22:42 GMT
Received: from fido.nc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-54-024.nc.rr.com [66.26.54.24])
	id QQlecf24264
	for <mpls@UU.NET>; Wed, 29 Aug 2001 00:22:43 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f7T0N0p17400;
	Tue, 28 Aug 2001 20:23:00 -0400
Date: Tue, 28 Aug 2001 20:22:58 -0400 (EDT)
From: Jim Boyle <jimpb@nc.rr.com>
X-X-Sender:  <jboyle@fido>
To: George Swallow <swallow@cisco.com>
cc: <mpls@UU.NET>, <vijay@cosinecom.com>
Subject: Re: Last call on recovery framework
In-Reply-To: <200108212203.SAA28209@telescope.cisco.com>
Message-ID: <Pine.LNX.4.33.0108282019120.15337-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


I'm having trouble identifying the IP statement at

http://www.ietf.org/ipr.html

that section 7 (intellection property) references.

Can one of the authors provide a clarification?

Jim



On Tue, 21 Aug 2001, George Swallow wrote:

> This message begins a last call on
>
>       Framework for MPLS-based Recovery
>       <draft-ietf-mpls-recovery-frmwrk-02.txt>
>
> The last call ends on Sept 5 at midnight GMT.
>
> ...George
>
>
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>
>



From owner-mpls@UU.NET  Tue Aug 28 21:28:26 2001
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 VAA25192
	for <mpls-archive@lists.ietf.org>; Tue, 28 Aug 2001 21:28:26 -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 QQlecj00991;
	Wed, 29 Aug 2001 01:29:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlecj00777
	for mpls-outgoing; Wed, 29 Aug 2001 01:28: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 QQlecj00767
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 01:28: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 QQlecj16562
	for <mpls@UU.NET>; Wed, 29 Aug 2001 01:28:36 GMT
Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radiant.calient.net [63.102.55.206])
	id QQlecj08704
	for <mpls@UU.NET>; Wed, 29 Aug 2001 01:28:38 GMT
Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RJNZ7PWT>; Tue, 28 Aug 2001 18:28:35 -0700
Message-ID: <A1AFE5CF886C5D439494D9D5DE84EEF373729F@radiant.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Guangzhi Li'" <gli@research.att.com>, John Drake <jdrake@calient.net>
Cc: Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Tue, 28 Aug 2001 18:28:35 -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

What this requires is an RSVP implementation in which the Resv processing
checks to see whether there is any outstanding  Path request specifying a
upstream label that is tied to the downstream label received in the Resv,
and if there is to tear down the LSP that was just established with the
Resv, as opposed to an implementation that would process Resvs serially.  I
don't know how sensible this may or may not be.

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 6:52 AM
To: John Drake
Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


John:

No. Node 1 may send out the PATH message to node 2 as the same time as node
2
sends out the RESV message to node 1. If the contention resolution is a
local
decision or policy implementation, node 1 may decide to fail LSP A since
node 1
has the higher node ID. Then both LSP A and LSP B are failed. This is not
what
we want. So, a consistent decision is required between these two nodes.

Thanks,

-- Guangzhi

John Drake wrote:

> Guangzhi,
>
> In Fong's note she indicated that the contention can be completely
resolved
> by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> node 1 is told the result of node 2's decision making process.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Monday, August 27, 2001 2:13 PM
> To: Fong Liaw
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> Fong:
>
> Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
both
> uni-directional and bi-directional together and uses the same port pool,
> then a PATH and a RESV may cross each other. I think that it should be
legal
> based on current GMPLS specification. IF this scenario happens, GMPLS has
to
> provide one standard way to handle this situation.
>
> Your suggestion works but it still involves the implementations of node 1
> and node 2. Both nodes should interperate the same way. That means RESV
> message always wins PATH message. No problem.
>
> I assume that the I/O ports of bi-didrectional LSP are paired together,
then
> suggested_label = upstream_label and suggested_label is hard binding. Note
> that contention happens in either this case or lack of resource. If
> suggested_label could be different upstream_label, no contention problem
at
> all.
>
> -- Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > The GMPLS contention resolution applies to the scenario
> > that two Path messages cross each other.  Your example
> > have Resv and Path cross each other so the rule in the
> > contention resolution does not directly apply and is more
> > of a policy and implementation issue.
> >
> > Here is one possible solution and is within the
> > interpretation of the draft, IMHO. here it is.
> > If node 2 already sends Resv to node 1, LSP A should
> > be considered established and therefore LSP B should
> > be rejected by node 2. If node 2 hasn't sent back Resv,
> > LSP A is still in establishing mode and node 2 can resolve
> > the contention internally by rejecting LSP A or LSP B, based
> > on their setting up priority or it can change LSP A's
> > label and reprogram the cross-connect without ever noticed
> > by any external node.  In both cases, node 2 is the one
> > that resolve this contention.  Hope this helps.
> >
> > p.s. I think you meant to use LABEL_SET since
> > Suggested label is a suggestion, not a hard binding.
> >
> > Regards
> > -Fong
> >
> > >  -----Original Message-----
> > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > >  Sent: Monday, August 27, 2001 6:17 AM
> > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > >  Cc: gli@research.att.com
> > >  Subject: Question on GMPLS contentions resolution
> > >
> > >
> > >  Dear GMPLS authors and all experts:
> > >
> > >  During GMPLS last call, I posted the same question on the
> > >  mailing list
> > >  without response. Please somebody spend a little time and
> > >  check with the
> > >  following example? Something seems not clear when the current GMPLS
> > >  contention resution schemes are applied on a framework with both
> > >  bi-directional and uni-directional LSPs. Your clarification
> > >  is very much
> > >  appreciated.
> > >
> > >  Sincerely,
> > >
> > >  Guangzhi
> > >
> > >  -------------------------------------------------------------
> > >  -------------------------------------
> > >
> > >  The issue arises because contention is resolved between
> > >  bi-directional
> > >  LSPs by the node with the higher node index while for uni-directional
> > >  LSPs, contention is resolved by the downstream node. Consider the
> > >  following example of two nodes with paired, bi-directional interfaces
> > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > >  transmitter port and
> > >  label 2 for the receiver port; node 2 uses label 4 for the
> > >  transmitter
> > >  port and label 3 for the receiver port.   We assume that a
> > >  bi-directional LSP requires a single I/O interface.
> > >
> > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > >  to node 2,
> > >  with the uni-directional LSP setup request arriving marginally before
> > >  the bi-directional LSP.  LSP A does not use a suggested
> > >  label, and thus
> > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > >  contention resolution rule for bi-directional LSPs) that LSP
> > >  B wins the
> > >  contention and thus label 3 is assigned to LSP B.  Thus
> > >  label 1 at node
> > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > >  LSPs have "won" the contention.
> > >
> > >


From owner-mpls@UU.NET  Wed Aug 29 00:24:56 2001
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 AAA29016
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 00:24:56 -0400 (EDT)
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 QQlecv02438;
	Wed, 29 Aug 2001 04:26:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlecv12207
	for mpls-outgoing; Wed, 29 Aug 2001 04:25: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 QQlecv12200
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 04:25:30 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 QQlecv17692
	for <mpls@UU.NET>; Wed, 29 Aug 2001 04:25:25 GMT
Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQlecv02851
	for <mpls@UU.NET>; Wed, 29 Aug 2001 04:25:09 GMT
Received: from neelesh ([165.133.13.22])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id JAA02953;
	Wed, 29 Aug 2001 09:47:34 -0600 (GMT)
Message-ID: <007001c13042$b19e4940$160d85a5@mercurykr.com>
Reply-To: "Neelesh Dwivedi" <neelesh@mercurykr.com>
From: "Neelesh Dwivedi" <neelesh@mercurykr.com>
To: <mpls@UU.NET>
Cc: <cheenu@alphion.com>
Subject: LSP ID in LSR MIB
Date: Wed, 29 Aug 2001 09:55:16 +0530
Organization: Mercury Corporation
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
I have  few doubts related to the MPLS LSR MIB
(draft-ietf-mpls-lsr-mib-07.txt).

The Cross-Connect Table has an entry

       mplsXCLspId                 MplsLSPID

 This MplsLSPID is described in  draft-ietf-mpls-tc-mib-02.txt as

 "An identifier that is assigned to each LSP and is used to uniquely
identify
it.  This is assigned at the head end of the LSP and can be used by all LSRs
to identify this LSP.  This value is piggybacked by the signaling protocol
when this LSP is signaled within the network.  This identifier can then be
used at each LSR to identify which labels are being swapped to other
labels for this LSP.  For IPv4 addresses this results in a 6-octet long
cookie."
SYNTAX        OCTET STRING (SIZE (0..31))

 My questions are:
a)  Is there any standard format for this unique identifier ? If not, then
what can be the possible ways to assign it?

 b) What do we mean by "piggybacking" this value by the signaling protocol?
If it is to be advertised in some control message then where and how do
we do it?

 Regards,
Neelesh.

 Mercury Corporation
New Delhi R&D Centre,
Gurgaon, India.




From owner-mpls@UU.NET  Wed Aug 29 02:52:55 2001
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 CAA17373
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 02:52:55 -0400 (EDT)
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 QQledf20027;
	Wed, 29 Aug 2001 06:54:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQledf02372
	for mpls-outgoing; Wed, 29 Aug 2001 06:53:33 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 QQledf02348
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 06:53:18 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 QQledf10146
	for <mpls@UU.NET>; Wed, 29 Aug 2001 06:53:08 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQledf20679
	for <mpls@UU.NET>; Wed, 29 Aug 2001 06:53:04 GMT
Received: from multitech.co.in (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f7T6ssu24659;
	Wed, 29 Aug 2001 12:24:54 +0530
Message-ID: <3B8C9272.FA661195@multitech.co.in>
Date: Wed, 29 Aug 2001 12:27:54 +0530
From: abhay <abhay@multitech.co.in>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ling Li <lli@axiowave.com>
CC: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Re: A question on mpls-te-mib: mplsTunnelHopEntryPathComp
X-Priority: 2 (High)
References: <EB5FFC72F183D411B38200062957342976A99B@r2d2.axiowave.com>
Content-Type: multipart/alternative;
 boundary="------------9E5D6764BC4B7601C300A5D0"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------9E5D6764BC4B7601C300A5D0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Ling Li,

             What we have on our hands here is:

             1)A dynamic CSPF path can be requested from the source(Boston) to San Francisco

             Also,

             2)An Offline CSPF path can be requested on the source router

             In both the above cases one can request one router(Chicago) to be included as a rule.

             Altough the user has requested deliberate inclusion,the path is still dynamic

             with the INCLUDED router as a Constraint.

             In such cases,the constraint may not be satisfied.

             Only,when the user has requested a complete explicit path,then we can consider it to

             be a explicit hop

             else

             The hops are all dynamic.

             Hope this helps,

             Regards,

             Abhay

Ling Li wrote:

> I was confused by the description of mplsTunnelHopEntryPathComp as bellow:
>
> mplsTunnelHopEntryPathComp OBJECT-TYPE
> SYNTAX INTEGER {
>         dynamic(1), -- CSPF computed
>         explicit(2) -- strict hop
> }
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "If this value is set to dynamic, then the user
> should only specify the source and destination of
> the path and expect that the CSPF will calculate
> the remainder of the path. If this value is set to
> explicit, the user should specify the entire path
> for the tunnel to take. This path may contain
> strict or loose hops. Each hop along a specific
> path should have this object set to the same value"
> ::= { mplsTunnelHopEntry 14 }
>
> My question is: what if a user want to use CSPF to find a route from Boston
> to San Francisco, but specifically he/she wants the route to go through
> Chicago.
>
> The description seems suggesting that this operation is not allowed, because
> 1. The user specified not only the source and destination, but an extra
> loose hop (Chicago). Therefore mplsTunnelHopEntryPathComp  cannot be dynamic
> 2. The user wanted to enable CSPF to calculate the path, so explicit is not
> appropriate for mplsTunnelHopEntryPathComp.
>
> Could anyone clarify on this doubt?
>
> Thanks,
>
> Ling Li
>
> Axiowave Networks, Inc.
> Email: lli@axiowave.com
> ========================

--------------9E5D6764BC4B7601C300A5D0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>Hello Ling Li,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What we have on our hands here is:</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1)A dynamic CSPF path can be requested from the source(Boston) to San Francisco</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Also,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2)An Offline CSPF path can be requested on the source router</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In both the above cases one can request one router(Chicago) to be included as a rule.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Altough the user has requested deliberate inclusion,the path is still dynamic</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with the INCLUDED router as a Constraint.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In such cases,the constraint may not be satisfied.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Only,when the user has requested a complete explicit path,then we can consider it to</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be a explicit hop</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The hops are all dynamic.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope this helps,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Abhay</pre>

<pre></pre>

<p><br>Ling Li wrote:
<blockquote TYPE=CITE>I was confused by the description of mplsTunnelHopEntryPathComp
as bellow:
<p>mplsTunnelHopEntryPathComp OBJECT-TYPE
<br>SYNTAX INTEGER {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dynamic(1), -- CSPF computed
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; explicit(2) -- strict hop
<br>}
<br>MAX-ACCESS read-create
<br>STATUS current
<br>DESCRIPTION
<br>"If this value is set to dynamic, then the user
<br>should only specify the source and destination of
<br>the path and expect that the CSPF will calculate
<br>the remainder of the path. If this value is set to
<br>explicit, the user should specify the entire path
<br>for the tunnel to take. This path may contain
<br>strict or loose hops. Each hop along a specific
<br>path should have this object set to the same value"
<br>::= { mplsTunnelHopEntry 14 }
<p>My question is: what if a user want to use CSPF to find a route from
Boston
<br>to San Francisco, but specifically he/she wants the route to go through
<br>Chicago.
<p>The description seems suggesting that this operation is not allowed,
because
<br>1. The user specified not only the source and destination, but an extra
<br>loose hop (Chicago). Therefore mplsTunnelHopEntryPathComp&nbsp; cannot
be dynamic
<br>2. The user wanted to enable CSPF to calculate the path, so explicit
is not
<br>appropriate for mplsTunnelHopEntryPathComp.
<p>Could anyone clarify on this doubt?
<p>Thanks,
<p>Ling Li
<p>Axiowave Networks, Inc.
<br>Email: lli@axiowave.com
<br>========================</blockquote>
</html>

--------------9E5D6764BC4B7601C300A5D0--



From owner-mpls@UU.NET  Wed Aug 29 03:11:02 2001
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 DAA17552
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 03:11: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 QQledg26699;
	Wed, 29 Aug 2001 07:12:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQledg22349
	for mpls-outgoing; Wed, 29 Aug 2001 07: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 QQledg22337
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 07:11:32 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 QQledg22455
	for <mpls@uu.net>; Wed, 29 Aug 2001 07:11:30 GMT
Received: from smtp014.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp014.mail.yahoo.com [216.136.173.58])
	id QQledg25404
	for <mpls@uu.net>; Wed, 29 Aug 2001 07:11:29 GMT
Received: from 216-174-224-251.atgi.net (HELO METANOIA) (216.174.224.251)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Aug 2001 07:11:29 -0000
X-Apparently-From: <vsharma87@yahoo.com>
Reply-To: <v.sharma@ieee.org>
From: "Vishal Sharma" <vsharma87@yahoo.com>
To: "Jim Boyle" <jimpb@nc.rr.com>, "George Swallow" <swallow@cisco.com>
Cc: <mpls@UU.NET>, <vijay@cosinecom.com>
Subject: RE: Last call on recovery framework
Date: Wed, 29 Aug 2001 00:10:45 -0700
Message-ID: <MMECLKMDFPCEJFECIBCMAEMGCDAA.vsharma87@yahoo.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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <Pine.LNX.4.33.0108282019120.15337-100000@fido>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

I think this IP statement is incorrect and needs to either be
removed or modified. I do not think that there is any
specific statement on the page you reference that this IP
statement actually refers to. (We somehow put this in a long
time ago, probably erroneously, and it has stuck, so far.)

In fact, I need to ask the Chairs and/or ADs about which
IP statement (if any) we should put there. The only patents
that I am aware of that relate somewhat to the terminology
defined in this draft were filed earlier this year with the
US PTO by Tellabs. (They actually pertain to the Chang 
mechanism draft, and their only relationship to anything in
the framework draft is by way of the terminology.)
In this case, what are we obligated to do? Do we need any
statement, or is none needed?
(If Nortel has some patents that somehow relate to the 
material in this draft, I'll leave it to my Nortel co-authors
to comment.)

-Vishal

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle
Sent: Tuesday, August 28, 2001 5:23 PM
To: George Swallow
Cc: mpls@UU.NET; vijay@cosinecom.com
Subject: Re: Last call on recovery framework



I'm having trouble identifying the IP statement at

http://www.ietf.org/ipr.html

that section 7 (intellection property) references.

Can one of the authors provide a clarification?

Jim



On Tue, 21 Aug 2001, George Swallow wrote:

> This message begins a last call on
>
>       Framework for MPLS-based Recovery
>       <draft-ietf-mpls-recovery-frmwrk-02.txt>
>
> The last call ends on Sept 5 at midnight GMT.
>
> ...George
>
>
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-mpls@UU.NET  Wed Aug 29 05:40:43 2001
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 FAA18855
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 05:40:43 -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 QQledq00596;
	Wed, 29 Aug 2001 09:41:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQledq12863
	for mpls-outgoing; Wed, 29 Aug 2001 09:41:16 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 QQledq12836
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 09:41:12 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 QQledq01256
	for <mpls@UU.NET>; Wed, 29 Aug 2001 09:40:18 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQledq08943
	for <mpls@UU.NET>; Wed, 29 Aug 2001 09:40:17 GMT
Received: from multitech.co.in (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f7T9flu31278;
	Wed, 29 Aug 2001 15:11:47 +0530
Message-ID: <3B8CB98F.7B32C87B@multitech.co.in>
Date: Wed, 29 Aug 2001 15:14:47 +0530
From: abhay <abhay@multitech.co.in>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neelesh Dwivedi <neelesh@mercurykr.com>
CC: mpls@UU.NET, cheenu@alphion.com
Subject: Re: LSP ID in LSR MIB
X-Priority: 2 (High)
References: <007001c13042$b19e4940$160d85a5@mercurykr.com>
Content-Type: multipart/alternative;
 boundary="------------804C65AE0D16601A0B62DDA1"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------804C65AE0D16601A0B62DDA1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neelesh,

       With regards to your questions

       1)You can have the LSPID as an array of unsigned chars

        for example  192.168.1.10:1  where this is the LSPID

        The 192.168.1.10 is the source address and 1 is the local lspid.

        Similar relevance can be applied to RSVP piggyback.

       2)Piggyback is the Label mapping message for a pending label request message

         here you only update the label value returned by the signaling protocol

         Hope this helps,

         Regards,

         Abhay

Neelesh Dwivedi wrote:

> Hello,
> I have  few doubts related to the MPLS LSR MIB
> (draft-ietf-mpls-lsr-mib-07.txt).
>
> The Cross-Connect Table has an entry
>
>        mplsXCLspId                 MplsLSPID
>
>  This MplsLSPID is described in  draft-ietf-mpls-tc-mib-02.txt as
>
>  "An identifier that is assigned to each LSP and is used to uniquely
> identify
> it.  This is assigned at the head end of the LSP and can be used by all LSRs
> to identify this LSP.  This value is piggybacked by the signaling protocol
> when this LSP is signaled within the network.  This identifier can then be
> used at each LSR to identify which labels are being swapped to other
> labels for this LSP.  For IPv4 addresses this results in a 6-octet long
> cookie."
> SYNTAX        OCTET STRING (SIZE (0..31))
>
>  My questions are:
> a)  Is there any standard format for this unique identifier ? If not, then
> what can be the possible ways to assign it?
>
>  b) What do we mean by "piggybacking" this value by the signaling protocol?
> If it is to be advertised in some control message then where and how do
> we do it?
>
>  Regards,
> Neelesh.
>
>  Mercury Corporation
> New Delhi R&D Centre,
> Gurgaon, India.

--------------804C65AE0D16601A0B62DDA1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>Neelesh,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; With regards to your questions</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1)You can have the LSPID as an array of unsigned chars</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for example&nbsp; 192.168.1.10:1&nbsp; where this is the LSPID</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The 192.168.1.10 is the source address and 1 is the local lspid.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Similar relevance can be applied to RSVP piggyback.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2)Piggyback is the Label mapping message for a pending label request message</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; here you only update the label value returned by the signaling protocol</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope this helps,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Abhay</pre>

<p><br>Neelesh Dwivedi wrote:
<blockquote TYPE=CITE>Hello,
<br>I have&nbsp; few doubts related to the MPLS LSR MIB
<br>(draft-ietf-mpls-lsr-mib-07.txt).
<p>The Cross-Connect Table has an entry
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mplsXCLspId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MplsLSPID
<p>&nbsp;This MplsLSPID is described in&nbsp; draft-ietf-mpls-tc-mib-02.txt
as
<p>&nbsp;"An identifier that is assigned to each LSP and is used to uniquely
<br>identify
<br>it.&nbsp; This is assigned at the head end of the LSP and can be used
by all LSRs
<br>to identify this LSP.&nbsp; This value is piggybacked by the signaling
protocol
<br>when this LSP is signaled within the network.&nbsp; This identifier
can then be
<br>used at each LSR to identify which labels are being swapped to other
<br>labels for this LSP.&nbsp; For IPv4 addresses this results in a 6-octet
long
<br>cookie."
<br>SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCTET STRING (SIZE
(0..31))
<p>&nbsp;My questions are:
<br>a)&nbsp; Is there any standard format for this unique identifier ?
If not, then
<br>what can be the possible ways to assign it?
<p>&nbsp;b) What do we mean by "piggybacking" this value by the signaling
protocol?
<br>If it is to be advertised in some control message then where and how
do
<br>we do it?
<p>&nbsp;Regards,
<br>Neelesh.
<p>&nbsp;Mercury Corporation
<br>New Delhi R&amp;D Centre,
<br>Gurgaon, India.</blockquote>
</html>

--------------804C65AE0D16601A0B62DDA1--



From owner-mpls@UU.NET  Wed Aug 29 06:10:58 2001
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 GAA19143
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 06:10:58 -0400 (EDT)
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 QQleds02689;
	Wed, 29 Aug 2001 10:12:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleds03794
	for mpls-outgoing; Wed, 29 Aug 2001 10:11:33 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 QQleds03776
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 10:11: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 QQleds16694
	for <mpls@UU.NET>; Wed, 29 Aug 2001 10:10:29 GMT
Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQleds25513
	for <mpls@UU.NET>; Wed, 29 Aug 2001 10:10:15 GMT
Received: from neelesh ([165.133.13.22])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id PAA11630;
	Wed, 29 Aug 2001 15:30:18 -0600 (GMT)
Message-ID: <011501c13072$98507820$160d85a5@mercurykr.com>
Reply-To: "Neelesh Dwivedi" <neelesh@mercurykr.com>
From: "Neelesh Dwivedi" <neelesh@mercurykr.com>
To: "abhay" <abhay@multitech.co.in>
Cc: <mpls@UU.NET>, <cheenu@alphion.com>
References: <007001c13042$b19e4940$160d85a5@mercurykr.com> <3B8CB98F.7B32C87B@multitech.co.in>
Subject: Re: LSP ID in LSR MIB
Date: Wed, 29 Aug 2001 15:38:22 +0530
Organization: Mercury Corporation
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Abhay,
Thanks for your reply.

But as the description of the MplsLSPID in  draft-ietf-mpls-tc-mib-02.txt
says:
"This is assigned at the head end of the LSP and can be used by all LSRs
to identify this LSP."
Now if we consider Head-End to be the Ingress LSR, then how is it going to
inform the other LSRs about the LSPID? The point is how are we going to
piggyback this
LSPID on any Signaling Protocol control message  ?

Neelesh.
Mercury Corporation
New Delhi R&D Centre,
Gurgaon, India.

----- Original Message -----
From: abhay
To: Neelesh Dwivedi
Cc: mpls@UU.NET ; cheenu@alphion.com
Sent: Wednesday, August 29, 2001 3:14 PM
Subject: Re: LSP ID in LSR MIB


Neelesh,
       With regards to your questions
       1)You can have the LSPID as an array of unsigned chars
        for example  192.168.1.10:1  where this is the LSPID
        The 192.168.1.10 is the source address and 1 is the local lspid.
        Similar relevance can be applied to RSVP piggyback.
       2)Piggyback is the Label mapping message for a pending label request
message
         here you only update the label value returned by the signaling
protocol
         Hope this helps,
         Regards,
         Abhay

Neelesh Dwivedi wrote:
Hello,
I have  few doubts related to the MPLS LSR MIB
(draft-ietf-mpls-lsr-mib-07.txt).
The Cross-Connect Table has an entry
       mplsXCLspId                 MplsLSPID
 This MplsLSPID is described in  draft-ietf-mpls-tc-mib-02.txt as
 "An identifier that is assigned to each LSP and is used to uniquely
identify
it.  This is assigned at the head end of the LSP and can be used by all LSRs
to identify this LSP.  This value is piggybacked by the signaling protocol
when this LSP is signaled within the network.  This identifier can then be
used at each LSR to identify which labels are being swapped to other
labels for this LSP.  For IPv4 addresses this results in a 6-octet long
cookie."
SYNTAX        OCTET STRING (SIZE (0..31))
 My questions are:
a)  Is there any standard format for this unique identifier ? If not, then
what can be the possible ways to assign it?
 b) What do we mean by "piggybacking" this value by the signaling protocol?
If it is to be advertised in some control message then where and how do
we do it?
 Regards,
Neelesh.
 Mercury Corporation
New Delhi R&D Centre,
Gurgaon, India.



From owner-mpls@UU.NET  Wed Aug 29 06:12:13 2001
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 GAA19161
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 06:12:12 -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 QQleds22163;
	Wed, 29 Aug 2001 10:13:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleds03987
	for mpls-outgoing; Wed, 29 Aug 2001 10:12:54 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 QQleds03965
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 10:12:40 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 QQleds06012
	for <mpls@UU.NET>; Wed, 29 Aug 2001 10:11:30 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQleds28036
	for <mpls@UU.NET>; Wed, 29 Aug 2001 10:11:32 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id GAA05133; Wed, 29 Aug 2001 06:11:56 -0400
Date: Wed, 29 Aug 2001 06:11:54 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Subject: Label Statistics at the time of LSP switching
Message-ID: <Pine.SUN.3.96.1010829060721.4345A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I have a doubt regarding the MPLS input and output label statistics. 
Usually an LSP can be denoted by input:output label & interfaces (simplest
case)
When LSP switching occurs, the backup LSP identified by the new
input:output label & interfaces.
For these two cases (working and bakcup LSP) there will be different sets
of statistics counters.
What is done with the working statistics counters, when the LSP is
switched. Are they restored when the LSP is restored or they are reset and
statistics is referred by the new statistics counters(associated with
backup LSP).
regards,
Hemant



From owner-mpls@UU.NET  Wed Aug 29 07:23:16 2001
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 HAA20272
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 07:23: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 QQledx13388;
	Wed, 29 Aug 2001 11:24:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQledx29118
	for mpls-outgoing; Wed, 29 Aug 2001 11:23: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 QQledx29112
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 11:23:53 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 QQledx02531
	for <mpls@uu.net>; Wed, 29 Aug 2001 11:23:42 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQledx24300
	for <mpls@uu.net>; Wed, 29 Aug 2001 11:23:44 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09128 for mpls@uu.net; Wed, 29 Aug 2001 07:23:40 -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 QQledx29086
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 11:23:23 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 QQledx00814
	for <mpls@uu.net>; Wed, 29 Aug 2001 11:22:14 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 QQledx24019
	for <mpls@uu.net>; Wed, 29 Aug 2001 11:22:16 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20135;
	Wed, 29 Aug 2001 07:20:54 -0400 (EDT)
Message-Id: <200108291120.HAA20135@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-koleyni-pwe3-atm-over-mpls-02.txt
Date: Wed, 29 Aug 2001 07:20:54 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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


	Title		: Requirements and framework for ATM network   
                          interworking over MPLS
	Author(s)	: G. Koleyni et al.
	Filename	: draft-koleyni-pwe3-atm-over-mpls-02.txt
	Pages		: 22
	Date		: 28-Aug-01
	
Generic requirements  for Pseudo-Wire  Emulation Edge-to-Edge  (PWE3) 
have  been  described   in  [2].  This   draft  lists  ATM   specific 
requirements and  provides  encapsulation  format and  semantics  for 
connecting ATM edge networks through a core packet network using  IP, 
L2TP or MPLS. This  basic application of ATM interworking will  allow 
ATM service providers  to take advantage  of new technologies in  the 
core to provide ATM multi-services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-koleyni-pwe3-atm-over-mpls-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-koleyni-pwe3-atm-over-mpls-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-koleyni-pwe3-atm-over-mpls-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:	<20010828123545.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-koleyni-pwe3-atm-over-mpls-02.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Wed Aug 29 08:32:24 2001
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 IAA23323
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 08:32:24 -0400 (EDT)
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 QQleec02961;
	Wed, 29 Aug 2001 12:33:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleec23652
	for mpls-outgoing; Wed, 29 Aug 2001 12:32: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 QQleec23638
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 12:32: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 QQleec11112
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:31:59 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQleec17623
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:32:00 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id IAA19973; Wed, 29 Aug 2001 08:32:25 -0400
Date: Wed, 29 Aug 2001 08:32:25 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
Reply-To: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Subject: Label Statistics at the time of LSP switching
Message-ID: <Pine.SUN.3.96.1010829083107.18359A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I have a doubt regarding the MPLS input and output label statistics.
Usually an LSP can be denoted by input:output label & interfaces (simplest
case)
When LSP switching occurs, the backup LSP identified by the new
input:output label & interfaces.
For these two cases (working and bakcup LSP) there will be different sets
of statistics counters.
What is done with the working statistics counters, when the LSP is
switched. Are they restored when the LSP is restored or they are reset and
statistics is referred by the new statistics counters(associated with
backup LSP).
regards,
Hemant



From owner-mpls@UU.NET  Wed Aug 29 08:39:49 2001
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 IAA23631
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 08:39:49 -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 QQleec29368;
	Wed, 29 Aug 2001 12:40:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleec24306
	for mpls-outgoing; Wed, 29 Aug 2001 12:40: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 QQleec24297
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 12:40: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 QQleec01904
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:40:03 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQleec24752
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:40:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA13658 for mpls@uu.net; Wed, 29 Aug 2001 08:40: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 QQleec24251
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 12:39:30 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 QQleec29155
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:39:27 GMT
Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.dataconnection.com [192.91.191.8])
	id QQleec12077
	for <mpls@uu.net>; Wed, 29 Aug 2001 12:39:29 GMT
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <QQQSPNYQ>; Wed, 29 Aug 2001 13:39:11 +0100
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8135DD6@baker.datcon.co.uk>
From: Edward Harrison <eph@dataconnection.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question about Interface_ID object in draft-ietf-generalized-sign
	aling-05.txt
Date: Wed, 29 Aug 2001 13:39:17 +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

Hi,

I have a question about the new section on Interface Identification in
draft-ietf-mpls-generalized-signaling-05.txt (section 9.1).

Whilst the draft specifies that the choice of data interface is indicated by
the upstream node, it is not clear whether the IP Address and Interface ID
that the upstream node puts into the Interface_ID object should be local
numbers or remote numbers.

Is the intention that the upstream node can fill the object in using either
local or remote numbering, or is the intention that one or another is used
(and is the same scheme used for all types of the object)?

Thanks,

Ed

------------------
Edward Harrison  mailto:eph@dataconnection.com
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468



From owner-mpls@UU.NET  Wed Aug 29 08:50:43 2001
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 IAA24184
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 08:50:42 -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 QQleed14271;
	Wed, 29 Aug 2001 12:51:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleed25571
	for mpls-outgoing; Wed, 29 Aug 2001 12:51: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 QQleed25508
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 12:51:11 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 QQleed22631
	for <mpls@UU.NET>; Wed, 29 Aug 2001 12:49:54 GMT
Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQleed12468
	for <mpls@UU.NET>; Wed, 29 Aug 2001 12:49:55 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 f7TCnn041005;
	Wed, 29 Aug 2001 05:49:50 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200108291249.f7TCnn041005@merlot.juniper.net>
To: Edward Harrison <eph@dataconnection.com>
cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: Question about Interface_ID object in draft-ietf-generalized-sign aling-05.txt 
In-Reply-To: Your message of "Wed, 29 Aug 2001 13:39:17 BST."
             <53F74F5A7B94D511841C00B0D0AB16F8135DD6@baker.datcon.co.uk> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8300.999089389.1@juniper.net>
Date: Wed, 29 Aug 2001 05:49:49 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Ed,

> I have a question about the new section on Interface Identification in
> draft-ietf-mpls-generalized-signaling-05.txt (section 9.1).
> 
> Whilst the draft specifies that the choice of data interface is indicated by
> the upstream node, it is not clear whether the IP Address and Interface ID
> that the upstream node puts into the Interface_ID object should be local
> numbers or remote numbers.
> 
> Is the intention that the upstream node can fill the object in using either
> local or remote numbering, or is the intention that one or another is used
> (and is the same scheme used for all types of the object)?

The intention is that the upstream node should use the local numbers.
It would be good to add some text to make this point clear...

Yakov.


From owner-mpls@UU.NET  Wed Aug 29 09:10:09 2001
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 JAA25077
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 09:10:09 -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 QQleee14488;
	Wed, 29 Aug 2001 13:11:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleee15435
	for mpls-outgoing; Wed, 29 Aug 2001 13:10: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 QQleee15420
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 13:10:33 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 QQleee16140
	for <mpls@uu.net>; Wed, 29 Aug 2001 13:10:13 GMT
From: SSafety999@aol.com
Received: from imo-r06.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-r06.mx.aol.com [152.163.225.102])
	id QQleee11300
	for <mpls@uu.net>; Wed, 29 Aug 2001 13:10:15 GMT
Received: from SSafety999@aol.com
	by imo-r06.mx.aol.com (mail_out_v31_r1.4.) id 1.144.b72b84 (4426);
	Wed, 29 Aug 2001 09:10:09 -0400 (EDT)
Message-ID: <144.b72b84.28be43b0@aol.com>
Date: Wed, 29 Aug 2001 09:10:08 EDT
Subject: Re: ATM over MPLS
To: mpls@UU.NET
CC: jputnam@okstate.edu, SSafety999@aol.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_144.b72b84.28be43b0_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10536
Sender: owner-mpls@UU.NET
Precedence: bulk


--part1_144.b72b84.28be43b0_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

MPLS Experts,

Has anyone tried MPLS over ATM established wireless network?  Is it possible? 
 I can see the advantages, but what would be some of the disadvantages.  
Should MPLS be considered as the base for 4G wireless networks?

Thanks in advance for any comments

Al Putnam

--part1_144.b72b84.28be43b0_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=2>MPLS Experts,
<BR>
<BR>Has anyone tried MPLS over ATM established wireless network? &nbsp;Is it possible? 
<BR>&nbsp;I can see the advantages, but what would be some of the disadvantages. &nbsp;
<BR>Should MPLS be considered as the base for 4G wireless networks?
<BR>
<BR>Thanks in advance for any comments
<BR>
<BR>Al Putnam</FONT></HTML>

--part1_144.b72b84.28be43b0_boundary--


From owner-mpls@UU.NET  Wed Aug 29 09:35:20 2001
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 JAA26265
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 09:35:20 -0400 (EDT)
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 QQleeg28050;
	Wed, 29 Aug 2001 13:36:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleeg18071
	for mpls-outgoing; Wed, 29 Aug 2001 13:35: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 QQleeg18061
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 13:35: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 QQleeg06195
	for <mpls@UU.NET>; Wed, 29 Aug 2001 13:35:09 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 QQleeg12665
	for <mpls@UU.NET>; Wed, 29 Aug 2001 13:35:11 GMT
Message-ID: <3B8CEF8B.94618B76@sandburst.com>
Date: Wed, 29 Aug 2001 09:35:07 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: John Drake <jdrake@calient.net>
Cc: "'Guangzhi Li'" <gli@research.att.com>, Fong Liaw <fliaw@zaffire.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <A1AFE5CF886C5D439494D9D5DE84EEF373729F@radiant.chromisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

John,

    Even in processing Resv messages serially, it is quite reasonable (if not
actually required) for an implementation to want to retrieve the PSB.  It is
conceivable that the delta in such a case for checking outstanding Path
requests is not that great.  Moreover, how much work is node 2 going to
have to go through to ascertain that - as Fong had implied - the completion
of LSP A means that LSP B does not have to be completed?  It seems to me
that - once again - it is be left open to the implementer to determine where
the work gets done in this case.

    If options may be ugly, ambiguity can be hideous.

--
Eric Gray

You wrote:

> What this requires is an RSVP implementation in which the Resv processing
> checks to see whether there is any outstanding  Path request specifying a
> upstream label that is tied to the downstream label received in the Resv,
> and if there is to tear down the LSP that was just established with the
> Resv, as opposed to an implementation that would process Resvs serially.  I
> don't know how sensible this may or may not be.
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Tuesday, August 28, 2001 6:52 AM
> To: John Drake
> Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> John:
>
> No. Node 1 may send out the PATH message to node 2 as the same time as node
> 2
> sends out the RESV message to node 1. If the contention resolution is a
> local
> decision or policy implementation, node 1 may decide to fail LSP A since
> node 1
> has the higher node ID. Then both LSP A and LSP B are failed. This is not
> what
> we want. So, a consistent decision is required between these two nodes.
>
> Thanks,
>
> -- Guangzhi
>
> John Drake wrote:
>
> > Guangzhi,
> >
> > In Fong's note she indicated that the contention can be completely
> resolved
> > by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> > node 1 is told the result of node 2's decision making process.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:gli@research.att.com]
> > Sent: Monday, August 27, 2001 2:13 PM
> > To: Fong Liaw
> > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > Fong:
> >
> > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
> both
> > uni-directional and bi-directional together and uses the same port pool,
> > then a PATH and a RESV may cross each other. I think that it should be
> legal
> > based on current GMPLS specification. IF this scenario happens, GMPLS has
> to
> > provide one standard way to handle this situation.
> >
> > Your suggestion works but it still involves the implementations of node 1
> > and node 2. Both nodes should interperate the same way. That means RESV
> > message always wins PATH message. No problem.
> >
> > I assume that the I/O ports of bi-didrectional LSP are paired together,
> then
> > suggested_label = upstream_label and suggested_label is hard binding. Note
> > that contention happens in either this case or lack of resource. If
> > suggested_label could be different upstream_label, no contention problem
> at
> > all.
> >
> > -- Guangzhi
> >
> > Fong Liaw wrote:
> >
> > > Guangzhi
> > >
> > > The GMPLS contention resolution applies to the scenario
> > > that two Path messages cross each other.  Your example
> > > have Resv and Path cross each other so the rule in the
> > > contention resolution does not directly apply and is more
> > > of a policy and implementation issue.
> > >
> > > Here is one possible solution and is within the
> > > interpretation of the draft, IMHO. here it is.
> > > If node 2 already sends Resv to node 1, LSP A should
> > > be considered established and therefore LSP B should
> > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > LSP A is still in establishing mode and node 2 can resolve
> > > the contention internally by rejecting LSP A or LSP B, based
> > > on their setting up priority or it can change LSP A's
> > > label and reprogram the cross-connect without ever noticed
> > > by any external node.  In both cases, node 2 is the one
> > > that resolve this contention.  Hope this helps.
> > >
> > > p.s. I think you meant to use LABEL_SET since
> > > Suggested label is a suggestion, not a hard binding.
> > >
> > > Regards
> > > -Fong
> > >
> > > >  -----Original Message-----
> > > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > > >  Cc: gli@research.att.com
> > > >  Subject: Question on GMPLS contentions resolution
> > > >
> > > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > >  During GMPLS last call, I posted the same question on the
> > > >  mailing list
> > > >  without response. Please somebody spend a little time and
> > > >  check with the
> > > >  following example? Something seems not clear when the current GMPLS
> > > >  contention resution schemes are applied on a framework with both
> > > >  bi-directional and uni-directional LSPs. Your clarification
> > > >  is very much
> > > >  appreciated.
> > > >
> > > >  Sincerely,
> > > >
> > > >  Guangzhi
> > > >
> > > >  -------------------------------------------------------------
> > > >  -------------------------------------
> > > >
> > > >  The issue arises because contention is resolved between
> > > >  bi-directional
> > > >  LSPs by the node with the higher node index while for uni-directional
> > > >  LSPs, contention is resolved by the downstream node. Consider the
> > > >  following example of two nodes with paired, bi-directional interfaces
> > > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > > >  transmitter port and
> > > >  label 2 for the receiver port; node 2 uses label 4 for the
> > > >  transmitter
> > > >  port and label 3 for the receiver port.   We assume that a
> > > >  bi-directional LSP requires a single I/O interface.
> > > >
> > > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > > >  to node 2,
> > > >  with the uni-directional LSP setup request arriving marginally before
> > > >  the bi-directional LSP.  LSP A does not use a suggested
> > > >  label, and thus
> > > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > > >  contention resolution rule for bi-directional LSPs) that LSP
> > > >  B wins the
> > > >  contention and thus label 3 is assigned to LSP B.  Thus
> > > >  label 1 at node
> > > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > > >  LSPs have "won" the contention.
> > > >
> > > >



From owner-mpls@UU.NET  Wed Aug 29 09:46:00 2001
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 JAA26710
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 09:46:00 -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 QQleeh27388;
	Wed, 29 Aug 2001 13:47:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleeh19093
	for mpls-outgoing; Wed, 29 Aug 2001 13:46: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 QQleeh19084
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 13:46:36 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 QQleeh25607
	for <mpls@UU.NET>; Wed, 29 Aug 2001 13:45:22 GMT
Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-blue.research.att.com [135.207.30.102])
	id QQleeh18339
	for <mpls@UU.NET>; Wed, 29 Aug 2001 13:45:21 GMT
Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 8A4A84CE67; Wed, 29 Aug 2001 09:45:17 -0400 (EDT)
Received: from research.att.com (pc-summer-gli.research.att.com [135.207.26.95])
	by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA01194;
	Wed, 29 Aug 2001 09:45:16 -0400 (EDT)
Message-ID: <3B8CF354.89D8B639@research.att.com>
Date: Wed, 29 Aug 2001 09:51:16 -0400
From: Guangzhi Li <gli@research.att.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Drake <jdrake@calient.net>
Cc: Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution
References: <A1AFE5CF886C5D439494D9D5DE84EEF373729F@radiant.chromisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fong:

What is your opinion? Is this a simple "local policy/implementation" issue or
both node1 and node2 are required to interperate the same way?

In your first email, you proposed one possible solution (Resv message wins Path
message always). Is this solution simply a "local decision" or global
requirement?

Also how about race condition between uni-PATH and Bi-PATH?

Your opinion is very much appreciated. Thanks,

-- Guangzhi

John Drake wrote:

> What this requires is an RSVP implementation in which the Resv processing
> checks to see whether there is any outstanding  Path request specifying a
> upstream label that is tied to the downstream label received in the Resv,
> and if there is to tear down the LSP that was just established with the
> Resv, as opposed to an implementation that would process Resvs serially.  I
> don't know how sensible this may or may not be.
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Tuesday, August 28, 2001 6:52 AM
> To: John Drake
> Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> John:
>
> No. Node 1 may send out the PATH message to node 2 as the same time as node
> 2
> sends out the RESV message to node 1. If the contention resolution is a
> local
> decision or policy implementation, node 1 may decide to fail LSP A since
> node 1
> has the higher node ID. Then both LSP A and LSP B are failed. This is not
> what
> we want. So, a consistent decision is required between these two nodes.
>
> Thanks,
>
> -- Guangzhi
>
> John Drake wrote:
>
> > Guangzhi,
> >
> > In Fong's note she indicated that the contention can be completely
> resolved
> > by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> > node 1 is told the result of node 2's decision making process.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Guangzhi Li [mailto:gli@research.att.com]
> > Sent: Monday, August 27, 2001 2:13 PM
> > To: Fong Liaw
> > Cc: ccamp@ops.ietf.org; mpls@UU.NET
> > Subject: Re: Question on GMPLS contentions resolution
> >
> > Fong:
> >
> > Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
> both
> > uni-directional and bi-directional together and uses the same port pool,
> > then a PATH and a RESV may cross each other. I think that it should be
> legal
> > based on current GMPLS specification. IF this scenario happens, GMPLS has
> to
> > provide one standard way to handle this situation.
> >
> > Your suggestion works but it still involves the implementations of node 1
> > and node 2. Both nodes should interperate the same way. That means RESV
> > message always wins PATH message. No problem.
> >
> > I assume that the I/O ports of bi-didrectional LSP are paired together,
> then
> > suggested_label = upstream_label and suggested_label is hard binding. Note
> > that contention happens in either this case or lack of resource. If
> > suggested_label could be different upstream_label, no contention problem
> at
> > all.
> >
> > -- Guangzhi
> >
> > Fong Liaw wrote:
> >
> > > Guangzhi
> > >
> > > The GMPLS contention resolution applies to the scenario
> > > that two Path messages cross each other.  Your example
> > > have Resv and Path cross each other so the rule in the
> > > contention resolution does not directly apply and is more
> > > of a policy and implementation issue.
> > >
> > > Here is one possible solution and is within the
> > > interpretation of the draft, IMHO. here it is.
> > > If node 2 already sends Resv to node 1, LSP A should
> > > be considered established and therefore LSP B should
> > > be rejected by node 2. If node 2 hasn't sent back Resv,
> > > LSP A is still in establishing mode and node 2 can resolve
> > > the contention internally by rejecting LSP A or LSP B, based
> > > on their setting up priority or it can change LSP A's
> > > label and reprogram the cross-connect without ever noticed
> > > by any external node.  In both cases, node 2 is the one
> > > that resolve this contention.  Hope this helps.
> > >
> > > p.s. I think you meant to use LABEL_SET since
> > > Suggested label is a suggestion, not a hard binding.
> > >
> > > Regards
> > > -Fong
> > >
> > > >  -----Original Message-----
> > > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > > >  Sent: Monday, August 27, 2001 6:17 AM
> > > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > > >  Cc: gli@research.att.com
> > > >  Subject: Question on GMPLS contentions resolution
> > > >
> > > >
> > > >  Dear GMPLS authors and all experts:
> > > >
> > > >  During GMPLS last call, I posted the same question on the
> > > >  mailing list
> > > >  without response. Please somebody spend a little time and
> > > >  check with the
> > > >  following example? Something seems not clear when the current GMPLS
> > > >  contention resution schemes are applied on a framework with both
> > > >  bi-directional and uni-directional LSPs. Your clarification
> > > >  is very much
> > > >  appreciated.
> > > >
> > > >  Sincerely,
> > > >
> > > >  Guangzhi
> > > >
> > > >  -------------------------------------------------------------
> > > >  -------------------------------------
> > > >
> > > >  The issue arises because contention is resolved between
> > > >  bi-directional
> > > >  LSPs by the node with the higher node index while for uni-directional
> > > >  LSPs, contention is resolved by the downstream node. Consider the
> > > >  following example of two nodes with paired, bi-directional interfaces
> > > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > > >  transmitter port and
> > > >  label 2 for the receiver port; node 2 uses label 4 for the
> > > >  transmitter
> > > >  port and label 3 for the receiver port.   We assume that a
> > > >  bi-directional LSP requires a single I/O interface.
> > > >
> > > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > > >  to node 2,
> > > >  with the uni-directional LSP setup request arriving marginally before
> > > >  the bi-directional LSP.  LSP A does not use a suggested
> > > >  label, and thus
> > > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > > >  contention resolution rule for bi-directional LSPs) that LSP
> > > >  B wins the
> > > >  contention and thus label 3 is assigned to LSP B.  Thus
> > > >  label 1 at node
> > > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > > >  LSPs have "won" the contention.
> > > >
> > > >



From owner-mpls@UU.NET  Wed Aug 29 11:09:30 2001
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 LAA00467
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 11:09:30 -0400 (EDT)
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 QQleem29305;
	Wed, 29 Aug 2001 15:10:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleem02306
	for mpls-outgoing; Wed, 29 Aug 2001 15:10:00 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 QQleem02282
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 15:09:59 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 QQleem26524
	for <mpls@uu.net>; Wed, 29 Aug 2001 15:09:30 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQleem27849
	for <mpls@uu.net>; Wed, 29 Aug 2001 15:09:32 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA25303 for mpls@uu.net; Wed, 29 Aug 2001 11:09:28 -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 QQleem02202
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 15:09:13 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 QQleem10357
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:09:05 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQleem10530
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:09:03 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24734; Wed, 29 Aug 2001 11:09:04 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-186.cisco.com [161.44.134.186])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AHD06745;
	Wed, 29 Aug 2001 11:09:03 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010829110807.035be930@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 29 Aug 2001 11:10:25 -0700
To: "Sharma, Prem" <p_sharma@trillium.com>, cheenu@alphion.com
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: FW: some queries on mpls-ftn-mib-03
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <F1CE15E08172D4119247009027AE9D5009AE2E21@FMSMSX37>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Did you not get our responses?

>Re-sending the mail I sent few days back. Authors, pls. respond.
>
>Prem
>
> >  -----Original Message-----
> > From:         Sharma, Prem
> > Sent: Thursday, August 23, 2001 1:11 PM
> > To:   'mpls@uu.net'
> > Subject:      some queries on mpls-ftn-mib-03
> >
> > Hi,
> >
> > I was trying to see if some consensus has been reached on the following
> > outstanding issues w.r.t. mpls-ftn-mib:
> > *     Keeping mapping of DSCP values to LSPs/Tunnels

         This exists in the current version.

> > *     Use of CIDR prefixes instead of Address ranges.

         This is supported by the existing MIB in that
you can use address prefix ranges.

> > *     Keeping IPv6 flow label also.

         There were no requests other than yours to add
this, so there was no consensus to add it.

> > Aforementioned pertain to the mplsFTNEntry in the MIB.


> > One more comment: I'll be better if the relation of this draft with
> > diffserv mib could be clarified too.

         Yes, we agreed to clarify the text in the MIB for this.
I also believe that text in the MIB exists which notes that
other packet marking/queuing can take place before the
FTN MIB is inserted into the processing chain.

         --Tom


> >
> > Thanks.
> > Prem



From owner-mpls@UU.NET  Wed Aug 29 11:19:22 2001
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 LAA00898
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 11:19:21 -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 QQleen14835;
	Wed, 29 Aug 2001 15:20:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleen03432
	for mpls-outgoing; Wed, 29 Aug 2001 15:19:59 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 QQleen03423
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 15:19:51 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 QQleen03998
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:18:09 GMT
Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQleen10623
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:18:10 GMT
Received: from mail1.tellium.com (mail1 [151.198.92.140])
	by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f7TFErk28844;
	Wed, 29 Aug 2001 11:14:54 -0400 (EDT)
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <RTXTA2SM>; Wed, 29 Aug 2001 11:17:41 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D022040402088951@mail1.tellium.com>
From: Hang Liu <hliu@tellium.com>
To: "'Guangzhi Li'" <gli@research.att.com>,
        Karthik Subramanian
	 <karthik@calient.net>,
        "'eric.gray@sandburst.com'"
	 <eric.gray@sandburst.com>
Cc: Hang Liu <hliu@tellium.com>, John Drake <jdrake@calient.net>,
        Fong Liaw <fliaw@zaffire.com>, ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Wed, 29 Aug 2001 11:17:39 -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

Hi.

One observation is 

When the I/O ports are paired, the contention between a uni-directional LSP
and a bi-directional LSP is similar to the contention of two bi-directional
LSPs. When a uni-directional LSP wants a label (I am not sure how common a
uni-directional LSP is needed in the case of paired I/O), it actually
contends that I/O pair with the bi-directional LSP.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 7:45 PM
To: Karthik Subramanian
Cc: 'Hang Liu'; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


Karthik:

I understand your argument. But
(1) It it legal not to suggest a label in PATH for a uni-directional LSP but
to
suggest a label for a bi-directional LSP especially I/O ports are paired.
(2) If this is too weak, then assume another scenario: the PATH message of
LSP A
suggested a label but was rejected by N2 due to race condition of other
LSPs,
(such as a bi-directional LSP C from N2 to N1), then it is up to the RESV
message of LSP A to assign the label. At this time, the condition happens
between LSP A and LSP B.

You may say why LSP A is so unlucky and it may not happen two race
conditions in
a short time. But it may although the probability is very small :=)

If you draw pictures, you may find other scenarios.

-- Guangzhi


Karthik Subramanian wrote:

> Guangzhi,
> Let me try to understand what you are suggesting here. Please correct me
if
> I'm wrong.
>
>                    m------------>n
>                N1                   N2
>                    o<------------p
>
> m,n,o,p are the labels for a bidirectional port.
> LSP A is an uni-directional LSP whose direction is from N1 to N2
> LSP B is a bi-directional LSP whose direction is from N1 to N2.
>
> The sequence of operations is
>
> 1. N1 suggests 'n' for LSP A.
> 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve
> 'n' yet.
> 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to
> N1.
>    Simultaneously, for LSP B, N1 allocates 'o' as upstream label,
>        suggests 'n' for the forward direction and forwards the PATH.
>
> The problem is caused due to N1 suggesting the same label 'n' for 2 lsps.
> With regard to suggested labels you can take 2 approaches.
>
> 1. Suggested Label is reserved by the upstream node when the PATH is
> forwarded:
>       In this case, the problem won't arise, since during step 1, the link
> (m,n) is reserved and hence for LSP B, this port is unavailable (since the
> I/O ports of a bi-directional LSP are paired).
>
> 2. Suggested Label is NOT reserved by the upstream node until RESV comes:
>       In this case, during step 3, you are contradicting yourself by
making
> the cross-connect in N1 and hence reserving the port. I understand that
the
> I/O port pairing for bi-directional lsp might be a hardware restriction,
but
> its a contradiction nonetheless.
>
> You need to decide which approach to take and no violations must be made.
> The first approach seems logical to me.
>
> Karthik
>
> > From: Guangzhi Li [mailto:gli@research.att.com]
> >
> > I did not make it clear. I assume that the I/O ports of
> > Bi-directional LSP
> > are
> > paired. After node 1 configured the cross-connect with the
> > upstream label
> > (of course
> > suggested label) for LSP B,  node 1 received the uni-directional RESV
> > message for
> > LSP A, is it obviously defined in GMPLS that node 1 should
> > accept LSP A and
> > give up
> > LSP B or simply is it a local decision/policy implementation?
> >
> > -- Guangzhi
> >
> > Guangzhi Li wrote:
> >
> > > Hang:
> > >
> > > NO. The PATH message is bi-directional and the RESV is
> > uni-directional. If
> > there
> > > is a contention,  the contention happens with LSP A and the
> > upstream label
> > of
> > > LSP B.
> > >
> > > In your suggestion, you used IF. IF GMPLS specifies a
> > consisten way to
> > resolve
> > > it, such as Resv wins Path message in all cases, there is
> > no problem. A
> > simply
> > > local decision is NOT enough.
> > >
> > > Please draw pictures and apply current GMPLS contention
> > resolution schemes
> > ONLY.
> > > You will see something needs to be fixed.
> > >
> > > Guangzhi


From owner-mpls@UU.NET  Wed Aug 29 11:29:17 2001
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 LAA01220
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 11:29:16 -0400 (EDT)
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 QQleeo02463;
	Wed, 29 Aug 2001 15:30:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleeo04208
	for mpls-outgoing; Wed, 29 Aug 2001 15:30: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 QQleeo04194
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 15:30:00 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 QQleen23105
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:29:32 GMT
Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radiant.calient.net [63.102.55.206])
	id QQleen00553
	for <mpls@UU.NET>; Wed, 29 Aug 2001 15:29:34 GMT
Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <RJNZ7QWD>; Wed, 29 Aug 2001 08:29:31 -0700
Message-ID: <A1AFE5CF886C5D439494D9D5DE84EEF37372A3@radiant.chromisys.com>
From: John Drake <jdrake@calient.net>
To: "'Hang Liu'" <hliu@tellium.com>, "'Guangzhi Li'" <gli@research.att.com>,
        Karthik Subramanian <karthik@calient.net>,
        "'eric.gray@sandburst.com'"
	 <eric.gray@sandburst.com>
Cc: John Drake <jdrake@calient.net>, Fong Liaw <fliaw@zaffire.com>,
        ccamp@ops.ietf.org, mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution
Date: Wed, 29 Aug 2001 08:29:31 -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

I think this is Guangzhi's #7, which he indicated could be derived from the
existing text.  (I wasn't sure that it could.)  The correct resolution may
be to indicate that a Resv always beats a Path and that for two Paths, the
higher node always wins?

----Original Message-----
From: Hang Liu [mailto:hliu@tellium.com]
Sent: Wednesday, August 29, 2001 8:18 AM
To: 'Guangzhi Li'; Karthik Subramanian; 'eric.gray@sandburst.com'
Cc: Hang Liu; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: Question on GMPLS contentions resolution


Hi.

One observation is 

When the I/O ports are paired, the contention between a uni-directional LSP
and a bi-directional LSP is similar to the contention of two bi-directional
LSPs. When a uni-directional LSP wants a label (I am not sure how common a
uni-directional LSP is needed in the case of paired I/O), it actually
contends that I/O pair with the bi-directional LSP.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 7:45 PM
To: Karthik Subramanian
Cc: 'Hang Liu'; John Drake; Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


Karthik:

I understand your argument. But
(1) It it legal not to suggest a label in PATH for a uni-directional LSP but
to
suggest a label for a bi-directional LSP especially I/O ports are paired.
(2) If this is too weak, then assume another scenario: the PATH message of
LSP A
suggested a label but was rejected by N2 due to race condition of other
LSPs,
(such as a bi-directional LSP C from N2 to N1), then it is up to the RESV
message of LSP A to assign the label. At this time, the condition happens
between LSP A and LSP B.

You may say why LSP A is so unlucky and it may not happen two race
conditions in
a short time. But it may although the probability is very small :=)

If you draw pictures, you may find other scenarios.

-- Guangzhi


Karthik Subramanian wrote:

> Guangzhi,
> Let me try to understand what you are suggesting here. Please correct me
if
> I'm wrong.
>
>                    m------------>n
>                N1                   N2
>                    o<------------p
>
> m,n,o,p are the labels for a bidirectional port.
> LSP A is an uni-directional LSP whose direction is from N1 to N2
> LSP B is a bi-directional LSP whose direction is from N1 to N2.
>
> The sequence of operations is
>
> 1. N1 suggests 'n' for LSP A.
> 2. N2 accepts 'n' for LSP A and forwards it downstream. N2 doesn't reserve
> 'n' yet.
> 3. N2 gets the RESV for LSP A, reserves the link (m,n) and forwards it to
> N1.
>    Simultaneously, for LSP B, N1 allocates 'o' as upstream label,
>        suggests 'n' for the forward direction and forwards the PATH.
>
> The problem is caused due to N1 suggesting the same label 'n' for 2 lsps.
> With regard to suggested labels you can take 2 approaches.
>
> 1. Suggested Label is reserved by the upstream node when the PATH is
> forwarded:
>       In this case, the problem won't arise, since during step 1, the link
> (m,n) is reserved and hence for LSP B, this port is unavailable (since the
> I/O ports of a bi-directional LSP are paired).
>
> 2. Suggested Label is NOT reserved by the upstream node until RESV comes:
>       In this case, during step 3, you are contradicting yourself by
making
> the cross-connect in N1 and hence reserving the port. I understand that
the
> I/O port pairing for bi-directional lsp might be a hardware restriction,
but
> its a contradiction nonetheless.
>
> You need to decide which approach to take and no violations must be made.
> The first approach seems logical to me.
>
> Karthik
>
> > From: Guangzhi Li [mailto:gli@research.att.com]
> >
> > I did not make it clear. I assume that the I/O ports of
> > Bi-directional LSP
> > are
> > paired. After node 1 configured the cross-connect with the
> > upstream label
> > (of course
> > suggested label) for LSP B,  node 1 received the uni-directional RESV
> > message for
> > LSP A, is it obviously defined in GMPLS that node 1 should
> > accept LSP A and
> > give up
> > LSP B or simply is it a local decision/policy implementation?
> >
> > -- Guangzhi
> >
> > Guangzhi Li wrote:
> >
> > > Hang:
> > >
> > > NO. The PATH message is bi-directional and the RESV is
> > uni-directional. If
> > there
> > > is a contention,  the contention happens with LSP A and the
> > upstream label
> > of
> > > LSP B.
> > >
> > > In your suggestion, you used IF. IF GMPLS specifies a
> > consisten way to
> > resolve
> > > it, such as Resv wins Path message in all cases, there is
> > no problem. A
> > simply
> > > local decision is NOT enough.
> > >
> > > Please draw pictures and apply current GMPLS contention
> > resolution schemes
> > ONLY.
> > > You will see something needs to be fixed.
> > >
> > > Guangzhi


From owner-mpls@UU.NET  Wed Aug 29 15:00:02 2001
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 PAA06134
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 15:00:01 -0400 (EDT)
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 QQlefc02058;
	Wed, 29 Aug 2001 19:01:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefc21844
	for mpls-outgoing; Wed, 29 Aug 2001 19:00:42 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 QQlefc21724
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 19:00:34 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 QQlefc21414
	for <mpls@uu.net>; Wed, 29 Aug 2001 19:00:25 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f154.law11.hotmail.com [64.4.17.154])
	id QQlefc00882
	for <mpls@uu.net>; Wed, 29 Aug 2001 19:00:27 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 29 Aug 2001 12:00:24 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Wed, 29 Aug 2001 19:00:24 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: mpls@UU.NET
Subject: LSR-MIB - AvailableBandwidth ?
Date: Wed, 29 Aug 2001 15:00:24 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F154R9Qz9IPUS9O4Tsv00015b24@hotmail.com>
X-OriginalArrivalTime: 29 Aug 2001 19:00:24.0577 (UTC) FILETIME=[DBFB9F10:01C130BC]
Sender: owner-mpls@UU.NET
Precedence: bulk

Cheenu et al,

The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
the attribute mplsInterfaceAvailableBandwidth

Typically the management application can use this attribute while
computing a constrained TE path or an LSP path.
Now if the signalling protocol is also setting up LSP on this
interface at or around the same time, the management application
would be computing a path based on incoreect value because the
value of this attribute may not be current.

My question is do we need a trap, like AvailableBandwidthChange,
to be sent to the NMS whenever a LSP is setup/teardown on an
interface. In the absence of such a mechanism the NMS may need to
get the value of all the interface in the network before it computes
the path even if the values may not have changed.

So in order to keep the NMS in sync with the NE I think a trap is
needed. If you think this is not the way to keep the NMS in sync with
the state of the NE then what is your suggestion.
Appreciate your comments.

Regards,
Irfan Lateef

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 15:16:49 2001
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 PAA06644
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 15:16:49 -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 QQlefd04650;
	Wed, 29 Aug 2001 19:17:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefd09839
	for mpls-outgoing; Wed, 29 Aug 2001 19:17:33 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 QQlefd09829
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 19:17:25 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 QQlefd27630
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:16:08 GMT
Received: from nwmq0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwmq0102a.jc.digitran.com [165.251.28.22])
	id QQlefd02118
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:16:09 GMT
Received: from csrinivasan [12.34.209.74] by nwmq0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Wed, 29 Aug 2001 15:10:55 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'Irfan Lateef'" <irfanlateef@hotmail.com>, <mpls@UU.NET>
Subject: RE: LSR-MIB - AvailableBandwidth ?
Date: Wed, 29 Aug 2001 15:28:54 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB13A@OPTONT>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <F154R9Qz9IPUS9O4Tsv00015b24@hotmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> the attribute mplsInterfaceAvailableBandwidth
> 
> Typically the management application can use this attribute while
> computing a constrained TE path or an LSP path.
> Now if the signalling protocol is also setting up LSP on this
> interface at or around the same time, the management application
> would be computing a path based on incoreect value because the
> value of this attribute may not be current.
> 
> My question is do we need a trap, like AvailableBandwidthChange,
> to be sent to the NMS whenever a LSP is setup/teardown on an
> interface. In the absence of such a mechanism the NMS may need to
> get the value of all the interface in the network before it computes
> the path even if the values may not have changed.
> 
> So in order to keep the NMS in sync with the NE I think a trap is
> needed. If you think this is not the way to keep the NMS in sync with
> the state of the NE then what is your suggestion.

This would lead to a trap storm. If you want to track link states
at this time scale your best bet is probably to participate passively
in the IGP.

Cheenu



From owner-mpls@UU.NET  Wed Aug 29 15:57:35 2001
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 PAA07684
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 15:57:34 -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 QQleff19481;
	Wed, 29 Aug 2001 19:58:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleff14333
	for mpls-outgoing; Wed, 29 Aug 2001 19:58: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 QQleff14316
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 19:58:15 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 QQleff19030
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:57:56 GMT
From: neil.2.harrison@bt.com
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 QQleff27139
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:57:58 GMT
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <RL28W1SX>; Wed, 29 Aug 2001 20:57:58 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891673@mbddmknt01.hc.bt.com>
To: hemant@cyberspace.org, mpls-ops@mplsrc.com
Cc: mpls@UU.NET
Subject: RE: Label Statistics at the time of LSP switching
Date: Wed, 29 Aug 2001 20:57:53 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hemant,

Good question.  The answer depends on having a definition of what
constitutes the 'up' and 'down' states of the LSP.  [I will restrict the
scope of the discussion which now follows to the pt-pt case for reasons I
hope are obvious]

LSPs really need 2 dependent performance categories associated with them:
1	Availability, ie % time in the 'up' state
2	QoS metrics, eg lost pkts/octets, errored pkts, delayed >Xs pkts,
etc (which may be on a per DS-class basis say)

QoS metrics are only meaningful when the LSP is in the available
state.......so any QoS SLA associated with an LSP requires a prior
availability SLA to be in place.

{Aside: Above does not apply to the IP fabric except on an end-end basis
since it is cnls.  That is, the memoryless nature of forwarding and the
inter-dependency of forwarding and the IGP (ie required
stability/convergence) means that a cnls fabric mutates failures into QoS
hits.  There is nothing wrong with this.....this is the required design
behaviour.  However, the key significance of this observation is that any
*objectives* for availability/QoS metrics within the IP layer network are
only meaningful on an end-end basis, ie they cannot be easily (see Note)
partitioned to smaller subnetwork elements.  Note - Subnetwork partitioning
may be possible on a coarse domain level, say between ASs, providing a fixed
NNI interconnection point applies, ie traffic is always forced through a
given point.}

Now, to define the availability of an LSP one needs to define the
availability entry/exit criteria.  Please note that I would strongly advise
against associating any QoS metrics (and the many-fold OR'd combinations
possible) in the specification of such availability entry/exit criteria as
the problem will very quickly become too complex (and costly to measure).
The most pragmatic way to define the availability entry/exit criteria is to
base them soley on defects....and if one is sensible, again for simplicity
reasons, one should also try and temporally harmonise the defect entry/exit
criteria as well.

Once the availability entry/exit criteria are defined then we now have a
base against which to start/stop QoS metric aggregation.

So the answer to your question is 'it depends of how long the switching
takes relative to the unavailability entry criteria' (which has to have some
time parameter associated with it of course, so let's call this T):
A	if one can switch to a back-up LSP in t<=T then one should simply
take the 'QoS hit', ie some value of lost pkts/octets say.....and this would
also apply to any later revertive switching back to the original LSP;
B	if one cannot switch to a back-up LSP in t<=T then the QoS metrics
should be suspended (note that the QoS counters should be back-dated to the
onset (t') of this event, ie at t' = t-T).

In case A then QoS metric aggregation is simply *transferred* from the
working to back-up LSP as if nothing had happened (what has really happened
from a customer perspective is a 'short-break', but it was below the
unavailability threshold).  You should not be associating different QoS
metrics with the 2 LSPs since, from the LSPs perspective (or the customer
using it) the end-end source/sink trail points are unchanged by the prot-sw
action.

I have skipped many nuances/detail in the above, but I hope you grasp the
thrust of the issues that need addressing.  The required behaviour is
described/specified in detail in draft-harrison-mpls-oam-00.txt.

regards, Neil



> -----Original Message-----
> From: Hemant P. Kelkar [mailto:hemant@cyberspace.org]
> Sent: 29 August 2001 11:12
> To: mpls-ops@mplsrc.com
> Cc: mpls@UU.NET
> Subject: Label Statistics at the time of LSP switching
> 
> 
> Hi,
> I have a doubt regarding the MPLS input and output label statistics. 
> Usually an LSP can be denoted by input:output label & 
> interfaces (simplest
> case)
> When LSP switching occurs, the backup LSP identified by the new
> input:output label & interfaces.
> For these two cases (working and bakcup LSP) there will be 
> different sets
> of statistics counters.
> What is done with the working statistics counters, when the LSP is
> switched. Are they restored when the LSP is restored or they 
> are reset and
> statistics is referred by the new statistics counters(associated with
> backup LSP).
> regards,
> Hemant
> 


From owner-mpls@UU.NET  Wed Aug 29 15:59:46 2001
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 PAA07849
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 15:59:46 -0400 (EDT)
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 QQlefg01221;
	Wed, 29 Aug 2001 20:00:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefg15381
	for mpls-outgoing; Wed, 29 Aug 2001 20:00: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 QQlefg14820
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:00: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 QQleff11784
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:59:40 GMT
From: sgong@gmu.edu
Received: from portal.gmu.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: portalknot.gmu.edu [129.174.0.8])
	id QQleff29393
	for <mpls@UU.NET>; Wed, 29 Aug 2001 19:59:42 GMT
Received: from gmu.edu (mail01.gmu.edu [129.174.0.6])
	by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA22398;
	Wed, 29 Aug 2001 15:59:29 -0400 (EDT)
To: "Cheenu Srinivasan" <cheenu@alphion.com>
Cc: "'Irfan Lateef'" <irfanlateef@hotmail.com>, <mpls@UU.NET>
Message-ID: <d3d2ad53b8.d53b8d3d2a@gmu.edu>
Date: Wed, 29 Aug 2001 14:59:29 -0500
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: en
Subject: Re: RE: LSR-MIB - AvailableBandwidth ?
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Maybe draft-kompella-tewg-bw-acct-00.txt can help answer your question.



From owner-mpls@UU.NET  Wed Aug 29 16:04:46 2001
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 QAA07942
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 16:04: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 QQlefg11751;
	Wed, 29 Aug 2001 20:05:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefg25034
	for mpls-outgoing; Wed, 29 Aug 2001 20:05: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 QQlefg24966
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:05: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 QQlefg06287
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:03:53 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f27.law11.hotmail.com [64.4.17.27])
	id QQlefg05670
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:03:55 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 29 Aug 2001 13:03:52 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;
	Wed, 29 Aug 2001 20:03:51 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: cheenu@alphion.com, mpls@UU.NET
Subject: RE: LSR-MIB - AvailableBandwidth ?
Date: Wed, 29 Aug 2001 16:03:51 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F27dnGiAw8HQEUEiffC00000469@hotmail.com>
X-OriginalArrivalTime: 29 Aug 2001 20:03:52.0160 (UTC) FILETIME=[B97AAE00:01C130C5]
Sender: owner-mpls@UU.NET
Precedence: bulk

Cheenu,

What is the intended use of this attribute
or in other words what is the motivation for
this attribute in the table.

Irfan


>From: "Cheenu Srinivasan" <cheenu@alphion.com>
>To: "'Irfan Lateef'" <irfanlateef@hotmail.com>, <mpls@UU.NET>
>Subject: RE: LSR-MIB - AvailableBandwidth ?
>Date: Wed, 29 Aug 2001 15:28:54 -0400
>
> > The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> > the attribute mplsInterfaceAvailableBandwidth
> >
> > Typically the management application can use this attribute while
> > computing a constrained TE path or an LSP path.
> > Now if the signalling protocol is also setting up LSP on this
> > interface at or around the same time, the management application
> > would be computing a path based on incoreect value because the
> > value of this attribute may not be current.
> >
> > My question is do we need a trap, like AvailableBandwidthChange,
> > to be sent to the NMS whenever a LSP is setup/teardown on an
> > interface. In the absence of such a mechanism the NMS may need to
> > get the value of all the interface in the network before it computes
> > the path even if the values may not have changed.
> >
> > So in order to keep the NMS in sync with the NE I think a trap is
> > needed. If you think this is not the way to keep the NMS in sync with
> > the state of the NE then what is your suggestion.
>
>This would lead to a trap storm. If you want to track link states
>at this time scale your best bet is probably to participate passively
>in the IGP.
>
>Cheenu
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 16:10:13 2001
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 QAA08129
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 16:10:12 -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 QQlefg20407;
	Wed, 29 Aug 2001 20:11:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefg03529
	for mpls-outgoing; Wed, 29 Aug 2001 20:10: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 QQlefg03494
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:10: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 QQlefg04153
	for <mpls@uu.net>; Wed, 29 Aug 2001 20:10:12 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlefg15251
	for <mpls@uu.net>; Wed, 29 Aug 2001 20:10:14 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA20008 for mpls@uu.net; Wed, 29 Aug 2001 16:10:10 -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 QQlefg02637
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:09: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 QQlefg21788
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:09:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQlefg13534
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:09:06 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA03620; Wed, 29 Aug 2001 16:09:03 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AHD11885;
	Wed, 29 Aug 2001 16:09:01 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010829130237.0351d9e0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 29 Aug 2001 13:10:19 -0700
To: "Irfan Lateef" <irfanlateef@hotmail.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: LSR-MIB - AvailableBandwidth ?
Cc: mpls@UU.NET
In-Reply-To: <F154R9Qz9IPUS9O4Tsv00015b24@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
>Cheenu et al,
>
>The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
>the attribute mplsInterfaceAvailableBandwidth
>
>Typically the management application can use this attribute while
>computing a constrained TE path or an LSP path.
>Now if the signalling protocol is also setting up LSP on this
>interface at or around the same time, the management application
>would be computing a path based on incoreect value because the
>value of this attribute may not be current.
>
>My question is do we need a trap, like AvailableBandwidthChange,
>to be sent to the NMS whenever a LSP is setup/teardown on an
>interface. In the absence of such a mechanism the NMS may need to
>get the value of all the interface in the network before it computes
>the path even if the values may not have changed.
>
>So in order to keep the NMS in sync with the NE I think a trap is
>needed. If you think this is not the way to keep the NMS in sync with
>the state of the NE then what is your suggestion.
>Appreciate your comments.

         I think that you raise an important point, but I would
first think carefully about whether or not you want to do
what you describe. What you seem to want to do are
ad hoc off-line TE calculations and then push them down to
the devices. First, as you mention there is a time lag between
when the bandwidth changes and when the NMS can know
about it. This is why it might be a better idea to let the
routers do the path computation after feeding them some
constraints (i.e.: end points and bandwidth requirements).

         Now, if you want to truly do what you describe, I don't
think that adding a notification will help prevent the
timing problem, since the bandwidth can still change
between the time that the notification is sent and processed
by the NMS. Furthermore, since notifications are typically
unreliable, they can be lost, and thus we have the same problem
even after implementing such a notification.

         --Tom






From owner-mpls@UU.NET  Wed Aug 29 16:36:46 2001
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 QAA08788
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 16:36:46 -0400 (EDT)
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 QQlefi02523;
	Wed, 29 Aug 2001 20:37:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefi06705
	for mpls-outgoing; Wed, 29 Aug 2001 20:37: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 QQlefi06696
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:37:19 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 QQlefi11392
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:36:46 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlefi00295
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:36:48 GMT
Message-ID: <3B8D525C.369FE85E@sandburst.com>
Date: Wed, 29 Aug 2001 16:36:44 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Irfan Lateef <irfanlateef@hotmail.com>
Cc: cheenu@alphion.com, mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
References: <F27dnGiAw8HQEUEiffC00000469@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan,

    My 2 cents (and worth every penny of it).  Typically, an NMS is
suited for analysis of network breakdown and monitoring trends -
mostly because the time scale for detecting changes in the network
in general using an NMS is suited to these types of uses.  It can
also be used to collect statisitics in general (for accounting, etc.).

    I believe this attribute would be useful for monitoring trends.

--
Eric Gray

You wrote:

> Cheenu,
>
> What is the intended use of this attribute
> or in other words what is the motivation for
> this attribute in the table.
>
> Irfan
>
> >From: "Cheenu Srinivasan" <cheenu@alphion.com>
> >To: "'Irfan Lateef'" <irfanlateef@hotmail.com>, <mpls@UU.NET>
> >Subject: RE: LSR-MIB - AvailableBandwidth ?
> >Date: Wed, 29 Aug 2001 15:28:54 -0400
> >
> > > The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> > > the attribute mplsInterfaceAvailableBandwidth
> > >
> > > Typically the management application can use this attribute while
> > > computing a constrained TE path or an LSP path.
> > > Now if the signalling protocol is also setting up LSP on this
> > > interface at or around the same time, the management application
> > > would be computing a path based on incoreect value because the
> > > value of this attribute may not be current.
> > >
> > > My question is do we need a trap, like AvailableBandwidthChange,
> > > to be sent to the NMS whenever a LSP is setup/teardown on an
> > > interface. In the absence of such a mechanism the NMS may need to
> > > get the value of all the interface in the network before it computes
> > > the path even if the values may not have changed.
> > >
> > > So in order to keep the NMS in sync with the NE I think a trap is
> > > needed. If you think this is not the way to keep the NMS in sync with
> > > the state of the NE then what is your suggestion.
> >
> >This would lead to a trap storm. If you want to track link states
> >at this time scale your best bet is probably to participate passively
> >in the IGP.
> >
> >Cheenu
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 16:44:24 2001
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 QAA09063
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 16:44:24 -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 QQlefj08683;
	Wed, 29 Aug 2001 20:45:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefj07218
	for mpls-outgoing; Wed, 29 Aug 2001 20:45:01 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 QQlefi07168
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 20:44:54 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 QQlefi01246
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:43:26 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlefi26913
	for <mpls@UU.NET>; Wed, 29 Aug 2001 20:43:25 GMT
Message-ID: <3B8D53EC.BA9E740E@sandburst.com>
Date: Wed, 29 Aug 2001 16:43:24 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>
Cc: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
References: <4.3.2.7.2.20010829130237.0351d9e0@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan,

    Just to add to what Tom says, there are other scary aspects of this
question.
For one, your question seems to assume that an NMS is being used to compute
paths, but that some other mechanism is being used to set them up and there is
apparently no coordination between the two mechanisms.  For another, in order
to avoid the trap storms that Cheenu mentioned, you'd have to include notions
of change granularity and minimum reporting cycle time.  This quickly starts to
be more costly than beneficial.

--
Eric Gray

Thomas Nadeau wrote:

> At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
> >Cheenu et al,
> >
> >The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> >the attribute mplsInterfaceAvailableBandwidth
> >
> >Typically the management application can use this attribute while
> >computing a constrained TE path or an LSP path.
> >Now if the signalling protocol is also setting up LSP on this
> >interface at or around the same time, the management application
> >would be computing a path based on incoreect value because the
> >value of this attribute may not be current.
> >
> >My question is do we need a trap, like AvailableBandwidthChange,
> >to be sent to the NMS whenever a LSP is setup/teardown on an
> >interface. In the absence of such a mechanism the NMS may need to
> >get the value of all the interface in the network before it computes
> >the path even if the values may not have changed.
> >
> >So in order to keep the NMS in sync with the NE I think a trap is
> >needed. If you think this is not the way to keep the NMS in sync with
> >the state of the NE then what is your suggestion.
> >Appreciate your comments.
>
>          I think that you raise an important point, but I would
> first think carefully about whether or not you want to do
> what you describe. What you seem to want to do are
> ad hoc off-line TE calculations and then push them down to
> the devices. First, as you mention there is a time lag between
> when the bandwidth changes and when the NMS can know
> about it. This is why it might be a better idea to let the
> routers do the path computation after feeding them some
> constraints (i.e.: end points and bandwidth requirements).
>
>          Now, if you want to truly do what you describe, I don't
> think that adding a notification will help prevent the
> timing problem, since the bandwidth can still change
> between the time that the notification is sent and processed
> by the NMS. Furthermore, since notifications are typically
> unreliable, they can be lost, and thus we have the same problem
> even after implementing such a notification.
>
>          --Tom



From owner-mpls@UU.NET  Wed Aug 29 17:37:43 2001
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 RAA11051
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 17:37:42 -0400 (EDT)
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 QQlefm05580;
	Wed, 29 Aug 2001 21:38:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefm00761
	for mpls-outgoing; Wed, 29 Aug 2001 21:38: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 QQlefm00756
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 21:38: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 QQlefm04310
	for <mpls@UU.NET>; Wed, 29 Aug 2001 21:37:46 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f273.law11.hotmail.com [64.4.16.148])
	id QQlefm03762
	for <mpls@UU.NET>; Wed, 29 Aug 2001 21:37:48 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 29 Aug 2001 14:37:45 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Wed, 29 Aug 2001 21:37:44 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: eric.gray@sandburst.com, tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
Date: Wed, 29 Aug 2001 17:37:44 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F273kLQ8aZRhQdOgl4r0000092d@hotmail.com>
X-OriginalArrivalTime: 29 Aug 2001 21:37:45.0107 (UTC) FILETIME=[D6FA2E30:01C130D2]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I will try to reply Cheenu, Tom and Eric in one mail.

Alarm or Trap Storms are considered to be undesirable during
failures because all of them tend to convey the same information during 
failure and hinder any corrective acton by congesting the
network. Even worse sometimes they are only a side effect of a
failure in the network downstream.
This generally happens in transport networks because of
the ability of the network to propagate the defect in forward and
backward direction. Where as in the present case, if an LSP is setup
across N links, then receiving N traps indicating a change in the
available bandwidth of each link respectively is not redundant and
undesirable but necessary. The debatable point could when should it
be sent. Also as Eric pointed if this is used for monitoring, even
then this has to updated at some agreeable interval period.

The second point I would like to make is the assumption that the
networks under consideration are fairly stable, in the sense that the
time scales for setup and teardown are fairly large. For example,
an enterprise customer requesting a 1 Gb pipe from point A to B.

As the number contraints and the number of nodes increase, the
optimization algorithm may become computationally expensive to fit in
the device, hence a desire to compute the bigger bw LSP with more
efficient mechanism off-line.

Addressing the time lag issue. Assume an LSP is being setup

A---B---C---D---E

While you are computing a path in A, from A to E, if C setup another
LSP from C to D and the OSPF update has not yet occured, you still
have the same problem. So let us assume we are operating with the
same assumption of time granularity irrespective of where we are
computing the path and also assume that the network does not change
between computation and setup.

Eric, you are right. for the reasons mentioned I am proposing TE
computation off-line in NMS and then setup from ingress and I am
trying to bring about the necessary coordination by the proposed
TRAP. Autonomous notifications will address the granularity and
reporting cycle issue.

So sending the notification and making the same assumptions as you
would have made while computing the path in the device could solve
the problem I am trying to impress upon the list and the authors.

However taking a cue from this discussion, the other method to do
the calculation  could be to retrieve the whole OSPF-TE MIB from
the ingress node and compute the path. But that also has some of the
caveats discussed above. Also I am not sure what would be the size
of such a MIB in large network.

Regards,

Irfan Lateef

P.S : Cheenu, Can you clarify the passive OSPF suggestion ,
      I did not understand your exact idea.





>From: Eric Gray <eric.gray@sandburst.com>
>To: Thomas Nadeau <tnadeau@cisco.com>
>CC: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
>Subject: Re: LSR-MIB - AvailableBandwidth ?
>Date: Wed, 29 Aug 2001 16:43:24 -0400
>
>Irfan,
>
>     Just to add to what Tom says, there are other scary aspects of this
>question.
>For one, your question seems to assume that an NMS is being used to compute
>paths, but that some other mechanism is being used to set them up and there 
>is
>apparently no coordination between the two mechanisms.  For another, in 
>order
>to avoid the trap storms that Cheenu mentioned, you'd have to include 
>notions
>of change granularity and minimum reporting cycle time.  This quickly 
>starts to
>be more costly than beneficial.
>
>--
>Eric Gray
>
>Thomas Nadeau wrote:
>
> > At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
> > >Cheenu et al,
> > >
> > >The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> > >the attribute mplsInterfaceAvailableBandwidth
> > >
> > >Typically the management application can use this attribute while
> > >computing a constrained TE path or an LSP path.
> > >Now if the signalling protocol is also setting up LSP on this
> > >interface at or around the same time, the management application
> > >would be computing a path based on incoreect value because the
> > >value of this attribute may not be current.
> > >
> > >My question is do we need a trap, like AvailableBandwidthChange,
> > >to be sent to the NMS whenever a LSP is setup/teardown on an
> > >interface. In the absence of such a mechanism the NMS may need to
> > >get the value of all the interface in the network before it computes
> > >the path even if the values may not have changed.
> > >
> > >So in order to keep the NMS in sync with the NE I think a trap is
> > >needed. If you think this is not the way to keep the NMS in sync with
> > >the state of the NE then what is your suggestion.
> > >Appreciate your comments.
> >
> >          I think that you raise an important point, but I would
> > first think carefully about whether or not you want to do
> > what you describe. What you seem to want to do are
> > ad hoc off-line TE calculations and then push them down to
> > the devices. First, as you mention there is a time lag between
> > when the bandwidth changes and when the NMS can know
> > about it. This is why it might be a better idea to let the
> > routers do the path computation after feeding them some
> > constraints (i.e.: end points and bandwidth requirements).
> >
> >          Now, if you want to truly do what you describe, I don't
> > think that adding a notification will help prevent the
> > timing problem, since the bandwidth can still change
> > between the time that the notification is sent and processed
> > by the NMS. Furthermore, since notifications are typically
> > unreliable, they can be lost, and thus we have the same problem
> > even after implementing such a notification.
> >
> >          --Tom
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 18:22:37 2001
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 SAA12249
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 18:22:37 -0400 (EDT)
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 QQlefp09183;
	Wed, 29 Aug 2001 22:23:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefp22974
	for mpls-outgoing; Wed, 29 Aug 2001 22:23:21 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 QQlefp22969
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 22:23:16 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 QQlefp13549
	for <mpls@UU.NET>; Wed, 29 Aug 2001 22:23:15 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 QQlefp23652
	for <mpls@UU.NET>; Wed, 29 Aug 2001 22:23:17 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 SAA13397
	for <mpls@UU.NET>; Wed, 29 Aug 2001 18:19:23 -0400 (EDT)
Subject: Speccomom Tspec in Path and Flow spec in Resv
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFC4AEA43E.1552F620-ON85256AB7.00760C28@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Wed, 29 Aug 2001 18:19:12 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/29/2001 06:19:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The Tspec in path should be the same as the Flow spec in Resv or not?


Token bucket rate
Token bucket size
Peak data rate
Minimum policed unit
Maximum packet size

Thanks,

Julia





From owner-mpls@UU.NET  Wed Aug 29 18:32:38 2001
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 SAA12486
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 18:32:38 -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 QQlefq17909;
	Wed, 29 Aug 2001 22:33:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefq23634
	for mpls-outgoing; Wed, 29 Aug 2001 22:33:21 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 QQlefq23629
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 22:33:18 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 QQlefq29884
	for <mpls@UU.NET>; Wed, 29 Aug 2001 22:33: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 QQlefq07423
	for <mpls@UU.NET>; Wed, 29 Aug 2001 22:33:08 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 SAA19232
	for <mpls@UU.NET>; Wed, 29 Aug 2001 18:33:03 -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 SAA29976
	for <mpls@UU.NET>; Wed, 29 Aug 2001 18:33:05 -0400 (EDT)
Message-ID: <3B8D6DB3.D6936A1C@marconi.com>
Date: Wed, 29 Aug 2001 18:33:23 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Speccomom Tspec in Path and Flow spec in Resv
References: <OFC4AEA43E.1552F620-ON85256AB7.00760C28@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:
> 
> The Tspec in path should be the same as the Flow spec in Resv or not?

The FLOWSPEC reserved will be truncated (on a parameter-by-parameter
basis) to the TSPEC during Resv processing.

Any FLOWSPEC values less than that are legal.  In the absence of other
data, the router should request the TSPEC values.

If the egress router wants to use more complicated heuristics, it may
choose some reduced value.  It would be ill-advised, however, to do this
without some explicit local policy.  I suspect that most administrators
will expect their LSPs to come up with the requested amount of resources
or not at all.

-- David


From owner-mpls@UU.NET  Wed Aug 29 19:01:12 2001
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 TAA13103
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 19:01:11 -0400 (EDT)
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 QQlefs29820;
	Wed, 29 Aug 2001 23:02:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefs04684
	for mpls-outgoing; Wed, 29 Aug 2001 23:02:01 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 QQlefs04467
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 23:01:59 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 QQlefs04280
	for <mpls@UU.NET>; Wed, 29 Aug 2001 23:01:41 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 QQlefs17023
	for <mpls@UU.NET>; Wed, 29 Aug 2001 23:01:42 GMT
Message-ID: <3B8D7453.9801E57@sandburst.com>
Date: Wed, 29 Aug 2001 19:01:39 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Irfan Lateef <irfanlateef@hotmail.com>
Cc: tnadeau@cisco.com, mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
References: <F273kLQ8aZRhQdOgl4r0000092d@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan,

    In this case, the trap storm would arise from the fact that you
have not defined an appropriate granularity for what you mean by
'change' (under this circumstance, every little hiccup in a network
would inundate the NMS with too much information).  Even if you
have picked an appropriate granularity, you should define a minimum
hold off delay in announcing yet more changes (otherwise, the NMS
would still be processing the data from one trap when it is over-run
with data from subsequent traps).

    It is likely that an appropriate granularity for change - dictated
by a need to avoid having a lot of traps sent all at once - will be
larger than the typical size of a setup.  Consequently, a change
large enough to block a typical setup will be too small to report
under some circumstances.  In addition, if any sort of timer is to
be used, then why not have the NMS poll the NEs?  This is what
I meant by the trap approach being more costly than beneficial.

    I think you would have to make up your mind who is going to be
in control of your TE setup.  If, as you say, an NMS can manage it
because of a protracted time scale - and an operator decides to
do it this way - then only the NMS should manage TE setup and
tear down.  If that is the case, then where would the change you
want to be notified of come from?  On the other hand, if you need
to use a more dynamic approach, then the NMS should be limited
to policy level management.  Otherwise, it would be like having a
manager that makes specific resource allocation decisions based
on monthly trend data and an annual budget for individual projects
with an average project life cycle of 3 days.

--
Eric Gray

You wrote:

> Hi,
>
> I will try to reply Cheenu, Tom and Eric in one mail.
>
> Alarm or Trap Storms are considered to be undesirable during
> failures because all of them tend to convey the same information during
> failure and hinder any corrective acton by congesting the
> network. Even worse sometimes they are only a side effect of a
> failure in the network downstream.
> This generally happens in transport networks because of
> the ability of the network to propagate the defect in forward and
> backward direction. Where as in the present case, if an LSP is setup
> across N links, then receiving N traps indicating a change in the
> available bandwidth of each link respectively is not redundant and
> undesirable but necessary. The debatable point could when should it
> be sent. Also as Eric pointed if this is used for monitoring, even
> then this has to updated at some agreeable interval period.
>
> The second point I would like to make is the assumption that the
> networks under consideration are fairly stable, in the sense that the
> time scales for setup and teardown are fairly large. For example,
> an enterprise customer requesting a 1 Gb pipe from point A to B.
>
> As the number contraints and the number of nodes increase, the
> optimization algorithm may become computationally expensive to fit in
> the device, hence a desire to compute the bigger bw LSP with more
> efficient mechanism off-line.
>
> Addressing the time lag issue. Assume an LSP is being setup
>
> A---B---C---D---E
>
> While you are computing a path in A, from A to E, if C setup another
> LSP from C to D and the OSPF update has not yet occured, you still
> have the same problem. So let us assume we are operating with the
> same assumption of time granularity irrespective of where we are
> computing the path and also assume that the network does not change
> between computation and setup.
>
> Eric, you are right. for the reasons mentioned I am proposing TE
> computation off-line in NMS and then setup from ingress and I am
> trying to bring about the necessary coordination by the proposed
> TRAP. Autonomous notifications will address the granularity and
> reporting cycle issue.
>
> So sending the notification and making the same assumptions as you
> would have made while computing the path in the device could solve
> the problem I am trying to impress upon the list and the authors.
>
> However taking a cue from this discussion, the other method to do
> the calculation  could be to retrieve the whole OSPF-TE MIB from
> the ingress node and compute the path. But that also has some of the
> caveats discussed above. Also I am not sure what would be the size
> of such a MIB in large network.
>
> Regards,
>
> Irfan Lateef
>
> P.S : Cheenu, Can you clarify the passive OSPF suggestion ,
>       I did not understand your exact idea.
>
> >From: Eric Gray <eric.gray@sandburst.com>
> >To: Thomas Nadeau <tnadeau@cisco.com>
> >CC: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
> >Subject: Re: LSR-MIB - AvailableBandwidth ?
> >Date: Wed, 29 Aug 2001 16:43:24 -0400
> >
> >Irfan,
> >
> >     Just to add to what Tom says, there are other scary aspects of this
> >question.
> >For one, your question seems to assume that an NMS is being used to compute
> >paths, but that some other mechanism is being used to set them up and there
> >is
> >apparently no coordination between the two mechanisms.  For another, in
> >order
> >to avoid the trap storms that Cheenu mentioned, you'd have to include
> >notions
> >of change granularity and minimum reporting cycle time.  This quickly
> >starts to
> >be more costly than beneficial.
> >
> >--
> >Eric Gray
> >
> >Thomas Nadeau wrote:
> >
> > > At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
> > > >Cheenu et al,
> > > >
> > > >The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> > > >the attribute mplsInterfaceAvailableBandwidth
> > > >
> > > >Typically the management application can use this attribute while
> > > >computing a constrained TE path or an LSP path.
> > > >Now if the signalling protocol is also setting up LSP on this
> > > >interface at or around the same time, the management application
> > > >would be computing a path based on incoreect value because the
> > > >value of this attribute may not be current.
> > > >
> > > >My question is do we need a trap, like AvailableBandwidthChange,
> > > >to be sent to the NMS whenever a LSP is setup/teardown on an
> > > >interface. In the absence of such a mechanism the NMS may need to
> > > >get the value of all the interface in the network before it computes
> > > >the path even if the values may not have changed.
> > > >
> > > >So in order to keep the NMS in sync with the NE I think a trap is
> > > >needed. If you think this is not the way to keep the NMS in sync with
> > > >the state of the NE then what is your suggestion.
> > > >Appreciate your comments.
> > >
> > >          I think that you raise an important point, but I would
> > > first think carefully about whether or not you want to do
> > > what you describe. What you seem to want to do are
> > > ad hoc off-line TE calculations and then push them down to
> > > the devices. First, as you mention there is a time lag between
> > > when the bandwidth changes and when the NMS can know
> > > about it. This is why it might be a better idea to let the
> > > routers do the path computation after feeding them some
> > > constraints (i.e.: end points and bandwidth requirements).
> > >
> > >          Now, if you want to truly do what you describe, I don't
> > > think that adding a notification will help prevent the
> > > timing problem, since the bandwidth can still change
> > > between the time that the notification is sent and processed
> > > by the NMS. Furthermore, since notifications are typically
> > > unreliable, they can be lost, and thus we have the same problem
> > > even after implementing such a notification.
> > >
> > >          --Tom
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 19:51:13 2001
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 TAA13604
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 19:51:13 -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 QQlefv05042;
	Wed, 29 Aug 2001 23:52:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlefv17934
	for mpls-outgoing; Wed, 29 Aug 2001 23:52:01 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 QQlefv17905
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 29 Aug 2001 23:51:53 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 QQlefv13830
	for <mpls@UU.NET>; Wed, 29 Aug 2001 23:51:44 GMT
Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: server.nayna.com [207.5.81.3])
	id QQlefv04206
	for <mpls@UU.NET>; Wed, 29 Aug 2001 23:51:45 GMT
Received: from nayna.com ([64.220.200.249])
	by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA02799;
	Wed, 29 Aug 2001 16:51:41 -0700
X-Authentication-Warning: server.nayna.com: Host [64.220.200.249] claimed to be nayna.com
Message-ID: <3B8D7FE3.F1796991@nayna.com>
Date: Wed, 29 Aug 2001 16:50:59 -0700
From: Sudheer Dharanikota <sudheer@nayna.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Irfan Lateef <irfanlateef@hotmail.com>
CC: mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
References: <F154R9Qz9IPUS9O4Tsv00015b24@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Irfan:

I think in such situations NMS should poll this parameter
at regualr intervals. This interval should be long enough
not to overwhelm your control channel and short enough to
get almost correct value.

The routing protocol should advertize the avilable change
only after certain thresholds have crossed.

When there is a conflict on the reservations between the
dynamic and static allocations it should be solved during the
signaling phase. I would put manual configuration at a
higher priority in such a conflict as recovering from such
a failure is diffucult than that using dynamic protocols.

Hope this makes sense.

sudheer

Irfan Lateef wrote:

> Cheenu et al,
>
> The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
> the attribute mplsInterfaceAvailableBandwidth
>
> Typically the management application can use this attribute while
> computing a constrained TE path or an LSP path.
> Now if the signalling protocol is also setting up LSP on this
> interface at or around the same time, the management application
> would be computing a path based on incoreect value because the
> value of this attribute may not be current.
>
> My question is do we need a trap, like AvailableBandwidthChange,
> to be sent to the NMS whenever a LSP is setup/teardown on an
> interface. In the absence of such a mechanism the NMS may need to
> get the value of all the interface in the network before it computes
> the path even if the values may not have changed.
>
> So in order to keep the NMS in sync with the NE I think a trap is
> needed. If you think this is not the way to keep the NMS in sync with
> the state of the NE then what is your suggestion.
> Appreciate your comments.
>
> Regards,
> Irfan Lateef
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Wed Aug 29 23:37:44 2001
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 XAA17911
	for <mpls-archive@lists.ietf.org>; Wed, 29 Aug 2001 23:37:43 -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 QQlegk07863;
	Thu, 30 Aug 2001 03:38:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlegk18016
	for mpls-outgoing; Thu, 30 Aug 2001 03:38:21 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 QQlegk18011
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 03:38: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 QQlegk14111
	for <mpls@uu.net>; Thu, 30 Aug 2001 03:38:10 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlegk03334
	for <mpls@uu.net>; Thu, 30 Aug 2001 03:38:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA14837 for mpls@uu.net; Wed, 29 Aug 2001 23:38:08 -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 QQlegk18000
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 03:38:01 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 QQlegk14960
	for <mpls@UU.NET>; Thu, 30 Aug 2001 03:37:31 GMT
Received: from alpo.casc.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpo.casc.com [152.148.10.6])
	id QQlegk19649
	for <mpls@UU.NET>; Thu, 30 Aug 2001 03:37:34 GMT
Received: from ITLPC16583 ([152.148.248.166])
	by alpo.casc.com (8.9.1a/8.9.1) with SMTP id XAA09882
	for <mpls@UU.NET>; Wed, 29 Aug 2001 23:37:37 -0400 (EDT)
Message-ID: <01c601c13105$8558ee80$a6f89498@ITLPC16583>
From: "Vijayalakshmi B" <vb8@casc.com>
To: <mpls@UU.NET>
References: <007001c13042$b19e4940$160d85a5@mercurykr.com> <3B8CB98F.7B32C87B@multitech.co.in> <011501c13072$98507820$160d85a5@mercurykr.com>
Subject: unsuscribe
Date: Thu, 30 Aug 2001 09:10:30 +0530
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


Imagination is more important than knowledge..
****************************************
Vijayalakshmi B
Software Engineer
Infosys Technologies LTD.




From owner-mpls@UU.NET  Thu Aug 30 02:37:21 2001
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 CAA06766
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 02:37:20 -0400 (EDT)
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 QQlegw29243;
	Thu, 30 Aug 2001 06:38:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlegw25709
	for mpls-outgoing; Thu, 30 Aug 2001 06:38: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 QQlegw25704
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 06:37:58 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 QQlegw28050
	for <mpls@UU.NET>; Thu, 30 Aug 2001 06:37:46 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlegw28181
	for <mpls@UU.NET>; Thu, 30 Aug 2001 06:37:46 GMT
Received: from multitech.co.in (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with ESMTP id f7U6dCu25604;
	Thu, 30 Aug 2001 12:09:13 +0530
Message-ID: <3B8DE043.DFD74FE3@multitech.co.in>
Date: Thu, 30 Aug 2001 12:12:11 +0530
From: abhay <abhay@multitech.co.in>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Neelesh Dwivedi <neelesh@mercurykr.com>
CC: mpls@UU.NET, cheenu@alphion.com
Subject: Re: LSP ID in LSR MIB
References: <007001c13042$b19e4940$160d85a5@mercurykr.com> <3B8CB98F.7B32C87B@multitech.co.in> <011501c13072$98507820$160d85a5@mercurykr.com>
Content-Type: multipart/alternative;
 boundary="------------CD164BB2659A1523559FEEEA"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------CD164BB2659A1523559FEEEA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neelesh,

       On the piggyback you have the Ingress (Source Address) and the local lspid

       along all the routers which serviced the LSP request message.

       This is the key.

       Hope this helps.

       Regards,

       Abhay





--------------CD164BB2659A1523559FEEEA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<pre>Neelesh,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; On the piggyback you have the Ingress (Source Address) and the local lspid</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; along all the routers which serviced the LSP request message.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is the key.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope this helps.</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</pre>

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Abhay</pre>

<pre>&nbsp;</pre>
&nbsp;</html>

--------------CD164BB2659A1523559FEEEA--



From owner-mpls@UU.NET  Thu Aug 30 02:41:26 2001
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 CAA06868
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 02:41:26 -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 QQlegw17477;
	Thu, 30 Aug 2001 06:42:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlegw25985
	for mpls-outgoing; Thu, 30 Aug 2001 06:42:07 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 QQlegw25978
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 06:42:04 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 QQlegw23454
	for <mpls@uu.net>; Thu, 30 Aug 2001 06:41:45 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlegw04543
	for <mpls@uu.net>; Thu, 30 Aug 2001 06:41:46 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <R2T04LY9>; Thu, 30 Aug 2001 12:14:56 +0500
Message-ID: <751B6DD7A243D511AB9F0002557C5687CAA016@HUAWEIMAIL>
From: Bhupesh Bajaj <bhupeshb@in.huawei.com>
To: mpls@UU.NET
Date: Thu, 30 Aug 2001 12:14:55 +0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13123.786BC670"
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_01C13123.786BC670
Content-Type: text/plain;
	charset="iso-8859-1"





------_=_NextPart_001_01C13123.786BC670
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.2653.12">
<TITLE></TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C13123.786BC670--


From owner-mpls@UU.NET  Thu Aug 30 05:05:57 2001
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 FAA08318
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 05:05:57 -0400 (EDT)
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 QQlehg06658;
	Thu, 30 Aug 2001 09:06:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlehg02805
	for mpls-outgoing; Thu, 30 Aug 2001 09:06: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 QQlehg02748
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 09:06:19 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 QQlehg28433
	for <mpls@uu.net>; Thu, 30 Aug 2001 09:05:28 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQlehg09941
	for <mpls@uu.net>; Thu, 30 Aug 2001 09:05:30 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id FAA23898; Thu, 30 Aug 2001 05:05:55 -0400
Date: Thu, 30 Aug 2001 05:05:55 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
Reply-To: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Subject: LSR APIs for Linux
Message-ID: <Pine.SUN.3.96.1010830044657.21097B-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

There are LDP sample source codes available on internet. Are there any
sources for LSR APIs which are used for label/forwarding/MPLS_stack
operation procedures for Linux or any other sample MPLS forwarding 
application ? If yes, where can I find them ?

Regards,
Hemant







From owner-mpls@UU.NET  Thu Aug 30 06:29:10 2001
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 GAA09022
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 06:29:10 -0400 (EDT)
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 QQlehm23540;
	Thu, 30 Aug 2001 10:30:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlehm27771
	for mpls-outgoing; Thu, 30 Aug 2001 10:30:01 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 QQlehl27734
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 10:29: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 QQlehl23295
	for <mpls@UU.NET>; Thu, 30 Aug 2001 10:29:32 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlehl22176
	for <mpls@UU.NET>; Thu, 30 Aug 2001 10:29:31 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <RRR6TCK5>; Thu, 30 Aug 2001 15:56:16 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D71E6885@mailserver.netbrahma.com>
From: Manoj Agiwal <ManojA@netbrahma.com>
To: rsvp@isi.edu, mpls@UU.NET
Subject: RE: RSVP over ATM
Date: Thu, 30 Aug 2001 15:56:15 +0530
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 ,
      Do we use PVC or SVC for transmission of RSVP messages.
      Which VPI / VCI should be used for  transmission of  RSVP messages
over ATM in case of PVC.
       Is there any RFC that mentions this .
Regards ,
Manoj


> ----------
> From: 	Khuzema Pithewan[SMTP:KhuzemaP@netbrahma.com]
> Sent: 	Tuesday, August 28, 2001 12:56 PM
> To: 	rsvp@ISI.EDU; mpls@UU.NET
> Subject: 	RSVP over ATM
> 
> Hi,
> 
> Over ATM, How does RSVP message travel on network, is it as IP packet
> broken
> down in cells or as RSVP message itself broken down in cells.?
> 
> Is it required to use AAL5 sockets to send/receive RSVP  message?
> 
> Khuzema.
> ------------------------------------------------
> Net Brahma Technologies Private Limited
> Internext Networking Software
> A Microland Group Company
> 777, 3rd 'a' cross, 18th Main 
> Koramangala VI th block
> Bangalore-95
> Phone no.s - (080) 5521451 / 5525011 / 5525012  Ext. 232
> Fax no        - (080) 5537233 
> email : khuzemap@netbrahma.com
> www.netbrahma.com
> 


From owner-mpls@UU.NET  Thu Aug 30 09:51:05 2001
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 JAA16986
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 09:51:05 -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 QQlehz09546;
	Thu, 30 Aug 2001 13:52:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlehz08026
	for mpls-outgoing; Thu, 30 Aug 2001 13:51: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 QQlehz08019
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 13:51:36 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 QQlehz01266
	for <mpls@uu.net>; Thu, 30 Aug 2001 13:50:51 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlehz20836
	for <mpls@uu.net>; Thu, 30 Aug 2001 13:50:53 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id NAA17788
	for <mpls@uu.net>; Thu, 30 Aug 2001 13:50:50 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001083006501011891
 for <mpls@uu.net>; Thu, 30 Aug 2001 06:50:10 -0700
Received: from alpha.igk.intel.com ([172.28.168.68]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RBZXK3DQ; Thu, 30 Aug 2001 06:50:49 -0700
Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19)
	id <NMB565MZ>; Thu, 30 Aug 2001 15:50:48 +0200
Message-ID: <413FBB0BA5AED1119122000083234B1A01D6E11C@alpha.igk.intel.com>
From: "Golichowski, Adam" <Adam.Golichowski@intel.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Cc: "Bisewski, Radoslaw" <Radoslaw.Bisewski@intel.com>
Subject: MPLS-LSR-MIB and MPLS-TE-MIB.
Date: Thu, 30 Aug 2001 15:50:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,
I have a some doubts about the semantics of MPLS-LSR-MIB and MPLS-TE-MIB.
Can someone answer some of the questions below? Thanks.

 -- Adam

in MPLS-LSR-MIB extracted from draft-ietf-mpls-lsr-mib-07.txt:

1. The "mplsInterfaceConfTable" contains
"mplsInterfaceLabelParticipationType" object
   of "BITS" type which is not defined or imported.

2. Can auxiliary objects ("mplsInSegmentIfIndex" and "mplsInSegmentLabel")
   in row "mplsInSegmentEntry", "mplsOutSegmentIndex" in
"mplsOutSegmentEntry" and
   "mplsXCIndex" in "mplsXCEntry" have "accessible-for-notify" value for
MAX-ACCESS?

3. Can auxiliary objects ("mplsXCIndex", "mplsInSegmentIfIndex",
   "mplsInSegmentLabel" and "mplsOutSegmentIndex") be used in notifications
   "mplsXCUp" and "mplsXCDown"?


in MPLS-TE-MIB extracted from draft-ietf-mpls-te-mib-07.txt

1. Scalar object "mplsTunnelTEDistProto" and columnar object
"mplsTunnelSessionAttributes"
   in row "mplsTunnelEntry" are of BITS type which is not defined or
imported.

2. Syntax specification of "mplsTunnelCRLDPResFrequency" object in sequence
   "MplsTunnelCRLDPResEntry" is incorrect.

3. Can auxiliary objects ("mplsTunnelIndex", "mplsTunnelInstance",
   "mplsTunnelIngressLSRId", "mplsTunnelEgressLSRId") in "mplsTunnelEntry"
   have "accessible-for-notify" value for MAX-ACCESS?

4. The default value for a bit mask "mplsTunnelSessionAttributes" should be
specified
   by the label ("fastReroute") of the integer value rather than by its
value.

5. Can auxiliary objects ("mplsTunnelIndex", "mplsTunnelInstance",
  "mplsTunnelIngressLSRId" and "mplsTunnelEgressLSRId") be used in
notifications
  ("mplsTunnelUp", "mplsTunnelDown", "mplsTunnelRerouted" and
"mplsTunnelReoptimized")?



From owner-mpls@UU.NET  Thu Aug 30 11:36:23 2001
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 LAA19757
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 11:36:23 -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 QQleig20952;
	Thu, 30 Aug 2001 15:37:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQleig23089
	for mpls-outgoing; Thu, 30 Aug 2001 15:37:01 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 QQleig23057
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 30 Aug 2001 15:36:50 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 QQleig12364
	for <mpls@UU.NET>; Thu, 30 Aug 2001 15:34:21 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f73.law11.hotmail.com [64.4.17.73])
	id QQleig26523
	for <mpls@UU.NET>; Thu, 30 Aug 2001 15:34:23 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 30 Aug 2001 08:34:20 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;
	Thu, 30 Aug 2001 15:34:19 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" <irfanlateef@hotmail.com>
To: eric.gray@sandburst.com
Cc: tnadeau@cisco.com, mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
Date: Thu, 30 Aug 2001 11:34:19 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F73tpe1OWhMnU5JzUID00001014@hotmail.com>
X-OriginalArrivalTime: 30 Aug 2001 15:34:20.0027 (UTC) FILETIME=[3C8CC4B0:01C13169]
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

You have brought out all the right issues with trap but also
suggested a probable solution which looks attractive to me for the
following reasons.

1. We allow the NMS/user to set the granularity and hold-off timer
based on what he/she thinks is necessary for his/her application
and the desirable number of traps.
2. We cannot and donot need to guess the typical setup size and judge 
whether it is going to be beneficial at this point.
3. The user can set the thresholds high enough to not see any traps
or even disbale this trap and use polling before path computation,
or compare the results and go one way or the other or both ;).

My concern with polling was, in a large network say 100s of links, the
NMS would be polling ALL THE LINKS even when the values may
not have changed taxing the control channel.
Where as if an optional trap is provided then NMS could judiciously
choose the values which suit its appl and save control bandwidth.

Actually the analogy is good. It is the other way I am looking at it.
The manager is making long term resources allocation but want to
have up to minute data when he is making a decision, which is typical
with managers.

Thanks and Regards,
Irfan Lateef


>From: Eric Gray <eric.gray@sandburst.com>
>To: Irfan Lateef <irfanlateef@hotmail.com>
>CC: tnadeau@cisco.com, mpls@UU.NET
>Subject: Re: LSR-MIB - AvailableBandwidth ?
>Date: Wed, 29 Aug 2001 19:01:39 -0400
>
>Irfan,
>
>     In this case, the trap storm would arise from the fact that you
>have not defined an appropriate granularity for what you mean by
>'change' (under this circumstance, every little hiccup in a network
>would inundate the NMS with too much information).  Even if you
>have picked an appropriate granularity, you should define a minimum
>hold off delay in announcing yet more changes (otherwise, the NMS
>would still be processing the data from one trap when it is over-run
>with data from subsequent traps).
>
>     It is likely that an appropriate granularity for change - dictated
>by a need to avoid having a lot of traps sent all at once - will be
>larger than the typical size of a setup.  Consequently, a change
>large enough to block a typical setup will be too small to report
>under some circumstances.  In addition, if any sort of timer is to
>be used, then why not have the NMS poll the NEs?  This is what
>I meant by the trap approach being more costly than beneficial.
>
>     I think you would have to make up your mind who is going to be
>in control of your TE setup.  If, as you say, an NMS can manage it
>because of a protracted time scale - and an operator decides to
>do it this way - then only the NMS should manage TE setup and
>tear down.  If that is the case, then where would the change you
>want to be notified of come from?  On the other hand, if you need
>to use a more dynamic approach, then the NMS should be limited
>to policy level management.  Otherwise, it would be like having a
>manager that makes specific resource allocation decisions based
>on monthly trend data and an annual budget for individual projects
>with an average project life cycle of 3 days.
>
>--
>Eric Gray
>
>You wrote:
>
> > Hi,
> >
> > I will try to reply Cheenu, Tom and Eric in one mail.
> >
> > Alarm or Trap Storms are considered to be undesirable during
> > failures because all of them tend to convey the same information during
> > failure and hinder any corrective acton by congesting the
> > network. Even worse sometimes they are only a side effect of a
> > failure in the network downstream.
> > This generally happens in transport networks because of
> > the ability of the network to propagate the defect in forward and
> > backward direction. Where as in the present case, if an LSP is setup
> > across N links, then receiving N traps indicating a change in the
> > available bandwidth of each link respectively is not redundant and
> > undesirable but necessary. The debatable point could when should it
> > be sent. Also as Eric pointed if this is used for monitoring, even
> > then this has to updated at some agreeable interval period.
> >
> > The second point I would like to make is the assumption that the
> > networks under consideration are fairly stable, in the sense that the
> > time scales for setup and teardown are fairly large. For example,
> > an enterprise customer requesting a 1 Gb pipe from point A to B.
> >
> > As the number contraints and the number of nodes increase, the
> > optimization algorithm may become computationally expensive to fit in
> > the device, hence a desire to compute the bigger bw LSP with more
> > efficient mechanism off-line.
> >
> > Addressing the time lag issue. Assume an LSP is being setup
> >
> > A---B---C---D---E
> >
> > While you are computing a path in A, from A to E, if C setup another
> > LSP from C to D and the OSPF update has not yet occured, you still
> > have the same problem. So let us assume we are operating with the
> > same assumption of time granularity irrespective of where we are
> > computing the path and also assume that the network does not change
> > between computation and setup.
> >
> > Eric, you are right. for the reasons mentioned I am proposing TE
> > computation off-line in NMS and then setup from ingress and I am
> > trying to bring about the necessary coordination by the proposed
> > TRAP. Autonomous notifications will address the granularity and
> > reporting cycle issue.
> >
> > So sending the notification and making the same assumptions as you
> > would have made while computing the path in the device could solve
> > the problem I am trying to impress upon the list and the authors.
> >
> > However taking a cue from this discussion, the other method to do
> > the calculation  could be to retrieve the whole OSPF-TE MIB from
> > the ingress node and compute the path. But that also has some of the
> > caveats discussed above. Also I am not sure what would be the size
> > of such a MIB in large network.
> >
> > Regards,
> >
> > Irfan Lateef
> >
> > P.S : Cheenu, Can you clarify the passive OSPF suggestion ,
> >       I did not understand your exact idea.
> >
> > >From: Eric Gray <eric.gray@sandburst.com>
> > >To: Thomas Nadeau <tnadeau@cisco.com>
> > >CC: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
> > >Subject: Re: LSR-MIB - AvailableBandwidth ?
> > >Date: Wed, 29 Aug 2001 16:43:24 -0400
> > >
> > >Irfan,
> > >
> > >     Just to add to what Tom says, there are other scary aspects of 
>this
> > >question.
> > >For one, your question seems to assume that an NMS is being used to 
>compute
> > >paths, but that some other mechanism is being used to set them up and 
>there
> > >is
> > >apparently no coordination between the two mechanisms.  For another, in
> > >order
> > >to avoid the trap storms that Cheenu mentioned, you'd have to include
> > >notions
> > >of change granularity and minimum reporting cycle time.  This quickly
> > >starts to
> > >be more costly than beneficial.
> > >
> > >--
> > >Eric Gray
> > >
> > >Thomas Nadeau wrote:
> > >
> > > > At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
> > > > >Cheenu et al,
> > > > >
> > > > >The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt 
>contains
> > > > >the attribute mplsInterfaceAvailableBandwidth
> > > > >
> > > > >Typically the management application can use this attribute while
> > > > >computing a constrained TE path or an LSP path.
> > > > >Now if the signalling protocol is also setting up LSP on this
> > > > >interface at or around the same time, the management application
> > > > >would be computing a path based on incoreect value because the
> > > > >value of this attribute may not be current.
> > > > >
> > > > >My question is do we need a trap, like AvailableBandwidthChange,
> > > > >to be sent to the NMS whenever a LSP is setup/teardown on an
> > > > >interface. In the absence of such a mechanism the NMS may need to
> > > > >get the value of all the interface in the network before it 
>computes
> > > > >the path even if the values may not have changed.
> > > > >
> > > > >So in order to keep the NMS in sync with the NE I think a trap is
> > > > >needed. If you think this is not the way to keep the NMS in sync 
>with
> > > > >the state of the NE then what is your suggestion.
> > > > >Appreciate your comments.
> > > >
> > > >          I think that you raise an important point, but I would
> > > > first think carefully about whether or not you want to do
> > > > what you describe. What you seem to want to do are
> > > > ad hoc off-line TE calculations and then push them down to
> > > > the devices. First, as you mention there is a time lag between
> > > > when the bandwidth changes and when the NMS can know
> > > > about it. This is why it might be a better idea to let the
> > > > routers do the path computation after feeding them some
> > > > constraints (i.e.: end points and bandwidth requirements).
> > > >
> > > >          Now, if you want to truly do what you describe, I don't
> > > > think that adding a notification will help prevent the
> > > > timing problem, since the bandwidth can still change
> > > > between the time that the notification is sent and processed
> > > > by the NMS. Furthermore, since notifications are typically
> > > > unreliable, they can be lost, and thus we have the same problem
> > > > even after implementing such a notification.
> > > >
> > > >          --Tom
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Thu Aug 30 20:39:45 2001
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 UAA01200
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 20:39:45 -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 QQlejq21887;
	Fri, 31 Aug 2001 00:40:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlejq19977
	for mpls-outgoing; Fri, 31 Aug 2001 00:40: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 QQlejq19972
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 00:40:09 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 QQlejq16892
	for <mpls@uu.net>; Fri, 31 Aug 2001 00:39:47 GMT
Received: from exc-sc1.yagosys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQlejq12030
	for <mpls@uu.net>; Fri, 31 Aug 2001 00:39:49 GMT
Received: by exc-sc1 with Internet Mail Service (5.5.2653.19)
	id <QZL3SBP9>; Thu, 30 Aug 2001 17:40:13 -0700
Message-ID: <329F35B18824D511B9C30008C733955828F508@exc-sc1>
From: "Haridass, Govind" <gharidas@riverstonenet.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question in LSR MIB...
Date: Thu, 30 Aug 2001 17:40:12 -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,

	I have an issue regarding the LSR MIB.

	In case of L2 MPLS, there is no way to represent the
	next-hop-mac.  How do we incorporate this ?

	Thanks.

===
With Warm Regards,
Govind,
Riverstone Networks.
http://www.riverstonenet.com/




From owner-mpls@UU.NET  Thu Aug 30 23:48:39 2001
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 XAA05464
	for <mpls-archive@lists.ietf.org>; Thu, 30 Aug 2001 23:48:39 -0400 (EDT)
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 QQlekd09378;
	Fri, 31 Aug 2001 03:49:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlekd29283
	for mpls-outgoing; Fri, 31 Aug 2001 03:49: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 QQlekd29278
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 03:49:01 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 QQlekd23095
	for <mpls@UU.NET>; Fri, 31 Aug 2001 03:48:55 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQlekd03729
	for <mpls@UU.NET>; Fri, 31 Aug 2001 03:48:53 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7V3mc715072;
	Fri, 31 Aug 2001 05:48:39 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256AB9.0014EDF7 ; Fri, 31 Aug 2001 05:48:36 +0200
X-Lotus-FromDomain: ALCATEL
To: "Haridass, Govind" <gharidas@riverstonenet.com>
cc: "'mpls@uu.net'" <mpls@UU.NET>, pierre.debuysscher@alcatel.be
Message-ID: <C1256AB9.0014ED16.00@Bemail06.net.alcatel.be>
Date: Fri, 31 Aug 2001 05:48:31 +0200
Subject: Re: Question in LSR MIB...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




Govind,

The MAC@ itself is indeed not present in the mpls lsr mib. However, it is also not needed since the next hop ip@ is present (see 'mplsOutSegmentNextHopIpv4Addr' object in extract included below). This ip@ is mapped to a MAC@ using the ipNetToMediaTable in
RFC 2011.

Regards,

     Francis.

-------------------

       MplsOutSegmentEntry ::= SEQUENCE {
              mplsOutSegmentIndex                Integer32,
              mplsOutSegmentIfIndex              InterfaceIndex,
              mplsOutSegmentPushTopLabel         TruthValue,
              mplsOutSegmentTopLabel             MplsLabel,
              mplsOutSegmentNextHopIpAddrType    InetAddressType,
              mplsOutSegmentNextHopIpv4Addr      InetAddressIPv4,
              mplsOutSegmentNextHopIpv6Addr      InetAddressIPv6,
              mplsOutSegmentXCIndex              Integer32,
              mplsOutSegmentOwner                MplsObjectOwner,
              mplsOutSegmentTrafficParamPtr      RowPointer,
              mplsOutSegmentRowStatus            RowStatus,
              mplsOutSegmentStorageType          StorageType
         }





"Haridass, Govind" <gharidas@riverstonenet.com> on 31/08/2001 02:40:12
                                                              
                                                              
                                                              
 To:      "'mpls@uu.net'" <mpls@UU.NET>                       
                                                              
 cc:      (bcc: Francis ARTS/BE/ALCATEL)                      
                                                              
                                                              
                                                              
 Subject: Question in LSR MIB...                              
                                                              





Hi,

     I have an issue regarding the LSR MIB.

     In case of L2 MPLS, there is no way to represent the
     next-hop-mac.  How do we incorporate this ?

     Thanks.

===
With Warm Regards,
Govind,
Riverstone Networks.
http://www.riverstonenet.com/







From owner-mpls@UU.NET  Fri Aug 31 02:01:58 2001
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 CAA17800
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 02:01:58 -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 QQlekm02579;
	Fri, 31 Aug 2001 06:02:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlekm24930
	for mpls-outgoing; Fri, 31 Aug 2001 06:02: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 QQlekm24913
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 06:02:14 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 QQlekm21264
	for <mpls@UU.NET>; Fri, 31 Aug 2001 06:02:02 GMT
From: chetan.kumar@wipro.com
Received: from iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: iisc.ernet.in [144.16.64.3])
	id QQlekm01735
	for <mpls@UU.NET>; Fri, 31 Aug 2001 06:02:03 GMT
Received: from protocol.ece.iisc.ernet.in (IDENT:root@protocol.ece.iisc.ernet.in [144.16.64.120])
	by iisc.ernet.in (8.9.2/8.9.0) with ESMTP id LAA49337;
	Fri, 31 Aug 2001 11:38:05 +0530 (IST)
Received: from localhost (chetan@localhost)
	by protocol.ece.iisc.ernet.in (8.11.0/8.11.0) with ESMTP id f7V6DWC07899;
	Fri, 31 Aug 2001 11:43:32 +0530
X-Authentication-Warning: protocol.ece.iisc.ernet.in: chetan owned process doing -bs
Date: Fri, 31 Aug 2001 11:43:32 +0530 (IST)
X-Sender: chetan@protocol.ece.iisc.ernet.in
Reply-To: chetan.kumar@wipro.com
To: "Hemant P. Kelkar" <hemant@cyberspace.org>
cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: LSR APIs for Linux
In-Reply-To: <Pine.SUN.3.96.1010830044657.21097B-100000@grex.cyberspace.org>
Message-ID: <Pine.LNX.4.21.0108311141140.7403-100000@protocol.ece.iisc.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Thu, 30 Aug 2001, Hemant P. Kelkar wrote:

*>Hi All,
*>
*>There are LDP sample source codes available on internet. Are there any

Hi,
	Have a look at http://sourceforge.net/projects/mpls-linux/
this has the appropriate implementation of forwarding for Linux kernel.


*>sources for LSR APIs which are used for label/forwarding/MPLS_stack
*>operation procedures for Linux or any other sample MPLS forwarding 
*>application ? If yes, where can I find them ?

-- 
Thanks
chetan . S




From owner-mpls@UU.NET  Fri Aug 31 03:11:13 2001
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 DAA26116
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 03:11:13 -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 QQlekq06685;
	Fri, 31 Aug 2001 07:12:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlekq27103
	for mpls-outgoing; Fri, 31 Aug 2001 07:11:50 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 QQlekq27092
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 07:11:46 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 QQlekq12096
	for <mpls@uu.net>; Fri, 31 Aug 2001 07:10:48 GMT
Received: from smtp018.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp018.mail.yahoo.com [216.136.174.115])
	id QQlekq05054
	for <mpls@uu.net>; Fri, 31 Aug 2001 07:10:46 GMT
Received: from unknown (HELO Manav) (203.200.20.224)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Aug 2001 07:10:45 -0000
X-Apparently-From: <marelines@yahoo.com>
Message-ID: <0b2d01c131ec$781ca2b0$b4036c6b@Manav>
From: "Mareline Sheldon" <marelines@yahoo.com>
To: <mpls@UU.NET>
Subject: Bindings ?
Date: Fri, 31 Aug 2001 12:43:06 +0530
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.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
I am a newbie and i am not sure as to what exactly is the difference between
Upstream and Downstream binding ?
Please can anyone of you explain ?

Rgds,
Mary



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-mpls@UU.NET  Fri Aug 31 06:52:52 2001
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 GAA27713
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 06: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 QQlelf24458;
	Fri, 31 Aug 2001 10:53:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelf07941
	for mpls-outgoing; Fri, 31 Aug 2001 10:53: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 QQlelf07934
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 10:53:20 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 QQlelf25161
	for <mpls@uu.net>; Fri, 31 Aug 2001 10:52:24 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQlelf22785
	for <mpls@uu.net>; Fri, 31 Aug 2001 10:52:25 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7VAqEP01058;
	Fri, 31 Aug 2001 12:52:14 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256AB9.003BB533 ; Fri, 31 Aug 2001 12:52:10 +0200
X-Lotus-FromDomain: ALCATEL
To: gharidas@riverstonenet.com
cc: mpls@UU.NET, pierre.debuysscher@alcatel.be
Message-ID: <C1256AB9.003BB489.00@Bemail06.net.alcatel.be>
Date: Fri, 31 Aug 2001 12:52:02 +0200
Subject: Re: Question in LSR MIB...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




---------------------- Forwarded by Francis ARTS/BE/ALCATEL on 31/08/2001 12:50 ---------------------------


Francis ARTS
31/08/2001 05:48

To:   "Haridass, Govind" <gharidas@riverstonenet.com>
cc:   "'mpls@uu.net'" <mpls@UU.NET>, pierre.debuysscher@alcatel.be
Subject:  Re: Question in LSR MIB...  (Document link: Francis ARTS)


Govind,

The MAC@ itself is indeed not present in the mpls lsr mib. However, it is also not needed since the next hop ip@ is present (see 'mplsOutSegmentNextHopIpv4Addr' object in extract included below). This ip@ is mapped to a MAC@ using the ipNetToMediaTable in
RFC 2011.

Regards,

     Francis.

-------------------

       MplsOutSegmentEntry ::= SEQUENCE {
              mplsOutSegmentIndex                Integer32,
              mplsOutSegmentIfIndex              InterfaceIndex,
              mplsOutSegmentPushTopLabel         TruthValue,
              mplsOutSegmentTopLabel             MplsLabel,
              mplsOutSegmentNextHopIpAddrType    InetAddressType,
              mplsOutSegmentNextHopIpv4Addr      InetAddressIPv4,
              mplsOutSegmentNextHopIpv6Addr      InetAddressIPv6,
              mplsOutSegmentXCIndex              Integer32,
              mplsOutSegmentOwner                MplsObjectOwner,
              mplsOutSegmentTrafficParamPtr      RowPointer,
              mplsOutSegmentRowStatus            RowStatus,
              mplsOutSegmentStorageType          StorageType
         }




"Haridass, Govind" <gharidas@riverstonenet.com> on 31/08/2001 02:40:12
                                                              
                                                              
                                                              
 To:      "'mpls@uu.net'" <mpls@UU.NET>                       
                                                              
 cc:      (bcc: Francis ARTS/BE/ALCATEL)                      
                                                              
                                                              
                                                              
 Subject: Question in LSR MIB...                              
                                                              





Hi,

     I have an issue regarding the LSR MIB.

     In case of L2 MPLS, there is no way to represent the
     next-hop-mac.  How do we incorporate this ?

     Thanks.

===
With Warm Regards,
Govind,
Riverstone Networks.
http://www.riverstonenet.com/









From owner-mpls@UU.NET  Fri Aug 31 09:32:05 2001
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 JAA04854
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 09:32:04 -0400 (EDT)
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 QQlelq13126;
	Fri, 31 Aug 2001 13:32:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelq14245
	for mpls-outgoing; Fri, 31 Aug 2001 13:32:09 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 QQlelq14240
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 13:32:08 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 QQlelq02730
	for <mpls@uu.net>; Fri, 31 Aug 2001 13:31:19 GMT
Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pilgrim.cisco.com [171.69.204.12])
	id QQlelq06250
	for <mpls@uu.net>; Fri, 31 Aug 2001 13:31:17 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50])
	by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA24284
	for <mpls@uu.net>; Fri, 31 Aug 2001 09:31:18 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA10758 for mpls@uu.net; Fri, 31 Aug 2001 09:30:45 -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 QQlelp14094
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 13:29:41 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 QQlelp28632
	for <mpls@uu.net>; Fri, 31 Aug 2001 13:29:22 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlelp09098
	for <mpls@uu.net>; Fri, 31 Aug 2001 13:29:23 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <R0ALQY86>; Fri, 31 Aug 2001 18:56:08 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D76B2A72@mailserver.netbrahma.com>
From: Binita Jha <BinitaJ@netbrahma.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: MPLS over FR.
Date: Fri, 31 Aug 2001 18:56:08 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

I have a doubt regarding MPLS over FR.
1) RFC 3034 says that the top label (DLCI) carries implicitly information
about the network protocol type. but how does it indicate about if the shim
header is present or not?

2) Also if the shim header is present then how do we know abt what network
protocol is present?

Kindly send me the answer if anyone has.
Regards
Binita



From owner-mpls@UU.NET  Fri Aug 31 10:10:09 2001
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 KAA06122
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:10:09 -0400 (EDT)
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 QQlels29766;
	Fri, 31 Aug 2001 14:10:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlels05255
	for mpls-outgoing; Fri, 31 Aug 2001 14:09:50 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 QQlels05220
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:09:32 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 QQlels23367
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:09:17 GMT
Received: from tju.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailserver.tju.edu.cn [202.113.15.13])
	id QQlels14302
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:09:08 GMT
Received: from rose.tju.edu.cn (rose.tju.edu.cn [202.113.0.9])
	by tju.edu.cn (8.9.1b+Sun/8.9.1) with ESMTP id WAA18855
	for <mpls@UU.NET>; Fri, 31 Aug 2001 22:00:34 +0800 (CST)
Received: from rose ([202.113.4.43])
	by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id VAA16655
	for <mpls@UU.NET>; Fri, 31 Aug 2001 21:54:29 +0800
Message-Id: <200108311354.VAA16655@rose.tju.edu.cn>
Date: Fri, 31 Aug 2001 22:7:35 +0800
From: STONE  CHEN <stone_ch@eyou.com>
To: "mpls@UU.NET" <mpls@UU.NET>
Subject: Routing with Preemption
X-mailer: FoxMail 3.11 Release [cn]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_Dragon533735713304_====="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

--=====_Dragon533735713304_=====
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit

Hello,

Have you known to any papers or pointers to the routing algorithms 
with "route-preemption" allowed? The network domain might be either MPLS or ATM. 
Thanks.

Rae

--=====_Dragon533735713304_=====
Content-Type: text/html; name="unknown(1).HTM"
Content-Disposition: attachment; filename="unknown(1).HTM"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLDwv
Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPkhhdmUgeW91IGtub3duIHRvIGFueSBwYXBlcnMgb3IgcG9pbnRlcnMgdG8g
dGhlIHJvdXRpbmcgDQphbGdvcml0aG1zIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
PndpdGggInJvdXRlLXByZWVtcHRpb24iIGFsbG93ZWQ/IDwvRk9OVD48Rk9OVCBzaXplPTI+VGhl
IA0KbmV0d29yayBkb21haW4mbmJzcDttaWdodCBiZSBlaXRoZXIgTVBMUyZuYnNwO29yIEFUTS4g
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzLjwvRk9OVD48L0RJVj4NCjxE
SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJh
ZTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

--=====_Dragon533735713304_=====--



From owner-mpls@UU.NET  Fri Aug 31 10:11:12 2001
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 KAA06148
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:11:12 -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 QQlels15130;
	Fri, 31 Aug 2001 14:09:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlels05169
	for mpls-outgoing; Fri, 31 Aug 2001 14:09:05 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 QQlels05136
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:08:51 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 QQlels19425
	for <mpls@uu.net>; Fri, 31 Aug 2001 14:07:54 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQlels26519
	for <mpls@uu.net>; Fri, 31 Aug 2001 14:07:57 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA02112 for mpls@uu.net; Fri, 31 Aug 2001 10:07:53 -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 QQlels04948
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:07:19 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 QQlels27467
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:06:45 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 QQlels24867
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:06:48 GMT
Received: (qmail 26144 invoked by uid 104); 31 Aug 2001 14:06:44 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.398196 secs); 31/08/2001 07:06:44
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 31 Aug 2001 14:06:44 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f7VE6hM07030;
	Fri, 31 Aug 2001 07:06:43 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <RBMNR15F>; Fri, 31 Aug 2001 07:07:46 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CC9CA@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Binita Jha'" <BinitaJ@netbrahma.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: MPLS over FR.
Date: Fri, 31 Aug 2001 07:07: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

Hi,

Comments in-line:

> -----Original Message-----
> From: Binita Jha [mailto:BinitaJ@netbrahma.com]
> Sent: Friday, August 31, 2001 9:26 AM
> To: 'mpls@uu.net'
> Subject: MPLS over FR.
> 
> 
> I have a doubt regarding MPLS over FR.
> 1) RFC 3034 says that the top label (DLCI) carries implicitly 
> information
> about the network protocol type. but how does it indicate 
> about if the shim
> header is present or not?

The shim header MUST always be present, even if the packet has one label. Only the S, EXP and TTL values of the top label of the shim header are used. The top label's 20-bit label value is not used at all, rather the DLCI is used instead.

> 
> 2) Also if the shim header is present then how do we know abt 
> what network
> protocol is present?

A DLCI value is bound to a specific network protocol (could be done by partitioning of DLCI space). If the S=1 in the top label, then it means that the payload has the same network protocol. If the S=0, then it means that another label is present and the payload is MPLS.

Yours,
-Shahram

> 
> Kindly send me the answer if anyone has.
> Regards
> Binita
> 



From owner-mpls@UU.NET  Fri Aug 31 10:20:46 2001
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 KAA06430
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:20:46 -0400 (EDT)
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 QQlelt13064;
	Fri, 31 Aug 2001 14:20:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelt06528
	for mpls-outgoing; Fri, 31 Aug 2001 14:20: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 QQlelt06523
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:20:26 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 QQlelt26043
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:18:04 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQlelt27757
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:18:01 GMT
Message-ID: <3B8F9C94.41A9247B@sandburst.com>
Date: Fri, 31 Aug 2001 10:17:57 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Irfan Lateef <irfanlateef@hotmail.com>
Cc: mpls@UU.NET
Subject: Re: LSR-MIB - AvailableBandwidth ?
References: <F73tpe1OWhMnU5JzUID00001014@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan,

    I was not suggesting a probable solution, I was pointing out problems and
making the point that solutions to these problems produce scenarios in which
it does not make sense to introduce the problem in the first place.

    If an NMS needs up-to-date information on the state of specific network
elements in order to make specific resource allocation decisions, then it is
far better off going and asking those specific nodes for that information then
it would be being inundated by unneeded information from network elements
about which it doesn't currently care.  This is particularly true if the period
during which this information might be delivered automatically must be
deliberatly prolonged to prevent the NMS from being overcome by too much
(mostly unecessary) information.  In this case, the frequency at which the
NMS may receive unsolicited updates (from the network elements it cares
about at any given instant) is necessarily less than the frequency at which
it may obtain this information by simply asking for it.

    The only solution that I suggested was to choose the right tools for the job

at hand and use them correctly.

--
Eric Gray

You wrote:

> Eric,
>
> You have brought out all the right issues with trap but also
> suggested a probable solution which looks attractive to me for the
> following reasons.
>
> 1. We allow the NMS/user to set the granularity and hold-off timer
> based on what he/she thinks is necessary for his/her application
> and the desirable number of traps.
> 2. We cannot and donot need to guess the typical setup size and judge
> whether it is going to be beneficial at this point.
> 3. The user can set the thresholds high enough to not see any traps
> or even disbale this trap and use polling before path computation,
> or compare the results and go one way or the other or both ;).
>
> My concern with polling was, in a large network say 100s of links, the
> NMS would be polling ALL THE LINKS even when the values may
> not have changed taxing the control channel.
> Where as if an optional trap is provided then NMS could judiciously
> choose the values which suit its appl and save control bandwidth.
>
> Actually the analogy is good. It is the other way I am looking at it.
> The manager is making long term resources allocation but want to
> have up to minute data when he is making a decision, which is typical
> with managers.
>
> Thanks and Regards,
> Irfan Lateef
>
> >From: Eric Gray <eric.gray@sandburst.com>
> >To: Irfan Lateef <irfanlateef@hotmail.com>
> >CC: tnadeau@cisco.com, mpls@UU.NET
> >Subject: Re: LSR-MIB - AvailableBandwidth ?
> >Date: Wed, 29 Aug 2001 19:01:39 -0400
> >
> >Irfan,
> >
> >     In this case, the trap storm would arise from the fact that you
> >have not defined an appropriate granularity for what you mean by
> >'change' (under this circumstance, every little hiccup in a network
> >would inundate the NMS with too much information).  Even if you
> >have picked an appropriate granularity, you should define a minimum
> >hold off delay in announcing yet more changes (otherwise, the NMS
> >would still be processing the data from one trap when it is over-run
> >with data from subsequent traps).
> >
> >     It is likely that an appropriate granularity for change - dictated
> >by a need to avoid having a lot of traps sent all at once - will be
> >larger than the typical size of a setup.  Consequently, a change
> >large enough to block a typical setup will be too small to report
> >under some circumstances.  In addition, if any sort of timer is to
> >be used, then why not have the NMS poll the NEs?  This is what
> >I meant by the trap approach being more costly than beneficial.
> >
> >     I think you would have to make up your mind who is going to be
> >in control of your TE setup.  If, as you say, an NMS can manage it
> >because of a protracted time scale - and an operator decides to
> >do it this way - then only the NMS should manage TE setup and
> >tear down.  If that is the case, then where would the change you
> >want to be notified of come from?  On the other hand, if you need
> >to use a more dynamic approach, then the NMS should be limited
> >to policy level management.  Otherwise, it would be like having a
> >manager that makes specific resource allocation decisions based
> >on monthly trend data and an annual budget for individual projects
> >with an average project life cycle of 3 days.
> >
> >--
> >Eric Gray
> >
> >You wrote:
> >
> > > Hi,
> > >
> > > I will try to reply Cheenu, Tom and Eric in one mail.
> > >
> > > Alarm or Trap Storms are considered to be undesirable during
> > > failures because all of them tend to convey the same information during
> > > failure and hinder any corrective acton by congesting the
> > > network. Even worse sometimes they are only a side effect of a
> > > failure in the network downstream.
> > > This generally happens in transport networks because of
> > > the ability of the network to propagate the defect in forward and
> > > backward direction. Where as in the present case, if an LSP is setup
> > > across N links, then receiving N traps indicating a change in the
> > > available bandwidth of each link respectively is not redundant and
> > > undesirable but necessary. The debatable point could when should it
> > > be sent. Also as Eric pointed if this is used for monitoring, even
> > > then this has to updated at some agreeable interval period.
> > >
> > > The second point I would like to make is the assumption that the
> > > networks under consideration are fairly stable, in the sense that the
> > > time scales for setup and teardown are fairly large. For example,
> > > an enterprise customer requesting a 1 Gb pipe from point A to B.
> > >
> > > As the number contraints and the number of nodes increase, the
> > > optimization algorithm may become computationally expensive to fit in
> > > the device, hence a desire to compute the bigger bw LSP with more
> > > efficient mechanism off-line.
> > >
> > > Addressing the time lag issue. Assume an LSP is being setup
> > >
> > > A---B---C---D---E
> > >
> > > While you are computing a path in A, from A to E, if C setup another
> > > LSP from C to D and the OSPF update has not yet occured, you still
> > > have the same problem. So let us assume we are operating with the
> > > same assumption of time granularity irrespective of where we are
> > > computing the path and also assume that the network does not change
> > > between computation and setup.
> > >
> > > Eric, you are right. for the reasons mentioned I am proposing TE
> > > computation off-line in NMS and then setup from ingress and I am
> > > trying to bring about the necessary coordination by the proposed
> > > TRAP. Autonomous notifications will address the granularity and
> > > reporting cycle issue.
> > >
> > > So sending the notification and making the same assumptions as you
> > > would have made while computing the path in the device could solve
> > > the problem I am trying to impress upon the list and the authors.
> > >
> > > However taking a cue from this discussion, the other method to do
> > > the calculation  could be to retrieve the whole OSPF-TE MIB from
> > > the ingress node and compute the path. But that also has some of the
> > > caveats discussed above. Also I am not sure what would be the size
> > > of such a MIB in large network.
> > >
> > > Regards,
> > >
> > > Irfan Lateef
> > >
> > > P.S : Cheenu, Can you clarify the passive OSPF suggestion ,
> > >       I did not understand your exact idea.
> > >
> > > >From: Eric Gray <eric.gray@sandburst.com>
> > > >To: Thomas Nadeau <tnadeau@cisco.com>
> > > >CC: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
> > > >Subject: Re: LSR-MIB - AvailableBandwidth ?
> > > >Date: Wed, 29 Aug 2001 16:43:24 -0400
> > > >
> > > >Irfan,
> > > >
> > > >     Just to add to what Tom says, there are other scary aspects of
> >this
> > > >question.
> > > >For one, your question seems to assume that an NMS is being used to
> >compute
> > > >paths, but that some other mechanism is being used to set them up and
> >there
> > > >is
> > > >apparently no coordination between the two mechanisms.  For another, in
> > > >order
> > > >to avoid the trap storms that Cheenu mentioned, you'd have to include
> > > >notions
> > > >of change granularity and minimum reporting cycle time.  This quickly
> > > >starts to
> > > >be more costly than beneficial.
> > > >
> > > >--
> > > >Eric Gray
> > > >
> > > >Thomas Nadeau wrote:
> > > >
> > > > > At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
> > > > > >Cheenu et al,
> > > > > >
> > > > > >The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt
> >contains
> > > > > >the attribute mplsInterfaceAvailableBandwidth
> > > > > >
> > > > > >Typically the management application can use this attribute while
> > > > > >computing a constrained TE path or an LSP path.
> > > > > >Now if the signalling protocol is also setting up LSP on this
> > > > > >interface at or around the same time, the management application
> > > > > >would be computing a path based on incoreect value because the
> > > > > >value of this attribute may not be current.
> > > > > >
> > > > > >My question is do we need a trap, like AvailableBandwidthChange,
> > > > > >to be sent to the NMS whenever a LSP is setup/teardown on an
> > > > > >interface. In the absence of such a mechanism the NMS may need to
> > > > > >get the value of all the interface in the network before it
> >computes
> > > > > >the path even if the values may not have changed.
> > > > > >
> > > > > >So in order to keep the NMS in sync with the NE I think a trap is
> > > > > >needed. If you think this is not the way to keep the NMS in sync
> >with
> > > > > >the state of the NE then what is your suggestion.
> > > > > >Appreciate your comments.
> > > > >
> > > > >          I think that you raise an important point, but I would
> > > > > first think carefully about whether or not you want to do
> > > > > what you describe. What you seem to want to do are
> > > > > ad hoc off-line TE calculations and then push them down to
> > > > > the devices. First, as you mention there is a time lag between
> > > > > when the bandwidth changes and when the NMS can know
> > > > > about it. This is why it might be a better idea to let the
> > > > > routers do the path computation after feeding them some
> > > > > constraints (i.e.: end points and bandwidth requirements).
> > > > >
> > > > >          Now, if you want to truly do what you describe, I don't
> > > > > think that adding a notification will help prevent the
> > > > > timing problem, since the bandwidth can still change
> > > > > between the time that the notification is sent and processed
> > > > > by the NMS. Furthermore, since notifications are typically
> > > > > unreliable, they can be lost, and thus we have the same problem
> > > > > even after implementing such a notification.
> > > > >
> > > > >          --Tom
> > > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



From owner-mpls@UU.NET  Fri Aug 31 10:24:57 2001
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 KAA06571
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:24:56 -0400 (EDT)
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 QQlelt18315;
	Fri, 31 Aug 2001 14:25:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelt07037
	for mpls-outgoing; Fri, 31 Aug 2001 14:25: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 QQlelt07024
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:25:00 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 QQlelt19569
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:24:15 GMT
Received: from nwmq0102.jc.digitran.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nwmq0102a.jc.digitran.com [165.251.28.22])
	id QQlelt05216
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:24:17 GMT
Received: from csrinivasan [12.34.209.74] by nwmq0102.jc.digitran.com
	with Novonyx SMTP Server $Revision:   2.74  $; Fri, 31 Aug 2001 10:19:06 -0400 (EDT)
From: "Cheenu Srinivasan" <cheenu@alphion.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Question in LSR MIB...
Date: Fri, 31 Aug 2001 10:37:15 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF20AB13E@OPTONT>
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.2911.0)
Importance: Normal
In-Reply-To: <329F35B18824D511B9C30008C733955828F508@exc-sc1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Govind Haridass wrote:
> 	In case of L2 MPLS, there is no way to represent the
> 	next-hop-mac.  How do we incorporate this ?

The out segment entry contains the next hop layer 3 address.
Use the net-to-media table to determine the layer 2 address.

Cheenu



From owner-mpls@UU.NET  Fri Aug 31 10:27:40 2001
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 KAA06619
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:27:40 -0400 (EDT)
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 QQlelt21294;
	Fri, 31 Aug 2001 14:27:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelt07312
	for mpls-outgoing; Fri, 31 Aug 2001 14:27: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 QQlelt07285
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:27:01 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 QQlelt22895
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:26:42 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 QQlelt07110
	for <mpls@UU.NET>; Fri, 31 Aug 2001 14:26: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 KAA19505
	for <mpls@UU.NET>; Fri, 31 Aug 2001 10:26:39 -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 KAA18542
	for <mpls@UU.NET>; Fri, 31 Aug 2001 10:26:41 -0400 (EDT)
Message-ID: <3B8F9E9C.D3D958C@marconi.com>
Date: Fri, 31 Aug 2001 10:26:36 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Bindings ?
References: <0b2d01c131ec$781ca2b0$b4036c6b@Manav>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mareline Sheldon wrote:
> 
> I am a newbie and i am not sure as to what exactly is the
> difference between Upstream and Downstream binding ?
> Please can anyone of you explain ?

You definitely must read the MPLS architecture RFC (at the very least):

	RFC 3031 - Multiprotocol Label Switching Architecture

RFCs may be retrieved from http://www.ietf.org/, and other places around
the net.

As for your specific question, the difference is in terms of which
router assigns labels over a given link.

Upstream and downstream are relative to the direction that the data will
be flowing through the LSP, once it is set up.  Signaling protocols send
control packets in both directions when they set up the LSPs.

With downstream label binding, the downstream router (for a given link)
picks the label and informs the upstream router about the choice.  With
upstream label binding, the upstream router chooses the label and
informs the downstream router about the choice.

RSVP-TE, LDP and CR-LDP all use downstream label binding.  I think the
GMPLS versions of these protocols may also have provisions for upstream
binding.

-- David


From owner-mpls@UU.NET  Fri Aug 31 10:48:55 2001
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 KAA07123
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 10:48:55 -0400 (EDT)
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 QQlelv18523;
	Fri, 31 Aug 2001 14:49:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelv09240
	for mpls-outgoing; Fri, 31 Aug 2001 14:48:34 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 QQlelv09229
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 14:48:29 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 QQlelv15943
	for <mpls@uu.net>; Fri, 31 Aug 2001 14:48:21 GMT
Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQlelv01707
	for <mpls@uu.net>; Fri, 31 Aug 2001 14:48:19 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7VEmFo00571
	for <mpls@uu.net>; Fri, 31 Aug 2001 16:48:16 +0200 (MET DST)
Received: from alcatel.be ([138.203.67.106]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.7  (934.1 12-30-1999)) with SMTP id C1256AB9.00514C69; Fri, 31 Aug 2001 16:47:59 +0200
Message-ID: <3B8FA39F.D7374FD9@alcatel.be>
Date: Fri, 31 Aug 2001 16:47:59 +0200
From: Jeremy De Clercq <Jeremy.De_Clercq@alcatel.be>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: reference in draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, there are still references to
section 4.8 of that draft.

Section 4.8 has been removed since the -07 version, so these references
should be updated.

with my appologies if this has been pointed out before. (could find a
discussion on this in the archives, but the result was to change
something in the diff-ext draft).

thanks, 

Jeremy.


From owner-mpls@UU.NET  Fri Aug 31 11:19:17 2001
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 LAA07646
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 11:19:17 -0400 (EDT)
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 QQlelx26596;
	Fri, 31 Aug 2001 15:19:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlelx29773
	for mpls-outgoing; Fri, 31 Aug 2001 15:19:32 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 QQlelx29767
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 15:19:22 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 QQlelx20675
	for <mpls@UU.NET>; Fri, 31 Aug 2001 15:19:19 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 QQlelx06987
	for <mpls@UU.NET>; Fri, 31 Aug 2001 15:19: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 LAA26895
	for <mpls@UU.NET>; Fri, 31 Aug 2001 11:19:16 -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 LAA11053
	for <mpls@UU.NET>; Fri, 31 Aug 2001 11:19:17 -0400 (EDT)
Message-ID: <3B8FAAEC.F3A7AD2E@marconi.com>
Date: Fri, 31 Aug 2001 11:19:08 -0400
From: David Charlap <david.charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: reference in draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
References: <3B8FA39F.D7374FD9@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jeremy De Clercq wrote:
> 
> In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, there are still
> references to section 4.8 of that draft.
> 
> Section 4.8 has been removed since the -07 version, so these
> references should be updated.
> 
> with my appologies if this has been pointed out before. (could
> find a discussion on this in the archives, but the result was to
> change something in the diff-ext draft).

This is known.  Last I heard, George is finishing up version -09 of the
draft, which will fix up this problem, and several related issues.  As
far as I know, this is the only substantial change since version -08,
which was intended to be a last-call revision.

According to past discussion on this subject, references to section 4.8
will be replaced with references to RFC 2997.  Best-effort LSPs are to
be signalled using the IntServ Null service type.  The CoS C-Type
objects (from section 4.8) no longer exist.  This update will be in the
next rev of the RSVP-TE draft.

-- David


From owner-mpls@UU.NET  Fri Aug 31 13:50:37 2001
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 NAA12003
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 13:50: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 QQlemh18698;
	Fri, 31 Aug 2001 17:50:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlemh17872
	for mpls-outgoing; Fri, 31 Aug 2001 17:50:13 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 QQlemh17864
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 17:50:04 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 QQlemh21916
	for <mpls@UU.NET>; Fri, 31 Aug 2001 17:48:52 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQlemh16714
	for <mpls@UU.NET>; Fri, 31 Aug 2001 17:48:53 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id NAA01623; Fri, 31 Aug 2001 13:49:08 -0400
Date: Fri, 31 Aug 2001 13:49:07 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: Shahram_Davari@pmc-sierra.com
cc: BinitaJ@netbrahma.com, mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Re: RE: MPLS over FR.
Message-ID: <Pine.SUN.3.96.1010831134524.1047A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi, 
2 small doubts:
#1. A particular value of a DLCI is bound with a particular protocol to be
carried in FR.
Is that conveyed in Q.933(PVC)/FRF4.1(SVC) ? Or they are administratively
known for a given network ?
#2. In the point (2)of the mail below, with S=1 there may still be MPLS
payload present with only "1" label.How to determine the Payload type in
that case ?

Regards,
Hemant Kelkar

Date: Fri, 31 Aug 2001 07:07:42 -0700
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: 'Binita Jha' <BinitaJ@netbrahma.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: MPLS over FR.

Hi,

Comments in-line:

> -----Original Message-----
> From: Binita Jha [mailto:BinitaJ@netbrahma.com]
> Sent: Friday, August 31, 2001 9:26 AM
> To: 'mpls@uu.net'
> Subject: MPLS over FR.
>
>
> I have a doubt regarding MPLS over FR.
> 1) RFC 3034 says that the top label (DLCI) carries implicitly
> information
> about the network protocol type. but how does it indicate
> about if the shim
> header is present or not?

The shim header MUST always be present, even if the packet has one label.
Only the S, EXP and TTL values of the top label of
the shim header are used. The top label's 20-bit label value is not used
at all, rather the DLCI is used instead.

>
> 2) Also if the shim header is present then how do we know abt
> what network
> protocol is present?

A DLCI value is bound to a specific network protocol (could be done by
partitioning of DLCI space). If the S=1 in the top
label, then it means that the payload has the same network protocol. If
the S=0, then it means that another label is present
and the payload is MPLS.

Yours,
-Shahram





From owner-mpls@UU.NET  Fri Aug 31 13:58:59 2001
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 NAA12198
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 13:58:59 -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 QQlemh28654;
	Fri, 31 Aug 2001 17:59:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlemh18512
	for mpls-outgoing; Fri, 31 Aug 2001 17:58: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 QQlemh18504
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 17:58:44 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 QQlemh13917
	for <mpls@UU.NET>; Fri, 31 Aug 2001 17:58:41 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlemh14962
	for <mpls@UU.NET>; Fri, 31 Aug 2001 17:58:44 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 NAA07925
	for <mpls@UU.NET>; Fri, 31 Aug 2001 13:54:10 -0400 (EDT)
Subject: ff85h error value
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF3C1D0513.E6C3F49F-ON85256AB9.0061E199@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 31 Aug 2001 13:53:57 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/31/2001 01:53:58 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

What is the interpretation for the error value of FF-85 = FF85h [65413d]
routing problem.

Thnaks,

Julia



From owner-mpls@UU.NET  Fri Aug 31 16:07:35 2001
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 QAA15142
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 16:07: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 QQlemq29260;
	Fri, 31 Aug 2001 20:08:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlemq22675
	for mpls-outgoing; Fri, 31 Aug 2001 20:07: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 QQlemq22648
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 20:07:43 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 QQlemq26664
	for <mpls@UU.NET>; Fri, 31 Aug 2001 20:07:26 GMT
Received: from dnsmx2pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlemq16290
	for <mpls@UU.NET>; Fri, 31 Aug 2001 20:07:24 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 QAA10258
	for <mpls@UU.NET>; Fri, 31 Aug 2001 16:04:42 -0400 (EDT)
Subject: patherr error value
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF1DC283F9.729E4BC7-ON85256AB9.006E3B12@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 31 Aug 2001 16:04:28 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 08/31/2001 04:04:29 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

What is the interpretation for the error value of FF-85 = FF85h [65413d]
routing problem.

Thnaks,

Julia




From owner-mpls@UU.NET  Fri Aug 31 19:04:53 2001
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 TAA17383
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 19:04:52 -0400 (EDT)
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 QQlenc11873;
	Fri, 31 Aug 2001 23:05:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlenc22728
	for mpls-outgoing; Fri, 31 Aug 2001 23:04: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 QQlenc22701
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 23:04:53 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 QQlenc09619
	for <mpls@UU.NET>; Fri, 31 Aug 2001 23:04:38 GMT
Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.186.47.7])
	id QQlenc10939
	for <mpls@UU.NET>; Fri, 31 Aug 2001 23:04:41 GMT
Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19)
	id <QBJX3RLH>; Fri, 31 Aug 2001 16:07:45 -0700
Message-ID: <D55193A1090CD4118171009027DC8CEBA0281E@newmail.coronanetworks.com>
From: Sanjeev Chakravarty <Sanjeev@coronanetworks.com>
To: mpls@UU.NET
Subject: Question on FEC
Date: Fri, 31 Aug 2001 16:07:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13271.BD58A100"
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_01C13271.BD58A100
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi,

Is it correct to conclude that FEC parameters in MPLS are same as
MF(Multi-field) or BA(behavior Aggregate) parameters in Diffserv?

Thanks,

Sanjeev Chakravarty

------_=_NextPart_001_01C13271.BD58A100
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>Question on FEC</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Is it correct to conclude that FEC parameters in MPLS =
are same as MF(Multi-field) or BA(behavior Aggregate) parameters in =
Diffserv?</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Sanjeev Chakravarty</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C13271.BD58A100--


From owner-mpls@UU.NET  Fri Aug 31 19:40:31 2001
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 TAA17750
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 19:40:31 -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 QQlene10207;
	Fri, 31 Aug 2001 23:41:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlene03240
	for mpls-outgoing; Fri, 31 Aug 2001 23:40:49 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 QQlene03235
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 31 Aug 2001 23:40: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 QQlene25818
	for <mpls@UU.NET>; Fri, 31 Aug 2001 23:40:39 GMT
Received: from EXCHANGE.networkelements.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat.networkelements.com [198.107.63.227] (may be forged))
	id QQlene29709
	for <mpls@UU.NET>; Fri, 31 Aug 2001 23:40:42 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13276.56751D56"
Subject: RE: Question on FEC
Date: Fri, 31 Aug 2001 16:40:38 -0700
Message-ID: <7C9FD61585BE294DB290E2207B6001AF2EC9DF@EXCHANGE.networkelements.com>
Thread-Topic: Question on FEC
Thread-Index: AcEycYeL9rT5HFsmRaeLK20bmuoITAABJGpQ
From: "Nepple, Bruce" <bnepple@networkelements.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C13276.56751D56
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is that explained by
draft-ietf-mpls-diff-ext-09.txt ?
=20
Bruce

-----Original Message-----
From: Sanjeev Chakravarty [mailto:Sanjeev@coronanetworks.com]
Sent: Friday, August 31, 2001 4:08 PM
To: mpls@UU.NET
Subject: Question on FEC



Hi,=20

Is it correct to conclude that FEC parameters in MPLS are same as
MF(Multi-field) or BA(behavior Aggregate) parameters in Diffserv?

Thanks,=20

Sanjeev Chakravarty=20


------_=_NextPart_001_01C13276.56751D56
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Question on FEC</TITLE>

<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D363553823-31082001>Is=20
that explained by</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D363553823-31082001>draft-ietf-mpls-diff-ext-09.txt =
?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D363553823-31082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D363553823-31082001>Bruce</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Sanjeev =
Chakravarty=20
  [mailto:Sanjeev@coronanetworks.com]<BR><B>Sent:</B> Friday, August 31, =
2001=20
  4:08 PM<BR><B>To:</B> mpls@UU.NET<BR><B>Subject:</B> Question on=20
  FEC<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Hi,</FONT> </P>
  <P><FONT size=3D2>Is it correct to conclude that FEC parameters in =
MPLS are same=20
  as MF(Multi-field) or BA(behavior Aggregate) parameters in=20
Diffserv?</FONT></P>
  <P><FONT size=3D2>Thanks,</FONT> </P>
  <P><FONT size=3D2>Sanjeev Chakravarty</FONT> =
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C13276.56751D56--


From owner-mpls@UU.NET  Fri Aug 31 23:11:07 2001
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 XAA22617
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 23:11:07 -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 QQlens16895;
	Sat, 1 Sep 2001 03:11:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlens00681
	for mpls-outgoing; Sat, 1 Sep 2001 03:11:21 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 QQlens00676
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Sep 2001 03:11:18 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 QQlens27754
	for <mpls@UU.NET>; Sat, 1 Sep 2001 03:09:47 GMT
Received: from EXCHANGE.networkelements.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat.networkelements.com [198.107.63.227] (may be forged))
	id QQlens26313
	for <mpls@UU.NET>; Sat, 1 Sep 2001 03:09:50 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13293.8DB80FBD"
Subject: Question about LSR MIB
Date: Fri, 31 Aug 2001 20:09:46 -0700
Message-ID: <7C9FD61585BE294DB290E2207B6001AF30D9AE@EXCHANGE.networkelements.com>
Thread-Topic: Question on FEC
Thread-Index: AcEycYeL9rT5HFsmRaeLK20bmuoITAABJGpQAAceHuA=
From: "Nepple, Bruce" <bnepple@networkelements.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C13293.8DB80FBD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 <http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt
describes =20
mplsXCLabelStackIndex as identifying a
        stack of labels to be pushed beneath the top label.  The "pushed
beneath" concept confuses me.  Does this assume the top
label is later stripped, or am I missing something completely.

------_=_NextPart_001_01C13293.8DB80FBD
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Question on FEC</TITLE>

<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.tx=
t"><FONT=20
face=3DArial color=3D#000000=20
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.t=
xt</FONT></A><SPAN=20
class=3D367430203-01092001><FONT face=3DArial size=3D2>&nbsp;=20
describes&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D367430203-01092001>mplsXCLabelStackIndex as =
identifying=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stack of labels to be =
pushed=20
beneath the top label.&nbsp; The "pushed</SPAN></DIV>
<DIV><SPAN class=3D367430203-01092001>beneath" concept confuses =
me.&nbsp; Does=20
this assume the top</SPAN></DIV>
<DIV><SPAN class=3D367430203-01092001>label is later stripped, or am I =
missing=20
something completely.</SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C13293.8DB80FBD--


From owner-mpls@UU.NET  Fri Aug 31 23:20:44 2001
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 XAA22780
	for <mpls-archive@lists.ietf.org>; Fri, 31 Aug 2001 23:20:44 -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 QQlent27953;
	Sat, 1 Sep 2001 03:20:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlent01438
	for mpls-outgoing; Sat, 1 Sep 2001 03:20:34 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 QQlent01431
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 1 Sep 2001 03:20:25 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 QQlent04123
	for <mpls@UU.NET>; Sat, 1 Sep 2001 03:19:58 GMT
Received: from EXCHANGE.networkelements.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nat.networkelements.com [198.107.63.227] (may be forged))
	id QQlent12036
	for <mpls@UU.NET>; Sat, 1 Sep 2001 03:20:01 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13294.FA499DD5"
Subject: RE: Question about LSR MIB
Date: Fri, 31 Aug 2001 20:19:57 -0700
Message-ID: <7C9FD61585BE294DB290E2207B6001AF2EC9E2@EXCHANGE.networkelements.com>
Thread-Topic: Question on FEC
Thread-Index: AcEycYeL9rT5HFsmRaeLK20bmuoITAABJGpQAAceHuAAAJMQcA==
From: "Nepple, Bruce" <bnepple@networkelements.com>
To: "Nepple, Bruce" <bnepple@networkelements.com>, <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

doh .... this must mean push on the top label, then push these below it.
=20
sorry

-----Original Message-----
From: Nepple, Bruce=20
Sent: Friday, August 31, 2001 8:10 PM
To: mpls@UU.NET
Subject: Question about LSR MIB


 <http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt
describes =20
mplsXCLabelStackIndex as identifying a
        stack of labels to be pushed beneath the top label.  The "pushed
beneath" concept confuses me.  Does this assume the top
label is later stripped, or am I missing something completely.


------_=_NextPart_001_01C13294.FA499DD5
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Question on FEC</TITLE>

<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D306101903-01092001><FONT face=3DArial color=3D#0000ff =
size=3D2>doh=20
.... this must mean push on the top label, then push these below=20
it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D306101903-01092001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D306101903-01092001><FONT face=3DArial color=3D#0000ff =

size=3D2>sorry</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Nepple, Bruce=20
  <BR><B>Sent:</B> Friday, August 31, 2001 8:10 PM<BR><B>To:</B>=20
  mpls@UU.NET<BR><B>Subject:</B> Question about LSR =
MIB<BR><BR></FONT></DIV>
  <DIV><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.tx=
t"><FONT=20
  face=3DArial color=3D#000000=20
  =
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.t=
xt</FONT></A><SPAN=20
  class=3D367430203-01092001><FONT face=3DArial size=3D2>&nbsp;=20
  describes&nbsp;&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D367430203-01092001>mplsXCLabelStackIndex as =
identifying=20
  a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stack of labels to be =
pushed=20
  beneath the top label.&nbsp; The "pushed</SPAN></DIV>
  <DIV><SPAN class=3D367430203-01092001>beneath" concept confuses =
me.&nbsp; Does=20
  this assume the top</SPAN></DIV>
  <DIV><SPAN class=3D367430203-01092001>label is later stripped, or am I =
missing=20
  something completely.</SPAN></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C13294.FA499DD5--