From owner-mpls@UU.NET  Wed Jan  2 11:10:11 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06036
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:10:10 -0500 (EST)
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 QQlwbw25403;
	Wed, 2 Jan 2002 16:09:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbw08849
	for mpls-outgoing; Wed, 2 Jan 2002 16:09: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 QQlwbw08844
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:09:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlwbw13055
	for <Mpls@uu.net>; Wed, 2 Jan 2002 16:08:45 GMT
Received: from [172.16.1.115] by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mdclient1.opnet.com [12.145.55.10])
	id QQlwbw24253
	for <Mpls@uu.net>; Wed, 2 Jan 2002 16:09:03 GMT
Received: from wtn10216.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58334bc2b8ac10010f658@>;
 Wed, 2 Jan 2002 11:08:45 -0500
Message-Id: <5.0.0.25.2.20020102105248.04d06d50@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 02 Jan 2002 11:08:15 -0500
To: Ping Pan <pingpan@juniper.net>
From: Sachin Kalra <skalra@opnet.com>
Subject: Re: Question about draft-pan-rsvp-fast-reroute Nov 2001
Cc: <Mpls@UU.NET>
In-Reply-To: <20011229124034.W15671-100000@garnet.juniper.net>
References: <5.0.0.25.2.20011228134319.00a58b60@mail.opnet.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_494345310==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_494345310==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Ping Pan:

Thanks for the email. Your reply made me understand the scenario.

Now, can anybody please answer the following.

Consider the following network in which two Bypass tunnels are configured 
originating from [R2]
1. [R2]==>[R6]==>[R7]==>[R8]==>[R4]
2. [R2]==>[R11]==>[R12]==>[R13]==>[R14]==>[R5]


             [R0]     [R10]
                \         /
                  \     /
   [R1]---------[R2]------------------[R3]----------------[R4]---------X--------[R5]-----------------[R9]
                  ||   \\                                          // 
                 ||
                  ||    \\                                        // 
                 ||
                  ||     [R6]======[R7]======[R8]                         ||
                  || 
||
                 [R11]========[R12]========[R13]========[R14]


Now, if Link [R4]-->[R5] fails then how will [R2] decide which backup 
tunnel to use in this case? Or, if there are many Bypass tunnels 
originating from a node then how does node decides which Bypass Tunnel to 
use at time of network changes?

Any help is appreciated.

Thanks,
Sachin Kalra

At 12:45 PM 12/29/01 -0800, Ping Pan wrote:
>Sachin:
>
>
>On Fri, 28 Dec 2001, Sachin Kalra wrote:
>
> > Hi All:
> >
> > I have few questions regarding Fast Reroute using Bypass tunnels using
> > RSVP-TE. Any help is appreciated.
> >
> > Consider the following network, where 10 different LSPs are
> > traversing  [R1]-->[R2]-->[R3]-->[R4]-->[R5], another one LSP traversing
> > [R1]-->[R2]-->[R10], And there is a Bypass Tunnel configured
> > from  [R2]==>[R6]==>[R7]==>[R8]==>[R4]
> >
> >
> >        [R0]            [R10]
> >              \          /
> >                \      /
> > 
> [R1]---------[R2]--------X----------[R3]----------------[R4]-----------------[R5]
> >
> >                    \\                                          //   \
> >                     \\                                        //      \
> >                      [R6]======[R7]======[R8]         [R9]
> >
> >
> > Now my questions are:
> > 1. Does the Bypass Tunnel protects all 10 LSPs or we can associate just
> > some of them to the Tunnel?
> >
>
>You can associate the LSPs to the bypass LSP base on the config at R2, and
>the information carried in the protected LSPs. For example, when R2 is set
>to backup any LSP that has the reroute-desired bit set in SAO, if all 10
>LSPs have such bit on, they will be backed up via the bypass tunnel.
>
> > 2. How to disassociate LSP [R1]-->[R2]-->[R10] from the bypass tunnel?
> >
>
>Again, base on your config at R2.
>
> > 3. How does [R2] makes its NHLFEs for the Bypass Tunnel?
> >
> > 4. What FEC does [R2] use to inject traffic into the bypass tunnel at time
> > of failure? Or how does [R2] associate any traffic with the Bypass Tunnel?
> >
> > I would appreciate answer to all or any of the above questions.
> >
> > Thanks,
> > Sachin Kalra
> >
> >

--=====================_494345310==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Ping Pan:<br>
<br>
Thanks for the email. Your reply made me understand the scenario.<br>
<br>
Now, can anybody please answer the following.<br>
<br>
Consider the following network in which two Bypass tunnels are configured
originating from [R2]<br>
1. [R2]==&gt;[R6]==&gt;[R7]==&gt;[R8]==&gt;[R4]<br>
2. [R2]==&gt;[R11]==&gt;[R12]==&gt;[R13]==&gt;[R14]==&gt;[R5]<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R0]&nbsp;&nbsp;&nbsp;&nbsp; [R10] <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; / <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp; / <br>
&nbsp;
[R1]---------[R2]------------------[R3]----------------[R4]---------X--------[R5]-----------------[R9]<br>
&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;&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;&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;&nbsp;&nbsp;&nbsp;
||<br>
&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;&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;&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;&nbsp;&nbsp;&nbsp;
|| <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||&nbsp;&nbsp;&nbsp;&nbsp;
[R6]======[R7]======[R8]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||<br>
&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;&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
||<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R11]========[R12]========[R13]========[R14]<br>
<br>
<br>
Now, if Link [R4]--&gt;[R5] fails then how will [R2] decide which backup
tunnel to use in this case? Or, if there are many Bypass tunnels
originating from a node then how does node decides which Bypass Tunnel to
use at time of network changes?<br>
<br>
Any help is appreciated.<br>
<br>
Thanks,<br>
Sachin Kalra<br>
<br>
At 12:45 PM 12/29/01 -0800, Ping Pan wrote:<br>
<blockquote type=cite class=cite cite>Sachin:<br>
<br>
<br>
On Fri, 28 Dec 2001, Sachin Kalra wrote:<br>
<br>
&gt; Hi All:<br>
&gt;<br>
&gt; I have few questions regarding Fast Reroute using Bypass tunnels
using<br>
&gt; RSVP-TE. Any help is appreciated.<br>
&gt;<br>
&gt; Consider the following network, where 10 different LSPs are<br>
&gt; traversing&nbsp; [R1]--&gt;[R2]--&gt;[R3]--&gt;[R4]--&gt;[R5],
another one LSP traversing<br>
&gt; [R1]--&gt;[R2]--&gt;[R10], And there is a Bypass Tunnel
configured<br>
&gt; from&nbsp; [R2]==&gt;[R6]==&gt;[R7]==&gt;[R8]==&gt;[R4]<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R0]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R10]<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
\&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>
&gt;
[R1]---------[R2]--------X----------[R3]----------------[R4]-----------------[R5]<br>
&gt;<br>
&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
//&nbsp;&nbsp; \<br>
&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;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R6]======[R7]======[R8]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[R9]<br>
&gt;<br>
&gt;<br>
&gt; Now my questions are:<br>
&gt; 1. Does the Bypass Tunnel protects all 10 LSPs or we can associate
just<br>
&gt; some of them to the Tunnel?<br>
&gt;<br>
<br>
You can associate the LSPs to the bypass LSP base on the config at R2,
and<br>
the information carried in the protected LSPs. For example, when R2 is
set<br>
to backup any LSP that has the reroute-desired bit set in SAO, if all
10<br>
LSPs have such bit on, they will be backed up via the bypass 
tunnel.<br>
<br>
&gt; 2. How to disassociate LSP [R1]--&gt;[R2]--&gt;[R10] from the bypass
tunnel?<br>
&gt;<br>
<br>
Again, base on your config at R2.<br>
<br>
&gt; 3. How does [R2] makes its NHLFEs for the Bypass Tunnel?<br>
&gt;<br>
&gt; 4. What FEC does [R2] use to inject traffic into the bypass tunnel
at time<br>
&gt; of failure? Or how does [R2] associate any traffic with the Bypass
Tunnel?<br>
&gt;<br>
&gt; I would appreciate answer to all or any of the above 
questions.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Sachin Kalra<br>
&gt;<br>
&gt;</blockquote></html>

--=====================_494345310==_.ALT--



From owner-mpls@UU.NET  Wed Jan  2 11:12:29 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06090
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:12:29 -0500 (EST)
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 QQlwbw16018;
	Wed, 2 Jan 2002 16:11:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbw09103
	for mpls-outgoing; Wed, 2 Jan 2002 16:11: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 QQlwbw09092
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:11: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 QQlwbw17532
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:10:42 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwbw14240
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:10:27 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA25025 for <mpls@uu.net>; Wed, 2 Jan 2002 11:10:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA27399 for mpls@uu.net; Wed, 2 Jan 2002 11:10:38 -0500 (EST)
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 QQlvra22458
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 30 Dec 2001 17:31:06 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 QQlvqz23810
	for <mpls@uu.net>; Sun, 30 Dec 2001 17:29:28 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [207.68.163.130])
	id QQlvqz19029
	for <mpls@uu.net>; Sun, 30 Dec 2001 17:29:16 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 30 Dec 2001 09:29:27 -0800
Received: from 212.25.110.131 by sea1fd.sea1.hotmail.msn.com with HTTP;
	Sun, 30 Dec 2001 17:29:27 GMT
X-Originating-IP: [212.25.110.131]
From: "Toni Jackob" <tonijackob@hotmail.com>
To: mpls@UU.NET
Subject: LDP over unnumbered interfaces
Date: Sun, 30 Dec 2001 17:29:27 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F130wFcxT1oGNjrRAKj0000a3ab@hotmail.com>
X-OriginalArrivalTime: 30 Dec 2001 17:29:27.0903 (UTC) FILETIME=[885C7EF0:01C19157]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All.

I'm new with the LDP protocol.
I hope someone can help me out.

My question is how LDP can work with unnumbered interfaces?

The routes that are created over such interfaces are interface routes, which 
has not IP address or network. LDP needs some IP address that it can compare 
with the IP addresses that its LDP PEERs advertised to it.

Thanks.

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



From owner-mpls@UU.NET  Wed Jan  2 11:28:16 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06412
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:28:16 -0500 (EST)
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 QQlwbx21853;
	Wed, 2 Jan 2002 16:27:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbx10478
	for mpls-outgoing; Wed, 2 Jan 2002 16:24:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlwbx10471
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:24:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlwbx17719
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:23:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwbx07719
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:22: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 LAA26760 for <mpls@uu.net>; Wed, 2 Jan 2002 11:23:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA28743 for mpls@uu.net; Wed, 2 Jan 2002 11:23:02 -0500 (EST)
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 QQlwbx10159
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:22: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 QQlwbx08352
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:22:25 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 QQlwbx06462
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:22:10 GMT
Received: (qmail 29190 invoked by uid 104); 2 Jan 2002 16:22:23 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4178. . Clean. Processed in 0.525911 secs); 02 Jan 2002 16:22:23 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 2 Jan 2002 16:22:23 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g02GMMu08953
	for <mpls@uu.net>; Wed, 2 Jan 2002 08:22:22 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <XNRN59PA>; Wed, 2 Jan 2002 08:22:23 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A4B0@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: MPLSOAM BOF final minutes & presentations
Date: Wed, 2 Jan 2002 08:22:11 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C193A9.A1EF5FA0"
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_000_01C193A9.A1EF5FA0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,

Based on received comments, please find attached the final minutes of the MPLSOAM BOF. The presentations have been submitted to IETF and will be available to the public shortly.


Thanks,
Shahram Davari
MPLSOAM BOF Co-chair




------_=_NextPart_000_01C193A9.A1EF5FA0
Content-Type: text/plain;
	name="minutes-mpls oam bof5.txt"
Content-Disposition: attachment;
	filename="minutes-mpls oam bof5.txt"
Content-Transfer-Encoding: quoted-printable

MPLS Maintenance Mechanisms BOF December 11, 2001 52nd IETF meeting, =
Salt Lake=20
City
2.15 pm to 3.15 pm, Room: Imperial C

Minutes recorded by Ananth Nagarajan=20


1. Introduction and Agenda
Shahram Davari did the introduction. Requests Q&A to be kept to the =
end.
Peter presented - What sort of OAM does MPLS need?=20
MPLS needs OAM. Are the current mechanisms (ping and traceroute) =
sufficient?

2. A word from the ADs (Scott Bradner and Bert Wijnen)
Scott - Reason for this BOF is because of disconnect on MPLS OAM =
requirements.=20
What is the problem that we are trying to solve?  Answer may be that =
there are=20
two fundamental different things and don't need merging. If both are =
needed,=20
then they may not need to be done in the IETF. ITU has requested an OAM =
label.=20
So it may be done in the ITU.
Presenters were requested to explain the problem that they are trying =
to solve=20
first.

3. Presentation - what are the requirements for MPLS OAM? - Peter =
Willis
OAM protects the three main organs of a network operator (brain, heart, =
wallet)
OAM requirements have been implicitly stated in RFC 1812 "Reqts for IP =
routers".
Described various MPLS fault scenarios and highlighted deficiencies in =
current=20
handling mechanisms. Various I-Ds and RFCs that include OAM =
requirements were=20
listed.  MPLS OAM tool requirements were listed.  Also, a list of =
things that=20
MPLS OAM tools should not do were listed. Limitations with traditional =
IP-based=20
ping mechanisms were discussed. OAM mechanisms in other protocols were =
listed.=20
The list of people who expressed interest in this work and a list of =
IETF I-Ds=20
related to this work was provided.


4. Presentation - To what degree do current proposals meet these =
requirements? -=20
Shahram Davari
Shahram discussed and compared currently available tools (IP tools such =
as=20
Bonica-GTTP, Ping Pan's LSP Ping, and MPLS specific tools such as the =
expired=20
draft-harrison-mpls-oam-00). It was also shown that various approaches =
satisfy=20
various subsets of MPLS control planes, except the draft-harrison, =
which=20
satisfies all MPLS control planes (i.e., RSVP-TE, CR-LDP, LDP, BGP,=20
Configuration-based).  Compliance of these three approaches with =
various OAM=20
requirements was compared. =20
Summary : operators have identified requirements, current proposals are =

insufficient.  Do we need one generic solution or a number of point =
solutions? =20
We also need to improve current proposals.




5. Presentation - Ron Bonica
Alternative approach:
Currently two approaches - OAM versus Ping/GTTP.  These approaches are =
based on=20
two competing views - MPLS as a layer, versus MPLS as a routing =
mechanism.=20
Trying to address how to harmonize these two views.
The proposed solution is : MPLS WG adopts the IP-centric view  (ping, =
gttp) and=20
the PWE3 WG should dictate the layer 2 OAM mechanisms.=20



6. Discussion

Brajesh Kumar - Need tools (may be modification of gttp/ping). But a =
full OAM=20
draft may take too long to be beneficial.

Yakov Rekhter - Presentations focused on frame/cell switching with =
MPLS. None=20
focused on DWDM/GMPLS. Should we not broaden the scope?
A: Immediate problem is to address Frame-based LSRs. GMPLS will be in =
the=20
future.

Yakov - are you saying that certain functionality available at certain =
data=20
planes need not apply to others.

Ben Mack-Crane - (after further clarification by email)

These problems are already solved at other layers, for example =
SONET/SDH, PDH, OTN."


Yakov - Requirements need to be broadened.

Ping Pan - LSP ping is driven by provider requirements. Not intended to =
give=20
full measurements on OAM. Agree that functionality is limited, but this =
is=20
within the context of IP. OAM is much beyond the context of IP.  LDP is =
not=20
covered by lsp-ping because LDP is used for label distribution and =
there is no=20
need to ping a label (unless associated with a VPN).

Shahram - LSP-Ping should also work with LDP.

Ray (Goldwire technology) - This work is truly essential and needs to =
be done.=20
Administratively a bad idea to have a separate WG. Seconds Ron's =
proposal.

Dave Allan - Seeing demand for this functionality from customers. Doing =
this in=20
PWE3 will not be a good idea. These should be built in current network =
elements.

Kireeti - Couple of comments : 1. LSP-PING is currently rsvp-te =
specific, but=20
can be extended. Actually a "good" thing that it works only at a data =
plane, and=20
not at control plane. 2. Non-goal not to do control plane stuff is not =
good.=20
Should do control plane also.  In response to Dave, if LSP-ping and =
GTTP don't=20
work, we should examine why they don't' work for IP.  Regarding SONET =
trails, we=20
need a tool for control plane for this.  Depending on what ITU says, we =
might=20
need such tools.  May be we should build something in CCAMP for this. =
Similarly=20
other WGs should do related stuff.

Ben Mack-Crane - SG 13 in ITU has been doing work.  Need to coordinate=20
what is done there and what here.

Rahul - Redback - none of the discussions talked about ICMP extensions =
to mpls. =20
That can solve a lot of these issues.

Shahram - that has been rejected by IESG.=20

Rahul - need to open it up again, since it is deployed.

Shahram - can't solve all the problems mentioned.

Rahul - don't agree.

Ben Mack-Crane - IP centric approaches may have limitations like =
security=20
violations. Still makes sense to use MPLS OAM mechanisms for IP centric =

networks.  Both data and control plane needs OAM. IT is good to keep =
them=20
separate.

Dave McDysan - Interpretations on references are inaccurate. Questions =
analysis=20
on limitations of other proposals. Harrison OAM is very similar to ATM.

Ping Pan - GTTP/LSP Ping is designed for IP network operators. Agree =
that OAM is=20
very important. But this needs to be done elsewhere.(ITU). Appropriate =
IP=20
mechanisms need to be done in appropriate IETF WGs.

Ben Mack-Crane- Defending harrison draft, as Neil had problems with ATM =
OAM and wanted to=20
make stuff better than ATM.  MPLS OAM is not an "application" over MPLS =
and=20
therefore not a separate application (unlike what Ping said).

Yakov - (after clarification on the mailing list)

Ron's slides showed that there are two views on MPLS,
with one of these views saying that MPLS is a layer on its own.
This view doesn't match the reality, as in reality MPLS, and
specifically its control plane, doesn't exist outside IP because MPLS
control plane uses IP addressing, routing (OSPF, ISIS), and signaling
(RSVP-TE, LDP, CR-LDP).


George Swallow - (after clarification on the mailing list)

In architeting MPLS the design goal was to offer IP based services.
Along with that the ubiquity of IP was also assumed.  In IP unicast
forwarding, bidirectionality is neither assumed nor assured.

These assumptions lead us to build unidirectional LSPs and to allow
penultimate hop popping since the box at the end of an LSP is assumed
to be able to forward IP packets and removing the label at the
previous hop is a useful optimization.

IP-centric approaches, are the right approach. For instance the
method proposed in draft-pan is to use normal IP pings to monitor a
tunnel.  Only when the normal ping fails do you use the tunnel ping.
This is used to differentiate between a loss of the ping (failure of
the forward path) and loss of the reply (failure of the reverse path).

Dave Allan - LSP creation is discussed in framework doc. Yes, MPLS is=20
predominantly deployed with IP control plane. But need to realize that =
the=20
forwarding plane can exist without IP.  (Ships in the night etc weren't =
made=20
with IP in mind).

Jerry Ash - Many carriers feel that MPLS OAM is needed. First question =
is=20
requirements and second question is capabilities to satisfy =
requirements. =20
Requirements are only partially fulfilled. Need a complete answer, so =
need this=20
work to progress.

Brajesh Kumar - This discussion is focused only on two approaches. OAM =
draft is=20
a good draft and specifies requirements clearly. Not achievable in =
short term.



7. Sense of the room and next steps (Scott and Bert)

Bert - Sense is divided. Original beholders of MPLS feel GTTP/Ping and =
SNMP etc=20
are sufficient.  Also opinion that work has been done, including work =
in ITU. =20
It is clear that a lot of people need this, but not clear where to do =
this (MPLS=20
or existing WGs or separate WG). Need to think more and discuss more.

Yakov Rekhter- may be we should get working code and implementation =
experience.=20
(blue sky talk as opposed to something that can be implemented).

Need minutes to be posted to relevant WGs to help evaluate next steps.

Marco - Good result seen here is that the requirements are clear. Could =
improve=20
current tools or invent new tools. This is a significant result of this =
BOF.

Bert - Need to chat a little more on requirements document and possibly =
have an=20
informational RFC.

Bilel Jamoussi- Need a decision soon. Dragging this to MPLS mailing =
list may not=20
be good. Need bounded time frame for this decision. 2-3 weeks? To =
decide whether=20
it will be done here or ITU.

Bert - If work is not done here, people are free to do it elsewhere. =
The purpose=20
of this BOF was to get an understanding of problems etc. and it has =
been=20
achieved.



------_=_NextPart_000_01C193A9.A1EF5FA0--



From owner-mpls@UU.NET  Wed Jan  2 11:49:44 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06929
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:49:44 -0500 (EST)
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 QQlwbz29048;
	Wed, 2 Jan 2002 16:49:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbz12791
	for mpls-outgoing; Wed, 2 Jan 2002 16:49:06 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 QQlwbz12779
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:48: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 QQlwbz27984
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:48:43 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 QQlwbz23527
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:49: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 LAA16376;
	Wed, 2 Jan 2002 11:48:33 -0500 (EST)
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 LAA26952;
	Wed, 2 Jan 2002 11:48:34 -0500 (EST)
Message-ID: <3C333A4C.9BC05BF5@marconi.com>
Date: Wed, 02 Jan 2002 11:50:20 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET, rsvp@ISI.EDU
Subject: Re: RSVP
References: <D11B30C7348BD511A40700010283497B3878E6@GAYATRI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Gopinath G - CTD, Chennai." wrote:
> 
> How  RSVP/RSVP-TE  recognises its peers  ?  Is there any discovery
> mechanism like in LDP
> or do we need to configure the peers ?

There is no discovery mechanism.  And there is no need for one.

When a Path message is received, the next-hop router is determined using
the routing table and the content of the SESSION (or EXPLICIT_ROUTE)
object.

Other messages that flow downstream use the same next-hop that the most
recent Path message for that flow used.  Messages that flow upstream are
sent to the previous-hop router, based on the PHOP object of the
most-reently received Path message for that flow.

-- David


From owner-mpls@UU.NET  Wed Jan  2 11:49:57 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06949
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:49:57 -0500 (EST)
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 QQlwbz18229;
	Wed, 2 Jan 2002 16:48:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbz12677
	for mpls-outgoing; Wed, 2 Jan 2002 16:48:06 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 QQlwbz12669
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:48:04 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 QQlwbz22632
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:47:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwbz16180
	for <mpls@uu.net>; Wed, 2 Jan 2002 16:46: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 LAA00326 for <mpls@uu.net>; Wed, 2 Jan 2002 11:47:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00747 for mpls@uu.net; Wed, 2 Jan 2002 11:47:01 -0500 (EST)
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 QQlwbz12461
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16: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 QQlwbz23506
	for <mpls@UU.net>; Wed, 2 Jan 2002 16:45:44 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 QQlwbz14312
	for <mpls@UU.net>; Wed, 2 Jan 2002 16:45:30 GMT
Received: (qmail 2487 invoked by uid 104); 2 Jan 2002 16:45:43 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4178. . Clean. Processed in 1.672874 secs); 02 Jan 2002 16:45:43 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 2 Jan 2002 16:45:41 -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 g02Gjec20859
	for <mpls@UU.net>; Wed, 2 Jan 2002 08:45:40 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <XNRN596A>; Wed, 2 Jan 2002 08:45:41 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A4B1@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'mpls@UU.net'" <mpls@UU.NET>
Subject: FW: MPLSOAM BOF final minutes & presentations
Date: Wed, 2 Jan 2002 08:45:33 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

Please find the MPLSOAM BOF final minutes below as plain text format (not an enclosure).

Thanks,
-Shahram

*************************************
MPLS Maintenance Mechanisms BOF December 11, 2001 52nd IETF meeting, Salt Lake 
City
2.15 pm to 3.15 pm, Room: Imperial C

Minutes recorded by Ananth Nagarajan 


1. Introduction and Agenda
Shahram Davari did the introduction. Requests Q&A to be kept to the end.
Peter presented - What sort of OAM does MPLS need? 
MPLS needs OAM. Are the current mechanisms (ping and traceroute) sufficient?

2. A word from the ADs (Scott Bradner and Bert Wijnen)
Scott - Reason for this BOF is because of disconnect on MPLS OAM requirements. 
What is the problem that we are trying to solve?  Answer may be that there are 
two fundamental different things and don't need merging. If both are needed, 
then they may not need to be done in the IETF. ITU has requested an OAM label. 
So it may be done in the ITU.
Presenters were requested to explain the problem that they are trying to solve 
first.

3. Presentation - what are the requirements for MPLS OAM? - Peter Willis
OAM protects the three main organs of a network operator (brain, heart, wallet)
OAM requirements have been implicitly stated in RFC 1812 "Reqts for IP routers".
Described various MPLS fault scenarios and highlighted deficiencies in current 
handling mechanisms. Various I-Ds and RFCs that include OAM requirements were 
listed.  MPLS OAM tool requirements were listed.  Also, a list of things that 
MPLS OAM tools should not do were listed. Limitations with traditional IP-based 
ping mechanisms were discussed. OAM mechanisms in other protocols were listed. 
The list of people who expressed interest in this work and a list of IETF I-Ds 
related to this work was provided.


4. Presentation - To what degree do current proposals meet these requirements? - 
Shahram Davari
Shahram discussed and compared currently available tools (IP tools such as 
Bonica-GTTP, Ping Pan's LSP Ping, and MPLS specific tools such as the expired 
draft-harrison-mpls-oam-00). It was also shown that various approaches satisfy 
various subsets of MPLS control planes, except the draft-harrison, which 
satisfies all MPLS control planes (i.e., RSVP-TE, CR-LDP, LDP, BGP, 
Configuration-based).  Compliance of these three approaches with various OAM 
requirements was compared.  
Summary : operators have identified requirements, current proposals are 
insufficient.  Do we need one generic solution or a number of point solutions?  
We also need to improve current proposals.




5. Presentation - Ron Bonica
Alternative approach:
Currently two approaches - OAM versus Ping/GTTP.  These approaches are based on 
two competing views - MPLS as a layer, versus MPLS as a routing mechanism. 
Trying to address how to harmonize these two views.
The proposed solution is : MPLS WG adopts the IP-centric view  (ping, gttp) and 
the PWE3 WG should dictate the layer 2 OAM mechanisms. 



6. Discussion

Brajesh Kumar - Need tools (may be modification of gttp/ping). But a full OAM 
draft may take too long to be beneficial.

Yakov Rekhter - Presentations focused on frame/cell switching with MPLS. None 
focused on DWDM/GMPLS. Should we not broaden the scope?
A: Immediate problem is to address Frame-based LSRs. GMPLS will be in the 
future.

Yakov - are you saying that certain functionality available at certain data 
planes need not apply to others.

Ben Mack-Crane - (after further clarification by email)

These problems are already solved at other layers, for example SONET/SDH, PDH, OTN."


Yakov - Requirements need to be broadened.

Ping Pan - LSP ping is driven by provider requirements. Not intended to give 
full measurements on OAM. Agree that functionality is limited, but this is 
within the context of IP. OAM is much beyond the context of IP.  LDP is not 
covered by lsp-ping because LDP is used for label distribution and there is no 
need to ping a label (unless associated with a VPN).

Shahram - LSP-Ping should also work with LDP.

Ray (Goldwire technology) - This work is truly essential and needs to be done. 
Administratively a bad idea to have a separate WG. Seconds Ron's proposal.

Dave Allan - Seeing demand for this functionality from customers. Doing this in 
PWE3 will not be a good idea. These should be built in current network elements.

Kireeti - Couple of comments : 1. LSP-PING is currently rsvp-te specific, but 
can be extended. Actually a "good" thing that it works only at a data plane, and 
not at control plane. 2. Non-goal not to do control plane stuff is not good. 
Should do control plane also.  In response to Dave, if LSP-ping and GTTP don't 
work, we should examine why they don't' work for IP.  Regarding SONET trails, we 
need a tool for control plane for this.  Depending on what ITU says, we might 
need such tools.  May be we should build something in CCAMP for this. Similarly 
other WGs should do related stuff.

Ben Mack-Crane - SG 13 in ITU has been doing work.  Need to coordinate 
what is done there and what here.

Rahul - Redback - none of the discussions talked about ICMP extensions to mpls.  
That can solve a lot of these issues.

Shahram - that has been rejected by IESG. 

Rahul - need to open it up again, since it is deployed.

Shahram - can't solve all the problems mentioned.

Rahul - don't agree.

Ben Mack-Crane - IP centric approaches may have limitations like security 
violations. Still makes sense to use MPLS OAM mechanisms for IP centric 
networks.  Both data and control plane needs OAM. IT is good to keep them 
separate.

Dave McDysan - Interpretations on references are inaccurate. Questions analysis 
on limitations of other proposals. Harrison OAM is very similar to ATM.

Ping Pan - GTTP/LSP Ping is designed for IP network operators. Agree that OAM is 
very important. But this needs to be done elsewhere.(ITU). Appropriate IP 
mechanisms need to be done in appropriate IETF WGs.

Ben Mack-Crane- Defending harrison draft, as Neil had problems with ATM OAM and wanted to 
make stuff better than ATM.  MPLS OAM is not an "application" over MPLS and 
therefore not a separate application (unlike what Ping said).

Yakov - (after clarification on the mailing list)

Ron's slides showed that there are two views on MPLS,
with one of these views saying that MPLS is a layer on its own.
This view doesn't match the reality, as in reality MPLS, and
specifically its control plane, doesn't exist outside IP because MPLS
control plane uses IP addressing, routing (OSPF, ISIS), and signaling
(RSVP-TE, LDP, CR-LDP).


George Swallow - (after clarification on the mailing list)

In architecting MPLS the design goal was to offer IP based services.
Along with that the ubiquity of IP was also assumed.  In IP unicast
forwarding, bidirectionality is neither assumed nor assured.

These assumptions lead us to build unidirectional LSPs and to allow
penultimate hop popping since the box at the end of an LSP is assumed
to be able to forward IP packets and removing the label at the
previous hop is a useful optimization.

IP-centric approaches, are the right approach. For instance the
method proposed in draft-pan is to use normal IP pings to monitor a
tunnel.  Only when the normal ping fails do you use the tunnel ping.
This is used to differentiate between a loss of the ping (failure of
the forward path) and loss of the reply (failure of the reverse path).

Dave Allan - LSP creation is discussed in framework doc. Yes, MPLS is 
predominantly deployed with IP control plane. But need to realize that the 
forwarding plane can exist without IP.  (Ships in the night etc weren't made 
with IP in mind).

Jerry Ash - Many carriers feel that MPLS OAM is needed. First question is 
requirements and second question is capabilities to satisfy requirements.  
Requirements are only partially fulfilled. Need a complete answer, so need this 
work to progress.

Brajesh Kumar - This discussion is focused only on two approaches. OAM draft is 
a good draft and specifies requirements clearly. Not achievable in short term.



7. Sense of the room and next steps (Scott and Bert)

Bert - Sense is divided. Original beholders of MPLS feel GTTP/Ping and SNMP etc 
are sufficient.  Also opinion that work has been done, including work in ITU.  
It is clear that a lot of people need this, but not clear where to do this (MPLS 
or existing WGs or separate WG). Need to think more and discuss more.

Yakov Rekhter- may be we should get working code and implementation experience. 
(blue sky talk as opposed to something that can be implemented).

Need minutes to be posted to relevant WGs to help evaluate next steps.

Marco - Good result seen here is that the requirements are clear. Could improve 
current tools or invent new tools. This is a significant result of this BOF.

Bert - Need to chat a little more on requirements document and possibly have an 
informational RFC.

Bilel Jamoussi- Need a decision soon. Dragging this to MPLS mailing list may not 
be good. Need bounded time frame for this decision. 2-3 weeks? To decide whether 
it will be done here or ITU.

Bert - If work is not done here, people are free to do it elsewhere. The purpose 
of this BOF was to get an understanding of problems etc. and it has been 
achieved.




From owner-mpls@UU.NET  Wed Jan  2 11:52:13 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06974
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:52:13 -0500 (EST)
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 QQlwbz02778;
	Wed, 2 Jan 2002 16:51:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbz12965
	for mpls-outgoing; Wed, 2 Jan 2002 16:51: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 QQlwbz12955
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:51:17 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 QQlwbz19886
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:50:46 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 QQlwbz01442
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:50: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 LAA16680;
	Wed, 2 Jan 2002 11:50:36 -0500 (EST)
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 LAA27627;
	Wed, 2 Jan 2002 11:50:37 -0500 (EST)
Message-ID: <3C333AC6.418EC2AF@marconi.com>
Date: Wed, 02 Jan 2002 11:52:22 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "Gopal@Home" <gnaganab@yahoo.com>
CC: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>, mpls@UU.NET,
        rsvp@ISI.EDU
Subject: Re: RSVP
References: <D11B30C7348BD511A40700010283497B3878E6@GAYATRI> <009601c18f55$60a1e7a0$030a0a0a@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Gopal@Home" wrote:
> 
> There is a new extension, 'Hello message'(rfc3209) which helps to
> recognize the presence or failure of the rsvp neighbor. This is
> optional and not mandatory for Rsvp/Te.

RSVP-Hello is not a discovery mechanism.  It can only be used for
failure detection.

Hellos are sent to a neighbor router's address, not a broadcast
address.  Therefore, you must already know who your neighbor is before
you can send a Hello to him.

-- David


From owner-mpls@UU.NET  Wed Jan  2 11:54:24 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07039
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:54:24 -0500 (EST)
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 QQlwbz01605;
	Wed, 2 Jan 2002 16:54:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwbz13309
	for mpls-outgoing; Wed, 2 Jan 2002 16:53: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 QQlwbz13290
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 16:53: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 QQlwbz02639
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:53:31 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 QQlwbz29665
	for <mpls@UU.NET>; Wed, 2 Jan 2002 16:53:17 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 LAA16928;
	Wed, 2 Jan 2002 11:53:21 -0500 (EST)
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 LAA28141;
	Wed, 2 Jan 2002 11:53:21 -0500 (EST)
Message-ID: <3C333B6A.E790B766@marconi.com>
Date: Wed, 02 Jan 2002 11:55:06 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET, rsvp@ISI.EDU
Subject: Re: RSVP
References: <200112280812.AA332529778@Mail.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:
> 
> There's no discovery mechanism, and all nodes in the expected LSP
> path must be configured.
> 
> From an operational point of view, RSVP-TE normally requires CSPF
> before signalling, which would in turn require IGP TE
> configuration.  Wherever IGP TE is configured, RSVP-TE should also
> be configured so the signalling would proceed across RSVP nodes
> only.

Not a requirement.

RSVP only requires a local forwarding table so that the next-hop address
and interface for a given destination may be determined.

How that forwarding table is generated is beyond the scope of RSVP.  It
is usually built from an IGP of some kind, but that is not a
requirement.

> There is a non-RSVP node discovery mechanism though.  See RFC3209
> 4.2.5.

You mean RFC 2205.  Non-RSVP node discovery is part of the core RSVP,
not part of the RSVP-TE extensions.

-- David


From owner-mpls@UU.NET  Wed Jan  2 12:01:54 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07161
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 12:01:54 -0500 (EST)
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 QQlwca21990;
	Wed, 2 Jan 2002 17:01:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwca18186
	for mpls-outgoing; Wed, 2 Jan 2002 17:01: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 QQlwca18141
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 17:01: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 QQlwca17389
	for <mpls@UU.NET>; Wed, 2 Jan 2002 17:00:57 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlwca12421
	for <mpls@UU.NET>; Wed, 2 Jan 2002 17:01:14 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 MAA17795;
	Wed, 2 Jan 2002 12:00:54 -0500 (EST)
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 MAA00005;
	Wed, 2 Jan 2002 12:00:55 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <ZNKNK0WF>; Wed, 2 Jan 2002 12:00:54 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55762EF5@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Toni Jackob'" <tonijackob@hotmail.com>, mpls@UU.NET
Subject: RE: LDP over unnumbered interfaces
Date: Wed, 2 Jan 2002 12:00:53 -0500 
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

-> The routes that are created over such interfaces are 
-> interface routes, which 
-> has not IP address or network. LDP needs some IP address 
-> that it can compare 
-> with the IP addresses that its LDP PEERs advertised to it.

  Unnumbered Interfaces uses some valid IP address (either
  borrowed from numbered interfaces or Router Address) as the
  source address for the IP packets originating that interface.

--Venkata Naidu


From owner-mpls@UU.NET  Wed Jan  2 14:26:52 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09039
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 14:26:51 -0500 (EST)
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 QQlwcj23437;
	Wed, 2 Jan 2002 19:25:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwcj22982
	for mpls-outgoing; Wed, 2 Jan 2002 19:24: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 QQlwcj22977
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 19:24:48 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 QQlwcj16310
	for <mpls@UU.NET>; Wed, 2 Jan 2002 19:24:27 GMT
Received: from Mail.TRINICOM.COM by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.149.136.4])
	id QQlwcj15589
	for <mpls@UU.NET>; Wed, 2 Jan 2002 19:24:03 GMT
Date: Wed,  2 Jan 2002 13:11:35 -0600
Message-Id: <200201021311.AA547684466@Mail.TRINICOM.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "Sean Crocker" <crockers@mail.trinicom.com>
Reply-To: <crockers@mail.trinicom.com>
To: <mpls@UU.NET>, <rsvp@ISI.EDU>, David Charlap  <David.Charlap@marconi.com>
Subject: Re: RSVP
X-Mailer: <IMail v7.03>
Sender: owner-mpls@UU.NET
Precedence: bulk

>> From an operational point of view, RSVP-TE normally requires CSPF
>> before signalling, which would in turn require IGP TE
>> configuration.  Wherever IGP TE is configured, RSVP-TE should also
>> be configured so the signalling would proceed across RSVP nodes
>> only.
>
>Not a requirement.

Emphasis on "operational point of view", as in normally network
operators will want to use CSPF before signalling and RSVP PATH
will probably never traverse non-RSVP nodes.  You've taken this
comment too literally.

>
>RSVP only requires a local forwarding table so that the next-hop address
>and interface for a given destination may be determined.
>
>How that forwarding table is generated is beyond the scope of RSVP.  It
>is usually built from an IGP of some kind, but that is not a
>requirement.
>
>> There is a non-RSVP node discovery mechanism though.  See RFC3209
>> 4.2.5.
>
>You mean RFC 2205.  Non-RSVP node discovery is part of the core RSVP,
>not part of the RSVP-TE extensions.

I meant what I said.  RFC3209 4.2.5 not only points to RFC2205 3.8,
it also makes the requirement unambiguous.

Sean

>-- David
>


From owner-mpls@UU.NET  Wed Jan  2 15:11:48 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09910
	for <mpls-archive@lists.ietf.org>; Wed, 2 Jan 2002 15:11:48 -0500 (EST)
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 QQlwcm05066;
	Wed, 2 Jan 2002 20:10:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwcm15264
	for mpls-outgoing; Wed, 2 Jan 2002 20:10: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 QQlwcm15249
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 2 Jan 2002 20:10:43 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 QQlwcm05676
	for <mpls@UU.NET>; Wed, 2 Jan 2002 20:10: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 QQlwcm01453
	for <mpls@UU.NET>; Wed, 2 Jan 2002 20:10: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 PAA06425;
	Wed, 2 Jan 2002 15:10:16 -0500 (EST)
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 PAA06365;
	Wed, 2 Jan 2002 15:10:17 -0500 (EST)
Message-ID: <3C33697E.B72AA58C@marconi.com>
Date: Wed, 02 Jan 2002 15:11:42 -0500
From: David Charlap <David.Charlap@marconi.com>
Reply-To: mpls@UU.NET
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET, rsvp@ISI.EDU
Subject: Re: RSVP
References: <200201021311.AA547684466@Mail.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:
> 
>> You mean RFC 2205.  Non-RSVP node discovery is part of the core
>> RSVP, not part of the RSVP-TE extensions.
> 
> I meant what I said.  RFC3209 4.2.5 not only points to RFC2205 3.8,
> it also makes the requirement unambiguous.

It adds a new requirement.  Non-MPLS RSVP is designed to work with
non-RSVP routers along the path.  In RFC 2205, the detection is in order
to inform downstream nodes.

RFC 3209 makes non-RSVP nodes along the path illegal, and therefore
changes the action when one is detected (PathErr instead of setting
ADSPEC break bits).  It does not, however, change, redefine or restate
the detection algorithm.

-- David


From owner-mpls@UU.NET  Thu Jan  3 11:45:21 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05738
	for <mpls-archive@lists.ietf.org>; Thu, 3 Jan 2002 11:45:20 -0500 (EST)
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 QQlwfq11033;
	Thu, 3 Jan 2002 16:40:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwfq12782
	for mpls-outgoing; Thu, 3 Jan 2002 16:40: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 QQlwfq12773
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 3 Jan 2002 16:39: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 QQlwfq21407
	for <mpls@UU.NET>; Thu, 3 Jan 2002 16:38:55 GMT
Received: from web20806.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20806.mail.yahoo.com [216.136.226.195])
	id QQlwfq08835
	for <mpls@UU.NET>; Thu, 3 Jan 2002 16:39:13 GMT
Message-ID: <20020103163851.37900.qmail@web20806.mail.yahoo.com>
Received: from [134.193.128.202] by web20806.mail.yahoo.com via HTTP; Thu, 03 Jan 2002 08:38:51 PST
Date: Thu, 3 Jan 2002 08:38:51 -0800 (PST)
From: senthil ayyasamy <mplsgeek@yahoo.com>
Subject: open questions before the TE community
To: RickGall1@aol.com, mpls-ops@mplsrc.com, mpls@UU.NET, te-wg@ops.ietf.org
In-Reply-To: <65.201d9b6d.295cddc1@aol.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1676423972-1010075931=:36190"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-1676423972-1010075931=:36190
Content-Type: text/plain; charset=us-ascii


 
Hi rick& all  , 
I was contemplating about rick's mail for past some  days...HIs  mail also talk about alll traffic theory stuff which is basically done for traffic modelling..I have came across a wonderfull IEEE communication paper " traffic theory and Internet " which discusses the statistical characteristics of Internet traffic at different time scales.The author also indicate the limitations of service differentiation as a means for guaranteeing QoS and highlight the importance of traditional traffic engineering approaches in ensuring that the network has sufficient capacity to handle offered demand through derived results (http://www.comsoc.org/ci/public/preview/roberts.html) .

    The author  at one place mentions that "Most providers systematically practice overbooking, 'allocating' available bandwidth several times over. Although this clearly violates the notion of service protection, perceived quality of service is satisfactory in most cases. It is tempting to deduce from this that reservation is not really necessary as long as admission control is employed to protect the QoS of existing traffic" .So,like I also have a question like if traditional traffic models itself provides a way for all TE capabilitie ..why is the need for TE mecahnisms proposed by IETF ITEWG like  service differentiation and QoS stuff all ..

    After going through most of the drafts in ITEWG..i got the idea that "This WG provides some mechanisms and frame work for TE and have not concentrated much on actual TE mechanisms..please clarify in this regard ...what is the actual objective of ITEWG other than giving inputs to other Wg's like MPLS and CCAMP...Is the WG coordinate the activities of all other sub-IP wg working in this area..

    This is my third question..when there are mechainsms for doing TE in IP networks itself ??? why cant they just be used..I have seen some literature in this side..really interesting works .(.http://www.research.att.com/~jrex/papers/ieeenet00.ps ) and also one other paper on the same subject (http://smg.ulb.ac.be/Preprints/Fortz99_29.html)....... These papers has convinced me that TE can be done in IP networks rather putting our time and energy in all multiservice networks(I am working in this area)o..so I like inputs from reserchers on what is the real advantage of MPLS for TE which IP networks cant provide ...

In a nutshell, we can view three choices for  TE 

1. Traditional traffic modelling taken from the well tested telephone networks by all possion modelling ,FBM , erlang calculation and all those stuff

2. Using IP network TE as proposed by Dr.Jennifer and et all in "NETSOPE " and also by optimizing OSPF weights 

3.Use the option of Multiservice networks like MPLS to TE by service diff and other QoS optimization principles....

Also one more question regarding this issue...when U have BW why should we do TE ???? Is there is any place where we need TE mecahnisms even when their is infinite BW 

     I would like the forum to answer all my questions to enlighten me on all this aspects as it will give input to my ongoing researh work..

Thanks in advance,

senthil.

  

 

  RickGall1@aol.com wrote: Hello all,

I need some help with traffic engineering.

I like to make things simple. If I were to describe traffic engineering as a 
two phase process,( 1. putting traffic where you want it, 2. Doing the math ) 
would that describe the two basic functions of TE?

1) Putting traffic where you want it could be RSVP-TE or CR-LDP.

2) Doing the math, 

a) Starting out with a bit/ link budget like a check book balance and 
removing all the cost of the OSI layers. Calculate the average overhead for 
each layer and subtract from the bit budget. Calculate the cost of the 
different types of data.

b) For voice calculations use the Erlang tables to estimate the needed 
channels.

I would like any feedback or help you can give me on this subject

Thank you
Rick Gallaher

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

SENTHIL KUMAR
MS(COMPUTER NETWORKING)
UMKC,
MO-64112,USA


---------------------------------
Do You Yahoo!?
Send your FREE holiday greetings online at Yahoo! Greetings.
--0-1676423972-1010075931=:36190
Content-Type: text/html; charset=us-ascii

<P>&nbsp;
<P>Hi rick&amp; all &nbsp;, 
<P>I was contemplating about rick's mail for past some&nbsp; days...HIs&nbsp; mail also talk about alll traffic theory stuff which is basically done for traffic modelling..I have came across a wonderfull IEEE communication paper " traffic theory and Internet " which discusses the statistical characteristics of Internet traffic at different time scales.The author also&nbsp;indicate the limitations of service differentiation as a means for guaranteeing QoS and highlight the importance of traditional traffic engineering approaches in ensuring that the network has sufficient capacity to handle offered demand through derived results (<A href="http://www.comsoc.org/ci/public/preview/roberts.html">http://www.comsoc.org/ci/public/preview/roberts.html</A>) .</P>
<P>&nbsp;&nbsp;&nbsp; The author&nbsp; at one place mentions that "Most providers systematically practice overbooking, 'allocating' available bandwidth several times over. Although this clearly violates the notion of service protection, perceived quality of service is satisfactory in most cases. It is tempting to deduce from this that reservation is not really necessary as long as admission control is employed to protect the QoS of existing traffic" .So,like I also have a question like if traditional traffic models itself provides a way for all TE capabilitie ..why is the need for TE mecahnisms proposed by IETF ITEWG like&nbsp; service differentiation and QoS stuff all ..</P>
<P>&nbsp;&nbsp;&nbsp; After going through most of the drafts in ITEWG..i got the idea that "This WG provides some mechanisms and frame work for TE and have not concentrated much on actual TE mechanisms..please clarify in this regard ...what is the actual objective of ITEWG other than giving inputs to other Wg's like MPLS and CCAMP...Is the WG coordinate the activities of all other sub-IP wg working in this area..</P>
<P>&nbsp;&nbsp;&nbsp; This is my third question..when there are mechainsms for doing TE in IP networks itself ??? why cant they just be used..I have seen some literature in this side..really interesting works .(.http://www.research.att.com/~jrex/papers/ieeenet00.ps&nbsp;) and&nbsp;also one other paper on the same subject (<A href="http://smg.ulb.ac.be/Preprints/Fortz99_29.html">http://smg.ulb.ac.be/Preprints/Fortz99_29.html</A>).......&nbsp;These papers has convinced me&nbsp;that&nbsp;TE can be done in IP networks rather putting&nbsp;our time and energy in all multiservice networks(I am working in this area)o..so&nbsp;I like&nbsp;inputs from reserchers on what is the real advantage of MPLS for TE which IP networks cant provide ...</P>
<P>In a&nbsp;nutshell, we can view three&nbsp;choices for &nbsp;TE </P>
<P>1. Traditional traffic modelling taken from the well tested telephone networks by all possion modelling ,FBM , erlang calculation and all those stuff</P>
<P>2. Using IP network TE as proposed by Dr.Jennifer and et all in "NETSOPE " and also by optimizing OSPF weights </P>
<P>3.Use the option of Multiservice networks like MPLS to TE by service diff and other QoS optimization principles....</P>
<P>Also one more question regarding this issue...when U have BW why should we do TE ???? Is there is any place where we need TE mecahnisms even when their is infinite BW </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp; I would like the forum to answer all my questions to enlighten me on all this aspects as it will give input to my ongoing researh work..</P>
<P>Thanks in advance,</P>
<P>senthil.</P>
<P>&nbsp; </P>
<P>&nbsp;</P>
<P>&nbsp; <B><I>RickGall1@aol.com</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hello all,<BR><BR>I need some help with traffic engineering.<BR><BR>I like to make things simple. If I were to describe traffic engineering as a <BR>two phase process,( 1. putting traffic where you want it, 2. Doing the math ) <BR>would that describe the two basic functions of TE?<BR><BR>1) Putting traffic where you want it could be RSVP-TE or CR-LDP.<BR><BR>2) Doing the math, <BR><BR>a) Starting out with a bit/ link budget like a check book balance and <BR>removing all the cost of the OSI layers. Calculate the average overhead for <BR>each layer and subtract from the bit budget. Calculate the cost of the <BR>different types of data.<BR><BR>b) For voice calculations use the Erlang tables to estimate the needed <BR>channels.<BR><BR>I would like any feedback or help you can give me on this subject<BR><BR>Thank you<BR>Rick Gallaher<BR><BR>-------<BR>The MPLS-OPS Mailing List<BR>Subscribe/Unsub!
!
!
!
scribe: http://www.mplsrc.com/mplsops.shtml<BR>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml</BLOCKQUOTE><BR><BR>SENTHIL KUMAR<br>MS(COMPUTER NETWORKING)<br>UMKC,<br>MO-64112,USA<p><br><hr size=1><b>Do You Yahoo!?</b><br>
Send your FREE holiday greetings online at <a href="http://rd.yahoo.com/mail_us/tag/?http://greetings.yahoo.com/">Yahoo! Greetings</a>.
--0-1676423972-1010075931=:36190--


From owner-mpls@UU.NET  Fri Jan  4 08:55:53 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02266
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 08:55:53 -0500 (EST)
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 QQlwix16964;
	Fri, 4 Jan 2002 13:54:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwix05919
	for mpls-outgoing; Fri, 4 Jan 2002 13:54: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 QQlwix05912
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 13:54: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 QQlwix08642
	for <mpls@uu.net>; Fri, 4 Jan 2002 13:54:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwix15293
	for <mpls@uu.net>; Fri, 4 Jan 2002 13:53: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 IAA26517 for <mpls@uu.net>; Fri, 4 Jan 2002 08:54:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25820 for mpls@uu.net; Fri, 4 Jan 2002 08:54:01 -0500 (EST)
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 QQlwix05858
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 13:53: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 QQlwix12889
	for <mpls@uu.net>; Fri, 4 Jan 2002 13:52:39 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 QQlwix18035
	for <mpls@uu.net>; Fri, 4 Jan 2002 13:52: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 IAA02133;
	Fri, 4 Jan 2002 08:52:37 -0500 (EST)
Message-Id: <200201041352.IAA02133@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-crldp-unnum-03.txt
Date: Fri, 04 Jan 2002 08:52:37 -0500
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		: Signalling Unnumbered Links in CR-LDP
	Author(s)	: K. Kompella, Y. Rekhter, A. Kullberg
	Filename	: draft-ietf-mpls-crldp-unnum-03.txt
	Pages		: 6
	Date		: 03-Jan-02
	
Current signalling used by MPLS TE doesn't provide support for
unnumbered links.  This document defines procedures and extensions to
CR-LDP, one of the MPLS TE signalling protocols, that are needed in
order to support unnumbered links.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-crldp-unnum-03.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Jan  4 09:04:39 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02466
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 09:04:39 -0500 (EST)
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 QQlwiy13930;
	Fri, 4 Jan 2002 14:03:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwiy17104
	for mpls-outgoing; Fri, 4 Jan 2002 14:03: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 QQlwiy17094
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 14:03: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 QQlwiy16157
	for <mpls@uu.net>; Fri, 4 Jan 2002 14:03:32 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQlwiy08030
	for <mpls@uu.net>; Fri, 4 Jan 2002 14:03:45 GMT
Received: from m2vwall3.wipro.com (m2vwall3.wipro.com [164.164.29.237])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g04E3Op18239
	for <mpls@uu.net>; Fri, 4 Jan 2002 19:33:24 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Fri, 04 Jan 2002 19:33:18 +0530
Received: from wipro ([192.168.220.134]) by
          sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GPF31H00.1M3 for <mpls@uu.net>; Fri, 4 Jan 2002 19:33:17 +0530 
Message-ID: <015a01c19529$9b286c80$86dca8c0@wipro.com>
From: "Girish Dandin" <girish.dandin@wipro.com>
To: <mpls@UU.NET>
Subject: TTL Processing in RFC 3032
Date: Fri, 4 Jan 2002 19:40:46 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-4a30f1b3-010b-11d6-a217-0000e22173f5"
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

This is a multi-part message in MIME format.

------=_NextPartTM-000-4a30f1b3-010b-11d6-a217-0000e22173f5
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0157_01C19557.B47BF340"

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

Hi

I have doubt in RFC 3032 regarding TTL processing (sec 2.4)

When packet needs to be given(fwd) to IPv4, RFC says, ( in sec 2.4.3, IP =
Dependent Rules), the value of the IP TTL field must be replaced with =
the OUT GOING TTL value.
Outgoing TTL value is the maximum of Incoming TTL Value -1 (OR) 0.
Now,  supposing a case of a Proxy Egress ( that is the Egress for the =
MPLS Domain, but the packet is still forwarded in the IP Domain) :
      Packet that is received by Shim layer would decrement the TTL =
Value by one, then it gets the Outgoing TTL which it would give to =
IPLayer. Now, IP Layer would decrement it one more time before =
forwarding the packet. That is, at the same node, TTL processing is done =
(decremented) twice, once on a Labelled Packet, other time on the IP =
Packet !
   I just wanted to know if my understanding is right ?,is the behavior =
normal?
 if not, how to come over this problem ?

Regards
Girish=20


------=_NextPart_000_0157_01C19557.B47BF340
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>Hi</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have doubt&nbsp;in RFC 3032 regarding =
TTL=20
processing (sec 2.4)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>When packet needs&nbsp;to be given(fwd) =
to IPv4,=20
RFC says, ( in sec 2.4.3, IP Dependent Rules), the value of the IP TTL =
field=20
must be replaced with the OUT GOING TTL value.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Outgoing TTL value is the maximum of =
Incoming TTL=20
Value -1 (OR) 0.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Now, </FONT>&nbsp;<FONT face=3DArial =
size=3D2>supposing=20
a case of a Proxy Egress ( that is the Egress for the MPLS Domain, but =
the=20
packet is still forwarded in the IP Domain) :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; &nbsp;&nbsp;&nbsp; Packet that =
is received=20
by Shim layer would decrement the TTL Value by one, then it gets the =
Outgoing=20
TTL which it would give to IPLayer. Now, IP Layer would decrement it one =
more=20
time before forwarding the packet. That is, at the same node, TTL=20
processing&nbsp;is done (decremented) twice, once on a Labelled Packet, =
other=20
time on the IP Packet !</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; I just wanted to know if =
my=20
understanding is right ?,is the behavior normal?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;if not, how to come over this =
problem=20
?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards<BR>Girish =
<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0157_01C19557.B47BF340--



------=_NextPartTM-000-4a30f1b3-010b-11d6-a217-0000e22173f5
Content-Type: text/plain;
	name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit

-------------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------

------=_NextPartTM-000-4a30f1b3-010b-11d6-a217-0000e22173f5--



From owner-mpls@UU.NET  Fri Jan  4 10:18:36 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05070
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 10:18:35 -0500 (EST)
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 QQlwjd24018;
	Fri, 4 Jan 2002 15:18:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwjd21754
	for mpls-outgoing; Fri, 4 Jan 2002 15:17: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 QQlwjd21747
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 15:17: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 QQlwjd18781
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:15:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwjc01485
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:14:44 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 KAA04770 for <mpls@uu.net>; Fri, 4 Jan 2002 10:15:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00041 for mpls@uu.net; Fri, 4 Jan 2002 10:15:01 -0500 (EST)
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 QQlwjc21380
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 15:14:01 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 QQlwjc17415
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:12:42 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwjc27741
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:12:23 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04485 for <mpls@uu.net>; Fri, 4 Jan 2002 10:12:41 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA09590 for <mpls@uu.net>; Fri, 4 Jan 2002 10:12:41 -0500 (EST)
Message-Id: <200201041512.KAA09590@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last Call on LSP Feedback
Date: Fri, 04 Jan 2002 10:12:41 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a two week WG last call on

   Improving Topology Data Base Accuracy with LSP Feedback  
    
                <draft-ietf-mpls-te-feed-03.txt>

The last call closes Friday Jan 18, 2002 at 2400 GMT.

...George 


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



 



From owner-mpls@UU.NET  Fri Jan  4 10:41:24 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05975
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 10:41:24 -0500 (EST)
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 QQlwje07501;
	Fri, 4 Jan 2002 15:39:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwje23383
	for mpls-outgoing; Fri, 4 Jan 2002 15:38: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 QQlwje23352
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 15:38:46 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 QQlwje05057
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:38:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwje10266
	for <mpls@uu.net>; Fri, 4 Jan 2002 15:37:43 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 KAA08299 for <mpls@uu.net>; Fri, 4 Jan 2002 10:38:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA01615 for mpls@uu.net; Fri, 4 Jan 2002 10:38:01 -0500 (EST)
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 QQlwje23276
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 15:36:55 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 QQlwje28727
	for <mpls@UU.NET>; Fri, 4 Jan 2002 15:36:00 GMT
Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQlwje06882
	for <mpls@UU.NET>; Fri, 4 Jan 2002 15:35:41 GMT
Received: (qmail 11581 invoked by uid 104); 4 Jan 2002 15:35:59 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4179. . Clean. Processed in 0.495634 secs); 04 Jan 2002 15:35:59 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by father.pmc-sierra.bc.ca with SMTP; 4 Jan 2002 15:35:58 -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 g04F6gc07437;
	Fri, 4 Jan 2002 07:06:42 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <XNRN68X2>; Fri, 4 Jan 2002 07:06:43 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A4C2@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Girish Dandin'" <girish.dandin@wipro.com>, mpls@UU.NET
Subject: RE: TTL Processing in RFC 3032
Date: Fri, 4 Jan 2002 07:06:41 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19531.6A687010"
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_01C19531.6A687010
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Girish,
 
Check the following draft, which tries to clarify the TTL processing:
 
http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt <http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt> 
 
Yours,
-Shahram

-----Original Message-----
From: Girish Dandin [mailto:girish.dandin@wipro.com]
Sent: Friday, January 04, 2002 9:11 AM
To: mpls@UU.NET
Subject: TTL Processing in RFC 3032


Hi
 
I have doubt in RFC 3032 regarding TTL processing (sec 2.4)
 
When packet needs to be given(fwd) to IPv4, RFC says, ( in sec 2.4.3, IP Dependent Rules), the value of the IP TTL field must be replaced with the OUT GOING TTL value.
Outgoing TTL value is the maximum of Incoming TTL Value -1 (OR) 0.
Now,  supposing a case of a Proxy Egress ( that is the Egress for the MPLS Domain, but the packet is still forwarded in the IP Domain) :
      Packet that is received by Shim layer would decrement the TTL Value by one, then it gets the Outgoing TTL which it would give to IPLayer. Now, IP Layer would decrement it one more time before forwarding the packet. That is, at the same node, TTL processing is done (decremented) twice, once on a Labelled Packet, other time on the IP Packet !
   I just wanted to know if my understanding is right ?,is the behavior normal?
 if not, how to come over this problem ?
 
Regards
Girish 



------_=_NextPart_001_01C19531.6A687010
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">


<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D679340615-04012002>Hi=20
Girish,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D679340615-04012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D679340615-04012002>Check=20
the following draft, which tries to clarify the TTL=20
processing:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D679340615-04012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D679340615-04012002><A=20
href=3D"http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01=
.txt">http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.=
txt</A></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D679340615-04012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D679340615-04012002>Yours,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D679340615-04012002>-Shahram</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Girish Dandin=20
  [mailto:girish.dandin@wipro.com]<BR><B>Sent:</B> Friday, January 04, =
2002 9:11=20
  AM<BR><B>To:</B> mpls@UU.NET<BR><B>Subject:</B> TTL Processing in RFC =

  3032<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>Hi</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I have doubt&nbsp;in RFC 3032 =
regarding TTL=20
  processing (sec 2.4)</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When packet needs&nbsp;to be =
given(fwd) to IPv4,=20
  RFC says, ( in sec 2.4.3, IP Dependent Rules), the value of the IP =
TTL field=20
  must be replaced with the OUT GOING TTL value.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Outgoing TTL value is the maximum of =
Incoming TTL=20
  Value -1 (OR) 0.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Now, </FONT>&nbsp;<FONT face=3DArial =

  size=3D2>supposing a case of a Proxy Egress ( that is the Egress for =
the MPLS=20
  Domain, but the packet is still forwarded in the IP Domain) =
:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp; &nbsp;&nbsp;&nbsp; Packet =
that is received=20
  by Shim layer would decrement the TTL Value by one, then it gets the =
Outgoing=20
  TTL which it would give to IPLayer. Now, IP Layer would decrement it =
one more=20
  time before forwarding the packet. That is, at the same node, TTL=20
  processing&nbsp;is done (decremented) twice, once on a Labelled =
Packet, other=20
  time on the IP Packet !</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; I just wanted to know =
if my=20
  understanding is right ?,is the behavior normal?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;if not, how to come over this =
problem=20
  ?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Regards<BR>Girish=20
<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19531.6A687010--



From owner-mpls@UU.NET  Fri Jan  4 12:49:55 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09559
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 12:49:55 -0500 (EST)
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 QQlwjn14187;
	Fri, 4 Jan 2002 17:49:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwjn12037
	for mpls-outgoing; Fri, 4 Jan 2002 17:49: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 QQlwjn12030
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 17:49: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 QQlwjn13993
	for <mpls@UU.NET>; Fri, 4 Jan 2002 17:47:47 GMT
Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange.movaz.com [65.205.166.141])
	id QQlwjn24359
	for <mpls@UU.NET>; Fri, 4 Jan 2002 17:47:32 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 4 Jan 2002 12:47:47 -0500
Message-ID: <02bd01c19547$eb9ee400$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <mpls@UU.NET>
Cc: "George Swallow" <swallow@cisco.com>
References: <200201041512.KAA09590@telescope.cisco.com>
Subject: Re: Last Call on LSP Feedback
Date: Fri, 4 Jan 2002 12:47:46 -0500
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: 04 Jan 2002 17:47:47.0212 (UTC) FILETIME=[EBAA7CC0:01C19547]
Sender: owner-mpls@UU.NET
Precedence: bulk

Would it not be appropriate to change the name of this draft to include the fact
that the protocol extensions defined apply to CR-LDP only?  This could also
usefully be pointed out in the Abstract.

Alternatively, perhaps it isn't too late to define the RSVP extensions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
----- Original Message -----
From: "George Swallow" <swallow@cisco.com>
To: <mpls@UU.NET>
Sent: Friday, January 04, 2002 10:12 AM
Subject: Last Call on LSP Feedback


> This message begins a two week WG last call on
>
>    Improving Topology Data Base Accuracy with LSP Feedback
>
>                 <draft-ietf-mpls-te-feed-03.txt>
>
> The last call closes Friday Jan 18, 2002 at 2400 GMT.
>
> ...George
>
>
> ======================================================================
> George Swallow          Cisco Systems                   (978) 497-8143
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
>
>
>
>
>




From owner-mpls@UU.NET  Fri Jan  4 13:35:06 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10459
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 13:35:06 -0500 (EST)
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 QQlwjq03049;
	Fri, 4 Jan 2002 18:34:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwjq04820
	for mpls-outgoing; Fri, 4 Jan 2002 18:34: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 QQlwjq04807
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 18:33:52 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 QQlwjq06156
	for <mpls@UU.NET>; Fri, 4 Jan 2002 18:33:41 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlwjq09978
	for <mpls@UU.NET>; Fri, 4 Jan 2002 18:33:19 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04IXME05298;
	Fri, 4 Jan 2002 13:33:22 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04IXKA29555;
	Fri, 4 Jan 2002 13:33:20 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <CJV75RDP>; Fri, 4 Jan 2002 13:31:43 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6E6B8C6@zcard0ke.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Adrian Farrel <afarrel@movaz.com>, mpls@UU.NET
Cc: George Swallow <swallow@cisco.com>
Subject: RE: Last Call on LSP Feedback
Date: Fri, 4 Jan 2002 12:59:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19549.8F42B770"
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_01C19549.8F42B770
Content-Type: text/plain;
	charset="iso-8859-1"

Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:afarrel@movaz.com]
> Sent: Friday, January 04, 2002 12:48 PM
> To: mpls@UU.NET
> Cc: George Swallow
> Subject: Re: Last Call on LSP Feedback
> 
> 
> Would it not be appropriate to change the name of this draft 
> to include the fact
> that the protocol extensions defined apply to CR-LDP only?  
> This could also
> usefully be pointed out in the Abstract.

Yes True.

> 
> Alternatively, perhaps it isn't too late to define the RSVP 
> extensions.

Pointed out in the text. I think there is a requirement that 
RSVP and CR-LDP be specified in separate documents otherwise 
it is hard to quote RFC compliance. I would be willing to 
do an RSVP equivalent document with a little help to make sure 
I put the objects in the right place.

Don

> 
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> afarrel@movaz.com
> ----- Original Message -----
> From: "George Swallow" <swallow@cisco.com>
> To: <mpls@UU.NET>
> Sent: Friday, January 04, 2002 10:12 AM
> Subject: Last Call on LSP Feedback
> 
> 
> > This message begins a two week WG last call on
> >
> >    Improving Topology Data Base Accuracy with LSP Feedback
> >
> >                 <draft-ietf-mpls-te-feed-03.txt>
> >
> > The last call closes Friday Jan 18, 2002 at 2400 GMT.
> >
> > ...George
> >
> >
> > 
> ======================================================================
> > George Swallow          Cisco Systems                   
> (978) 497-8143
> >                         250 Apollo Drive
> >                         Chelmsford, Ma 01824
> >
> >
> >
> >
> >
> 
> 
> 

------_=_NextPart_001_01C19549.8F42B770
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: Last Call on LSP Feedback</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Adrian</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Adrian Farrel [<A =
HREF=3D"mailto:afarrel@movaz.com">mailto:afarrel@movaz.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 04, 2002 12:48 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: George Swallow</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Last Call on LSP Feedback</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Would it not be appropriate to change the name =
of this draft </FONT>
<BR><FONT SIZE=3D2>&gt; to include the fact</FONT>
<BR><FONT SIZE=3D2>&gt; that the protocol extensions defined apply to =
CR-LDP only?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This could also</FONT>
<BR><FONT SIZE=3D2>&gt; usefully be pointed out in the Abstract.</FONT>
</P>

<P><FONT SIZE=3D2>Yes True.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Alternatively, perhaps it isn't too late to =
define the RSVP </FONT>
<BR><FONT SIZE=3D2>&gt; extensions.</FONT>
</P>

<P><FONT SIZE=3D2>Pointed out in the text. I think there is a =
requirement that </FONT>
<BR><FONT SIZE=3D2>RSVP and CR-LDP be specified in separate documents =
otherwise </FONT>
<BR><FONT SIZE=3D2>it is hard to quote RFC compliance. I would be =
willing to </FONT>
<BR><FONT SIZE=3D2>do an RSVP equivalent document with a little help to =
make sure </FONT>
<BR><FONT SIZE=3D2>I put the objects in the right place.</FONT>
</P>

<P><FONT SIZE=3D2>Don</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Adrian</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>&gt; Movaz Networks Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; Tel: 703-847-1867</FONT>
<BR><FONT SIZE=3D2>&gt; afarrel@movaz.com</FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;George Swallow&quot; =
&lt;swallow@cisco.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &lt;mpls@UU.NET&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 04, 2002 10:12 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Last Call on LSP Feedback</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This message begins a two week WG last =
call on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Improving Topology Data =
Base Accuracy with LSP Feedback</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;draft-ietf-mpls-te-feed-03.txt&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The last call closes Friday Jan 18, 2002 =
at 2400 GMT.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ...George</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT=
>
<BR><FONT SIZE=3D2>&gt; &gt; George =
Swallow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; (978) 497-8143</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; 250 Apollo Drive</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; Chelmsford, Ma 01824</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19549.8F42B770--


From owner-mpls@UU.NET  Fri Jan  4 14:51:02 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12426
	for <mpls-archive@lists.ietf.org>; Fri, 4 Jan 2002 14:51:01 -0500 (EST)
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 QQlwjv02949;
	Fri, 4 Jan 2002 19:49:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwjv29744
	for mpls-outgoing; Fri, 4 Jan 2002 19:49: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 QQlwjv29734
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 19:49: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 QQlwjv00583
	for <mpls@uu.net>; Fri, 4 Jan 2002 19:49:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwjv21325
	for <mpls@uu.net>; Fri, 4 Jan 2002 19:48:44 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 OAA11685 for <mpls@uu.net>; Fri, 4 Jan 2002 14:49:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA14493 for mpls@uu.net; Fri, 4 Jan 2002 14:49:01 -0500 (EST)
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 QQlwjv29632
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 4 Jan 2002 19:47:39 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 QQlwjv25160
	for <mpls@uu.net>; Fri, 4 Jan 2002 19:47:19 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwjv18068
	for <mpls@uu.net>; Fri, 4 Jan 2002 19:47:00 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11456 for <mpls@uu.net>; Fri, 4 Jan 2002 14:47:18 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA12015 for <mpls@uu.net>; Fri, 4 Jan 2002 14:47:18 -0500 (EST)
Message-Id: <200201041947.OAA12015@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last calls on Hierarchy, Bundle, and Unnum
Date: Fri, 04 Jan 2002 14:47:18 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a two week WG last call on the following four
interrelated drafts:

 LSP Hierarchy with MPLS TE
   draft-ietf-mpls-lsp-hierarchy-03.txt

 Link Bundling in MPLS Traffic Engineering
   draft-ietf-mpls-bundle-01.txt

 Signalling Unnumbered Links in CR-LDP
   draft-ietf-mpls-crldp-unnum-03.txt

 Signalling Unnumbered Links in RSVP-TE
   draft-ietf-mpls-rsvp-unnum-03.txt

The last calls close Friday Jan 18, 2002 at 2400 GMT.

...George 



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





From owner-mpls@UU.NET  Sun Jan  6 22:52:55 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01248
	for <mpls-archive@lists.ietf.org>; Sun, 6 Jan 2002 22:52:55 -0500 (EST)
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 QQlwsl18713;
	Mon, 7 Jan 2002 03:51:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwsl21417
	for mpls-outgoing; Mon, 7 Jan 2002 03:51: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 QQlwsl21412
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 03:51: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 QQlwsl10573
	for <mpls@UU.NET>; Mon, 7 Jan 2002 03:51:51 GMT
Received: from mail.cad.zju.edu.cn by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [210.32.131.2])
	id QQlwsl05039
	for <mpls@UU.NET>; Mon, 7 Jan 2002 03:52:08 GMT
Received: (qmail 17194 invoked from network); 7 Jan 2002 03:51:57 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 7 Jan 2002 03:51:57 -0000
Message-ID: <3C391A7A.4F6C868B@cad.zju.edu.cn>
Date: Mon, 07 Jan 2002 11:48:10 +0800
From: Jing Shen <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Will MPLS replace ATM in near future?
Content-Type: multipart/alternative;
 boundary="------------AE040CBBC0537FEED3DDE6D8"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------AE040CBBC0537FEED3DDE6D8
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

Hi:

I've noticed that the research on MPLS has come to a very hot spot in
past days. And, now Cisco and other company start to
provide MPLS enabled interconnection product, both in backbone
interconnection product and those for access network. I even read about
"ethernet over MPLS". I think this will change not only current
interconnection technology but also those backbone transmission
techniques.
Because, as I think, this means now MPLS can take the place of
those high speed access network ( PPPoA, PPPoE ) dominated by ATM, and
the method how those subscriber channels are multiplexed
into a up transmission backbone. If the backbone is also made up of
MPLS, the method will be more flexible and gives more service. Also the
variable length of MPLS frame will give
more effient usage of physical channal.

So, I want to know is ATM will be out-of-day in near future ?

--
Jing Shen

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************



--------------AE040CBBC0537FEED3DDE6D8
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi:
<p>I've noticed that the research on MPLS has come to a very hot spot in
past days. And, now Cisco and other company start to
<br>provide MPLS enabled interconnection product, both in backbone interconnection
product and those for access network. I even read about "ethernet over
MPLS". I think this will change not only current interconnection technology
but also those backbone transmission techniques.
<br>Because, as I think, this means now MPLS can take the place of
<br>those high speed access network ( PPPoA, PPPoE ) dominated by ATM,
and the method how those subscriber channels are multiplexed
<br>into a up transmission backbone. If the backbone is also made up of
MPLS, the method will be more flexible and gives more service. Also the
variable length of MPLS frame will give
<br>more effient usage of physical channal.
<p>So, I want to know is ATM will be out-of-day in near future ?
<pre>--&nbsp;
Jing Shen

**********************************************************************
* The SunShine of life is made up of very little beams which is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
*&nbsp; bright all the time&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
**********************************************************************</pre>
&nbsp;</html>

--------------AE040CBBC0537FEED3DDE6D8--



From owner-mpls@UU.NET  Sun Jan  6 23:19:09 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01450
	for <mpls-archive@lists.ietf.org>; Sun, 6 Jan 2002 23:19:08 -0500 (EST)
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 QQlwsn09128;
	Mon, 7 Jan 2002 04:18:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwsn13540
	for mpls-outgoing; Mon, 7 Jan 2002 04:18: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 QQlwsn13535
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 04:18:29 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 QQlwsn23582
	for <mpls@uu.net>; Mon, 7 Jan 2002 04:17:19 GMT
From: Rghines1@aol.com
Received: from imo-r10.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-r10.mx.aol.com [152.163.225.106])
	id QQlwsn16189
	for <mpls@uu.net>; Mon, 7 Jan 2002 04:17:00 GMT
Received: from Rghines1@aol.com
	by imo-r10.mx.aol.com (mail_out_v31_r1.9.) id 2.a6.1f2f2546 (3941);
	Sun, 6 Jan 2002 23:15:23 -0500 (EST)
Message-ID: <a6.1f2f2546.296a7ada@aol.com>
Date: Sun, 6 Jan 2002 23:15:22 EST
Subject: Re: Will MPLS replace ATM in near future?
To: jshen@cad.zju.edu.cn, mpls@UU.NET, mpls-ops@mplsrc.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 7.0 for Windows US sub 118
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Displace or Replace?


From owner-mpls@UU.NET  Sun Jan  6 23:26:01 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01488
	for <mpls-archive@lists.ietf.org>; Sun, 6 Jan 2002 23:26:01 -0500 (EST)
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 QQlwsn25577;
	Mon, 7 Jan 2002 04:25:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwsn13992
	for mpls-outgoing; Mon, 7 Jan 2002 04:25: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 QQlwsn13985
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 04:25: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 QQlwsn26667
	for <mpls@UU.NET>; Mon, 7 Jan 2002 04:24:31 GMT
Received: from web20803.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20803.mail.yahoo.com [216.136.226.192])
	id QQlwsn05051
	for <mpls@UU.NET>; Mon, 7 Jan 2002 04:24:50 GMT
Message-ID: <20020107042430.8649.qmail@web20803.mail.yahoo.com>
Received: from [134.193.6.56] by web20803.mail.yahoo.com via HTTP; Sun, 06 Jan 2002 20:24:30 PST
Date: Sun, 6 Jan 2002 20:24:30 -0800 (PST)
From: senthil ayyasamy <mplsgeek@yahoo.com>
Subject: Re: Will MPLS replace ATM in near future?
To: jshen@cad.zju.edu.cn, mpls@UU.NET, mpls-ops@mplsrc.com
In-Reply-To: <3C391A7A.4F6C868B@cad.zju.edu.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1355130764-1010377470=:7851"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-1355130764-1010377470=:7851
Content-Type: text/plain; charset=us-ascii


 Hi Shen,
    Ur reasoning seems to be good ..But what i feel is MPLS will help to make ATM and IP networks to co-exist than replacing ATM.Also, ATM is a well-tested technology with all features..I think lot of traffic engineering mechanisms in ATM  is also applicable to MPLS environ..Also many features now adapted in IETF for MPLS have come from ATM features only..So,I dont think ATM will be out-of-day in the near future rather MPLS will butress ATM usage .This seems to be possible but i am not aware whether it is being done in the industry..It is for the industry to answer!!! 
senthil.
  Jing Shen <jshen@cad.zju.edu.cn> wrote: Hi: 
I've noticed that the research on MPLS has come to a very hot spot in past days. And, now Cisco and other company start to 
provide MPLS enabled interconnection product, both in backbone interconnection product and those for access network. I even read about "ethernet over MPLS". I think this will change not only current interconnection technology but also those backbone transmission techniques. 
Because, as I think, this means now MPLS can take the place of 
those high speed access network ( PPPoA, PPPoE ) dominated by ATM, and the method how those subscriber channels are multiplexed 
into a up transmission backbone. If the backbone is also made up of MPLS, the method will be more flexible and gives more service. Also the variable length of MPLS frame will give 
more effient usage of physical channal. 
So, I want to know is ATM will be out-of-day in near future ? 
-- Jing Shen*********************************************************************** The SunShine of life is made up of very little beams which is      **  bright all the time                                               ***********************************************************************
  

SENTHIL KUMAR
MS(COMPUTER NETWORKING)
UMKC,
MO-64112,USA


---------------------------------
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail.
--0-1355130764-1010377470=:7851
Content-Type: text/html; charset=us-ascii

<P>&nbsp;Hi Shen,
<P>&nbsp;&nbsp;&nbsp; Ur reasoning seems to be good ..But what i feel is MPLS will help to make ATM and IP networks to co-exist than replacing ATM.Also, ATM is a well-tested technology with all features..I think lot of traffic engineering mechanisms in ATM &nbsp;is also applicable to MPLS environ..Also many features now adapted in IETF for MPLS have come from ATM features only..So,I dont think ATM will be out-of-day in the near future rather MPLS will butress ATM usage .This seems to be possible but i am not aware whether it is being done in the industry..It is for the industry to answer!!! 
<P>senthil.
<P>&nbsp; <B><I>Jing Shen &lt;jshen@cad.zju.edu.cn&gt;</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Hi: 
<P>I've noticed that the research on MPLS has come to a very hot spot in past days. And, now Cisco and other company start to <BR>provide MPLS enabled interconnection product, both in backbone interconnection product and those for access network. I even read about "ethernet over MPLS". I think this will change not only current interconnection technology but also those backbone transmission techniques. <BR>Because, as I think, this means now MPLS can take the place of <BR>those high speed access network ( PPPoA, PPPoE ) dominated by ATM, and the method how those subscriber channels are multiplexed <BR>into a up transmission backbone. If the backbone is also made up of MPLS, the method will be more flexible and gives more service. Also the variable length of MPLS frame will give <BR>more effient usage of physical channal. 
<P>So, I want to know is ATM will be out-of-day in near future ? <PRE>--&nbsp;
Jing Shen

**********************************************************************
* The SunShine of life is made up of very little beams which is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
*&nbsp; bright all the time&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
**********************************************************************</PRE>&nbsp; </BLOCKQUOTE><BR><BR>SENTHIL KUMAR<br>MS(COMPUTER NETWORKING)<br>UMKC,<br>MO-64112,USA<p><br><hr size=1><b>Do You Yahoo!?</b><br>
Send FREE <a href="http://rd.yahoo.com/mail_us/tag/?http://promo.yahoo.com/videomail/">video</a> emails in <a href="http://rd.yahoo.com/mail_us/tag/?http://mail.yahoo.com/">Yahoo! Mail</a>.
--0-1355130764-1010377470=:7851--


From owner-mpls@UU.NET  Mon Jan  7 09:26:50 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15186
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 09:26:50 -0500 (EST)
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 QQlwub28211;
	Mon, 7 Jan 2002 14:25:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwub19332
	for mpls-outgoing; Mon, 7 Jan 2002 14:25: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 QQlwub19307
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 14:25: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 QQlwub16025
	for <mpls@uu.net>; Mon, 7 Jan 2002 14:24:43 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwub02430
	for <mpls@uu.net>; Mon, 7 Jan 2002 14:24:26 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA17235 for <mpls@uu.net>; Mon, 7 Jan 2002 09:24:42 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01381 for mpls@uu.net; Mon, 7 Jan 2002 09:24:42 -0500 (EST)
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 QQlwpv28338
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 6 Jan 2002 10:53: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 QQlwpv25383
	for <mpls@UU.NET>; Sun, 6 Jan 2002 10:52:40 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [207.68.162.206])
	id QQlwpv09513
	for <mpls@UU.NET>; Sun, 6 Jan 2002 10:52:24 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 6 Jan 2002 02:52:39 -0800
X-Originating-IP: [212.25.110.131]
From: "kaki brown" <brown_kaki@hotmail.com>
To: <mpls@UU.NET>
Subject: questions about draft-pan-rsvp-fast-reroute Nov 2000
Date: Sun, 6 Jan 2002 12:52:13 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000D_01C196B0.F62D77F0"
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
Message-ID: <DAV71YXg9ba5qSjYUdB0000a393@hotmail.com>
X-OriginalArrivalTime: 06 Jan 2002 10:52:39.0906 (UTC) FILETIME=[4294B420:01C196A0]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

happy new year to all the members.
I am very interested in the fast reroute protection and reading the =
above draft I got some questions.

1) In DETOUR solution - in the PLR - what is the proposed CSPF decision =
where to merge to the primary LSP? should it find the Shortest path to =
any of the tail nodes?should it insist reaching the NNHOP? should it =
support multi destination computations?

2) again in DETOUR method - should the LSP constraints (include-all =
exclude-all bandwidth) by default be copy into the DETOUR Object? or =
should the user be forced to configure them separately ,or it has =
default values?

3) BYPASS method - suppose I have configured a bypass tunnel with a =
certain BW. now Im starting to cinfigure protected LSPs that will use =
this bypass. what happenes when the sum of those LSPs reaches the bypass =
limit? or to be more specifically - in cisco's implementation - what =
happens when configuring an interface to be protected by a LSP - =
shouldn't a bandwidth availability check be made ?


thanks.
kaki.

------=_NextPart_000_000D_01C196B0.F62D77F0
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>happy new year to all the =
members.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I am very interested in the fast =
reroute protection=20
and reading the above draft I got some questions.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) In DETOUR solution - in the PLR - =
what is the=20
proposed CSPF decision where to merge to the primary LSP? should it find =
the=20
Shortest path to any of the tail nodes?should it insist reaching the =
NNHOP?=20
should it support multi destination computations?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) again in DETOUR method - should the =
LSP=20
constraints (include-all exclude-all bandwidth) by default be copy into =
the=20
DETOUR Object? or should the user be forced to configure them separately =
,or it=20
has default values?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3) BYPASS method - suppose I have =
configured a=20
bypass tunnel with a certain BW. now Im starting to cinfigure protected =
LSPs=20
that will use this bypass. what happenes when the sum of those LSPs =
reaches the=20
bypass limit?&nbsp;or to be more specifically - in cisco's =
implementation - what=20
happens when configuring an interface to&nbsp;be protected by a LSP - =
shouldn't=20
a bandwidth availability check be made ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks.</FONT></DIV>
<DIV>kaki.</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_000D_01C196B0.F62D77F0--



From owner-mpls@UU.NET  Mon Jan  7 09:28:17 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15256
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 09:28:16 -0500 (EST)
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 QQlwub28155;
	Mon, 7 Jan 2002 14:27:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwub19588
	for mpls-outgoing; Mon, 7 Jan 2002 14:27: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 QQlwub19581
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 14:26:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlwub16129
	for <mpls@uu.net>; Mon, 7 Jan 2002 14:26:41 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwub05607
	for <mpls@uu.net>; Mon, 7 Jan 2002 14:26: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 JAA17422 for <mpls@uu.net>; Mon, 7 Jan 2002 09:26:40 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01477 for mpls@uu.net; Mon, 7 Jan 2002 09:26:40 -0500 (EST)
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 QQlwtx24993
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 13:26:29 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 QQlwtx09164
	for <mpls@uu.net>; Mon, 7 Jan 2002 13:26:19 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlwtx10539
	for <mpls@uu.net>; Mon, 7 Jan 2002 13:26:01 GMT
Received: from netbrahma.com (sumanbs.netbrahma.com [172.16.72.148]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZJY4WYJT; Mon, 7 Jan 2002 18:55:21 +0530
Message-ID: <3C39A1B4.84C5455E@netbrahma.com>
Date: Mon, 07 Jan 2002 18:55:08 +0530
From: sumeshkp <sumeshkp@netbrahma.com>
Reply-To: sumeshkp@netbrahma.com
Organization: netbrahma
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Some questions on HA
Content-Type: multipart/alternative;
 boundary="------------EC977610664D4B29C71B39F5"
Sender: owner-mpls@UU.NET
Precedence: bulk


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

hi all,

i have some quick questions on high availability for MPLS. it will be
great if any one can answer this for me

assumption: we are considering only data plane redundancy.

1. what is the format of FIS and FRS (not to be found in any
contermporary drafts)
2. can the "root" be outside the PML, IOW can root be outside the
protection domain configured?
3. should PSL always terminate the FIS or can it be extended over to the
Ingress


thank you very much,
warm regards,
sumesh

--
           \\\///             | Url  : http://www.netbrahma.com     |
          netbrahma           | Phone: +91-80-552-1452 X 263 (work) |
           ///\\\             |        +91-80-534-2165 (home)       |
Internext Networking Software | Fax  : +91-80-553-7533              |



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi all,
<p>i have some quick questions on high availability for MPLS. it will be
great if any one can answer this for me
<p>assumption:&nbsp;we are considering only data plane redundancy.
<p>1. what is the format of FIS and FRS (not to be found in any contermporary
drafts)
<br>2. can the "root" be outside the PML, IOW&nbsp;can root be outside
the protection domain configured?
<br>3. should PSL always terminate the FIS or can it be extended over to
the Ingress
<br>&nbsp;
<p>thank you very much,
<br>warm regards,
<br>sumesh
<pre>--&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \\\///&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Url&nbsp; : <A HREF="http://www.netbrahma.com">http://www.netbrahma.com</A>&nbsp;&nbsp;&nbsp;&nbsp; |
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; netbrahma&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Phone: +91-80-552-1452 X 263 (work) |
&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;&nbsp;&nbsp;&nbsp; +91-80-534-2165 (home)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
Internext Networking Software | Fax&nbsp; : +91-80-553-7533&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</pre>
&nbsp;</html>

--------------EC977610664D4B29C71B39F5--



From owner-mpls@UU.NET  Mon Jan  7 10:37:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17497
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 10:37:58 -0500 (EST)
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 QQlwug29227;
	Mon, 7 Jan 2002 15:32:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwug14772
	for mpls-outgoing; Mon, 7 Jan 2002 15:32: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 QQlwug14765
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 15:32:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlwug15299
	for <mpls@UU.NET>; Mon, 7 Jan 2002 15:32:03 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlwug28434
	for <mpls@UU.NET>; Mon, 7 Jan 2002 15:32:22 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FW0A08808;
	Mon, 7 Jan 2002 10:32:00 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FVwM05441;
	Mon, 7 Jan 2002 10:31:58 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <CPSX31WS>; Mon, 7 Jan 2002 10:30:22 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD34014BEDF8@zcard0ka.ca.nortel.com>
From: "David Allan"<dallan@nortelnetworks.com>
To: sumeshkp@netbrahma.com, mpls@UU.NET
Subject: RE: Some questions on HA
Date: Mon, 7 Jan 2002 10:29:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19790.127DE590"
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_01C19790.127DE590
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Sumesh:
 
FIS and FRS are not defined anywhere. The draft assumed that such capability
was required and described it in generalized terms (for example, reading the
definition it could be somthing on the user plane or control plane). 
 
The closest functional equivalent to FIS/FRS on the user plane is the
CV/FDI/BDI currently proposed in the ITU-T Y.1711 work. FDI/BDI (forward and
backward defect indication) are the equivalent to FIS, and rules exist for
handling CV whereby failure and recovery would be determined (there is no
explicit "it has been fixed" message).
 
cheers
Dave

-----Original Message-----
From: sumeshkp [mailto:sumeshkp@netbrahma.com]
Sent: Monday, January 07, 2002 8:25 AM
To: mpls@UU.NET
Subject: Some questions on HA


hi all, 

i have some quick questions on high availability for MPLS. it will be great
if any one can answer this for me 


assumption: we are considering only data plane redundancy. 


1. what is the format of FIS and FRS (not to be found in any contermporary
drafts) 
2. can the "root" be outside the PML, IOW can root be outside the protection
domain configured? 
3. should PSL always terminate the FIS or can it be extended over to the
Ingress 
  


thank you very much, 
warm regards, 
sumesh 

-- 

           \\\///             | Url  :  http://www.netbrahma.com
<http://www.netbrahma.com>      |

          netbrahma           | Phone: +91-80-552-1452 X 263 (work) |

           ///\\\             |        +91-80-534-2165 (home)       |

Internext Networking Software | Fax  : +91-80-553-7533              |
  


------_=_NextPart_001_01C19790.127DE590
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">


<META content=3D"MSHTML 5.00.3314.2100" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D497211815-07012002>Hi=20
Sumesh:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D497211815-07012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D497211815-07012002>FIS=20
and FRS are not defined anywhere. The draft assumed that such =
capability was=20
required and described it in generalized terms (for example, reading =
the=20
definition it could be somthing on the user plane or control plane).=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D497211815-07012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D497211815-07012002>The closest functional equivalent to FIS/FRS =
on the=20
user plane is the CV/FDI/BDI currently proposed in the ITU-T Y.1711=20
work.</SPAN>&nbsp;<SPAN class=3D497211815-07012002>FDI/BDI (forward and =
backward=20
defect indication) are the equivalent to FIS, and rules exist for =
handling CV=20
whereby failure and recovery would be determined (there is no explicit =
"it has=20
been fixed" message).</SPAN></FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D497211815-07012002>cheers</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D497211815-07012002>Dave</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> sumeshkp=20
  [mailto:sumeshkp@netbrahma.com]<BR><B>Sent:</B> Monday, January 07, =
2002 8:25=20
  AM<BR><B>To:</B> mpls@UU.NET<BR><B>Subject:</B> Some questions on=20
  HA<BR><BR></DIV></FONT>hi all,=20
  <P>i have some quick questions on high availability for MPLS. it will =
be great=20
  if any one can answer this for me=20
  <P>assumption:&nbsp;we are considering only data plane redundancy.=20
  <P>1. what is the format of FIS and FRS (not to be found in any =
contermporary=20
  drafts) <BR>2. can the "root" be outside the PML, IOW&nbsp;can root =
be outside=20
  the protection domain configured? <BR>3. should PSL always terminate =
the FIS=20
  or can it be extended over to the Ingress <BR>&nbsp;=20
  <P>thank you very much, <BR>warm regards, <BR>sumesh <PRE>--&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
\\\///&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; | Url&nbsp; : <A =
href=3D"http://www.netbrahma.com">http://www.netbrahma.com</A>&nbsp;&nbs=
p;&nbsp;&nbsp; |
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
netbrahma&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
Phone: +91-80-552-1452 X 263 (work) |
&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;&nbsp;&nbsp;&nbsp; +91-80-534-2165 =
(home)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
Internext Networking Software | Fax&nbsp; : =
+91-80-553-7533&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; |</PRE>&nbsp;=20
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19790.127DE590--


From owner-mpls@UU.NET  Mon Jan  7 11:46:45 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20044
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 11:46:45 -0500 (EST)
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 QQlwuk02851;
	Mon, 7 Jan 2002 16:43:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwuk10694
	for mpls-outgoing; Mon, 7 Jan 2002 16:43: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 QQlwuk10687
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 16: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 QQlwuk13121
	for <mpls@UU.NET>; Mon, 7 Jan 2002 16:43:18 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f97.pav2.hotmail.com [64.4.37.97])
	id QQlwuk01763
	for <mpls@UU.NET>; Mon, 7 Jan 2002 16:43:01 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 7 Jan 2002 08:43:17 -0800
Received: from 12.125.43.134 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Mon, 07 Jan 2002 16:43:16 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: mpls@UU.NET
Subject: Static MPLS configuration
Date: Mon, 07 Jan 2002 16:43:16 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F9787WLcd7YT6sE5YhS0001ae02@hotmail.com>
X-OriginalArrivalTime: 07 Jan 2002 16:43:17.0142 (UTC) FILETIME=[6829EB60:01C1979A]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,

Does anybody use MPLS interface as a layer 3 logical interface, or 
subinterface (part of a physical interface), like ATM PVC or Frame Relay 
DLCI, with its own entry in ifTable (mpls(166) ifType from IANAifType-MIB) 
and IP address associated with it? Of course, it makes sense for static MPLS 
configuration of bidirectional flows.

I think it can be useful for multiplexing of small traffic flows onto big 
capacity MPLS trunk. Another possible application is eliminating of 
complexity of forwarding adjacencies in routing protocols (LSP hierarchy 
draft), where simple static MPLS path can be used as actual, not virtual 
interface. In latter case MPLS interface can be even unnumbered, without IP 
address.

Thanks,
Igor


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From owner-mpls@UU.NET  Mon Jan  7 12:28:58 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21704
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 12:28:58 -0500 (EST)
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 QQlwun05644;
	Mon, 7 Jan 2002 17:25:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwun03942
	for mpls-outgoing; Mon, 7 Jan 2002 17:25: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 QQlwun03937
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 17:25: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 QQlwun08304
	for <mpls@uu.net>; Mon, 7 Jan 2002 17:24:48 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwun15010
	for <mpls@uu.net>; Mon, 7 Jan 2002 17:25: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 MAA12399 for <mpls@uu.net>; Mon, 7 Jan 2002 12:24:48 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10828 for mpls@uu.net; Mon, 7 Jan 2002 12:24:48 -0500 (EST)
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 QQlwuk10320
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 16:36:52 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 QQlwuk11298
	for <mpls@uu.net>; Mon, 7 Jan 2002 16:36:27 GMT
Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212])
	id QQlwuk24105
	for <mpls@uu.net>; Mon, 7 Jan 2002 16:36:08 GMT
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g07GaKA24704
	for mpls@uu.net; Mon, 7 Jan 2002 11:36:20 -0500 (EST)
Date: Mon, 7 Jan 2002 11:36:20 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200201071636.g07GaKA24704@newdev.harvard.edu>
To: mpls@UU.NET
Subject: draft minutes of sub-ip area meeting
Sender: owner-mpls@UU.NET
Precedence: bulk


  We have posted the draft minutes of the SUB-IP Area
  open meeting to subip-area@subip.ietf.org - please comment on the
  draft minutes (for example correct what they have you saying)
  by Jan 11 at 8pm EST

  To subscribe to the subip list send email to: majordomo@subip.ietf.org
  in message body: subscribe subip-area

  To find the posting about the minutes, pls point your
  web browser to: http://psg.com/lists/subip-area/subip-area.2002/   

  Thanks
        Scott & Bert



From owner-mpls@UU.NET  Mon Jan  7 12:37:21 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21997
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 12:37:20 -0500 (EST)
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 QQlwuo27205;
	Mon, 7 Jan 2002 17:34:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwuo04655
	for mpls-outgoing; Mon, 7 Jan 2002 17:34: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 QQlwuo04643
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 17:34:09 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 QQlwuo03702
	for <mpls@uu.net>; Mon, 7 Jan 2002 17:33:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwuo28085
	for <mpls@uu.net>; Mon, 7 Jan 2002 17:33: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 MAA13510 for <mpls@uu.net>; Mon, 7 Jan 2002 12:33:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11604 for mpls@uu.net; Mon, 7 Jan 2002 12:33:02 -0500 (EST)
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 QQlwuo04496
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 17:32: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 QQlwuo23175
	for <mpls@UU.NET>; Mon, 7 Jan 2002 17:31:41 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwuo26116
	for <mpls@UU.NET>; Mon, 7 Jan 2002 17:32:00 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA13323; Mon, 7 Jan 2002 12:31:40 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAJ84575;
	Mon, 7 Jan 2002 12:31:39 -0500 (EST)
Message-Id: <4.3.2.7.2.20020107122710.01ce2f90@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 07 Jan 2002 12:31:19 -0500
To: "Igor Achkinazi" <achkinazi@hotmail.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: Static MPLS configuration
Cc: mpls@UU.NET
In-Reply-To: <F9787WLcd7YT6sE5YhS0001ae02@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Does anybody use MPLS interface as a layer 3 logical interface, or 
>subinterface (part of a physical interface), like ATM PVC or Frame Relay 
>DLCI, with its own entry in ifTable (mpls(166) ifType from IANAifType-MIB) 
>and IP address associated with it?

         I know of lots of vendors that support this, as it is the standard 
model for MPLS
interface stacking.

>Of course, it makes sense for static MPLS configuration of bidirectional 
>flows.

         It makes sense from a configuration perspective because it allows
a manager to determine if MPLS is configured on that interface, as well as
allows them to configure MPLS on an existing interface. It also makes sense
from a statistical gathering perspective because stacking an MPLS interface on
top of another physical interface such as Ethernet allows a manager to 
count just
the MPLS traffic on that interface, as opposed to the (aggregate) enet traffic,
or anything else (IP).

         --Tom


>I think it can be useful for multiplexing of small traffic flows onto big 
>capacity MPLS trunk. Another possible application is eliminating of 
>complexity of forwarding adjacencies in routing protocols (LSP hierarchy 
>draft), where simple static MPLS path can be used as actual, not virtual 
>interface. In latter case MPLS interface can be even unnumbered, without 
>IP address.
>
>Thanks,
>Igor
>
>
>_________________________________________________________________
>Send and receive Hotmail on your mobile device: http://mobile.msn.com



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



From owner-mpls@UU.NET  Mon Jan  7 12:49:42 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22459
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 12:49:42 -0500 (EST)
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 QQlwup21286;
	Mon, 7 Jan 2002 17:46:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwup05728
	for mpls-outgoing; Mon, 7 Jan 2002 17:46: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 QQlwup05644
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 17:46: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 QQlwup28677
	for <mpls@UU.NET>; Mon, 7 Jan 2002 17:45:44 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f180.pav2.hotmail.com [64.4.37.180])
	id QQlwup15491
	for <mpls@UU.NET>; Mon, 7 Jan 2002 17:45:27 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 7 Jan 2002 09:45:43 -0800
Received: from 12.125.43.134 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Mon, 07 Jan 2002 17:45:43 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: Re: Static MPLS configuration
Date: Mon, 07 Jan 2002 17:45:43 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F180pPUNxX58eDlBcmf0001af45@hotmail.com>
X-OriginalArrivalTime: 07 Jan 2002 17:45:43.0604 (UTC) FILETIME=[213AA740:01C197A3]
Sender: owner-mpls@UU.NET
Precedence: bulk

Sorry for confusion, I meant statically configured MPLS label, LSP, to be a 
logical interface. May be mplsTunnel (150) ifType is better for this kind of 
interface. It is not MPLS capability configuration over an interface. It is 
new subinterface, like ATM PVC over ATM physical link. My suggestion was not 
just gathering statistics, but use of such interface in a system as a 
regular layer 3 link.

Thanks,
Igor


>From: "Thomas D. Nadeau" <tnadeau@cisco.com>
>To: "Igor Achkinazi" <achkinazi@hotmail.com>
>CC: mpls@UU.NET
>Subject: Re: Static MPLS configuration
>Date: Mon, 07 Jan 2002 12:31:19 -0500
>
>
>>Does anybody use MPLS interface as a layer 3 logical interface, or
>>subinterface (part of a physical interface), like ATM PVC or Frame Relay
>>DLCI, with its own entry in ifTable (mpls(166) ifType from IANAifType-MIB)
>>and IP address associated with it?
>
>         I know of lots of vendors that support this, as it is the standard
>model for MPLS
>interface stacking.
>
>>Of course, it makes sense for static MPLS configuration of bidirectional
>>flows.
>
>         It makes sense from a configuration perspective because it allows
>a manager to determine if MPLS is configured on that interface, as well as
>allows them to configure MPLS on an existing interface. It also makes sense
>from a statistical gathering perspective because stacking an MPLS interface 
>on
>top of another physical interface such as Ethernet allows a manager to
>count just
>the MPLS traffic on that interface, as opposed to the (aggregate) enet 
>traffic,
>or anything else (IP).
>
>         --Tom
>
>
>>I think it can be useful for multiplexing of small traffic flows onto big
>>capacity MPLS trunk. Another possible application is eliminating of
>>complexity of forwarding adjacencies in routing protocols (LSP hierarchy
>>draft), where simple static MPLS path can be used as actual, not virtual
>>interface. In latter case MPLS interface can be even unnumbered, without
>>IP address.
>>
>>Thanks,
>>Igor
>>
>>
>>_________________________________________________________________
>>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time.
>


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



From owner-mpls@UU.NET  Mon Jan  7 14:43:39 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25870
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 14:43:38 -0500 (EST)
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 QQlwuw01156;
	Mon, 7 Jan 2002 19:38:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwuw23902
	for mpls-outgoing; Mon, 7 Jan 2002 19:38: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 QQlwuw23886
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 19:37:57 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 QQlwuw25813
	for <mpls@UU.NET>; Mon, 7 Jan 2002 19:37:08 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 QQlwuw29131
	for <mpls@UU.NET>; Mon, 7 Jan 2002 19:37: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 OAA00078;
	Mon, 7 Jan 2002 14:37:05 -0500 (EST)
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 OAA15066;
	Mon, 7 Jan 2002 14:37:05 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <C24F4JTN>; Mon, 7 Jan 2002 14:37:04 -0500
Message-ID: <1DE644007776D3119FAC00204840ECF409134109@whq-msgusr-03.pit.comms.marconi.com>
From: "Dekany, Steven" <steven.dekany@marconi.com>
To: Igor Achkinazi <achkinazi@hotmail.com>, tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: RE: Static MPLS configuration
Date: Mon, 7 Jan 2002 14:37:01 -0500 
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

MPLS UNI solves this from a different direction. You may want to take a look
at that.

Best Regards,


Steven

-----Original Message-----
From: Igor Achkinazi [mailto:achkinazi@hotmail.com]
Sent: Monday, January 07, 2002 11:46 AM
To: tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: Re: Static MPLS configuration


Sorry for confusion, I meant statically configured MPLS label, LSP, to be a 
logical interface. May be mplsTunnel (150) ifType is better for this kind of

interface. It is not MPLS capability configuration over an interface. It is 
new subinterface, like ATM PVC over ATM physical link. My suggestion was not

just gathering statistics, but use of such interface in a system as a 
regular layer 3 link.

Thanks,
Igor


>From: "Thomas D. Nadeau" <tnadeau@cisco.com>
>To: "Igor Achkinazi" <achkinazi@hotmail.com>
>CC: mpls@UU.NET
>Subject: Re: Static MPLS configuration
>Date: Mon, 07 Jan 2002 12:31:19 -0500
>
>
>>Does anybody use MPLS interface as a layer 3 logical interface, or
>>subinterface (part of a physical interface), like ATM PVC or Frame Relay
>>DLCI, with its own entry in ifTable (mpls(166) ifType from IANAifType-MIB)
>>and IP address associated with it?
>
>         I know of lots of vendors that support this, as it is the standard
>model for MPLS
>interface stacking.
>
>>Of course, it makes sense for static MPLS configuration of bidirectional
>>flows.
>
>         It makes sense from a configuration perspective because it allows
>a manager to determine if MPLS is configured on that interface, as well as
>allows them to configure MPLS on an existing interface. It also makes sense
>from a statistical gathering perspective because stacking an MPLS interface

>on
>top of another physical interface such as Ethernet allows a manager to
>count just
>the MPLS traffic on that interface, as opposed to the (aggregate) enet 
>traffic,
>or anything else (IP).
>
>         --Tom
>
>
>>I think it can be useful for multiplexing of small traffic flows onto big
>>capacity MPLS trunk. Another possible application is eliminating of
>>complexity of forwarding adjacencies in routing protocols (LSP hierarchy
>>draft), where simple static MPLS path can be used as actual, not virtual
>>interface. In latter case MPLS interface can be even unnumbered, without
>>IP address.
>>
>>Thanks,
>>Igor
>>
>>
>>_________________________________________________________________
>>Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time.
>


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


From owner-mpls@UU.NET  Mon Jan  7 14:56:49 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26252
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 14:56:49 -0500 (EST)
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 QQlwux26352;
	Mon, 7 Jan 2002 19:54:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwux25015
	for mpls-outgoing; Mon, 7 Jan 2002 19:53: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 QQlwux25008
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 19:53: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 QQlwux14893
	for <mpls@UU.NET>; Mon, 7 Jan 2002 19:52:56 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f46.pav2.hotmail.com [64.4.37.46])
	id QQlwux10204
	for <mpls@UU.NET>; Mon, 7 Jan 2002 19:52:39 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 7 Jan 2002 11:52:55 -0800
Received: from 12.125.43.134 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Mon, 07 Jan 2002 19:52:55 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: steven.dekany@marconi.com, tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: RE: Static MPLS configuration
Date: Mon, 07 Jan 2002 19:52:55 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F46e3ZGtmzPbJqCCViS0001b2e3@hotmail.com>
X-OriginalArrivalTime: 07 Jan 2002 19:52:55.0697 (UTC) FILETIME=[E64FA010:01C197B4]
Sender: owner-mpls@UU.NET
Precedence: bulk

Thanks, Steven

However MPLS UNI implies MPLS signaling that adds complexity. In LSP 
hierarchy case it does not help at all. I intentionally asked about static 
configuration, because it is simple and easy to control. And it is much, 
much easier to implement.
Sorry, I do not want to use UNI :)

Best regards,
Igor

>From: "Dekany, Steven" <steven.dekany@marconi.com>
>To: Igor Achkinazi <achkinazi@hotmail.com>, tnadeau@cisco.com
>CC: mpls@UU.NET
>Subject: RE: Static MPLS configuration
>Date: Mon, 7 Jan 2002 14:37:01 -0500
>
>MPLS UNI solves this from a different direction. You may want to take a 
>look
>at that.
>
>Best Regards,
>
>
>Steven
>
>-----Original Message-----
>From: Igor Achkinazi [mailto:achkinazi@hotmail.com]
>Sent: Monday, January 07, 2002 11:46 AM
>To: tnadeau@cisco.com
>Cc: mpls@UU.NET
>Subject: Re: Static MPLS configuration
>
>
>Sorry for confusion, I meant statically configured MPLS label, LSP, to be a
>logical interface. May be mplsTunnel (150) ifType is better for this kind 
>of
>
>interface. It is not MPLS capability configuration over an interface. It is
>new subinterface, like ATM PVC over ATM physical link. My suggestion was 
>not
>
>just gathering statistics, but use of such interface in a system as a
>regular layer 3 link.
>
>Thanks,
>Igor
>
>
> >From: "Thomas D. Nadeau" <tnadeau@cisco.com>
> >To: "Igor Achkinazi" <achkinazi@hotmail.com>
> >CC: mpls@UU.NET
> >Subject: Re: Static MPLS configuration
> >Date: Mon, 07 Jan 2002 12:31:19 -0500
> >
> >
> >>Does anybody use MPLS interface as a layer 3 logical interface, or
> >>subinterface (part of a physical interface), like ATM PVC or Frame Relay
> >>DLCI, with its own entry in ifTable (mpls(166) ifType from 
>IANAifType-MIB)
> >>and IP address associated with it?
> >
> >         I know of lots of vendors that support this, as it is the 
>standard
> >model for MPLS
> >interface stacking.
> >
> >>Of course, it makes sense for static MPLS configuration of bidirectional
> >>flows.
> >
> >         It makes sense from a configuration perspective because it 
>allows
> >a manager to determine if MPLS is configured on that interface, as well 
>as
> >allows them to configure MPLS on an existing interface. It also makes 
>sense
> >from a statistical gathering perspective because stacking an MPLS 
>interface
>
> >on
> >top of another physical interface such as Ethernet allows a manager to
> >count just
> >the MPLS traffic on that interface, as opposed to the (aggregate) enet
> >traffic,
> >or anything else (IP).
> >
> >         --Tom
> >
> >
> >>I think it can be useful for multiplexing of small traffic flows onto 
>big
> >>capacity MPLS trunk. Another possible application is eliminating of
> >>complexity of forwarding adjacencies in routing protocols (LSP hierarchy
> >>draft), where simple static MPLS path can be used as actual, not virtual
> >>interface. In latter case MPLS interface can be even unnumbered, without
> >>IP address.
> >>
> >>Thanks,
> >>Igor
> >>
> >>
> >>_________________________________________________________________
> >>Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
> >
> >------------------------------------------------------------------------
> >Mathematics is the supreme nostalgia of our time.
> >
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From owner-mpls@UU.NET  Mon Jan  7 15:53:09 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27731
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 15:53:08 -0500 (EST)
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 QQlwvb04116;
	Mon, 7 Jan 2002 20:46:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwvb18956
	for mpls-outgoing; Mon, 7 Jan 2002 20:45: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 QQlwvb18949
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 20:45: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 QQlwvb05014
	for <mpls@UU.NET>; Mon, 7 Jan 2002 20:45:13 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlwva15696
	for <mpls@UU.NET>; Mon, 7 Jan 2002 20:44:54 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 PAA07306;
	Mon, 7 Jan 2002 15:45:10 -0500 (EST)
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 PAA00006;
	Mon, 7 Jan 2002 15:45:06 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <C24F4N4D>; Mon, 7 Jan 2002 15:45:05 -0500
Message-ID: <1DE644007776D3119FAC00204840ECF409134123@whq-msgusr-03.pit.comms.marconi.com>
From: "Dekany, Steven" <steven.dekany@marconi.com>
To: Igor Achkinazi <achkinazi@hotmail.com>,
        "Dekany, Steven"
	 <steven.dekany@marconi.com>, tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: RE: Static MPLS configuration
Date: Mon, 7 Jan 2002 15:44:58 -0500 
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

Igor,

I understand that you may not want to use UNI, it may be an overkill. 

BTW MPLS UNI "only" needs a subset of LDP signaling between CE and PE. In
theory there is no reason why hierarchical TE LSPs could not be configured,
since all is under the (potentially manual) control of the SP. So you can
set up a single default FEC with a single label on the interface, if that is
what is required, and then the LSP will "automatically" come up once the
link is up. Agree, that it is a unique application.

Best Regards,

Steven 

-----Original Message-----
From: Igor Achkinazi [mailto:achkinazi@hotmail.com]
Sent: Monday, January 07, 2002 1:53 PM
To: steven.dekany@marconi.com; tnadeau@cisco.com
Cc: mpls@UU.NET
Subject: RE: Static MPLS configuration


Thanks, Steven

However MPLS UNI implies MPLS signaling that adds complexity. In LSP 
hierarchy case it does not help at all. I intentionally asked about static 
configuration, because it is simple and easy to control. And it is much, 
much easier to implement.
Sorry, I do not want to use UNI :)

Best regards,
Igor

>From: "Dekany, Steven" <steven.dekany@marconi.com>
>To: Igor Achkinazi <achkinazi@hotmail.com>, tnadeau@cisco.com
>CC: mpls@UU.NET
>Subject: RE: Static MPLS configuration
>Date: Mon, 7 Jan 2002 14:37:01 -0500
>
>MPLS UNI solves this from a different direction. You may want to take a 
>look
>at that.
>
>Best Regards,
>
>
>Steven
>
>-----Original Message-----
>From: Igor Achkinazi [mailto:achkinazi@hotmail.com]
>Sent: Monday, January 07, 2002 11:46 AM
>To: tnadeau@cisco.com
>Cc: mpls@UU.NET
>Subject: Re: Static MPLS configuration
>
>
>Sorry for confusion, I meant statically configured MPLS label, LSP, to be a
>logical interface. May be mplsTunnel (150) ifType is better for this kind 
>of
>
>interface. It is not MPLS capability configuration over an interface. It is
>new subinterface, like ATM PVC over ATM physical link. My suggestion was 
>not
>
>just gathering statistics, but use of such interface in a system as a
>regular layer 3 link.
>
>Thanks,
>Igor
>
>
> >From: "Thomas D. Nadeau" <tnadeau@cisco.com>
> >To: "Igor Achkinazi" <achkinazi@hotmail.com>
> >CC: mpls@UU.NET
> >Subject: Re: Static MPLS configuration
> >Date: Mon, 07 Jan 2002 12:31:19 -0500
> >
> >
> >>Does anybody use MPLS interface as a layer 3 logical interface, or
> >>subinterface (part of a physical interface), like ATM PVC or Frame Relay
> >>DLCI, with its own entry in ifTable (mpls(166) ifType from 
>IANAifType-MIB)
> >>and IP address associated with it?
> >
> >         I know of lots of vendors that support this, as it is the 
>standard
> >model for MPLS
> >interface stacking.
> >
> >>Of course, it makes sense for static MPLS configuration of bidirectional
> >>flows.
> >
> >         It makes sense from a configuration perspective because it 
>allows
> >a manager to determine if MPLS is configured on that interface, as well 
>as
> >allows them to configure MPLS on an existing interface. It also makes 
>sense
> >from a statistical gathering perspective because stacking an MPLS 
>interface
>
> >on
> >top of another physical interface such as Ethernet allows a manager to
> >count just
> >the MPLS traffic on that interface, as opposed to the (aggregate) enet
> >traffic,
> >or anything else (IP).
> >
> >         --Tom
> >
> >
> >>I think it can be useful for multiplexing of small traffic flows onto 
>big
> >>capacity MPLS trunk. Another possible application is eliminating of
> >>complexity of forwarding adjacencies in routing protocols (LSP hierarchy
> >>draft), where simple static MPLS path can be used as actual, not virtual
> >>interface. In latter case MPLS interface can be even unnumbered, without
> >>IP address.
> >>
> >>Thanks,
> >>Igor
> >>
> >>
> >>_________________________________________________________________
> >>Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
> >
> >------------------------------------------------------------------------
> >Mathematics is the supreme nostalgia of our time.
> >
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


From owner-mpls@UU.NET  Mon Jan  7 18:23:41 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00788
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 18:23:41 -0500 (EST)
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 QQlwvl01378;
	Mon, 7 Jan 2002 23:19:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwvl05137
	for mpls-outgoing; Mon, 7 Jan 2002 23:19: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 QQlwvl05132
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 23:19: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 QQlwvl02244
	for <mpls@UU.NET>; Mon, 7 Jan 2002 23:17:37 GMT
Received: from web20804.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20804.mail.yahoo.com [216.136.226.193])
	id QQlwvl27338
	for <mpls@UU.NET>; Mon, 7 Jan 2002 23:17:20 GMT
Message-ID: <20020107231736.35078.qmail@web20804.mail.yahoo.com>
Received: from [134.193.6.56] by web20804.mail.yahoo.com via HTTP; Mon, 07 Jan 2002 15:17:36 PST
Date: Mon, 7 Jan 2002 15:17:36 -0800 (PST)
From: senthil ayyasamy <mplsgeek@yahoo.com>
Subject: RE: L2 VPN services
To: David Kuder <david.kuder@gobeam.com>,
        "'Irwin Lazar'" <ILazar@burtongroup.com>, mpls-ops@mplsrc.com
Cc: mpls@UU.NET
In-Reply-To: <002201c197c5$e9908a80$4200c80a@gobeam.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-933385541-1010445456=:33883"
Sender: owner-mpls@UU.NET
Precedence: bulk

--0-933385541-1010445456=:33883
Content-Type: text/plain; charset=us-ascii


 leave alone alll other tunneling methods, what is the exact prons and cons of IPsec and MPLS VPNs ...I feel like IPsec VPN have an edge over MPLS in that it provides more security and also no change to the core network.Also,i dont have to depend too much on the ISP for support....enlighten me more in this aspect
-senthil
  David Kuder <david.kuder@gobeam.com> wrote: Irwin Lazar [ILazar@burtongroup.com] on January 07, 2002 6:46 AM wrote:
> Here's a similar question to the ATM-MPLS debate, but on a
> slightly different track - right now there seems to be a lot
> of interest in using MPLS to provide L2 "VPN" services (e.g.
> frame relay, Ethernet, TDM, ATM) over an IP network. Yet,
> others suggest that using L2TP rather than MPLS is a better
> approach in that it is more scalable and easier to manage.

> My question is what are you folks seeing in the service provider
> space - are SPs moving toward MPLS or are they looking at L2TP.
> Is this an either/or decision or will both technologies have a
> role? Which technology will become the preferred choice for
> providing L2 services of an IP network? Are there any other
> alternatives?

Cisco has a hierarchy of VPNs that I hacked:
Overlay VPN
Layer 2
Frame Relay
ATM
Layer 3
Tunneling
IPSec
GRE
L2TP
P2TP
firewall appliance
Peer to Peer VPN
MPLS
Dedicated Router
real
virtual
Virtual LAN
Bridging Ethernet over 
TDM
DSL
metro fiber

You can probably find a vendor or service provide living in
every one of those categories.

For me, ease of management is not a winner for any tunneling
protocol. I'm not sure about scalability. Obvious losers are
increased bandwidth, increased latency, CPE support, and QOS.

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

SENTHIL KUMAR
MS(COMPUTER NETWORKING)
UMKC,
MO-64112,USA


---------------------------------
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail.
--0-933385541-1010445456=:33883
Content-Type: text/html; charset=us-ascii

<P> leave alone alll other tunneling methods, what is the exact prons and cons of IPsec and MPLS VPNs ...I feel like&nbsp;IPsec VPN have an edge over MPLS in that it provides more security and also no change to the core network.Also,i dont have to depend too much on the ISP for support....enlighten me more in this aspect
<P>-senthil
<P>&nbsp; <B><I>David Kuder &lt;david.kuder@gobeam.com&gt;</I></B> wrote: 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Irwin Lazar [ILazar@burtongroup.com] on January 07, 2002 6:46 AM wrote:<BR>&gt; Here's a similar question to the ATM-MPLS debate, but on a<BR>&gt; slightly different track - right now there seems to be a lot<BR>&gt; of interest in using MPLS to provide L2 "VPN" services (e.g.<BR>&gt; frame relay, Ethernet, TDM, ATM) over an IP network. Yet,<BR>&gt; others suggest that using L2TP rather than MPLS is a better<BR>&gt; approach in that it is more scalable and easier to manage.<BR><BR>&gt; My question is what are you folks seeing in the service provider<BR>&gt; space - are SPs moving toward MPLS or are they looking at L2TP.<BR>&gt; Is this an either/or decision or will both technologies have a<BR>&gt; role? Which technology will become the preferred choice for<BR>&gt; providing L2 services of an IP network? Are there any other<BR>&gt; alternatives?<BR><BR>Cisco has a hierarchy of VPNs that I hac!
!
!
!
ked:<BR>Overlay VPN<BR>Layer 2<BR>Frame Relay<BR>ATM<BR>Layer 3<BR>Tunneling<BR>IPSec<BR>GRE<BR>L2TP<BR>P2TP<BR>firewall appliance<BR>Peer to Peer VPN<BR>MPLS<BR>Dedicated Router<BR>real<BR>virtual<BR>Virtual LAN<BR>Bridging Ethernet over <BR>TDM<BR>DSL<BR>metro fiber<BR><BR>You can probably find a vendor or service provide living in<BR>every one of those categories.<BR><BR>For me, ease of management is not a winner for any tunneling<BR>protocol. I'm not sure about scalability. Obvious losers are<BR>increased bandwidth, increased latency, CPE support, and QOS.<BR><BR>-------<BR>The MPLS-OPS Mailing List<BR>Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml<BR>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml</BLOCKQUOTE><BR><BR>SENTHIL KUMAR<br>MS(COMPUTER NETWORKING)<br>UMKC,<br>MO-64112,USA<p><br><hr size=1><b>Do You Yahoo!?</b><br>
Send FREE <a href="http://rd.yahoo.com/mail_us/tag/?http://promo.yahoo.com/videomail/">video</a> emails in <a href="http://rd.yahoo.com/mail_us/tag/?http://mail.yahoo.com/">Yahoo! Mail</a>.
--0-933385541-1010445456=:33883--


From owner-mpls@UU.NET  Mon Jan  7 18:51:03 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01311
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 18:51:03 -0500 (EST)
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 QQlwvn07231;
	Mon, 7 Jan 2002 23:48:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwvn07173
	for mpls-outgoing; Mon, 7 Jan 2002 23:48: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 QQlwvn07168
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 23:48: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 QQlwvn10054
	for <mpls@UU.NET>; Mon, 7 Jan 2002 23:46:54 GMT
Received: from cmail.packetcom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.108.173.139])
	id QQlwvn06030
	for <mpls@UU.NET>; Mon, 7 Jan 2002 23:47:14 GMT
Received: from caspiannetworks.com ([192.168.5.198])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABP92148 (AUTH tso@caspiannetworks.com);
	Mon, 7 Jan 2002 15:46:53 -0800 (PST)
Message-ID: <3C3A2DB9.130CD7AF@caspiannetworks.com>
Date: Mon, 07 Jan 2002 15:22:33 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dhg@juniper.net
CC: pingpan@juniper.net, mpls@UU.NET
Subject: Questions for FRR 
References: <F46e3ZGtmzPbJqCCViS0001b2e3@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 Der-Hwa and Ping,

After reviewing your draft in more details, I have the following questions
regarding the detour mechanism for FRR.  Hope you can help me to clarify a few
things.  Thanks....

1. According to the latest draft, section 3.2.1, your recommend the use of the
RSVP_HOP object to be included in the detour Path message.  Since the
SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
tunnel sender address", is also being used in the Path message, why the RSVP_HOP
object is needed to carry the same information (i.e. PLR's IP addrss)?

2. In section 3.2.2., you have a statement mentioned that the MP may receieve
the Path message from different interfaces with the identical SESSION and
SENDER_TEMPLATE objects.  I don't see this would be possible except for the case
of the software error.  It is because the SENDER_TEMPLATE should be coded with
different LSP_IDs for the Protected and Detour LSPs for the same tunnel over
different interfaces.  This the design intent of using different LSP_IDs to
differentiate different instances of the LSPs for the same tunnel.  Am I
misunderstood your statement?

3. Somebody sent a previous email to suggest that the detour Path message should
include the option to specify the requested LSP's bandwidth and administrative
group constraint that is same as the Protected LSP, instead of locally
configuring these two options at each FRR capable LSR to adopt the Protected LSP
requirements or not.  I happen to agree with his view.  What do think about his
suggestion?

Thanks in advance to your help......
Tricci






From owner-mpls@UU.NET  Mon Jan  7 22:12:23 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04651
	for <mpls-archive@lists.ietf.org>; Mon, 7 Jan 2002 22:12:23 -0500 (EST)
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 QQlwwa13629;
	Tue, 8 Jan 2002 03:11:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwwa09673
	for mpls-outgoing; Tue, 8 Jan 2002 03:10: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 QQlwwa09644
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 03:10: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 QQlwwa02559
	for <mpls@UU.NET>; Tue, 8 Jan 2002 03:10:10 GMT
Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: yarilo.pluris.com [208.227.9.200])
	id QQlwwa12750
	for <mpls@UU.NET>; Tue, 8 Jan 2002 03:10:28 GMT
Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA19915;
	Mon, 7 Jan 2002 19:10:07 -0800 (PST)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <YNMDFDF6>; Mon, 7 Jan 2002 19:10:07 -0800
Message-ID: <17C81AD1F1FED411991E006008F6D1CA013D472E@avalon.pluris.com>
From: Sundara Murugan <sundar@pluris.com>
To: "'Tricci So'" <tso@caspiannetworks.com>, dhg@juniper.net
Cc: pingpan@juniper.net, mpls@UU.NET
Subject: RE: Questions for FRR 
Date: Mon, 7 Jan 2002 19:10:06 -0800 
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

my comments are embedded.

-----Original Message-----
From: Tricci So [mailto:tso@caspiannetworks.com]
Sent: Monday, January 07, 2002 3:23 PM
To: dhg@juniper.net
Cc: pingpan@juniper.net; mpls@UU.NET
Subject: Questions for FRR 


Hi Der-Hwa and Ping,

After reviewing your draft in more details, I have the following questions
regarding the detour mechanism for FRR.  Hope you can help me to clarify a
few
things.  Thanks....

1. According to the latest draft, section 3.2.1, your recommend the use of
the
RSVP_HOP object to be included in the detour Path message.  Since the
SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
tunnel sender address", is also being used in the Path message, why the
RSVP_HOP
object is needed to carry the same information (i.e. PLR's IP addrss)?

>> Detour and the protected LSPs will have the same session and sender id.
Also the next-hop will send resv msg to the IP addr specified in the
RSVP_HOP oject. 

2. In section 3.2.2., you have a statement mentioned that the MP may
receieve
the Path message from different interfaces with the identical SESSION and
SENDER_TEMPLATE objects.  I don't see this would be possible except for the
case
of the software error.  It is because the SENDER_TEMPLATE should be coded
with
different LSP_IDs for the Protected and Detour LSPs for the same tunnel over
different interfaces.  This the design intent of using different LSP_IDs to
differentiate different instances of the LSPs for the same tunnel.  Am I
misunderstood your statement?

>> If the LSP_IDs of the protected and the detour lsp is different then they
can't be merged.

3. Somebody sent a previous email to suggest that the detour Path message
should
include the option to specify the requested LSP's bandwidth and
administrative
group constraint that is same as the Protected LSP, instead of locally
configuring these two options at each FRR capable LSR to adopt the Protected
LSP
requirements or not.  I happen to agree with his view.  What do think about
his
suggestion?

>>Since the detour lsp will be used only during reroute, the user may not
want to waste the band-width. So, the user will decide the bw allocated for
the detour lsp.

Thanks in advance to your help......
Tricci





From owner-mpls@UU.NET  Tue Jan  8 07:09:08 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19530
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 07:09:08 -0500 (EST)
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 QQlwxk05820;
	Tue, 8 Jan 2002 12:08:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxk16307
	for mpls-outgoing; Tue, 8 Jan 2002 12:07:35 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 QQlwxk16284
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 12:07: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 QQlwxk09131
	for <mpls@UU.NET>; Tue, 8 Jan 2002 12:06:40 GMT
Received: from smtp4.cluster.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62])
	id QQlwxk03821
	for <mpls@UU.NET>; Tue, 8 Jan 2002 12:07:00 GMT
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id g08C6dP17267 for <mpls@UU.NET>; Tue, 8 Jan 2002 13:06:39 +0100 (CET)
Message-ID: <02db01c1983c$a78d4e80$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <mpls@UU.NET>
Subject: MPLS World Congress 2002 
Date: Tue, 8 Jan 2002 13:03:28 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_02D6_01C19844.DD4A0BA0"
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_02D6_01C19844.DD4A0BA0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

AT&T, Equant, France Telecom, Infonet, Terabeam, Storm Telecom, =
Lambdanet, Utfors=85 Why have these operators chosen to implement MPLS? =
What type of VPN do they operate? Carriers, ISPs and carrier operators =
will be present en masse at MPLS World 2002 to address these issues.=20
In parallel, the successfull exhibition will showcase MPLS equipments =
and applications.
More details at:
http://www.upperside.fr/congress02/mplsworld2002.htm



------=_NextPart_000_02D6_01C19844.DD4A0BA0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
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>
<DIV><FONT size=3D2>AT&amp;T, Equant, France Telecom, Infonet, Terabeam, =
Storm=20
Telecom, Lambdanet, Utfors=85 Why have these operators chosen to =
implement MPLS?=20
What type of VPN do they operate? Carriers, ISPs and carrier operators =
will be=20
present en masse at MPLS World 2002 to address these issues. =
</FONT></DIV>
<DIV><FONT size=3D2>In parallel, the successfull exhibition will =
showcase MPLS=20
equipments and applications.</FONT></DIV>
<DIV><FONT size=3D2>More details at:</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/congress02/mplsworld2002.htm">http://www.=
upperside.fr/congress02/mplsworld2002.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_02D6_01C19844.DD4A0BA0--



From owner-mpls@UU.NET  Tue Jan  8 08:05:02 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20026
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 08:05:02 -0500 (EST)
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 QQlwxo15802;
	Tue, 8 Jan 2002 13:04:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxo01440
	for mpls-outgoing; Tue, 8 Jan 2002 13:04: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 QQlwxo01431
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 13:04:06 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 QQlwxo03465
	for <mpls@uu.net>; Tue, 8 Jan 2002 13:03:14 GMT
From: Rghines1@aol.com
Received: from imo-r09.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imo-r09.mx.aol.com [152.163.225.105])
	id QQlwxo03938
	for <mpls@uu.net>; Tue, 8 Jan 2002 13:02:56 GMT
Received: from Rghines1@aol.com
	by imo-r09.mx.aol.com (mail_out_v31_r1.9.) id n.d0.205c95b2 (16335);
	Tue, 8 Jan 2002 08:03:05 -0500 (EST)
Message-ID: <d0.205c95b2.296c4809@aol.com>
Date: Tue, 8 Jan 2002 08:03:05 EST
Subject: Re: MPLS World Congress 2002 
To: peter.lewis@upperside.fr, mpls@UU.NET
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_d0.205c95b2.296c4809_boundary"
X-Mailer: AOL 7.0 for Windows US sub 118
Sender: owner-mpls@UU.NET
Precedence: bulk


--part1_d0.205c95b2.296c4809_boundary
Content-Type: text/plain; charset="UTF-8"
Content-Language: en
Content-Transfer-Encoding: quoted-printable

Peter,

First these list are not for advertisements. =20

Second MPLS is a fine technology, but for en-masse rollout it won't do the=20
trick by itself.

R. Hines, Consulting


In a message dated 1/8/02 4:10:04 AM Pacific Standard Time,=20
peter.lewis@upperside.fr writes:


>=20
> AT&T, Equant, France Telecom, Infonet, Terabeam, Storm Telecom, Lambdanet,=
=20
> Utfors=E2=80=A6 Why have these operators chosen to implement MPLS? What ty=
pe of VPN=20
> do they operate? Carriers, ISPs and carrier operators will be present en=20
> masse at MPLS World 2002 to address these issues.=20
> In parallel, the successfull exhibition will showcase MPLS equipments and=20
> applications.
> More details at
>=20
>=20


--part1_d0.205c95b2.296c4809_boundary
Content-Type: text/html; charset="UTF-8"
Content-Language: en
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2>Peter,<BR>
<BR>
First these list are not for advertisements.&nbsp; <BR>
<BR>
Second MPLS is a fine technology, but for en-masse rollout it won't do the t=
rick by itself.<BR>
<BR>
R. Hines, Consulting<BR>
<BR>
<BR>
In a message dated 1/8/02 4:10:04 AM Pacific Standard Time, peter.lewis@uppe=
rside.fr writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"><BR>
AT&amp;T, Equant, France Telecom, Infonet, Terabeam, Storm Telecom, Lambdane=
t, Utfors=E2=80=A6 Why have these operators chosen to implement MPLS? What t=
ype of VPN do they operate? Carriers, ISPs and carrier operators will be pre=
sent en masse at MPLS World 2002 to address these issues. </FONT><FONT  COLO=
R=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSER=
IF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT  COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">In parallel, the successfull=
 exhibition will showcase MPLS equipments and applications.</FONT><FONT  COL=
OR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSE=
RIF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT  COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">More details at</FONT><FONT=20=
 COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SA=
NSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
<BR>
</BLOCKQUOTE><BR>
</FONT><FONT  COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT></HTML>
--part1_d0.205c95b2.296c4809_boundary--


From owner-mpls@UU.NET  Tue Jan  8 09:03:40 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21866
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 09:03:39 -0500 (EST)
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 QQlwxs12033;
	Tue, 8 Jan 2002 14:02:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxs26152
	for mpls-outgoing; Tue, 8 Jan 2002 14:02:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlwxs26135
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:02: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 QQlwxs20863
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:02:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxs19214
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:02: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 JAA05442 for <mpls@uu.net>; Tue, 8 Jan 2002 09:02:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04924 for mpls@uu.net; Tue, 8 Jan 2002 09:02:01 -0500 (EST)
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 QQlwxs21246
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:01:36 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 QQlwxs17744
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:21 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 QQlwxs18214
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:41 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21569;
	Tue, 8 Jan 2002 09:01:19 -0500 (EST)
Message-Id: <200201081401.JAA21569@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-01.txt
Date: Tue, 08 Jan 2002 09:01:18 -0500
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Multiprotocol Label Switching (MPLS) Management 
                          Overview
	Author(s)	: T. Nadeau, C. Srinivasan, A. Farrel
	Filename	: draft-ietf-mpls-mgmt-overview-01.txt
	Pages		: 13
	Date		: 07-Jan-02
	
This memo describes the Multiprotocol Label Switching
(MPLS) management architecture and the inter-relationships
between the different management information bases (MIBs)
used for MPLS network management.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jan  8 09:03:46 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21877
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 09:03:46 -0500 (EST)
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 QQlwxs12305;
	Tue, 8 Jan 2002 14:03:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxs26226
	for mpls-outgoing; Tue, 8 Jan 2002 14:02: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 QQlwxs26136
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:02: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 QQlwxs20866
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:02:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxs19215
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:02: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 JAA05441 for <mpls@uu.net>; Tue, 8 Jan 2002 09:02:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04925 for mpls@uu.net; Tue, 8 Jan 2002 09:02:01 -0500 (EST)
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 QQlwxs19847
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:01:19 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlwxs17367
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:16 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 QQlwxs18092
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:36 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21549;
	Tue, 8 Jan 2002 09:01:14 -0500 (EST)
Message-Id: <200201081401.JAA21549@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-04.txt
Date: Tue, 08 Jan 2002 09:01:13 -0500
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-04.txt
	Pages		: 24
	Date		: 07-Jan-02
	
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 defining Forwarding
Equivalent Class (FEC) to Next Hop Label Forwarding Entry (NHLFE)
mappings 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-04.txt

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-ftn-mib-04.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jan  8 09:04:43 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21991
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 09:04:42 -0500 (EST)
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 QQlwxs22231;
	Tue, 8 Jan 2002 14:04:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxs26473
	for mpls-outgoing; Tue, 8 Jan 2002 14:03: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 QQlwxs26454
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:03:21 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 QQlwxs06374
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxs20631
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03: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 JAA05496 for <mpls@uu.net>; Tue, 8 Jan 2002 09:03:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04990 for mpls@uu.net; Tue, 8 Jan 2002 09:03:02 -0500 (EST)
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 QQlwxs25928
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:02:22 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 QQlwxs23190
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:11 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 QQlwxs17970
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:31 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21533;
	Tue, 8 Jan 2002 09:01:09 -0500 (EST)
Message-Id: <200201081401.JAA21533@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-lsr-mib-08.txt
Date: Tue, 08 Jan 2002 09:01:09 -0500
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) Label Switch 
                          Router  (LSR) Management Information Base 	
        Author(s)	: C. Srinivasan, A. Viswanathan, T. Nadeau
	Filename	: draft-ietf-mpls-lsr-mib-08.txt
	Pages		: 52
	Date		: 07-Jan-02
	
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
modeling a Multiprotocol Label Switching (MPLS) Label Switch
Router (LSR).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-08.txt

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-lsr-mib-08.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jan  8 09:05:20 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22022
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 09:05:20 -0500 (EST)
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 QQlwxs28810;
	Tue, 8 Jan 2002 14:03:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxs26469
	for mpls-outgoing; Tue, 8 Jan 2002 14:03: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 QQlwxs26451
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:03:20 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 QQlwxs06359
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxs20615
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03: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 JAA05492 for <mpls@uu.net>; Tue, 8 Jan 2002 09:03:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04982 for mpls@uu.net; Tue, 8 Jan 2002 09:03:01 -0500 (EST)
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 QQlwxs25920
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:02:22 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 QQlwxs22963
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:07 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 QQlwxs17864
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01: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 JAA21515;
	Tue, 8 Jan 2002 09:01:04 -0500 (EST)
Message-Id: <200201081401.JAA21515@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-03.txt
Date: Tue, 08 Jan 2002 09:01:04 -0500
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-03.txt
	Pages		: 13
	Date		: 07-Jan-02
	
This memo describes Textual Conventions and OBJECT-
IDENTITIES common to the Management Information Bases
(MIBs) for managing Multiprotocol Label Switching (MPLS)
networks.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-tc-mib-03.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jan  8 09:05:45 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22064
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 09:05:45 -0500 (EST)
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 QQlwxs28992;
	Tue, 8 Jan 2002 14:03:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxs26470
	for mpls-outgoing; Tue, 8 Jan 2002 14:03: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 QQlwxs26453
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:03:20 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 QQlwxs06350
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxs20601
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:03: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 JAA05488 for <mpls@uu.net>; Tue, 8 Jan 2002 09:03:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04968 for mpls@uu.net; Tue, 8 Jan 2002 09:03:01 -0500 (EST)
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 QQlwxs21751
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 14:01:45 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 QQlwxs01261
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:26 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 QQlwxs18340
	for <mpls@uu.net>; Tue, 8 Jan 2002 14:01:46 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21613;
	Tue, 8 Jan 2002 09:01:24 -0500 (EST)
Message-Id: <200201081401.JAA21613@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-08.txt
Date: Tue, 08 Jan 2002 09:01:23 -0500
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-08.txt
	Pages		: 64
	Date		: 07-Jan-02
	
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 Multiprotocol Label Switching (MPLS)
based traffic engineering.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-te-mib-08.txt

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Jan  8 10:07:42 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24700
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 10:07:35 -0500 (EST)
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 QQlwxw26491;
	Tue, 8 Jan 2002 15:03:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwxw15255
	for mpls-outgoing; Tue, 8 Jan 2002 15: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 QQlwxw15178
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 15:03: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 QQlwxw29440
	for <mpls@uu.net>; Tue, 8 Jan 2002 15:02:50 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwxw12758
	for <mpls@uu.net>; Tue, 8 Jan 2002 15:02: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 KAA10963 for <mpls@uu.net>; Tue, 8 Jan 2002 10:02:49 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09647 for mpls@uu.net; Tue, 8 Jan 2002 10:02:49 -0500 (EST)
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 QQlwvm06430
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 7 Jan 2002 23:37: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 QQlwvm15194
	for <mpls@uu.net>; Mon, 7 Jan 2002 23:36:25 GMT
Received: from srcamx01.sanramon.gobeam.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host251.gobeam.com [207.33.39.251] (may be forged))
	id QQlwvm25978
	for <mpls@uu.net>; Mon, 7 Jan 2002 23:36:08 GMT
Received: from srmail.sanramon.gobeam.com ([10.200.0.76]) by srcamx01.sanramon.gobeam.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 7 Jan 2002 15:36:18 -0800
Received: from dlap ([10.200.0.66]) by srmail.sanramon.gobeam.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 7 Jan 2002 15:36:18 -0800
From: "David Kuder" <david.kuder@gobeam.com>
To: "'senthil ayyasamy'" <mplsgeek@yahoo.com>,
        "'Irwin Lazar'" <ILazar@burtongroup.com>, <mpls-ops@mplsrc.com>
Cc: <mpls@UU.NET>
Subject: RE: L2 VPN services
Date: Mon, 7 Jan 2002 15:36:17 -0800
Message-ID: <002b01c197d4$1a7ac940$4200c80a@gobeam.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, Build 10.0.2616
x-mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
In-Reply-To: <20020107231736.35078.qmail@web20804.mail.yahoo.com>
X-OriginalArrivalTime: 07 Jan 2002 23:36:18.0793 (UTC) FILETIME=[1B2DC590:01C197D4]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


senthil ayyasamy [mplsgeek@yahoo.com] on January 07, 2002 3:18 PM wrote:
> leave alone alll other tunneling methods, what is the exact
> prons and cons of IPsec and MPLS VPNs ...I feel like IPsec
> VPN have an edge over MPLS in that it provides more security
> and also no change to the core network.Also,i dont have to
> depend too much on the ISP for support....enlighten me more
> in this aspect 

I am the service provider so already that's different.

IPSec is not as well supported by our default vendor or so
the sales engineer claims.  You may get a different answer
from the same vendor.

IPSec requires many more TLAs (PKI, IKE, MD5, HMAC, ESP).  That's
not entirely a joke.  In terms of configuration and maintenance
there is a big chunk of infrastructure to deal with. 

IPSec does encrypt the payload.  That can be so important as to
make the rest of it part of the cost doing things.

For our application (VOIP), IPSec introduces too much overhead
in bandwidth and latency.

I'm not sure if MPLS is a big winner.  That's why I joined the
list, to learn.  Speaking of which, I see that Senthil cc-ed
mpls@uu.net.  What is the difference between it and mpls-ops?

Every one of the VPN options I've seen is applicable for someone
under some set of assumptions.  



From owner-mpls@UU.NET  Tue Jan  8 11:17:12 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27780
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 11:17:10 -0500 (EST)
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 QQlwya09239;
	Tue, 8 Jan 2002 16:14:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwya26330
	for mpls-outgoing; Tue, 8 Jan 2002 16:14: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 QQlwya26325
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:14: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 QQlwya14220
	for <Mpls@uu.net>; Tue, 8 Jan 2002 16:13:54 GMT
Received: from [172.16.1.115] by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mdclient1.opnet.com [12.145.55.10])
	id QQlwya05565
	for <Mpls@uu.net>; Tue, 8 Jan 2002 16:14:14 GMT
Received: from wtn10216.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T585236a241ac10010f69c@>;
 Tue, 8 Jan 2002 11:13:54 -0500
Message-Id: <5.0.0.25.2.20020108110208.03f9d140@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 08 Jan 2002 11:13:09 -0500
To: Mpls@UU.NET, Ping Pan <pingpan@juniper.net>
From: Sachin Kalra <skalra@opnet.com>
Subject: One-to-Many Bypass Tunnels (Facility Backups)
Cc: mpls-ops@mplsrc.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Dear All:

Can we have more than one, "One-to-Many Bypass Tunnels (Facility Backups)" 
originating from the same node [R]? Where one Bypass Tunnel is NNHOP, i.e. 
protecting the next hop, and other Bypass Tunnel is NNNHOP i.e. protecting 
next two hops, and so on.

Thanks for your response,
Sachin Kalra 



From owner-mpls@UU.NET  Tue Jan  8 11:30:13 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28507
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 11:30:13 -0500 (EST)
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 QQlwyb23729;
	Tue, 8 Jan 2002 16:27:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyb27351
	for mpls-outgoing; Tue, 8 Jan 2002 16:27:07 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlwyb27335
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:26: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 QQlwyb18968
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:26:48 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyb27180
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:26: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 LAA24074 for <mpls@uu.net>; Tue, 8 Jan 2002 11:26:48 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14109 for mpls@uu.net; Tue, 8 Jan 2002 11:26:47 -0500 (EST)
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 QQlwyb27142
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:25: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 QQlwyb10664
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 16:25:12 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: europe.cisco.com [144.254.52.73])
	id QQlwyb22953
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 16:25:31 GMT
Received: from JVASSEUR-W2K.cisco.com (par-ilm-dhcp1-vl112-23.cisco.com [144.254.56.218])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21777;
	Tue, 8 Jan 2002 17:24:17 +0100 (MET)
Message-Id: <4.3.2.7.2.20020108171914.057d5690@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Jan 2002 17:24:20 +0100
To: Sachin Kalra <skalra@opnet.com>
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Re: One-to-Many Bypass Tunnels (Facility Backups)
Cc: Mpls@UU.NET, Ping Pan <pingpan@juniper.net>, mpls-ops@mplsrc.com
In-Reply-To: <5.0.0.25.2.20020108110208.03f9d140@mail.opnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Sachin,

At 11:13 08/01/2002 -0500, Sachin Kalra wrote:
>Dear All:
>
>Can we have more than one, "One-to-Many Bypass Tunnels (Facility Backups)" 
>originating from the same node [R]? Where one Bypass Tunnel is NNHOP, i.e. 
>protecting the next hop, and other Bypass Tunnel is NNNHOP i.e. protecting 
>next two hops, and so on.

Let me answer from a draft perspective, as the focus on this list is 
related to protocols, not specific implementation (you can still send me a 
separate email is you have questions about CISCO implementation).

To answer your question now: on a specific PLR, one can configure:
         - one or more bypass tunnels to NHOP,
         - one or more bypass tunnel to NNHOP,
         - one or more bypass tunnel to NNHOP,

The choice of a specific bypass tunnel for a TE LSP when first signalled is 
a matter of implementation.

JP.

>Thanks for your response,
>Sachin Kalra


Jean-Philippe Vasseur - jpv@cisco.com
CISCO SYSTEMS
11, rue Camille Desmoulins
92782  Issy les Moulineaux Cedex 9
FRANCE

My mobile phone number has changed
Phone: +33 (0)1 58 04 63 02
Mobile:+33 (0)6 19 98 30 26



From owner-mpls@UU.NET  Tue Jan  8 11:30:52 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28525
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 11:30:51 -0500 (EST)
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 QQlwyb28295;
	Tue, 8 Jan 2002 16:27:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyb27361
	for mpls-outgoing; Tue, 8 Jan 2002 16:27: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 QQlwyb27353
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:27:09 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 QQlwyb12309
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:26:46 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyb27116
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:26:27 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24066 for <mpls@uu.net>; Tue, 8 Jan 2002 11:26:45 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14048 for mpls@uu.net; Tue, 8 Jan 2002 11:26:45 -0500 (EST)
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 QQlwyb26999
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:22:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlwyb01258
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 16:21:53 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 QQlwyb15397
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 16:21:36 GMT
Received: from ASIMHA-W2K.amer.cisco.com (dhcp-64-102-48-150.cisco.com [64.102.48.150])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA00508;
	Tue, 8 Jan 2002 11:21:52 -0500 (EST)
Date: Tue, 8 Jan 2002 11:21:34 -0500 (Eastern Standard Time)
From: Ajay Simha <asimha@cisco.com>
To: Sachin Kalra <skalra@opnet.com>
cc: Mpls@UU.NET, Ping Pan <pingpan@juniper.net>, <mpls-ops@mplsrc.com>
Subject: Re: One-to-Many Bypass Tunnels (Facility Backups)
In-Reply-To: <5.0.0.25.2.20020108110208.03f9d140@mail.opnet.com>
Message-ID: <Pine.WNT.4.40.0201081120140.836-100000@ASIMHA-W2K.amer.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 Tue, 8 Jan 2002, Sachin Kalra wrote:

SK>Dear All:
SK>
SK>Can we have more than one, "One-to-Many Bypass Tunnels (Facility Backups)"
SK>originating from the same node [R]? Where one Bypass Tunnel is NNHOP, i.e.
SK>protecting the next hop, and other Bypass Tunnel is NNNHOP i.e. protecting
SK>next two hops, and so on.

Sure but depends on implementation

-ajay
SK>
SK>Thanks for your response,
SK>Sachin Kalra
SK>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
Cisco Systems
(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  Tue Jan  8 11:40:39 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28887
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 11:40:39 -0500 (EST)
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 QQlwyc10580;
	Tue, 8 Jan 2002 16:37:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyc28292
	for mpls-outgoing; Tue, 8 Jan 2002 16:37: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 QQlwyc28287
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:37:17 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlwyc25690
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:36:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyc11183
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:35:43 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 LAA25208 for <mpls@uu.net>; Tue, 8 Jan 2002 11:36:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA15442 for mpls@uu.net; Tue, 8 Jan 2002 11:36:01 -0500 (EST)
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 QQlwyc28086
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 16:34:55 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 QQlwyc20574
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:34:24 GMT
Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: europe.cisco.com [144.254.52.73])
	id QQlwyc07338
	for <mpls@uu.net>; Tue, 8 Jan 2002 16:34:43 GMT
Received: from JVASSEUR-W2K.cisco.com (par-ilm-dhcp1-vl112-23.cisco.com [144.254.56.218])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA25450;
	Tue, 8 Jan 2002 17:33:29 +0100 (MET)
Message-Id: <4.3.2.7.2.20020108172947.052d4d88@paris.cisco.com>
X-Sender: jvasseur@paris.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Jan 2002 17:33:31 +0100
To: skalra@opnet.com
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: Fwd: Re: One-to-Many Bypass Tunnels (Facility Backups)
Cc: mpls@UU.NET, Ping Pan <pingpan@juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>X-Sender: jvasseur@paris.cisco.com
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Tue, 08 Jan 2002 17:24:20 +0100
>To: Sachin Kalra <skalra@opnet.com>
>From: Jean Philippe Vasseur <jvasseur@cisco.com>
>Subject: Re: One-to-Many Bypass Tunnels (Facility Backups)
>Cc: Mpls@UU.NET, Ping Pan <pingpan@juniper.net>, mpls-ops@mplsrc.com
>Sender: owner-mpls@UU.NET
>
>Hi Sachin,
>
>At 11:13 08/01/2002 -0500, Sachin Kalra wrote:
>>Dear All:
>>
>>Can we have more than one, "One-to-Many Bypass Tunnels (Facility 
>>Backups)" originating from the same node [R]? Where one Bypass Tunnel is 
>>NNHOP, i.e. protecting the next hop, and other Bypass Tunnel is NNNHOP 
>>i.e. protecting next two hops, and so on.
>
>Let me answer from a draft perspective, as the focus on this list is 
>related to protocols, not specific implementation (you can still send me a 
>separate email is you have questions about CISCO implementation).
>
>To answer your question now: on a specific PLR, one can configure:
>         - one or more bypass tunnels to NHOP,
>         - one or more bypass tunnel to NNHOP,
>         - one or more bypass tunnel to NNHOP,

please read NNNHOP (in the last bullet)

JP.

>The choice of a specific bypass tunnel for a TE LSP when first signalled 
>is a matter of implementation.
>
>JP.
>
>>Thanks for your response,
>>Sachin Kalra
>
>
>Jean-Philippe Vasseur - jpv@cisco.com
>CISCO SYSTEMS
>11, rue Camille Desmoulins
>92782  Issy les Moulineaux Cedex 9
>FRANCE
>
>My mobile phone number has changed
>Phone: +33 (0)1 58 04 63 02
>Mobile:+33 (0)6 19 98 30 26


Jean-Philippe Vasseur - jpv@cisco.com
CISCO SYSTEMS
11, rue Camille Desmoulins
92782  Issy les Moulineaux Cedex 9
FRANCE

My mobile phone number has changed
Phone: +33 (0)1 58 04 63 02
Mobile:+33 (0)6 19 98 30 26



From owner-mpls@UU.NET  Tue Jan  8 12:57:48 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02537
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 12:57:48 -0500 (EST)
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 QQlwyh08570;
	Tue, 8 Jan 2002 17:55:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyh24141
	for mpls-outgoing; Tue, 8 Jan 2002 17:54: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 QQlwyh24133
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 17:54:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlwyh04120
	for <mpls@uu.net>; Tue, 8 Jan 2002 17:54:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyh10134
	for <mpls@uu.net>; Tue, 8 Jan 2002 17:53:45 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 MAA04583 for <mpls@uu.net>; Tue, 8 Jan 2002 12:54:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA19729 for mpls@uu.net; Tue, 8 Jan 2002 12:54:01 -0500 (EST)
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 QQlwyh24052
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 17:53:20 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 QQlwyh12400
	for <mpls@uu.net>; Tue, 8 Jan 2002 17:52:54 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 QQlwyh05573
	for <mpls@uu.net>; Tue, 8 Jan 2002 17:53:12 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 MAA00248
	for <mpls@uu.net>; Tue, 8 Jan 2002 12:52:50 -0500 (EST)
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 MAA15880
	for <mpls@uu.net>; Tue, 8 Jan 2002 12:52:50 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <C24FV4VL>; Tue, 8 Jan 2002 12:52:50 -0500
Message-ID: <EB6D4918A175D311971E00204840E28206CFDE03@whq-msgusr-01.pit.comms.marconi.com>
From: "Milk, Scott" <Scott.Milk@marconi.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RSVP-TE Label Merge Question
Date: Tue, 8 Jan 2002 12:52:44 -0500 
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


What happens to an allocated label for a second sender part of a session
when the two sender label streams were merged somewhere upstream?

Take the following example.  LSR1 interface to LSR2 IS merge capable.  LSR2
interface to LER3 IS NOT merge capable.  LER1 and LER2 will both request
connection to LER3 and are 2 senders of the same session.  Assume all
criteria for merging traffic are met.

  -LER1--
         \
         LSR1--LSR2--LER3
  -LER2--/

       LSR1     LSR2
      ------   ------
      Lx->L2   L2->L1
      Ly->L2   L2(?)->L3

LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.  LSR2
provids LSR1 with label L2.  When LER2 as a 2nd sender of the same session
requests the connection, LER3 includes a different label L3 for the second
sender in RESV to LSR2 as LSR2 is not merge capable.  LSR2 knowing that LSR1
is merge capable issues the same label (L2) to LSR1 for both senders.

So my question is, what happens to label L3 between LSR2 and LER3?  Clearly
since the traffic is merged at LSR1, it will never be used.  This could be a
problem for any number of consecutive non-merge capable links that follow a
merge capable one.  Obviously this problem only effects non-merge ATM links
so is this considered an insignificant problem?  









From owner-mpls@UU.NET  Tue Jan  8 13:28:44 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03812
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 13:28:44 -0500 (EST)
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 QQlwyj22946;
	Tue, 8 Jan 2002 18:26:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyj16812
	for mpls-outgoing; Tue, 8 Jan 2002 18:25: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 QQlwyj16803
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 18:25:23 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 QQlwyj14956
	for <mpls@UU.NET>; Tue, 8 Jan 2002 18:24:37 GMT
Received: from cmail.packetcom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.108.173.139])
	id QQlwyj21156
	for <mpls@UU.NET>; Tue, 8 Jan 2002 18:24:56 GMT
Received: from caspiannetworks.com ([192.168.5.200])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABP97597 (AUTH tso@caspiannetworks.com);
	Tue, 8 Jan 2002 10:24:36 -0800 (PST)
Message-ID: <3C3B33B6.F36E175C@caspiannetworks.com>
Date: Tue, 08 Jan 2002 10:00:22 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: dhg@juniper.net, pingpan@juniper.net, mpls@UU.NET
Subject: Re: Questions for FRR
References: <17C81AD1F1FED411991E006008F6D1CA013D472E@avalon.pluris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sundara,

Thanks for the feedback.  Please see my inserted comments below.....

Cheers,
Tricci

Sundara Murugan wrote:

> my comments are embedded.
>
> -----Original Message-----
> From: Tricci So [mailto:tso@caspiannetworks.com]
> Sent: Monday, January 07, 2002 3:23 PM
> To: dhg@juniper.net
> Cc: pingpan@juniper.net; mpls@UU.NET
> Subject: Questions for FRR
>
> Hi Der-Hwa and Ping,
>
> After reviewing your draft in more details, I have the following questions
> regarding the detour mechanism for FRR.  Hope you can help me to clarify a
> few
> things.  Thanks....
>
> 1. According to the latest draft, section 3.2.1, your recommend the use of
> the
> RSVP_HOP object to be included in the detour Path message.  Since the
> SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
> tunnel sender address", is also being used in the Path message, why the
> RSVP_HOP
> object is needed to carry the same information (i.e. PLR's IP addrss)?
>
> >> Detour and the protected LSPs will have the same session and sender id.
> Also the next-hop will send resv msg to the IP addr specified in the
> RSVP_HOP oject.

[Tricci] I am sorry that I don't agree.  The Detour and the Protected LSPs
should  NOT have the same sender id except for the case when the PLR is the
ingress LER.  In general, the PLR should include its IP address in the
SENDER_TEMPLATE.  To me, it does not make sense to have the PLR to initiate a
Detour LSP but to insert the ingress LER's IP address into the detour Path
message.  If my observation is correct, then the RSVP_HOP object is not needed,
isn't it?

>
> 2. In section 3.2.2., you have a statement mentioned that the MP may
> receieve
> the Path message from different interfaces with the identical SESSION and
> SENDER_TEMPLATE objects.  I don't see this would be possible except for the
> case
> of the software error.  It is because the SENDER_TEMPLATE should be coded
> with
> different LSP_IDs for the Protected and Detour LSPs for the same tunnel over
> different interfaces.  This the design intent of using different LSP_IDs to
> differentiate different instances of the LSPs for the same tunnel.  Am I
> misunderstood your statement?
>
> >> If the LSP_IDs of the protected and the detour lsp is different then they
> can't be merged.

[Tricci] There is already a Tunnel ID defined in the LSP_TUNNEL_IPv4_SESSION
object to be used to identify the tunnel (i.e. the Detour and Protected LSPs
would have the same Tunnel ID); and the merging can be done via the use of all
the info from the SESSION object.  Different LSP_ID should be used to
differentiate the Detour and the Protected LSPs.  How else can it be done to
differentiate the messages for the Detour and the Protected LSPs?  What am I
missing?

>
> 3. Somebody sent a previous email to suggest that the detour Path message
> should
> include the option to specify the requested LSP's bandwidth and
> administrative
> group constraint that is same as the Protected LSP, instead of locally
> configuring these two options at each FRR capable LSR to adopt the Protected
> LSP
> requirements or not.  I happen to agree with his view.  What do think about
> his
> suggestion?
>
> >>Since the detour lsp will be used only during reroute, the user may not
> want to waste the band-width. So, the user will decide the bw allocated for
> the detour lsp.

[Tricci] I apologize for my mis-written of my previous question.  What I meat
was to have the original Path message of the Protected LSP to contain the option
to specify what are the bandwidth and administrative requirements to be for the
Detour LSP so that no configuration is needed at each PLR to decide whether it
needs to include the bandwidth or administrative info in the Detour Path message
or not.   The current draft implies that such encoding decision is configured
locally at each PLR.  Please check it out and let me know if I am wrong.
Thanks....

>
> Thanks in advance to your help......
> Tricci



From owner-mpls@UU.NET  Tue Jan  8 13:42:27 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04455
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 13:42:27 -0500 (EST)
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 QQlwyk12861;
	Tue, 8 Jan 2002 18:39:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyk17878
	for mpls-outgoing; Tue, 8 Jan 2002 18:39: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 QQlwyk17873
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 18:39:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlwyk22027
	for <mpls@uu.net>; Tue, 8 Jan 2002 18:39:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyk23739
	for <mpls@uu.net>; Tue, 8 Jan 2002 18:38:45 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 NAA10549 for <mpls@uu.net>; Tue, 8 Jan 2002 13:39:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA22534 for mpls@uu.net; Tue, 8 Jan 2002 13:39:01 -0500 (EST)
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 QQlwyk17607
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 18:35:27 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 QQlwyk08992
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 18:35:04 GMT
Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlwyk02795
	for <Mpls@UU.NET>; Tue, 8 Jan 2002 18:34:45 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08IYpU16675;
	Tue, 8 Jan 2002 13:34:51 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08IYmF15270;
	Tue, 8 Jan 2002 13:34:48 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <CPSXPZ0B>; Tue, 8 Jan 2002 13:33:15 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E638A435@zcard0ke.ca.nortel.com>
From: "Sheng Sun"<shengs@nortelnetworks.com>
To: "'Sachin Kalra'" <skalra@opnet.com>, Mpls@UU.NET,
        Ping Pan
	 <pingpan@juniper.net>
Cc: mpls-ops@mplsrc.com
Subject: RE: One-to-Many Bypass Tunnels (Facility Backups)
Date: Tue, 8 Jan 2002 13:33:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19872.FD6BAAF0"
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_01C19872.FD6BAAF0
Content-Type: text/plain;
	charset="iso-8859-1"

>From my understanding,corrct me if I am wrong, according to the
architecure,the detour object being sent downstreams along the detour path
will only be triggered by fast reroute object inside the RSVP PATH message
reaching at the PLR  , which excludes the possibility of daisy-chained back
up routes like what you mentioned. To provide one-to-many bypass tunnels, we
need some kinds of workarounds .
 

-----Original Message-----
From: Sachin Kalra [mailto:skalra@opnet.com]
Sent: Tuesday, January 08, 2002 11:13 AM
To: Mpls@UU.NET; Ping Pan
Cc: mpls-ops@mplsrc.com
Subject: One-to-Many Bypass Tunnels (Facility Backups)


Dear All:

Can we have more than one, "One-to-Many Bypass Tunnels (Facility Backups)" 
originating from the same node [R]? Where one Bypass Tunnel is NNHOP, i.e. 
protecting the next hop, and other Bypass Tunnel is NNNHOP i.e. protecting 
next two hops, and so on.

Thanks for your response,
Sachin Kalra 

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

------_=_NextPart_001_01C19872.FD6BAAF0
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: One-to-Many Bypass Tunnels (Facility Backups)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>From my understanding,corrct me if I am wrong, =
according to the architecure,the detour object being sent downstreams =
along the detour path will only be triggered by fast reroute object =
inside the RSVP PATH message&nbsp; reaching at the PLR&nbsp; , which =
excludes the possibility of daisy-chained back up routes like what you =
mentioned. To provide one-to-many bypass tunnels, we need some kinds of =
workarounds .</FONT></P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Sachin Kalra [<A =
HREF=3D"mailto:skalra@opnet.com">mailto:skalra@opnet.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 08, 2002 11:13 AM</FONT>
<BR><FONT SIZE=3D2>To: Mpls@UU.NET; Ping Pan</FONT>
<BR><FONT SIZE=3D2>Cc: mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=3D2>Subject: One-to-Many Bypass Tunnels (Facility =
Backups)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dear All:</FONT>
</P>

<P><FONT SIZE=3D2>Can we have more than one, &quot;One-to-Many Bypass =
Tunnels (Facility Backups)&quot; </FONT>
<BR><FONT SIZE=3D2>originating from the same node [R]? Where one Bypass =
Tunnel is NNHOP, i.e. </FONT>
<BR><FONT SIZE=3D2>protecting the next hop, and other Bypass Tunnel is =
NNNHOP i.e. protecting </FONT>
<BR><FONT SIZE=3D2>next two hops, and so on.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your response,</FONT>
<BR><FONT SIZE=3D2>Sachin Kalra </FONT>
</P>

<P><FONT SIZE=3D2>-------</FONT>
<BR><FONT SIZE=3D2>The MPLS-OPS Mailing List</FONT>
<BR><FONT SIZE=3D2>Subscribe/Unsubscribe:&nbsp; <A =
HREF=3D"http://www.mplsrc.com/mplsops.shtml" =
TARGET=3D"_blank">http://www.mplsrc.com/mplsops.shtml</A></FONT>
<BR><FONT SIZE=3D2>Archive: <A =
HREF=3D"http://www.mplsrc.com/mpls-ops_archive.shtml" =
TARGET=3D"_blank">http://www.mplsrc.com/mpls-ops_archive.shtml</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19872.FD6BAAF0--



From owner-mpls@UU.NET  Tue Jan  8 13:51:28 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04816
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 13:51:28 -0500 (EST)
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 QQlwyl23152;
	Tue, 8 Jan 2002 18:49:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyl18954
	for mpls-outgoing; Tue, 8 Jan 2002 18:49:36 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 QQlwyl18949
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 18:49: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 QQlwyl15651
	for <mpls@uu.net>; Tue, 8 Jan 2002 18:48:59 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f68.pav2.hotmail.com [64.4.37.68])
	id QQlwyl09433
	for <mpls@uu.net>; Tue, 8 Jan 2002 18:48:42 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 8 Jan 2002 10:48:58 -0800
Received: from 12.125.43.134 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Tue, 08 Jan 2002 18:48:58 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" <achkinazi@hotmail.com>
To: mpls@UU.NET
Subject: draft-martini-l2circuit-trans-mpls-08.txt
Date: Tue, 08 Jan 2002 18:48:58 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F68EzVWRbavjr2hO22c00002874@hotmail.com>
X-OriginalArrivalTime: 08 Jan 2002 18:48:58.0512 (UTC) FILETIME=[21956900:01C19875]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,

Martini's L2overMPLS draft mentions static MPLS configuration. What MIBs are 
supposed to be used for that? Is anybody implementing this?

Thanks,
Igor


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



From owner-mpls@UU.NET  Tue Jan  8 14:51:25 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07716
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 14:51:25 -0500 (EST)
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 QQlwyp15116;
	Tue, 8 Jan 2002 19:48:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyp13513
	for mpls-outgoing; Tue, 8 Jan 2002 19:48:15 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlwyp13508
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 19:48: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 QQlwyp06752
	for <mpls@uu.net>; Tue, 8 Jan 2002 19:48:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyp19017
	for <mpls@uu.net>; Tue, 8 Jan 2002 19:48: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 OAA19583 for <mpls@uu.net>; Tue, 8 Jan 2002 14:48:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26329 for mpls@uu.net; Tue, 8 Jan 2002 14:48:01 -0500 (EST)
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 QQlwyp13480
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 19:47: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 QQlwyp03973
	for <mpls@UU.NET>; Tue, 8 Jan 2002 19:46:51 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyp17376
	for <mpls@UU.NET>; Tue, 8 Jan 2002 19:47:11 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19356; Tue, 8 Jan 2002 14:46:20 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (ch2-dhcp134-227.cisco.com [161.44.134.227])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAK01468;
	Tue, 8 Jan 2002 14:46:19 -0500 (EST)
Message-Id: <4.3.2.7.2.20020108143939.01e02490@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Jan 2002 14:46:19 -0500
To: "Igor Achkinazi" <achkinazi@hotmail.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: draft-martini-l2circuit-trans-mpls-08.txt
Cc: mpls@UU.NET, pwe3@ietf.org
In-Reply-To: <F68EzVWRbavjr2hO22c00002874@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


[ You may want to move this discussion to the PWE3 mailing list,
         which I have CC:ed. ]


>Martini's L2overMPLS draft mentions static MPLS configuration.
>What MIBs are supposed to be used for that?

         The PW MIBs are being constructed to support this and other features
of PWE. There are several available today:

1. draft-nadeau-pw-tc-mib-00.txt
2. draft-zelig-pw-mpls-mib-00.txt
3. draft-danenberg-pw-cem-mib-01.txt
4. draft-zelig-pw-mib-01.txt

         Some folks and I are also working on Enet and ATM "glue layer" MIBs
that will connect these services to their native MIBs (ENET, AToM MIBS)
that should be out shortly.

         The requirements for these are described here:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-02.txt

>Is anybody implementing this?

         I know of several vendors that are implementing these.

         --Tom





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



From owner-mpls@UU.NET  Tue Jan  8 15:05:22 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08418
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 15:05:22 -0500 (EST)
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 QQlwyq06053;
	Tue, 8 Jan 2002 20:02:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyq24374
	for mpls-outgoing; Tue, 8 Jan 2002 20:02:48 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlwyq23900
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 20:02:40 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 QQlwyq11622
	for <mpls@uu.net>; Tue, 8 Jan 2002 20:02:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyq08906
	for <mpls@uu.net>; Tue, 8 Jan 2002 20:02:23 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 PAA21292 for <mpls@uu.net>; Tue, 8 Jan 2002 15:02:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA27400 for mpls@uu.net; Tue, 8 Jan 2002 15:02:02 -0500 (EST)
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 QQlwyq19185
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 20:01:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlwyp27059
	for <mpls@uu.net>; Tue, 8 Jan 2002 19:59:29 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlwyp04963
	for <mpls@uu.net>; Tue, 8 Jan 2002 19:59:48 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA20983 for <mpls@uu.net>; Tue, 8 Jan 2002 14:59:28 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA15791 for <mpls@uu.net>; Tue, 8 Jan 2002 14:59:28 -0500 (EST)
Message-Id: <200201081959.OAA15791@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: One week last call on TC-MIB
Date: Tue, 08 Jan 2002 14:59:28 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

The TC-MIB arose out of a request from the IESG to combine the common
part of several other MIBs.  As such it represents work that has
already passed WG last call.  However, since the form has changed, I'm
asking for a one week last to verify that it still captures our
consensus.

Thus, this message initiates a one week last call on:

Definitions of Textual Conventions and OBJECT-IDENTITIES for 
Multi-Protocol Label Switching (MPLS) Management

	<draft-ietf-mpls-tc-mib-03.txt>

The last call ends Jan 15 at 2400 GMT.

...George

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





From owner-mpls@UU.NET  Tue Jan  8 15:07:07 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08511
	for <mpls-archive@lists.ietf.org>; Tue, 8 Jan 2002 15:07:07 -0500 (EST)
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 QQlwyq05886;
	Tue, 8 Jan 2002 20:03:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlwyq25176
	for mpls-outgoing; Tue, 8 Jan 2002 20:03:31 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 QQlwyq25139
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 8 Jan 2002 20:03: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 QQlwyq23958
	for <mpls@UU.NET>; Tue, 8 Jan 2002 20:02:50 GMT
Received: from calliope1.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQlwyq10028
	for <mpls@UU.NET>; Tue, 8 Jan 2002 20:03:10 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id UAA12172
	for <mpls@UU.NET>; Tue, 8 Jan 2002 20:02:49 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002010812035024524
 ; Tue, 08 Jan 2002 12:03:50 -0800
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <CR9WT115>; Tue, 8 Jan 2002 12:02:49 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA18E@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Milk, Scott'" <Scott.Milk@marconi.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: RSVP-TE Label Merge Question
Date: Tue, 8 Jan 2002 12:02:47 -0800 
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, LSR2 cannot issue the same label to LSR1 for the exact reason.
This is mentioned in RFC3031. The idea is that the LSR cannot have a coarser
granularity than its downstream node.

Hope this helps.

- Mark

> -----Original Message-----
> From: Milk, Scott [mailto:Scott.Milk@marconi.com]
> Sent: Tuesday, January 08, 2002 9:53 AM
> To: 'mpls@uu.net'
> Subject: RSVP-TE Label Merge Question
> 
> 
> 
> What happens to an allocated label for a second sender part 
> of a session
> when the two sender label streams were merged somewhere upstream?
> 
> Take the following example.  LSR1 interface to LSR2 IS merge 
> capable.  LSR2
> interface to LER3 IS NOT merge capable.  LER1 and LER2 will 
> both request
> connection to LER3 and are 2 senders of the same session.  Assume all
> criteria for merging traffic are met.
> 
>   -LER1--
>          \
>          LSR1--LSR2--LER3
>   -LER2--/
> 
>        LSR1     LSR2
>       ------   ------
>       Lx->L2   L2->L1
>       Ly->L2   L2(?)->L3
> 
> LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.  LSR2
> provids LSR1 with label L2.  When LER2 as a 2nd sender of the 
> same session
> requests the connection, LER3 includes a different label L3 
> for the second
> sender in RESV to LSR2 as LSR2 is not merge capable.  LSR2 
> knowing that LSR1
> is merge capable issues the same label (L2) to LSR1 for both senders.
> 
> So my question is, what happens to label L3 between LSR2 and 
> LER3?  Clearly
> since the traffic is merged at LSR1, it will never be used.  
> This could be a
> problem for any number of consecutive non-merge capable links 
> that follow a
> merge capable one.  Obviously this problem only effects 
> non-merge ATM links
> so is this considered an insignificant problem?  
> 
> 
> 
> 
> 
> 
> 


From owner-mpls@UU.NET  Wed Jan  9 00:07:27 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20438
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 00:07:27 -0500 (EST)
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 QQlxaa17791;
	Wed, 9 Jan 2002 05:06:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxaa19075
	for mpls-outgoing; Wed, 9 Jan 2002 05:06: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 QQlxaa19064
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 05:06: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 QQlxaa27796
	for <mpls@uu.net>; Wed, 9 Jan 2002 05:06:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxaa16316
	for <mpls@uu.net>; Wed, 9 Jan 2002 05:05:45 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 AAA00878 for <mpls@uu.net>; Wed, 9 Jan 2002 00:06:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA19813 for mpls@uu.net; Wed, 9 Jan 2002 00:06:02 -0500 (EST)
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 QQlxaa14545
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 05:05:32 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 QQlxaa10567
	for <mpls@UU.NET>; Wed, 9 Jan 2002 05:04:54 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 QQlxaa24559
	for <mpls@UU.NET>; Wed, 9 Jan 2002 05:04:35 GMT
Received: from juniper.net (lookout.juniper.net [172.17.20.54])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0954n611157;
	Tue, 8 Jan 2002 21:04:49 -0800 (PST)
	(envelope-from dhg@juniper.net)
Message-Id: <200201090504.g0954n611157@merlot.juniper.net>
To: Tricci So <tso@caspiannetworks.com>
cc: pingpan@juniper.net, mpls@UU.NET
Subject: Re: Questions for FRR 
In-reply-to: Your message of Tue, 08 Jan 2002 10:00:22 -0800.
             <3C3B33B6.F36E175C@caspiannetworks.com> 
Date: Tue, 08 Jan 2002 21:04:49 -0800
From: Der-Hwa Gan <dhg@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk


> Sundara,
> 
> Thanks for the feedback.  Please see my inserted comments below.....
> 
> Cheers,
> Tricci
> 
> Sundara Murugan wrote:
> 
> > my comments are embedded.
> >
> > -----Original Message-----
> > From: Tricci So [mailto:tso@caspiannetworks.com]
> > Sent: Monday, January 07, 2002 3:23 PM
> > To: dhg@juniper.net
> > Cc: pingpan@juniper.net; mpls@UU.NET
> > Subject: Questions for FRR
> >
> > Hi Der-Hwa and Ping,
> >
> > After reviewing your draft in more details, I have the following questions
> > regarding the detour mechanism for FRR.  Hope you can help me to clarify a
> > few
> > things.  Thanks....
> >
> > 1. According to the latest draft, section 3.2.1, your recommend the use of
> > the
> > RSVP_HOP object to be included in the detour Path message.  Since the
> > SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
> > tunnel sender address", is also being used in the Path message, why the
> > RSVP_HOP
> > object is needed to carry the same information (i.e. PLR's IP addrss)?
> >
> > >> Detour and the protected LSPs will have the same session and sender id.
> > Also the next-hop will send resv msg to the IP addr specified in the
> > RSVP_HOP oject.
> 
> [Tricci] I am sorry that I don't agree.  The Detour and the Protected LSPs
> should  NOT have the same sender id except for the case when the PLR is the
> ingress LER.  In general, the PLR should include its IP address in the
> SENDER_TEMPLATE.  To me, it does not make sense to have the PLR to initiate a
> Detour LSP but to insert the ingress LER's IP address into the detour Path
> message.  If my observation is correct, then the RSVP_HOP object is not neede
d,
> isn't it?

RSVP_HOP object is a hop-by-hop information, to help downstream routers
sending Resv message (and others) upstream. It is always needed, and it
should reflect the current interface being used to transmit Path message.

As for the sender id in the detour, as specified in the current spec,
is the same id as protected LSP. This was intended as a necessary
condition for doing the merging procedure.

But the spec is being changed due to comments received at last IETF. It 
will be optional whether or not PLR modifies the sender id. On the MP,
it must perform merging procedure for LSPs with identical sender id.
As for LSPs with different sender id, merging becomes optional.

> 
> >
> > 2. In section 3.2.2., you have a statement mentioned that the MP may
> > receieve
> > the Path message from different interfaces with the identical SESSION and
> > SENDER_TEMPLATE objects.  I don't see this would be possible except for the
> > case
> > of the software error.  It is because the SENDER_TEMPLATE should be coded
> > with
> > different LSP_IDs for the Protected and Detour LSPs for the same tunnel ove
r
> > different interfaces.  This the design intent of using different LSP_IDs to
> > differentiate different instances of the LSPs for the same tunnel.  Am I
> > misunderstood your statement?
> >
> > >> If the LSP_IDs of the protected and the detour lsp is different then the
y
> > can't be merged.
> 
> [Tricci] There is already a Tunnel ID defined in the LSP_TUNNEL_IPv4_SESSION
> object to be used to identify the tunnel (i.e. the Detour and Protected LSPs
> would have the same Tunnel ID); and the merging can be done via the use of al
l
> the info from the SESSION object.  Different LSP_ID should be used to
> differentiate the Detour and the Protected LSPs.  How else can it be done to
> differentiate the messages for the Detour and the Protected LSPs?  What am I
> missing?

It is not necessary to use SENDER_TEMPLATE to differentiate Detour 
and Protected LSP.  The FAST_REROUTE/DETOUR objects already do the job for you.

> 
> >
> > 3. Somebody sent a previous email to suggest that the detour Path message
> > should
> > include the option to specify the requested LSP's bandwidth and
> > administrative
> > group constraint that is same as the Protected LSP, instead of locally
> > configuring these two options at each FRR capable LSR to adopt the Protecte
d
> > LSP
> > requirements or not.  I happen to agree with his view.  What do think about
> > his
> > suggestion?
> >
> > >>Since the detour lsp will be used only during reroute, the user may not
> > want to waste the band-width. So, the user will decide the bw allocated for
> > the detour lsp.
> 
> [Tricci] I apologize for my mis-written of my previous question.  What I meat
> was to have the original Path message of the Protected LSP to contain the opt
ion
> to specify what are the bandwidth and administrative requirements to be for t
he
> Detour LSP so that no configuration is needed at each PLR to decide whether i
t
> needs to include the bandwidth or administrative info in the Detour Path mess
age
> or not.   The current draft implies that such encoding decision is configured
> locally at each PLR.  Please check it out and let me know if I am wrong.
> Thanks....

The requirements for detour are already contained in the FAST_REROUTE
object, which is configurable by user at ingress. The requirements do
include bw, administrative constraints, and others.

THanks,
Der-Hwa
> 
> >
> > Thanks in advance to your help......
> > Tricci
> 



From owner-mpls@UU.NET  Wed Jan  9 01:51:28 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21832
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 01:51:28 -0500 (EST)
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 QQlxah12170;
	Wed, 9 Jan 2002 06:50:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxah17287
	for mpls-outgoing; Wed, 9 Jan 2002 06:50: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 QQlxah17248
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 06:50:14 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 QQlxah16636
	for <mpls@UU.NET>; Wed, 9 Jan 2002 06:49:29 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 QQlxah23446
	for <mpls@UU.NET>; Wed, 9 Jan 2002 06:49:10 GMT
Received: from utfors.se ([172.20.0.47]) by tomp.smb.utfors.se
          (Netscape Messaging Server 4.15) with ESMTP id GPNSGW00.12Z;
          Wed, 9 Jan 2002 07:53:20 +0100 
Message-ID: <3C3BE7F7.FE4E5E4A@utfors.se>
Date: Wed, 09 Jan 2002 07:49:27 +0100
From: Loa Andersson <loa.andersson@utfors.se>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: George Swallow <swallow@cisco.com>
CC: mpls@UU.NET
Subject: Re: One week last call on TC-MIB
References: <200201081959.OAA15791@telescope.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,

I have one thing that might be a nit.

In the Framework/Architecture an LSR is a Label Switching Router,
while in the set of MIBs (including the TC-MIB) it is a 
Label Switch Router.
Apart from that conceptual and terminological homogeneity is a good
thing in itself, it has always been my view that an LSR is a router
doing "label switching". Should be corrected in the MIBs.

/Loa

George Swallow wrote:
> 
> The TC-MIB arose out of a request from the IESG to combine the common
> part of several other MIBs.  As such it represents work that has
> already passed WG last call.  However, since the form has changed, I'm
> asking for a one week last to verify that it still captures our
> consensus.
> 
> Thus, this message initiates a one week last call on:
> 
> Definitions of Textual Conventions and OBJECT-IDENTITIES for
> Multi-Protocol Label Switching (MPLS) Management
> 
>         <draft-ietf-mpls-tc-mib-03.txt>
> 
> The last call ends Jan 15 at 2400 GMT.
> 
> ...George
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 497-8143
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824

-- 
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  Wed Jan  9 01:56:10 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21871
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 01:56:10 -0500 (EST)
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 QQlxah08521;
	Wed, 9 Jan 2002 06:55:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxah17636
	for mpls-outgoing; Wed, 9 Jan 2002 06:55: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 QQlxah17631
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 06:55: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 QQlxah03027
	for <mpls@uu.net>; Wed, 9 Jan 2002 06:54:49 GMT
Received: from huaweidns.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.165])
	id QQlxah00720
	for <mpls@uu.net>; Wed, 9 Jan 2002 06:54:27 GMT
Received: from HUAWEIMAIL [203.197.168.162] by huaweidns.in.huawei.com - SuperScout Email Filter ; Wednesday, 09 January 2002, 12:18:01
Received: by huaweimail with Internet Mail Service (5.5.2653.19)
	id <CRHHK86H>; Wed, 9 Jan 2002 12:15:36 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C56870246DD30@huaweimail>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: "Feng, Mark" <m_feng@trillium.com>,
        "'Milk, Scott'" <Scott.Milk@marconi.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Date: Wed, 9 Jan 2002 12:15:35 +0530
Subject: RE: RSVP-TE Label Merge Question
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--=_NextPart_ST_12_18_08_Wednesday_January_09_2002_12937"
X-Mailer: Internet Mail Service (5.5.2653.19)
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_ST_12_18_08_Wednesday_January_09_2002_12937
Content-Type: text/plain;
	charset="iso-8859-1"


Hello Feng & Scott

  When LSR1 receives a label request and since it is 
  merge capable router. It doesn't send the request 
  further to LSR2 since it has already label from the 
  LSR2 and for the same session, and reply with the label 
  mapping message with the new label.
  Note that at LSR1 the outsegment will have label L2 
  for both insegment table. 

  Please correct me if i am wrong. 


Ashwin
 

-----Original Message-----
From: Feng, Mark [mailto:m_feng@trillium.com]
Sent: Wednesday, January 09, 2002 1:03 AM
To: 'Milk, Scott'; 'mpls@uu.net'
Subject: RE: RSVP-TE Label Merge Question


Actually, LSR2 cannot issue the same label to LSR1 for the exact reason.
This is mentioned in RFC3031. The idea is that the LSR cannot have a coarser
granularity than its downstream node.

Hope this helps.

- Mark

> -----Original Message-----
> From: Milk, Scott [mailto:Scott.Milk@marconi.com]
> Sent: Tuesday, January 08, 2002 9:53 AM
> To: 'mpls@uu.net'
> Subject: RSVP-TE Label Merge Question
> 
> 
> 
> What happens to an allocated label for a second sender part 
> of a session
> when the two sender label streams were merged somewhere upstream?
> 
> Take the following example.  LSR1 interface to LSR2 IS merge 
> capable.  LSR2
> interface to LER3 IS NOT merge capable.  LER1 and LER2 will 
> both request
> connection to LER3 and are 2 senders of the same session.  Assume all
> criteria for merging traffic are met.
> 
>   -LER1--
>          \
>          LSR1--LSR2--LER3
>   -LER2--/
> 
>        LSR1     LSR2
>       ------   ------
>       Lx->L2   L2->L1
>       Ly->L2   L2(?)->L3
> 
> LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.  LSR2
> provids LSR1 with label L2.  When LER2 as a 2nd sender of the 
> same session
> requests the connection, LER3 includes a different label L3 
> for the second
> sender in RESV to LSR2 as LSR2 is not merge capable.  LSR2 
> knowing that LSR1
> is merge capable issues the same label (L2) to LSR1 for both senders.
> 
> So my question is, what happens to label L3 between LSR2 and 
> LER3?  Clearly
> since the traffic is merged at LSR1, it will never be used.  
> This could be a
> problem for any number of consecutive non-merge capable links 
> that follow a
> merge capable one.  Obviously this problem only effects 
> non-merge ATM links
> so is this considered an insignificant problem?  
> 
> 
> 
> 
> 
> 
> 
--------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please notify the
originator of the message. 

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Huawei Technologies India Pvt. Ltd.
----=_NextPart_ST_12_18_08_Wednesday_January_09_2002_12937
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: RSVP-TE Label Merge Question</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Hello Feng &amp; Scott</FONT>
</P>

<P><FONT SIZE=2>&nbsp; When LSR1 receives a label request and since it is </FONT>
<BR><FONT SIZE=2>&nbsp; merge capable router. It doesn't send the request </FONT>
<BR><FONT SIZE=2>&nbsp; further to LSR2 since it has already label from the </FONT>
<BR><FONT SIZE=2>&nbsp; LSR2 and for the same session, and reply with the label </FONT>
<BR><FONT SIZE=2>&nbsp; mapping message with the new label.</FONT>
<BR><FONT SIZE=2>&nbsp; Note that at LSR1 the outsegment will have label L2 </FONT>
<BR><FONT SIZE=2>&nbsp; for both insegment table. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; Please correct me if i am wrong. </FONT>
</P>
<BR>

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

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Feng, Mark [<A HREF="mailto:m_feng@trillium.com">mailto:m_feng@trillium.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, January 09, 2002 1:03 AM</FONT>
<BR><FONT SIZE=2>To: 'Milk, Scott'; 'mpls@uu.net'</FONT>
<BR><FONT SIZE=2>Subject: RE: RSVP-TE Label Merge Question</FONT>
</P>
<BR>

<P><FONT SIZE=2>Actually, LSR2 cannot issue the same label to LSR1 for the exact reason.</FONT>
<BR><FONT SIZE=2>This is mentioned in RFC3031. The idea is that the LSR cannot have a coarser</FONT>
<BR><FONT SIZE=2>granularity than its downstream node.</FONT>
</P>

<P><FONT SIZE=2>Hope this helps.</FONT>
</P>

<P><FONT SIZE=2>- Mark</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Milk, Scott [<A HREF="mailto:Scott.Milk@marconi.com">mailto:Scott.Milk@marconi.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, January 08, 2002 9:53 AM</FONT>
<BR><FONT SIZE=2>&gt; To: 'mpls@uu.net'</FONT>
<BR><FONT SIZE=2>&gt; Subject: RSVP-TE Label Merge Question</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; What happens to an allocated label for a second sender part </FONT>
<BR><FONT SIZE=2>&gt; of a session</FONT>
<BR><FONT SIZE=2>&gt; when the two sender label streams were merged somewhere upstream?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Take the following example.&nbsp; LSR1 interface to LSR2 IS merge </FONT>
<BR><FONT SIZE=2>&gt; capable.&nbsp; LSR2</FONT>
<BR><FONT SIZE=2>&gt; interface to LER3 IS NOT merge capable.&nbsp; LER1 and LER2 will </FONT>
<BR><FONT SIZE=2>&gt; both request</FONT>
<BR><FONT SIZE=2>&gt; connection to LER3 and are 2 senders of the same session.&nbsp; Assume all</FONT>
<BR><FONT SIZE=2>&gt; criteria for merging traffic are met.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -LER1--</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSR1--LSR2--LER3</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; -LER2--/</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LSR1&nbsp;&nbsp;&nbsp;&nbsp; LSR2</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp;&nbsp; ------</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Lx-&gt;L2&nbsp;&nbsp; L2-&gt;L1</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ly-&gt;L2&nbsp;&nbsp; L2(?)-&gt;L3</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; LER1 establishes LSP to LER3.&nbsp; LER3 provides LSR2 with label L1.&nbsp; LSR2</FONT>
<BR><FONT SIZE=2>&gt; provids LSR1 with label L2.&nbsp; When LER2 as a 2nd sender of the </FONT>
<BR><FONT SIZE=2>&gt; same session</FONT>
<BR><FONT SIZE=2>&gt; requests the connection, LER3 includes a different label L3 </FONT>
<BR><FONT SIZE=2>&gt; for the second</FONT>
<BR><FONT SIZE=2>&gt; sender in RESV to LSR2 as LSR2 is not merge capable.&nbsp; LSR2 </FONT>
<BR><FONT SIZE=2>&gt; knowing that LSR1</FONT>
<BR><FONT SIZE=2>&gt; is merge capable issues the same label (L2) to LSR1 for both senders.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So my question is, what happens to label L3 between LSR2 and </FONT>
<BR><FONT SIZE=2>&gt; LER3?&nbsp; Clearly</FONT>
<BR><FONT SIZE=2>&gt; since the traffic is merged at LSR1, it will never be used.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; This could be a</FONT>
<BR><FONT SIZE=2>&gt; problem for any number of consecutive non-merge capable links </FONT>
<BR><FONT SIZE=2>&gt; that follow a</FONT>
<BR><FONT SIZE=2>&gt; merge capable one.&nbsp; Obviously this problem only effects </FONT>
<BR><FONT SIZE=2>&gt; non-merge ATM links</FONT>
<BR><FONT SIZE=2>&gt; so is this considered an insignificant problem?&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

--------------------------------------------------------------------------------------------------------------------<br>This email and any files transmitted with it are confidential and<br>intended solely for the use of the individual or entity to whom<br>they are addressed. If you have received this email in error please notify the<br>originator of the message. <br><br>Any views expressed in this message are those of the individual<br>sender, except where the sender specifies and with authority,<br>states them to be the views of Huawei Technologies India Pvt. Ltd.</BODY>
</HTML>
----=_NextPart_ST_12_18_08_Wednesday_January_09_2002_12937--



From owner-mpls@UU.NET  Wed Jan  9 04:59:13 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01882
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 04:59:13 -0500 (EST)
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 QQlxat14842;
	Wed, 9 Jan 2002 09:58:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxat00485
	for mpls-outgoing; Wed, 9 Jan 2002 09:58: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 QQlxat00480
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 09:58: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 QQlxat26832
	for <mpls@UU.NET>; Wed, 9 Jan 2002 09:57:51 GMT
Received: from ws1-2.us4.outblaze.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 205-158-62-54.outblaze.com [205.158.62.54])
	id QQlxat03345
	for <mpls@UU.NET>; Wed, 9 Jan 2002 09:57:33 GMT
Received: (qmail 90291 invoked by uid 1001); 9 Jan 2002 09:57:49 -0000
Message-ID: <20020109095749.90289.qmail@mail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from ws1-2.us4.outblaze.com for [216.175.97.127] via web-mailer
    on Wed, 09 Jan 2002 17:57:49 +0800
From: "Girish Wadhwani" <girishw@mail.com>
To: mpls@UU.NET
Date: Wed, 09 Jan 2002 17:57:49 +0800
Subject: LDP Questions
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

I have a couple of questions about LDP:


1, How do Hello messages and keepAlive messages work once a session is established with a peer? Is the peer required to send both? What happens if the LSR recieves one but not the other?

2, Are there any reference implmentations avialable for LDP?

Thanks,
Girish
-- 

_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup


1 cent a minute calls anywhere in the U.S.!

http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://www.getpennytalk.com




From owner-mpls@UU.NET  Wed Jan  9 08:24:04 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03524
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 08:24:03 -0500 (EST)
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 QQlxbh24619;
	Wed, 9 Jan 2002 13:23:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbh05337
	for mpls-outgoing; Wed, 9 Jan 2002 13:23:08 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlxbh05332
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 13:23: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 QQlxbh25436
	for <mpls@uu.net>; Wed, 9 Jan 2002 13:22:47 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlxbh29687
	for <mpls@uu.net>; Wed, 9 Jan 2002 13:22:29 GMT
Received: (qmail 1214 invoked from network); 9 Jan 2002 13:03:16 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 9 Jan 2002 13:03:16 -0000
Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121])
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id SAA17271;
	Wed, 9 Jan 2002 18:50:04 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id SAA32288;
	Wed, 9 Jan 2002 18:58:46 +0530
X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Wed, 9 Jan 2002 18:58:46 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: <mpls@UU.NET>
cc: <mpls-linux-general@lists.sourcforge.net>, <mpls@ee.iitb.ac.in>
Subject: Multithreaded LDP Implementation
Message-ID: <Pine.LNX.4.30.0201091807080.26543-100000@bharati.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

At MPLS Research Group of IIT Bombay, We have implemented a multi-threaded
implementation of Label Distribution Protocol using posix threads.

This implementation is available for download and testing at following
site

http://www.ee.iitb.ac.in/uma/~mpls/

- MPLS Group IIT Bombay (mpls@ee.iitb.ac.in)





From owner-mpls@UU.NET  Wed Jan  9 09:02:29 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03899
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 09:02:29 -0500 (EST)
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 QQlxbk05637;
	Wed, 9 Jan 2002 14:01:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbk12514
	for mpls-outgoing; Wed, 9 Jan 2002 14:01: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 QQlxbk12504
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 14:01: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 QQlxbk01027
	for <mpls@uu.net>; Wed, 9 Jan 2002 14:00:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbj19460
	for <mpls@uu.net>; Wed, 9 Jan 2002 13:59:43 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 JAA28342 for <mpls@uu.net>; Wed, 9 Jan 2002 09:00:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12515 for mpls@uu.net; Wed, 9 Jan 2002 09:00:01 -0500 (EST)
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 QQlxbj07711
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 13:59: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 QQlxbj27450
	for <mpls@UU.NET>; Wed, 9 Jan 2002 13:58:55 GMT
Received: from hawk.CrescentNetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144])
	id QQlxbj17661
	for <mpls@UU.NET>; Wed, 9 Jan 2002 13:58:36 GMT
Received: from crescentnetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132])
	by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id IAA09622;
	Wed, 9 Jan 2002 08:58:49 -0500 (EST)
Message-ID: <3C3C4D02.32122468@crescentnetworks.com>
Date: Wed, 09 Jan 2002 09:00:34 -0500
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Loa Andersson <loa.andersson@utfors.se>
CC: George Swallow <swallow@cisco.com>, mpls@UU.NET
Subject: Re: One week last call on TC-MIB
References: <200201081959.OAA15791@telescope.cisco.com> <3C3BE7F7.FE4E5E4A@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 JAA03899


Loa,

I agree.  The Architecture doc does define LSR as
Label Switching Router and MIBs should be consistent.

There are 2 or 3 changes to the TC MIB and about 3 to the LDP MIB.

   Thanks, 
    -Joan

Loa Andersson wrote:
> 
> All,
> 
> I have one thing that might be a nit.
> 
> In the Framework/Architecture an LSR is a Label Switching Router,
> while in the set of MIBs (including the TC-MIB) it is a
> Label Switch Router.
> Apart from that conceptual and terminological homogeneity is a good
> thing in itself, it has always been my view that an LSR is a router
> doing "label switching". Should be corrected in the MIBs.
> 
> /Loa
> 
> George Swallow wrote:
> >
> > The TC-MIB arose out of a request from the IESG to combine the common
> > part of several other MIBs.  As such it represents work that has
> > already passed WG last call.  However, since the form has changed, I'm
> > asking for a one week last to verify that it still captures our
> > consensus.
> >
> > Thus, this message initiates a one week last call on:
> >
> > Definitions of Textual Conventions and OBJECT-IDENTITIES for
> > Multi-Protocol Label Switching (MPLS) Management
> >
> >         <draft-ietf-mpls-tc-mib-03.txt>
> >
> > The last call ends Jan 15 at 2400 GMT.
> >
> > ...George
> >
> > ======================================================================
> > George Swallow          Cisco Systems                   (978) 497-8143
> >                         250 Apollo Drive
> >                         Chelmsford, Ma 01824
> 
> --
> 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  Wed Jan  9 09:07:03 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03960
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 09:07:03 -0500 (EST)
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 QQlxbk04838;
	Wed, 9 Jan 2002 14:06:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbk26683
	for mpls-outgoing; Wed, 9 Jan 2002 14:06: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 QQlxbk26409
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 14:06:09 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 QQlxbk07301
	for <mpls@uu.net>; Wed, 9 Jan 2002 14:06:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbk00339
	for <mpls@uu.net>; Wed, 9 Jan 2002 14:05:43 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 JAA28847 for <mpls@uu.net>; Wed, 9 Jan 2002 09:06:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13077 for mpls@uu.net; Wed, 9 Jan 2002 09:06:02 -0500 (EST)
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 QQlxbk23514
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 14:05:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlxbk22038
	for <mpls@UU.NET>; Wed, 9 Jan 2002 14:05:31 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbk29566
	for <mpls@UU.NET>; Wed, 9 Jan 2002 14:05:11 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28786; Wed, 9 Jan 2002 09:05:30 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAK10318;
	Wed, 9 Jan 2002 09:05:29 -0500 (EST)
Message-Id: <4.3.2.7.2.20020109090324.01e982e8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Jan 2002 09:05:02 -0500
To: Loa Andersson <loa.andersson@utfors.se>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: One week last call on TC-MIB
Cc: George Swallow <swallow@cisco.com>, mpls@UU.NET
In-Reply-To: <3C3BE7F7.FE4E5E4A@utfors.se>
References: <200201081959.OAA15791@telescope.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03960

At 07:49 AM 1/9/2002 +0100, Loa Andersson wrote:
>All,
>
>I have one thing that might be a nit.
>
>In the Framework/Architecture an LSR is a Label Switching Router,
>while in the set of MIBs (including the TC-MIB) it is a
>Label Switch Router.

         I think that the collection of MIBs forms the management base
for a standard LSR (i.e.: what is defined in the framework). So I
don't understand your question. Are you  saying that the text
for the MIBs states that the MIBs *are* the LSR?

         --Tom

>Apart from that conceptual and terminological homogeneity is a good
>thing in itself, it has always been my view that an LSR is a router
>doing "label switching". Should be corrected in the MIBs.
>
>/Loa
>
>George Swallow wrote:
> >
> > The TC-MIB arose out of a request from the IESG to combine the common
> > part of several other MIBs.  As such it represents work that has
> > already passed WG last call.  However, since the form has changed, I'm
> > asking for a one week last to verify that it still captures our
> > consensus.
> >
> > Thus, this message initiates a one week last call on:
> >
> > Definitions of Textual Conventions and OBJECT-IDENTITIES for
> > Multi-Protocol Label Switching (MPLS) Management
> >
> >         <draft-ietf-mpls-tc-mib-03.txt>
> >
> > The last call ends Jan 15 at 2400 GMT.
> >
> > ...George
> >
> > ======================================================================
> > George Swallow          Cisco Systems                   (978) 497-8143
> >                         250 Apollo Drive
> >                         Chelmsford, Ma 01824
>
>--
>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



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



From owner-mpls@UU.NET  Wed Jan  9 10:12:33 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05147
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 10:12:33 -0500 (EST)
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 QQlxbo04981;
	Wed, 9 Jan 2002 15:10:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbo22914
	for mpls-outgoing; Wed, 9 Jan 2002 15:10: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 QQlxbo22889
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15:10: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 QQlxbo20914
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:10:17 GMT
Received: from mail.paramanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.paramaoptical.com [216.217.24.162])
	id QQlxbo12380
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:09:59 GMT
Content-class: urn:content-classes:message
Subject: RE: One week last call on TC-MIB
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 9 Jan 2002 10:10:16 -0500
Message-ID: <9791A828507D5A418741095C3FD0DDE33BB617@INDUS.paramanet.com>
Thread-topic: One week last call on TC-MIB
Thread-index: AcGZFvL36XbdK0f8QVWOKjNY2LIJNAACIO+w
From: "Cheenu Srinivasan" <cheenu@paramanet.com>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>,
        "Loa Andersson" <loa.andersson@utfors.se>
Cc: <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 KAA05147

> >In the Framework/Architecture an LSR is a Label Switching Router,
> >while in the set of MIBs (including the TC-MIB) it is a
> >Label Switch Router.
> 
>          I think that the collection of MIBs forms the management base
> for a standard LSR (i.e.: what is defined in the framework). So I
> don't understand your question. Are you  saying that the text
> for the MIBs states that the MIBs *are* the LSR?

I believe Loa is saying that the MIBs should define LSR to be "Label
Switching Router" rather than "Label Switch Router" as it is now.
We'll fix this. Thanks,

Cheenu


From owner-mpls@UU.NET  Wed Jan  9 10:23:00 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05279
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 10:22:59 -0500 (EST)
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 QQlxbp09103;
	Wed, 9 Jan 2002 15:21:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbp24154
	for mpls-outgoing; Wed, 9 Jan 2002 15:21: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 QQlxbp24140
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15: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 QQlxbp00958
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:20:26 GMT
Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQlxbp07495
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:20:46 GMT
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g09FKPE18770
	for <mpls@UU.NET>; Wed, 9 Jan 2002 10:20:25 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <Z0ZV6NWA>; Wed, 9 Jan 2002 16:20:24 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E40F2BC@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Thomas D. Nadeau" <tnadeau@cisco.com>,
        Loa Andersson
	 <loa.andersson@utfors.se>
Cc: mpls@UU.NET
Subject: RE: One week last call on TC-MIB
Date: Wed, 9 Jan 2002 16:20:15 +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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05279

I think that Loa meant that you should be consistent
in the terminology, also in the MIBs.

Bert 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Wednesday, January 09, 2002 3:05 PM
> To: Loa Andersson
> Cc: George Swallow; mpls@UU.NET
> Subject: Re: One week last call on TC-MIB
> 
> 
> At 07:49 AM 1/9/2002 +0100, Loa Andersson wrote:
> >All,
> >
> >I have one thing that might be a nit.
> >
> >In the Framework/Architecture an LSR is a Label Switching Router,
> >while in the set of MIBs (including the TC-MIB) it is a
> >Label Switch Router.
> 
>          I think that the collection of MIBs forms the management base
> for a standard LSR (i.e.: what is defined in the framework). So I
> don't understand your question. Are you  saying that the text
> for the MIBs states that the MIBs *are* the LSR?
> 
>          --Tom
> 
> >Apart from that conceptual and terminological homogeneity is a good
> >thing in itself, it has always been my view that an LSR is a router
> >doing "label switching". Should be corrected in the MIBs.
> >
> >/Loa
> >
> >George Swallow wrote:
> > >
> > > The TC-MIB arose out of a request from the IESG to 
> combine the common
> > > part of several other MIBs.  As such it represents work that has
> > > already passed WG last call.  However, since the form has 
> changed, I'm
> > > asking for a one week last to verify that it still captures our
> > > consensus.
> > >
> > > Thus, this message initiates a one week last call on:
> > >
> > > Definitions of Textual Conventions and OBJECT-IDENTITIES for
> > > Multi-Protocol Label Switching (MPLS) Management
> > >
> > >         <draft-ietf-mpls-tc-mib-03.txt>
> > >
> > > The last call ends Jan 15 at 2400 GMT.
> > >
> > > ...George
> > >
> > > 
> ======================================================================
> > > George Swallow          Cisco Systems                   
> (978) 497-8143
> > >                         250 Apollo Drive
> > >                         Chelmsford, Ma 01824
> >
> >--
> >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
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 


From owner-mpls@UU.NET  Wed Jan  9 10:38:52 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05638
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 10:38:52 -0500 (EST)
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 QQlxbq03632;
	Wed, 9 Jan 2002 15:36:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbq25223
	for mpls-outgoing; Wed, 9 Jan 2002 15:35: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 QQlxbq25217
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15:35: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 QQlxbq14620
	for <mpls@uu.net>; Wed, 9 Jan 2002 15:34:50 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbq21017
	for <mpls@uu.net>; Wed, 9 Jan 2002 15:34: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 KAA09272 for <mpls@uu.net>; Wed, 9 Jan 2002 10:34:50 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18009 for mpls@uu.net; Wed, 9 Jan 2002 10:34:50 -0500 (EST)
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 QQlxad23135
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 05:53:09 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlxad22337
	for <mpls@UU.NET>; Wed, 9 Jan 2002 05:52:57 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe44.law9.hotmail.com [64.4.8.16])
	id QQlxad00636
	for <mpls@UU.NET>; Wed, 9 Jan 2002 05:52:40 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 8 Jan 2002 21:52:56 -0800
X-Originating-IP: [202.125.129.110]
From: "Asim Khan" <rainron@hotmail.com>
To: "senthil ayyasamy" <mplsgeek@yahoo.com>, <jshen@cad.zju.edu.cn>,
        <mpls@UU.NET>, <mpls-ops@mplsrc.com>
References: <20020107042430.8649.qmail@web20803.mail.yahoo.com>
Subject: Re: Will MPLS replace ATM in near future?
Date: Tue, 8 Jan 2002 11:04:34 +0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0191_01C19834.417CBDE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID: <OE44SYxzgmUbVKiIaBg000110dd@hotmail.com>
X-OriginalArrivalTime: 09 Jan 2002 05:52:56.0360 (UTC) FILETIME=[E2CA9A80:01C198D1]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0191_01C19834.417CBDE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi senthil
you are right but as lon as i know that its the lable exist b/w layer 2 =
and layer 3 why it will replace to ATM.

Regards
Asim

  ----- Original Message -----=20
  From: senthil ayyasamy=20
  To: jshen@cad.zju.edu.cn ; mpls@UU.NET ; mpls-ops@mplsrc.com=20
  Sent: Monday, January 07, 2002 9:24 AM
  Subject: Re: Will MPLS replace ATM in near future?


   Hi Shen,=20

      Ur reasoning seems to be good ..But what i feel is MPLS will help =
to make ATM and IP networks to co-exist than replacing ATM.Also, ATM is =
a well-tested technology with all features..I think lot of traffic =
engineering mechanisms in ATM  is also applicable to MPLS environ..Also =
many features now adapted in IETF for MPLS have come from ATM features =
only..So,I dont think ATM will be out-of-day in the near future rather =
MPLS will butress ATM usage .This seems to be possible but i am not =
aware whether it is being done in the industry..It is for the industry =
to answer!!!=20

  senthil.=20

    Jing Shen <jshen@cad.zju.edu.cn> wrote:=20

    Hi:=20
    I've noticed that the research on MPLS has come to a very hot spot =
in past days. And, now Cisco and other company start to=20
    provide MPLS enabled interconnection product, both in backbone =
interconnection product and those for access network. I even read about =
"ethernet over MPLS". I think this will change not only current =
interconnection technology but also those backbone transmission =
techniques.=20
    Because, as I think, this means now MPLS can take the place of=20
    those high speed access network ( PPPoA, PPPoE ) dominated by ATM, =
and the method how those subscriber channels are multiplexed=20
    into a up transmission backbone. If the backbone is also made up of =
MPLS, the method will be more flexible and gives more service. Also the =
variable length of MPLS frame will give=20
    more effient usage of physical channal.=20

    So, I want to know is ATM will be out-of-day in near future ?=20

--=20
Jing Shen

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************
     =20


  SENTHIL KUMAR
  MS(COMPUTER NETWORKING)
  UMKC,
  MO-64112,USA




-------------------------------------------------------------------------=
-----
  Do You Yahoo!?
  Send FREE video emails in Yahoo! Mail.

------=_NextPart_000_0191_01C19834.417CBDE0
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.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi senthil</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>you are right but as lon as i know that =
its the=20
lable exist b/w layer 2 and layer 3 why it will replace to =
ATM.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Asim</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:mplsgeek@yahoo.com" =
title=3Dmplsgeek@yahoo.com>senthil=20
  ayyasamy</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:jshen@cad.zju.edu.cn"=20
  title=3Djshen@cad.zju.edu.cn>jshen@cad.zju.edu.cn</A> ; <A=20
  href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>mpls@UU.NET</A> ; <A=20
  href=3D"mailto:mpls-ops@mplsrc.com"=20
  title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 07, 2002 =
9:24=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Will MPLS replace =
ATM in=20
  near future?</DIV>
  <DIV><BR></DIV>
  <P>&nbsp;Hi Shen,=20
  <P>&nbsp;&nbsp;&nbsp; Ur reasoning seems to be good ..But what i feel =
is MPLS=20
  will help to make ATM and IP networks to co-exist than replacing =
ATM.Also, ATM=20
  is a well-tested technology with all features..I think lot of traffic=20
  engineering mechanisms in ATM &nbsp;is also applicable to MPLS =
environ..Also=20
  many features now adapted in IETF for MPLS have come from ATM features =

  only..So,I dont think ATM will be out-of-day in the near future rather =
MPLS=20
  will butress ATM usage .This seems to be possible but i am not aware =
whether=20
  it is being done in the industry..It is for the industry to answer!!!=20
  <P>senthil.=20
  <P>&nbsp; <B><I>Jing Shen &lt;jshen@cad.zju.edu.cn&gt;</I></B> wrote:=20
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">Hi:=20

    <P>I've noticed that the research on MPLS has come to a very hot =
spot in=20
    past days. And, now Cisco and other company start to <BR>provide =
MPLS=20
    enabled interconnection product, both in backbone interconnection =
product=20
    and those for access network. I even read about "ethernet over =
MPLS". I=20
    think this will change not only current interconnection technology =
but also=20
    those backbone transmission techniques. <BR>Because, as I think, =
this means=20
    now MPLS can take the place of <BR>those high speed access network ( =
PPPoA,=20
    PPPoE ) dominated by ATM, and the method how those subscriber =
channels are=20
    multiplexed <BR>into a up transmission backbone. If the backbone is =
also=20
    made up of MPLS, the method will be more flexible and gives more =
service.=20
    Also the variable length of MPLS frame will give <BR>more effient =
usage of=20
    physical channal.=20
    <P>So, I want to know is ATM will be out-of-day in near future ? =
<PRE>--&nbsp;
Jing Shen

**********************************************************************
* The SunShine of life is made up of very little beams which =
is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
*&nbsp; bright all the =
time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *
**********************************************************************</P=
RE>&nbsp;=20
  </BLOCKQUOTE><BR><BR>SENTHIL KUMAR<BR>MS(COMPUTER=20
  NETWORKING)<BR>UMKC,<BR>MO-64112,USA
  <P><BR>
  <HR SIZE=3D1>
  <B>Do You Yahoo!?</B><BR>Send FREE <A=20
  =
href=3D"http://rd.yahoo.com/mail_us/tag/?http://promo.yahoo.com/videomail=
/">video</A>=20
  emails in <A=20
  =
href=3D"http://rd.yahoo.com/mail_us/tag/?http://mail.yahoo.com/">Yahoo!=20
Mail</A>.</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0191_01C19834.417CBDE0--



From owner-mpls@UU.NET  Wed Jan  9 10:42:17 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05709
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 10:42:17 -0500 (EST)
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 QQlxbq27757;
	Wed, 9 Jan 2002 15:38:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbq25571
	for mpls-outgoing; Wed, 9 Jan 2002 15:38: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 QQlxbq25566
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15:38:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlxbq28977
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:38:33 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 QQlxbq08613
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:38:53 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 KAA21208
	for <mpls@UU.NET>; Wed, 9 Jan 2002 10:38:26 -0500 (EST)
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 KAA14965
	for <mpls@UU.NET>; Wed, 9 Jan 2002 10:38:26 -0500 (EST)
Message-ID: <3C3C644E.65940DC9@marconi.com>
Date: Wed, 09 Jan 2002 10:39:58 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: RSVP-TE Label Merge Question
References: <751B6DD7A243D511AB9F0002557C56870246DD30@huaweimail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ashwin C. Prabhu wrote:
> Feng, Mark wrote:
>> Milk, Scott wrote:
>>>
>>> What happens to an allocated label for a second sender part of a
>>> session when the two sender label streams were merged somewhere
>>> upstream?
>>>
>>> Take the following example.  LSR1 interface to LSR2 IS merge
>>> capable.  LSR2 interface to LER3 IS NOT merge capable.  LER1 and
>>> LER2 will both request connection to LER3 and are 2 senders of the
>>> same session.  Assume all criteria for merging traffic are met.
>>>
>>>   -LER1--
>>>          \
>>>          LSR1--LSR2--LER3
>>>   -LER2--/
>>>
>>>        LSR1     LSR2
>>>       ------   ------
>>>       Lx->L2   L2->L1
>>>       Ly->L2   L2(?)->L3
>>>
>>> LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.
>>> LSR2 provids LSR1 with label L2.  When LER2 as a 2nd sender of the
>>> same session requests the connection, LER3 includes a different
>>> label L3 for the second sender in RESV to LSR2 as LSR2 is not
>>> merge capable.  LSR2 knowing that LSR1 is merge capable issues the
>>> same label (L2) to LSR1 for both senders.
>>>
>>> So my question is, what happens to label L3 between LSR2 and
>>> LER3?  Clearly since the traffic is merged at LSR1, it will never
>>> be used.  This could be a problem for any number of consecutive
>>> non-merge capable links that follow a merge capable one.
>>> Obviously this problem only effects non-merge ATM links so is
>>> this considered an insignificant problem?
>>
>> Actually, LSR2 cannot issue the same label to LSR1 for the exact
>> reason.  This is mentioned in RFC3031. The idea is that the LSR
>> cannot have a coarser granularity than its downstream node.
> 
> When LSR1 receives a label request and since it is merge capable
> router. It doesn't send the request further to LSR2 since it has
> already label from the LSR2 and for the same session, and reply
> with the label mapping message with the new label.  Note that at
> LSR1 the outsegment will have label L2 for both insegment table.

You are describing LDP operation, not RSVP-TE.

Unless I've been missing something fundamental for the past two years,
an RSVP Path message must propagate all the way to the egress router
(except when WF-style reservations are used, which is not applicable for
MPLS).

This means that the LABEL_REQUEST object goes all the way to the egress.

The way I see it, if LSR1 decides to merge the two LSPs, then the labels
assigned by LSR2 and LER3 for one of them will be wasted.

The solution to the wastage is for LSR2 and LER3 to also assign the same
label for the two LSPs, but the question then becomes how they know that
they should do this.  In this case, it doesn't matter that LSR2 and LER3
are not merge capable - one the data plane it's still one label in, and
one label out.  But their choice to do this will fail if LSR1 is not
merge capable.

-- David


From owner-mpls@UU.NET  Wed Jan  9 10:51:52 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05871
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 10:51:52 -0500 (EST)
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 QQlxbr27351;
	Wed, 9 Jan 2002 15:45:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbr26254
	for mpls-outgoing; Wed, 9 Jan 2002 15:45:37 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 QQlxbr26246
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15:45: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 QQlxbr15088
	for <mpls@uu.net>; Wed, 9 Jan 2002 15:45:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbq07194
	for <mpls@uu.net>; Wed, 9 Jan 2002 15:44: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 KAA11303 for <mpls@uu.net>; Wed, 9 Jan 2002 10:45:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19036 for mpls@uu.net; Wed, 9 Jan 2002 10:45:03 -0500 (EST)
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 QQlxbq26101
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 15:44:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlxbq09063
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:42:45 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxbq03739
	for <mpls@UU.NET>; Wed, 9 Jan 2002 15:42:28 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10744; Wed, 9 Jan 2002 10:42:45 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAK11982;
	Wed, 9 Jan 2002 10:42:43 -0500 (EST)
Message-Id: <4.3.2.7.2.20020109104153.01f1c290@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Jan 2002 10:42:16 -0500
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: One week last call on TC-MIB
Cc: Loa Andersson <loa.andersson@utfors.se>, mpls@UU.NET
In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0E40F2BC@nl0006exch002u.nl
 .lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05871


         Yes. Just added this to my "IESG MIB changes" file.

         --Tom

>I think that Loa meant that you should be consistent
>in the terminology, also in the MIBs.
>
>Bert
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Wednesday, January 09, 2002 3:05 PM
> > To: Loa Andersson
> > Cc: George Swallow; mpls@UU.NET
> > Subject: Re: One week last call on TC-MIB
> >
> >
> > At 07:49 AM 1/9/2002 +0100, Loa Andersson wrote:
> > >All,
> > >
> > >I have one thing that might be a nit.
> > >
> > >In the Framework/Architecture an LSR is a Label Switching Router,
> > >while in the set of MIBs (including the TC-MIB) it is a
> > >Label Switch Router.
> >
> >          I think that the collection of MIBs forms the management base
> > for a standard LSR (i.e.: what is defined in the framework). So I
> > don't understand your question. Are you  saying that the text
> > for the MIBs states that the MIBs *are* the LSR?
> >
> >          --Tom
> >
> > >Apart from that conceptual and terminological homogeneity is a good
> > >thing in itself, it has always been my view that an LSR is a router
> > >doing "label switching". Should be corrected in the MIBs.
> > >
> > >/Loa
> > >
> > >George Swallow wrote:
> > > >
> > > > The TC-MIB arose out of a request from the IESG to
> > combine the common
> > > > part of several other MIBs.  As such it represents work that has
> > > > already passed WG last call.  However, since the form has
> > changed, I'm
> > > > asking for a one week last to verify that it still captures our
> > > > consensus.
> > > >
> > > > Thus, this message initiates a one week last call on:
> > > >
> > > > Definitions of Textual Conventions and OBJECT-IDENTITIES for
> > > > Multi-Protocol Label Switching (MPLS) Management
> > > >
> > > >         <draft-ietf-mpls-tc-mib-03.txt>
> > > >
> > > > The last call ends Jan 15 at 2400 GMT.
> > > >
> > > > ...George
> > > >
> > > >
> > ======================================================================
> > > > George Swallow          Cisco Systems
> > (978) 497-8143
> > > >                         250 Apollo Drive
> > > >                         Chelmsford, Ma 01824
> > >
> > >--
> > >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
> >
> >
> >
> > --------------------------------------------------------------
> > ----------
> > Mathematics is the supreme nostalgia of our time.
> >



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



From owner-mpls@UU.NET  Wed Jan  9 12:20:04 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07525
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 12:20:04 -0500 (EST)
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 QQlxbx02982;
	Wed, 9 Jan 2002 17:15:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxbx13598
	for mpls-outgoing; Wed, 9 Jan 2002 17:15: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 QQlxbx13516
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 17:15: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 QQlxbw04114
	for <mpls@uu.net>; Wed, 9 Jan 2002 17:14:20 GMT
Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQlxbw00983
	for <mpls@uu.net>; Wed, 9 Jan 2002 17:14:02 GMT
Received: from mail1.tellium.com (unverified) by alpha.tellium.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58579450dd4177d21035c@alpha.tellium.com>;
 Wed, 9 Jan 2002 12:14:19 -0500
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <ZFHNV84A>; Wed, 9 Jan 2002 12:13:38 -0500
Message-ID: <05707214338CD5119BFF0040A5B170D3039BD5@mail3.tellium.com>
From: Vasanthi Thirumalai <Vasanthi@tellium.com>
To: "'Girish Wadhwani'" <girishw@mail.com>, mpls@UU.NET
Subject: RE: LDP Questions
Date: Wed, 9 Jan 2002 12:07:57 -0500 
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


Girish,
Yes, even after a session is established it is necessary to send both the
Hello messages and the Keep alive messages. The reason for this has been
already discussed at length(some two years ago, if my memory is right) on
this list. You can refer the archives for that discussion.

If the Hello message is not received on time the hello adjacency as well as
the session(assuming this is the last Hello adjacency between the pair in
question) are terminated.

If the Hellos are received but not the keep alive, then just the session is
terminated and on receiving the next Hello, the session is established again
as though this is a new neighbor discovery.

Regarding the reference LDP implementation, the next mail on this list seems
to provide the answer. I have not personally used this implementation but
this is the most recent one that I heard of.

-Vasanthi
-----Original Message-----
From: Girish Wadhwani [mailto:girishw@mail.com]
Sent: Wednesday, January 09, 2002 4:58 AM
To: mpls@UU.NET
Subject: LDP Questions


Hello,

I have a couple of questions about LDP:


1, How do Hello messages and keepAlive messages work once a session is
established with a peer? Is the peer required to send both? What happens if
the LSR recieves one but not the other?

2, Are there any reference implmentations avialable for LDP?

Thanks,
Girish
-- 

_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup


1 cent a minute calls anywhere in the U.S.!

http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://
www.getpennytalk.com



From owner-mpls@UU.NET  Wed Jan  9 16:53:53 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17175
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 16:53:53 -0500 (EST)
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 QQlxcp14159;
	Wed, 9 Jan 2002 21:53:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxcp23687
	for mpls-outgoing; Wed, 9 Jan 2002 21:53: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 QQlxcp23676
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 9 Jan 2002 21:52: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 QQlxcp08328
	for <mpls@uu.net>; Wed, 9 Jan 2002 21:52:43 GMT
Received: from web14007.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14007.mail.yahoo.com [216.136.175.123])
	id QQlxcp13176
	for <mpls@uu.net>; Wed, 9 Jan 2002 21:53:02 GMT
Message-ID: <20020109215240.80770.qmail@web14007.mail.yahoo.com>
Received: from [216.94.112.2] by web14007.mail.yahoo.com via HTTP; Wed, 09 Jan 2002 16:52:40 EST
Date: Wed, 9 Jan 2002 16:52:40 -0500 (EST)
From: carlito mendez <carlito555_2000@yahoo.ca>
Subject: Q: Has anyone ever implemented (draft-ietf-mpls-rsvp-unnum-03.txt)
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

- does anybody know any practical uses for this
(besides saving IP address space)

- has this been implemented by anyone ?  Configuration
example would be helpful to experiment with...

Thanks!


______________________________________________________________________ 
Web-hosting solutions for home and business! http://website.yahoo.ca


From owner-mpls@UU.NET  Wed Jan  9 19:19:22 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21743
	for <mpls-archive@lists.ietf.org>; Wed, 9 Jan 2002 19:19:22 -0500 (EST)
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 QQlxcz00736;
	Thu, 10 Jan 2002 00:19:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxcz09631
	for mpls-outgoing; Thu, 10 Jan 2002 00:18: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 QQlxcz09624
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 10 Jan 2002 00:18:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlxcz16498
	for <mpls@UU.NET>; Thu, 10 Jan 2002 00:17:08 GMT
Received: from cmail.packetcom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.108.173.139])
	id QQlxcz28695
	for <mpls@UU.NET>; Thu, 10 Jan 2002 00:17:28 GMT
Received: from caspiannetworks.com ([192.168.5.200])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABQ08177 (AUTH tso@caspiannetworks.com);
	Wed, 9 Jan 2002 16:17:07 -0800 (PST)
Message-ID: <3C3CD7CB.1352719E@caspiannetworks.com>
Date: Wed, 09 Jan 2002 15:52:44 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Der-Hwa Gan <dhg@juniper.net>
CC: pingpan@juniper.net, mpls@UU.NET
Subject: Re: Questions for FRR
References: <200201090504.g0954n611157@merlot.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Der-Hwa,

Thank you for your responses.  However, somehow it seems I can't quite clearly
describe my questions to you and Sandara.  In order to make it easier for our
further discussion, let me rephase each question carefully to you.

1. In the latest draft, section 3.2, it indicates that the user of RSVP_HOP object
is needed for the "Detour" Path message.

My question is that why "hop-by-hop" info is needed for the "Detour" LSP especially
the RRO object will be returned in the Resv message.  I can see that it is needed
for the "Protected" LSP since each PLR needs to be awared of its neighbour. But I
don't know why it is needed for the Detour LSP.   I understand that the RSVP_HOP is
mandatory for a Path message for RSVP. But, is this the case for the RSVP-TE?

2. According to RFC 3209, you can use the LSP_TUNNEL_IPv4_SESSION to identify the
ingress and the egress LERs to uniquely identify the same LSP tunnel to support
merging;  and use the LSP_ID from the SENDER_TEMPLATE object to differentiate
instance of the LSP for a particular tunnel.

But in your FRR approach
(a) All PLRs encode the SENDER_TEMPLATE with the ingress LER's IP address instead
of the PLR's IP address to support merging
(b) Rather than using the LSP_ID, you use the Fast_reroute and Detour objects to
distinguish the Protected and Detour LSP requests.

(3) Finally, I am aware that the Detour Path message includes the bandwidth and the
administrative group info.  But, my question is that how to let each PLR know what
to encode in the bandwidth and administrative group objects (e.g. original
bandwidth for Protected LSP is 1 Gb, but the bandwidth for the Detour LSP is
degraded to 0.2 Gb)?   One way for PLR to know what the detour bandwidth to set to
or how to select the detour path as according to the administrative group info or
not is to configure each PLR locally.  The other way is to have the ingress LER to
specify such information in the beginning of the Path message of the Protected
LSP.   In fact, the latter approach make more sense since it is likely the ingress
LER would have the policy information of the Detour requirements.  Your current FRR
approach will require the policy to be distributed to all PLRs.

I hope that this time I make my questions more clear to you.  Thanks in advance to
your help:-o)

Tricci


Der-Hwa Gan wrote:

> > Sundara,
> >
> > Thanks for the feedback.  Please see my inserted comments below.....
> >
> > Cheers,
> > Tricci
> >
> > Sundara Murugan wrote:
> >
> > > my comments are embedded.
> > >
> > > -----Original Message-----
> > > From: Tricci So [mailto:tso@caspiannetworks.com]
> > > Sent: Monday, January 07, 2002 3:23 PM
> > > To: dhg@juniper.net
> > > Cc: pingpan@juniper.net; mpls@UU.NET
> > > Subject: Questions for FRR
> > >
> > > Hi Der-Hwa and Ping,
> > >
> > > After reviewing your draft in more details, I have the following questions
> > > regarding the detour mechanism for FRR.  Hope you can help me to clarify a
> > > few
> > > things.  Thanks....
> > >
> > > 1. According to the latest draft, section 3.2.1, your recommend the use of
> > > the
> > > RSVP_HOP object to be included in the detour Path message.  Since the
> > > SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
> > > tunnel sender address", is also being used in the Path message, why the
> > > RSVP_HOP
> > > object is needed to carry the same information (i.e. PLR's IP addrss)?
> > >
> > > >> Detour and the protected LSPs will have the same session and sender id.
> > > Also the next-hop will send resv msg to the IP addr specified in the
> > > RSVP_HOP oject.
> >
> > [Tricci] I am sorry that I don't agree.  The Detour and the Protected LSPs
> > should  NOT have the same sender id except for the case when the PLR is the
> > ingress LER.  In general, the PLR should include its IP address in the
> > SENDER_TEMPLATE.  To me, it does not make sense to have the PLR to initiate a
> > Detour LSP but to insert the ingress LER's IP address into the detour Path
> > message.  If my observation is correct, then the RSVP_HOP object is not neede
> d,
> > isn't it?
>
> RSVP_HOP object is a hop-by-hop information, to help downstream routers
> sending Resv message (and others) upstream. It is always needed, and it
> should reflect the current interface being used to transmit Path message.
>
> As for the sender id in the detour, as specified in the current spec,
> is the same id as protected LSP. This was intended as a necessary
> condition for doing the merging procedure.
>
> But the spec is being changed due to comments received at last IETF. It
> will be optional whether or not PLR modifies the sender id. On the MP,
> it must perform merging procedure for LSPs with identical sender id.
> As for LSPs with different sender id, merging becomes optional.
>
> >
> > >
> > > 2. In section 3.2.2., you have a statement mentioned that the MP may
> > > receieve
> > > the Path message from different interfaces with the identical SESSION and
> > > SENDER_TEMPLATE objects.  I don't see this would be possible except for the
> > > case
> > > of the software error.  It is because the SENDER_TEMPLATE should be coded
> > > with
> > > different LSP_IDs for the Protected and Detour LSPs for the same tunnel ove
> r
> > > different interfaces.  This the design intent of using different LSP_IDs to
> > > differentiate different instances of the LSPs for the same tunnel.  Am I
> > > misunderstood your statement?
> > >
> > > >> If the LSP_IDs of the protected and the detour lsp is different then the
> y
> > > can't be merged.
> >
> > [Tricci] There is already a Tunnel ID defined in the LSP_TUNNEL_IPv4_SESSION
> > object to be used to identify the tunnel (i.e. the Detour and Protected LSPs
> > would have the same Tunnel ID); and the merging can be done via the use of al
> l
> > the info from the SESSION object.  Different LSP_ID should be used to
> > differentiate the Detour and the Protected LSPs.  How else can it be done to
> > differentiate the messages for the Detour and the Protected LSPs?  What am I
> > missing?
>
> It is not necessary to use SENDER_TEMPLATE to differentiate Detour
> and Protected LSP.  The FAST_REROUTE/DETOUR objects already do the job for you.
>
> >
> > >
> > > 3. Somebody sent a previous email to suggest that the detour Path message
> > > should
> > > include the option to specify the requested LSP's bandwidth and
> > > administrative
> > > group constraint that is same as the Protected LSP, instead of locally
> > > configuring these two options at each FRR capable LSR to adopt the Protecte
> d
> > > LSP
> > > requirements or not.  I happen to agree with his view.  What do think about
> > > his
> > > suggestion?
> > >
> > > >>Since the detour lsp will be used only during reroute, the user may not
> > > want to waste the band-width. So, the user will decide the bw allocated for
> > > the detour lsp.
> >
> > [Tricci] I apologize for my mis-written of my previous question.  What I meat
> > was to have the original Path message of the Protected LSP to contain the opt
> ion
> > to specify what are the bandwidth and administrative requirements to be for t
> he
> > Detour LSP so that no configuration is needed at each PLR to decide whether i
> t
> > needs to include the bandwidth or administrative info in the Detour Path mess
> age
> > or not.   The current draft implies that such encoding decision is configured
> > locally at each PLR.  Please check it out and let me know if I am wrong.
> > Thanks....
>
> The requirements for detour are already contained in the FAST_REROUTE
> object, which is configurable by user at ingress. The requirements do
> include bw, administrative constraints, and others.
>
> THanks,
> Der-Hwa
> >
> > >
> > > Thanks in advance to your help......
> > > Tricci
> >



From owner-mpls@UU.NET  Thu Jan 10 03:15:23 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11504
	for <mpls-archive@lists.ietf.org>; Thu, 10 Jan 2002 03:15:23 -0500 (EST)
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 QQlxdy04114;
	Thu, 10 Jan 2002 06:44:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxdy09355
	for mpls-outgoing; Thu, 10 Jan 2002 06:44: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 QQlxdy09348
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 10 Jan 2002 06:44:20 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 QQlxdy21419
	for <mpls@uu.net>; Thu, 10 Jan 2002 06:43:37 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlxdy02615
	for <mpls@uu.net>; Thu, 10 Jan 2002 06:43:18 GMT
Received: (qmail 3005 invoked from network); 10 Jan 2002 06:24:13 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 10 Jan 2002 06:24:13 -0000
Received: from localhost (ranoo@localhost)
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with SMTP id MAA09603;
	Thu, 10 Jan 2002 12:11:04 +0530 (IST)
Date: Thu, 10 Jan 2002 12:11:03 +0530 (IST)
From: Ranoo Malhotra <ranoo@ee.iitb.ac.in>
To: mpls@UU.NET
cc: mpls@ee.iitb.ac.in
Subject: Multithreaded LDP Implementation (fwd)
Message-ID: <Pine.GSO.3.96.1020110120902.9349A-100000@bhairav.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

There was some problem with our institute link last night. It has been
rectified.

You should be able to download now. In case you still face some
problem, mail us.

- MPLS Group IIT Bombay (mpls@ee.iitb.ac.in)



---------- Forwarded message ----------
Date: Wed, 9 Jan 2002 18:58:46 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: mpls@uu.net
Cc: mpls-linux-general@lists.sourcforge.net, mpls@ee.iitb.ac.in
Subject: Multithreaded LDP Implementation


Hi,

At MPLS Research Group of IIT Bombay, We have implemented a multi-threaded
implementation of Label Distribution Protocol using posix threads.

This implementation is available for download and testing at following
site

http://www.ee.iitb.ac.in/uma/~mpls/

- MPLS Group IIT Bombay (mpls@ee.iitb.ac.in)








From owner-mpls@UU.NET  Thu Jan 10 04:14:10 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11961
	for <mpls-archive@lists.ietf.org>; Thu, 10 Jan 2002 04:14:10 -0500 (EST)
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 QQlxei03913;
	Thu, 10 Jan 2002 09:13:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxei20382
	for mpls-outgoing; Thu, 10 Jan 2002 09:13: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 QQlxei20337
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 10 Jan 2002 09:13: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 QQlxei23339
	for <mpls@uu.net>; Thu, 10 Jan 2002 09:13:08 GMT
Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [192.116.246.129])
	id QQlxei28891
	for <mpls@uu.net>; Thu, 10 Jan 2002 09:12:49 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Subject: TE Constraints change question
Date: Thu, 10 Jan 2002 11:13:01 +0200
Message-ID: <C7DF4400240AFB4095D98C7C6EC2A34A068489@bart.cwnt.com>
Thread-Topic: TE Constraints change question
Thread-Index: AcGZtwDYo4ZyIdQ7R9ij/bQnJh1pCg==
From: "Leonid Dubinsky" <leonid@cwnt.com>
To: <mpls@UU.NET>, <te-wg@ops.ietf.org>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11961

Hi all,

I have a question concerning the following scenario:
Consider an LSR A that is an ingress point for some LSP L1. L1 is established after CSPF calculation, and it is defined to traverse only "blue" links. Now administrator changes the color of a link along the path of L1 from "blue" to "red", and LSR A learns about it from IGP-TE updates.
The question is, should LSR A try to reopen the LSP? If there are no valid paths that satisfy the constraints of L1 currently, should L1 be torn down?

Best Regards,
    Leonid Dubinsky.


From owner-mpls@UU.NET  Thu Jan 10 16:23:26 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24117
	for <mpls-archive@lists.ietf.org>; Thu, 10 Jan 2002 16:23:26 -0500 (EST)
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 QQlxgf16071;
	Thu, 10 Jan 2002 21:22:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxgf25203
	for mpls-outgoing; Thu, 10 Jan 2002 21:22: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 QQlxgf25182
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 10 Jan 2002 21:22: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 QQlxgf11349
	for <mpls@uu.net>; Thu, 10 Jan 2002 21:21:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxgf13385
	for <mpls@uu.net>; Thu, 10 Jan 2002 21:20:44 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 QAA16210 for <mpls@uu.net>; Thu, 10 Jan 2002 16:21:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA15304 for mpls@uu.net; Thu, 10 Jan 2002 16:21:01 -0500 (EST)
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 QQlxgf25052
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 10 Jan 2002 21:20:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlxgf18737
	for <mpls@UU.NET>; Thu, 10 Jan 2002 21:19:02 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 QQlxgf10279
	for <mpls@UU.NET>; Thu, 10 Jan 2002 21:18:44 GMT
Received: from juniper.net (lookout.juniper.net [172.17.20.54])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0ALJ0698638;
	Thu, 10 Jan 2002 13:19:00 -0800 (PST)
	(envelope-from dhg@juniper.net)
Message-Id: <200201102119.g0ALJ0698638@merlot.juniper.net>
To: Tricci So <tso@caspiannetworks.com>
cc: pingpan@juniper.net, mpls@UU.NET
Subject: Re: Questions for FRR 
In-reply-to: Your message of Wed, 09 Jan 2002 15:52:44 -0800.
             <3C3CD7CB.1352719E@caspiannetworks.com> 
Date: Thu, 10 Jan 2002 13:19:00 -0800
From: Der-Hwa Gan <dhg@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk


> Der-Hwa,
> 
> Thank you for your responses.  However, somehow it seems I can't quite clearly
> describe my questions to you and Sandara.  In order to make it easier for our
> further discussion, let me rephase each question carefully to you.
> 
> 1. In the latest draft, section 3.2, it indicates that the user of RSVP_HOP object
> is needed for the "Detour" Path message.
> 
> My question is that why "hop-by-hop" info is needed for the "Detour" LSP especiall
y
> the RRO object will be returned in the Resv message.  I can see that it is needed
> for the "Protected" LSP since each PLR needs to be awared of its neighbour. But I
> don't know why it is needed for the Detour LSP.   I understand that the RSVP_HOP i
s
> mandatory for a Path message for RSVP. But, is this the case for the RSVP-TE?

It is also mandatory for RSVP-TE, that is why Detours also need to have
RSVP_HOP. THe purpose of the statement in 3.2, is to make sure you don't 
just copy RSVP_HOP from Protected LSP to Detours, its contents need some
changes.

> 
> 2. According to RFC 3209, you can use the LSP_TUNNEL_IPv4_SESSION to identify the
> ingress and the egress LERs to uniquely identify the same LSP tunnel to support
> merging;  and use the LSP_ID from the SENDER_TEMPLATE object to differentiate
> instance of the LSP for a particular tunnel.

3209 did not mandate what value should be in the 'Extended Tunnel ID' field.
It will be risky to assume that 'Extended Tunnel ID' matchs that of LSP_ID
(in SENDER_TEMPLATE) for the Protected LSP.

> 
> But in your FRR approach
> (a) All PLRs encode the SENDER_TEMPLATE with the ingress LER's IP address instead
> of the PLR's IP address to support merging
> (b) Rather than using the LSP_ID, you use the Fast_reroute and Detour objects to
> distinguish the Protected and Detour LSP requests.
> 
> (3) Finally, I am aware that the Detour Path message includes the bandwidth and th
e
> administrative group info.  But, my question is that how to let each PLR know what
> to encode in the bandwidth and administrative group objects (e.g. original
> bandwidth for Protected LSP is 1 Gb, but the bandwidth for the Detour LSP is
> degraded to 0.2 Gb)?   One way for PLR to know what the detour bandwidth to set to
> or how to select the detour path as according to the administrative group info or
> not is to configure each PLR locally.  The other way is to have the ingress LER to
> specify such information in the beginning of the Path message of the Protected
> LSP.   In fact, the latter approach make more sense since it is likely the ingress
> LER would have the policy information of the Detour requirements.  Your current FR
R
> approach will require the policy to be distributed to all PLRs.

This information is encoded in FAST_REROUTE object by ingress, and distributed
to all PLRs via Path messages. There is no need to configure each PLR
separately, in the current design.

Thanks,
Der-Hwa

> 
> I hope that this time I make my questions more clear to you.  Thanks in advance to
> your help:-o)
> 
> Tricci
> 
> 
> Der-Hwa Gan wrote:
> 
> > > Sundara,
> > >
> > > Thanks for the feedback.  Please see my inserted comments below.....
> > >
> > > Cheers,
> > > Tricci
> > >
> > > Sundara Murugan wrote:
> > >
> > > > my comments are embedded.
> > > >
> > > > -----Original Message-----
> > > > From: Tricci So [mailto:tso@caspiannetworks.com]
> > > > Sent: Monday, January 07, 2002 3:23 PM
> > > > To: dhg@juniper.net
> > > > Cc: pingpan@juniper.net; mpls@UU.NET
> > > > Subject: Questions for FRR
> > > >
> > > > Hi Der-Hwa and Ping,
> > > >
> > > > After reviewing your draft in more details, I have the following questions
> > > > regarding the detour mechanism for FRR.  Hope you can help me to clarify a
> > > > few
> > > > things.  Thanks....
> > > >
> > > > 1. According to the latest draft, section 3.2.1, your recommend the use of
> > > > the
> > > > RSVP_HOP object to be included in the detour Path message.  Since the
> > > > SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
> > > > tunnel sender address", is also being used in the Path message, why the
> > > > RSVP_HOP
> > > > object is needed to carry the same information (i.e. PLR's IP addrss)?
> > > >
> > > > >> Detour and the protected LSPs will have the same session and sender id.
> > > > Also the next-hop will send resv msg to the IP addr specified in the
> > > > RSVP_HOP oject.
> > >
> > > [Tricci] I am sorry that I don't agree.  The Detour and the Protected LSPs
> > > should  NOT have the same sender id except for the case when the PLR is the
> > > ingress LER.  In general, the PLR should include its IP address in the
> > > SENDER_TEMPLATE.  To me, it does not make sense to have the PLR to initiate a
> > > Detour LSP but to insert the ingress LER's IP address into the detour Path
> > > message.  If my observation is correct, then the RSVP_HOP object is not neede
> > d,
> > > isn't it?
> >
> > RSVP_HOP object is a hop-by-hop information, to help downstream routers
> > sending Resv message (and others) upstream. It is always needed, and it
> > should reflect the current interface being used to transmit Path message.
> >
> > As for the sender id in the detour, as specified in the current spec,
> > is the same id as protected LSP. This was intended as a necessary
> > condition for doing the merging procedure.
> >
> > But the spec is being changed due to comments received at last IETF. It
> > will be optional whether or not PLR modifies the sender id. On the MP,
> > it must perform merging procedure for LSPs with identical sender id.
> > As for LSPs with different sender id, merging becomes optional.
> >
> > >
> > > >
> > > > 2. In section 3.2.2., you have a statement mentioned that the MP may
> > > > receieve
> > > > the Path message from different interfaces with the identical SESSION and
> > > > SENDER_TEMPLATE objects.  I don't see this would be possible except for the
> > > > case
> > > > of the software error.  It is because the SENDER_TEMPLATE should be coded
> > > > with
> > > > different LSP_IDs for the Protected and Detour LSPs for the same tunnel ove
> > r
> > > > different interfaces.  This the design intent of using different LSP_IDs to
> > > > differentiate different instances of the LSPs for the same tunnel.  Am I
> > > > misunderstood your statement?
> > > >
> > > > >> If the LSP_IDs of the protected and the detour lsp is different then the
> > y
> > > > can't be merged.
> > >
> > > [Tricci] There is already a Tunnel ID defined in the LSP_TUNNEL_IPv4_SESSION
> > > object to be used to identify the tunnel (i.e. the Detour and Protected LSPs
> > > would have the same Tunnel ID); and the merging can be done via the use of al
> > l
> > > the info from the SESSION object.  Different LSP_ID should be used to
> > > differentiate the Detour and the Protected LSPs.  How else can it be done to
> > > differentiate the messages for the Detour and the Protected LSPs?  What am I
> > > missing?
> >
> > It is not necessary to use SENDER_TEMPLATE to differentiate Detour
> > and Protected LSP.  The FAST_REROUTE/DETOUR objects already do the job for you.
> >
> > >
> > > >
> > > > 3. Somebody sent a previous email to suggest that the detour Path message
> > > > should
> > > > include the option to specify the requested LSP's bandwidth and
> > > > administrative
> > > > group constraint that is same as the Protected LSP, instead of locally
> > > > configuring these two options at each FRR capable LSR to adopt the Protecte
> > d
> > > > LSP
> > > > requirements or not.  I happen to agree with his view.  What do think about
> > > > his
> > > > suggestion?
> > > >
> > > > >>Since the detour lsp will be used only during reroute, the user may not
> > > > want to waste the band-width. So, the user will decide the bw allocated for
> > > > the detour lsp.
> > >
> > > [Tricci] I apologize for my mis-written of my previous question.  What I meat
> > > was to have the original Path message of the Protected LSP to contain the opt
> > ion
> > > to specify what are the bandwidth and administrative requirements to be for t
> > he
> > > Detour LSP so that no configuration is needed at each PLR to decide whether i
> > t
> > > needs to include the bandwidth or administrative info in the Detour Path mess
> > age
> > > or not.   The current draft implies that such encoding decision is configured
> > > locally at each PLR.  Please check it out and let me know if I am wrong.
> > > Thanks....
> >
> > The requirements for detour are already contained in the FAST_REROUTE
> > object, which is configurable by user at ingress. The requirements do
> > include bw, administrative constraints, and others.
> >
> > THanks,
> > Der-Hwa
> > >
> > > >
> > > > Thanks in advance to your help......
> > > > Tricci
> > >
> 



From owner-mpls@UU.NET  Fri Jan 11 10:21:45 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17414
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 10:21:45 -0500 (EST)
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 QQlxiz04666;
	Fri, 11 Jan 2002 15:20:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxiz13801
	for mpls-outgoing; Fri, 11 Jan 2002 15:20: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 QQlxiz13796
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 15:20: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 QQlxiz10641
	for <mpls@uu.net>; Fri, 11 Jan 2002 15:17:56 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 QQlxiz29242
	for <mpls@uu.net>; Fri, 11 Jan 2002 15:18:17 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 KAA06048
	for <mpls@uu.net>; Fri, 11 Jan 2002 10:17:54 -0500 (EST)
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 KAA17683
	for <mpls@uu.net>; Fri, 11 Jan 2002 10:17:54 -0500 (EST)
Message-ID: <3C3F0282.D676D01A@marconi.com>
Date: Fri, 11 Jan 2002 10:19:30 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE Label Merge Question
References: <751B6DD7A243D511AB9F0002557C568702500572@huaweimail>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ashwin C. Prabhu wrote:
> David Charlap wrote:
>> Ashwin C. Prabhu wrote:
>>> Feng, Mark wrote:
>>>> Milk, Scott wrote:
>>>>>
>>>>> What happens to an allocated label for a second sender part of a
>>>>> session when the two sender label streams were merged somewhere
>>>>> upstream?
>>>>>
>>>>> Take the following example.  LSR1 interface to LSR2 IS merge
>>>>> capable.  LSR2 interface to LER3 IS NOT merge capable.  LER1 and
>>>>> LER2 will both request connection to LER3 and are 2 senders of
>>>>> the same session.  Assume all criteria for merging traffic are
>>>>> met.
>>>>>
>>>>>   -LER1--
>>>>>          \
>>>>>          LSR1--LSR2--LER3
>>>>>   -LER2--/
>>>>>
>>>>>        LSR1     LSR2
>>>>>       ------   ------
>>>>>       Lx->L2   L2->L1
>>>>>       Ly->L2   L2(?)->L3
>>>>>
>>>>> LER1 establishes LSP to LER3.  LER3 provides LSR2 with label L1.
>>>>> LSR2 provids LSR1 with label L2.  When LER2 as a 2nd sender of
>>>>> the same session requests the connection, LER3 includes a
>>>>> different label L3 for the second sender in RESV to LSR2 as
>>>>> LSR2 is not merge capable.  LSR2 knowing that LSR1 is merge
>>>>> capable issues the same label (L2) to LSR1 for both senders.
>>>>>
>>>>> So my question is, what happens to label L3 between LSR2 and
>>>>> LER3?  Clearly since the traffic is merged at LSR1, it will never
>>>>> be used.  This could be a problem for any number of consecutive
>>>>> non-merge capable links that follow a merge capable one.
>>>>> Obviously this problem only effects non-merge ATM links so is
>>>>> this considered an insignificant problem?
>>>>
>>>> Actually, LSR2 cannot issue the same label to LSR1 for the exact
>>>> reason.  This is mentioned in RFC3031. The idea is that the LSR
>>>> cannot have a coarser granularity than its downstream node.
>>>
>>> When LSR1 receives a label request and since it is merge capable
>>> router. It doesn't send the request further to LSR2 since it has
>>> already label from the LSR2 and for the same session, and reply
>>> with the label mapping message with the new label.  Note that at
>>> LSR1 the outsegment will have label L2 for both insegment table.
>> 
>> You are describing LDP operation, not RSVP-TE.
>> 
>> Unless I've been missing something fundamental for the past two
>> years, an RSVP Path message must propagate all the way to the
>> egress router (except when WF-style reservations are used, which
>> is not applicable for MPLS).
>>
>> This means that the LABEL_REQUEST object goes all the way to the
>> egress.
>>
>> The way I see it, if LSR1 decides to merge the two LSPs, then the
>> labels assigned by LSR2 and LER3 for one of them will be wasted.
>>
>> The solution to the wastage is for LSR2 and LER3 to also assign the
>> same label for the two LSPs, but the question then becomes how they
>> know that they should do this.  In this case, it doesn't matter
>> that LSR2 and LER3 are not merge capable - one the data plane it's
>> still one label in, and one label out.  But their choice to do this
>> will fail if LSR1 is not merge capable.
> 
> Yes i was talking about LDP.
> 
> I have still some more doubts can you please clarify it. If LDP
> can so this why can't RSVP ? Why should the label message go till
> the egress and why can't the LSR1 reply back ?
> Anyway the resources are shared by both of them ( Shared Explicit )?

First off, please don't send me personal e-mails with questions like
this.  If you have a question regarding the protocol, please ask it to
the entire working group so that eveyrbody can learn the answer.

Anyway, regarding your question, LDP and RSVP are not the same
protocol.  It is completely wrong to think that the two are doing the
same thing with different format packets.  LDP label request messages
are _NOT_ the same as Path messages.

LDP is only concerned with mapping labels on to FECs.  The eventual
existnance of LSPs through the network is an emergent property.  No
aspect of the protocol explicitly sets up an LSP across the network.

RSVP-TE is very different.  Every Path message originated is intended to
describe exactly one LSP.  It must be delivered to the egress node or
the LSP can not be eastablished.  The egress nost _MUST_ specifically
identify the sender in every Resv message that it sends.  This is a hard
requirement for FF and SE style.  It can not do this if it does not
receive a Path message from each sender.

-- David


From owner-mpls@UU.NET  Fri Jan 11 14:43:29 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27133
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 14:43:28 -0500 (EST)
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 QQlxjq05377;
	Fri, 11 Jan 2002 19:42:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxjq24150
	for mpls-outgoing; Fri, 11 Jan 2002 19:41: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 QQlxjq24143
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 19:41:50 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlxjq20523
	for <mpls@uu.net>; Fri, 11 Jan 2002 19:41:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxjq03775
	for <mpls@uu.net>; Fri, 11 Jan 2002 19:41:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26497 for <mpls@uu.net>; Fri, 11 Jan 2002 14:41:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA10567 for mpls@uu.net; Fri, 11 Jan 2002 14:41:01 -0500 (EST)
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 QQlxjq23930
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 19:39:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlxjq26464
	for <mpls@uu.net>; Fri, 11 Jan 2002 19:39:13 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxjq01234
	for <mpls@uu.net>; Fri, 11 Jan 2002 19:39:13 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26288 for <mpls@uu.net>; Fri, 11 Jan 2002 14:39:12 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA19959 for <mpls@uu.net>; Fri, 11 Jan 2002 14:39:12 -0500 (EST)
Message-Id: <200201111939.OAA19959@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: MPLS WG Minutes
Date: Fri, 11 Jan 2002 14:39:12 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Attached are the minutes.

...George

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



======================================================================
MPLS WG meeting minutes       Salt Lake City                  12/10/01
======================================================================

1.  "MTU Signalling Extensions for LDP" 
      <draft-black-ldp-mtu-extensions-02.txt>

      Kireeti Kompella 

There was a very brief prsentation to update the workgroup
on changes since the last document, concluding with a request 
to go to last call.

Discussion:

Pradgesh: This draft only addresses a part of the problem: MTU
discovery for LDP. What do we do for RSVP?
Kireeti: RSVP is done.
Prad: why do we have a separate draft?
K: 2 drafts are okay.
Lou: The RSVP info is in the original draft.

K: George, can we check the room for consensus for last call? What
does the room think?

Room: More for than against, but George wants to see a little more
enthusiasm. George will issue a WG last call shortly.


2.  "TTL Processing in MPLS Networks" 
      <draft-agarwal-mpls-ttl-01.txt>

    Puneet Agarwal 

Puneet: Made a short presentation, followed by a request to adopt the
draft as WG document.

George: Do people in the room believe this draft is a good idea. Do I
see any nods for yet/no?  Some clarifications on this would help for
interoperability of this. There seems to be a consensus for such
documents. 

Anonymous: 

Provides useful clarification, but would like to know how you know 
which model of TTL decrment to use?  

Puneet: Signaling is out of the scope of this document. If the group
wants to address this, the chair needs to address this.

Scott Bradner: The documents going into being WG documents need to be
items that are in the charter, or the charter needs to be re-spun to
change. We need more WG support short for this document before it can
be accepted.

George: This document is just a document to clarify how things are
being done.  It does not represent new protocol work.
We decided it would be informational in London.

The document was accepted as a WG document.


3.  Restart/Recovery

Three drafts were presented on Restart/Recovery, adjudication was
withheld until all were presented.

    "Graceful Restart Mechanism for BGP with MPLS" 
     <draft-rekhter-bgp-mpls-restart-00.txt> 

    Yakov Rekhter 

Yakov:  Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: What is the required restart time.

Yakov: User configurable.

Anonymous: BGP has a specific timer.

Y: You should look at the BGP proposal; whatever BGP does this does too.

Y: Any other questions?


    "Graceful Restart Mechanism for LDP" 
     <draft-leelanivas-ldp-restart-01.txt>

     Yakov Rekhter

Yakov: Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: Why previous BGP restart should be done in IDR?

Y: Distribution of BGP labels has been done in this WG, so we should
do this here.


    "Graceful Restart Mechanism for LDP" 
     <draft-smith-mpls-ldp-restart-00.txt>

     Andy Malis / Toby Smith 

Toby: Presentation. Detailed difference between this proposal and Yakov's.

Anonymous: Discuss different proposals?

George: Drafts have not been accepted, so we need to get to the bottom
of that. Lets discuss this for a few minutes.

Eric Gray: This draft does not compete with Yakov's draft. Yakov's is
focused on BGP MPLS. This draft proposes a difference between what is
in the IESG queue for a year now.  The LDP fault tolerance draft had
looked at stuff like this drafts. The problems are that these
assumptions do not work in all deployments unless all LSRs agree to do
this fault tolerant mode. It doesn't do any good to support any LSPs
that are not supported in any other segments in the network.

Andy: First comment: this only goes on between LDP peers, so if you
are running lDP throughout the network and you have an outage between
two peers, those should come up okay and should not affect other peers
elsewhere. Comment two: it is all or none.

Luca: I would like to see these approaches get together. 

Andy: We already have plans to meet with the other authors.

Anonymous: The assumption that was made that checkpoint information
can be kept can be a problem with regard to resources.

Andy: This is a problem with all of the approaches.

Phil: After querying about the number of implementations of the
existing draft, I have not heard of any problems with this
approach. There are apparently 2 implementations of the existing fault
tolerant draft.

Andy: There is no problem with the difficulty to implement these or
the new approaches; just the implementation complexity.

Kireeti: This draft is nice because it is light, but I am afraid that
two end points of the connection can loose state. If you exchange
control messages, you are assured that things are in sync.  The IDR
approach does exchange control messages. Just an important point to
understand.

Anonymous: A few points. The BGP restart drafts pretty much learn
their state from the network. With this approach, you have the
possibility of loosing state. The main difference between the two
approaches is that one approach caches state, and the other doesn't.

Andy: We considered that LDP runs over TCP, so we have a reliable and
sequenced path. You know that the receiver knows that they received
control messages. We are pretty clear that things should work pretty
well. All should read the current draft, and send email to the list.

George: Requested that the group having lunch please send email to the
        list.


4.  Fast Reoute

    "Fast Reroute Techniques in RSVP-TE" 
      <draft-ping-rsvp-fastreroute-00.txt>

      Ping Pan 

Ping: Presentation

George: Would like this accepted as a WG document?

Ping: Yes.

Question: I could not figure out how one approach complements the others.

Ping: We would like to combine the request mechanism from all drafts,
so that any router in the network based on local configuration can
construct a back-up path.  We haven't finished integrating these.

Question: I think the case when the backup path LSP fails behavior is
not specified. There should be recommendations/considerations of what
should be done. Now, if the backup LSP fails what do we do?

Question2: Generalizing the applicability for this (i.e.:
bi-directional LSPs)?

Ping: I think in the case of GMPLS this is already done.


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

     Alia Atlas 

Note: Alia is also one of the co-authors of the draft presented by
Ping.  Her draft is intended to allow some of the open issues in that
draft to be aired before the workgroup.

Alia: Presentation

A lively discusion between Ping and Alia ensued, particularly over the
issue of make-before-break on backup tunnels.

George: Any objection to accepting the Ping draft as a WG document?
Note that the issues that Alia raised should contunied to be disussed
on the mailing list.  How many people think this should be added to
the WG?

George: The I's have it.   


5.  "Multiprotocol Label Switching (MPLS) Management Overview" 
     <draft-ietf-mpls-mgmt-overview-00.txt>

     Tom Nadeau 

George:  This draft was requested by ADs.  It 
shows relationship of various MIBs.

Tom: Presentation

Kireeti: Include TE-MIB?

Tom: Yes.

George: WG draft?

Group: Lots of hands. No objections.

George: Draft will be last called after IESG process on MPLS
LSR/TE/LDP/FTN MIBs has progressed and any changes that emerge from
that process are inculded.


6.  "IPv6 Traffic Engineering Tunnel" 
     <draft-ishii-ipv6-te-tunnel-00.txt>

     Hiroki Ishibashi 

George: This next presentation is out of the scope of the WG, and is more
of an application of MPLS.

Hiroki: Presentation.

Francois: This work belongs to the NG-trans WG. There is a draft
there for this work already. LSPs are constraint based routed. There
is a lot of overlap between this draft and the draft being progressed
there.

George: (to Hiroki) The point is that the discussion belongs in the
other WG, not here.


7.  Document Status

George: Presented drafts that are in IESG last call, are on IESG queue.

Yakov: There are some changes to the unnumbered draft for CR-LDP that
 need to be done.

George: Any comments on mpls-te-feedback-draft

Don Fedyk: We were looking to progress this document.

George: I will send it to last call.

We now want to shift gears and talk about which RFCs that can be
progressed onto the standards track.  Scott, please comment on
architecture document.

Scott: Beats me.  In general, architecture documents are not standards
track documents.

George: Enaps draft. There are quite a few implementations of that
that interoperate. What we need is for people to collect interop
information.

Lou: a while back when this draft was coming out, there were MTU
discovery interop issues.  The discussion was that when it came time
to advance the document until these issues are addressed.

George: Dig up old email and start a new discussion. 

Lou: Hopefully it will be just what we agreed to 2 years ago and put
it into the draft.

George: LDP draft. Has many different flavors. In order to progress,
only those things for which there are 2 or more interop
implementations can be progressed, and the rest removed. A survey
effort needs to happen and documentation of what is there and what is
not.

Joel Halpern: Are you going to make the list or is someone else?

George: I am not going to do it. Volunteers? Loa, you showed interest
in this in the past.

Loa: I will help out if Bob Thomas doesn't have time.

George: Technology-specific drafts (ATM). There are multiple
implementations, not sure about interop of them. Need to get to the
bottom of this. The (FR) drafts: don't know of any implementations, so
it will stay proposed (forever).  BGP draft: there are interoperable
implementations of this, so this can be progressed.  I will send the
list of these drafts/status to the list.






From owner-mpls@UU.NET  Fri Jan 11 15:14:25 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28017
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 15:14:25 -0500 (EST)
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 QQlxjs18685;
	Fri, 11 Jan 2002 20:13:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxjs16710
	for mpls-outgoing; Fri, 11 Jan 2002 20:13: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 QQlxjs16700
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 20:13: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 QQlxjs27185
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:11:51 GMT
Received: from zrc2s0jx.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zrc2s0jx.nortelnetworks.com [47.103.122.112])
	id QQlxjs05613
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:11:50 GMT
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0BKBhb12109
	for <mpls@UU.NET>; Fri, 11 Jan 2002 14:11:44 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <ZWHJSF3S>; Fri, 11 Jan 2002 12:11:39 -0800
Message-ID: <5D630265EF50D311ABB60008C7917DB6079CCAB3@zsc4c004.us.nortel.com>
From: "Sundeep Singatwaria"<ssingatw@nortelnetworks.com>
To: mpls@UU.NET
Subject: pulledUnconditional / pulledConditional
Date: Fri, 11 Jan 2002 12:11:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19ADC.2C6EB520"
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_01C19ADC.2C6EB520
Content-Type: text/plain;
	charset="iso-8859-1"


Could some explain this one -

From the MPLS Architecture rfc -

----
Let Rd be an LSR.  Suppose that:

      1. X is an address prefix in Rd's routing table

      2. Ru is a label distribution peer of Rd with respect to X

      3. Ru has explicitly requested that Rd bind a label to X and
         distribute the binding to Ru

      4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
         Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
         Rn has bound a label to X and distributed that binding to Rd

   Then as soon as these conditions all hold, Rd should bind a label to
   X and distribute that binding to Ru.  Note that if X is not in Rd's
   routing table and a binding for X is not obtainable via Rd's next hop
   for X, 
**********
   or if Rd is not a label distribution peer of Ru with respect
   to X, 
**********
   then Rd must inform Ru that it cannot provide a binding at this
   time.
-----

How does a router Rd decide that it is not a label distribution peer 
of Ru with respect to X ? 

Tx.
Sundeep

------_=_NextPart_001_01C19ADC.2C6EB520
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.2654.89">
<TITLE>pulledUnconditional / pulledConditional</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Could some explain this one -</FONT>
</P>

<P><FONT SIZE=2>From the MPLS Architecture rfc -</FONT>
</P>

<P><FONT SIZE=2>----</FONT>
<BR><FONT SIZE=2>Let Rd be an LSR.&nbsp; Suppose that:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. X is an address prefix in Rd's routing table</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. Ru is a label distribution peer of Rd with respect to X</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. Ru has explicitly requested that Rd bind a label to X and</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; distribute the binding to Ru</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rn has bound a label to X and distributed that binding to Rd</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Then as soon as these conditions all hold, Rd should bind a label to</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; X and distribute that binding to Ru.&nbsp; Note that if X is not in Rd's</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; routing table and a binding for X is not obtainable via Rd's next hop</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; for X, </FONT>
<BR><FONT SIZE=2>**********</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; or if Rd is not a label distribution peer of Ru with respect</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; to X, </FONT>
<BR><FONT SIZE=2>**********</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; then Rd must inform Ru that it cannot provide a binding at this</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; time.</FONT>
<BR><FONT SIZE=2>-----</FONT>
</P>

<P><FONT SIZE=2>How does a router Rd decide that it is not a label distribution peer </FONT>
<BR><FONT SIZE=2>of Ru with respect to X ? </FONT>
</P>

<P><FONT SIZE=2>Tx.</FONT>
<BR><FONT SIZE=2>Sundeep</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19ADC.2C6EB520--


From owner-mpls@UU.NET  Fri Jan 11 15:19:23 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28167
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 15:19:23 -0500 (EST)
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 QQlxjt15498;
	Fri, 11 Jan 2002 20:18:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxjt17422
	for mpls-outgoing; Fri, 11 Jan 2002 20:18:37 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 QQlxjt17417
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 20:18: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 QQlxjt28166
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:17:28 GMT
Received: from c2.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.118.32.25])
	id QQlxjt13464
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:17:28 GMT
Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0)
	id PAA04427; Fri, 11 Jan 2002 15:17:27 -0500 (EST)
Received: from w2k04exg01.ciena.com(10.4.40.46) by c2.ciena.com via smap (V2.0)
	id xma004353; Fri, 11 Jan 02 15:17:05 -0500
Received: by w2k04exg01.ciena.com with Internet Mail Service (5.5.2653.19)
	id <YJBY20FM>; Fri, 11 Jan 2002 15:14:55 -0500
Message-ID: <5744240BDA524C41A9D4E9C2780E950A256EFC@w2k04exg01.ciena.com>
From: "Kapur, Rajan" <RKapur@ciena.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Questions about LMP
Date: Fri, 11 Jan 2002 15:14:54 -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,

Some questions came to mind after reviewing the draft-ietf-ccamp-lmp-00.txt and draft-fredette-lmp-wdm-02.txt drafts.  I would appreciate it if somebody could provide answers to the following questions:

1. Are there currently any provisions for send proprietary data in LMP? i.e, Is there a way in LMP to define proprietary TLV's or can a set of values be reserved for defining proprietary TLV's?
2. Are the type values for the TLV objects in lmp-wdm published somewhere?

Thanks,
Raj Kapur




From owner-mpls@UU.NET  Fri Jan 11 16:01:58 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29487
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 16:01:58 -0500 (EST)
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 QQlxjw25171;
	Fri, 11 Jan 2002 21:01:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxjw24378
	for mpls-outgoing; Fri, 11 Jan 2002 21:00:52 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlxjw23700
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 21:00:42 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 QQlxjw21348
	for <mpls@UU.NET>; Fri, 11 Jan 2002 21:00:04 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 QQlxjv20810
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:59:57 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id UAA07053
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:59:57 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011113005600375
 ; Fri, 11 Jan 2002 13:00:56 -0800
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <C4MFTPQ0>; Fri, 11 Jan 2002 12:59:56 -0800
Message-ID: <AA5ED351DFA4D5118A2C00508B68BB7E03FFD229@orsmsx109.jf.intel.com>
From: "Bakshi, Sanjay" <sanjay.bakshi@intel.com>
To: "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>,
        "'mpls@UU.NET'" <mpls@UU.NET>
Subject: generic label space question
Date: Fri, 11 Jan 2002 12:59:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19AE2.EBD6BDD0"
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_01C19AE2.EBD6BDD0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
Is it ok for an LDP implementation to only support a sub-set of 20bit label
space?
RFC3036 does not talk about it but do the LDP implementations available from
various vendors allow such a configuration?
thanks
--sanjay
 

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

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


<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN 
class=424235420-11012002>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN class=424235420-11012002>Is it 
ok for an LDP implementation to only support a sub-set of 20bit label 
space?</SPAN></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN 
class=424235420-11012002>RFC3036 does&nbsp;not talk about it but do the LDP 
implementations available from various vendors allow such a 
configuration?</SPAN></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN 
class=424235420-11012002>thanks</SPAN></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN 
class=424235420-11012002>--sanjay</SPAN></FONT></DIV>
<DIV><FONT color=#ff00ff face=Arial size=2><SPAN 
class=424235420-11012002></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C19AE2.EBD6BDD0--


From owner-mpls@UU.NET  Fri Jan 11 17:07:57 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01481
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 17:07:57 -0500 (EST)
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 QQlxjz12799;
	Fri, 11 Jan 2002 21:57:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxjz15323
	for mpls-outgoing; Fri, 11 Jan 2002 21:57:02 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 QQlxjz15315
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 21:57:00 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 QQlxjz03419
	for <mpls@UU.NET>; Fri, 11 Jan 2002 21:56:41 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 QQlxjz11831
	for <mpls@UU.NET>; Fri, 11 Jan 2002 21:56: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 QAA17104;
	Fri, 11 Jan 2002 16:56:38 -0500 (EST)
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 QAA19232;
	Fri, 11 Jan 2002 16:56:40 -0500 (EST)
Message-ID: <3C3F5FFB.F3D24C51@marconi.com>
Date: Fri, 11 Jan 2002 16:58:19 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>
CC: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Re: generic label space question
References: <AA5ED351DFA4D5118A2C00508B68BB7E03FFD229@orsmsx109.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Bakshi, Sanjay" wrote:
> 
> Is it ok for an LDP implementation to only support a sub-set of
> 20bit label space?
> RFC3036 does not talk about it but do the LDP implementations
> available from various vendors allow such a configuration?
> thanks

With respect to the labels that you generate and send to your upstream
peer (via Label Mapping messages), you can choose to restrict yourself
to a subset if you like.

With respect to the labels you receive, I think you have to accept
whatever values you get.  The problem is that you must somehow tell the
downstream router what range is acceptible, so that it will choose a
label from that range.

If you have an ATM or Frame Relay interface, you can specify the
acceptible range using the ATM Session Parameters or FR Session
Parameters TLV.  Unfortunately, there doesn't appear to be any TLV for
signaling label range on generic interfaces.

This means that if you don't support the entire 20-bit range on a
generic interface, you will have to come up with some non-standard way
of getting the downstream router to only generate labels in your range.

-- David


From owner-mpls@UU.NET  Fri Jan 11 17:13:48 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01643
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 17:13:47 -0500 (EST)
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 QQlxka04727;
	Fri, 11 Jan 2002 22:03:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxka24972
	for mpls-outgoing; Fri, 11 Jan 2002 22:02: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 QQlxka24581
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 22:02:38 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 QQlxka20061
	for <mpls@uu.net>; Fri, 11 Jan 2002 22:02:30 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxka03760
	for <mpls@uu.net>; Fri, 11 Jan 2002 22:02:30 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 RAA04304 for <mpls@uu.net>; Fri, 11 Jan 2002 17:02:30 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13644 for mpls@uu.net; Fri, 11 Jan 2002 15:34:01 -0500 (EST)
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 QQlxju18923
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 20:33:45 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 QQlxju17299
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:32:39 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 QQlxju05699
	for <mpls@UU.NET>; Fri, 11 Jan 2002 20:32:37 GMT
Received: (qmail 22340 invoked by uid 104); 11 Jan 2002 20:32:36 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4180. . Clean. Processed in 6.601991 secs); 11 Jan 2002 20:32:37 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 11 Jan 2002 20:32:26 -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 g0BKWMm05757;
	Fri, 11 Jan 2002 12:32:23 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2653.19)
	id <XNRN0FQV>; Fri, 11 Jan 2002 12:32:23 -0800
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A4F3@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'George Swallow'" <swallow@cisco.com>, mpls@UU.NET
Subject: RE: MPLS WG Minutes
Date: Fri, 11 Jan 2002 12:32:16 -0800
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 George,

I believe I made a comment in support of the second item (TTL processing in MPLS networks), which is not captured. My comments were:

"I, as one of the authors of draft-MPLS-Diffserv-09, feel that this work is needed as a supplement to draft-MPLS-Diffserv-09, which addresses practical uncertainties that have been observed during implementations of various tunneling modes".

Thanks,
-Shahram Davari  

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Friday, January 11, 2002 2:39 PM
> To: mpls@UU.NET
> Subject: MPLS WG Minutes
> 
> 
> Attached are the minutes.
> 
> ...George
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 497-8143
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824
> 
> 
> 
> ======================================================================
> MPLS WG meeting minutes       Salt Lake City                  12/10/01
> ======================================================================
> 
> 1.  "MTU Signalling Extensions for LDP" 
>       <draft-black-ldp-mtu-extensions-02.txt>
> 
>       Kireeti Kompella 
> 
> There was a very brief prsentation to update the workgroup
> on changes since the last document, concluding with a request 
> to go to last call.
> 
> Discussion:
> 
> Pradgesh: This draft only addresses a part of the problem: MTU
> discovery for LDP. What do we do for RSVP?
> Kireeti: RSVP is done.
> Prad: why do we have a separate draft?
> K: 2 drafts are okay.
> Lou: The RSVP info is in the original draft.
> 
> K: George, can we check the room for consensus for last call? What
> does the room think?
> 
> Room: More for than against, but George wants to see a little more
> enthusiasm. George will issue a WG last call shortly.
> 
> 
> 2.  "TTL Processing in MPLS Networks" 
>       <draft-agarwal-mpls-ttl-01.txt>
> 
>     Puneet Agarwal 
> 
> Puneet: Made a short presentation, followed by a request to adopt the
> draft as WG document.
> 
> George: Do people in the room believe this draft is a good idea. Do I
> see any nods for yet/no?  Some clarifications on this would help for
> interoperability of this. There seems to be a consensus for such
> documents. 
> 
> Anonymous: 
> 
> Provides useful clarification, but would like to know how you know 
> which model of TTL decrment to use?  
> 
> Puneet: Signaling is out of the scope of this document. If the group
> wants to address this, the chair needs to address this.
> 
> Scott Bradner: The documents going into being WG documents need to be
> items that are in the charter, or the charter needs to be re-spun to
> change. We need more WG support short for this document before it can
> be accepted.
> 
> George: This document is just a document to clarify how things are
> being done.  It does not represent new protocol work.
> We decided it would be informational in London.
> 
> The document was accepted as a WG document.
> 
> 
> 3.  Restart/Recovery
> 
> Three drafts were presented on Restart/Recovery, adjudication was
> withheld until all were presented.
> 
>     "Graceful Restart Mechanism for BGP with MPLS" 
>      <draft-rekhter-bgp-mpls-restart-00.txt> 
> 
>     Yakov Rekhter 
> 
> Yakov:  Made a short presentation, followed by a request to adopt the
> draft as WG document.
> 
> Anonymous: What is the required restart time.
> 
> Yakov: User configurable.
> 
> Anonymous: BGP has a specific timer.
> 
> Y: You should look at the BGP proposal; whatever BGP does 
> this does too.
> 
> Y: Any other questions?
> 
> 
>     "Graceful Restart Mechanism for LDP" 
>      <draft-leelanivas-ldp-restart-01.txt>
> 
>      Yakov Rekhter
> 
> Yakov: Made a short presentation, followed by a request to adopt the
> draft as WG document.
> 
> Anonymous: Why previous BGP restart should be done in IDR?
> 
> Y: Distribution of BGP labels has been done in this WG, so we should
> do this here.
> 
> 
>     "Graceful Restart Mechanism for LDP" 
>      <draft-smith-mpls-ldp-restart-00.txt>
> 
>      Andy Malis / Toby Smith 
> 
> Toby: Presentation. Detailed difference between this proposal 
> and Yakov's.
> 
> Anonymous: Discuss different proposals?
> 
> George: Drafts have not been accepted, so we need to get to the bottom
> of that. Lets discuss this for a few minutes.
> 
> Eric Gray: This draft does not compete with Yakov's draft. Yakov's is
> focused on BGP MPLS. This draft proposes a difference between what is
> in the IESG queue for a year now.  The LDP fault tolerance draft had
> looked at stuff like this drafts. The problems are that these
> assumptions do not work in all deployments unless all LSRs agree to do
> this fault tolerant mode. It doesn't do any good to support any LSPs
> that are not supported in any other segments in the network.
> 
> Andy: First comment: this only goes on between LDP peers, so if you
> are running lDP throughout the network and you have an outage between
> two peers, those should come up okay and should not affect other peers
> elsewhere. Comment two: it is all or none.
> 
> Luca: I would like to see these approaches get together. 
> 
> Andy: We already have plans to meet with the other authors.
> 
> Anonymous: The assumption that was made that checkpoint information
> can be kept can be a problem with regard to resources.
> 
> Andy: This is a problem with all of the approaches.
> 
> Phil: After querying about the number of implementations of the
> existing draft, I have not heard of any problems with this
> approach. There are apparently 2 implementations of the existing fault
> tolerant draft.
> 
> Andy: There is no problem with the difficulty to implement these or
> the new approaches; just the implementation complexity.
> 
> Kireeti: This draft is nice because it is light, but I am afraid that
> two end points of the connection can loose state. If you exchange
> control messages, you are assured that things are in sync.  The IDR
> approach does exchange control messages. Just an important point to
> understand.
> 
> Anonymous: A few points. The BGP restart drafts pretty much learn
> their state from the network. With this approach, you have the
> possibility of loosing state. The main difference between the two
> approaches is that one approach caches state, and the other doesn't.
> 
> Andy: We considered that LDP runs over TCP, so we have a reliable and
> sequenced path. You know that the receiver knows that they received
> control messages. We are pretty clear that things should work pretty
> well. All should read the current draft, and send email to the list.
> 
> George: Requested that the group having lunch please send email to the
>         list.
> 
> 
> 4.  Fast Reoute
> 
>     "Fast Reroute Techniques in RSVP-TE" 
>       <draft-ping-rsvp-fastreroute-00.txt>
> 
>       Ping Pan 
> 
> Ping: Presentation
> 
> George: Would like this accepted as a WG document?
> 
> Ping: Yes.
> 
> Question: I could not figure out how one approach complements 
> the others.
> 
> Ping: We would like to combine the request mechanism from all drafts,
> so that any router in the network based on local configuration can
> construct a back-up path.  We haven't finished integrating these.
> 
> Question: I think the case when the backup path LSP fails behavior is
> not specified. There should be recommendations/considerations of what
> should be done. Now, if the backup LSP fails what do we do?
> 
> Question2: Generalizing the applicability for this (i.e.:
> bi-directional LSPs)?
> 
> Ping: I think in the case of GMPLS this is already done.
> 
> 
>     "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute" 
>      <draft-atlas-rsvp-local-protect-interop-02.txt>
> 
>      Alia Atlas 
> 
> Note: Alia is also one of the co-authors of the draft presented by
> Ping.  Her draft is intended to allow some of the open issues in that
> draft to be aired before the workgroup.
> 
> Alia: Presentation
> 
> A lively discusion between Ping and Alia ensued, particularly over the
> issue of make-before-break on backup tunnels.
> 
> George: Any objection to accepting the Ping draft as a WG document?
> Note that the issues that Alia raised should contunied to be disussed
> on the mailing list.  How many people think this should be added to
> the WG?
> 
> George: The I's have it.   
> 
> 
> 5.  "Multiprotocol Label Switching (MPLS) Management Overview" 
>      <draft-ietf-mpls-mgmt-overview-00.txt>
> 
>      Tom Nadeau 
> 
> George:  This draft was requested by ADs.  It 
> shows relationship of various MIBs.
> 
> Tom: Presentation
> 
> Kireeti: Include TE-MIB?
> 
> Tom: Yes.
> 
> George: WG draft?
> 
> Group: Lots of hands. No objections.
> 
> George: Draft will be last called after IESG process on MPLS
> LSR/TE/LDP/FTN MIBs has progressed and any changes that emerge from
> that process are inculded.
> 
> 
> 6.  "IPv6 Traffic Engineering Tunnel" 
>      <draft-ishii-ipv6-te-tunnel-00.txt>
> 
>      Hiroki Ishibashi 
> 
> George: This next presentation is out of the scope of the WG, 
> and is more
> of an application of MPLS.
> 
> Hiroki: Presentation.
> 
> Francois: This work belongs to the NG-trans WG. There is a draft
> there for this work already. LSPs are constraint based routed. There
> is a lot of overlap between this draft and the draft being progressed
> there.
> 
> George: (to Hiroki) The point is that the discussion belongs in the
> other WG, not here.
> 
> 
> 7.  Document Status
> 
> George: Presented drafts that are in IESG last call, are on 
> IESG queue.
> 
> Yakov: There are some changes to the unnumbered draft for CR-LDP that
>  need to be done.
> 
> George: Any comments on mpls-te-feedback-draft
> 
> Don Fedyk: We were looking to progress this document.
> 
> George: I will send it to last call.
> 
> We now want to shift gears and talk about which RFCs that can be
> progressed onto the standards track.  Scott, please comment on
> architecture document.
> 
> Scott: Beats me.  In general, architecture documents are not standards
> track documents.
> 
> George: Enaps draft. There are quite a few implementations of that
> that interoperate. What we need is for people to collect interop
> information.
> 
> Lou: a while back when this draft was coming out, there were MTU
> discovery interop issues.  The discussion was that when it came time
> to advance the document until these issues are addressed.
> 
> George: Dig up old email and start a new discussion. 
> 
> Lou: Hopefully it will be just what we agreed to 2 years ago and put
> it into the draft.
> 
> George: LDP draft. Has many different flavors. In order to progress,
> only those things for which there are 2 or more interop
> implementations can be progressed, and the rest removed. A survey
> effort needs to happen and documentation of what is there and what is
> not.
> 
> Joel Halpern: Are you going to make the list or is someone else?
> 
> George: I am not going to do it. Volunteers? Loa, you showed interest
> in this in the past.
> 
> Loa: I will help out if Bob Thomas doesn't have time.
> 
> George: Technology-specific drafts (ATM). There are multiple
> implementations, not sure about interop of them. Need to get to the
> bottom of this. The (FR) drafts: don't know of any implementations, so
> it will stay proposed (forever).  BGP draft: there are interoperable
> implementations of this, so this can be progressed.  I will send the
> list of these drafts/status to the list.
> 
> 
> 
> 



From owner-mpls@UU.NET  Fri Jan 11 18:13:14 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02723
	for <mpls-archive@lists.ietf.org>; Fri, 11 Jan 2002 18:13:14 -0500 (EST)
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 QQlxke02711;
	Fri, 11 Jan 2002 23:11:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxke01317
	for mpls-outgoing; Fri, 11 Jan 2002 23:11: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 QQlxke01286
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 11 Jan 2002 23:11: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 QQlxke22440
	for <mpls@UU.NET>; Fri, 11 Jan 2002 23:10:56 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlxke01519
	for <mpls@UU.NET>; Fri, 11 Jan 2002 23:10:54 GMT
Received: (qmail 21739 invoked from network); 11 Jan 2002 22:51:25 -0000
Received: from mailscan2.iitb.ernet.in (HELO iitb.ac.in) (144.16.108.202)
  by mailhost.iitb.ac.in with SMTP; 11 Jan 2002 22:51:25 -0000
X-SMTP-Sending-IP: 144.16.116.2
Received: from akash.it.iitb.ac.in by iitb.ac.in ; 12 Jan 2002 04:40:34 +0530
Received: from cygnus.it.iitb.ac.in (cygnus.it.iitb.ac.in [144.16.116.9])
	by akash.it.iitb.ac.in (8.11.2/8.8.8) with ESMTP id g0BNAXF20893;
	Sat, 12 Jan 2002 04:40:33 +0530
Received: from localhost (praveen@localhost)
	by cygnus.it.iitb.ac.in (8.11.0/8.8.7) with ESMTP id g0BNATE18798;
	Sat, 12 Jan 2002 04:40:29 +0530
Date: Sat, 12 Jan 2002 04:40:29 +0530 (IST)
From: Praveen Kumar <praveen@it.iitb.ac.in>
To: David Charlap <David.Charlap@marconi.com>
cc: "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>,
        "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Re: generic label space question
In-Reply-To: <3C3F5FFB.F3D24C51@marconi.com>
Message-ID: <Pine.LNX.4.21.0201120426550.17789-100000@cygnus.it.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Some times you may need to accept what you get. This is in case your
downstream don't have free labels within your required range. Why do you
need to restrict to small subset of 20bit, other than space/time?

On Fri, 11 Jan 2002, David Charlap wrote:

> "Bakshi, Sanjay" wrote:
> > 
> > Is it ok for an LDP implementation to only support a sub-set of
> > 20bit label space?
> > RFC3036 does not talk about it but do the LDP implementations
> > available from various vendors allow such a configuration?
> > thanks
> 
> With respect to the labels that you generate and send to your upstream
> peer (via Label Mapping messages), you can choose to restrict yourself
> to a subset if you like.
> 
> With respect to the labels you receive, I think you have to accept
> whatever values you get.  The problem is that you must somehow tell the
> downstream router what range is acceptible, so that it will choose a
> label from that range.
> 
> If you have an ATM or Frame Relay interface, you can specify the
> acceptible range using the ATM Session Parameters or FR Session
> Parameters TLV.  Unfortunately, there doesn't appear to be any TLV for
> signaling label range on generic interfaces.
> 
> This means that if you don't support the entire 20-bit range on a
> generic interface, you will have to come up with some non-standard way
> of getting the downstream router to only generate labels in your range.
> 
> -- David
> 

-- 
S.Praveen Kumar
M.Tech,KReSIT
IIT-Bombay
web: http://www.it.iitb.ac.in/~praveen




From owner-mpls@UU.NET  Sat Jan 12 04:26:47 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18878
	for <mpls-archive@lists.ietf.org>; Sat, 12 Jan 2002 04:26:47 -0500 (EST)
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 QQlxlt20941;
	Sat, 12 Jan 2002 09:26:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxlt05636
	for mpls-outgoing; Sat, 12 Jan 2002 09:25: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 QQlxlt05629
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 12 Jan 2002 09:25: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 QQlxlt03398
	for <mpls@UU.NET>; Sat, 12 Jan 2002 09:25:26 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f178.law8.hotmail.com [216.33.241.178])
	id QQlxlt19936
	for <mpls@UU.NET>; Sat, 12 Jan 2002 09:25:26 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 12 Jan 2002 01:25:25 -0800
Received: from 192.11.188.113 by lw8fd.law8.hotmail.msn.com with HTTP;
	Sat, 12 Jan 2002 09:25:25 GMT
X-Originating-IP: [192.11.188.113]
From: "Ashish Vyas" <ashish_vyas@hotmail.com>
To: mpls@UU.NET
Subject: regarding label-stack in MPLS-ATM
Date: Sat, 12 Jan 2002 14:55:25 +0530
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <F178K56n8oXeYg6E64w000076e8@hotmail.com>
X-OriginalArrivalTime: 12 Jan 2002 09:25:25.0966 (UTC) FILETIME=[116356E0:01C19B4B]
Sender: owner-mpls@UU.NET
Precedence: bulk

<html><div style='background-color:'><DIV>
<DIV>
<P>Hi all,</P>
<P>In MPLS-IP the lable-stack can be maintained using multiple "Shim-Headers". </P>
<P>But how does label-stack ( of depth &gt;2) is maintained in case of "MPLS over ATM"?&nbsp;</P>
<P>&nbsp;</P>
<P>Regards</P>
<P>Ashish Vyas<BR>&nbsp;</P></DIV></DIV></div><br clear=all><hr>Send and receive Hotmail on your mobile device: <a href='http://go.msn.com/bql/hmtag2_etl_EN.asp'>Click Here</a><br></html>


From owner-mpls@UU.NET  Sat Jan 12 04:44:50 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18987
	for <mpls-archive@lists.ietf.org>; Sat, 12 Jan 2002 04:44:49 -0500 (EST)
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 QQlxlu15496;
	Sat, 12 Jan 2002 09:44:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxlu06858
	for mpls-outgoing; Sat, 12 Jan 2002 09:44: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 QQlxlu06850
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 12 Jan 2002 09:44:02 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 QQlxlu18379
	for <mpls@UU.NET>; Sat, 12 Jan 2002 09:42:57 GMT
Received: from mailhost.iitb.ac.in by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlxlu26366
	for <mpls@UU.NET>; Sat, 12 Jan 2002 09:42:56 GMT
Received: (qmail 14888 invoked from network); 12 Jan 2002 09:23:36 -0000
Received: from mailscan2.iitb.ernet.in (HELO iitb.ac.in) (144.16.108.202)
  by mailhost.iitb.ac.in with SMTP; 12 Jan 2002 09:23:36 -0000
X-SMTP-Sending-IP: 144.16.116.2
Received: from akash.it.iitb.ac.in by iitb.ac.in ; 12 Jan 2002 15:12:44 +0530
Received: from cygnus.it.iitb.ac.in (cygnus.it.iitb.ac.in [144.16.116.9])
	by akash.it.iitb.ac.in (8.11.2/8.8.8) with ESMTP id g0C9ghF28355;
	Sat, 12 Jan 2002 15:12:43 +0530
Received: from localhost (praveen@localhost)
	by cygnus.it.iitb.ac.in (8.11.0/8.8.7) with ESMTP id g0C9ggH28880;
	Sat, 12 Jan 2002 15:12:43 +0530
Date: Sat, 12 Jan 2002 15:12:42 +0530 (IST)
From: Praveen Kumar <praveen@it.iitb.ac.in>
To: Sundeep Singatwaria <ssingatw@nortelnetworks.com>
cc: mpls@UU.NET
Subject: Re: pulledUnconditional / pulledConditional
In-Reply-To: <5D630265EF50D311ABB60008C7917DB6079CCAB3@zsc4c004.us.nortel.com>
Message-ID: <Pine.LNX.4.21.0201121450380.27029-100000@cygnus.it.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk



A sample scenario could be like this....
Sine 3031 allows a signaling protocol to exchange negotiations (by an 
LSR) in order to know other MPLS capable LSRs which are using same
signaling protocol, we can say Ru is not a label distribution peer of Rd
with respect to X, if Rd don't have adjacency with Ru on the interface or
label space (to which X of Ru belongs to) even though X is in Rd's routing
table.

On Fri, 11 Jan 2002, Sundeep Singatwaria wrote:

> Could some explain this one -
> 
> >From the MPLS Architecture rfc -
> 
> ----
> Let Rd be an LSR.  Suppose that:
> 
>       1. X is an address prefix in Rd's routing table
> 
>       2. Ru is a label distribution peer of Rd with respect to X
> 
>       3. Ru has explicitly requested that Rd bind a label to X and
>          distribute the binding to Ru
> 
>       4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
>          Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
>          Rn has bound a label to X and distributed that binding to Rd
> 
>    Then as soon as these conditions all hold, Rd should bind a label to
>    X and distribute that binding to Ru.  Note that if X is not in Rd's
>    routing table and a binding for X is not obtainable via Rd's next hop
>    for X, 
> **********
>    or if Rd is not a label distribution peer of Ru with respect
>    to X, 
> **********
>    then Rd must inform Ru that it cannot provide a binding at this
>    time.
> -----
> 
> How does a router Rd decide that it is not a label distribution peer 
> of Ru with respect to X ? 
> 
> Tx.
> Sundeep
> 

-- 
S.Praveen Kumar
M.Tech,KReSIT
IIT-Bombay
web: http://www.it.iitb.ac.in/~praveen




From owner-mpls@UU.NET  Sat Jan 12 05:19:18 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19199
	for <mpls-archive@lists.ietf.org>; Sat, 12 Jan 2002 05:19:17 -0500 (EST)
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 QQlxlx07817;
	Sat, 12 Jan 2002 10:18:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxlx29468
	for mpls-outgoing; Sat, 12 Jan 2002 10:18:36 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 QQlxlx29463
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 12 Jan 2002 10:18: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 QQlxlx18088
	for <mpls@UU.NET>; Sat, 12 Jan 2002 10:18:03 GMT
From: mvsjetti@hss.hns.com
Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.26.202])
	id QQlxlx06295
	for <mpls@UU.NET>; Sat, 12 Jan 2002 10:18:02 GMT
Received: from sandesh.hss.hns.com (sandesh [139.85.242.35])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id g0CAJCE26961
	for <mpls@UU.NET>; Sat, 12 Jan 2002 15:49:12 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256B3F.00388CFD ; Sat, 12 Jan 2002 15:47:41 +0530
X-Lotus-FromDomain: HSS
To: mpls@UU.NET
Message-ID: <65256B3F.00388C46.00@sandesh.hss.hns.com>
Date: Sat, 12 Jan 2002 15:49:01 +0530
Subject: regarding how to ethernet identifies mpls packet.?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



hi,
 i am working on MPLS over ethernet .
i had gone through the draft    "draft-jagd-mpls-mcast-eth-00.txt"  .

i was able to get the information on how ethernet identifies mpls packet  when
it
receives a packet form layers below it .(physical layer)
(i.e from the standard ethernet type values for MPLS mulicast and
unicast values 0x8847 & ox8848 in ethernet header)

But when ethernet receives a packet from upper layer(i.e MPLS layer) how can
it know that it had received from MPLS layer? is there any standard method?
For example in BSD when ethernet receives a packet form IP it compares the
address family of destination with AF_INET and determines whether it received
packet from
IP or not ?  Similarly is there any address family  AF_MPLS defined for MPLS? if
not defined
then how can ethernet identify that it had recived packet from MPLS?

can anyone  help me out in this issue?

thanks in advance

mahesh


Hughes Software Systems





From owner-mpls@UU.NET  Sun Jan 13 05:22:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09383
	for <mpls-archive@lists.ietf.org>; Sun, 13 Jan 2002 05:22:23 -0500 (EST)
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 QQlxpp11031;
	Sun, 13 Jan 2002 10:21:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxpp12081
	for mpls-outgoing; Sun, 13 Jan 2002 10:21: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 QQlxpp12076
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 13 Jan 2002 10:21: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 QQlxpp11547
	for <mpls@UU.NET>; Sun, 13 Jan 2002 10:20:59 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f183.law8.hotmail.com [216.33.241.183])
	id QQlxpp17796
	for <mpls@UU.NET>; Sun, 13 Jan 2002 10:20:59 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 13 Jan 2002 02:20:58 -0800
Received: from 192.11.188.113 by lw8fd.law8.hotmail.msn.com with HTTP;
	Sun, 13 Jan 2002 10:20:58 GMT
X-Originating-IP: [192.11.188.113]
From: "Ashish Vyas" <ashish_vyas@hotmail.com>
To: mpls@UU.NET
Subject: Re: regarding label-stack in MPLS-ATM
Date: Sun, 13 Jan 2002 15:50:58 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F183e6EEkuHiOyjtW0j0001a581@hotmail.com>
X-OriginalArrivalTime: 13 Jan 2002 10:20:58.0299 (UTC) FILETIME=[FE06C0B0:01C19C1B]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,

In MPLS-IP the lable-stack can be maintained using multiple "Shim-Headers".

But how does label-stack ( of depth &gt;2) is maintained in case of "MPLS 
over ATM"?

Regards
-ashish vyas


>From: Scott  Bradner <sob@harvard.edu>
>To: ashish_vyas@hotmail.com
>Subject: Re: regarding label-stack in MPLS-ATM
>Date: Sat, 12 Jan 2002 13:53:48 -0500 (EST)
>
>please do not send HTML mail to IETF mailing lists
>
>-----
>From owner-mpls@UU.NET  Sat Jan 12 04:27:12 2002
>X-Originating-IP: [192.11.188.113]
>From: "Ashish Vyas" <ashish_vyas@hotmail.com>
>To: mpls@UU.NET
>Subject: regarding label-stack in MPLS-ATM
>Date: Sat, 12 Jan 2002 14:55:25 +0530
>Mime-Version: 1.0
>Content-Type: text/html
>X-OriginalArrivalTime: 12 Jan 2002 09:25:25.0966 (UTC) 
>FILETIME=[116356E0:01C19B4B]
>Sender: owner-mpls@UU.NET
>Precedence: bulk
>
><html><div style='background-color:'><DIV>
><DIV>
><P>Hi all,</P>
><P>In MPLS-IP the lable-stack can be maintained using multiple 
>"Shim-Headers". </P>
><P>But how does label-stack ( of depth &gt;2) is maintained in case of 
>"MPLS over ATM"?&nbsp;</P>
><P>&nbsp;</P>
><P>Regards</P>
><P>Ashish Vyas<BR>&nbsp;</P></DIV></DIV></div><br clear=all><hr>Send and 
>receive Hotmail on your mobile device: <a 
>href='http://go.msn.com/bql/hmtag2_etl_EN.asp'>Click Here</a><br></html>
>


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



From owner-mpls@UU.NET  Sun Jan 13 09:34:29 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10785
	for <mpls-archive@lists.ietf.org>; Sun, 13 Jan 2002 09:34:24 -0500 (EST)
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 QQlxqg05005;
	Sun, 13 Jan 2002 14:33:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxqg19718
	for mpls-outgoing; Sun, 13 Jan 2002 14:33: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 QQlxqg19711
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 13 Jan 2002 14:33:17 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlxqg21145
	for <mpls@uu.net>; Sun, 13 Jan 2002 14:32:51 GMT
Received: from web14303.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14303.mail.yahoo.com [216.136.173.79])
	id QQlxqg10780
	for <mpls@uu.net>; Sun, 13 Jan 2002 14:32:51 GMT
Message-ID: <20020113143250.69059.qmail@web14303.mail.yahoo.com>
Received: from [65.24.148.139] by web14303.mail.yahoo.com via HTTP; Sun, 13 Jan 2002 06:32:50 PST
Date: Sun, 13 Jan 2002 06:32:50 -0800 (PST)
From: anurag sahai <emailsahai@yahoo.com>
Subject: re: MPLS
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

HI! 

Can, any one tell me is it possible to install MNS
v2.0 on network simulator2 ver 1.8 or I have to
install NS2 ver 1.6
  I tried it but is not working on NS2 ver 1.8 ?
appreciate your help.
sahai

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/


From owner-mpls@UU.NET  Sun Jan 13 20:36:16 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16629
	for <mpls-archive@lists.ietf.org>; Sun, 13 Jan 2002 20:36:15 -0500 (EST)
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 QQlxry07459;
	Mon, 14 Jan 2002 01:35:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxry17259
	for mpls-outgoing; Mon, 14 Jan 2002 01:35:26 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlxry17254
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 01:35:22 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlxry29626
	for <mpls@UU.NET>; Mon, 14 Jan 2002 01:34:48 GMT
Received: from cmail.packetcom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.108.173.139])
	id QQlxry13796
	for <mpls@UU.NET>; Mon, 14 Jan 2002 01:34:48 GMT
Received: from caspiannetworks.com (h-64-105-34-181.SNVACAID.covad.net [64.105.34.181])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABQ29471 (AUTH tso@caspiannetworks.com);
	Sun, 13 Jan 2002 17:34:47 -0800 (PST)
Message-ID: <3C422FD2.3D93B666@caspiannetworks.com>
Date: Sun, 13 Jan 2002 17:09:38 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: Re: regarding label-stack in MPLS-ATM
References: <F183e6EEkuHiOyjtW0j0001a581@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ashish,

In the case of ATM, the inner label is kept within the payload, unfortunately.

Tricci

Ashish Vyas wrote:

> Hi all,
>
> In MPLS-IP the lable-stack can be maintained using multiple "Shim-Headers".
>
> But how does label-stack ( of depth &gt;2) is maintained in case of "MPLS
> over ATM"?
>
> Regards
> -ashish vyas
>
> >From: Scott  Bradner <sob@harvard.edu>
> >To: ashish_vyas@hotmail.com
> >Subject: Re: regarding label-stack in MPLS-ATM
> >Date: Sat, 12 Jan 2002 13:53:48 -0500 (EST)
> >
> >please do not send HTML mail to IETF mailing lists
> >
> >-----
> >From owner-mpls@UU.NET  Sat Jan 12 04:27:12 2002
> >X-Originating-IP: [192.11.188.113]
> >From: "Ashish Vyas" <ashish_vyas@hotmail.com>
> >To: mpls@UU.NET
> >Subject: regarding label-stack in MPLS-ATM
> >Date: Sat, 12 Jan 2002 14:55:25 +0530
> >Mime-Version: 1.0
> >Content-Type: text/html
> >X-OriginalArrivalTime: 12 Jan 2002 09:25:25.0966 (UTC)
> >FILETIME=[116356E0:01C19B4B]
> >Sender: owner-mpls@UU.NET
> >Precedence: bulk
> >
> ><html><div style='background-color:'><DIV>
> ><DIV>
> ><P>Hi all,</P>
> ><P>In MPLS-IP the lable-stack can be maintained using multiple
> >"Shim-Headers". </P>
> ><P>But how does label-stack ( of depth &gt;2) is maintained in case of
> >"MPLS over ATM"?&nbsp;</P>
> ><P>&nbsp;</P>
> ><P>Regards</P>
> ><P>Ashish Vyas<BR>&nbsp;</P></DIV></DIV></div><br clear=all><hr>Send and
> >receive Hotmail on your mobile device: <a
> >href='http://go.msn.com/bql/hmtag2_etl_EN.asp'>Click Here</a><br></html>
> >
>
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com



From owner-mpls@UU.NET  Sun Jan 13 21:49:20 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18190
	for <mpls-archive@lists.ietf.org>; Sun, 13 Jan 2002 21:49:20 -0500 (EST)
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 QQlxsd06235;
	Mon, 14 Jan 2002 02:48:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxsd12930
	for mpls-outgoing; Mon, 14 Jan 2002 02:48: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 QQlxsd12903
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 02:47:57 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 QQlxsd09695
	for <mpls@UU.NET>; Mon, 14 Jan 2002 02:47:45 GMT
Received: from cmail.packetcom.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.108.173.139])
	id QQlxsd11699
	for <mpls@UU.NET>; Mon, 14 Jan 2002 02:47:45 GMT
Received: from caspiannetworks.com (h-64-105-34-181.SNVACAID.covad.net [64.105.34.181])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABQ29637 (AUTH tso@caspiannetworks.com);
	Sun, 13 Jan 2002 18:47:43 -0800 (PST)
Message-ID: <3C4240E6.7C7F7AB2@caspiannetworks.com>
Date: Sun, 13 Jan 2002 18:22:30 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: Re: regarding how to ethernet identifies mpls packet.?
References: <65256B3F.00388C46.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

As far as I know, the only way to encapsulate Ethernet over MPLS is to refer to the
Martini draft (see draft-martini-l2circuit-encap-mpls-xx.txt).  There is no such
thing as  protocol type in MPLS to identify the encapsulated packet is Ethernet.
You need to configure or to signal the info for the associated MPLS i/f.

Tricci

mvsjetti@hss.hns.com wrote:

> hi,
>  i am working on MPLS over ethernet .
> i had gone through the draft    "draft-jagd-mpls-mcast-eth-00.txt"  .
>
> i was able to get the information on how ethernet identifies mpls packet  when
> it
> receives a packet form layers below it .(physical layer)
> (i.e from the standard ethernet type values for MPLS mulicast and
> unicast values 0x8847 & ox8848 in ethernet header)
>
> But when ethernet receives a packet from upper layer(i.e MPLS layer) how can
> it know that it had received from MPLS layer? is there any standard method?
> For example in BSD when ethernet receives a packet form IP it compares the
> address family of destination with AF_INET and determines whether it received
> packet from
> IP or not ?  Similarly is there any address family  AF_MPLS defined for MPLS? if
> not defined
> then how can ethernet identify that it had recived packet from MPLS?
>
> can anyone  help me out in this issue?
>
> thanks in advance
>
> mahesh
>
> Hughes Software Systems



From owner-mpls@UU.NET  Mon Jan 14 12:14:49 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07608
	for <mpls-archive@lists.ietf.org>; Mon, 14 Jan 2002 12:14:48 -0500 (EST)
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 QQlxui16678;
	Mon, 14 Jan 2002 17:14:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxui16110
	for mpls-outgoing; Mon, 14 Jan 2002 17:13: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 QQlxui16105
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 17:13: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 QQlxui02382
	for <mpls@UU.NET>; Mon, 14 Jan 2002 17:12:25 GMT
Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged))
	id QQlxui11102
	for <mpls@UU.NET>; Mon, 14 Jan 2002 17:12:25 GMT
Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <CPWKZXPH>; Mon, 14 Jan 2002 09:06:17 -0800
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8455D5D@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'Kapur, Rajan'" <RKapur@ciena.com>, "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: Questions about LMP
Date: Mon, 14 Jan 2002 09:06:10 -0800
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

Raj,
  Please look at the latest versions of the drafts:
draft-ietf-ccamp-lmp-02.txt and draft-fredette-lmp-wdm-03.txt.  Other
comments inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Kapur, Rajan [mailto:RKapur@ciena.com]
> Sent: Friday, January 11, 2002 12:15 PM
> To: 'mpls@UU.NET'
> Subject: Questions about LMP
> 
> 
> Hi,
> 
> Some questions came to mind after reviewing the 
> draft-ietf-ccamp-lmp-00.txt and draft-fredette-lmp-wdm-02.txt 
> drafts.  I would appreciate it if somebody could provide 
> answers to the following questions:
> 
> 1. Are there currently any provisions for send proprietary 
> data in LMP? i.e, Is there a way in LMP to define proprietary 
> TLV's or can a set of values be reserved for defining 
> proprietary TLV's?
Currently there are no C-Types reserved for proprietary purposes.

> 2. Are the type values for the TLV objects in lmp-wdm published somewhere?
Any new C-types defined in lmp-wdm must be assigned by IANA.

> 
> Thanks,
> Raj Kapur
> 
> 


From owner-mpls@UU.NET  Mon Jan 14 18:22:29 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25023
	for <mpls-archive@lists.ietf.org>; Mon, 14 Jan 2002 18:22:29 -0500 (EST)
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 QQlxvh29288;
	Mon, 14 Jan 2002 23:21:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxvh16567
	for mpls-outgoing; Mon, 14 Jan 2002 23:21:28 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlxvh16560
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 23:21:18 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlxvh06479
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:21:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxvh01596
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:21:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA29734 for <mpls@uu.net>; Mon, 14 Jan 2002 18:21:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA23614 for mpls@uu.net; Mon, 14 Jan 2002 18:21:01 -0500 (EST)
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 QQlxvh16511
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 23:20:05 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 QQlxvh01769
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:19:04 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxvh26500
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:19:03 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA29596; Mon, 14 Jan 2002 18:18:59 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id SAA24060; Mon, 14 Jan 2002 18:18:59 -0500 (EST)
Message-Id: <200201142318.SAA24060@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: minutes@ietf.org
Cc: mpls@UU.NET
Subject: Final MPLS Minutes
Date: Mon, 14 Jan 2002 18:18:59 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Attached are updated minutes with a few small corrections.

...George


======================================================================
MPLS WG meeting minutes       Salt Lake City                  12/10/01
======================================================================

1.  "MTU Signalling Extensions for LDP" 
      <draft-black-ldp-mtu-extensions-02.txt>

      Kireeti Kompella 

There was a very brief prsentation to update the workgroup
on changes since the last document, concluding with a request 
to go to last call.

Discussion:

Brijesh: This draft only addresses a part of the problem: MTU
discovery for LDP. What do we do for RSVP?
Kireeti: RSVP is done.
Brijesh: why do we have a separate draft?
Kireeti: 2 drafts are okay.
Lou: The RSVP info is in the original draft.

K: George, can we check the room for consensus for last call? What
does the room think?

Room: More for than against, but George wants to see a little more
enthusiasm. George will issue a WG last call shortly.


2.  "TTL Processing in MPLS Networks" 
      <draft-agarwal-mpls-ttl-01.txt>

    Puneet Agarwal 

Puneet: Made a short presentation, followed by a request to adopt the
draft as WG document.

George: Do people in the room believe this draft is a good idea. Do I
see any nods for yet/no?  Some clarifications on this would help for
interoperability of this. There seems to be a consensus for such
documents. 

Anonymous: 

Provides useful clarification, but would like to know how you know 
which model of TTL decrment to use?  

Puneet: Signaling is out of the scope of this document. If the group
wants to address this, the chair needs to address this.


Shahram Davari: as one of the authors of draft-MPLS-Diffserv-09, I
feel that this work is needed as a supplement to
draft-MPLS-Diffserv-09, which addresses practical uncertainties that
have been observed during implementations of various tunneling modes.

Scott Bradner: The documents going into being WG documents need to be
items that are in the charter, or the charter needs to be re-spun to
change. We need more WG support short for this document before it can
be accepted.

George: This document is just a document to clarify how things are
being done.  It does not represent new protocol work.
We decided it would be informational in London.

The document was accepted as a WG document.


3.  Restart/Recovery

Three drafts were presented on Restart/Recovery, adjudication was
withheld until all were presented.

    "Graceful Restart Mechanism for BGP with MPLS" 
     <draft-rekhter-bgp-mpls-restart-00.txt> 

    Yakov Rekhter 

Yakov:  Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: What is the required restart time.

Yakov: User configurable.

Anonymous: BGP has a specific timer.

Y: You should look at the BGP proposal; whatever BGP does this does too.

Y: Any other questions?


    "Graceful Restart Mechanism for LDP" 
     <draft-leelanivas-ldp-restart-01.txt>

     Yakov Rekhter

Yakov: Made a short presentation, followed by a request to adopt the
draft as WG document.

Anonymous: Why previous BGP restart should be done in IDR?

Y: Distribution of BGP labels has been done in this WG, so we should
do this here.


    "Graceful Restart Mechanism for LDP" 
     <draft-smith-mpls-ldp-restart-00.txt>

     Andy Malis / Toby Smith 

Toby: Presentation. Detailed difference between this proposal and Yakov's.

Anonymous: Discuss different proposals?

George: Drafts have not been accepted, so we need to get to the bottom
of that. Lets discuss this for a few minutes.

Eric Gray: This draft does not compete with Yakov's draft. Yakov's is
focused on BGP MPLS. This draft proposes a difference between what is
in the IESG queue for a year now.  The LDP fault tolerance draft had
looked at stuff like this drafts. The problems are that these
assumptions do not work in all deployments unless all LSRs agree to do
this fault tolerant mode. It doesn't do any good to support any LSPs
that are not supported in any other segments in the network.

Andy: First comment: this only goes on between LDP peers, so if you
are running lDP throughout the network and you have an outage between
two peers, those should come up okay and should not affect other peers
elsewhere. Comment two: it is all or none.

Luca: I would like to see these approaches get together. 

Andy: We already have plans to meet with the other authors.

Anonymous: The assumption that was made that checkpoint information
can be kept can be a problem with regard to resources.

Andy: This is a problem with all of the approaches.

Phil: After querying about the number of implementations of the
existing draft, I have not heard of any problems with this
approach. There are apparently 2 implementations of the existing fault
tolerant draft.

Andy: There is no problem with the difficulty to implement these or
the new approaches; just the implementation complexity.

Kireeti: This draft is nice because it is light, but I am afraid that
two end points of the connection can loose state. If you exchange
control messages, you are assured that things are in sync.  The IDR
approach does exchange control messages. Just an important point to
understand.

Anonymous: A few points. The BGP restart drafts pretty much learn
their state from the network. With this approach, you have the
possibility of loosing state. The main difference between the two
approaches is that one approach caches state, and the other doesn't.

Andy: We considered that LDP runs over TCP, so we have a reliable and
sequenced path. You know that the receiver knows that they received
control messages. We are pretty clear that things should work pretty
well. All should read the current draft, and send email to the list.

George: Requested that the group having lunch please send email to the
        list.


4.  Fast Reoute

    "Fast Reroute Techniques in RSVP-TE" 
      <draft-ping-rsvp-fastreroute-00.txt>

      Ping Pan 

Ping: Presentation

George: Would like this accepted as a WG document?

Ping: Yes.

Question: I could not figure out how one approach complements the others.

Ping: We would like to combine the request mechanism from all drafts,
so that any router in the network based on local configuration can
construct a back-up path.  We haven't finished integrating these.

Question: I think the case when the backup path LSP fails behavior is
not specified. There should be recommendations/considerations of what
should be done. Now, if the backup LSP fails what do we do?

Question2: Generalizing the applicability for this (i.e.:
bi-directional LSPs)?

Ping: I think in the case of GMPLS this is already done.


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

     Alia Atlas 

Note: Alia is also one of the co-authors of the draft presented by
Ping.  Her draft is intended to allow some of the open issues in that
draft to be aired before the workgroup.

Alia: Presentation

A lively discusion between Ping and Alia ensued, particularly over the
issue of make-before-break on backup tunnels.

George: Any objection to accepting the Ping draft as a WG document?
Note that the issues that Alia raised should contunied to be disussed
on the mailing list.  How many people think this should be added to
the WG?

George: The I's have it.   


5.  "Multiprotocol Label Switching (MPLS) Management Overview" 
     <draft-ietf-mpls-mgmt-overview-00.txt>

     Tom Nadeau 

George:  This draft was requested by ADs.  It 
shows relationship of various MIBs.

Tom: Presentation

Kireeti: Include TE-MIB?

Tom: Yes.

George: WG draft?

Group: Lots of hands. No objections.

George: Draft will be last called after IESG process on MPLS
LSR/TE/LDP/FTN MIBs has progressed and any changes that emerge from
that process are inculded.


6.  "IPv6 Traffic Engineering Tunnel" 
     <draft-ishii-ipv6-te-tunnel-00.txt>

     Hiroki Ishibashi 

George: This next presentation is out of the scope of the WG, and is more
of an application of MPLS.

Hiroki: Presentation.

Francois: This work belongs to the NG-trans WG. There is a draft
there for this work already. LSPs are constraint based routed. There
is a lot of overlap between this draft and the draft being progressed
there.

George: (to Hiroki) The point is that the discussion belongs in the
other WG, not here.


7.  Document Status

George: Presented drafts that are in IESG last call, are on IESG queue.

Yakov: There are some changes to the unnumbered draft for CR-LDP that
 need to be done.

George: Any comments on mpls-te-feedback-draft

Don Fedyk: We were looking to progress this document.

George: I will send it to last call.

We now want to shift gears and talk about which RFCs that can be
progressed onto the standards track.  Scott, please comment on
architecture document.

Scott: Beats me.  In general, architecture documents are not standards
track documents.

George: Enaps draft. There are quite a few implementations of that
that interoperate. What we need is for people to collect interop
information.

Lou: a while back when this draft was coming out, there were MTU
discovery interop issues.  The discussion was that when it came time
to advance the document until these issues are addressed.

George: Dig up old email and start a new discussion. 

Lou: Hopefully it will be just what we agreed to 2 years ago and put
it into the draft.

George: LDP draft. Has many different flavors. In order to progress,
only those things for which there are 2 or more interop
implementations can be progressed, and the rest removed. A survey
effort needs to happen and documentation of what is there and what is
not.

Joel Halpern: Are you going to make the list or is someone else?

George: I am not going to do it. Volunteers? Loa, you showed interest
in this in the past.

Loa: I will help out if Bob Thomas doesn't have time.

George: Technology-specific drafts (ATM). There are multiple
implementations, not sure about interop of them. Need to get to the
bottom of this. The (FR) drafts: don't know of any implementations, so
it will stay proposed (forever).  BGP draft: there are interoperable
implementations of this, so this can be progressed.  I will send the
list of these drafts/status to the list.







From owner-mpls@UU.NET  Mon Jan 14 18:47:46 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25962
	for <mpls-archive@lists.ietf.org>; Mon, 14 Jan 2002 18:47:46 -0500 (EST)
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 QQlxvj13361;
	Mon, 14 Jan 2002 23:46:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxvj17916
	for mpls-outgoing; Mon, 14 Jan 2002 23:46: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 QQlxvj17911
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 23:46: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 QQlxvj29037
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:46:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxvj08137
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:46:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA01393 for <mpls@uu.net>; Mon, 14 Jan 2002 18:46:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA25105 for mpls@uu.net; Mon, 14 Jan 2002 18:46:02 -0500 (EST)
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 QQlxvj17732
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 14 Jan 2002 23:45: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 QQlxvi25720
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:44:34 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f244.law10.hotmail.com [64.4.15.244])
	id QQlxvi06192
	for <mpls@uu.net>; Mon, 14 Jan 2002 23:44:34 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 14 Jan 2002 15:44:33 -0800
Received: from 198.242.58.71 by lw10fd.law10.hotmail.msn.com with HTTP;
	Mon, 14 Jan 2002 23:44:33 GMT
X-Originating-IP: [198.242.58.71]
From: "manoj juneja" <manojkumarjuneja@hotmail.com>
To: mpls@UU.NET
Subject: Integrity Object
Date: Mon, 14 Jan 2002 16:44:33 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F2447GDiDlNHy6XJRx50001d61b@hotmail.com>
X-OriginalArrivalTime: 14 Jan 2002 23:44:33.0917 (UTC) FILETIME=[6B2FF2D0:01C19D55]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

        If a node does not support integrity object and receives
this object in a message, should it ignore the object (as it is optional) or 
discard the complete message (as integrity object is optional but if present 
the integrity check is mandatory) ?

I know this is not the right mailing list for this question but just wanted 
to know the thoughts of MPLS experts.

Regards,
manoj.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



From owner-mpls@UU.NET  Mon Jan 14 19:17:32 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26889
	for <mpls-archive@lists.ietf.org>; Mon, 14 Jan 2002 19:17:32 -0500 (EST)
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 QQlxvl07962;
	Tue, 15 Jan 2002 00:17:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxvl09620
	for mpls-outgoing; Tue, 15 Jan 2002 00:16: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 QQlxvl09615
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 00:16:36 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 QQlxvl23799
	for <mpls@UU.NET>; Tue, 15 Jan 2002 00:16: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 QQlxvl21314
	for <mpls@UU.NET>; Tue, 15 Jan 2002 00:16:35 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 TAA26180
	for <mpls@UU.NET>; Mon, 14 Jan 2002 19:16:32 -0500 (EST)
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 TAA06520
	for <mpls@UU.NET>; Mon, 14 Jan 2002 19:16:34 -0500 (EST)
Message-ID: <3C437551.AA6E637F@marconi.com>
Date: Mon, 14 Jan 2002 19:18:25 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Integrity Object
References: <F2447GDiDlNHy6XJRx50001d61b@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 a node does not support integrity object and receives
> this object in a message, should it ignore the object (as it is
> optional) or discard the complete message (as integrity object is
> optional but if present the integrity check is mandatory) ?

I have been working with the assumption that the object should be
ignored.

IMO, there's no reason to discard the message.  The sender is including
information to cryptographically validate the message.  If you are
incapable of performing the validation, the presence/absence of the
object does not in any way alter the validity of the data, so there's no
reason why you should reject the message.

One thing you should definitely _NOT_ do is forward the INTEGRITY
object.  Its contents can not possibly be valid when the message body
changes (e.g. a different HOP or ERO object).

-- David


From owner-mpls@UU.NET  Mon Jan 14 20:22:59 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28365
	for <mpls-archive@lists.ietf.org>; Mon, 14 Jan 2002 20:22:59 -0500 (EST)
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 QQlxvp04816;
	Tue, 15 Jan 2002 01:22:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxvp03849
	for mpls-outgoing; Tue, 15 Jan 2002 01:22: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 QQlxvp03844
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 01:22:03 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 QQlxvp22150
	for <mpls@uu.net>; Tue, 15 Jan 2002 01:21:49 GMT
Received: from tsmtp1.mail.isp by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [195.235.113.141])
	id QQlxvp07904
	for <mpls@uu.net>; Tue, 15 Jan 2002 01:21:48 GMT
Received: from maigmo ([193.153.110.219]) by tsmtp1.mail.isp
          (Netscape Messaging Server 4.15 tsmtp1 Jul 26 2001 13:10:38)
          with ESMTP id GPYH4A02.0CT for <mpls@uu.net>; Tue, 15 Jan 2002
          02:21:46 +0100 
From: =?iso-8859-1?Q?Javier_P=E9rez_Lled=F3?= <javi.pll@terra.es>
To: <mpls@UU.NET>
Subject: Test
Date: Tue, 15 Jan 2002 02:21:41 +0100
Message-ID: <001901c19d62$fd430bf0$db6e99c1@maigmo>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01C19D6B.5F0773F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C19D6B.5F0773F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Test

------=_NextPart_000_001A_01C19D6B.5F0773F0
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>Mensaje</TITLE>

<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D274262101-15012002><FONT face=3DArial=20
size=3D2>Test</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_001A_01C19D6B.5F0773F0--



From owner-mpls@UU.NET  Tue Jan 15 06:37:51 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18678
	for <mpls-archive@lists.ietf.org>; Tue, 15 Jan 2002 06:37:51 -0500 (EST)
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 QQlxxe26004;
	Tue, 15 Jan 2002 11:32:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxxe03202
	for mpls-outgoing; Tue, 15 Jan 2002 11:31: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 QQlxxe03195
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 11:31:48 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 QQlxxe00905
	for <mpls@uu.net>; Tue, 15 Jan 2002 11:31:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxxe23469
	for <mpls@uu.net>; Tue, 15 Jan 2002 11:31:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA03852 for <mpls@uu.net>; Tue, 15 Jan 2002 06:31:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA24249 for mpls@uu.net; Tue, 15 Jan 2002 06:31:01 -0500 (EST)
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 QQlxxe03030
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 11:30:19 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 QQlxxd24011
	for <mpls@uu.net>; Tue, 15 Jan 2002 11:29:33 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 QQlxxd15020
	for <mpls@uu.net>; Tue, 15 Jan 2002 11:29:28 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18020;
	Tue, 15 Jan 2002 06:29:24 -0500 (EST)
Message-Id: <200201151129.GAA18020@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-multicast-07.txt
Date: Tue, 15 Jan 2002 06:29:24 -0500
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 IP Multicast in MPLS
	Author(s)	: D. Ooms, B. Sales, W. Livens, A. Acharya,
                          F. Griffoul, F. Ansari
	Filename	: draft-ietf-mpls-multicast-07.txt
	Pages		: 29
	Date		: 14-Jan-02
	
This document offers a framework for IP multicast deployment in an
MPLS environment.  Issues arising when MPLS techniques are applied to
IP multicast are overviewed.  The pros and cons of existing IP
multicast routing protocols in the context of MPLS are described and
the relation to the different trigger methods and label distribution
modes are discussed.  The consequences of various layer 2 (L2)
technologies are listed.  Both point-to-point and multi-access
networks are considered.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-mpls-multicast-07.txt

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

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

--OtherAccess--

--NextPart--




From zappacor@TELEFONICA.COM.AR  Tue Jan 15 14:14:08 2002
Received: from mail1.telefonica.com.ar ([168.226.49.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10160
	for <mpls-archive@lists.ietf.org>; Tue, 15 Jan 2002 14:13:57 -0500 (EST)
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <YQ00CT57>; Tue, 15 Jan 2002 16:07:03 -0300
Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D44736@MSTELEFONICA1>
From: Zappacosta Rolando Jorge <zappacor@TELEFONICA.COM.AR>
To: "'zappacor@yahoo.com.ar'" <zappacor@yahoo.com.ar>
Subject: Job hiring
Date: Tue, 15 Jan 2002 15:49:23 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C19DF5.5942E870"

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_000_01C19DF5.5942E870
Content-Type: text/plain

> Hi.
> 
> 	First of all I want to apologize for the inconvenience and time
> wasting in your surely complicated agenda.
> I contacted you because I'll be fired because of the personnel reduction
> the company is now implementing as a consequence of the economical
> situation that is bad by these days in our country.
> 	This is why I want to contact you just in case you know some current
> hiring. As a dual citizen of Europe, I would be able to quickly accept a
> job not only in Argentina (where I'm now living) but also in any European
> country. This doesn't mean that I would not accept a job in other
> countries at all but I think it would be easier in Europe because of that.
> 	Nowadays my job at the company lab included basically core and
> border routing equipment test and formerly NGN and ISDN test trials, but
> for a more complete knowledge of my skills and priors jobs please see the
> attached document.
> In case you need references from this job, at Telefonica Argentina, it
> would not be a problem since my boss, the supervisor and even our Director
> are also worried to have to fire me.
> 	If you also have some colleagues or companies that you think may be
> interested to contact me, please feel free to forward them this e-mail or
> tell me how to contact them.
> 	I will be using as mail account zappacor@yahoo.com.ar, which is in
> the copy field and will be actually forwarded to rzappa@movi.com.ar. If
> you have any problem please contact me there instead of this originating
> address.
> 	Best regards,
> 
> 
> 
> 		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
>  <<CVRJZ3.doc>> 

------_=_NextPart_000_01C19DF5.5942E870
Content-Type: application/msword;
	name="CVRJZ3.doc"
Content-Disposition: attachment;
	filename="CVRJZ3.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAswAAAAAAAAAA
EAAAmwAAAAEAAAD+////AAAAANgAAAC0AAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////+
/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAC4AQAAEgAAAAEA
AACYAAAAAgAAAKAAAAADAAAAxAAAAAQAAADQAAAABQAAAOwAAAAGAAAA+AAAAAcAAAAEAQAACAAA
ABgBAAAJAAAAQAEAABIAAABMAQAACgAAAGgBAAALAAAAdAEAAAwAAACAAQAADQAAAIwBAAAOAAAA
mAEAAA8AAACgAQAAEAAAAKgBAAATAAAAsAEAAAIAAADkBAAAHgAAABkAAABSb2xhbmRvIEpvcmdl
IFphcHBhY29zdGEAADAAHgAAAAEAAAAAb2xhHgAAABEAAABtaWNyb2luZm9ybWF0aWNhAHBhYx4A
AAABAAAAAGljch4AAAABAAAAAGljch4AAAALAAAATm9ybWFsLmRvdABhHgAAAB4AAABEaXJlY2Np
b24gU2lzdGVtYXMgZGUgSW5mb3JtYQBNaR4AAAACAAAANwByZR4AAAATAAAATWljcm9zb2Z0IFdv
cmQgOC4wAGRAAAAAAKb3XwIAAABAAAAAAHYK1VidwQFAAAAAAJop2T6dwQFAAAAAAFY/ar2dwQED
AAAAAQAAAAMAAACuAgAAAwAAAEgPAAADAAAAAAAAAGlsbGFzAAAARBZDADoAAPC09bl+6PW5fv7/
AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI
ACss+a5YAQAAFAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAJAAAAAGAAAAmAAAABEAAACgAAAA
FwAAAKgAAAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAAyAAAAA0AAADQAAAADAAAAPUAAAAC
AAAA5AQAAB4AAAAYAAAAVGVsZWbzbmljYSBkZSBBcmdlbnRpbmEAAwAAACAAAAADAAAABwAAAAMA
AADEEgAAAwAAALMNCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAGQAA
AFJvbGFuZG8gSm9yZ2UgWmFwcGFjb3N0YQAMEAAAAgAAAB4AAAAHAAAAVO10dWxvAAMAAAABAAAA
DAEAAAQAAAAAAAAAKAAAAAEAAABSAAAAAgAAAFoAAAADAAAAsgAAAAIAAAACAAAACgAAAF9QSURf
R1VJRAADAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAE4AAAB7AEYAOQAyADQAQgBFAEYA
OQAtADgAQwA5AEYALQAxADEARAAzAC0AOQBCADMAQgAtADAAMAAyADAAQQBGAEUANABGADgAUm9s
YW5kbyBKb3JnZSBaYXBwYWNvc3RhDQ0IMjc1IEdhbGxvIFN0Lg1Mb21hcyBkZSBaYW1vcmEsIENQ
IDE4MzINQnVlbm9zIEFpcmVzLCBBcmdlbnRpbmENUGhvbmU6ICg1NC0xMSk0MjQyLTU5NDcNQ2Vs
bCBQaG9uZTogKDU0LTExKTQxNzYtODU4Mw1FLW1haWw6IHJ6YXBwYUBpbmFtZS5jb20NDQ1QRVJT
T05BTDoHDUJpcnRoIGRhdGU6IE1hcmNoIDYsIDE5NzINUGFzc3BvcnRzOiBBcyBkdWFsIGNpdGl6
ZW4gb2YgSXRhbHkgSSBoYXZlIHR3bzoNQXJnZW50aW5hOiAyMjQxMTUyNU4NRXVyb3BlYW4gQ29t
bXVuaXR5OiAwMTk2NDFMDU1hcml0YWwgc3RhdHVzOiBTaW5nbGUNSGFtLVJhZGlvIGxpY2Vuc2U6
IExXMkVFSQ1JRUVFIE1lbWJlcjogU2luY2UgeWVhciAyMDAwDUxhbmd1YWdlczoNUG9ydHVndWVz
ZTogYmFzaWMgDVNwYW5pc2g6IG5hdGl2ZQ1FbmdsaXNoLCBUT0VJQyAoVGVzdCBvZiBFbmdsaXNo
IGZvciBJbnRlcm5hdGlvbmFsIENvbW11bmljYXRpb24pIHNjb3JlOg1MaXN0ZW5pbmc6IDQwNS80
OTUNUmVhZGluZzogNDEwLzQ5NS4NBwcNT0JKRUNUSVZFOgcNVG8gb2J0YWluIGEgY2hhbGxlbmdp
bmcgcG9zaXRpb24gaW4gYSB0b3AgY3JlYXRpdmUgYW5kIGdyb3dpbmcgZmlybSB0aGF0IHdpbGwg
YWxsb3cgbWUgdG8gZXhwYW5kIHVwb24gbXkgZXhwZXJpZW5jZSBhbmQgY29udGludWUgdG8gYWNj
dW11bGF0ZSBrbm93bGVkZ2UuDQcHDUVYUEVSSUVOQ0U6Bw1UZWxlZm9uaWNhIGRlIEFyZ2VudGlu
YTogTWFyY2ggMTk5OSCWIHByZXNlbnQuIFdvcmtpbmcgYXQgdGhlIExhYm9yYXRvcnkgQXJlYSBp
biB0aGlzIHRlbGVwaG9uZSBjb21wYW55IHdoaWNoIGlzIGEgc3Vic2lkaWFyeSBvZiBUZWxlZm9u
aWNhIEludGVybmFjaW9uYWwsIG9uZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgdGVsZWNvbW11bmlj
YXRpb25zIGhvbGRpbmcgaW4gRXVyb3BlIGFuZCBhbGwgYXJvdW5kIExhdGluIEFtZXJpY2EuIFRo
aXMgcG9zaXRpb24gaW52b2x2ZXMgbWFpbmx5IHRhc2tzIGluIHRoZSBmaWVsZCBvZiBjb3JlIGFu
ZCBib3JkZXIgdGVjaG5vbG9naWVzIGxhYm9yYXRvcnkgdGVzdHMgYW5kIGFsc28gc29tZSBkZWdy
ZWUgb2YgcGFydGljaXBhdGlvbiBpbiBzcGVjaWZpYyBOR04gdGVzdCB0cmlhbHMuDVNraWxscyBh
Y2hpZXZlZDoNTVBMUw1TT05FVC9TREgNSVAgVGVsZXBob255LCBILjMyMywgTUdDUCwgU0lQLCBN
RUdBQ08vSC4yNDgNSVNETg1UZWxlcGhvbmUgc3BlY2lmaWMgcHJvdG9jb2xzLCBzdWNoIGFzIFNT
NyBhbmQgTUZDIFIyDVNvbWUgZGVncmVlIG9mIEludGVsbGlnZW50IE5ldHdvcmtzIG9wZXJhdGlv
biBrbm93bGVkZ2UNQWR2YW5jZWQgdGVzdCBlcXVpcG1lbnQgb3BlcmF0aW9uLiBUaGVzZSBpbmNs
dWRlcyBBZ2lsZW50IFJvdXRlciBUZXN0ZXIsIEFnaWxlbnQgQlNUUywgaU5FVCBTcGVjdHJhIGFu
ZCBvdGhlcnMuDUJhbmtCb3N0b246IEF1Z3VzdCAxOTk2IJYgTWFyY2ggMTk5OSwgYXQgdGhlIFRl
Y2huaWNhbCBTdXBwb3J0IE9mZmljZS4gTGF0ZWx5IGFzIFRlYW0gTGVhZGVyIGluIHRoZSBuZXR3
b3JrIGVxdWlwbWVudCBzZXR1cCB0ZWFtIGZvciB0aGUgYnJhbmNoZXMgdGhhdCB0aGUgQmFuayB3
YXMgb3BlbmluZywgcG9zaXRpb24gdGhhdCBpbXBsaWVkIGVtcGxveWVlcyByZWxhdGlvbnMgbWFu
YWdpbmcsIHN1Z2dlc3Rpb25zIGFuZCBkdXRpZXMgZGVsZWdhdGlvbiB0byBvdGhlciB0ZWFtcyBh
bmQgZ3JvdXAgcGVyc29ubmVsIGNvb3JkaW5hdGlvbi4gQmVmb3JlIHRoaXMsIGluIGpvYnMgcmVs
YXRlZCBmdW5kYW1lbnRhbGx5IHdpdGggdGhlIFRva2VuIFJpbmcgbmV0d29yayBzdGFydHVwIGFu
ZCBvcGVyYXRpb24gYXQgdGhlIEJhbmsgaGVhZHF1YXJ0ZXJzIGFuZCBuZWFyYnkgYnVpbGRpbmdz
LiBCZXNpZGVzLCBiZWZvcmUgYSB3ZWxsLWRvbmUgam9iIEkgb2J0YWluZWQgYSCTU2VydmljaW8g
Q3VtYnJllCwgd2hpY2ggaXMgYW4gaG9ub3IgYXdhcmQgZ3JhbnRlZCB0byByZWNvZ25pemUgdGhl
IGVtcGxveWVlc5IgZXhjZWxsZW5jZS4NU2tpbGxzIGFjaGlldmVkOg1JUA1BVE0NTEFOL1dBTiBj
b21tdW5pY2F0aW9uIHByb3RvY29scw1Ub2tlbiBSaW5nIExBTiB0b3BvbG9naWVzLCBlc3BlY2lh
bGx5IHdpdGggZmliZXItb3B0aWNzIGJhY2tib25lIEhVQpJzLCBicmlkZ2VzLCByb3V0ZXJzIGFu
ZCBnYXRld2F5cw1XQU4gZXF1aXBtZW50LCBtb2RlbXMsIENQRZJzLCBhbmQgTWFpblN0cmVldCBk
ZXZpY2VzDUFnaWxlbnQgSW50ZXJuZXQgQWR2aXNvci4NQ09NUEFRIEF1dGhvcml6ZWQgQ3VzdG9t
ZXIgU3VwcG9ydCBDZW50ZXIsIEFyZ2VudGluYTogSnVuZSAxOTkyIJYgRGVjZW1iZXIgMTk5Mywg
ZHVlIHRvIGEgNiBtb250aCBpbnRlcm5zaGlwIHJlbmV3ZWQgdHdpY2UuIFRoZSBwb3NpdGlvbiBp
bnZvbHZlZCB0aGUgaGFyZHdhcmUgYW5kIHNvZnR3YXJlIGluc3RhbGxhdGlvbiBwbGFubmluZyBh
bmQgb3JnYW5pemluZyBuZWVkZWQgZm9yIEV0aGVyTmV0IG5ldHdvcmtzIGFzIHdlbGwgYXMgY29t
cHV0ZXJzIGFuZCBpdHMgcmVsYXRlZCBwZXJpcGhlcmFscyBzZXJ2aWNpbmcuDVNraWxscyBhY2hp
ZXZlZDoNQ29heCBhbmQgVVRQIG5ldHdvcmtzIGNhYmxpbmcNTEFOIGVxdWlwbWVudCwgc3VjaCBh
cyBIVUKScywgYnJpZGdlcyBhbmQgc3dpdGNoZXMNRXRoZXJOZXQgTEFOknMgcHJvamVjdCBhbmQg
aW5zdGFsbGF0aW9uIHdpdGggUEOScyBhbmQgaGlnaC1lbmQgc2VydmVycywgZXNwZWNpYWxseSB3
aXRoIE5vdmVsbCBOZXR3YXJlDVRlYW13b3JrIGV4cGVyaWVuY2UgYW5kIHN0YWZmIG1vdGl2YXRp
bmcgdG8gYXR0YWluIGdvYWxzLg0HBw1FRFVDQVRJT046Bw1FbGVjdHJvbmljcyBFbmdpbmVlcjog
VW5pdmVyc2lkYWQgVGVjbm9sb2dpY2EgTmFjaW9uYWwsIEZhY3VsdGFkIFJlZ2lvbmFsIEF2ZWxs
YW5lZGEuDUhvbm9yczoNVGVzdHMgYXZlcmFnZSAocmFuZ2luZyBmcm9tIDAgdG8gMTAsIHdvcnN0
IHRvIGJlc3QpOiA4LjI1DVRoaXJkIHRlc3RzIGF2ZXJhZ2Ugb2YgdGhlIGdyYWR1YXRpb24NU2Vs
ZWN0ZWQgdG8gYmUgdGhlIG5hdGlvbmFsIGZsYWcgY2FycmllciBwZXJzb24gYmFja3VwDU1vc3Qg
b3V0c3RhbmRpbmcgYWNhZGVtaWMgcGVyZm9ybWFuY2Ugd2hpbGUgd29ya2luZyBmdWxsLXRpbWUu
DQcHDUNPVVJTRVM6Bw1DSVNDTyBHU1IgTWFuYWdlcjogSnVuZSAyMDAxLCBhdCBTb2Z0TmV0IEJ1
ZW5vcyBBaXJlcywgQXJnZW50aW5hDUNJU0NPIENvbmZpZ3VyaW5nIEdTUjEyMDAwIFNlcmllczog
TWF5IDIwMDEsIGF0IFNvZnROZXQgQnVlbm9zIEFpcmVzLCBBcmdlbnRpbmENQ0lTQ08gU3lzdGVt
c5IgTUdYIEFjY2VzcyBDb25jZW50cmF0b3IgQ29uZmlndXJhdGlvbjogTWFyY2ggMjAwMSwgYXQg
SVQgQ29sbGVnZSwgQnVlbm9zIEFpcmVzLCBBcmdlbnRpbmENQ0lTQ08gR1NSMTIwMDAvMTI0MDAg
U2VyaWVzOiBKYW51YXJ5IDIwMDEsIENJU0NPIFNhbiBQYWJsbywgQnJhemlsDU1pY3Jvc29mdCBG
cm9udCBQYWdlIJI5ODogQXQgdGhlIHRyYWluaW5nIG9mZmljZSBvZiBUZWxlZm9uaWNhIGRlIEFy
Z2VudGluYQ1VTklYOiBKdWx5IDE5OTksIGF0IHRoZSB0cmFpbmluZyBvZmZpY2Ugb2YgVGVsZWZv
bmljYSBkZSBBcmdlbnRpbmENRW5nbGlzaCBhcyBhIFNlY29uZCBMYW5ndWFnZTogRmVicnVhcnkg
MTk5OSwgaW4gTmV3dG9uLCBNQS4gQXR0ZW5kZWQgYXQgRW1iYXNzeSBDRVMgd2hpbGUgc3RheWlu
ZyBhdCB0aGUgQ29sbGVnZSBkb3JtcyB3aXRoIEFtZXJpY2FuIHN0dWRlbnRzDU1pY3Jvc29mdCBO
ZXR3b3JrIEVzc2VudGlhbHM6IEFzIHBhcnQgb2YgdGhlIE1pY3Jvc29mdCBDZXJ0aWZpZWQgU3lz
dGVtIEVuZ2luZWVyIGNhcmVlcg1PUy8yIFYyLjExLCBPUy8yIFdhcnAsIGFuZCBPUy8yIExhblNl
cnZlcjogRmVicnVhcnkgLSBBcHJpbCAxOTk3LCBhdCB0aGUgTEFOIE1hbmFnZXIgT2ZmaWNlIG9m
IEJhbmtCb3N0b24NV29ya2luZyBjb25kaXRpb25zIGFuZCBlbnZpcm9ubWVudDogT2N0b2JlciAx
OTkwLCB3aXRoIE1BUEZSRSBGb3VuZGF0aW9uIChmcm9tIFNwYWluKSB0ZWFjaGVycywgYXQgQ29s
ZWdpbyBQcm9mZXNpb25hbCBkZSBIaWdpZW5lIHkgU2VndXJpZGFkIEluZHVzdHJpYWwuDVJvYm90
aWNzOiBKdW5lIDE5ODgsIGF0IFVuaXZlcnNpZGFkIE5hY2lvbmFsIGRlIExvbWFzIGRlIFphbW9y
YSB1bmRlciB0aGUgU2VjcmV0YXJpYSBkZSBDaWVuY2lhIHkgVGVjbmljYSBzdXBlcnZpc2lvbi4N
BwcNQ09NUFVURVIgU0tJTExTOgcNVU5JWA1NaWNyb3NvZnQgV2luZG93cyBwbGF0Zm9ybXMNTWlj
cm9zb2Z0IE9mZmljZQ1NYW55IHByb2dyYW1taW5nIGxhbmd1YWdlcywgd29yZC1wcm9jZXNzaW5n
LCBncmFwaGljcyBhbmQgc3ByZWFkIHNoZWV0IHRvb2xzDUUtbWFpbCBhbmQgSW50ZXJuZXQgYnJv
d3NlcnMuBwcNU1RSRU5HVEhTOgcNQ3JlYXRpdml0eSBhbmQgZGVkaWNhdGlvbiBhcmUgbXkgZ3Jl
YXRlc3Qgc3RyZW5ndGhzDU15IG9yZ2FuaXphdGlvbmFsIHNraWxscyBhbmQgc3R1ZGlvdXMgbmF0
dXJlIGFsbG93IG1lIGV4Y2VsIGF0IHdoYXRldmVyIEkgZG8NVHJhdmVsaW5nIGVuYWJsZWQgbWUg
dG8gZXhwYW5kIG15IG91dGxvb2sgb24gbGlmZSBhcyBJIGhhdmUgZW5jb3VudGVyZWQgbWFueSB2
YWx1YWJsZSBleHBlcmllbmNlcy4NBwcNUkVGRVJFTkNFUzoHDUF2YWlsYWJsZSB1cG9uIHJlcXVl
c3QuDQcHDVJvbGFuZG8gWmFwcGFjb3N0YQ1yemFwcGFAaW5hbWUuY29tDQ1Sb2xhbmRvIFphcHBh
Y29zdGENcnphcHBhQGluYW1lLmNvbQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAGQQAABoEAAAb
BAAAqQQAAKoEAAC0BAAAtQQAAMAEAADPBAAA2QQAAC8FAAA/BQAARgUAAFkFAABgBQAAbQUAAH0F
AACJBQAAmwUAAJwFAACrBQAArAUAAAYGAAAHBgAAGAYAABoGAAAbBgAAHAYAACcGAAAoBgAAwQYA
AMUGAADRBgAA0gYAAOoGAABvCAAAfwgAAJ4JAACpCQAA5gsAAPYLAADTDAAACA0AAP0NAAANDgAA
Ag8AAAMPAAAODwAAJA8AAGQPAABlDwAAbA8AAG0PAACmDwAApw8AAMwPAADNDwAAAxAAAAQQAABC
EAAARhAAAE8QAABQEAAAYhAAAJAQAACzEAAA4BAAABYRAABJEQAAZhEAAIwRAACmEQAA2BEAAN4R
AAAbEgAAORIAAKkSAADHEgAAAhMAACwTAABsEwAAjxMAAAYUAAAPFAAAfRQAAH4UAAB/FAAAgBQA
AJEUAAAQFQAAAPvy7fsA6wDr++j76Pvo++j76Pvo++j76Pvo+wD76PsA6Pvo5Oj76OTo++jk6PsA
++j75Pvo++j76Pvo+wDo++j76Pvo++j76Pvo++j76Pvo++j76Pvo+wDoAAAHPioBbUgJBARtSAkE
AAM1CIEIQ0ocAG1ICQQAEQNqAAAAAENKHABVCAFtSAAEBzUIgW1ICQQAWgAEAAAZBAAAGgQAACkE
AABCBAAAWgQAAHIEAACPBAAAqAQAAKkEAACqBAAAtAQAALUEAADPBAAA/wQAABQFAAAwBQAARwUA
AGEFAAB+BQAAiQUAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAA
AAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAA
AAAA5gAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANAA
AAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC0AAAAAAAA
AAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAJAAADJAMKJgALRgMAFiQBQCYACgAAAyQDCiYAC0YkAA+E0AIWJAEIAAADJAMKJgALRgMA
FiQBCAEAAyQDCiYAC0YDABYkAQAEAQADJAMWJAEDAQAWJAEGAAADJAMWJAFAJgAABgAAAyQBD4Qc
AUAmAAUAAAMkAQ+EHAEACgAAAyQBD4QcAUAmAA3GBQABMweAAAEQAAAUAAQAABkEAAAaBAAAKQQA
AEIEAABaBAAAcgQAAI8EAACoBAAAqQQAAKoEAAC0BAAAtQQAAM8EAAD/BAAAFAUAADAFAABHBQAA
YQUAAH4FAACJBQAAnAUAAKwFAAD0BQAABwYAABkGAAAaBgAAGwYAABwGAAAnBgAAKAYAAMIGAAD8
+vf0+vr6+vrv7ebd08vBt62jmZGHf3dtaGRf7VpSAAAAAAAOAwEFCgaA/v//CAoACQEACQMBBQoG
gf7//wkDAQUKBo3+//8HAwEGjv7//wkDAQUKBo/+//8TAwEFCgah/v//CCUACQEKAQAAAA4DAQUK
BrT+//8IJQAJAQAOAwEFCgb8/v//CCYACQEAEwMBBQoGDP///wgnAAkBCgEAAAAOAwEFCgYf////
CCcACQEAEwMBBQoGKv///wgDAAkBCgUAAAATAwEFCgZH////CAMACQEKBAAAABMDAQUKBmH///8I
AwAJAQoDAAAAEwMBBQoGeP///wgDAAkBCgIAAAATAwEFCgaU////CCQACQEKAQAAAA4DAQUKBqn/
//8IJAAJAQATAwEFCgbZ////CAMACQEKAQAAABECAQADAQUKBvP///8IAwAJAQwCAQADAQUKBvT/
//8AAgEBAAkDAQUKBv////8FBvD///8FBv////8CBQAABQIQAAUAAB+JBQAAnAUAAKwFAAD0BQAA
BwYAABkGAAAaBgAAGwYAABwGAAAnBgAAKAYAAMIGAADDBgAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA
AAAAAADnAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA
paQCAAAAAAAAAAAAANUAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAnQAAAAAAAAAAAAAAAJUAAAAA
AAAAAAAAAACdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAA
AyQDCiYAC0YKABYkAQAEAAADJAMWJAEDAQAWJAEALwAAFiQBFyQBApZGAAeUDwIF1hgAAAAAAAAA
AAAAAAAAAAAAGBgAAAAAAAAI1jAAArr/TwjMIgAAAAAYGAAAAAAAABgYAAAAAAAAAAAAABgYAAAA
AAAAGBgAAAAAAAAGAAADJAMWJAFAJgAACwAAAyQDCiYAC0YlAA+EOAQWJAFAJgAACwAAAyQDCiYA
C0YmAA+E0AIWJAFAJgAACwAAAyQDCiYAC0YnAA+E0AIWJAFAJgAADMIGAADDBgAAxAYAAMUGAADR
BgAA0gYAAG8IAACACAAAhQgAAI8IAAC8CAAAwQgAAPYIAAAuCQAAngkAAOYLAAD3CwAA+gsAAP4L
AAAeDAAAhAwAALkMAADTDAAA/Q0AAA4OAAD69vHv6ODb08m/tauhl4+KgnhuZFpQSEMAAAAAAAAA
AAAACQMBBQoGq/b//w4DAQUKBtX3//8IEwAJAQATAwEFCgbv9///CBwACQEKBQAAABMDAQUKBiT4
//8IHAAJAQoEAAAAEwMBBQoGivj//wgcAAkBCgMAAAATAwEFCgaq+P//CBwACQEKAgAAABMDAQUK
Bq74//8IHAAJAQoBAAAADgMBBQoGsfj//wgcAAkBAAkDAQUKBsL4//8OAwEFCgYK+///CB0ACQEA
EwMBBQoGevv//wgaAAkBCgYAAAATAwEFCgay+///CBoACQEKBQAAABMDAQUKBuf7//8IGgAJAQoE
AAAAEwMBBQoG7Pv//wgaAAkBCgMAAAATAwEFCgYZ/P//CBoACQEKAgAAABMDAQUKBiP8//8IGgAJ
AQoBAAAADgMBBQoGKPz//wgaAAkBAAkDAQUKBjn8//8OAwEFCgbW/f//CAcACQEADAIRAAMBBQoG
1/3//wACAQEACQMBBQoG5P3//wcDAQbl/f//CQMBBQoG5v3//wAYwwYAAMQGAADFBgAA0QYAANIG
AABvCAAAgAgAAIUIAACPCAAAvAgAAMEIAAD2CAAALgkAAJ4JAADmCwAA9wsAAPoLAADP+CAAAAAA
AAAAAAAAyQAAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAAC9AAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAA
AK4AAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAApAAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAACkAAAA
AAAAAAAAAAAApAAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAAnAAAAAAAAAAA
AAAAAK4AAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAMkAwomAAtG
HAAPhNACFiQBCAAAAyQDCiYAC0YdABYkAQoAAAMkAwomAAtGGgAPhNACFiQBAAYAAAMkAw+EaAEW
JAEIAAADJAMKJgALRgcAFiQBCREAAyQDFiQBDcYGAkMRhiIAAwEAFiQBBgAAAyQDFiQBQCYAAC8A
ABYkARckAQKWRgAHlA8CBdYYAAAAAAAAAAAAAAAAAAAAABgYAAAAAAAACNYwAAK6/08IzCIAAAAA
/////wAAAAAAAAAAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAABD6CwAA/gsAAB4MAACEDAAAuQwA
ANMMAAD9DQAADg4AACwOAABfDgAAxg4AAAAPAAABDwAAAg8AAAMPAAAODwAADw8AAGUPAABtDwAA
9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA
AAAAAAAAAADtAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAA
AAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAAuwwFAAAAAAAAAAAAALUA
AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAAKoAAAAAAAAAAAAAAADmAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAyQDCiYAC0YKABYkAQMBABYk
AQYAAAMkAxYkAUAmAAAbAAAWJAEXJAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAA
AAjWCAACuv9PCMwiAAQAAAMkAxYkAQoAAAMkAwomAAtGFgAPhNACFiQBAAYAAAMkAw+EaAEWJAEI
AAADJAMKJgALRhMAFiQBCgAAAyQDCiYAC0YcAA+E0AIWJAEAEg4OAAAsDgAAXw4AAMYOAAAADwAA
AQ8AAAIPAAADDwAADg8AAA8PAABlDwAAbQ8AAKcPAADNDwAABBAAAEMQAABEEAAARRAAAEYQAABP
EAAAUBAAAJEQAADhEAAAShEAAI0RAADZEQAAHBIAAPju5NrV0czKxbu2rqSakIuHgsp9dWthV01D
EwMBBQoGz/L//wgMAAkBCgUAAAATAwEFCgYb8///CAwACQEKBAAAABMDAQUKBl7z//8IDAAJAQoD
AAAAEwMBBQoGx/P//wgMAAkBCgIAAAATAwEFCgYX9P//CAwACQEKAQAAAA4DAQUKBlj0//8IDAAJ
AQAJAwEFCgZZ9P//CQMBBQoGY/T//wcDAQZk9P//CQMBBQoGZfT//xMDAQUKBqT0//8IGwAJAQoD
AAAAEwMBBQoG2/T//wgbAAkBCgIAAAATAwEFCgYB9f//CBsACQEKAQAAAA4DAQUKBjv1//8IGwAJ
AQAJAwEFCgZD9f//EwMBBQoGmfX//wgKAAkBCgEAAAAJAwEFCgaa9f//AgEBAAkDAQUKBqb1//8H
AwEGp/X//wkDAQUKBqj1//8TAwEFCgbi9f//CBYACQEKAwAAABMDAQUKBkn2//8IFgAJAQoCAAAA
EwMBBQoGfPb//wgWAAkBCgEAAAAOAwEFCgaa9v//CBYACQEabQ8AAKcPAADNDwAABBAAAEMQAABE
EAAARRAAAEYQAABPEAAAUBAAAJEQAADhEAAAShEAAI0RAADZEQAAHBIAAKoSAAACEwAAbBMAAAYU
AAB9FAAAfhQAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA
AAAAAADwAAAAAAAAAAAAAAAA1OgQAAAAAAAAAAAAAM4AAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAA
8AAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAA
AAAAAAAAAADDAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADDAAAAAAAAAAAA
AAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAyQDCiYAC0YMABYkAQMBABYkAQYAAAMkAxYk
AUAmAAAbAAAWJAEXJAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWCAACuv9P
CMwiAAQAAAMkAxYkAQoAAAMkAwomAAtGGwAPhNACFiQBABUcEgAAqhIAAAITAABsEwAABhQAAH0U
AAB+FAAAfxQAAIAUAACRFAAAkhQAAJcUAACzFAAAxBQAABEVAAAvFQAAMBUAADEVAAA8FQAAPRUA
AHEVAAC+FQAAIRYAACIWAAAjFgAAJBYAADAWAAD16+HXzcjEvry2rqSakIaCfbx2bGJYUU1IvAAA
AAAAAAAAAAAJAwEFCgaF7v//BwMBBobu//8MAhEAAwEFCgaH7v//ABMDAQUKBuru//8IBwAJAQoD
AAAAEwMBBQoGN+///wgHAAkBCgIAAAATAwEFCgZr7///CAcACQEKAQAAAAwCEQADAQUKBmzv//8A
CQMBBQoGeO///wcDAQZ57///EwMBBQoGl+///wgOAAkBCgQAAAATAwEFCgbk7///CA4ACQEKAwAA
ABMDAQUKBvXv//8IDgAJAQoCAAAAEwMBBQoGEfD//wgOAAkBCgEAAAAOAwEFCgYW8P//CA4ACQEA
CwMBBQoGF/D//w0BAgEBAAsDAQUKBinw//8NAQcDAQYq8P//CQMBBQoGK/D//xMDAQUKBqLw//8I
DAAJAQoKAAAAEwMBBQoGPPH//wgMAAkBCgkAAAATAwEFCgam8f//CAwACQEKCAAAABMDAQUKBv7x
//8IDAAJAQoHAAAAEwMBBQoGjPL//wgMAAkBCgYAAAAAGn4UAAB/FAAAgBQAAJEUAACSFAAAlxQA
ALMUAADEFAAAERUAAC8VAAAwFQAAMRUAADwVAAA9FQAAz8QCAAAAAAAAAAAAAMkAAAAAAAAAAAAA
AADGAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAuQAA
AAAAAAAAAAAAALkAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAicwDAAAAAAAAAAAAAMkAAAAAAAAA
AAAAAADGAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAJEQADJAMWJAENxgYCQxGGIgAALwAAFiQBFyQBApZGAAeUDwIF1hgAAAAAAAAAAAAAAAAA
AAAAGBgAAAAAAAAI1jAAArr/TwjMIgAAAAAYGAAAAAAAABgYAAAAAAAAAAAAABgYAAAAAAAAGBgA
AAAAAAAIAAADJAMKJgALRg4AFiQBAAQAAAMkAxYkAQMBABYkAQYAAAMkAxYkAUAmAAAvAAAWJAEX
JAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAjWMAACuv9PCMwiAAAAAAAAAAAA
AAAA/////wAAAAAAAAAAAAAAAAAAAAD/////AAAAAAANMgBBAH0AAAAAAEEAAABQAAAABgAAAAMA
AABNAGUAAwAAAP////8DAAAAAgQAAAMAAAABAAAAHwAAAAwAAABBADoAXABmAG8AdABvAC4AcABj
AHgAAAAfAAAAAQAAAAAAAAAAAPgAAAAHAAAABAEAAAgAAAAYAQAACQAAAEABAAASAAAATAEAAAoA
AABoAQAACwAAAHQBAAAMAAAAgAEAAA0AAACMAQAADgAAAJgBAAAPAAAAoAEAABAAAACoAQAAEwAA
ALABAAACAAAA5AQAAB4AAAAZAAAAUm9sYW5kbyBKb3JnZSBaYXBwYWNvc3RhAAAwAB4AAAABAAAA
AG9sYR4AAAARAAAAbWljcm9pbmZvcm1hdGljYQBwYWMeAAAAAQAAAABpY3IeAAAAAQAAAABpY3Ie
AAAACwAAAE5vcm1hbC5kb3QAYR4AAAAeAAAARGlyZWNjaW9uIFNpc3RlbWFzIGRlIEluZm9ybWEA
TWkeAAAAAgAAADcAcmUeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMABkQAAAAACm918CAAAAQAAA
AAB2CtVYncEBQAAAAACaKdk+ncEBQAAAAABWP2q9ncEBAwAAAAEAAAADAAAArgIAAAMAAABIDwAA
AwAAAAAAAABpbGxhcwAAAEQWQwA6AADwtPW5fuj1uX49FQAAcRUAAL4VAAAhFgAAIhYAACMWAAAk
FgAAMBYAADEWAABJFgAAShYAAEsWAABMFgAAXxYAAHAWAABxFgAAhBYAAJUWAACWFgAA9wAAAAAA
AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAL6gAAAAAAAAAAAA
AAC4AAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAsAAA
AAAAAAAAAAAAAL4AAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAA
AAAAAACgAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAADEgADJAEDAABAJgAIAAADJAMKJgALRikAFiQBAAQAAAMkAxYkAQMBABYk
AQYAAAMkAxYkAUAmAAAvAAAWJAEXJAEClkYAB5QPAgXWGAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAA
AAjWMAACuv9PCMwiAAAAABgYAAAAAAAAGBgAAAAAAAAAAAAAGBgAAAAAAAAYGAAAAAAAAAkRAAMk
AxYkAQ3GBgJDEYYiAAgAAAMkAwomAAtGBwAWJAEAEjAWAAAxFgAASRYAAEoWAABLFgAATBYAAF8W
AABwFgAAcRYAAIQWAACVFgAAlhYAAJcWAACYFgAA+vLw8O7s6efp6efw7gAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAINAQAFAhIADQEDAhIAAgUAAAIB
AQAOAwEFCgZ37v//CCkACQEACQMBBQoGeO7//wANEBUAABEVAAAuFQAALxUAADAVAAAxFQAAPBUA
ACMWAAAkFgAAMBYAADEWAABHFgAATBYAAF8WAABwFgAAcRYAAIQWAACVFgAAlxYAAJgWAACqfQAA
rH0AAK59AAAYfgAAOH4AADp+AAA8fgAALIAAAFqAAABcgAAAXoAAANqCAAAIgwAACoMAAAyDAAD7
+Pv4+wD4+wD4APj18AD18AD46wD46/AA+Pj7APj4+wD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQ0ocAG1ICQQACENK
EABtSAosAARtSAosAARtSAkEAAc1CIFtSAkEACIkACZQCQAfsIMuILDIQSGwigUisIoFI5CKBSSQ
igUlsAAAGLBTAwBuHvBkRwAAbelgwit03ZSlBS7fHHg7Cf+JUE5HDQoaCgAAAA1JSERSAAAAYQAA
AHIIAgAAAMwmKMEAAAAEZ0FNQQAAsYiVmPSmAAAgAElEQVR4nEy8aaxt2XEe9lXVWmvvM93p3fuG
7jf1yG6S4iSKkgfNFm1J0ZDYiezAgm0ocoRYcGwok2EFQQw4/pMATpDYlvJHQGDDMOBItiRIsITI
oqOmCYkRRYpDs9lk9+vuN787nmHvvVZV5cfap5sX3Y37+t17zj5r1ar66qvvWzT9P/5tKrakIOyD
ghkGd2aYgQKgKIbIcAMARESCKogAAASHCAwghzkYZF5gQGR2GCBkxMFNjdgNDBMqAWHDvPByYQFE
sAIlkDObWQATVFkcTkaMbMTeCAZyeCIa3AKCswVmz+5X2e57IFUurmQwEMjMQSCxRQgoZeOB2Gfg
DLDbxn1ubIzB7YqXdwp2WPYiHwmeZO2LbYw5cMtqCgr/++/CSeFuEGF1AznUwYGJjB1QZEYgqAEE
YRCDDUoQ58E8MWWyBLiDACUAYGeGORMsANkRPRjU2J2JDQagKAczI0DgCgRQQQE4gAcUAjuc4QYn
qtsUeVZsQ2ZgMncwrD6VwQahZCB3QC1QKRTICoPUCZRhAieYwZkYDhDIXaEF5gAjW913EMEdAATM
zEZIpMQgZrjDACUIA2akKBmIaBimYAMAI4jBCaIAmbAbWSxAAREMcAU7QHUdHKEAcOSgSAQAVmMy
I4r1AmLAIQFU4AAMyCACCTgAAAWwu0MaRM0rwIzZjchBjuBgwBk0VbgbgwhkBQJiR1RmGKABTKjP
xXByCDscitTQ+EaBkRjCIMKEwQxiB1iANeAKZ1MKCIQgcEJdMhEUrWGFIGAGA9lBChVA63ZgABRQ
gABhKOAKEyYLnL1uDkiLOhgMJg8UQIyJwxjMAAAGAzGCBJ4QCFzgBmYIh8SqsaSIKIhklIwZYCgD
ABPYAYbUrWHA4UB0ENeIQGYIwxOIwAHmcL7a0DAwyGEACOaAgYAeiMzEIGIlIhcPDA9gR9bxPdzh
AU7gGnuGAkDBgDuKQBx100qBCDjAAAMc4LoqahlFBQ5YgRtMAMBghEIMG6ACMpQCNzjDAowAgBTm
GAjOKBnwYgJVLwxlZgUyFOOHB8EKcoE51AEDgEJwRVG4AgWG0BaojUupVn/3vgIM9AYHTEHjK8KB
Yubm7kxEiA5juAKABMCAAgCJxoDSjPrlAsoQgTgIICA4nEEZXMClBsy4rMRIDAIECAHOIIMYwDDA
DBbBDmEwwxzIEIU5nFAIIggBgcACFWgBHAJINmsBhjhgcIAdCGMw1gMIINL2jQAEGJVexlJDQKgf
x8EEENoAcTBDayh90xeBiYg8SfAxHxGDCWD4Nm/VgyYEIjABEbRNAQAKEAhI0ABi1GI2fjFDAYNt
j2FdfHeow2mshV4XlACBEgJADjaojsmRDOSAgw0DwI7SAw6PYGxXwcc3KAYFCqAAKziCHIHA9S3q
Pw443MGAMVjgABOigB3M751cMBxBAYaihpwxaslxhwAUEQsK4ARSiKA4UH/Mx/cSYMw3VqEAZPwW
bFb/QGN4IdQPYyAnIYJbCPCIAgTADA1hUJDCI0xhPr67KchRGDygEzjalDsN4xvV7aYCDrACEiQD
CGqgHAJKCaC6dQZiuLMFY4Fvbjf8RrZxv93hGCssGG61OoWarZwx5nytbxZBPq661FVnwBGwjW3A
FE4oQATcxmetu1pfTQFnSA2WmuYEkcAEiy5Em/P24YPDcnKyWi+8n3z+zX5gevCOvf2YLs9852b6
0++7+9TtPNtFK9AGGACABmjoLMAUAch1PxTG4zGHj2lUIooXI1CPCkIIKAoR8/qg8Y1ssAAUkIAU
xGCACXV/iQEQ/+P/lwCtGUEI2WAEdpCDIwIwKAQjgoBvz1BdFAIZlEFWccd41H3c2rFa1ZSEiDKg
O3t+eV/u3W8fPGm+8ZbevbO592S2f3hy8sUVLgA3gLAzwVTgDfaJSdK+/eAnv/FtH17Or2DK6Aqg
I86on+RdlESGAgij2Jh9qQCAAmYczQYey64UKLOYuYAducADvIzopx4F85pYif7JK2Tqwm4AEXIB
A6EuWYQzvMAIVAAGM7yMRbpUDEQQoABisAouDAoIwy2IFxOIoNfpo9eu/sHn0qc/3T25MNwZ4IKl
ITo44TBAetxZAnuYM5Kh67AGkIEC7OHq808/8/DgA6c/9CffvvU+pICur5muZojtehG0FuUyPlgu
kAitGc3gPIYYDIjQPjSh5AJjYEARiAEEY5hCCHCYE/2TVxJKb5HJzG18iVyPJCMAxcZyWE8/14A2
mIEE5tsU9k2nLIxpERaQwq2z1w7+4DP2r3/zZH3PMMs4EWwI6AAADWCgAHEIjzUcLeCgDo4tlpjg
0stH7xu4v88vf/m/+Au4eQNDQd+PoIEB8zFX1ANhts1Tikxb6MSAggVqiAwj8IDMKAYnUF2gd2PT
QQVKRL/wihMLoMVA22wPgjokgnyLGvib1oBHkFOPGMu4MzXO1REcYHBAE69+8bdu/It/sfrGqycY
CIkxy7hP3/RyAezwHTzvePIYxwFoQYxJC49wgyg2x7A1IMACuwfy9Ik+OHvpp45/7kcRG14PZrWZ
UKhDAakorJ4UIADrgkagDK8/AAghF7iDGZ6hFe7J2J+Cx/TiTgyiX/g0DAxTkRFHweEFzhABMVhR
aKwLBhDDCYFgNsJTroWcYQpjiAAFkjBtLv3eL+//o/+twDZYRaSAaYdHPTDB+Pw1a7WIe3gaOF6E
W1057nGfMLm0eG73aFIunjiUEHOPR+cn9/FkBb3FL63s0RPwxZ/4W+u/8j0IEV1FAwZ1gMa0Ehhe
8Q6NiQmMAgSDEoIhA6RwgoOZjQx9bdfDiFaCkYLwi6+MuRaOYuAAKRgczBCC6wigqQAy4itzcC3y
GR5BAJWx74WBCCpI8eYf/+rBP/zHj0ATsKI9IDr2x5dxc/8AcbXJOrBo7rVDD4TFvu3x/uFLT/Gm
9zZEuHuR2bydtdKmvhxrR+f3n7zz1UcPLvIJlhmzAXmD5QQ//M7f+xlcO0RfYAAZIPACdRAQBpQE
r9tmGGpKBbhAI8eNoUVvQAETDCgOqmnIwAIyMFH4xVeISi48hqgaiEBbaAeABAQUq2uCSLCyPXQC
U3AEFGRQBxGKYTa//Pqn9v/+/9SjBEhC3JHdNNXu4uTKtcOrUxuIj27u2kp9NsXyJE7nRzeOdq4t
tOOcL5gEZSPpMvlmf++p6YzOL7oiw3o9LDe2eXz8x7/xhT9avvkImIEfwRjfufkHP49LLQYe05A7
1MA89t6uGAQRyAxSkABlbKSiITuUxkZPCaGg0JhPCZCajwAGWUWGFRpUhE0Yj1XF04IthiawQXnE
hxBYBvmYj6az2f3PXf9v/86A4wuU5/Hy/Pr84uHXDxf7128dHF7Z3b05Xyx22hijM4Ch70XSoomT
NoUUgsVhMzQpWTus1wNLOHl831OMzXyxk9o4PVvnu8enT77+4Lf+5W/+PtaHwBlw8dz/zH/jYxbD
mFJrva8VZizqBc5QgAxUA4QBh9UtBwZHBAAUAmpZ5JrFAxFNgRXVhM/jKnAFqQx+t6+o67p93Xrm
qR7bgmIIBAmYTvDWZ6/+/N9eootY7KEpWK0fnX3w5q0Xfujbnrl6eLQzdR8mcWgQ4c5ouAncNIQI
6SMlU6JhUCe2HoeTzJuj/Xmfu5KL8m4k340Srjx1+ej60Uc+OPvv/9ffxpkA8YRzrEFkcIH4+NC1
wNR2yoBgKAJSMAGKXEKgwoDye7AuOLRC3wI3hCD0oz9d2N1p7CSwffVay8IWcWDb6TGP1Bc5mEEO
r2VVMJ+kV1957n/8Xwb0LXbX6OfgeZu+589+4v3f+8Gbh3v7syReUkKDREGIkZrZZLEICTHGSIFY
RSi0KTDH2W5sIzU+a6ezeTvb2985oJh2mzQwmn7TNdQcfddH0mcevlqepM09Ty/bzYPxkWAohOAj
5+U6PqfWYicAwxRBzBkq48nwSm8R2FEcFMACdvEf/Sl3GZsvbDNR/QYOdYR3/yeA2nYw3L4JIjgA
pAnO7tz8uz8/Qdvh/oB+jmmE/cAnP/LSR1+6fuVoEkxCs7ezO5mG2Ewmu20rTQqtpARuQhKZCmIb
UiTyEJsQxWImjhyiqwZxDhIZ7pFtYOZiOgu7T3/y4/w7X31dX128+iv8uWfz99yAC8IW2Y6fyGEC
cjBBGaGmFEIIgIMdCkDA/l5bxzImJDehH/lptrpEFWJgrHFcsXz9uW0cWT2GjrDt4EfwymjD5X/2
y+HNz57jbYcQJjPYX/5Pf/zFD96eTuO8nc52dncakbZNbQyNiIMk0jS5RIlOBOImNQ3ilJupTBfU
AMYCEqgSUyjg6JRYDJZjmgYqq27Flq5/78fe+e3fPYfp6nfKH37Iv/vmSCRFhm7bogrJCsYHJgMb
OozVmcJYyxBBhjx+VHghJnaGcS3pDAlggjAMKFv44/Zey7qtZsiA4D2GJCRcvDX51K8wuIDmeG6C
+IHr77v87GTSTo52F4udponEiScNYkoCgqTYcODSNklC4qblNvpswe2EJ8JsAKOd8rSh0MRJimke
QsNsIjHOJtLKfD7f30kLKZMeP/EzP0nADJjd+zn6g2MIgRnZEOy9LAGMlBYDAqig8Tb2sHrWGEyQ
gsJIBGe4IgYHM3n9e8AUGTAbX5oBVwQGC2Aj6Tcet9qOVcjNiJBpfPo3fs9w7xiP5rh6ePXpPdl/
5sPXj+ZXLx3OJ4tZkBgip3YuISFMYjNvGnDcZzlwcY4TTjvULiRMmZhpiph4shti9GaP9y6H2RSx
IQ7CKp5DO5s0zJL3Zml3TxYt7V+/9h1xOsMzu8CVf/Z7CAIzRAZ4DICxoTP0BDcMDHJmdDmA3k32
QC4gQCuFFJAdDian2oExM+KWYYKAZOy7RuINY42rIwV7N7KMpbHhLP3b3yyY7+Ey43T18EGKevND
z873F8wzDonb0DYTTuyxiZNCqZXmQEQkhDA5YE4iBJlymEhKiK2ECTdTnu7KZIF2B+mAJvOw2Anp
wENL0sh0d7bYD6ltY9hZpGjpo//xtxuefPCF7z8c/s3uox7SwAwOCwGBt20mgQrM6se07XQDRMj2
/imN1IqVkRRiBiPURn5Myu8GS62F5t/ET2PkmdxgYAKczBWDk6A5PcHqtc1Ir88v33pqlpaTSUwS
wyyEOEzCApOWSZkZ1pAQhwkHR0rg6CGYtCQDgTTuJHcVl8DeZQuBS2/T/ThsdDn4NAYT52CWLZIk
TAgl+850cvWFjyT8zoXimdsHuH/3bO8mrBKnhsqiCcMMHGAGVjhtWa4CJAT50rogB7CCCAT0hoag
zsbMJFT/ZQLVfFZGeqEmtUoME1BXlmFOZmVOgiBKTF/9ygk2LWLA7hQHVz54cOWpSwe7eyYDmzGi
BA6iZiGKS0rE5tFBqm7GQdrLzfwSIzlroKEIOER441Ec5CGyrovseZyGtBsX+yRZV2vrzmPDRBxZ
d2aTSZq8eHilPz350ht/sPPmQ3Aai0+l5AVQrSTkiIrH8HFwGkGPRciYq1AAESgIxAJ3FDInU4zN
jIACso9LouNpZgfYrRKK0QFempGQBPevPo6IhpKwSDi///mv71+/FlNMcRZCaZpAbWCWmOAxuq05
NQBMjC0HCdSIo2dqODAoEjvKYLYxRdCBCykFsQHSl+7U8rkqccvSTthEUopJYjxf7O0+9dwtXZ6c
4fTRr34WkJHPB4NlHBq6cTA4oAJWeCVRdQwrzuACHxAEoXKbcPc6jkNi1gqh3UcwGdJ7PD8JpM5I
wkjUKkItcoV0GNL56QY5oGUsGe3i8tHu0SLCQxNi2nMqlF0EROyubK5F3LM5IQq0G5ZPtMvuSxvW
RgTq3AdWY637k8nM0JNG8876PmgmCjAh6WBrljby7k6c7H3kNg1agB6fkfMeVJuk2oRTLfCW67hN
gQhTaIAIKMAdHOEBHlAExWECZhAxwYNxrqiZiUOAMAhMDg6A1paNJW75kHFkWNiJAgdGsPxIW7QD
dImuICNIjN5nJdMQITxzcUdwdxgZBbEzB3OYwQiuUoTQW7f0YcD6CTombh0D0JsW2BqbY2RkgngE
B/jggQvDMjFPmDUki40eHN5gZAcGREUDyXDZZgkbcW+s3YnBHCFAto2bGKyA8rupF6icP9idKhHM
gMGtlEohGSwYpBgTkN1qiGmBVt5ghJlOkELlYAKA4IqOQN2D49OulDyIewjJ2RASJwITmzqKc2KL
jILYclogkhaV0JAapIEXG5ZUDCXDBwZ5nLI3EeIpujRo9qFFvAeZ+QqevS/JMGsndBAEkDp968N7
g4xal1WggGMc/JEzC3IGBMYwgqdxMsY8JnsGK0EJqsUV7tuRrANGhVUlmRALwQrMRo0HEQxsZFK8
qJXMFIESgAgY6OR0vXnnjNklRkRhBECtL2zZuGGZsCekXjk2op872TQpyeRAeMd96iZs5l7gbA5z
RpFA5qF1kFMTm11n1jBxnnA7dRLnECYNC4jL+fFZBgY8DVdMCHAQIRhYGHXiti3cAMys0q3QUQoh
BBE4jUNKEgIC3MSAQOoYV6dWcAKKIxiMjSwwige4gQPcmMnhKBGWSai7tt/+oSQkRbsrBxfHx32n
FFtODZfBCVSIWrgL1DiItxNXRJlljt92mPrQEiWfNHFipieUmZGpmYjP4Obk8D1xHXMZ9RJjoqVJ
0BxTpJ6g2hOavusf4zwAE3wcc0OnT6VwVwucATMDWEb+WxwKECNWIpzAhTmab+doqu+KBgIDyhxd
lQmgOevSGKgT122jzFQssDs8GPXg1jwzk7lJaCx5TCmhGXDSYu+uvraGlqy78z2OwdgxDJ40+4Q5
SQgcp8TiUSATSdM+JGKhpnWbeMls0SZOZe1wogmnmZk4dcgqFEg79IKGRUi6pfqmQNxNiDJJ4KYq
My4k1ENxV8c4AG8HXAYEBwliwVAHBAAThmA1l3OBEjyArCKH4MREOtTJh9myDohGNq+A6+SWq6AF
pDCB58BQQ2AUUnLOWXusG1DGOWMg7ATZiU2wPLhnBAFFoZRXS0p7iC6qHDgFMj1lXfBiz9TJ3WMC
CEPPzdSKIwSDEzrvHzMRwgK+XnZPLs7OqBQnz+tVKXHWUDbWkoeiPTAHutsH42CdHJoRBYNtCR6D
BkhGZnAGAhSAc1tsE1EcFBF0HLIL4B6YkJWYLMAGE7iOjRgAEbhCCSJQY4E5gwlWigFuBYTiHmyh
fYPgaBL6DnDIYqcNgTTnrEWgk8Xi0d033rhztrM7W/aDDqePT04ulkYhfOxDH332+RcXl65Y4EBQ
mYPEoIRsuSOaOQqUzk7e+sbrX/70pz/72tfunb1+b7ozeenjH760Ow2puXHjxcOdZL5Zb7ABDiDl
8QXOzjGbggvQwDJIoAbhkd7JAjIgggli6N26MJ3SesMQgwcIoDXzUFA3EJhpUJ4mX5dtMqoSiUoG
WAa7DQoiRK0SPsCrQoVWur40bbAzARVsGBhwni5NU4hONGw2Iaa7X/7819+6U4b0hS+fn626O1+9
x81u4BCo/+wrrz3/zNGf+eFPvvDSi5jsULN0wNRYMhlMOlseP777+Vc+9crbdzb333h8eHRt72PP
nL11/8FXX8czz+dy8s7d4+efe/Gpp/bDpDsCOmg5+5W9L9w+++5nfeMQhfGYhk1BBPFRH1EUyiCG
KJzXvYEq56GINPLZ6gEgdhQPQF77u2IyQBXCcIZlgOCC5FBwNquTAwUzm4vbkj5/N2JdMBWEDoNB
J5MWIqYX/SD333pzedFf3X0hzdP7JaZZ4v9QmtiU0juou7iw0vWPvv544oe33p+kABpkx2wDR1kv
u5N3No+O33/7petX+/TtzXyn5dRSYBpAnEDl9TtvPrh3Pt1ZzNrDPM4v37GHg5sg5pFCYoySmIob
A8Erfw9oHSwb1MAC41H/GQgMFAsgMgaTIkqVYY0YKghUwbUWOOBMbGLGjDKScObKTD6Z6cs3z77A
CwyMKEDCngeLsEEjJ93bvXz95qzZ3Y1BphPvN0MZelex4svzC3Ijl/39K4ktn99hfpqbBiGKpr5c
+Pphd/pwudycHefZ5ODo2h6bl0zDxWNF2b90FW370q3npLmXM2KMAkQcKa4d39gf+dnK/NcMqzoS
/rYl/yuBzwzTvQlO11XGWPuVSjTW/3glLB0ex5a3kkf87jcU2Op0cpxtWiVM2Ip7GXwWvvf9f+ky
piucEUCwQYmCgFzIF4eXD65cmzXI/fGdV7/+8I23L+6fDzCJ8xQ3u32H5fL80fHp6VC6wW2AtBB2
6qlfXRw/vvuNO8d3V3s+7Ek/SHOidv/0UVEZVv3bX3+9bIonunzp2qVZaCcNAwMeBdzApYhsQIEV
mMJ0VGxiG1ajhmKLvz2cbgLERp3Ye7NMD0ZOlUAwgHQUFBCAMOpxQDAvo7CIgAACokAdBUiEItd2
dn/sP9j/9N2nTk83pzhp0DdgysqhbaMGFtN1Hk7O7x/r4I/uvfXpP/zDt1999PDu8PyHvv07v+/F
m+VBs3Mom835CcV2SSziautH+fT84Z03dL33VPt2N1z59N1Hv/Rf/r27WFyHffTP/OiHX/BnP/iB
0m24mexMJGI63YQGOAXm8+/EjX2QwoAQYYoQxlAyB4VRxOkEqdo1ABkcRoVgVYVkQzRULMgOIubK
IZAjBJCACIFABCcmYgkjnVTBvDHUWZiKQ+L86KmDYfmt/9F3/ec/9vEr2HNIlBBinMz3FweXZ4up
UtZus1w/+jef+u3fv3tLbt/+jdcenN7+/lVJ3/IX/9b8o987ne4ePnublo/Xxw/89HE5e2Rd0M3Q
XfTXroT53ovX//zPXvvW923w7FPf8vHbNz/6k3/nvznZ8K/9q187OTvNfUcxNVPZm0+P9q5eQrP4
MGO5GSfslRWrA2c4iBEA6DiDrDomA0KAAckRBBxBEYlr4WNm9kgQVwG7Q3leSQPZUrHszuzuAAKP
PCS7E7OROwN52H3zG9/33X9qU+7feauLPDP4rAVRJJbIMU1adimdvvPFt6617//r/8kP/Pmf+NlP
fuvupS/+2g/9jZ+5cWh7YbP/0ndIE0psyqYYkq43WJ269oFDDvMo2V79rZeOXvqhP7ez84Xf/r6/
/XPXwsmf/ej7nrl67fzxMVlIU47EE9Ldy7O/+tJf+dOfmKPHNZK/NDWUrWqvqoDrHE0LpFKseeQe
wSBFAQrDKs5G/RXhH//rcIYjQIwY0QYlOBKrGhGBSWqDR4ATs5A7QdwNe+xTCZui7zs//ssf37ly
Zed4c/8rX7sQnX7/J//kzSt7YeNxlzg2DA0U5tevPn00zw++Osv40Me/54f+2s9+4Ohi9aU/PH/j
Ledm5T1OT+bNjlgfREytPz8rm25VppNrt7u3v5r69KGPfPi7fvDPHW7ubd760vL89Mr7nrvy9NUw
b6fTPQN13fCgw1/7q9/75iP/lE+WB9M/pjD2DHU2UXUf4Pd8CvzNKYXHJAWMgw9mwEMVAABQLxyC
FjDY2Fqm7ICbCUirYInHMUkADDvsp5WC6da+WZcTHB7c/q4/9Z1/9O//6Ne/aIf7+6oltoW0sbbx
mHhnuk+li0HXm9y9vcAEp597cOeJGXm716/u77aTFCfcRDM1dSCLtJP5XiznT976UuuT9aPX2ylP
28lqNjSy4KuXmunO3mJqHIu524o73Lp8c35p/mjmSC1KgQKBkOvYyOH1k4/DaMDgWy2W63bgaqMd
YJSiIrjDFVGQJUAhgLJDcZ4V3tCEwoBCHs0yChmb1DmKnbOImcIxmX2tXSz5cHLt1ouXwg9//8e+
8NbXmslESJzhIQVyS3OXxLGdgvrVeujOaei1X4vsBwmIzWQ35Qdvoj3KZSPNlI2Kl67vppPdsukX
l+cn5+vG2pL7FGj/0nUi3W8S0kLalhTUbbJP1Y8//NzT80sHG1+CeRysGm1nau8q2Gqxr2S0j2KQ
Gm7aATRSTqNWEcEJBMvCjVvvgIGZm2AbTU2gYaASnYtmJ+HAUFMB3AXR0FK5yBISv33x5MH6yout
5G7yAz/5X11M/u/gcFVQ60OfvYikEObOEdalxSTOZ3r+KBenRdtO9kJThtMzxEtmZ7rOcXGZIpPN
BKebft02c6Zw48Ub3cXQLS+glhg0mzXN1JgZ7i69qTNc0mQyn6fwwkHYFi8f3UCjlrQyXgSyUCkj
i4DCHeyj3A1b+VFdSjeurLUXDAbi+kfbgG/E0ruBnLVYIDgbtCCauDJAUODC+XKywgEHBxfLDXfn
PrvNR0996BMvS8lDUQJ5T8E7AsM6KNgjmWBzQsTTo8VsupvS4Os1h1mhbnMyNLMFc1+Wy1hiCO3q
5HGZtECmIbWzdufq/mQxZba4elKWx9713hf0HREkE8XJulsu33nzxu7h2HgyIVtl8UfmqH5vKIXN
jDkDBNlO30IABLZNLMXgCMGhAT6OsA0AEULBWxxhzgGqoz47Gg2e4ULs4qxmwvKwKAts72g5ZHv7
K7pQxTQ28/PNue+0rhYm0TEldwcJNijGtoKnKAAnSQks3JD3x2dffHL4zPPzySHgoTlz62f713Zz
OXvn4bUPvGxqbCxBwvygmAEzcdXcmfRm01CoMJj05PTBQ02r5jasCmicI9uoaatQG2AbaUYXM4aW
sdkqZYQFoLFNoW0cmSIJ03ZSHYFMFqviXZUkAIGJM49yXy+ezYhMVTlICowmXGinzf7yjddW9+5p
k5wDNw1k4iRw42KcM2VmlcAHqZ3I4lJodznOOM3T/ODkzW/sHd6a7OyjNQpkwl46ozw72NM8PHrz
7ebSLk/3qNkjFk6XeDpnZCqBlqLrLjMHArQQkh/degCGCALBg3kdkHhFypAKmAtAoABmxBpgjsij
jIKB3rbiAOdKwgEQMxgFQQJILZtzVXM7mM1gRAwJHIiYBCLMzOymgxtiWq25yCI9c+3kG1/VwrDs
eWOUKRQq66KDZ0cGc+tx5tIauajcvnwAACAASURBVMeAZkq7e8u7r3K+tHPjepglYEC3jrOr4cr7
Ai940j79wsthud6cHPNiKoEgia1Iz95e9RA9O2uhrPBiucz3do5uHtxoDa5EW52NAaizsarjqKxy
BgagQ66it0rA2tjSN4zA9cQxgGBwU6Zo5Kq4UFBkNmetpVDNNBhXN567goOyFydjjmA3QPjctNus
0v71p156kcqyB+m6iMHWZsrUdbY5R+lcwK6EGMIux6kF9v5JebLZfeYW4mBmTHPsX5Vbn+Abt7HL
7E27ONx/4cX+dO0+xfSIE/vF4MJsGsRAgxvppiuDaxkaCOeh7XtEcgekGgV9qyjeFn1WII6eB2Y0
vKXMGMWQtwJ5NxCFFui5qpg1IrgM5mKkRExJWdlEolAuRQhQMxG3ImCFwmhwiEPZ720G3WRfreKl
y/HJibsTOal7MGR3kKw7zBfirj5QnLoPUEYzp2HjkbrjexcP74fJ3t7TT6fE+vhLtD7LZbj7jS/l
tR/euBFAGFZoBWFHrot1D21Q3/QkU3hB6YuKsi0vVsv7qw/wEHGYqysH2Pp3MCqrSw+OW5NWGPVH
dY2qHkYzPI5UJIOZqHLAYBusDIVUfOZBksADA5GRcxY3N/OKPt216E1mdopAIgb47TMLzn5xbu/c
m00XG80Wogt5yRRZxGhnx1vrGI5EoZAVhMR6bNpNd+bDnYf7l64n48dfeU1PHtjJ/dxtTr/+qgyX
bty6pg/eITXtHlq/8mhGRnFGWJQwM+/JejA06GagvcMDKsvD89W3SxrRsTnQw2gcRhqDEmyLh7VA
C9zhBCuIgARIGPVa7lAPVR/hBoMkeAYo2wUjDF6q58GUJXhRExIbnbBIdKcfxDnHUEwR0heOjxMO
7HxJh0fz+IQIFkpWE3ItWVVDUPEYSb2Roc/BVIRVnTYDT+a7Lz43PD7l1M72jh49ejAB9axnm/m8
LZuvXaSnb7UHcCul75Azx8gc4RdcOgwlMwaQDp6xmk4PDvZmD5+kV9XQCHqDELwZwRELoDBBqAYX
AgRWhcdlFBRnRSQUbEWyHoo5O0BIpl1gZzdnMBdYYwaEwZwiiJ08KOVqoIYCMQXgGdOvkVCIXzw9
/8xr937wE89hl774+usn3SRv+j6VOGERBhNLLAEwBCstYUixrDuUQUpvPbnrutk9z6c7RM3lZwi9
bDbzmRcteXYYI1nu1ZiiGbmrN7HzNvrqXEWAtZe2cyJMfvczn713ef/X37z+6KUj9DaqYN+Fkaao
JhrCKOkMBpdxcDIq3wml/sqYwLg4CjnDlAO5RI8CSq7RCR4ULgRWVw9K2maHAB6qL643/5ozHEgJ
z1z5kf/uX/2jf/eFf/rrv/3Jn/h/NtGJQ+/9MGzMvAy9uvPjMxBnpYGnZWND8dLZxcpXeTgbdO0a
ZwcmzuTCodnfL5vzIs2G9bicPn7Ury/WuVN10QFdzkCHvV1eRKXWW87odubTX/7X/+7H/+tf/D/v
AJFAMubdd+0sY3+L0e0AglE11o7qJONt//quTNZDIgyl9JwOyVYiqpgzBgeBiX0YPZfCbFDqgoCq
+aEafogLqpmebjwjWPzN/+GXAAUWq6XLdY7FsxDlTiSWYZCkDpD2RU0ZfSlMA5p4sdyINLO9+XSa
EBbIG3amJuxeuz2s1ll82Mw2cZWpofVmnhaFhnbIHichyaZEL2TdAHWUzUXzQXnmx/S7nmPbiu94
W9ErPqremRoyo2Qto2egjC4ObN2cNI55QzYvFBuzMyIvxcBnxhPwmh1Ao8gJyWDEZkrErgoRwMwI
bsZERFDH0Y3yd3+4+fuL8vJzOu0f3LugDx7Bs+XkTeu2IoreTjm4eszFSWbtJOTOOIY9XzSLuciM
80D5AhzK+RMaJjttYzN1meveer0M6zJYaKhpg7RmPjhxUVLN5IYum5dutv6pn9Fd5pItF+hIbmxN
QNtJPQosjqL7UWKtMIEBIjCFGISQR8lw9Yp6Jg8mHMgcEWUDZgOMLbhnUHIqakzkPjqLCAGsQUjV
i9aBvrz8sf7/+gi3U7z2pU/9zit/8btvzhgQ7Yb1VNgqz7a2QabZKITB+qXbJi4R4lwfPSynS1t2
Q9dLM2sn09y/vVqtHcTNjBdRWpmwbGytwwU1cSjahJjdFQIn59mcTu70/nXL6GDDWPPrTQNjr18d
Hczj/RcjVcRjLrcyuvCcAcFgCFWtr6Ha4gwS2TIoGCgIjeavQghO3ql5IQkEdzOQkJkWInSDS2SQ
qcKhkBlj0/VI7efeOD8+K4u95Dmi4WLK5C5NohDUpJ1bfrR662vnb29Wd+/lJ+ctZk0I0CF5Q+Jh
b5eHYb2+KLnPMRaS5fps+tTT7bNX9256nC/aNqqza8m5GJNpB/O3uzkm23mGVEYRo2mydvzQ9/xI
lR0iR514mkB09Lu4jhYbGICglbGEZwMIReBWBFTY4XFwb8C92ftb/9Kg5OyGepEHVBEDLFuIVZrK
uayCwAvmE4h8+c7ja5dvRFfZlJJMvFHeSBawp5S0vbr3TDq6nYaz4+HROc43obBoArcyW3D0MvSH
m1U+OxnYS5JwZUaX95pGWGzTJFAL60tBX7xeUNI7fn8p2JEkOjiPNk3YeIUAANbRH6QKNpTa7isK
jdYbpZETiYTM7zb5AQ6HCYKAEtOZGph3GafOl5hO3Q3WGn15ULjAnQkG52LWCHJVgwE0ALDKuzgQ
J/jQ0//8V7/6Jz7xNClBA3VDbgcqM4tFOJTcgTJb9OTx0l442KM86EVPmw0PRDMtIO50uBhskprZ
fnspaGRGQRAlwCkg98X6UkSQrTB82eOfrhhiQ12d2qNzHMc8BkBQdMQBIvB3rZyGeo9MpfHZx8Fi
VdEIMcjJSdka2JlZJN5lWnlQ4BgOdyPqxR2B2AmjUsvg6A0k4Iy63CEgKEAoDol431Of/fyDNx4N
xJQTrA2pXXhiTawehvVGoKZLPe/hRkwm8J22v7p/vmOPfDjV1QN0y4Mde/Zpv7WnDYTgg7lapjZv
+j4PQ+/GXWc+dENH/nuvLpFmI3tINDoaywDIlgka5/cQQeZty6YwgtO2azFUyza/N9AX/NhPOykZ
d0xz9uwYDES2BwuwtbkXCkJGBKsHfVs1R+nulgOtjsPKIYQAB/6/V7/w79/+5A88Q+YhtjERcYGZ
hYZRMpQ18CxwjASHtBIltVMJExbywdt5O93dTYs2RaGcERuKQ+k9D8u1h6xdD1NlVRlK/847b/3N
TzE+9hwSj96y0YBGAEbOn3W0gJgjASRbGf7WQFoVALWn82plJ7gJ/8hPA8kFLbGxmLmLm/napQ8c
gruRMQMFzqO3VnhkobZmDAgDCgrgkQROTav57PiVV7/9A4vZbKZtYB5vUshmm6H0g4plpihERkFi
JEDKgP5MLzYBJawurF+7KcfgQWHLYU0rGy66AmaDaFnldRlKf7Za/sIv/fHrz38Hbu+PDsj3vrbe
HwJQ48U5VB55G1bVvliHZQRQnVZm6AgjA1fvsXIXrMInIlQvASm7CbMqAkzeu72HbQzpCvNlC099
66EkGlK89JEXnvzKVxZq79x5fVJuld2wN5toWVmaxb544jW5rx5jmMlshxnWX/Qn51QQqEVKkPmw
OS8PT9BtuI1eqC9aRAeXCPdhuSolICw3+cnrb66PPojnLzO5aUQAbBgrV40aU3jVO/h4e8V4DZGP
BBMYOozX7VABCBy3iIEEP/afuSkxzUGZnHSEDMLZjJ3cnUZXMQyQ8d4HEZiBCU4gAfk44Katj0Rk
sd+uhv4vPDX9lqfar995bGln0k7QRCkYMJAbEIhYRDz33g/5oieeYLKPdkJxLospUSjBDJKVl3m1
HHTZaQhs4GKuA533+eE7J8+neHr5w5+5tHBxqCHouGfggGJVJY0Iqa5HG3NFzcqBUAS09YdWMSQG
WJhHDMVBXiXvgYnFXLjakNQLCUMhDLUqjOSSmAdVaPUiY9TQherN9K0gzOBVqkIPZYEPv/yw+8bH
Z7MPvTD/4zt3++7s+tPXXCi4mLNFg5ERNUBoJzSdURAKc26Fesd86qU04sOmy+gvNujcY8sbZVUr
OW+6/vzh6tlL08XamrRAHRWSoURAgQAvRdLYfJmOYn5J8LLtNhgbgB0WEBSK0W2GBmTLoqgCTgaY
xRQ9UTFThxuDefAEdmOCVD6YBwSQgAnOoFIvinjPWcgGLiPjGaqTvmCnuVcKhbi3mH741rVUNl/5
+jcePjlbDVYCl2xrFwqyLNZDCpGkBpMIg+cuHz9wDXk6L4E79Q1zR/TwzM+G4fR8+fDJ+fp889zR
bLdJFi1BYQYFjOBVH1LD3AAbUU+NLd1epYN6FQFvU5WDeOQDeGtKY6Ig1Xg1OGmHcjPK2PXBJjQI
FKUWiLBN2DxCe2NAAut2lF5VEgzjMUdWN/ik/doqFFImLHYnty4f3Z7NN+cXx8dPHp2dn+TBiq02
Kyc6Xy77Mmw2j8rySdet1+g6zdpEzjkLslgg2gwolIZVt1r1+63dmuNgZxaDbzab77uxcykKjMA2
3oVVyfh6KZLxmARCFUQwnBAJwpDqJ7WalMbfUkEgUASTG3hwh1Mwg9NbpS55YUJXghK3NMAdlsEF
2Kp4xk3RUpGIGcxBClO4j3tYHOpI8fd7083aC2KgySzO5+HybHKQWlquL05XD9bL88F7NQcGzX1G
tyl9d7bp1hva5NWjVX8+DNplCzwpnlf98dBvjmazBbe7+4vUMJJz4msHe//g9uXx0rkqTjBDofeY
o1HMbvXuGySGVpaSt1fJVGGMb7ECAYSsY10zQyFiY0HJkGqcgTCKZ05QR4ijwbvenTamb95eg0AI
1RZOoIxBxp8B4Hz92s0exzEpGy8aFsyzrmJI/39VXxpj2XWc91Wdc+59S/d0z/RsPZyFHIrLkEOO
SUoUxUSSFxESFEqOJSCxYNiJHdiBkcSxs0f5kRhwYgSBDCQyHDGIowC2EQcOJFmyIgmy6IQxaW4W
RUrkUKQ4Czkczr70+t6951TlR9V5PepfBNHz+r57zqnz1VdffcUhlG6yvrZ6YTLdNpwbptCO2gnp
gKYKUiGd9psFGdQXnQpdXr96/dKl7aPtC8N2jH7cxPk4wnCQqCuawmj+r+xu8b2TkKbeVgFUnKLN
ABVYSdb6hM3IybKNADd+KuZEo+4pUwQxgkokAExDlD6EXqP96jiVaVFlKlQrKrPjzeyAwveX2QFZ
/de0GVo7BQpK/hcf/3hz7g+nq5txe6Oaho0ujgb9VNMg5TbO9eXS5vrq2upmaun6ChNxLNKVkKgv
pShHhSBONq9F0P6FxVETW8Ww5cGgkTFH6bh0gTFYmJtbaP/ajvmvrk6RCWpS0SrlC0C2tiL2cq31
PmZGFHQCEHqjIgWFBgkTVz0qQFxIt7Fsijd5oyhI1wtnpqLRO7/MlcgyGikIpn63Rh1CBCK5wlDE
+y6tlwDpRw6GdufytO+4GVBDsUkLo8FoGAaB54aDbePRUtvOlw6bK23SQZCBcgShR5MpZCHNMr22
OBwfWFzaMRy3ipR0NBqPtqUYmtKX0m+kxR+Z39+mgJ85uAsZaLk2cRbMQra9nVkjo7VCJrumTVrL
7vFEmBb1QgARFDwgXSkYsYiiqVU3KEMohg65RO08/9Da6ScK5ZwjOIPYb1YzXLCGQI72NLcOFhYS
Fg4/AEzLxpUk4KZpF+YWFsfNgNF1pJOFweKenTv2zo8GnbBMc56MElrpmkBzpIsxHdy+c3c7WBi1
wzaMhnPbm0HoeqGo0w1Bp5vYe98jiJgWffjQrr2tkUTFRVYmY4+AMV8RUJdTuYYmVGcW2Qrt2sHl
pAIo4qYQFFNFG5WyImIn+JIICCVTDMjScixiVIuQV12o+mj5sTYHsQBJoOK9hr38jaVtbQueWxgv
35qvvc2D+VSIYggxDIdtxAR9yWOKMhoNoyJM1ldVgqIvoSHFcNs2pmksqdOsHObHqXQaB00sSoLp
RifrK4N9H5k7nKRDIRrPt//s4O5/9OpZpGQdfTXFLe4X0wPBe4f8KGlCyH7fE5ALgNhytpOYGOL5
GimFLH0mhvAGF1KJCiWSrGBVc5CzzkKqNkmmyrDn0IAIxxfeFgj0/Ot3H75pkfuA8fId62+9jrya
4gAgGjRSlHPm0VxiamJLASE0g9Fofpza1AyHsY0xFhmkGMY8Go0GiYmUByEKcdt03Uq/eo12fnDP
B49K56cHSrtGw83Lmy9OJtACe45AKMUBgQRvizRWxF/TjKosKAGkooJCgDkFIdCjv2g7kgwfmluQ
soQAsF9eQREIndgfrqmsfXYCiivnhRySMaFkdOFfHrtpNEYpaFrMHbpnev5t3VxhjqTccEQJMWgc
QgPH1MQ2NW2L0aiJIQxHzdygGc9zCkqRWQMDIcUYEFm0TM68nvZ8ePePHpMMJS/EZmA8SA/uXvzQ
/PzCVP5yYwrqXUhrJhEehQEOiGToBUKu5LY0JaDqbRFZhCjQx35Roa0tgyWlDChGJBJZc/FWLSVY
99wWMxKcWDAZobnBSgEDXbkzzn/2rsNHlxMF562ahHTwDi2pv/IGB4AoBCqcNacYG8QYQMwcYiK2
w00UE5HGEFQopUYZUCERdCuDmz+x/cF32bG2H7K2q4I0DIeXRg/tX3p0Ydvunl/su750KAwGzV6T
xU0HkeT95ghoFYUAZYZ6FyRR/C/PKFnHjLq7nwJRgQgm5A4cQeRxzgxzFJDsnRIe/AIi0GcoPbxt
26/s2/fw7XMLY0wEHBBjtVQipIjuWll/5Zu6uRpHi0JEyrnvaNCq5kiNBgFFDpBs3YtFRKSUmIJ0
U9Wei8Z9HxncPKCCXl3EwIoiUEWXQUCTEAKS4Nqanjm/8cyZq//tzPmXNtegBCZiJjLGWaHWRl3c
1rMUgKAlgrJmyorIFB57uiCQKgBVBVsSbx3snjaDTNeVvXSnhCwAmEksUSwZFD8xXvrb79p9dN9w
xwK4atwDQxWJ3OTDLGOIsHHiZH/iGd6+IyB000JUkElsz3PkAEhnqR/HRnJWCtxd0+n20dEP6tIW
CAPc2giKPnu+1AanFUkQgLUpNlbk+IVrj5+49NkL56UvGABhxNpJoQDVrAQSUlWg7yL3OYdEVChD
iMJjT5MQiApDlYECa5Bj80G1SKzArLwryEASKlGRkRUIP72445eP3nTbrhQatI1roAuAAo3W5w5Y
WwA7LSER0yu5O/41sEAj4hCiOi0hoEcXNBRr2mmawElyh3yt0OHRsQfSoBKq9XKysoUH5ZmLqnpr
WRbnu7Sg9Lh8PT91+txn3jj36uYaQNQEKmDSMlWCEkFyhqgyBckiREEpPfZMJiZVMbWO1JodEWsQ
tl4KYgBKokIQUhYApQPP/eOdO3/qjj0Hl6htIUDbAlZGZ9tqQN1KzMi9G5gqvJMsd+hPv9pd+AHz
hMOcFhXEQFwkB4KECNLAWXLG+P7xXfvMU7h+8Nbl4VCxeNtZZP8egaDqVgWulO3BwOZEn3zj0m+/
cvLPr08wUCjFLAzuNVMWDTFojrmUGFSF0mPP9qogHIvlxdwAzlkjhFrVxIBpAqBIkFAoQwpK+PTy
/p+9Z++eXdXdLXpPstkuzrTgvqjkcX9G8NoXACFE5B79VSmXf6CX30IQaAviMF3P1OV+ndpb2sMP
DvaS2g1ur4m23pExsaX4RpcMDu6B6e5yACzNEAghCkTBRVfX9JnTF3/75beeXFsBuGHkwJjmwBqz
TomGrJ0Wio89PV/kKkXP4DlYqgHoQsNjlb7QxZC4iO+dzJ9a3P2r9x+67xZkwWqPNlqRHIEq5rjh
azgnTL7glvDNckauoEpNt9qje+tEOf0SUyicFTvTHe8f7IVYe5mCALEKq9nG4YdigL8x4x0qkhOF
CJoWRaHFz6N9jokip+vl26cu/8eXT/3fqytgcn6ycIiZpyRBKH3uaWguEpWJQhQpICIFRUTRTgOa
2IpMpaDkjzQ7/+l9N7/7cGharHeOBwybpIACkDpAmxWQEd0iyM4C10qEaZu2HEKzQwgE9Fcn+spz
zdKd8bZdOSJkv05dq1idQAW+W610SMHFMzkgVYdPMyPIBSlWa83aC6tmL08oGVR0ba179uTVz7/6
5p9evxoK5hpMehlQnFKhuc/9xVphv8uCTzsgVQ1KFNUXrozL8HfuvPmj924bRmwCITpLUxRNxWjm
NuiBtKYBII9HZtgeZzRcrfFBvKPcTLQFSAkZOHHqzdHwwME9VKaYmheGVp5agACCV4mk7taIakZj
xQ5yO4hstugRauJPRilQoO9BhARkoC/Kva6uT186c/kPjp/60tn11KgWjSnQ0mNPXslpPnRzFM8q
gUIgFSa1hchldxz96r59HzuydGA3CJBQ0xJTVTCIUdSjowV9Yrf7C4RsLV6GrshvSBKUgJBdrMHF
zOEQGvzB//itUXnXWzK98PT/0mb86N/8tx943/LaBFSxh8deo4Zmu5Vc1lAKYtxi+gpBM7oMAClC
CWBErfSZQSJLgdVcySUIr083j59a+fLxU//z/IXYtOHwx//OhUxTDask24h6YBi5E0XuFmj0W7fc
/K/ffehDR0YL8wCQ1WswHJxRUKseMfoekUHVqyICZOILQjG8Rd7x65tMnWJP6hijbfD6yy/899/8
Twu/98L3h2/vnF/avRRfOoPlQ0d3LViIgEU4Le4SY5VzZsdzQsgZHLyvzEDTTFBswdtgn90eBC8d
cXBEAlCmEkNc3jN46MCeR/buQe7imYJbUn57Gg614ZJkUV7vuyjNb9x84BNH9t+0C72gEAoQI4LW
71xpPHfVUqTodECtQjoCELhPkxknmXcA1wZof1/G0zd4/oUnaDxaeHhh3JY2dafP8L6D3/ni1xf/
4c99mNlHhJg4z8VmEVEBbFGsHLf0Ru6br6CI0LvJrxXcWCHVSzRElOLbCqyBg3BhjcM5PTa/sLDj
1rDjY7/wjmI54Dry1Z7Q8T9fPvi5h+/4yD3bBgNsZiAiJT9KHkfYbbhs61oibMtl9xq7RAlM4KqK
th4fgvcfmpo+kP+mHaL50btOvvks7ZjMHb94Itz0yCMHnnzypXL++SO3/PWd+2KReqnNgh2g5Hz0
7L4jeNO9/QkElFwbp6toy4o79sCO7c3qskeWAqXAUJQ87dvU8FShlN4suLLB/2D7zqceefe/+tC+
/ctYFWRgNEIIyIJe/aYiU4vEanWcoVYKrmtodclIThCYXWmVqXguSNVYSQkhIpCLog/fvvOnf/7v
n3hthd45cvSTf++ZlxcPLEzffOXEXz73XduYTE6EzX6ssOMafvLiFqMSogT0btdot4SBuAywQEPF
gmZhzEAkZlbVtY2uz+DBKEXmAC4bG8d47osP3vtvHr396EHesBFHAZzQdY5iZjfR5hSDsIUDjVAq
terpcHGrP847esx03x3kq4GcXfwmw0eECCYdDh482u1N7yyceeErz97z4/ed7XbtuevQiTOvC9Bb
y7j4YTLdohU9nReqRSBxlIaiQPT1EEZWZ5LNYYun/u1MYgtCYoAoEKUUc0HfbQiI9zbtZ++6+xuf
vPcn7plTYCLgBgXIxSvgRFvviBjJhkOIRxnY2amranc5BHSDWkzM0cv6L2fTXOw2sY82tBNBisVR
uP3Ig/PXV/YMV1/71hffc+vc1bdw23iHVRVmHoNe0wuQDARwdnBoD1ZrflswKhASgRlddhyHAm5r
EcCd+8EBDRMxReIAZWkgyp++9/AvfGDXcIyNgrUOq5tY30C3iZxdNFAyhJDNv14RCLOdPrt5bVtJ
jQJgENALUq2VoFYi7PYhqv8hPnzFriLLVI/ef8f0yuVbpi/vnVv/s/9z4tYjD73vb31YMiDVU9j8
dNgXwACSmzZGH+LC9UIwkjkED3/mCV6k2kVJNbW3L6JQQghELIlZYwEpv/fQwmqPiyuTjU1tI+ZG
aAbg5La08YZxQQ1BYpVjGJQjl9NxdfgNlfEylGSuihanYWGeAYGY/bCtYanbDAAjA9zl9In7yl1z
r39f7nvvDrSHlnajKKzJyjjVaBbYgmD4l7bYSAvYdpAJiOp9+1Ttn5wzUAe6MxWMBYFi1HWICEwC
QLkNWJ/kQRosLNK4RWwwbDAcoBl44cBuBBvNU5NIKEEzVJDZCUhr4fGZPxZorERKnnyY5Y39BHEp
ov0y1fqoMgIw3r6ne+PE/H8+2+4arF/XpcU2oUrLKmNuUzLItFURMfg8MIbvL639NID7DlvQMZPI
rkBnHGYtGvmzG+5TpaAUAoijqgxiHA592A1X/9DACBG9xXwjM3VrA6OOWPBZUpYBGG6yFKz+ahHM
IEsWrwb4tAvyb25BSoBYoAnYXD+t2/b+1dsv6fL69cmdbbEXaqsVCIA3gGYFOlBAqVN4pAK3mRLB
SrC2TjnA+j4Bz2yhoABWy7iAuhOZUKBETFQ4cmhbhz+FvEyAyuibikbMkFyrU4T9+WrGBdShE+pp
VBY/g1TN62cyBbA7K/sXEA95vgUCCJhMNz/wobu+e/a4bp7cvmv+wP43L11HSk5I5QzJFcQyCkHV
qzN5a6N7MPZoNdsg6uJHiD8z19DANYDYzJACihoTEwPMERyrpRj8QPl8nJp8srh5GeoYJatIWn8p
FXSAKGKocwDgF2JWaO84k+oNEhnr1ZNgVlu21bfCxJ7dc3/8h9/92E/d2h1/feHi6a/9yR//+be+
19ocD0FI/oKtNoRaRfYdziBg2t+QytVFtTAfDQcxstaZVFoPR32S4uPAVElBxJaU3/gTk6fCGRB4
iAk2ma5aCJBNm7KTb6acNgtRfHkj16dPYPK36fhNMR+2yENVcDSQqUSYTDa/8p3pr/z6R3/3sVd+
7tM/uVqme4/c2841dmFnhfS+O6zmENXr++bQbzu7TVtfahZFzdigiHCBQXaD5vZUdZn8nvHpiyZh
9mtbfByXwvQkNVgw2rpC1NbpcQAABvJJREFUibYuNSou5r3x7jfgb78tqC6S1UZSTURvWtXiMchq
TuyXN4WACU0v/rvf2fzCyV+Li1/98lO3bd/90B8dv/L2pQSAfGhAZOAG+RwBJSNXAnv2PEYG6Gwo
gVe5mBKaBEB60WIxpO44I/NsrFpkspuKLUuIwYGyHTEFkB0TmxGQfWeqQ+gMxZuSgHtfKzJKSL3p
oCgkVu//Uue5WXt9AARq5p4VoYhoDLj+zonJneNTy83/69YeOHLParf6vfff/OrzT/Xw1M8RfL0T
LIIIATa0b0YTz2jJUv9VxXeWLQbm3HXItV5o4FZQApJWTjUQE7HdfIZiI3shzE6Kz0Y0AkwBrYsP
v79s45Xkh9E9pMy8q1Kl/lEWuQkJ3nYnRtdyTT5FA5EC3/zGF3ct71pDHv7Y0qVrZyXON7fEsxef
O3kCKUABqn7MvlMEABLQEaSAraeTnFMXgYQfSgOcgFIEQkhNLxWgKyggMoKiN5sENZGx+YuH6kBi
R8ZEHzbZ54YMyBkWqbwUnO4KBXCRpp9tUkjnK1wq+W8vqy8QApdKG6hPXxRCaPDaqRdf/LOXY4r0
zaul0ZW310c7d0zPTuenq1/5wh9ZMVRmfueW6FgqGxGAvqCvfLY9KtTTSdSdV+CJNwUQqZDP47MJ
oLEeCKOaGFDierHUCGKdt6ipsx03szG3N2WYMFCdDCGQ4GmaYVmxizy42J/Ec1FLr01xaYmVz+4y
paBSJFx+/GsPbz8yN+zufvHC/m/vnf/9c5eeWb3t6t67v3w6X3n8xHcnTYIISnG/q9mFpgXBWmGm
EJ2xxNDZ4tkbqwtmOyAxk2gR5Lw1p9LoMM0ohcUmhl5d1wKQgGrF2Zggp4EbkHrRCuxVDQ7IisZk
NmbmwT4vkwAlG5WHWN+dcYAwx/cAlYoh6nmhXjnQsMU/+aVfi/kyxjv6y1d2P/LzwwHPLR5455Uv
nX7qBcI7Rw988u9+5pc3OwSzC5sBMapsSUHuIRGxDm6wP5RnvFXeonqz6LnL3c6FIL2k1IToZ9Oe
1kZxMSlQe+A8Pa0njhUx+lkwHGQslDVB2Oa8EX3YwCi7E7tZ8imOdj2VEYC2sIzMZu8pRHNo8NaF
K8sH1nm4vK1cuuO9913+6n8Iq2fPP/4b3dmLD9yz2Y4Pv3ju8edf2hgkn52YjVCvCjoYZLM5kgIp
WzdMzcZQwwOUcX1FD+1tY4hgneZpkZnvLLQgJlP+9aKV1xDc0Mhgx0fRRIQ62iYaEJ/do+SaCU+O
thpFEBmh8STTsvkQXAD0QzUlC58C0QKNiXDu5HdOvnp5oNc63fv6cy/tufXe68efmFwdLQ+uPP2n
/bY0HWf9wn/9zETqFLW6og5q7NAZ1CjoxflyreGJAQnI5PTDziXubKYPRymUux5SBTY2bZYQQhKR
WCsxW9jHqRlCL45KZwNVubjdn6NYAtSnbFrHgWNf1+fUJKtUGya4SsgCGQVIyVAlCgR8//t/sXPv
sb0P/ZiO5/fLK09//Vvbd92zbfTq8XPDj/7ST55LhwYX3zjzxNdeev78e+7fMymwUWczqsgjNCFG
lAzpERpocT6gaBUm2nArQs6uEmhCyFw6EWSw9EyJVIioiIKKwwyH5DdebTcUabJ42Uu2QAnYcI3d
a1Xvr5X9sEHkqDyRyUz8QpilSE4nFVCyWtPrT77z/jsWf/C/v3T6U/8+f/v0u79+jujatfX2x49f
DN977cRnf//M7710/wP7v/EnXw0DACAyrmHL2sg1n+oP7Piw3hg5gntoqAEcW8vccNTSa8lCqQCq
rGZFJwQI+zxedWrKtpXMUOwNoM85EPvfvnch9c0Z8rZYJvDxQrghDwqA1HR0Bv97ag2/lhYAAJcW
AACYFgAArH0AAK59AAA6fgAAPH4AAFyAAABegAAAhIIAAAqDAAAMgwAA/QAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
APoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACgAAAyQDCiYAC0YaAA+E0AIWJAEDAABAJgAAAQAAAAsQFQAAERUA
AC4VAAAvFQAAMBUAADEVAAA8FQAAIxYAACQWAAAwFgAAMRYAAEcWAABMFgAAXxYAAHAWAABxFgAA
hBYAAJUWAACXFgAAmBYAAKp9AACsfQAArn0AABh+AAA4fgAAOn4AADx+AAAsgAAAWoAAAFyAAABe
gAAA2oIAAAiDAAAKgwAADIMAAEKEAABUhAAAVoQAAFiEAAD7+Pv4+wD4+wD4APj18AD18AD46wD4
6/AA+Pj7APj4+wD4+PsA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAhDShwAbUgJBAAIQ0oQAG1ICiwABG1ICiwABG1ICQQABzUIgW1ICQQAJpYWAACXFgAA
mBYAAKx9AACufQAAOn4AADx+AABcgAAAXoAAAISCAAAKgwAADIMAAFaEAABYhAAA/QAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD6
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAPoAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAoAAAMkAwomAAtGGgAPhNACFiQBAwAAQCYAAAEAAAANZQBjAG8AcgB5
AGEAaABvAG8ALgBhAHIAYwBvAHIAQAB5AGEAaABvAG8ALgBjAG8AbQAuAGEAcgANAA0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJAFAAIABhAG4A
ZAAgAE0AUABMAFMAIABzACAAdwBlAGwAbAAgAGEAcwAgAGEAbgBkACAASQBTAEQATgAgAGQAZQBi
AHUAZwBpAG4AZwAgAGEAbgBkACAALAAgAFYAUABOABkgcwAsACAASQBQACAATQB1AGwAdABpAGMA
YQBzAHQADQBNAEcAGSBzACwAIABNAEcAQwAZIHMAIABhAG4AZAAgAEMAYQBsAGwAIABBAGcAZQBu
AHQAcwAgAG8AcABlAHIAYQB0AGkAbwBuACwAIABJAFMARABOAFMAUwA3ACAAYQBuAGQAIABJAFMA
RABOACAAcwBpAGcAbgBhAGwAbABpAG4AZwANAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpAHIAZQBjAGMA
aQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAAAAAAAAAAAAAAAA
AAAAAAAAAAAAEgBXAAoAAQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBsAAAA
AgAAAAQAbUgKDDIAAUABAAIAMgAAAAgAVADtAHQAdQBsAG8AIAAxAAAACAABAAYkAUAmAAcANQiB
bUgJBABEAAIAAQACAEQAAAAIAFQA7QB0AHUAbABvACAAMgAAABAAAgAGJAETpPAAFKQ8AEAmARIA
NQiBNgiBQ0oYAE9KAgBRSgIAPgADAAEAAgA+AAAACABUAO0AdAB1AGwAbwAgADMAAAAQAAMABiQB
E6TwABSkPABAJgIMAENKGABPSgIAUUoCAEIABAABAAIAQgAAAAgAVADtAHQAdQBsAG8AIAA0AAAA
EAAEAAYkAROk8AAUpDwAQCYDDwA1CIFDShgAT0oCAFFKAgAANAAFAAEAAgA0AAAACABUAO0AdAB1
AGwAbwAgADUAAAANAAUAE6TwABSkPABAJgQABABDShYAOAAGAAEAAgA4AAAACABUAO0AdAB1AGwA
bwAgADYAAAANAAYAE6TwABSkPABAJgUABwA2CIFDShYAADgABwABAAIAOAAAAAgAVADtAHQAdQBs
AG8AIAA3AAAADQAHABOk8AAUpDwAQCYGAAgAT0oCAFFKAgA8AAgAAQACADwAAAAIAFQA7QB0AHUA
bABvACAAOAAAAA0ACAATpPAAFKQ8AEAmBwALADYIgU9KAgBRSgIAAEIACQABAAIAQgAAAAgAVADt
AHQAdQBsAG8AIAA5AAAADQAJABOk8AAUpDwAQCYIABIANQiBNgiBQ0oSAE9KAgBRSgIARgBBQPL/
oQBGAAAAGwBGAHUAZQBuAHQAZQAgAGQAZQAgAHAA4QByAHIAYQBmAG8AIABwAHIAZQBkAGUAdABl
AHIALgAAAAAAAAAAAAAAAAAuAFVAogDxAC4AAAAMAEgAaQBwAGUAcgB2AO0AbgBjAHUAbABvAAAA
BgA+KgFCKgI+AD5AAQACAT4AAAAGAFQA7QB0AHUAbABvAAAAFAAQAAMkAQ+EHAFAJgANxgUAATMH
gAsANQiBQ0ooAG1ICQQANAAfQAEAEgE0AAAACgBFAG4AYwBhAGIAZQB6AGEAZABvAAAADQARAA3G
CAACQxGGIgECAAAAOgAgQAEAIgE6AAAADQBQAGkAZQAgAGQAZQAgAHAA4QBnAGkAbgBhAAAADQAS
AA3GCAACQxGGIgECAAAAJAA/AAEAMgEkAAAABgBDAGkAZQByAHIAZQAAAAYAEwAPhJwQAAA6AEQA
AQBCAToAAAAPAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhAAAACgAUAA+EGwEUpHgAAAA+
AEUAAQBSAT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhACAAMgAAAAoAFQAPhDYC
FKR4AAAAPgBGAAEAYgE+AAAAEQBDAG8AbgB0AGkAbgB1AGEAcgAgAGwAaQBzAHQAYQAgADMAAAAK
ABYAD4RRAxSkeAAAAD4ARwABAHIBPgAAABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEA
IAA0AAAACgAXAA+EbAQUpHgAAAA+AEgAAQCCAT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABp
AHMAdABhACAANQAAAAoAGAAPhIcFFKR4AAAAWgAkAAEAkgFaAAAADwBEAGkAcgBlAGMAYwBpAPMA
bgAgAHMAbwBiAHIAZQAAAB0AGQAbJoAPhEALGIT8/xmE9P8ahPAeL4SNACtEvAcADABDShgAT0oC
AFFKAgBOAC4AAQACAE4AAAATAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABsAGkAcwB0AGEA
AAAGABoAE6R4AA8ANQiBQ0oYAE9KAgBRSgIAAG4ASQABALIBbgAAABUARQBuAGMAYQBiAGUAegBh
AGQAbwAgAGQAZQAgAG0AZQBuAHMAYQBqAGUAAAAmABsAD4RuBBGEkvskZAYBAAElZAYBAAEmZAYB
AAEnZAYBAAEtRAAQDABDShgAT0oCAFFKAgA4AE8AAQACADgAAAASAEUAbgBjAGEAYgBlAHoAYQBk
AG8AIABkAGUAIABuAG8AdABhAAAAAgAcAAAAMAAiAAEAAgAwAAAACABFAHAA7QBnAHIAYQBmAGUA
AAAKAB0AE6R4ABSkeAADADUIgQAeAEwAAQACAB4AAAAFAEYAZQBjAGgAYQAAAAIAHgAAACIAQAAB
APIBIgAAAAUARgBpAHIAbQBhAAAABgAfAA+EnBAAACwACgABAAIALAABAAgAzQBuAGQAaQBjAGUA
IAAxAAAACgAgAA+EyAARhDj/AAAsAAsAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAMgAAAAoAIQAP
hJABEYQ4/wAALAAMAAEAAgAsAAEACADNAG4AZABpAGMAZQAgADMAAAAKACIAD4RYAhGEOP8AACwA
DQABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA0AAAACgAjAA+EIAMRhDj/AAAsAA4AAQACACwAAQAI
AM0AbgBkAGkAYwBlACAANQAAAAoAJAAPhOgDEYQ4/wAALAAPAAEAAgAsAAEACADNAG4AZABpAGMA
ZQAgADYAAAAKACUAD4SwBBGEOP8AACwAEAABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA3AAAACgAm
AA+EeAURhDj/AAAsABEAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAOAAAAAoAJwAPhEAGEYQ4/wAA
LAASAAEAAgAsAAEACADNAG4AZABpAGMAZQAgADkAAAAKACgAD4QIBxGEOP8AACYALwABAJICJgAA
AAUATABpAHMAdABhAAAACgApAA+EGwERhOX+AAAqADIAAQCiAioAAAAHAEwAaQBzAHQAYQAgADIA
AAAKACoAD4Q2AhGE5f4AACoAMwABALICKgAAAAcATABpAHMAdABhACAAMwAAAAoAKwAPhFEDEYTl
/gAAKgA0AAEAwgIqAAAABwBMAGkAcwB0AGEAIAA0AAAACgAsAA+EbAQRhOX+AAAqADUAAQDSAioA
AAAHAEwAaQBzAHQAYQAgADUAAAAKAC0AD4SHBRGE5f4AAD4AMQABAOICPgAAABEATABpAHMAdABh
ACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzAAAACQAuAAomAAtGKgAAAABCADoAAQDyAkIAAAATAEwA
aQBzAHQAYQAgAGMAbwBuACAAbgD6AG0AZQByAG8AcwAgADIAAAAJAC8ACiYAC0YrAAAAAEIAOwAB
AAIDQgAAABMATABpAHMAdABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzACAAMwAAAAkAMAAKJgAL
RiwAAAAAQgA8AAEAEgNCAAAAEwBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAA0
AAAACQAxAAomAAtGLQAAAABCAD0AAQAiA0IAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6AG0A
ZQByAG8AcwAgADUAAAAJADIACiYAC0YuAAAAAD4AMAABADIDPgABABEATABpAHMAdABhACAAYwBv
AG4AIAB2AGkA8QBlAHQAYQBzAAAACQAzAAomAAtGLwAAAABCADYAAQBCA0IAAQATAEwAaQBzAHQA
YQAgAGMAbwBuACAAdgBpAPEAZQB0AGEAcwAgADIAAAAJADQACiYAC0YwAAAAAEIANwABAFIDQgAB
ABMATABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAAMwAAAAkANQAKJgALRjEAAAAA
QgA4AAEAYgNCAAEAEwBMAGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAIAA0AAAACQA2
AAomAAtGMgAAAABCADkAAQByA0IAAQATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBpAPEAZQB0AGEA
cwAgADUAAAAJADcACiYAC0YzAAAAAEQAWQABAIIDRAAAABIATQBhAHAAYQAgAGQAZQBsACAAZABv
AGMAdQBtAGUAbgB0AG8AAAAGADgALUQgAQgAT0oDAFFKAwA6ACUAAQCSAzoAAAAPAFIAZQBtAGkA
dABlACAAZABlACAAcwBvAGIAcgBlAAAAAgA5AAgAT0oCAFFKAgAgAEsAAQACACAAAAAGAFMAYQBs
AHUAZABvAAAAAgA6AAAAXABSAAEAsgNcAAAAHQBTAGEAbgBnAHIA7QBhACAAMgAgAGQAZQAgAHQA
LgAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAAAAQADsAD4QbARJk4AEBABSkeAAAAFoAUwAB
AMIDWgAAAB0AUwBhAG4AZwByAO0AYQAgADMAIABkAGUAIAB0AC4AIABpAG4AZABlAHAAZQBuAGQA
aQBlAG4AdABlAAAACgA8AA+EGwEUpHgABABDShAAUgBDAAEA0gNSAAAAGwBTAGEAbgBnAHIA7QBh
ACAAZABlACAAdAAuACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAAAAoAPQAPhBsBFKR4AAAA
NAAcAAEA4gM0AAAADgBTAGEAbgBnAHIA7QBhACAAbgBvAHIAbQBhAGwAAAAGAD4AD4TEAgAAPABK
AAEA8gM8AAAACQBTAHUAYgB0AO0AdAB1AGwAbwAAAAwAPwADJAEUpDwAQCYBDABDShgAT0oCAFFK
AgBIACMAAQACAEgAAAAWAFQAYQBiAGwAYQAgAGQAZQAgAGkAbAB1AHMAdAByAGEAYwBpAG8AbgBl
AHMAAAAKAEAAD4SQARGEcP4AAB4AEwABAAIAHgABAAUAVABEAEMAIAAxAAAAAgBBAAAAIgAUAAEA
AgAiAAEABQBUAEQAQwAgADIAAAAGAEIAD4TIAAAAIgAVAAEAAgAiAAEABQBUAEQAQwAgADMAAAAG
AEMAD4SQAQAAIgAWAAEAAgAiAAEABQBUAEQAQwAgADQAAAAGAEQAD4RYAgAAIgAXAAEAAgAiAAEA
BQBUAEQAQwAgADUAAAAGAEUAD4QgAwAAIgAYAAEAAgAiAAEABQBUAEQAQwAgADYAAAAGAEYAD4To
AwAAIgAZAAEAAgAiAAEABQBUAEQAQwAgADcAAAAGAEcAD4SwBAAAIgAaAAEAAgAiAAEABQBUAEQA
QwAgADgAAAAGAEgAD4R4BQAAIgAbAAEAAgAiAAEABQBUAEQAQwAgADkAAAAGAEkAD4RABgAANAAe
AAEAogQ0AAAAEABUAGUAeAB0AG8AIABjAG8AbQBlAG4AdABhAHIAaQBvAAAAAgBKAAAAPgAsAAEA
AgA+AAAAEQBUAGUAeAB0AG8AIABjAG8AbgAgAHMAYQBuAGcAcgDtAGEAAAAKAEsAD4TIABGEOP8A
AD4AVAABAMIEPgAAAA8AVABlAHgAdABvACAAZABlACAAYgBsAG8AcQB1AGUAAAAOAEwADoSgBQ+E
oAUUpHgAAAA+AEIAAQDSBD4AAAATAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0
AGUAAAAGAE0AFKR4AAAASABQAAEA4gRIAAAAFQBUAGUAeAB0AG8AIABpAG4AZABlAHAAZQBuAGQA
aQBlAG4AdABlACAAMgAAAAwATgASZOABAQAUpHgAAABGAFEAAQDyBEYAAAAVAFQAZQB4AHQAbwAg
AGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIAAzAAAABgBPABSkeAAEAENKEABeAE0A0QQCBV4A
AAAjAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBh
ACAAcwBhAG4AZwByAO0AYQAAAAYAUAARhNIAAABiAE4A0QMSBWIAAAAlAFQAZQB4AHQAbwAgAGkA
bgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAAcwBhAG4AZwByAO0AYQAg
ADIAAAAGAFEAEYTSAAAAVgAtAPH/IgVWAAAACwBUAGUAeAB0AG8AIABtAGEAYwByAG8AAAAiAFIA
DcYdAAngAcADoAWAB2AJQAsgDQAP4BAAAAAAAAAAAAAMAE9KBABRSgQAbUgKDDoAKwABADIFOgAA
ABMAVABlAHgAdABvACAAbgBvAHQAYQAgAGEAbAAgAGYAaQBuAGEAbAAAAAIAUwAAADAAHQABAEIF
MAAAAA4AVABlAHgAdABvACAAbgBvAHQAYQAgAHAAaQBlAAAAAgBUAAAAPgBaAAEAUgU+AAAAEQBU
AGUAeAB0AG8AIABzAGkAbgAgAGYAbwByAG0AYQB0AG8AAAACAFUACABPSgQAUUoEAEAAIQABAAIC
QAAAABAAVADtAHQAdQBsAG8AIABkAGUAIADtAG4AZABpAGMAZQAAAAIAVgALADUIgU9KAgBRSgIA
AAAAAAC3EgAABAAANgAAAAD/////AAAAAI8AAACtAAAArwAAALkAAAAhAgAALAIAAMoCAADWAgAA
1wIAAIoEAACbBAAAoAQAAKoEAADXBAAA3AQAABEFAABJBQAAuQUAAAEIAAASCAAAFQgAABkIAAA5
CAAAnwgAANQIAADuCAAAGAoAACkKAABHCgAAegoAAOEKAAAbCwAAHAsAAB0LAAAeCwAAKQsAACoL
AACACwAAiAsAAMILAADoCwAAHwwAAF4MAABfDAAAYAwAAGEMAABqDAAAawwAAKwMAAD8DAAAZQ0A
AKgNAADzDQAANg4AAMQOAAAcDwAAhg8AACAQAACXEAAAmBAAAJkQAACaEAAAqxAAAKwQAACxEAAA
zRAAAN4QAAArEQAASREAAEoRAABLEQAAVhEAAFcRAACLEQAA2BEAADsSAAA8EgAAPRIAAD4SAABK
EgAASxIAAGMSAABkEgAAZRIAAGYSAAB5EgAAjxIAALUSAAC4EgAAngAAAAAAAAAAAAAAAIAAAACA
CAAAAAAAAAAAAAAAAIAAAACAngAAAAAAAAAAAAAAAIAAAACAqQAAAAEAAAAAAAAAAICtAAAAngAA
AAAAAAAAAAAAAIAAAACAqQAAAAEAAAAAAAAAAICtAAAAngAAAAAAAAAAAAAAAIAAAACAqQAAAAEA
AAAAAAAAAICtAAAAngAAAAAAAAAAAAAAAIAAAACAqQAHIAAAAAAAAAAAAICtAAAAqQAAAAAAAAAA
AAAAAICtAAAAqQAaIAAAAAAAAAAAAICtAAAAqQAaIAAAAQAAAAAAAICtAAAAqQAaIAAAAgAAAAAA
AICtAAAAqQAaIAAAAwAAAAAAAICtAAAAqQAaIAAABAAAAAAAAICtAAAAqQAaIAAABQAAAAAAAICt
AAAAqQAaIAAABgAAAAAAAICtAAAAqQAdIAAAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAA
qQAcIAAAAAAAAAAAAICtAAAAqQAcIAAAAQAAAAAAAICtAAAAqQAcIAAAAgAAAAAAAICtAAAAqQAc
IAAAAwAAAAAAAICtAAAAqQAcIAAABAAAAAAAAICtAAAAqQAcIAAABQAAAAAAAICtAAAAqQATIAAA
AAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAqQAWIAAAAAAAAAAAAICtAAAAqQAWIAAAAQAA
AAAAAICtAAAAqQAWIAAAAgAAAAAAAICtAAAAqQAWIAAAAwAAAAAAAICtAAAAqQAAAAAAAAAAAAAA
AICtAAAAmQAAAAAAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAqQAAAAEAAAAAAAAAAICt
AAAAqQAAAAAAAAAAAAAAAICtAAAAqQAKIAAAAQAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAA
qQAbIAAAAAAAAAAAAICtAAAAqQAbIAAAAQAAAAAAAICtAAAAqQAbIAAAAgAAAAAAAICtAAAAqQAb
IAAAAwAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAmQAAAAAAAAAAAAAAAICtAAAAqQAAAAAA
AAAAAAAAAICtAAAAqQAAAAEAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAqQAMIAAAAAAA
AAAAAICtAAAAqQAMIAAAAQAAAAAAAICtAAAAqQAMIAAAAgAAAAAAAICtAAAAqQAMIAAAAwAAAAAA
AICtAAAAqQAMIAAABAAAAAAAAICtAAAAqQAMIAAABQAAAAAAAICtAAAAqQAMIAAABgAAAAAAAICt
AAAAqQAMIAAABwAAAAAAAICtAAAAqQAMIAAACAAAAAAAAICtAAAAqQAMIAAACQAAAAAAAICtAAAA
qQAMIAAACgAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAmQAAAAAAAAAAAAAAAICtAAAAqUAA
AAAAAAAAAAAAAICtAAAAqQAAAAEAAAAAAAAAAICtAAAAqUAAAAAAAAAAAAAAAICtAAAAqQAOIAAA
AAAAAAAAAICtAAAAqQAOIAAAAQAAAAAAAICtAAAAqQAOIAAAAgAAAAAAAICtAAAAqQAOIAAAAwAA
AAAAAICtAAAAqQAOIAAABAAAAAAAAICtAAAAmQAAAAAAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAA
AICtAAAAqQAAAAEAAAAAAAAAAICtAAAAqQAAABEAAAAAAAAAAICtAAAAqQAHIAAAAQAAAAAAAICt
AAAAqQAHIAAAAgAAAAAAAICtAAAAqQAHIAAAAwAAAAAAAICtAAAAqQAAABEAAAAAAAAAAICtAAAA
mQAAAAAAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAqQAAAAEAAAAAAAAAAICtAAAAqQAA
AAAAAAAAAAAAAICtAAAAqQApIAAAAAAAAAAAAICtAAAAqQAAAAAAAAAAAAAAAICtAAAAmQAAAAAA
AAAAAAAAAICtAAAACAAAAAAAAAAAAAAAAIAAAACAmkAAABIAAAAAAAAAAIAAAACAmEAAABIAAAAA
AAAAAIAAAACAmkAAAAAAAAAAAAAAAIAAAACACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAAAqAAAATwAAAFIAAAAABAAAEBUAAF6AAAAM
AAAAFwAAAAAEAACJBQAAwwYAAPoLAABtDwAAfhQAAD0VAACWFgAAXoAAAA0AAAAPAAAAEQAAABIA
AAAUAAAAFgAAABgAAAAaAAAAAAQAAMIGAAAODgAAHBIAADAWAACYFgAADgAAABAAAAATAAAAFQAA
ABkAAAAPAADwbAAAAAAABvAYAAAAAggAAAIAAAACAAAAAQAAAAEAAAADAAAAHwAB8CwAAABiAAfw
JAAAAAYGbelgwit03ZSlBS7fHHg7Cf8AbEcAAAEAAAAmNgAAAAAAAEAAHvEQAAAA//8AAAAA/wCA
gIAA9wAAEAAPAALwNAEAABAACPAIAAAAAgAAAAIEAAAPAAPw0gAAAA8ABPAoAAAAAQAJ8BAAAAAA
AA0AAAAMAAAACwAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPCaAAAAsgQK8AgAAAACBAAAAAoAAGMA
C/BqAAAABEEBAAAABcEYAAAABgECAAAA/wEAAAgAg8MuAAAAvwMgAGAAQQA6AFwAZgBvAHQAbwAu
AHAAYwB4AAAABQAIAAgAIf///wAAAAAh////o1MAAGBUAACjUwAAYFQAAAAAAAAh////AAAAAAAA
EPAEAAAAAAAAAAAAEfAEAAAABgAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEA
ABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAGgAAALcSAAACBAAAJhcAAGIA
AADVHAAAEAcAALRCAAAAAAAAAAAHAAAADgAAABgAAAAfAAAAJAAAACkAAAAuAAAAMgAAADgAAACX
AAAArAAAAGMDAABwAwAAaQQAAGsEAABwBAAAfQQAAIgEAACIBAAAewUAAIIFAACSBQAAmQUAAKAF
AACkBQAAuQUAAMMFAACnBwAArwcAALAHAAC2BwAA0wgAANQIAADbCAAA3AgAAOQIAADlCAAA7AgA
AO4IAAD0CAAA9QgAAAMMAAAEDAAACAwAAAkMAACoDQAAvw0AAJgQAACaEAAAohAAAKMQAACpEAAA
qhAAAEcRAABLEQAAVBEAAFcRAABlEgAAuBIAABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAE
AAcABAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwAAwAHAAMABwADAAcAAwAHAAMABwADAAcA
AwAHAAMABAADAAcAAwAHAAMABwADAAcAAwAHAAMABwAAAAAAzwMAAGkEAABrBAAAcAQAAH0EAACI
BAAAiAQAAGwFAACoDQAAvw0AALgSAAADAAcABAAHAAQABwAEAAcAAwAEAAMA//8UAAAAHQBEAGkA
cgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAQQBD
ADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEcAdQBhAHIAZABhAGQAbwAgAGMAbwBuACAA
QQB1AHQAbwByAHIAZQBjAHUAcABlAHIAYQBjAGkA8wBuACAAZABlACAAQwBWAF8AUgBKAFoAXwBF
AE4ARwAyAC4AYQBzAGQAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQA
ZQAgAEkAbgBmAG8AcgBtAGEAQQBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEcAdQBh
AHIAZABhAGQAbwAgAGMAbwBuACAAQQB1AHQAbwByAHIAZQBjAHUAcABlAHIAYQBjAGkA8wBuACAA
ZABlACAAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AYQBzAGQAHQBEAGkAcgBlAGMAYwBpAG8AbgAg
AFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAQQBDADoAXABXAEkATgBEAE8A
VwBTAFwAVABFAE0AUABcAEcAdQBhAHIAZABhAGQAbwAgAGMAbwBuACAAQQB1AHQAbwByAHIAZQBj
AHUAcABlAHIAYQBjAGkA8wBuACAAZABlACAAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AYQBzAGQA
HQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBt
AGEAIQBDADoAXABNAGkAcwAgAGQAbwBjAHUAbQBlAG4AdABvAHMAXABDAFYAXwBSAEoAWgBfAEUA
TgBHADIALgBkAG8AYwAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABl
ACAASQBuAGYAbwByAG0AYQBBAEMAOgBcAFcASQBOAEQATwBXAFMAXABUAEUATQBQAFwARwB1AGEA
cgBkAGEAZABvACAAYwBvAG4AIABBAHUAdABvAHIAcgBlAGMAdQBwAGUAcgBhAGMAaQDzAG4AIABk
AGUAIABDAFYAXwBSAEoAWgBfAEUATgBHADIALgBhAHMAZAAdAEQAaQByAGUAYwBjAGkAbwBuACAA
UwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwByAG0AYQAhAEMAOgBcAE0AaQBzACAAZABv
AGMAdQBtAGUAbgB0AG8AcwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIA
ZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhACUAQwA6
AFwAVwBJAE4ARABPAFcAUwBcAEUAcwBjAHIAaQB0AG8AcgBpAG8AXABDAFYAXwBSAEoAWgBfAEUA
TgBHADIALgBkAG8AYwAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABl
ACAASQBuAGYAbwByAG0AYQAlAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIA
aQBvAFwAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAg
AFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAJQBDADoAXABXAEkATgBEAE8A
VwBTAFwARQBzAGMAcgBpAHQAbwByAGkAbwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBj
AB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIA
bQBhACUAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEUAcwBjAHIAaQB0AG8AcgBpAG8AXABDAFYAXwBS
AEoAWgBfAEUATgBHADIALgBkAG8AYwAzAHz///+eUAqpMgD/D/8P/w//D/8P/w//D/8PAQB9////
omOMczEA/w//D/8P/w//D/8P/w//DwEAfv///44+kH8wAP8P/w//D/8P/w//D/8P/w8BAH////+Y
WbiFLwD/D/8P/w//D/8P/w//D/8PAQCA////tL0ovjcA/w//D/8P/w//D/8P/w//DwEAgf///xja
tBo2AP8P/w//D/8P/w//D/8P/w8BAIL///8AlJp8NQD/D/8P/w//D/8P/w//D/8PAQCD////kirG
hDQA/w//D/8P/w//D/8P/w//DwEAiP///ywYst4uAP8P/w//D/8P/w//D/8P/w8BAIn///8S30oS
MwD/D/8P/w//D/8P/w//D/8PAQBqLgQEDwAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAI1lKBwEACgz/
DwAAAAAAAAAAAAAAAAAAAAABAOxrUA1Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDVd+cNVLdMwP8P
AAAAAAAAAAAAAAAAAAAAAAEAjW+RD9DaHJX/DwAAAAAAAAAAAAAAAAAAAAABAIYCxw9Ut0zA/w8A
AAAAAAAAAAAAAAAAAAAAAQDVZkET7kR0k/8PAAAAAAAAAAAAAAAAAAAAAAEAPivkFAEACgz/DwAA
AAAAAAAAAAAAAAAAAAABAOZeHhUBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBsJxQaAQAKDP8PAAAA
AAAAAAAAAAAAAAAAAAEAr1YmGgEACgz/DwAAAAAAAAAAAAAAAAAAAAABAOtpmB4BAAoM/w8AAAAA
AAAAAAAAAAAAAAAAAQBuMyQgVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEAyEhmIlS3TMD/DwAAAAAA
AAAAAAAAAAAAAAABAJwkaCoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBvbessAQAKDP8PAAAAAAAA
AAAAAAAAAAAAAAEAXx55LlS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAK5SuDC4+Io0/w8AAAAAAAAA
AAAAAAAAAAAAAQAzfjs4AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA+BlTOAEACgz/DwAAAAAAAAAA
AAAAAAAAAAABANNasj9Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDvQDVBAQAKDP8PAAAAAAAAAAAA
AAAAAAAAAAEANBnkRAEACgz/DwAAAAAAAAAAAAAAAAAAAAABALVRtEUBAAoM/w8AAAAAAAAAAAAA
AAAAAAAAAQA2MolKAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAs2lIUur+UPn/DwAAAAAAAAAAAAAA
AAAAAAABAAJxRlcBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQASPExXAQAKDP8PAAAAAAAAAAAAAAAA
AAAAAAEATitCXO5EdJP/DwAAAAAAAAAAAAAAAAAAAAABAI4gxl5Ut0zA/w8AAAAAAAAAAAAAAAAA
AAAAAQD8DfdhDwAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA4kQcZAEACgz/DwAAAAAAAAAAAAAAAAAA
AAABAGB5+WRUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDDV/1pVLdMwP8PAAAAAAAAAAAAAAAAAAAA
AAEAvWytbAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAO8b7W8BAAoM/w8AAAAAAAAAAAAAAAAAAAAA
AQCKAg1wAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA6nMsdQEACgz/DwAAAAAAAAAAAAAAAAAAAAAB
AHIVAXgBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQD8NN54VLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA
witVfAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAP
hNQFEYSY/hXGBQAB1AUGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EuQQRhJj+
FcYFAAG5BAYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SeAxGEmP4VxgUAAZ4D
BgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhIMCEYSY/hXGBQABgwIGAgAAAC4A
AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E1AURhJj+FcYFAAHUBQZPSgEAUUoBAG8oAAEA
t/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4S5BBGEmP4VxgUAAbkEBk9KAQBRSgEAbygA
AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhJ4DEYSY/hXGBQABngMGT0oBAFFKAQBv
KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EgwIRhJj+FcYFAAGDAgZPSgEAUUoB
AG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAu
AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB
ALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAA
FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AAA
AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0A
AAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEA
LQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA
AQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABv
KAABAC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oF
AFFKBQBvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP
SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB
Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB
aAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF
AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V
xgUAAWgBBk9KAQBRSgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY
/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro
ARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP
hGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA
AA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAS
EAAAD4RoARGEmP4VxgUAAWgBBkIqAENKHABPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA
AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAA
AAAAAAAAAAAAAAAACxAAAA+EaAERCfDelTef/fyL85em8z86fOH5M+fHc+HqxsJ4eG0tvXpmJbVp
d3/q5G++MP/cE29eRAooBUW9Zi31D9nsvMBIDSBOmTr8KZBQB6NjazmVwImZaTrd1F4gIphqKWQD
q8HsThsCImhn1/BMDLGFjLLl8QQ1Y0nAhiGZwk/JB+DRTAgoyLW3kGd1CBuEZ7W2nEFqsV8FG5v9
51d3HPiZufXDy3PH+nB03/pH29XhLsbF1z58+65jk355+/yjUX72fS9O3r50et365Ym884xqxLA9
ZVN0Zs4PVJv7ZrHU/kEw6MQgkZSicj+ZXCmlSAlFc6+bVMzKjvyMAKDo29I+0Yt2cN2uwgWpxeb6
1ikmzjeRH9iZNDBUmsUSV615toMXjlbLNmKwW9v81B1Lbz3RzePC2plRE86115hvP1/i4sFXT19b
GoyuXl15ohlsnnjw7veMBnkycZmUPa2Rs7an/TG0ToNAHWk1IwjrP7GpfBZkcpZAbWwbZgaJgUJh
IeD/AwD5jFsMJtT2AAAAAElFTkSuQmCCZQBjAG8AcgB5AGEAaABvAG8ALgBhAHIADQANAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABhAG4AZAAgAEkAUwBEAE4AIABkAGUAYgB1AGcAaQBuAGcAIABh
AG4AZAAgAFMAUwA3ACAAYQBuAGQAIABJAFMARABOACAAcwBpAGcAbgBhAGwAbABpAG4AZwANAA0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAGQAZQBiAHUAZwBnAGkAbgBnAFQAaABlAHMAZQAgAGkAbgBjAGwA
dQBkAGUAZQB4AHAAZQByAGkAZQBuAGMAZQBzAHMAaQBnAG4AYQBsAGkAbgBnAA0ADQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGABSAG8AbABhAG4AZABvACAASgBvAHIAZwBlACAAWgBh
AHAAcABhAGMAbwBzAHQAYQAAAAAAAAAQAG0AaQBjAHIAbwBpAG4AZgBvAHIAbQBhAHQAaQBjAGEA
HQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBt
AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAASAFcACgABAFsADwACAAAAAAAAACQAAEDx/wIAJAAAAAYA
TgBvAHIAbQBhAGwAAAACAAAABABtSAoMMgABQAEAAgAyAAAACABUAO0AdAB1AGwAbwAgADEAAAAI
AAEABiQBQCYABwA1CIFtSAkEAEQAAgABAAIARAAAAAgAVADtAHQAdQBsAG8AIAAyAAAAEAACAAYk
AROk8AAUpDwAQCYBEgA1CIE2CIFDShgAT0oCAFFKAgA+AAMAAQACAD4AAAAIAFQA7QB0AHUAbABv
ACAAMwAAABAAAwAGJAETpPAAFKQ8AEAmAgwAQ0oYAE9KAgBRSgIAQgAEAAEAAgBCAAAACABUAO0A
dAB1AGwAbwAgADQAAAAQAAQABiQBE6TwABSkPABAJgMPADUIgUNKGABPSgIAUUoCAAA0AAUAAQAC
ADQAAAAIAFQA7QB0AHUAbABvACAANQAAAA0ABQATpPAAFKQ8AEAmBAAEAENKFgA4AAYAAQACADgA
AAAIAFQA7QB0AHUAbABvACAANgAAAA0ABgATpPAAFKQ8AEAmBQAHADYIgUNKFgAAOAAHAAEAAgA4
AAAACABUAO0AdAB1AGwAbwAgADcAAAANAAcAE6TwABSkPABAJgYACABPSgIAUUoCADwACAABAAIA
PAAAAAgAVADtAHQAdQBsAG8AIAA4AAAADQAIABOk8AAUpDwAQCYHAAsANgiBT0oCAFFKAgAAQgAJ
AAEAAgBCAAAACABUAO0AdAB1AGwAbwAgADkAAAANAAkAE6TwABSkPABAJggAEgA1CIE2CIFDShIA
T0oCAFFKAgBGAEFA8v+hAEYAAAAbAEYAdQBlAG4AdABlACAAZABlACAAcADhAHIAcgBhAGYAbwAg
AHAAcgBlAGQAZQB0AGUAcgAuAAAAAAAAAAAAAAAAAC4AVUCiAPEALgAAAAwASABpAHAAZQByAHYA
7QBuAGMAdQBsAG8AAAAGAD4qAUIqAj4APkABAAIBPgAAAAYAVADtAHQAdQBsAG8AAAAUABAAAyQB
D4QcAUAmAA3GBQABMweACwA1CIFDSigAbUgJBAA0AB9AAQASATQAAAAKAEUAbgBjAGEAYgBlAHoA
YQBkAG8AAAANABEADcYIAAJDEYYiAQIAAAA6ACBAAQAiAToAAAANAFAAaQBlACAAZABlACAAcADh
AGcAaQBuAGEAAAANABIADcYIAAJDEYYiAQIAAAAkAD8AAQAyASQAAAAGAEMAaQBlAHIAcgBlAAAA
BgATAA+EnBAAADoARAABAEIBOgAAAA8AQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEAAAAK
ABQAD4QbARSkeAAAAD4ARQABAFIBPgAAABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEA
IAAyAAAACgAVAA+ENgIUpHgAAAA+AEYAAQBiAT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABp
AHMAdABhACAAMwAAAAoAFgAPhFEDFKR4AAAAPgBHAAEAcgE+AAAAEQBDAG8AbgB0AGkAbgB1AGEA
cgAgAGwAaQBzAHQAYQAgADQAAAAKABcAD4RsBBSkeAAAAD4ASAABAIIBPgAAABEAQwBvAG4AdABp
AG4AdQBhAHIAIABsAGkAcwB0AGEAIAA1AAAACgAYAA+EhwUUpHgAAABaACQAAQCSAVoAAAAPAEQA
aQByAGUAYwBjAGkA8wBuACAAcwBvAGIAcgBlAAAAHQAZABsmgA+EQAsYhPz/GYT0/xqE8B4vhI0A
K0S8BwAMAENKGABPSgIAUUoCAE4ALgABAAIATgAAABMARQBuAGMAYQBiAGUAegBhAGQAbwAgAGQA
ZQAgAGwAaQBzAHQAYQAAAAYAGgATpHgADwA1CIFDShgAT0oCAFFKAgAAbgBJAAEAsgFuAAAAFQBF
AG4AYwBhAGIAZQB6AGEAZABvACAAZABlACAAbQBlAG4AcwBhAGoAZQAAACYAGwAPhG4EEYSS+yRk
BgEAASVkBgEAASZkBgEAASdkBgEAAS1EABAMAENKGABPSgIAUUoCADgATwABAAIAOAAAABIARQBu
AGMAYQBiAGUAegBhAGQAbwAgAGQAZQAgAG4AbwB0AGEAAAACABwAAAAwACIAAQACADAAAAAIAEUA
cADtAGcAcgBhAGYAZQAAAAoAHQATpHgAFKR4AAMANQiBAB4ATAABAAIAHgAAAAUARgBlAGMAaABh
AAAAAgAeAAAAIgBAAAEA8gEiAAAABQBGAGkAcgBtAGEAAAAGAB8AD4ScEAAALAAKAAEAAgAsAAEA
CADNAG4AZABpAGMAZQAgADEAAAAKACAAD4TIABGEOP8AACwACwABAAIALAABAAgAzQBuAGQAaQBj
AGUAIAAyAAAACgAhAA+EkAERhDj/AAAsAAwAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAMwAAAAoA
IgAPhFgCEYQ4/wAALAANAAEAAgAsAAEACADNAG4AZABpAGMAZQAgADQAAAAKACMAD4QgAxGEOP8A
ACwADgABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA1AAAACgAkAA+E6AMRhDj/AAAsAA8AAQACACwA
AQAIAM0AbgBkAGkAYwBlACAANgAAAAoAJQAPhLAEEYQ4/wAALAAQAAEAAgAsAAEACADNAG4AZABp
AGMAZQAgADcAAAAKACYAD4R4BRGEOP8AACwAEQABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA4AAAA
CgAnAA+EQAYRhDj/AAAsABIAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAOQAAAAoAKAAPhAgHEYQ4
/wAAJgAvAAEAkgImAAAABQBMAGkAcwB0AGEAAAAKACkAD4QbARGE5f4AACoAMgABAKICKgAAAAcA
TABpAHMAdABhACAAMgAAAAoAKgAPhDYCEYTl/gAAKgAzAAEAsgIqAAAABwBMAGkAcwB0AGEAIAAz
AAAACgArAA+EUQMRhOX+AAAqADQAAQDCAioAAAAHAEwAaQBzAHQAYQAgADQAAAAKACwAD4RsBBGE
5f4AACoANQABANICKgAAAAcATABpAHMAdABhACAANQAAAAoALQAPhIcFEYTl/gAAPgAxAAEA4gI+
AAAAEQBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAAAAJAC4ACiYAC0YqAAAAAEIA
OgABAPICQgAAABMATABpAHMAdABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzACAAMgAAAAkALwAK
JgALRisAAAAAQgA7AAEAAgNCAAAAEwBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMA
IAAzAAAACQAwAAomAAtGLAAAAABCADwAAQASA0IAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6
AG0AZQByAG8AcwAgADQAAAAJADEACiYAC0YtAAAAAEIAPQABACIDQgAAABMATABpAHMAdABhACAA
YwBvAG4AIABuAPoAbQBlAHIAbwBzACAANQAAAAkAMgAKJgALRi4AAAAAPgAwAAEAMgM+AAEAEQBM
AGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAAAAJADMACiYAC0YvAAAAAEIANgABAEID
QgABABMATABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAAMgAAAAkANAAKJgALRjAA
AAAAQgA3AAEAUgNCAAEAEwBMAGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAIAAzAAAA
CQA1AAomAAtGMQAAAABCADgAAQBiA0IAAQATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBpAPEAZQB0
AGEAcwAgADQAAAAJADYACiYAC0YyAAAAAEIAOQABAHIDQgABABMATABpAHMAdABhACAAYwBvAG4A
IAB2AGkA8QBlAHQAYQBzACAANQAAAAkANwAKJgALRjMAAAAARABZAAEAggNEAAAAEgBNAGEAcABh
ACAAZABlAGwAIABkAG8AYwB1AG0AZQBuAHQAbwAAAAYAOAAtRCABCABPSgMAUUoDADoAJQABAJID
OgAAAA8AUgBlAG0AaQB0AGUAIABkAGUAIABzAG8AYgByAGUAAAACADkACABPSgIAUUoCACAASwAB
AAIAIAAAAAYAUwBhAGwAdQBkAG8AAAACADoAAABcAFIAAQCyA1wAAAAdAFMAYQBuAGcAcgDtAGEA
IAAyACAAZABlACAAdAAuACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAAABAAOwAPhBsBEmTg
AQEAFKR4AAAAWgBTAAEAwgNaAAAAHQBTAGEAbgBnAHIA7QBhACAAMwAgAGQAZQAgAHQALgAgAGkA
bgBkAGUAcABlAG4AZABpAGUAbgB0AGUAAAAKADwAD4QbARSkeAAEAENKEABSAEMAAQDSA1IAAAAb
AFMAYQBuAGcAcgDtAGEAIABkAGUAIAB0AC4AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4AdABlAAAA
CgA9AA+EGwEUpHgAAAA0ABwAAQDiAzQAAAAOAFMAYQBuAGcAcgDtAGEAIABuAG8AcgBtAGEAbAAA
AAYAPgAPhMQCAAA8AEoAAQDyAzwAAAAJAFMAdQBiAHQA7QB0AHUAbABvAAAADAA/AAMkARSkPABA
JgEMAENKGABPSgIAUUoCAEgAIwABAAIASAAAABYAVABhAGIAbABhACAAZABlACAAaQBsAHUAcwB0
AHIAYQBjAGkAbwBuAGUAcwAAAAoAQAAPhJABEYRw/gAAHgATAAEAAgAeAAEABQBUAEQAQwAgADEA
AAACAEEAAAAiABQAAQACACIAAQAFAFQARABDACAAMgAAAAYAQgAPhMgAAAAiABUAAQACACIAAQAF
AFQARABDACAAMwAAAAYAQwAPhJABAAAiABYAAQACACIAAQAFAFQARABDACAANAAAAAYARAAPhFgC
AAAiABcAAQACACIAAQAFAFQARABDACAANQAAAAYARQAPhCADAAAiABgAAQACACIAAQAFAFQARABD
ACAANgAAAAYARgAPhOgDAAAiABkAAQACACIAAQAFAFQARABDACAANwAAAAYARwAPhLAEAAAiABoA
AQACACIAAQAFAFQARABDACAAOAAAAAYASAAPhHgFAAAiABsAAQACACIAAQAFAFQARABDACAAOQAA
AAYASQAPhEAGAAA0AB4AAQCiBDQAAAAQAFQAZQB4AHQAbwAgAGMAbwBtAGUAbgB0AGEAcgBpAG8A
AAACAEoAAAA+ACwAAQACAD4AAAARAFQAZQB4AHQAbwAgAGMAbwBuACAAcwBhAG4AZwByAO0AYQAA
AAoASwAPhMgAEYQ4/wAAPgBUAAEAwgQ+AAAADwBUAGUAeAB0AG8AIABkAGUAIABiAGwAbwBxAHUA
ZQAAAA4ATAAOhKAFD4SgBRSkeAAAAD4AQgABANIEPgAAABMAVABlAHgAdABvACAAaQBuAGQAZQBw
AGUAbgBkAGkAZQBuAHQAZQAAAAYATQAUpHgAAABIAFAAAQDiBEgAAAAVAFQAZQB4AHQAbwAgAGkA
bgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIAAyAAAADABOABJk4AEBABSkeAAAAEYAUQABAPIERgAA
ABUAVABlAHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAgADMAAAAGAE8AFKR4AAQA
Q0oQAF4ATQDRBAIFXgAAACMAVABlAHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAg
AHAAcgBpAG0AZQByAGEAIABzAGEAbgBnAHIA7QBhAAAABgBQABGE0gAAAGIATgDRAxIFYgAAACUA
VABlAHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAgAHAAcgBpAG0AZQByAGEAIABz
AGEAbgBnAHIA7QBhACAAMgAAAAYAUQARhNIAAABWAC0A8f8iBVYAAAALAFQAZQB4AHQAbwAgAG0A
YQBjAHIAbwAAACIAUgANxh0ACeABwAOgBYAHYAlACyANAA/gEAAAAAAAAAAAAAwAT0oEAFFKBABt
SAoMOgArAAEAMgU6AAAAEwBUAGUAeAB0AG8AIABuAG8AdABhACAAYQBsACAAZgBpAG4AYQBsAAAA
AgBTAAAAMAAdAAEAQgUwAAAADgBUAGUAeAB0AG8AIABuAG8AdABhACAAcABpAGUAAAACAFQAAAA+
AFoAAQBSBT4AAAARAFQAZQB4AHQAbwAgAHMAaQBuACAAZgBvAHIAbQBhAHQAbwAAAAIAVQAIAE9K
BABRSgQAQAAhAAEAAgJAAAAAEABUAO0AdAB1AGwAbwAgAGQAZQAgAO0AbgBkAGkAYwBlAAAAAgBW
AAsANQiBT0oCAFFKAgAAAAAAANoSAAAEAAA2AAAAAP////8AAAAAGQAAABoAAAApAAAAQgAAAFoA
AAByAAAAjwAAAK0AAACuAAAArwAAALkAAAC6AAAA1AAAAAQBAAAZAQAANQEAAEwBAABmAQAAgwEA
AI4BAAChAQAAsQEAAPkBAAAMAgAAHgIAAB8CAAAgAgAAIQIAACwCAAAtAgAAxwIAAMgCAADJAgAA
ygIAANYCAADXAgAAgQQAAJIEAACsBAAAtgQAAOMEAAAJBQAARAUAAG0FAADcBQAAJAgAADUIAAA4
CAAAPAgAAFwIAADCCAAA9wgAABEJAAA7CgAATAoAAGoKAACdCgAABAsAAD8LAABACwAAQQsAAEIL
AABNCwAATgsAAKQLAACsCwAA5gsAAAwMAABDDAAAggwAAIMMAACEDAAAhQwAAI4MAACPDAAA0AwA
ACANAACJDQAAzA0AABYOAABZDgAA5w4AAD8PAACpDwAAQxAAALoQAAC7EAAAvBAAAL0QAADOEAAA
zxAAANQQAADwEAAAAREAAE4RAABsEQAAbREAAG4RAAB5EQAAehEAAK4RAAD7EQAAXhIAAF8SAABg
EgAAYRIAAG0SAABuEgAAhhIAAIcSAACIEgAAiRIAAJwSAACyEgAA2BIAANsSAAAIAAAAEAAAAAAA
AAAAgAAAAIAIAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgBkAAACYAAAAAAAAAAAAAAAA
gBkAAAAIAAAAAAAAAAAAAAAAgAAAAIAIAAAAAAAAAAAAAAAAgAAAAIAIAAAAAAAAAAAAAAAAgAAA
AIAIAAAAAAAAAAAAAAAAgAAAAIAIAAAAAAAAAAAAAAAAgAAAAICpAAAAAAAAAAAAAAAAgK0AAACp
AAAAAQAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAAgK0AAACpAAMgAQAAAAAAAAAAgK0AAACpAAMg
AAABAAAAAAAAgK0AAACpACQgAAAAAAAAAAAAgK0AAACpACQgAAABAAAAAAAAgK0AAACpAAMgAAAC
AAAAAAAAgK0AAACpAAMgAAADAAAAAAAAgK0AAACpAAMgAAAEAAAAAAAAgK0AAACpAAMgAAAFAAAA
AAAAgK0AAACpACcgAAAAAAAAAAAAgK0AAACpACcgAAABAAAAAAAAgK0AAACpACYgAAAAAAAAAAAA
gK0AAACpACUgAAAAAAAAAAAAgK0AAACpACUgAAABAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0A
AACZAAAAAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAAgK0AAACp
AAAAAAAAAAAAAAAAgK0AAACpAAogAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACZAAAA
AAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAAgK0AAACpAAAAEQAA
AAAAAAAAgK0AAACpAAcgAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpABogAAAAAAAA
AAAAgK0AAACpABogAAABAAAAAAAAgK0AAACpABogAAACAAAAAAAAgK0AAACpABogAAADAAAAAAAA
gK0AAACpABogAAAEAAAAAAAAgK0AAACpABogAAAFAAAAAAAAgK0AAACpABogAAAGAAAAAAAAgK0A
AACpAB0gAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpABwgAAAAAAAAAAAAgK0AAACp
ABwgAAABAAAAAAAAgK0AAACpABwgAAACAAAAAAAAgK0AAACpABwgAAADAAAAAAAAgK0AAACpABwg
AAAEAAAAAAAAgK0AAACpABwgAAAFAAAAAAAAgK0AAACpABMgAAAAAAAAAAAAgK0AAACpAAAAAAAA
AAAAAAAAgK0AAACpABYgAAAAAAAAAAAAgK0AAACpABYgAAABAAAAAAAAgK0AAACpABYgAAACAAAA
AAAAgK0AAACpABYgAAADAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACZAAAAAAAAAAAAAAAA
gK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0A
AACpAAogAAABAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpABsgAAAAAAAAAAAAgK0AAACp
ABsgAAABAAAAAAAAgK0AAACpABsgAAACAAAAAAAAgK0AAACpABsgAAADAAAAAAAAgK0AAACpAAAA
AAAAAAAAAAAAgK0AAACZAAAAAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAAAAQAA
AAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAwgAAAAAAAAAAAAgK0AAACpAAwgAAABAAAA
AAAAgK0AAACpAAwgAAACAAAAAAAAgK0AAACpAAwgAAADAAAAAAAAgK0AAACpAAwgAAAEAAAAAAAA
gK0AAACpAAwgAAAFAAAAAAAAgK0AAACpAAwgAAAGAAAAAAAAgK0AAACpAAwgAAAHAAAAAAAAgK0A
AACpAAwgAAAIAAAAAAAAgK0AAACpAAwgAAAJAAAAAAAAgK0AAACpAAwgAAAKAAAAAAAAgK0AAACp
AAAAAAAAAAAAAAAAgK0AAACZAAAAAAAAAAAAAAAAgK0AAACpQAAAAAAAAAAAAAAAgK0AAACpAAAA
AQAAAAAAAAAAgK0AAACpQAAAAAAAAAAAAAAAgK0AAACpAA4gAAAAAAAAAAAAgK0AAACpAA4gAAAB
AAAAAAAAgK0AAACpAA4gAAACAAAAAAAAgK0AAACpAA4gAAADAAAAAAAAgK0AAACpAA4gAAAEAAAA
AAAAgK0AAACZAAAAAAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAA
gK0AAACpAAAAEQAAAAAAAAAAgK0AAACpAAcgAAABAAAAAAAAgK0AAACpAAcgAAACAAAAAAAAgK0A
AACpAAcgAAADAAAAAAAAgK0AAACpAAAAEQAAAAAAAAAAgK0AAACZAAAAAAAAAAAAAAAAgK0AAACp
AAAAAAAAAAAAAAAAgK0AAACpAAAAAQAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACpACkg
AAAAAAAAAAAAgK0AAACpAAAAAAAAAAAAAAAAgK0AAACZAAAAAAAAAAAAAAAAgK0AAAAIAAAAAAAA
AAAAAAAAgAAAAICaQAAAEgAAAAAAAAAAgAAAAICYQAAAEgAAAAAAAAAAgAAAAICaQAAAAAAAAAAA
AAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAKgAAACoAAABPAAAAUgAAAAAEAAAQFQAAWIQAAAwAAAAXAAAAAAQAAIkFAADDBgAA
+gsAAG0PAAB+FAAAPRUAAJYWAABYhAAADQAAAA8AAAARAAAAEgAAABQAAAAWAAAAGAAAABoAAAAA
BAAAwgYAAA4OAAAcEgAAMBYAAJgWAAAOAAAAEAAAABMAAAAVAAAAGQAAAA8AAPBsAAAAAAAG8BgA
AAACCAAAAgAAAAIAAAABAAAAAQAAAAMAAAAfAAHwLAAAAGIAB/AkAAAABgZt6WDCK3TdlKUFLt8c
eDsJ/wBsRwAAAQAAACY2AAAAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvA0AQAAEAAI
8AgAAAACAAAAAgQAAA8AA/DSAAAADwAE8CgAAAABAAnwEAAAAAAADQAAAAwAAAALAAAAAAACAArw
CAAAAAAEAAAFAAAADwAE8JoAAACyBArwCAAAAAIEAAAACgAAYwAL8GoAAAAEQQEAAAAFwRgAAAAG
AQIAAAD/AQAACACDwy4AAAC/AyAAYABBADoAXABmAG8AdABvAC4AcABjAHgAAAAFAAgACAAh////
AAAAACH///+jUwAAYFQAAKNTAABgVAAAAAAAACH///8AAAAAAAAQ8AQAAAAAAAAAAAAR8AQAAAAH
AAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkA
AAA/AwEAAQAAABHwBAAAAAEAAAAaAAAA2hIAAAIEAAAmFwAAYgAAANUcAAAQBwAAtEIAAAAAAAAA
AIkSAACyEgAAsxIAANcSAADbEgAABwAHAAIABwACAAAAAACJEgAA2BIAANsSAAAHAAcAAgD//xQA
AAAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwBy
AG0AYQBBAEMAOgBcAFcASQBOAEQATwBXAFMAXABUAEUATQBQAFwARwB1AGEAcgBkAGEAZABvACAA
YwBvAG4AIABBAHUAdABvAHIAcgBlAGMAdQBwAGUAcgBhAGMAaQDzAG4AIABkAGUAIABDAFYAXwBS
AEoAWgBfAEUATgBHADIALgBhAHMAZAAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0A
YQBzACAAZABlACAASQBuAGYAbwByAG0AYQAhAEMAOgBcAE0AaQBzACAAZABvAGMAdQBtAGUAbgB0
AG8AcwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIAZQBjAGMAaQBvAG4A
IABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAEEAQwA6AFwAVwBJAE4ARABP
AFcAUwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0AG8AcgByAGUA
YwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGEAcwBk
AB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIA
bQBhACEAQwA6AFwATQBpAHMAIABkAG8AYwB1AG0AZQBuAHQAbwBzAFwAQwBWAF8AUgBKAFoAXwBF
AE4ARwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQA
ZQAgAEkAbgBmAG8AcgBtAGEAJQBDADoAXABXAEkATgBEAE8AVwBTAFwARQBzAGMAcgBpAHQAbwBy
AGkAbwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIAZQBjAGMAaQBvAG4A
IABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhACUAQwA6AFwAVwBJAE4ARABP
AFcAUwBcAEUAcwBjAHIAaQB0AG8AcgBpAG8AXABDAFYAXwBSAEoAWgBfAEUATgBHADIALgBkAG8A
YwAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwBy
AG0AYQAlAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBWAF8A
UgBKAFoAXwBFAE4ARwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBt
AGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAJQBDADoAXABXAEkATgBEAE8AVwBTAFwARQBzAGMA
cgBpAHQAbwByAGkAbwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIAZQBj
AGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhACUAQwA6AFwA
VwBJAE4ARABPAFcAUwBcAEUAcwBjAHIAaQB0AG8AcgBpAG8AXABDAFYAXwBSAEoAWgBfAEUATgBH
ADIALgBkAG8AYwAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAA
SQBuAGYAbwByAG0AYQAlAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBv
AFwAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AZABvAGMAMwB8////nlAKqTIA/w//D/8P/w//D/8P
/w//DwEAff///6JjjHMxAP8P/w//D/8P/w//D/8P/w8BAH7///+OPpB/MAD/D/8P/w//D/8P/w//
D/8PAQB/////mFm4hS8A/w//D/8P/w//D/8P/w//DwEAgP///7S9KL43AP8P/w//D/8P/w//D/8P
/w8BAIH///8Y2rQaNgD/D/8P/w//D/8P/w//D/8PAQCC////AJSafDUA/w//D/8P/w//D/8P/w//
DwEAg////5IqxoQ0AP8P/w//D/8P/w//D/8P/w8BAIj///8sGLLeLgD/D/8P/w//D/8P/w//D/8P
AQCJ////Et9KEjMA/w//D/8P/w//D/8P/w//DwEAai4EBA8ACgz/DwAAAAAAAAAAAAAAAAAAAAAB
ACNZSgcBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDsa1ANVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA
1XfnDVS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAI1vkQ/Q2hyV/w8AAAAAAAAAAAAAAAAAAAAAAQCG
AscPVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA1WZBE+5EdJP/DwAAAAAAAAAAAAAAAAAAAAABAD4r
5BQBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDmXh4VAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAbCcU
GgEACgz/DwAAAAAAAAAAAAAAAAAAAAABAK9WJhoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDraZge
AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAbjMkIFS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAMhIZiJU
t0zA/w8AAAAAAAAAAAAAAAAAAAAAAQCcJGgqAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAb23rLAEA
Cgz/DwAAAAAAAAAAAAAAAAAAAAABAF8eeS5Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQCuUrgwuPiK
NP8PAAAAAAAAAAAAAAAAAAAAAAEAM347OAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAPgZUzgBAAoM
/w8AAAAAAAAAAAAAAAAAAAAAAQDTWrI/VLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEA70A1QQEACgz/
DwAAAAAAAAAAAAAAAAAAAAABADQZ5EQBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQC1UbRFAQAKhJj+
FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE
mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB
EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E
aAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA
D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8Q
AAAPhGgBEYSY/hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA
AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgUAUUoFAG8oAAEAp/AAAAAAFwAAAAAA
AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAA
AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAAAAAAAAAA
AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAAAAAAXAAAAAAAA
AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAQAAABcAAAAA
AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAA
AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAX
AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA
ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB
AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3
8AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAAB
AC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o
AAEAt/AzAAAA6nMsdQAAAAAAAAAAAAAAAG9t6ywAAAAAAAAAAAAAAAAjWUoHAAAAAAAAAAAAAAAA
AnFGVwAAAAAAAAAAAAAAAJwkaCoAAAAAAAAAAAAAAAD4GVM4AAAAAAAAAAAAAAAAchUBeAAAAAAA
AAAAAAAAAO8b7W8AAAAAAAAAAAAAAAC1UbRFAAAAAAAAAAAAAAAA70A1QQAAAAAAAAAAAAAAADQZ
5EQAAAAAAAAAAAAAAADraZgeAAAAAAAAAAAAAAAArlK4MAAAAAAAAAAAAAAAADN+OzgAAAAAAAAA
AAAAAAA+K+QUAAAAAAAAAAAAAAAANjKJSgAAAAAAAAAAAAAAAMIrVXwAAAAAAAAAAAAAAAC9bK1s
AAAAAAAAAAAAAAAAigINcAAAAAAAAAAAAAAAAGouBAQAAAAAAAAAAAAAAAD8DfdhAAAAEgBXAAoA
AQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAQAbUgKDDIAAUAB
AAIAMgAAAAgAVADtAHQAdQBsAG8AIAAxAAAACAABAAYkAUAmAAcANQiBbUgJBABEAAIAAQACAEQA
AAAIAFQA7QB0AHUAbABvACAAMgAAABAAAgAGJAETpPAAFKQ8AEAmARIANQiBNgiBQ0oYAE9KAgBR
SgIAPgADAAEAAgA+AAAACABUAO0AdAB1AGwAbwAgADMAAAAQAAMABiQBE6TwABSkPABAJgIMAENK
GABPSgIAUUoCAEIABAABAAIAQgAAAAgAVADtAHQAdQBsAG8AIAA0AAAAEAAEAAYkAROk8AAUpDwA
QCYDDwA1CIFDShgAT0oCAFFKAgAANAAFAAEAAgA0AAAACABUAO0AdAB1AGwAbwAgADUAAAANAAUA
E6TwABSkPABAJgQABABDShYAOAAGAAEAAgA4AAAACABUAO0AdAB1AGwAbwAgADYAAAANAAYAE6Tw
ABSkPABAJgUABwA2CIFDShYAADgABwABAAIAOAAAAAgAVADtAHQAdQBsAG8AIAA3AAAADQAHABOk
8AAUpDwAQCYGAAgAT0oCAFFKAgA8AAgAAQACADwAAAAIAFQA7QB0AHUAbABvACAAOAAAAA0ACAAT
pPAAFKQ8AEAmBwALADYIgU9KAgBRSgIAAEIACQABAAIAQgAAAAgAVADtAHQAdQBsAG8AIAA5AAAA
DQAJABOk8AAUpDwAQCYIABIANQiBNgiBQ0oSAE9KAgBRSgIARgBBQPL/oQBGAAAAGwBGAHUAZQBu
AHQAZQAgAGQAZQAgAHAA4QByAHIAYQBmAG8AIABwAHIAZQBkAGUAdABlAHIALgAAAAAAAAAAAAAA
AAAuAFVAogDxAC4AAAAMAEgAaQBwAGUAcgB2AO0AbgBjAHUAbABvAAAABgA+KgFCKgI+AD5AAQAC
AT4AAAAGAFQA7QB0AHUAbABvAAAAFAAQAAMkAQ+EHAFAJgANxgUAATMHgAsANQiBQ0ooAG1ICQQA
NAAfQAEAEgE0AAAACgBFAG4AYwBhAGIAZQB6AGEAZABvAAAADQARAA3GCAACQxGGIgECAAAAOgAg
QAEAIgE6AAAADQBQAGkAZQAgAGQAZQAgAHAA4QBnAGkAbgBhAAAADQASAA3GCAACQxGGIgECAAAA
JAA/AAEAMgEkAAAABgBDAGkAZQByAHIAZQAAAAYAEwAPhJwQAAA6AEQAAQBCAToAAAAPAEMAbwBu
AHQAaQBuAHUAYQByACAAbABpAHMAdABhAAAACgAUAA+EGwEUpHgAAAA+AEUAAQBSAT4AAAARAEMA
bwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhACAAMgAAAAoAFQAPhDYCFKR4AAAAPgBGAAEAYgE+
AAAAEQBDAG8AbgB0AGkAbgB1AGEAcgAgAGwAaQBzAHQAYQAgADMAAAAKABYAD4RRAxSkeAAAAD4A
RwABAHIBPgAAABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEAIAA0AAAACgAXAA+EbAQU
pHgAAAA+AEgAAQCCAT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhACAANQAAAAoA
GAAPhIcFFKR4AAAAWgAkAAEAkgFaAAAADwBEAGkAcgBlAGMAYwBpAPMAbgAgAHMAbwBiAHIAZQAA
AB0AGQAbJoAPhEALGIT8/xmE9P8ahPAeL4SNACtEvAcADABDShgAT0oCAFFKAgBOAC4AAQACAE4A
AAATAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABsAGkAcwB0AGEAAAAGABoAE6R4AA8ANQiB
Q0oYAE9KAgBRSgIAAG4ASQABALIBbgAAABUARQBuAGMAYQBiAGUAegBhAGQAbwAgAGQAZQAgAG0A
ZQBuAHMAYQBqAGUAAAAmABsAD4RuBBGEkvskZAYBAAElZAYBAAEmZAYBAAEnZAYBAAEtRAAQDABD
ShgAT0oCAFFKAgA4AE8AAQACADgAAAASAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABuAG8A
dABhAAAAAgAcAAAAMAAiAAEAAgAwAAAACABFAHAA7QBnAHIAYQBmAGUAAAAKAB0AE6R4ABSkeAAD
ADUIgQAeAEwAAQACAB4AAAAFAEYAZQBjAGgAYQAAAAIAHgAAACIAQAABAPIBIgAAAAUARgBpAHIA
bQBhAAAABgAfAA+EnBAAACwACgABAAIALAABAAgAzQBuAGQAaQBjAGUAIAAxAAAACgAgAA+EyAAR
hDj/AAAsAAsAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAMgAAAAoAIQAPhJABEYQ4/wAALAAMAAEA
AgAsAAEACADNAG4AZABpAGMAZQAgADMAAAAKACIAD4RYAhGEOP8AACwADQABAAIALAABAAgAzQBu
AGQAaQBjAGUAIAA0AAAACgAjAA+EIAMRhDj/AAAsAA4AAQACACwAAQAIAM0AbgBkAGkAYwBlACAA
NQAAAAoAJAAPhOgDEYQ4/wAALAAPAAEAAgAsAAEACADNAG4AZABpAGMAZQAgADYAAAAKACUAD4Sw
BBGEOP8AACwAEAABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA3AAAACgAmAA+EeAURhDj/AAAsABEA
AQACACwAAQAIAM0AbgBkAGkAYwBlACAAOAAAAAoAJwAPhEAGEYQ4/wAALAASAAEAAgAsAAEACADN
AG4AZABpAGMAZQAgADkAAAAKACgAD4QIBxGEOP8AACYALwABAJICJgAAAAUATABpAHMAdABhAAAA
CgApAA+EGwERhOX+AAAqADIAAQCiAioAAAAHAEwAaQBzAHQAYQAgADIAAAAKACoAD4Q2AhGE5f4A
ACoAMwABALICKgAAAAcATABpAHMAdABhACAAMwAAAAoAKwAPhFEDEYTl/gAAKgA0AAEAwgIqAAAA
BwBMAGkAcwB0AGEAIAA0AAAACgAsAA+EbAQRhOX+AAAqADUAAQDSAioAAAAHAEwAaQBzAHQAYQAg
ADUAAAAKAC0AD4SHBRGE5f4AAD4AMQABAOICPgAAABEATABpAHMAdABhACAAYwBvAG4AIABuAPoA
bQBlAHIAbwBzAAAACQAuAAomAAtGKgAAAABCADoAAQDyAkIAAAATAEwAaQBzAHQAYQAgAGMAbwBu
ACAAbgD6AG0AZQByAG8AcwAgADIAAAAJAC8ACiYAC0YrAAAAAEIAOwABAAIDQgAAABMATABpAHMA
dABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzACAAMwAAAAkAMAAKJgALRiwAAAAAQgA8AAEAEgNC
AAAAEwBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAA0AAAACQAxAAomAAtGLQAA
AABCAD0AAQAiA0IAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6AG0AZQByAG8AcwAgADUAAAAJ
ADIACiYAC0YuAAAAAD4AMAABADIDPgABABEATABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQA
YQBzAAAACQAzAAomAAtGLwAAAABCADYAAQBCA0IAAQATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBp
APEAZQB0AGEAcwAgADIAAAAJADQACiYAC0YwAAAAAEIANwABAFIDQgABABMATABpAHMAdABhACAA
YwBvAG4AIAB2AGkA8QBlAHQAYQBzACAAMwAAAAkANQAKJgALRjEAAAAAQgA4AAEAYgNCAAEAEwBM
AGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAIAA0AAAACQA2AAomAAtGMgAAAABCADkA
AQByA0IAAQATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBpAPEAZQB0AGEAcwAgADUAAAAJADcACiYA
C0YzAAAAAEQAWQABAIIDRAAAABIATQBhAHAAYQAgAGQAZQBsACAAZABvAGMAdQBtAGUAbgB0AG8A
AAAGADgALUQgAQgAT0oDAFFKAwA6ACUAAQCSAzoAAAAPAFIAZQBtAGkAdABlACAAZABlACAAcwBv
AGIAcgBlAAAAAgA5AAgAT0oCAFFKAgAgAEsAAQACACAAAAAGAFMAYQBsAHUAZABvAAAAAgA6AAAA
XABSAAEAsgNcAAAAHQBTAGEAbgBnAHIA7QBhACAAMgAgAGQAZQAgAHQALgAgAGkAbgBkAGUAcABl
AG4AZABpAGUAbgB0AGUAAAAQADsAD4QbARJk4AEBABSkeAAAAFoAUwABAMIDWgAAAB0AUwBhAG4A
ZwByAO0AYQAgADMAIABkAGUAIAB0AC4AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4AdABlAAAACgA8
AA+EGwEUpHgABABDShAAUgBDAAEA0gNSAAAAGwBTAGEAbgBnAHIA7QBhACAAZABlACAAdAAuACAA
aQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAAAAoAPQAPhBsBFKR4AAAANAAcAAEA4gM0AAAADgBT
AGEAbgBnAHIA7QBhACAAbgBvAHIAbQBhAGwAAAAGAD4AD4TEAgAAPABKAAEA8gM8AAAACQBTAHUA
YgB0AO0AdAB1AGwAbwAAAAwAPwADJAEUpDwAQCYBDABDShgAT0oCAFFKAgBIACMAAQACAEgAAAAW
AFQAYQBiAGwAYQAgAGQAZQAgAGkAbAB1AHMAdAByAGEAYwBpAG8AbgBlAHMAAAAKAEAAD4SQARGE
cP4AAB4AEwABAAIAHgABAAUAVABEAEMAIAAxAAAAAgBBAAAAIgAUAAEAAgAiAAEABQBUAEQAQwAg
ADIAAAAGAEIAD4TIAAAAIgAVAAEAAgAiAAEABQBUAEQAQwAgADMAAAAGAEMAD4SQAQAAIgAWAAEA
AgAiAAEABQBUAEQAQwAgADQAAAAGAEQAD4RYAgAAIgAXAAEAAgAiAAEABQBUAEQAQwAgADUAAAAG
AEUAD4QgAwAAIgAYAAEAAgAiAAEABQBUAEQAQwAgADYAAAAGAEYAD4ToAwAAIgAZAAEAAgAiAAEA
BQBUAEQAQwAgADcAAAAGAEcAD4SwBAAAIgAaAAEAAgAiAAEABQBUAEQAQwAgADgAAAAGAEgAD4R4
BQAAIgAbAAEAAgAiAAEABQBUAEQAQwAgADkAAAAGAEkAD4RABgAANAAeAAEAogQ0AAAAEABUAGUA
eAB0AG8AIABjAG8AbQBlAG4AdABhAHIAaQBvAAAAAgBKAAAAPgAsAAEAAgA+AAAAEQBUAGUAeAB0
AG8AIABjAG8AbgAgAHMAYQBuAGcAcgDtAGEAAAAKAEsAD4TIABGEOP8AAD4AVAABAMIEPgAAAA8A
VABlAHgAdABvACAAZABlACAAYgBsAG8AcQB1AGUAAAAOAEwADoSgBQ+EoAUUpHgAAAA+AEIAAQDS
BD4AAAATAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAAAAGAE0AFKR4AAAA
SABQAAEA4gRIAAAAFQBUAGUAeAB0AG8AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4AdABlACAAMgAA
AAwATgASZOABAQAUpHgAAABGAFEAAQDyBEYAAAAVAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4A
ZABpAGUAbgB0AGUAIAAzAAAABgBPABSkeAAEAENKEABeAE0A0QQCBV4AAAAjAFQAZQB4AHQAbwAg
AGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAAcwBhAG4AZwByAO0A
YQAAAAYAUAARhNIAAABiAE4A0QMSBWIAAAAlAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABp
AGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAAcwBhAG4AZwByAO0AYQAgADIAAAAGAFEAEYTSAAAA
VgAtAPH/IgVWAAAACwBUAGUAeAB0AG8AIABtAGEAYwByAG8AAAAiAFIADcYdAAngAcADoAWAB2AJ
QAsgDQAP4BAAAAAAAAAAAAAMAE9KBABRSgQAbUgKDDoAKwABADIFOgAAABMAVABlAHgAdABvACAA
bgBvAHQAYQAgAGEAbAAgAGYAaQBuAGEAbAAAAAIAUwAAADAAHQABAEIFMAAAAA4AVABlAHgAdABv
ACAAbgBvAHQAYQAgAHAAaQBlAAAAAgBUAAAAPgBaAAEAUgU+AAAAEQBUAGUAeAB0AG8AIABzAGkA
bgAgAGYAbwByAG0AYQB0AG8AAAACAFUACABPSgQAUUoEAEAAIQABAAICQAAAABAAVADtAHQAdQBs
AG8AIABkAGUAIADtAG4AZABpAGMAZQAAAAIAVgALADUIgU9KAgBRSgIAAAAAAACdEgAABAAANgAA
AAD/////AAAAAI8AAACtAAAAUBIAAJ4SAACeAAAAAAAAAAAAAAAAgAAAAIAIAAAAAAAAAAAAAAAA
gAAAAICeAAAAAAAAAAAAAAAAgAAAAIAIAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAACUAAABKAAAATQAAAAAEAAAQFQAArn0AAAwAAAAX
AAAAAAQAAIkFAADDBgAA+gsAAG0PAAB+FAAAPRUAAJYWAACufQAADQAAAA8AAAARAAAAEgAAABQA
AAAWAAAAGAAAABoAAAAABAAAwgYAAA4OAAAcEgAAMBYAAJgWAAAOAAAAEAAAABMAAAAVAAAAGQAA
AA8AAPBsAAAAAAAG8BgAAAACCAAAAgAAAAIAAAABAAAAAQAAAAMAAAAfAAHwLAAAAGIAB/AkAAAA
BgZt6WDCK3TdlKUFLt8ceDsJ/wBsRwAAAQAAACY2AAAAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3
AAAQAA8AAvA0AQAAEAAI8AgAAAACAAAAAgQAAA8AA/DSAAAADwAE8CgAAAABAAnwEAAAAAAADQAA
AAwAAAALAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8JoAAACyBArwCAAAAAIEAAAACgAAYwAL8GoA
AAAEQQEAAAAFwRgAAAAGAQIAAAD/AQAACACDwy4AAAC/AyAAYABBADoAXABmAG8AdABvAC4AcABj
AHgAAAAFAAgACAAh////AAAAACH///+jUwAAYFQAAKNTAABgVAAAAAAAACH///8AAAAAAAAQ8AQA
AAAAAAAAAAAR8AQAAAAGAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADL
AQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAAaAAAAnRIAAAIEAAAmFwAAYgAAANUc
AAAQBwAAtEIAAAAAAAAAABkAAAAZAAAAGgAAABoAAABxAAAAjgAAAI8AAACQAAAAlwAAAJcAAACc
AAAAnwAAAKAAAAClAAAAqQAAAKwAAADTAAAA0wAAADQBAAA0AQAASwEAAEsBAABlAQAAZQEAAIIB
AACCAQAAgwEAALoBAADIAQAAyQEAABwCAAAcAgAAHQIAAB0CAAAeAgAAHgIAAPsCAAD8AgAAzgMA
AHMEAACJBAAAkwQAAJQEAACUBAAAoAQAAMUEAADQBAAA2QQAAPoEAAD7BAAAVAUAAKIFAAC7BQAA
vAUAAL0IAADWCAAA5QsAAOULAACDEAAAgxAAADIRAAAzEQAANREAAFASAACeEgAAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAAHAAAAAAAZAAAAGQAAABoAAAAaAAAAcQAAAI4AAACPAAAAkAAAAJcAAACXAAAAnAAAAJ8A
AACgAAAApQAAAKkAAACsAAAAuAAAALkAAADTAAAA0wAAADQBAAA0AQAASwEAAEsBAABlAQAAZQEA
AIIBAACCAQAAgwEAALoBAADIAQAAyQEAABwCAAAcAgAAHQIAAB0CAAAeAgAAHgIAACsCAAAsAgAA
1QIAANYCAAD7AgAA/AIAAM4DAABzBAAAiQQAAJMEAACUBAAAlAQAAKAEAADFBAAA0AQAANkEAAD6
BAAA+wQAAFQFAACiBQAAuwUAALwFAAC9CAAA1ggAABILAAATCwAA5QsAAOULAABTDAAAVAwAAIMQ
AACDEAAAlRAAAJYQAAAyEQAAMxEAADURAABQEgAAnhIAAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQABwD//xQAAAAdAEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0A
YQBzACAAZABlACAASQBuAGYAbwByAG0AYQAhAEMAOgBcAE0AaQBzACAAZABvAGMAdQBtAGUAbgB0
AG8AcwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIAZQBjAGMAaQBvAG4A
IABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAEEAQwA6AFwAVwBJAE4ARABP
AFcAUwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0AG8AcgByAGUA
YwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGEAcwBk
AB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIA
bQBhAEEAQwA6AFwAVwBJAE4ARABPAFcAUwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8AIABj
AG8AbgAgAEEAdQB0AG8AcgByAGUAYwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgBfAFIA
SgBaAF8ARQBOAEcAMgAuAGEAcwBkAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBh
AHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAEEAQwA6AFwAVwBJAE4ARABPAFcAUwBcAFQARQBNAFAA
XABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0AG8AcgByAGUAYwB1AHAAZQByAGEAYwBp
APMAbgAgAGQAZQAgAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGEAcwBkAB0ARABpAHIAZQBjAGMA
aQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAEEAQwA6AFwAVwBJ
AE4ARABPAFcAUwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0AG8A
cgByAGUAYwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAu
AGEAcwBkAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4A
ZgBvAHIAbQBhACEAQwA6AFwATQBpAHMAIABkAG8AYwB1AG0AZQBuAHQAbwBzAFwAQwBWAF8AUgBK
AFoAXwBFAE4ARwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEA
cwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAQQBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABc
AEcAdQBhAHIAZABhAGQAbwAgAGMAbwBuACAAQQB1AHQAbwByAHIAZQBjAHUAcABlAHIAYQBjAGkA
8wBuACAAZABlACAAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AYQBzAGQAHQBEAGkAcgBlAGMAYwBp
AG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAIQBDADoAXABNAGkA
cwAgAGQAbwBjAHUAbQBlAG4AdABvAHMAXABDAFYAXwBSAEoAWgBfAEUATgBHADIALgBkAG8AYwAd
AEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwByAG0A
YQAlAEMAOgBcAFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBWAF8AUgBK
AFoAXwBFAE4ARwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEA
cwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAJQBDADoAXABXAEkATgBEAE8AVwBTAFwARQBzAGMAcgBp
AHQAbwByAGkAbwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjADMAfP///55QCqkyAP8P
/w//D/8P/w//D/8P/w8BAH3///+iY4xzMQD/D/8P/w//D/8P/w//D/8PAQB+////jj6QfzAA/w//
D/8P/w//D/8P/w//DwEAf////5hZuIUvAP8P/w//D/8P/w//D/8P/w8BAID///+0vSi+NwD/D/8P
/w//D/8P/w//D/8PAQCB////GNq0GjYA/w//D/8P/w//D/8P/w//DwEAgv///wCUmnw1AP8P/w//
D/8P/w//D/8P/w8BAIP///+SKsaENAD/D/8P/w//D/8P/w//D/8PAQCI////LBiy3i4A/w//D/8P
/w//D/8P/w//DwEAif///xLfShIzAP8P/w//D/8P/w//D/8P/w8BAGouBAQPAAoM/w8AAAAAAAAA
AAAAAAAAAAAAAQAjWUoHAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA7GtQDVS3TMD/DwAAAAAAAAAA
AAAAAAAAAAABANV35w1Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQCNb5EP0Noclf8PAAAAAAAAAAAA
AAAAAAAAAAEAhgLHD1S3TMD/DwAAAAAAAAAAAAAAAAAAAAABANVmQRPuRHST/w8AAAAAAAAAAAAA
AAAAAAAAAQA+K+QUAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA5l4eFQEACgz/DwAAAAAAAAAAAAAA
AAAAAAABAGwnFBoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQCvViYaAQAKDP8PAAAAAAAAAAAAAAAA
AAAAAAEA62mYHgEACgz/DwAAAAAAAAAAAAAAAAAAAAABAG4zJCBUt0zA/w8AAAAAAAAAAAAAAAAA
AAAAAQDISGYiVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEAnCRoKgEACgz/DwAAAAAAAAAAAAAAAAAA
AAABAG9t6ywBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBfHnkuVLdMwP8PAAAAAAAAAAAAAAAAAAAA
AAEArlK4MLj4ijT/DwAAAAAAAAAAAAAAAAAAAAABADN+OzgBAAoM/w8AAAAAAAAAAAAAAAAAAAAA
AQD4GVM4AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA01qyP1S3TMD/DwAAAAAAAAAAAAAAAAAAAAAB
AO9ANUEBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQA0GeREAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA
tVG0RQEACgz/DwAAAAAAAAAAAAAAAAAAAAABADYyiUoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQCz
aUhS6v5Q+f8PAAAAAAAAAAAAAAAAAAAAAAEAAnFGVwEACgz/DwAAAAAAAAAAAAAAAAAAAAABABI8
TFcBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBOK0Jc7kR0k/8PAAAAAAAAAAAAAAAAAAAAAAEAjiDG
XlS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAPwN92EPAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDiRBxk
AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAYHn5ZFS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAMNX/WlU
t0zA/w8AAAAAAAAAAAAAAAAAAAAAAQC9bK1sAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA7xvtbwEA
Cgz/DwAAAAAAAAAAAAAAAAAAAAABAIoCDXABAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDqcyx1AQAK
DP8PAAAAAAAAAAAAAAAAAAAAAAEAchUBeAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAPw03nhUt0zA
/w8AAAAAAAAAAAAAAAAAAAAAAQDCK1V8AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAQAA
AAAAAAAAAAAAAAAAAAAAABAAAA+E1AURhJj+FcYFAAHUBQYCAAAALgABAAAAAAABAAAAAAAAAAAA
AAAAAAAAAAAAEAAAD4S5BBGEmP4VxgUAAbkEBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAAQAAAPhJ4DEYSY/hXGBQABngMGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E
gwIRhJj+FcYFAAGDAgYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TUBRGEmP4V
xgUAAdQFBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhLkEEYSY
/hXGBQABuQQGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EngMR
hJj+FcYFAAGeAwZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4SD
AhGEmP4VxgUAAYMCBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAP
hGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+
FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGE
mP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB
aAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF
AAFoAQZPSgAAUUoAAG8oAAEALQAAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V
xgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY
/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4Ro
ARGEmP4VxgUAAWgBBkNKEABPSgUAUUoFAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
EAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAA
AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA
AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA
AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAA
AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQAAAAAAFwAAAAAAAAAA
AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAA
AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA
AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAA
AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAX
AAAAAAAAAAAAAAAAAAAAAAAAABIQAAAPhGgBEYSY/hXGBQABaAEGQioAQ0ocAE9KAQBRSgEAbygA
AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBv
KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoB
AG8oAAEAt/AAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABR
SgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB
AFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP
SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB
Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB
aAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYF
AAFoAQZDShAAT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro
ARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAP
hGgBEYSY/hXGBQABaAEGQ0oQAE9KBQBRSgUAbygAAQCn8AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAQAAAAAAAQAAAAAAAAAAAAAAAAAA
AAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA
D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ
AAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA
CxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAA
AAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA
AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA
AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAA
AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAA
AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38DMAAADqcyx1
AAAAAAAAAAAAAAAAb23rLAAAAAAAAAAAAAAAACNZSgcAAAAAAAAAAAAAAAACcUZXAAAAAAAAAAAA
AAAAnCRoKgAAAAAAAAAAAAAAAPgZUzgAAAAAAAAAAAAAAAByFQF4AAAAAAAAAAAAAAAA7xvtbwAA
AAAAAAAAAAAAALVRtEUAAAAAAAAAAAAAAADvQDVBAAAAAAAAAAAAAAAANBnkRAAAAAAAAAAAAAAA
AOtpmB4AAAAAAAAAAAAAAACuUrgwAAAAAAAAAAAAAAAAM347OAAAAAAAAAAAAAAAAD4r5BQAAAAA
AAAAAAAAAAA2MolKAAAAAAAAAAAAAAAAwitVfAAAAAAAAAAAAAAAAL1srWwAAAAAAAAAAAAAAACK
Ag1wAAAAAAAAAAAAAAAAai4EBAAAAAAAAAAAAAAAAPwN92EAAAAAAAAAAAAAAADTWrI/AAAAAAAA
AAAAAAAA5l4eFQAAAAAAAAAAAAAAABI8TFcAAAAAAAAAAAAAAABfHnkuAAAAAAAAAAAAAAAAjiDG
XgAAAAAAAAAAAAAAAIYCxw8AAAAAAAAAAAAAAAD8NN54AAAAAAAAAAAAAAAA4kQcZAAAAAAAAAAA
AAAAAE4rQlwAAAAAAAAAAAAAAADVZkETAAAAAAAAAAAAAAAAs2lIUgAAAAAAAAAAAAAAAI1vkQ8A
AAAAAAAAAAAAAABgeflkAAAAAAAAAAAAAAAAbCcUGgAAAAAAAAAAAAAAAG4zJCAAAAAAAAAAAAAA
AADISGYiAAAAAAAAAAAAAAAA1XfnDQAAAAAAAAAAAAAAAMNX/WkAAAAAAAAAAAAAAADsa1ANAAAA
AAAAAAAAAAAAr1YmGgAAAAAAAAAAAAAAAIj///8AAAAAAAAAAAAAAAB/////AAAAAAAAAAAAAAAA
fv///wAAAAAAAAAAAAAAAH3///8AAAAAAAAAAAAAAAB8////AAAAAAAAAAAAAAAAif///wAAAAAA
AAAAAAAAAIP///8AAAAAAAAAAAAAAACC////AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAAAID/
//8AAAAAAAAAAAAAAAD/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////zMAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QAGAAQCQAAAAkAAAAKw2
ygBWAFYAkAAAAAAAAACQAAAAAAAAAAKsAAAAAAAAAI8AAACQAAAAlwAAAJwAAACfAAAAoAAAAKUA
AACpAAAArAAAAFASAABREgAAmxIAAJwSAACdEgAAQAAACABAAABBAJJ9AAAAAEEAIAkAQAAAQQAw
CQBAAABBAJR9AAAAAEEAOgkAQAAAQQCafQAAAABBAEYJAEAAAEEApH0AAAAAQABOCQBAAABAAC4t
AEAAAEAAmCwAQAAAQACqfQAAAABAAC4tAEAAAAYAAABHFpABAAACAgYDBQQFAgMEhzoAAAAAAAAA
AAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQEC
AQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgIC
AgIEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAANSaQAQAAAgsGBAMFBAQCBIc6
AAEAAAAAAAAAAAAAAAD/AAEAAAAAAFQAYQBoAG8AbQBhAAAAPzWQAQAAAgcDCQICBQIEBIc6AAAA
AAAAAAAAAAAAAAD/AAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAA
AAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABAAxCIgYAADF
AgAAqQEAAAAAg3RhJkh1YSaAdGEmAwAAAAAApgIAABoPAAABAAcAAAAEAAMQIAAAAAAAAAAAAAAA
AQABAAAAAQAAAAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAA
EjAAABAAGQBkAAAAGQAAAIsSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAABgAUgBvAGwAYQBuAGQA
bwAgAEoAbwByAGcAZQAgAFoAYQBwAHAAYQBjAG8AcwB0AGEAAAAAAAAAEABtAGkAYwByAG8AaQBu
AGYAbwByAG0AYQB0AGkAYwBhAB0AREkAUAAgAGEAbgBkACAATQBQAEwAUwAgAHMAIAB3AGUAbABs
ACAAYQBzACAAYQBuAGQAIABJAFMARABOACAAZABlAGIAdQBnAGkAbgBnACAAYQBuAGQAIAAsACAA
VgBQAE4AGSBzACwAIABJAFAAIABNAHUAbAB0AGkAYwBhAHMAdAANAE0ARwAZIHMALAAgAE0ARwBD
ABkgcwAgAGEAbgBkACAAQwBhAGwAbAAgAEEAZwBlAG4AdABzACAAbwBwAGUAcgBhAHQAaQBvAG4A
LAAgAEkAUwBEAE4AUwBTADcAIABhAG4AZAAgAEkAUwBEAE4AIABzAGkAZwBuAGEAbABsAGkAbgBn
AA0ADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA01qyPwAAAAAAAAAAAAAAAOZeHhUAAAAAAAAA
AAAAAAASPExXAAAAAAAAAAAAAAAAXx55LgAAAAAAAAAAAAAAAI4gxl4AAAAAAAAAAAAAAACGAscP
AAAAAAAAAAAAAAAA/DTeeAAAAAAAAAAAAAAAAOJEHGQAAAAAAAAAAAAAAABOK0JcAAAAAAAAAAAA
AAAA1WZBEwAAAAAAAAAAAAAAALNpSFIAAAAAAAAAAAAAAACNb5EPAAAAAAAAAAAAAAAAYHn5ZAAA
AAAAAAAAAAAAAGwnFBoAAAAAAAAAAAAAAABuMyQgAAAAAAAAAAAAAAAAyEhmIgAAAAAAAAAAAAAA
ANV35w0AAAAAAAAAAAAAAADDV/1pAAAAAAAAAAAAAAAA7GtQDQAAAAAAAAAAAAAAAK9WJhoAAAAA
AAAAAAAAAACI////AAAAAAAAAAAAAAAAf////wAAAAAAAAAAAAAAAH7///8AAAAAAAAAAAAAAAB9
////AAAAAAAAAAAAAAAAfP///wAAAAAAAAAAAAAAAIn///8AAAAAAAAAAAAAAACD////AAAAAAAA
AAAAAAAAgv///wAAAAAAAAAAAAAAAIH///8AAAAAAAAAAAAAAACA////AAAAAAAAAAAAAAAA////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////8zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/0ADgAEAAAAAAAAAAACsNsoAAQCfAAAAAAAAAAAAAAAA
AAAAAAACVAEAAAAAAACPAAAAkAAAAJcAAACcAAAAnwAAAKAAAAClAAAAqQAAAKwAAABnBAAAaQQA
AGoEAABrBAAAcAQAAH0EAACIBAAAqA0AAL8NAABlEgAAZhIAAHkSAAB+EgAAgRIAAI4SAACQEgAA
tRIAALYSAAC3EgAAQAAACABAAABBAAB+AAAAAEEAIAkAQAAAQQAwCQBAAABBAAJ+AAAAAEEAOgkA
QAAAQQAIfgAAAABBAEYJAEAAAEEAEn4AAAAAQABOCQBAAABBAACAAAAAAEEABIAAAAAAQQAGgAAA
AABBAAiAAAAAAEEAEoAAAAAAQQDEEABAAABAANoQAEAAAEEALIAAAAAAQABKIwBAAABAAC4tAEAA
AEAAmCwAQAAAQQDALABAAABBABh+AAAAAEEAHn4AAAAAQADeLABAAABAAOIsAEAAAEAAWoAAAAAA
QAAuLQBAAAAGAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAFQAaQBt
AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAA
AAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIc6AAAAAAAAAAAAAAAAAAD/
AAAAAAAAAEEAcgBpAGEAbAAAADUmkAEAAAILBgQDBQQEAgSHOgABAAAAAAAAAAAAAAAA/wABAAAA
AABUAGEAaABvAG0AYQAAAD81kAEAAAIHAwkCAgUCBASHOgAAAAAAAAAAAAAAAAAA/wAAAAAAAABD
AG8AdQByAGkAZQByACAATgBlAHcAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAA
AIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAMQiIGAAAxQIAAKkBAAAAAIN0YSYzemFGSXVh
JgUABgAAAKkCAAArDwAAAQAHAAAABAADECAAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQMAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAABIwAAAQABkAZAAAABkAAACgEgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASREAAAAAAAAAAAAAAAAA
AAAAAAAAAAIAAAAAAP//EgAAAAAAAAAYAFIAbwBsAGEAbgBkAG8AIABKAG8AcgBnAGUAIABaAGEA
cABwAGEAYwBvAHMAdABhAAAAAAAAABAAbQBpAGMAcgBvAGkAbgBmAG8AcgBtAGEAdABpAGMAYQAd
AEQAaQByAGUAYwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwByAG0A
YQAAAAAAAAAAAAAAAAAAAAAAAAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAA
ADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAdgAAAP////9AAAAAQQAAAEIAAABDAAAA
RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABS
AAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAA/v//////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////xgAAAAbAAAA/v///3gAAAB5AAAAegAAAHsAAAB8AAAA
fQAAAH4AAAB/AAAAgAAAAAz/DwAAAAAAAAAAAAAAAAAAAAABADYyiUoBAAoM/w8AAAAAAAAAAAAA
AAAAAAAAAQCzaUhS6v5Q+f8PAAAAAAAAAAAAAAAAAAAAAAEAAnFGVwEACgz/DwAAAAAAAAAAAAAA
AAAAAAABABI8TFcBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBOK0Jc7kR0k/8PAAAAAAAAAAAAAAAA
AAAAAAEAjiDGXlS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAPwN92EPAAoM/w8AAAAAAAAAAAAAAAAA
AAAAAQDiRBxkAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAYHn5ZFS3TMD/DwAAAAAAAAAAAAAAAAAA
AAABAMNX/WlUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQC9bK1sAQAKDP8PAAAAAAAAAAAAAAAAAAAA
AAEA7xvtbwEACgz/DwAAAAAAAAAAAAAAAAAAAAABAIoCDXABAAoM/w8AAAAAAAAAAAAAAAAAAAAA
AQDqcyx1AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAchUBeAEACgz/DwAAAAAAAAAAAAAAAAAAAAAB
APw03nhUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDCK1V8AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA
AQAAAAAAAQAAAAAAAAAAAQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA
AAD+////DQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAAP7/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAAAAAAAAEAAAD4TUBRGEmP4VxgUAAdQFBgIAAAAuAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAQAAAPhLkEEYSY/hXGBQABuQQGAgAAAC4AAQAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAABAAAA+EngMRhJj+FcYFAAGeAwYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAA
AAAAEAAAD4SDAhGEmP4VxgUAAYMCBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP
hNQFEYSY/hXGBQAB1AUGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA
AA+EuQQRhJj+FcYFAAG5BAZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
EAAAD4SeAxGEmP4VxgUAAZ4DBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AAsQAAAPhIMCEYSY/hXGBQABgwIGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAA
AAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA
D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQ
AAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro
ARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP
hGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA
AA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
EAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AA8QAAAPhGgBEYSY/hXGBQABaAEGQ0oQAE9KBQBRSgUAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAA
AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA
AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAA
AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA
AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA
AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAA
AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAAAAAAX
AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAQAA
ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB
AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3
8AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oAAFFKAABvKAAB
AC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAEhAAAA+EaAERhJj+FcYFAAFoAQZCKgBDShwAT0oB
AFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP
SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB
Bk9KAQBRSgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB
aAEGT0oAAFFKAABvKAABAC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF
AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V
xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY
/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4Ro
ARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
EAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAA
AAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oFAFFKBQBvKAABAKfwAAAAABcAAAAAAAAAAAAA
AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAAAABAAAAAAAA
AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAA
AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQAAAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAA
AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAA
AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA
AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAA
AAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcA
AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAA
FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEA
AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw
MwAAAOpzLHUAAAAAAAAAAAAAAABvbessAAAAAAAAAAAAAAAAI1lKBwAAAAAAAAAAAAAAAAJxRlcA
AAAAAAAAAAAAAACcJGgqAAAAAAAAAAAAAAAA+BlTOAAAAAAAAAAAAAAAAHIVAXgAAAAAAAAAAAAA
AADvG+1vAAAAAAAAAAAAAAAAtVG0RQAAAAAAAAAAAAAAAO9ANUEAAAAAAAAAAAAAAAA0GeREAAAA
AAAAAAAAAAAA62mYHgAAAAAAAAAAAAAAAK5SuDAAAAAAAAAAAAAAAAAzfjs4AAAAAAAAAAAAAAAA
PivkFAAAAAAAAAAAAAAAADYyiUoAAAAAAAAAAAAAAADCK1V8AAAAAAAAAAAAAAAAvWytbAAAAAAA
AAAAAAAAAIoCDXAAAAAAAAAAAAAAAABqLgQEAAAAAAAAAAAAAAAA/A33YQAAAAAAAAAAAAAAANNa
sj8AAAAAAAAAAAAAAADmXh4VAAAAAAAAAAAAAAAAEjxMVwAAAAAAAAAAAAAAAF8eeS4AAAAAAAAA
AAAAAACOIMZeAAAAAAAAAAAAAAAAhgLHDwAAAAAAAAAAAAAAAPw03ngAAAAAAAAAAAAAAADiRBxk
AAAAAAAAAAAAAAAATitCXAAAAAAAAAAAAAAAANVmQRMAAAAAAAAAAAAAAACzaUhSAAAAAAAAAAAA
AAAAjW+RDwAAAAAAAAAAAAAAAGB5+WQAAAAAAAAAAAAAAABsJxQaAAAAAAAAAAAAAAAAbjMkIAAA
AAAAAAAAAAAAAMhIZiIAAAAAAAAAAAAAAADVd+cNAAAAAAAAAAAAAAAAw1f9aQAAAAAAAAAAAAAA
AOxrUA0AAAAAAAAAAAAAAACvViYaAAAAAAAAAAAAAAAAiP///wAAAAAAAAAAAAAAAH////8AAAAA
AAAAAAAAAAB+////AAAAAAAAAAAAAAAAff///wAAAAAAAAAAAAAAAHz///8AAAAAAAAAAAAAAACJ
////AAAAAAAAAAAAAAAAg////wAAAAAAAAAAAAAAAIL///8AAAAAAAAAAAAAAACB////AAAAAAAA
AAAAAAAAgP///wAAAAAAAAAAAAAAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
MwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP9AAYABAAAA
AAAAAAAArDbKAAEAAQAAAAAAAAAAAAAAAAAAAAAAAQQAbUgJBALIAgAAAAAAAI8AAACQAAAAlwAA
AJwAAACfAAAAoAAAAKUAAACpAAAArAAAABMEAAAfBAAAPgQAAEcEAABIBAAAWQQAAF0EAABfBAAA
YAQAAGEEAABmBAAAbwQAAHQEAAB/BAAAlgQAAJsEAACfBAAAogQAAKsEAADiBAAA4wQAAOUEAADp
BAAA7AQAAO4EAADyBAAA8wQAAP4EAAAIBQAACQUAADIFAAA4BQAARAUAAJAFAACdBQAADQsAABgL
AADMDQAA2Q0AAOINAACIEgAAiRIAAJwSAAChEgAApBIAALESAACzEgAA2BIAANkSAADaEgAAQAAA
CABAAQBBAAB+AAABAEEAIAkAQAEAQQAwCQBAAQBBAAJ+AAABAEEAOgkAQAEAQQAIfgAAAQBBAEYJ
AEABAEEAEn4AAAEAQABOCQBAAQBBAACCAAABAEEAHBAAQAEAQQAYggAAAQBBACqCAAABAEEAiBAA
QAEAQQC8EABAAQBBACyCAAABAEEAMIIAAAEAQQAyggAAAQBBADSCAAABAEEAAIQAAAAAQQBOggAA
AQBBAMQQAEABAEAA2hAAQAEAQQBYggAAAQBBAGKCAAABAEEAaoIAAAEAQQBwggAAAQBAAAgRAEAB
AEAAgoIAAAEAQQCEggAAAQBBAIiCAAABAEEAkIIAAAEAQQCWggAAAQBBAJqCAAABAEEAooIAAAEA
QQCkggAAAQBBALqCAAABAEAAdhEAQAEAQQCCEQBAAQBBAM6CAAABAEAA1BEAQAEAQAAKEgBAAQBB
ABKEAAAAAEAAvhIAQAEAQQAshAAAAABAALIdAEABAEEA2oIAAAEAQQBChAAAAABAAEojAEABAEAA
Li0AQAEAQACYLABAAABBAMAsAEAAAEEAGH4AAAAAQQAefgAAAABAAN4sAEAAAEAA4iwAQAAAQABU
hAAAAABAAC4tAEABAAYAAABHFpABAAACAgYDBQQFAgMEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAA
VABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAA
AAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEhzoAAAAAAAAAAAAA
AAAAAP8AAAAAAAAAQQByAGkAYQBsAAAANSaQAQAAAgsGBAMFBAQCBIc6AAEAAAAAAAAAAAAAAAD/
AAEAAAAAAFQAYQBoAG8AbQBhAAAAPzWQAQAAAgcDCQICBQIEBIc6AAAAAAAAAAAAAAAAAAD/AAAA
AAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAA
AAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABADxCIgYAADFAgAAqQEAAAAAg3RhJkl6
YUZJdWEmBwARAAAArgIAAEgPAAABAAcAAAAEAAMQIAAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAh
AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAcjAAABAAGQBkAAAAGQAA
AMQSEgBXAAoAAQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAQA
bUgKDDIAAUABAAIAMgAAAAgAVADtAHQAdQBsAG8AIAAxAAAACAABAAYkAUAmAAcANQiBbUgJBABE
AAJAAQACAEQAAAAIAFQA7QB0AHUAbABvACAAMgAAABAAAgAGJAETpPAAFKQ8AEAmARIANQiBNgiB
Q0oYAE9KAgBRSgIAPgADQAEAAgA+AAAACABUAO0AdAB1AGwAbwAgADMAAAAQAAMABiQBE6TwABSk
PABAJgIMAENKGABPSgIAUUoCAEIABEABAAIAQgAAAAgAVADtAHQAdQBsAG8AIAA0AAAAEAAEAAYk
AROk8AAUpDwAQCYDDwA1CIFDShgAT0oCAFFKAgAANAAFQAEAAgA0AAAACABUAO0AdAB1AGwAbwAg
ADUAAAANAAUAE6TwABSkPABAJgQABABDShYAOAAGQAEAAgA4AAAACABUAO0AdAB1AGwAbwAgADYA
AAANAAYAE6TwABSkPABAJgUABwA2CIFDShYAADgAB0ABAAIAOAAAAAgAVADtAHQAdQBsAG8AIAA3
AAAADQAHABOk8AAUpDwAQCYGAAgAT0oCAFFKAgA8AAhAAQACADwAAAAIAFQA7QB0AHUAbABvACAA
OAAAAA0ACAATpPAAFKQ8AEAmBwALADYIgU9KAgBRSgIAAEIACUABAAIAQgAAAAgAVADtAHQAdQBs
AG8AIAA5AAAADQAJABOk8AAUpDwAQCYIABIANQiBNgiBQ0oSAE9KAgBRSgIARgBBQPL/oQBGAAAA
GwBGAHUAZQBuAHQAZQAgAGQAZQAgAHAA4QByAHIAYQBmAG8AIABwAHIAZQBkAGUAdABlAHIALgAA
AAAAAAAAAAAAAAAuAFVAogDxAC4AAAAMAEgAaQBwAGUAcgB2AO0AbgBjAHUAbABvAAAABgA+KgFC
KgI+AD5AAQACAT4AAAAGAFQA7QB0AHUAbABvAAAAFAAQAAMkAQ+EHAFAJgANxgUAATMHgAsANQiB
Q0ooAG1ICQQANAAfQAEAEgE0AAAACgBFAG4AYwBhAGIAZQB6AGEAZABvAAAADQARAA3GCAACQxGG
IgECAAAAOgAgQAEAIgE6AAAADQBQAGkAZQAgAGQAZQAgAHAA4QBnAGkAbgBhAAAADQASAA3GCAAC
QxGGIgECAAAAJAA/QAEAMgEkAAAABgBDAGkAZQByAHIAZQAAAAYAEwAPhJwQAAA6AERAAQBCAToA
AAAPAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhAAAACgAUAA+EGwEUpHgAAAA+AEVAAQBS
AT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhACAAMgAAAAoAFQAPhDYCFKR4AAAA
PgBGQAEAYgE+AAAAEQBDAG8AbgB0AGkAbgB1AGEAcgAgAGwAaQBzAHQAYQAgADMAAAAKABYAD4RR
AxSkeAAAAD4AR0ABAHIBPgAAABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEAIAA0AAAA
CgAXAA+EbAQUpHgAAAA+AEhAAQCCAT4AAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABh
ACAANQAAAAoAGAAPhIcFFKR4AAAAWgAkQAEAkgFaAAAADwBEAGkAcgBlAGMAYwBpAPMAbgAgAHMA
bwBiAHIAZQAAAB0AGQAbJoAPhEALGIT8/xmE9P8ahPAeL4SNACtEvAcADABDShgAT0oCAFFKAgBO
AC5AAQACAE4AAAATAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABsAGkAcwB0AGEAAAAGABoA
E6R4AA8ANQiBQ0oYAE9KAgBRSgIAAG4ASUABALIBbgAAABUARQBuAGMAYQBiAGUAegBhAGQAbwAg
AGQAZQAgAG0AZQBuAHMAYQBqAGUAAAAmABsAD4RuBBGEkvskZAYBAAElZAYBAAEmZAYBAAEnZAYB
AAEtRAAQDABDShgAT0oCAFFKAgA4AE9AAQACADgAAAASAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABk
AGUAIABuAG8AdABhAAAAAgAcAAAAMAAiQAEAAgAwAAAACABFAHAA7QBnAHIAYQBmAGUAAAAKAB0A
E6R4ABSkeAADADUIgQAeAExAAQACAB4AAAAFAEYAZQBjAGgAYQAAAAIAHgAAACIAQEABAPIBIgAA
AAUARgBpAHIAbQBhAAAABgAfAA+EnBAAACwACkABAAIALAABAAgAzQBuAGQAaQBjAGUAIAAxAAAA
CgAgAA+EyAARhDj/AAAsAAtAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAMgAAAAoAIQAPhJABEYQ4
/wAALAAMQAEAAgAsAAEACADNAG4AZABpAGMAZQAgADMAAAAKACIAD4RYAhGEOP8AACwADUABAAIA
LAABAAgAzQBuAGQAaQBjAGUAIAA0AAAACgAjAA+EIAMRhDj/AAAsAA5AAQACACwAAQAIAM0AbgBk
AGkAYwBlACAANQAAAAoAJAAPhOgDEYQ4/wAALAAPQAEAAgAsAAEACADNAG4AZABpAGMAZQAgADYA
AAAKACUAD4SwBBGEOP8AACwAEEABAAIALAABAAgAzQBuAGQAaQBjAGUAIAA3AAAACgAmAA+EeAUR
hDj/AAAsABFAAQACACwAAQAIAM0AbgBkAGkAYwBlACAAOAAAAAoAJwAPhEAGEYQ4/wAALAASQAEA
AgAsAAEACADNAG4AZABpAGMAZQAgADkAAAAKACgAD4QIBxGEOP8AACYAL0ABAJICJgAAAAUATABp
AHMAdABhAAAACgApAA+EGwERhOX+AAAqADJAAQCiAioAAAAHAEwAaQBzAHQAYQAgADIAAAAKACoA
D4Q2AhGE5f4AACoAM0ABALICKgAAAAcATABpAHMAdABhACAAMwAAAAoAKwAPhFEDEYTl/gAAKgA0
QAEAwgIqAAAABwBMAGkAcwB0AGEAIAA0AAAACgAsAA+EbAQRhOX+AAAqADVAAQDSAioAAAAHAEwA
aQBzAHQAYQAgADUAAAAKAC0AD4SHBRGE5f4AAD4AMUABAOICPgAAABEATABpAHMAdABhACAAYwBv
AG4AIABuAPoAbQBlAHIAbwBzAAAACQAuAAomAAtGKgAAAABCADpAAQDyAkIAAAATAEwAaQBzAHQA
YQAgAGMAbwBuACAAbgD6AG0AZQByAG8AcwAgADIAAAAJAC8ACiYAC0YrAAAAAEIAO0ABAAIDQgAA
ABMATABpAHMAdABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzACAAMwAAAAkAMAAKJgALRiwAAAAA
QgA8QAEAEgNCAAAAEwBMAGkAcwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAA0AAAACQAx
AAomAAtGLQAAAABCAD1AAQAiA0IAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6AG0AZQByAG8A
cwAgADUAAAAJADIACiYAC0YuAAAAAD4AMEABADIDPgABABEATABpAHMAdABhACAAYwBvAG4AIAB2
AGkA8QBlAHQAYQBzAAAACQAzAAomAAtGLwAAAABCADZAAQBCA0IAAQATAEwAaQBzAHQAYQAgAGMA
bwBuACAAdgBpAPEAZQB0AGEAcwAgADIAAAAJADQACiYAC0YwAAAAAEIAN0ABAFIDQgABABMATABp
AHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAAMwAAAAkANQAKJgALRjEAAAAAQgA4QAEA
YgNCAAEAEwBMAGkAcwB0AGEAIABjAG8AbgAgAHYAaQDxAGUAdABhAHMAIAA0AAAACQA2AAomAAtG
MgAAAABCADlAAQByA0IAAQATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBpAPEAZQB0AGEAcwAgADUA
AAAJADcACiYAC0YzAAAAAEQAWUABAIIDRAAAABIATQBhAHAAYQAgAGQAZQBsACAAZABvAGMAdQBt
AGUAbgB0AG8AAAAGADgALUQgAQgAT0oDAFFKAwA6ACVAAQCSAzoAAAAPAFIAZQBtAGkAdABlACAA
ZABlACAAcwBvAGIAcgBlAAAAAgA5AAgAT0oCAFFKAgAgAEtAAQACACAAAAAGAFMAYQBsAHUAZABv
AAAAAgA6AAAAXABSQAEAsgNcAAAAHQBTAGEAbgBnAHIA7QBhACAAMgAgAGQAZQAgAHQALgAgAGkA
bgBkAGUAcABlAG4AZABpAGUAbgB0AGUAAAAQADsAD4QbARJk4AEBABSkeAAAAFoAU0ABAMIDWgAA
AB0AUwBhAG4AZwByAO0AYQAgADMAIABkAGUAIAB0AC4AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4A
dABlAAAACgA8AA+EGwEUpHgABABDShAAUgBDQAEA0gNSAAAAGwBTAGEAbgBnAHIA7QBhACAAZABl
ACAAdAAuACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAAAAoAPQAPhBsBFKR4AAAANAAcQAEA
4gM0AAAADgBTAGEAbgBnAHIA7QBhACAAbgBvAHIAbQBhAGwAAAAGAD4AD4TEAgAAPABKQAEA8gM8
AAAACQBTAHUAYgB0AO0AdAB1AGwAbwAAAAwAPwADJAEUpDwAQCYBDABDShgAT0oCAFFKAgBIACNA
AQACAEgAAAAWAFQAYQBiAGwAYQAgAGQAZQAgAGkAbAB1AHMAdAByAGEAYwBpAG8AbgBlAHMAAAAK
AEAAD4SQARGEcP4AAB4AE0ABAAIAHgABAAUAVABEAEMAIAAxAAAAAgBBAAAAIgAUQAEAAgAiAAEA
BQBUAEQAQwAgADIAAAAGAEIAD4TIAAAAIgAVQAEAAgAiAAEABQBUAEQAQwAgADMAAAAGAEMAD4SQ
AQAAIgAWQAEAAgAiAAEABQBUAEQAQwAgADQAAAAGAEQAD4RYAgAAIgAXQAEAAgAiAAEABQBUAEQA
QwAgADUAAAAGAEUAD4QgAwAAIgAYQAEAAgAiAAEABQBUAEQAQwAgADYAAAAGAEYAD4ToAwAAIgAZ
QAEAAgAiAAEABQBUAEQAQwAgADcAAAAGAEcAD4SwBAAAIgAaQAEAAgAiAAEABQBUAEQAQwAgADgA
AAAGAEgAD4R4BQAAIgAbQAEAAgAiAAEABQBUAEQAQwAgADkAAAAGAEkAD4RABgAANAAeQAEAogQ0
AAAAEABUAGUAeAB0AG8AIABjAG8AbQBlAG4AdABhAHIAaQBvAAAAAgBKAAAAPgAsQAEAAgA+AAAA
EQBUAGUAeAB0AG8AIABjAG8AbgAgAHMAYQBuAGcAcgDtAGEAAAAKAEsAD4TIABGEOP8AAD4AVEAB
AMIEPgAAAA8AVABlAHgAdABvACAAZABlACAAYgBsAG8AcQB1AGUAAAAOAEwADoSgBQ+EoAUUpHgA
AAA+AEJAAQDSBD4AAAATAFQAZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAAAAG
AE0AFKR4AAAASABQQAEA4gRIAAAAFQBUAGUAeAB0AG8AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4A
dABlACAAMgAAAAwATgASZOABAQAUpHgAAABGAFFAAQDyBEYAAAAVAFQAZQB4AHQAbwAgAGkAbgBk
AGUAcABlAG4AZABpAGUAbgB0AGUAIAAzAAAABgBPABSkeAAEAENKEABeAE1A0QQCBV4AAAAjAFQA
ZQB4AHQAbwAgAGkAbgBkAGUAcABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAAcwBh
AG4AZwByAO0AYQAAAAYAUAARhNIAAABiAE5A0QMSBWIAAAAlAFQAZQB4AHQAbwAgAGkAbgBkAGUA
cABlAG4AZABpAGUAbgB0AGUAIABwAHIAaQBtAGUAcgBhACAAcwBhAG4AZwByAO0AYQAgADIAAAAG
AFEAEYTSAAAAVgAtQPH/IgVWAAAACwBUAGUAeAB0AG8AIABtAGEAYwByAG8AAAAiAFIAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIEgAAAAAAAAAAAAAAAAAAAAAA
AAAAAgAAAAAA//8SAAAAAAAAABgAUgBvAGwAYQBuAGQAbwAgAEoAbwByAGcAZQAgAFoAYQBwAHAA
YQBjAG8AcwB0AGEAAAAAAAAAEABtAGkAYwByAG8AaQBuAGYAbwByAG0AYQB0AGkAYwBhAB0ARABp
AHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAALB6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////////////
//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspcEASQAK
DAAAVBC/AAAAAAAAEAAAAAAABAAAmBYAAA4AYmpiarKzsrMAAAAAAAAAAAAAAAAAAAAAAAAKDBYA
AIYAANDZAQDQ2QEAiRIAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD/
/w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAAAAAACwegAAHhMAAM6NAAAAAAAA
zo0AAAAAAADOjQAAAAAAAM6NAAAAAAAAzo0AABQAAAAAAAAAAAAAAOKNAAAAAAAA3pcAAAAAAADe
lwAAAAAAAN6XAAA4AAAAFpgAABQAAAAqmAAARAAAAOKNAAAAAAAA7LgAAGgBAACamAAAAAAAAJqY
AAAAAAAAmpgAAAAAAACamAAAAAAAAJqYAAAAAAAAbZoAAAAAAABtmgAAAAAAAG2aAAAAAAAA8rUA
AAIAAAD0tQAAAAAAAPS1AAAAAAAA9LUAAAAAAAD0tQAAAAAAAPS1AAAAAAAA9LUAACQAAABUugAA
9AEAAEi8AAC0AAAAGLYAANQCAAAAAAAAAAAAAAAAAAAAAAAAzo0AAAAAAABtmgAAAAAAAAAAAAAA
AAAAAAAAAAAAAABLmgAAIgAAAG2aAAAAAAAAbZoAAAAAAABtmgAAAAAAABi2AAAAAAAApZoAAAAA
AADOjQAAAAAAAM6NAAAAAAAAmpgAAAAAAAAAAAAAAAAAAJqYAACxAQAAmpgAAAAAAAClmgAAAAAA
AKWaAAAAAAAApZoAAAAAAABtmgAAIgAAAM6NAAAAAAAAmpgAAAAAAADOjQAAAAAAAJqYAAAAAAAA
8rUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4o0AAAAAAADijQAAAAAAAM6NAAAAAAAAzo0AAAAAAADO
jQAAAAAAAM6NAAAAAAAAbZoAAAAAAADytQAAAAAAAKWaAAC2BQAApZoAAAAAAABboAAAlgUAAIax
AAAABAAAzo0AAAAAAADOjQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAA8rUAAAAAAACamAAAAAAAAG6YAAAsAAAAQK5QcL2dwQHijQAA
/AkAAN6XAAAAAAAAj5oAABYAAACGtQAAbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgBvAG8AdAAg
AEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA
BQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAMAb//M+ncEBQK5QcL2dwQHZAAAAAAUA
AAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAADgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAKcAAAAXQgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAACGAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A
cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAA6AEAAAAAAACBAAAAggAAAIMA
AACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAA
AJIAAACTAAAAQwAAAP////+WAAAAlwAAAJgAAABfAAAA/////5wAAAD+////nQAAAJ4AAACfAAAA
oAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAALAAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACu
AAAArwAAALUAAAD+////sgAAAAIAAADXAAAA/f///7YAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwA
AAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAA
AMsAAADMAAAAzQAAAP7////////////////////////////////////////////////////+////
/f///9oAAADbAAAA/v//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////w3GHQAJ4AHAA6AF
gAdgCUALIA0AD+AQAAAAAAAAAAAADABPSgQAUUoEAG1ICgw6ACtAAQAyBToAAAATAFQAZQB4AHQA
bwAgAG4AbwB0AGEAIABhAGwAIABmAGkAbgBhAGwAAAACAFMAAAAwAB1AAQBCBTAAAAAOAFQAZQB4
AHQAbwAgAG4AbwB0AGEAIABwAGkAZQAAAAIAVAAAAD4AWkABAFIFPgAAABEAVABlAHgAdABvACAA
cwBpAG4AIABmAG8AcgBtAGEAdABvAAAAAgBVAAgAT0oEAFFKBABAACFAAQACAkAAAAAQAFQA7QB0
AHUAbABvACAAZABlACAA7QBuAGQAaQBjAGUAAAACAFYACwA1CIFPSgIAUUoCAAAAAAAA2hIAAAQA
ADYAAAAA/////wAAAACPAAAArQAAAK8AAAC5AAAAIQIAACwCAADKAgAA1gIAANcCAACABAAAkQQA
AKsEAAC1BAAA4gQAAAgFAABDBQAAbAUAANwFAAAkCAAANQgAADgIAAA8CAAAXAgAAMIIAAD3CAAA
EQkAADsKAABMCgAAagoAAJ0KAAAECwAAPgsAAD8LAABACwAAQQsAAEwLAABNCwAAowsAAKsLAADl
CwAACwwAAEIMAACBDAAAggwAAIMMAACEDAAAjQwAAI4MAADPDAAAHw0AAIgNAADLDQAAFg4AAFkO
AADnDgAAPw8AAKkPAABDEAAAuhAAALsQAAC8EAAAvRAAAM4QAADPEAAA1BAAAPAQAAABEQAAThEA
AGwRAABtEQAAbhEAAHkRAAB6EQAArhEAAPsRAABeEgAAXxIAAGASAABhEgAAbRIAAG4SAACGEgAA
hxIAAIgSAACJEgAAnBIAALISAADYEgAA2xIAAJ4AAAAAAAAAAAAAAACAAAAAgAgAAAAAAAAAAAAA
AACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgKkAAAABAAAAAAAAAACArQAAAJ4AAAAAAAAAAAAAAACA
AAAAgKkAAAABAAAAAAAAAACArQAAAJ4AAAAAAAAAAAAAAACAAAAAgKkAAAABAAAAAAAAAACArQAA
AJ4AAAAAAAAAAAAAAACAAAAAgKkAByAAAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkA
GiAAAAAAAAAAAACArQAAAKkAGiAAAAEAAAAAAACArQAAAKkAGiAAAAIAAAAAAACArQAAAKkAGiAA
AAMAAAAAAACArQAAAKkAGiAAAAQAAAAAAACArQAAAKkAGiAAAAUAAAAAAACArQAAAKkAGiAAAAYA
AAAAAACArQAAAKkAHSAAAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkAHCAAAAAAAAAA
AACArQAAAKkAHCAAAAEAAAAAAACArQAAAKkAHCAAAAIAAAAAAACArQAAAKkAHCAAAAMAAAAAAACA
rQAAAKkAHCAAAAQAAAAAAACArQAAAKkAHCAAAAUAAAAAAACArQAAAKkAEyAAAAAAAAAAAACArQAA
AKkAAAAAAAAAAAAAAACArQAAAKkAFiAAAAAAAAAAAACArQAAAKkAFiAAAAEAAAAAAACArQAAAKkA
FiAAAAIAAAAAAACArQAAAKkAFiAAAAMAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAJkAAAAA
AAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkAAAABAAAAAAAAAACArQAAAKkAAAAAAAAA
AAAAAACArQAAAKkACiAAAAEAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkAGyAAAAAAAAAA
AACArQAAAKkAGyAAAAEAAAAAAACArQAAAKkAGyAAAAIAAAAAAACArQAAAKkAGyAAAAMAAAAAAACA
rQAAAKkAAAAAAAAAAAAAAACArQAAAJkAAAAAAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAA
AKkAAAABAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkADCAAAAAAAAAAAACArQAAAKkA
DCAAAAEAAAAAAACArQAAAKkADCAAAAIAAAAAAACArQAAAKkADCAAAAMAAAAAAACArQAAAKkADCAA
AAQAAAAAAACArQAAAKkADCAAAAUAAAAAAACArQAAAKkADCAAAAYAAAAAAACArQAAAKkADCAAAAcA
AAAAAACArQAAAKkADCAAAAgAAAAAAACArQAAAKkADCAAAAkAAAAAAACArQAAAKkADCAAAAoAAAAA
AACArQAAAKkAAAAAAAAAAAAAAACArQAAAJkAAAAAAAAAAAAAAACArQAAAKlAAAAAAAAAAAAAAACA
rQAAAKkAAAABAAAAAAAAAACArQAAAKlAAAAAAAAAAAAAAACArQAAAKkADiAAAAAAAAAAAACArQAA
AKkADiAAAAEAAAAAAACArQAAAKkADiAAAAIAAAAAAACArQAAAKkADiAAAAMAAAAAAACArQAAAKkA
DiAAAAQAAAAAAACArQAAAJkAAAAAAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkAAAAB
AAAAAAAAAACArQAAAKkAAAARAAAAAAAAAACArQAAAKkAByAAAAEAAAAAAACArQAAAKkAByAAAAIA
AAAAAACArQAAAKkAByAAAAMAAAAAAACArQAAAKkAAAARAAAAAAAAAACArQAAAJkAAAAAAAAAAAAA
AACArQAAAKkAAAAAAAAAAAAAAACArQAAAKkAAAABAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACA
rQAAAKkAKSAAAAAAAAAAAACArQAAAKkAAAAAAAAAAAAAAACArQAAAJkAAAAAAAAAAAAAAACArQAA
AAgAAAAAAAAAAAAAAACAAAAAgJpAAAASAAAAAAAAAACAAAAAgJhAAAASAAAAAAAAAACAAAAAgJpA
AAAAAAAAAAAAAACAAAAAgAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAqAAAAKgAAAE8AAABSAAAAAAQAABAVAAAMgwAADAAAABcAAAAABAAA
iQUAAMMGAAD6CwAAbQ8AAH4UAAA9FQAAlhYAAAyDAAANAAAADwAAABEAAAASAAAAFAAAABYAAAAY
AAAAGgAAAAAEAADCBgAADg4AABwSAAAwFgAAmBYAAA4AAAAQAAAAEwAAABUAAAAZAAAADwAA8GwA
AAAAAAbwGAAAAAIIAAACAAAAAgAAAAEAAAABAAAAAwAAAB8AAfAsAAAAYgAH8CQAAAAGBm3pYMIr
dN2UpQUu3xx4Own/AGxHAAABAAAAJjYAAAAAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC
8DQBAAAQAAjwCAAAAAIAAAACBAAADwAD8NIAAAAPAATwKAAAAAEACfAQAAAAAAANAAAADAAAAAsA
AAAAAAIACvAIAAAAAAQAAAUAAAAPAATwmgAAALIECvAIAAAAAgQAAAAKAABjAAvwagAAAARBAQAA
AAXBGAAAAAYBAgAAAP8BAAAIAIPDLgAAAL8DIABgAEEAOgBcAGYAbwB0AG8ALgBwAGMAeAAAAAUA
CAAIACH///8AAAAAIf///6NTAABgVAAAo1MAAGBUAAAAAAAAIf///wAAAAAAABDwBAAAAAAAAAAA
ABHwBAAAAAYAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8B
AAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAABoAAADaEgAAAgQAACYXAABiAAAA1RwAABAHAAC0
QgAAAAAAAAAABwAAAA4AAAAYAAAAHwAAACQAAAApAAAALgAAADIAAAA4AAAAlwAAAKwAAABjAwAA
cAMAABMEAAAfBAAAPgQAAEgEAABZBAAAWQQAAF8EAABhBAAAZgQAAHMEAAB+BAAAfgQAAJUEAACq
BAAA4QQAAAcFAAAIBQAACAUAADEFAAA3BQAAQwUAAEMFAACeBQAApQUAALUFAAC8BQAAwwUAAMcF
AADcBQAA5gUAAMoHAADSBwAA0wcAANkHAAD2CAAA9wgAAP4IAAD/CAAABwkAAAgJAAAPCQAAEQkA
ABcJAAAYCQAAJgwAACcMAAArDAAALAwAAMsNAADiDQAAuxAAAL0QAADFEAAAxhAAAMwQAADNEAAA
ahEAAG4RAAB3EQAAehEAAIgSAADbEgAAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAE
AAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwADAAQAAwAHAAMABwADAAcAAwAHAAMABwAD
AAcAAAAAAM8DAAATBAAAHwQAAD4EAABIBAAAWQQAAFkEAABfBAAAYQQAAGYEAABzBAAAfgQAAH4E
AACVBAAAqgQAAOEEAAAHBQAACAUAAAgFAAAxBQAANwUAAEMFAABDBQAAjwUAAMsNAADiDQAA2xIA
AAMABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAMABAADAP//
FAAAAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBv
AHIAbQBhAEEAQwA6AFwAVwBJAE4ARABPAFcAUwBcAFQARQBNAFAAXABHAHUAYQByAGQAYQBkAG8A
IABjAG8AbgAgAEEAdQB0AG8AcgByAGUAYwB1AHAAZQByAGEAYwBpAPMAbgAgAGQAZQAgAEMAVgBf
AFIASgBaAF8ARQBOAEcAMgAuAGEAcwBkAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUA
bQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAEEAQwA6AFwAVwBJAE4ARABPAFcAUwBcAFQARQBN
AFAAXABHAHUAYQByAGQAYQBkAG8AIABjAG8AbgAgAEEAdQB0AG8AcgByAGUAYwB1AHAAZQByAGEA
YwBpAPMAbgAgAGQAZQAgAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGEAcwBkAB0ARABpAHIAZQBj
AGMAaQBvAG4AIABTAGkAcwB0AGUAbQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhACEAQwA6AFwA
TQBpAHMAIABkAG8AYwB1AG0AZQBuAHQAbwBzAFwAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AZABv
AGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8A
cgBtAGEAQQBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEcAdQBhAHIAZABhAGQAbwAg
AGMAbwBuACAAQQB1AHQAbwByAHIAZQBjAHUAcABlAHIAYQBjAGkA8wBuACAAZABlACAAQwBWAF8A
UgBKAFoAXwBFAE4ARwAyAC4AYQBzAGQAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBt
AGEAcwAgAGQAZQAgAEkAbgBmAG8AcgBtAGEAIQBDADoAXABNAGkAcwAgAGQAbwBjAHUAbQBlAG4A
dABvAHMAXABDAFYAXwBSAEoAWgBfAEUATgBHADIALgBkAG8AYwAdAEQAaQByAGUAYwBjAGkAbwBu
ACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwByAG0AYQAlAEMAOgBcAFcASQBOAEQA
TwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBWAF8AUgBKAFoAXwBFAE4ARwAyAC4AZABv
AGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAgAEkAbgBmAG8A
cgBtAGEAJQBDADoAXABXAEkATgBEAE8AVwBTAFwARQBzAGMAcgBpAHQAbwByAGkAbwBcAEMAVgBf
AFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUA
bQBhAHMAIABkAGUAIABJAG4AZgBvAHIAbQBhACUAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEUAcwBj
AHIAaQB0AG8AcgBpAG8AXABDAFYAXwBSAEoAWgBfAEUATgBHADIALgBkAG8AYwAdAEQAaQByAGUA
YwBjAGkAbwBuACAAUwBpAHMAdABlAG0AYQBzACAAZABlACAASQBuAGYAbwByAG0AYQAlAEMAOgBc
AFcASQBOAEQATwBXAFMAXABFAHMAYwByAGkAdABvAHIAaQBvAFwAQwBWAF8AUgBKAFoAXwBFAE4A
RwAyAC4AZABvAGMAHQBEAGkAcgBlAGMAYwBpAG8AbgAgAFMAaQBzAHQAZQBtAGEAcwAgAGQAZQAg
AEkAbgBmAG8AcgBtAGEAJQBDADoAXABXAEkATgBEAE8AVwBTAFwARQBzAGMAcgBpAHQAbwByAGkA
bwBcAEMAVgBfAFIASgBaAF8ARQBOAEcAMgAuAGQAbwBjADMAfP///55QCqkyAP8P/w//D/8P/w//
D/8P/w8BAH3///+iY4xzMQD/D/8P/w//D/8P/w//D/8PAQB+////jj6QfzAA/w//D/8P/w//D/8P
/w//DwEAf////5hZuIUvAP8P/w//D/8P/w//D/8P/w8BAID///+0vSi+NwD/D/8P/w//D/8P/w//
D/8PAQCB////GNq0GjYA/w//D/8P/w//D/8P/w//DwEAgv///wCUmnw1AP8P/w//D/8P/w//D/8P
/w8BAIP///+SKsaENAD/D/8P/w//D/8P/w//D/8PAQCI////LBiy3i4A/w//D/8P/w//D/8P/w//
DwEAif///xLfShIzAP8P/w//D/8P/w//D/8P/w8BAGouBAQPAAoM/w8AAAAAAAAAAAAAAAAAAAAA
AQAjWUoHAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA7GtQDVS3TMD/DwAAAAAAAAAAAAAAAAAAAAAB
ANV35w1Ut0zA/w8AAAAAAAAAAAAAAAAAAAAAAQCNb5EP0Noclf8PAAAAAAAAAAAAAAAAAAAAAAEA
hgLHD1S3TMD/DwAAAAAAAAAAAAAAAAAAAAABANVmQRPuRHST/w8AAAAAAAAAAAAAAAAAAAAAAQA+
K+QUAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA5l4eFQEACgz/DwAAAAAAAAAAAAAAAAAAAAABAGwn
FBoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQCvViYaAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA62mY
HgEACgz/DwAAAAAAAAAAAAAAAAAAAAABAG4zJCBUt0zA/w8AAAAAAAAAAAAAAAAAAAAAAQDISGYi
VLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEAnCRoKgEACgz/DwAAAAAAAAAAAAAAAAAAAAABAG9t6ywB
AAoM/w8AAAAAAAAAAAAAAAAAAAAAAQBfHnkuVLdMwP8PAAAAAAAAAAAAAAAAAAAAAAEArlK4MLj4
ijT/DwAAAAAAAAAAAAAAAAAAAAABADN+OzgBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQD4GVM4AQAK
DP8PAAAAAAAAAAAAAAAAAAAAAAEA01qyP1S3TMD/DwAAAAAAAAAAAAAAAAAAAAABAO9ANUEBAAoM
/w8AAAAAAAAAAAAAAAAAAAAAAQA0GeREAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAtVG0RQEACgz/
DwAAAAAAAAAAAAAAAAAAAAABADYyiUoBAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQCzaUhS6v5Q+f8P
AAAAAAAAAAAAAAAAAAAAAAEAAnFGVwEACgz/DwAAAAAAAAAAAAAAAAAAAAABABI8TFcBAAoM/w8A
AAAAAAAAAAAAAAAAAAAAAQBOK0Jc7kR0k/8PAAAAAAAAAAAAAAAAAAAAAAEAjiDGXlS3TMD/DwAA
AAAAAAAAAAAAAAAAAAABAPwN92EPAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDiRBxkAQAKDP8PAAAA
AAAAAAAAAAAAAAAAAAEAYHn5ZFS3TMD/DwAAAAAAAAAAAAAAAAAAAAABAMNX/WlUt0zA/w8AAAAA
AAAAAAAAAAAAAAAAAQC9bK1sAQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEA7xvtbwEACgz/DwAAAAAA
AAAAAAAAAAAAAAABAIoCDXABAAoM/w8AAAAAAAAAAAAAAAAAAAAAAQDqcyx1AQAKDP8PAAAAAAAA
AAAAAAAAAAAAAAEAchUBeAEACgz/DwAAAAAAAAAAAAAAAAAAAAABAPw03nhUt0zA/w8AAAAAAAAA
AAAAAAAAAAAAAQDCK1V8AQAKDP8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAQAAAAAAAAAAAAAA
AAAAAAAAABAAAA+E1AURhJj+FcYFAAHUBQYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA
EAAAD4S5BBGEmP4VxgUAAbkEBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhJ4D
EYSY/hXGBQABngMGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EgwIRhJj+FcYF
AAGDAgYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TUBRGEmP4VxgUAAdQFBk9K
AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhLkEEYSY/hXGBQABuQQG
T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EngMRhJj+FcYFAAGe
AwZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4SDAhGEmP4VxgUA
AYMCBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXG
BQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP
SgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgB
BgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK
AQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAA
UUoAAG8oAAEALQAAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9K
AABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG
T0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo
AQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUA
AWgBBkNKEABPSgUAUUoFAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE
mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB
EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E
aAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA
D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ
AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAA
CxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQAAAAAAFwAAAAAAAAAAAAAAAAAAAAAA
AAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA
AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAFwAAAAAAAAAAAAAA
AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAtAAEAAAAXAAAAAAAAAAAA
AAAAAAAAAAAAABIQAAAPhGgBEYSY/hXGBQABaAEGQioAQ0ocAE9KAQBRSgEAbygAAQC38AEAAAAX
AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA
ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AA
AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAABRSgAAbygAAQAt
AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB
ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o
AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEA
bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK
AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAA
T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo
AQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA
AWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhGgBEYSY/hXG
BQABaAEGQ0oQAE9KBQBRSgUAbygAAQCn8AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB
EYSY/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E
aAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V
xgUAAWgBBk9KAQBRSgEAbygAAQC38AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY
/hXGBQABaAEGT0oAAFFKAABvKAABAC0AAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER
hJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro
ARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP
hGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA
AA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
EAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA
AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAAAAABcAAAAAAAAAAAAAAAAAAAAA
AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgAAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAAAAAAAAAA
AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38DMAAADqcyx1AAAAAAAAAAAA
AAAAb23rLAAAAAAAAAAAAAAAACNZSgcAAAAAAAAAAAAAAAACcUZXAAAAAAAAAAAAAAAAnCRoKgAA
AAAAAAAAAAAAAPgZUzgAAAAAAAAAAAAAAAByFQF4AAAAAAAAAAAAAAAA7xvtbwAAAAAAAAAAAAAA
ALVRtEUAAAAAAAAAAAAAAADvQDVBAAAAAAAAAAAAAAAANBnkRAAAAAAAAAAAAAAAAOtpmB4AAAAA
AAAAAAAAAACuUrgwAAAAAAAAAAAAAAAAM347OAAAAAAAAAAAAAAAAD4r5BQAAAAAAAAAAAAAAAA2
MolKAAAAAAAAAAAAAAAAwitVfAAAAAAAAAAAAAAAAL1srWwAAAAAAAAAAAAAAACKAg1wAAAAAAAA
AAAAAAAAai4EBAAAAAAAAAAAAAAAAPwN92EAAAAAAAAAAAAAAADTWrI/AAAAAAAAAAAAAAAA5l4e
FQAAAAAAAAAAAAAAABI8TFcAAAAAAAAAAAAAAABfHnkuAAAAAAAAAAAAAAAAjiDGXgAAAAAAAAAA
AAAAAIYCxw8AAAAAAAAAAAAAAAD8NN54AAAAAAAAAAAAAAAA4kQcZAAAAAAAAAAAAAAAAE4rQlwA
AAAAAAAAAAAAAADVZkETAAAAAAAAAAAAAAAAs2lIUgAAAAAAAAAAAAAAAI1vkQ8AAAAAAAAAAAAA
AABgeflkAAAAAAAAAAAAAAAAbCcUGgAAAAAAAAAAAAAAAG4zJCAAAAAAAAAAAAAAAADISGYiAAAA
AAAAAAAAAAAA1XfnDQAAAAAAAAAAAAAAAMNX/WkAAAAAAAAAAAAAAADsa1ANAAAAAAAAAAAAAAAA
r1YmGgAAAAAAAAAAAAAAAIj///8AAAAAAAAAAAAAAAB/////AAAAAAAAAAAAAAAAfv///wAAAAAA
AAAAAAAAAH3///8AAAAAAAAAAAAAAAB8////AAAAAAAAAAAAAAAAif///wAAAAAAAAAAAAAAAIP/
//8AAAAAAAAAAAAAAACC////AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAAAID///8AAAAAAAAA
AAAAAAD/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////zMAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QAOAAQAAAAAAAAAAAKw2ygABAJ8AAAAA
AAAAAAAAAAAAAAAAAAKAAgAAAAAAAI8AAACQAAAAlwAAAJwAAACfAAAAoAAAAKUAAACpAAAArAAA
ABMEAAAfBAAAPgQAAEcEAABIBAAAWQQAAF0EAABfBAAAYAQAAGEEAABmBAAAcwQAAH4EAACVBAAA
mgQAAJ4EAAChBAAAqgQAAOEEAADiBAAA5AQAAOgEAADrBAAA7QQAAPEEAADyBAAA/QQAAAcFAAAI
BQAAMQUAADcFAABDBQAAyw0AAOINAACIEgAAiRIAAJwSAAChEgAApBIAALESAACzEgAA2BIAANkS
AADaEgAAQAAACABAAABBAAB+AAAAAEEAIAkAQAAAQQAwCQBAAABBAAJ+AAAAAEEAOgkAQAAAQQAI
fgAAAABBAEYJAEAAAEEAEn4AAAAAQABOCQBAAABBAACCAAAAAEEAHBAAQAAAQQAYggAAAABBACqC
AAAAAEEAiBAAQAAAQQC8EABAAABBACyCAAAAAEEAMIIAAAAAQQAyggAAAABBADSCAAAAAEEAPoIA
AAAAQQDEEABAAABAANoQAEAAAEEAWIIAAAAAQQBiggAAAABBAGqCAAAAAEEAcIIAAAAAQAAIEQBA
AABAAIKCAAAAAEEAhIIAAAAAQQCIggAAAABBAJCCAAAAAEEAloIAAAAAQQCaggAAAABBAKKCAAAA
AEEApIIAAAAAQQC6ggAAAABAAHYRAEAAAEEAghEAQAAAQQDOggAAAABAANQRAEAAAEAAChIAQAAA
QQDaggAAAABAAEojAEAAAEAALi0AQAAAQACYLABAAABBAMAsAEAAAEEAGH4AAAAAQQAefgAAAABA
AN4sAEAAAEAA4iwAQAAAQAAIgwAAAABAAC4tAEAAAAYAAABHFpABAAACAgYDBQQFAgMEhzoAAAAA
AAAAAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAF
BQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYE
AgICAgIEhzoAAAAAAAAAAAAAAAAAAP8AAAAAAAAAQQByAGkAYQBsAAAANSaQAQAAAgsGBAMFBAQC
BIc6AAEAAAAAAAAAAAAAAAD/AAEAAAAAAFQAYQBoAG8AbQBhAAAAPzWQAQAAAgcDCQICBQIEBIc6
AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAA
AAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIABAAxCIgY
AADFAgAAqQEAAAAAg3RhJkF6YUZJdWEmBgAQAAAArgIAAEgPAAABAAcAAAAEAAMQIAAAAAAAAAAA
AAAAAQABAAAAAQAAAAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0
AIAAEjAAABAAGQBkAAAAGQAAAMQSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA+CwAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAABgAUgBvAGwAYQBu
AGQAbwAgAEoAbwByAGcAZQAgAFoAYQBwAHAAYQBjAG8AcwB0AGEAAAAAAAAAEABtAGkAYwByAG8A
aQBuAGYAbwByAG0AYQB0AGkAYwBhAB0ARABpAHIAZQBjAGMAaQBvAG4AIABTAGkAcwB0AGUAbQBh
AHMAIABkAGUAIABJAG4AZgBvAHIAbQBhAAAAAAAAAAAAAAAAAAAAAAAAAAAArdrwoDMYuO1L4GZH
MvpQfAnaGjssqsBd6Af3Kka6WTmMQTiDaFAv9eRAY2hzPFM9NjuL5CD2L4emgT2MMAe/8zCXMsJg
1IvEi8/uZaH6ceeK/kRyQwrYDFs8VA18zNNlWpla+GqxH+cnj5fkiwqPnhm+OBzdU70wrq5lLBZw
brac8xytXTXTw0vP4P1X0sAVkni+4O2zUp8V+NVVPMM/scAbILQjETdFopW3UVpSk6boXHfxQdzx
S1EhgwRnwPLlAtYMe7FCvL29nNSLeqzZXuHENTwGyMig9OM/wplDaqwGDotpqB3wsFZ3EsiGVu5M
1lI7+HwUVfMyltXTQTU+bgNL1Vk2OP3PJP/7HeeGoNuhaxTT7UQ7ixZ4u/Ciz74Kt3ah+7awDNTq
lVyAajMNsfkfng1A8hf0l6VaX1Hmyp+gxWCvyzp0NI9OGaX6CwW05CjKYcGamxp5AMn/YQ6QZzIC
hPlZrSGRe023dWDYtv/fvDg/q03ND4HmBmJkEIIP8qKii2Ne/g4+ZilKa+Z/0ERJMVfvc53ifXDW
PZQYUI4MmzeI3p+2Yz18G/+xDsryEH5M0k1DRG6GkBTEWecGRJK1oZQK5sq69hAeG+SP5g8PujJI
PMphN3MGYSUkeA3xH39kGeQlGwhS7KXBAEkACgwAAEQSvwAAAAAAABAAAAAAAAQAAJgWAAAOAGJq
Ymqys7KzAAAAAAAAAAAAAAAAAAAAAAAACgwWAACEAADQ2QEA0NkBAIkSAAAAAAAAUAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA//8PAAAAAAAAAAAA//8PAAAAAAAAAAAA//8PAAAAAAAAAAAAAAAAAAAA
AABdAAAAAAAAAAAAAAAAAB4TAAAeEwAAAAAAAB4TAAAAAAAAHhMAAAAAAAAeEwAAAAAAAB4TAAAU
AAAAAAAAAAAAAAAyEwAAAAAAANwaAAAAAAAA3BoAAAAAAADcGgAAOAAAABQbAAAUAAAAKBsAAEQA
AAAyEwAAAAAAAAc+AABoAQAAmBsAAAAAAACYGwAAAAAAAJgbAAAAAAAAmBsAAAAAAACYGwAAAAAA
AGsdAAAAAAAAax0AAAAAAABrHQAAAAAAAFw7AAACAAAAXjsAAAAAAABeOwAAAAAAAF47AAAAAAAA
XjsAAAAAAABeOwAAAAAAAF47AAAkAAAAbz8AAPQBAABjQQAAtAAAAII7AACFAgAAAAAAAAAAAAAA
AAAAAAAAAB4TAAAAAAAAax0AAAAAAAAAAAAAAAAAAAAAAAAAAAAASR0AACIAAABrHQAAAAAAAGsd
AAAAAAAAax0AAAAAAACCOwAAAAAAANcfAAAAAAAAHhMAAAAAAAAeEwAAAAAAAJgbAAAAAAAAAAAA
AAAAAACYGwAAsQEAAJgbAAAAAAAA1x8AAAAAAADXHwAAAAAAANcfAAAAAAAAax0AAMYBAAAeEwAA
AAAAAJgbAAAAAAAAHhMAAAAAAACYGwAAAAAAAFw7AAAAAAAAAAAAAAAAAAAAAAAAAAAAADITAAAA
AAAAMhMAAAAAAAAeEwAAAAAAAB4TAAAAAAAAHhMAAAAAAAAeEwAAAAAAAGsdAAAAAAAAXDsAAAAA
AADXHwAA7gUAANcfAAAAAAAAxSUAAJYFAADwNgAAAAQAAB4TAAAAAAAAHhMAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFw7AAAAAAAA
mBsAAAAAAABsGwAALAAAAEC2aFa8ncEBMhMAAKoHAADcGgAAAAAAADEfAACmAAAA8DoAAGwAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA
RgAAAADAG//zPp3BAUC2aFa8ncEB1AAAAAAFAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEGAAAABQAAAP////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACnAAAAF0IAAAAAAABXAG8AcgBkAEQA
bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC
AQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM4AAAAAhAAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAADAAAAOgBAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAA
AIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAEMAAAD+////lgAAAJcAAACYAAAA
mQAAAP7//////////v//////////////////////////////////////////////////////////
////qAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAAC1AAAA////////////////////////
//+2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAA
AMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAAD+////zwAAAAIAAADTAAAA
/f////3////+////1QAAANYAAAD+////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA
CwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAGgAAAP////8Z
AAAAPgAAABgAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcA
AAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAA
ADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAXAAAABsAAAD//////////10AAAD/////
RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABS
AAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAdAAAAEEAAACUAAAA////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////3UAAAB2AAAAlQAAAHgAAAB5AAAAegAAAHsAAAB8AAAA
fQAAAH4AAAB/AAAAgAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy
AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAGQCAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAAAAAAAwAFQAYQBiAGwAZQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHcAAACwegAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhkAAABEb2N1bWVudG8g
TWljcm9zb2Z0IFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAACAAAA
AtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuWAEAABQBAAAMAAAAAQAAAGgAAAAP
AAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMA
AADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAAD1AAAAAgAAAOQEAAAeAAAAGAAAAFRlbGVm825pY2Eg
ZGUgQXJnZW50aW5hAAMAAAAgAAAAAwAAAAcAAAADAAAAxBIAAAMAAACzDQgACwAAAAAAAAALAAAA
AAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABkAAABSb2xhbmRvIEpvcmdlIFphcHBhY29zdGEA
DBAAAAIAAAAeAAAABwAAAFTtdHVsbwADAAAAAQAAAAwBAAAEAAAAAAAAACgAAAABAAAAUgAAAAIA
AABaAAAAAwAAALIAAAACAAAAAgAAAAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwAC
AAAA5AQAAEEAAABOAAAAewBGADkAMgA0AEIARQBGADkALQA4AEMAOQBGAC0AMQAxAEQAMwAtADkA
QgAzAEIALQAwADAAMgAwAEEARgBFADQARgA4ADIAQQB9AAAAAABBAAAAUAAAAAYAAAADAAAATQBl
AAMAAAD/////AwAAAAIEAAADAAAAAQAAAB8AAAAMAAAAQQA6AFwAZgBvAHQAbwAuAHAAYwB4AAAA
HwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAA
AAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAuAEAABIAAAABAAAAmAAAAAIAAACgAAAA
AwAAAMQAAAAEAAAA0AAAAAUAAADsAAAABgAAAPgAAAAHAAAABAEAAAgAAAAYAQAACQAAAEABAAAS
AAAATAEAAAoAAABoAQAACwAAAHQBAAAMAAAAgAEAAA0AAACMAQAADgAAAJgBAAAPAAAAoAEAABAA
AACoAQAAEwAAALABAAACAAAA5AQAAB4AAAAZAAAAUm9sYW5kbyBKb3JnZSBaYXBwYWNvc3RhAAAw
AB4AAAABAAAAAG9sYR4AAAARAAAAbWljcm9pbmZvcm1hdGljYQBwYWMeAAAAAQAAAABpY3IeAAAA
AQAAAABpY3IeAAAACwAAAE5vcm1hbC5kb3QAYR4AAAAeAAAARGlyZWNjaW9uIFNpc3RlbWFzIGRl
IEluZm9ybWEATWkeAAAAAgAAADYAcmUeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMABkQAAAAABg
NDwCAAAAQAAAAAB2CtVYncEBQAAAAACaKdk+ncEBQAAAAAAmJUy8ncEBAwAAAAEAAAADAAAArgIA
AAMAAABIDwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh
AHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAAAAZAIAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrAAAAAAAAADAAVABhAGIAbABlAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwAAAPy8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD//////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwA
AAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAPwAAAP////8ZAAAAQAAA
AP////8cAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA
KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3
AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAXAAAAP////8YAAAAGwAAAF0AAABeAAAARAAAAEUA
AABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAA
AFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAdAAAAEEAAABCAAAA/v///2AAAABhAAAA
YgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABw
AAAAcQAAAHIAAABzAAAAmgAAAHUAAAB2AAAAlQAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4A
AAB/AAAAgAAAAAEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYZAAAARG9jdW1lbnRvIE1pY3Jv
c29mdCBXb3JkAAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWc
LhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlgBAAAUAQAADAAAAAEAAABoAAAADwAAAHAA
AAAFAAAAkAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAAAAsAAACwAAAAEAAAALgAAAATAAAAwAAA
ABYAAADIAAAADQAAANAAAAAMAAAA9QAAAAIAAADkBAAAHgAAABgAAABUZWxlZvNuaWNhIGRlIEFy
Z2VudGluYQADAAAAIAAAAAMAAAAHAAAAAwAAAMQSAAADAAAAsw0IAAsAAAAAAAAACwAAAAAAAAAL
AAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAZAAAAUm9sYW5kbyBKb3JnZSBaYXBwYWNvc3RhAAwQAAAC
AAAAHgAAAAcAAABU7XR1bG8AAwAAAAEAAAAMAQAABAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAA
AAMAAACyAAAAAgAAAAIAAAAKAAAAX1BJRF9HVUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQE
AABBAAAATgAAAHsARgA5ADIANABCAEUARgA5AC0AOABDADkARgAtADEAMQBEADMALQA5AEIAMwBC
AC0AMAAwADIAMABBAEYARQA0AEYAOAAyAEEAfQAAAAAAQQAAAFAAAAAGAAAAAwAAAE0AZQADAAAA
/////wMAAAACBAAAAwAAAAEAAAAfAAAADAAAAEEAOgBcAGYAbwB0AG8ALgBwAGMAeAAAAB8AAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAA
AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALgBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADE
AAAABAAAANAAAAAFAAAA7AAAAAYAAAD4AAAABwAAAAQBAAAIAAAAGAEAAAkAAABAAQAAEgAAAEwB
AAAKAAAAaAEAAAsAAAB0AQAADAAAAIABAAANAAAAjAEAAA4AAACYAQAADwAAAKABAAAQAAAAqAEA
ABMAAACwAQAAAgAAAOQEAAAeAAAAGQAAAFJvbGFuZG8gSm9yZ2UgWmFwcGFjb3N0YQAAMAAeAAAA
AQAAAABvbGEeAAAAEQAAAG1pY3JvaW5mb3JtYXRpY2EAcGFjHgAAAAEAAAAAaWNyHgAAAAEAAAAA
aWNyHgAAAAsAAABOb3JtYWwuZG90AGEeAAAAHgAAAERpcmVjY2lvbiBTaXN0ZW1hcyBkZSBJbmZv
cm1hAE1pHgAAAAIAAAA3AHJlHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAAZEAAAAAApvdfAgAA
AEAAAAAAdgrVWJ3BAUAAAAAAminZPp3BAUAAAAAAVj9qvZ3BAQMAAAABAAAAAwAAAK4CAAADAAAA
SA8AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA==

------_=_NextPart_000_01C19DF5.5942E870--


From owner-mpls@UU.NET  Tue Jan 15 17:57:51 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15595
	for <mpls-archive@lists.ietf.org>; Tue, 15 Jan 2002 17:57:51 -0500 (EST)
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 QQlxyx15700;
	Tue, 15 Jan 2002 22:57:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxyx07798
	for mpls-outgoing; Tue, 15 Jan 2002 22:56: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 QQlxyx07793
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 22:56: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 QQlxyx10429
	for <mpls@uu.net>; Tue, 15 Jan 2002 22:53:57 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlxyx06428
	for <mpls@uu.net>; Tue, 15 Jan 2002 22:53:56 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 RAA18188 for <mpls@uu.net>; Tue, 15 Jan 2002 17:53:56 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA23914 for mpls@uu.net; Tue, 15 Jan 2002 17:53:56 -0500 (EST)
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 QQlxys10911
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 21:34:18 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 QQlxys11471
	for <mpls@UU.NET>; Tue, 15 Jan 2002 21:32:46 GMT
Received: from web14901.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14901.mail.yahoo.com [216.136.225.53])
	id QQlxys03407
	for <mpls@UU.NET>; Tue, 15 Jan 2002 21:32:46 GMT
Message-ID: <20020115213243.30190.qmail@web14901.mail.yahoo.com>
Received: from [204.253.82.9] by web14901.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 13:32:42 PST
Date: Tue, 15 Jan 2002 13:32:42 -0800 (PST)
From: Snigdho Bardalai <sbardalai@yahoo.com>
Subject: Explicit Loose Path Computation
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I wanted to find out if anybody has come across an
algorithm to compute an explicit loose path.

Thanks,
Snigdho

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/



From owner-mpls@UU.NET  Tue Jan 15 18:34:50 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16222
	for <mpls-archive@lists.ietf.org>; Tue, 15 Jan 2002 18:34:50 -0500 (EST)
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 QQlxza20619;
	Tue, 15 Jan 2002 23:34:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlxza00598
	for mpls-outgoing; Tue, 15 Jan 2002 23:34: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 QQlxza00591
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 15 Jan 2002 23:34: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 QQlxza18236
	for <mpls@uu.net>; Tue, 15 Jan 2002 23:33:48 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 QQlxza18974
	for <mpls@uu.net>; Tue, 15 Jan 2002 23:33:48 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 SAA03451
	for <mpls@uu.net>; Tue, 15 Jan 2002 18:33:45 -0500 (EST)
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 SAA10167
	for <mpls@uu.net>; Tue, 15 Jan 2002 18:33:46 -0500 (EST)
Message-ID: <3C44BCCD.8A1CA295@marconi.com>
Date: Tue, 15 Jan 2002 18:35:41 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Explicit Loose Path Computation
References: <20020115213243.30190.qmail@web14901.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

Snigdho Bardalai wrote:
> 
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough routing information
available to automatically compute an ERO, why wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation, where a human
operator can specify certain key nodes, knowing that the topology of the
intervening nodes may change over time.  But any software that
auto-generates these EROs should also be capable of dynamically
recomputing those EROs as the topology changes, meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David


From owner-mpls@UU.NET  Wed Jan 16 03:38:10 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02749
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 03:38:10 -0500 (EST)
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 QQlyak04571;
	Wed, 16 Jan 2002 08:37:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyak09632
	for mpls-outgoing; Wed, 16 Jan 2002 08:36: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 QQlyak09623
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 08:36:48 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlyak08689
	for <mpls@UU.NET>; Wed, 16 Jan 2002 08:36:36 GMT
Received: from p-mail1.rd.francetelecom.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: p-mail1.rd.francetelecom.com [193.49.124.31])
	id QQlyak03425
	for <mpls@UU.NET>; Wed, 16 Jan 2002 08:36:30 GMT
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <CVJTNS33>; Wed, 16 Jan 2002 09:35:57 +0100
Message-ID: <9549DC8CBBA9D411BEFD00062938847B015A9B30@lat4576.rd.francetelecom.fr>
From: LE ROUX Jean-Louis FTRD/DAC/LAN
	 <jeanlouis.leroux@rd.francetelecom.com>
To: "'David Charlap'" <David.Charlap@marconi.com>,
        "'Snigdho Bardalai'"
	 <sbardalai@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: Explicit Loose Path Computation
Date: Wed, 16 Jan 2002 09:36:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Are you sure David that there is no real need for loose nodes ?

To my mind loose routes may be relevant in case of multi-area, or multi AS
TE.

The head-end LSR calculates a route that is stirctely explicited in it's
area, because it has a complete topology, and loosely explicited in other
areas, because it has only some recheability information provided by border
routers.

Each border router receving a Path message loosely routed, determines the
strict path in it's area.


JL



-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: mercredi 16 janvier 2002 00:36
To: mpls@UU.NET
Subject: Re: Explicit Loose Path Computation


Snigdho Bardalai wrote:
> 
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough routing information
available to automatically compute an ERO, why wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation, where a human
operator can specify certain key nodes, knowing that the topology of the
intervening nodes may change over time.  But any software that
auto-generates these EROs should also be capable of dynamically
recomputing those EROs as the topology changes, meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David


From owner-mpls@UU.NET  Wed Jan 16 04:29:40 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03221
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 04:29:39 -0500 (EST)
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 QQlyan26296;
	Wed, 16 Jan 2002 09:29:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyan03451
	for mpls-outgoing; Wed, 16 Jan 2002 09:28: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 QQlyan03444
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 09:28: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 QQlyan15210
	for <mpls@UU.NET>; Wed, 16 Jan 2002 09:28:28 GMT
From: sven.van_den_bosch@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 QQlyan02839
	for <mpls@UU.NET>; Wed, 16 Jan 2002 09:28:26 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0G9S1d03135;
	Wed, 16 Jan 2002 10:28:02 +0100 (MET)
Subject: RE: Explicit Loose Path Computation
To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>
Cc: "'David Charlap'" <David.Charlap@marconi.com>,
        "'Snigdho Bardalai'" <sbardalai@yahoo.com>, mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF505CDA00.A2C7EF1E-ONC1256B43.00303839@net.alcatel.be>
Date: Wed, 16 Jan 2002 09:59:49 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/16/2002 10:28:02
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Let's explore this a little bit further.

In my opinion, the proposal for loosely specified parts in the explicit
route (the ABRs probably) makes sense if:
- the ABR of the computing area has more than one ABR alternative in the
destination area
- the computing node knows about the path between the possible ABR pairs
- the computing node knows about the path following the ABR in the
destination area
After all, why would you change the ABR selection if it wasn't to find a
more optimal path? I think the above scenario requires signalling between
the computing node and one or more ABRs. In this case, couldn't we assume
that not only the computing node, but also the explicit route (segment) is
passed?
I agree, however, that it may be interesting to be able to set up more
optimal multi-area LSPs without the need for communication between
computing nodes or specifying the complete explicit route at the ingress.
In draft-vdbosch-tewg-multiarea-branch-te-00.txt, a proposal is made to
send several path setup messages in parallel and letting the egress decide
on the actual path that is taken. This does not require specifying the
complete explicit route at the ingress. It allows the specification of any
path segment, and it can find the most optimal path through the network. It
achieves this at the cost of extra signalling during LSP setup.

Sven.






"LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>
on 16/01/2002 09:36:08
                                                              
                                                              
                                                              
  To:          "'David Charlap'" <David.Charlap@marconi.com>, 
               "'Snigdho Bardalai'" <sbardalai@yahoo.com>     
                                                              
  cc:          mpls@UU.NET(bcc: Sven VAN DEN                  
               BOSCH/BE/ALCATEL)                              
                                                              
                                                              
                                                              
  Subject      RE: Explicit Loose Path Computation            
  :                                                           
                                                              





Are you sure David that there is no real need for loose nodes ?

To my mind loose routes may be relevant in case of multi-area, or multi AS
TE.

The head-end LSR calculates a route that is stirctely explicited in it's
area, because it has a complete topology, and loosely explicited in other
areas, because it has only some recheability information provided by border
routers.

Each border router receving a Path message loosely routed, determines the
strict path in it's area.


JL



-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: mercredi 16 janvier 2002 00:36
To: mpls@UU.NET
Subject: Re: Explicit Loose Path Computation


Snigdho Bardalai wrote:
>
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough routing information
available to automatically compute an ERO, why wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation, where a human
operator can specify certain key nodes, knowing that the topology of the
intervening nodes may change over time.  But any software that
auto-generates these EROs should also be capable of dynamically
recomputing those EROs as the topology changes, meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David





From owner-mpls@UU.NET  Wed Jan 16 06:32:43 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04156
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 06:32:43 -0500 (EST)
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 QQlyaw28543;
	Wed, 16 Jan 2002 11:31:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyaw22479
	for mpls-outgoing; Wed, 16 Jan 2002 11:31: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 QQlyaw22469
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 11:31: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 QQlyaw17962
	for <mpls@UU.NET>; Wed, 16 Jan 2002 11:31:15 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlyaw18922
	for <mpls@UU.NET>; Wed, 16 Jan 2002 11:31:14 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT50BND>; Wed, 16 Jan 2002 16:52:55 +0530
Message-ID: <D11B30C7348BD511A40700010283497B40DA59@GAYATRI>
From: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>
To: "mpls@UU.NET (E-mail)" <mpls@UU.NET>
Subject: mpsl testing using netsim
Date: Wed, 16 Jan 2002 16:59:13 +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

Hello All

        Can anyone tell me whether we can do LDP testing using NetSim
(www.isi.edu/nsnam/ns) ?  If so how ?


Thanks In Advance

gopinathg


Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.




From owner-mpls@UU.NET  Wed Jan 16 06:33:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04170
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 06:33:23 -0500 (EST)
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 QQlyav11926;
	Wed, 16 Jan 2002 11:27:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyav22136
	for mpls-outgoing; Wed, 16 Jan 2002 11:27: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 QQlyav22127
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 11:27: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 QQlyav05978
	for <mpls@UU.NET>; Wed, 16 Jan 2002 11:25:25 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlyav08263
	for <mpls@UU.NET>; Wed, 16 Jan 2002 11:25:24 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT50BJ0>; Wed, 16 Jan 2002 16:47:04 +0530
Message-ID: <D11B30C7348BD511A40700010283497B40DA52@GAYATRI>
From: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>
To: "mpls@UU.NET (E-mail)" <mpls@UU.NET>
Date: Wed, 16 Jan 2002 16:53:20 +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




Gopinath.G.S
Member Technical Staff
HCL Technologies
VI Floor P.M Towers
37 Greams Road
Thousand Lights
CHENNAI  600 006

Mail-id : gopinathg@ctd.hcltech.com
Personal Mails: srinivasagopinat@yahoo.com

Ph work: +91-44-8291735/36/37 ext-629
Ph Res  : +91-44-8292491

Disclaimer:
This document is intended for transmission to the named recipient only.  If
you are not that person, you should note that legal rights reside in this
document and you are not authorized to access, read, disclose, copy, use or
otherwise deal with it and any such actions are prohibited and may be
unlawful. The views expressed in this document are not necessarily those of
HCL Technologies Ltd. Notice is hereby given that no representation,
contract or other binding obligation shall be created by this e-mail, which
must be interpreted accordingly. Any representations, contractual rights or
obligations shall be separately communicated in writing and signed in the
original by a duly authorized officer of the relevant company.




From owner-mpls@UU.NET  Wed Jan 16 07:27:26 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05229
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 07:27:26 -0500 (EST)
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 QQlyaz07686;
	Wed, 16 Jan 2002 12:26:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyaz16440
	for mpls-outgoing; Wed, 16 Jan 2002 12:26: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 QQlyaz16341
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 12:26: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 QQlyay07838
	for <mpls@UU.NET>; Wed, 16 Jan 2002 12:00:31 GMT
From: sven.van_den_bosch@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 QQlyay11994
	for <mpls@UU.NET>; Wed, 16 Jan 2002 12:00:30 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0GC0Tw08286
	for <mpls@UU.NET>; Wed, 16 Jan 2002 13:00:29 +0100 (MET)
Subject: last call on hierarchy
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF809B6E88.45B9028D-ONC1256B43.003E75E1@net.alcatel.be>
Date: Wed, 16 Jan 2002 12:33:46 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/16/2002 13:00:29
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I would like to clarify two questions regarding the hierarchy draft that is
currently on last call:

1. Dynamic recomputation of the path of the FA-LSP

If I understand correctly, the path information regarding the FA-LSP is
made available to other nodes by means of the PATH TLV. This information
may be used by other nodes for their own path computations. They could for
instance take it into account when computing a backup path. Then if the
FA-LSP changes path, primary and backup path of the client LSPs may no
longer be disjoint.

My proposal would be to foresee the possibility to restrict the
reroutability of the FA-LSP and advertise this in the PATH-TLV. In this
way, nodes that use this information would know whether it is subject to
change or not.

2. Automatic setup of FA-LSP

The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets up
a new FA-LSP.  That is, it initiates a new LSP setup just for the FA-LSP."
I would like to clarify what happens when two FA-LSPs exist that, when
concatenated, can replace the new FA-LSP that is proposed to be set up in
the quoted text.

I would propose to say that the LSR may set up a new FA-LSP or
alternatively, it may replace the hop by a sequence of hops for which FAs
are available.

Would this make sense?

Sven.



From owner-mpls@UU.NET  Wed Jan 16 08:56:50 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07196
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 08:56:50 -0500 (EST)
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 QQlybf20595;
	Wed, 16 Jan 2002 13:56:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybf12805
	for mpls-outgoing; Wed, 16 Jan 2002 13:55: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 QQlybf12800
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 13:55:49 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 QQlybf00813
	for <mpls@uu.net>; Wed, 16 Jan 2002 13:53:43 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlybf29283
	for <mpls@uu.net>; Wed, 16 Jan 2002 13:53: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 IAA01254 for <mpls@uu.net>; Wed, 16 Jan 2002 08:53:42 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01505 for mpls@uu.net; Wed, 16 Jan 2002 08:53:42 -0500 (EST)
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 QQlxzd24525
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 00:29: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 QQlxzd14429
	for <mpls@uu.net>; Wed, 16 Jan 2002 00:29:12 GMT
From: claus.bauer@tellabs.com
Received: from mx4.tellabs.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx4.tellabs.com [204.68.180.54])
	id QQlxzd01686
	for <mpls@uu.net>; Wed, 16 Jan 2002 00:29:12 GMT
Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101])
	by mx4.tellabs.com (Mirapoint)
	with ESMTP id ACC81758;
	Tue, 15 Jan 2002 18:28:46 -0600 (CST)
Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id SAA20772 for <mpls@uu.net>; Tue, 15 Jan 2002 18:28:48 -0600 (CST)
X-OpenMail-Hops: 1
Date: Tue, 15 Jan 2002 18:28:47 -0600
Message-Id: <H00006c4037782aa.1011140927.mailw02@MHS>
Subject: draft-chang-mpls-path-protection
MIME-Version: 1.0
TO: mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Tue, 15 Jan 2002 18:28:47 -0600"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi 

three questions on the drafts draft-chang-mpls-path-protection and 
draft-owens-crldp-path-protection:
1. I understand that the PSL receives the ER -Protection ER-HOP TLV 
without an Path Protection TLV. 
Before forwarding the label request message, the PSL introduces the Path 

Protection TVL. Therefore, the PSL must decide which value the value of 
the Flags field in the Path Protection TLV. Based on what is this 
decision taken ? Network policy ? Would it not make sense that the 
ingress router tells the PSL how to choose the Flags field.
2. Once the PSL has decided how to set the Flags field, he needs to be 
able to distinguish between working and protection path to forward the 
data along the correct path. If CR-LDP is used, the work and protection 
path both have the same LSPID TLV (non-merged) or the same FEC TLV 
(merged). So what information does the LSR use to distinguisg between 
both paths ?
3. Why do you chose different common identifier for working and 
protection path in the merged and non-merged case ?

Thanks in advance

Claus

Dr. Claus Bauer
Research engineer
Tellabs Research Center
One Kendall Square
Bldg. 100, Suite 121
Cambridge, MA, 02139
USA

Tel.: +1 617 577 8787
Fax.: +1 617 494 0118
 
Dr. Claus Bauer
Research engineer
Tellabs Research Center
One Kendall Square
Bldg. 100, Suite 121
Cambridge, MA, 02139
USA

Tel.: +1 617 577 8787
Fax.: +1 617 494 0118
 



From owner-mpls@UU.NET  Wed Jan 16 10:47:35 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11839
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 10:47:35 -0500 (EST)
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 QQlybm03332;
	Wed, 16 Jan 2002 15:44:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybm01441
	for mpls-outgoing; Wed, 16 Jan 2002 15:44: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 QQlybm01408
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 15:44:04 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 QQlybm29295
	for <mpls@uu.net>; Wed, 16 Jan 2002 15:43:37 GMT
Received: from smtp5.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp5.cluster.oleane.net [195.25.12.27])
	id QQlybm18731
	for <mpls@uu.net>; Wed, 16 Jan 2002 15:43:37 GMT
Received: from conference (nas-cbv-2-29-152.dial.proxad.net [213.228.29.152]) by smtp5.cluster.oleane.net with SMTP id g0GFhZc38403 for <mpls@uu.net>; Wed, 16 Jan 2002 16:43:35 +0100 (CET)
Message-ID: <003201c19ea4$cb372ae0$1864a8c0@conference.local>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <mpls@UU.NET>
Subject: The "Ethernet in the Access" conference
Date: Wed, 16 Jan 2002 16:45:14 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C19EAD.2BC44B60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C19EAD.2BC44B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The "Ethernet in the Access" conference, to be held on May 21 and 24 in =
Paris, will serve as a backdrop for bringing together normalization body =
representatives, equipment vendors and operators involved actively in =
developing ways to allow Ethernet to become a credible protocol in the =
access network.=20
A call for papers is online at:
http://www.upperside.fr/ethernetaccess/ethaccessintro.htm

------=_NextPart_000_002F_01C19EAD.2BC44B60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D2>The &quot;<STRONG>Ethernet in the =
Access</STRONG>&quot;=20
conference, to be held on May 21 and 24 in Paris, will serve as a =
backdrop for=20
bringing together normalization body representatives, equipment vendors =
and=20
operators involved actively in developing ways to allow Ethernet to =
become a=20
credible protocol in the access network. </FONT></DIV>
<DIV><FONT size=3D2>A call for papers is online at:<BR></FONT><FONT =
size=3D2><A=20
href=3D"http://www.upperside.fr/ethernetaccess/ethaccessintro.htm">http:/=
/www.upperside.fr/ethernetaccess/ethaccessintro.htm</A></FONT></DIV></DIV=
></BODY></HTML>

------=_NextPart_000_002F_01C19EAD.2BC44B60--



From owner-mpls@UU.NET  Wed Jan 16 11:32:17 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13264
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 11:32:17 -0500 (EST)
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 QQlybp28530;
	Wed, 16 Jan 2002 16:28:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybp26062
	for mpls-outgoing; Wed, 16 Jan 2002 16:27: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 QQlybp26057
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 16:27:47 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 QQlybp06527
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:27:36 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlybp08695
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:27:36 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 LAA20519 for <mpls@uu.net>; Wed, 16 Jan 2002 11:27:36 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09306 for mpls@uu.net; Wed, 16 Jan 2002 11:27:36 -0500 (EST)
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 QQlybl29873
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 15:24: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 QQlybl26203
	for <mpls@UU.NET>; Wed, 16 Jan 2002 15:24:41 GMT
Received: from web14903.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14903.mail.yahoo.com [216.136.225.55])
	id QQlybl04890
	for <mpls@UU.NET>; Wed, 16 Jan 2002 15:24:40 GMT
Message-ID: <20020116152440.7452.qmail@web14903.mail.yahoo.com>
Received: from [204.253.82.10] by web14903.mail.yahoo.com via HTTP; Wed, 16 Jan 2002 07:24:40 PST
Date: Wed, 16 Jan 2002 07:24:40 -0800 (PST)
From: Snigdho Bardalai <sbardalai@yahoo.com>
Subject: RE: Explicit Loose Path Computation
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

My question may have been a little confusing -
actually the algorithm should generate an explicit
path based on loose route constraint specification.

Snigdho

Snigdho Bardalai wrote:
> 
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough
routing information
available to automatically compute an ERO, why
wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation,
where a human
operator can specify certain key nodes, knowing that
the topology of the
intervening nodes may change over time.  But any
software that
auto-generates these EROs should also be capable of
dynamically
recomputing those EROs as the topology changes,
meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/



From owner-mpls@UU.NET  Wed Jan 16 11:32:24 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13275
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 11:32:24 -0500 (EST)
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 QQlybp11158;
	Wed, 16 Jan 2002 16:28:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybp26097
	for mpls-outgoing; Wed, 16 Jan 2002 16:28: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 QQlybp26090
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 16:28:20 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 QQlybp03274
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:27:58 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlybp09263
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:27:57 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 LAA20562 for <mpls@uu.net>; Wed, 16 Jan 2002 11:27:57 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09311 for mpls@uu.net; Wed, 16 Jan 2002 11:27:57 -0500 (EST)
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 QQlybo23634
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 16:11: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 QQlybo18836
	for <mpls@UU.NET>; Wed, 16 Jan 2002 16:10:30 GMT
Received: from smtp.monmouth.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.monmouth.com [209.191.58.6])
	id QQlybo00256
	for <mpls@UU.NET>; Wed, 16 Jan 2002 16:10:30 GMT
Received: from monmouth.com ([64.19.191.1])
	by smtp.monmouth.com (8.11.6/8.11.6) with ESMTP id g0GGAOn08626;
	Wed, 16 Jan 2002 11:10:24 -0500 (EST)
Message-ID: <3C45A5C9.4020800@monmouth.com>
Date: Wed, 16 Jan 2002 11:09:45 -0500
From: Dipak <dipak@monmouth.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: mpls@UU.NET
CC: ds_mpls@atlantis.rug.ac.be
Subject: Is RSVP-TE Label Request optional?
References: <200201021311.AA547684466@Mail.TRINICOM.COM> <3C33697E.B72AA58C@marconi.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

Hi all,
        According to RFC 3209 section 4.2.4 says that "

	If a LABEL_REQUEST object was not present in the Path
   message, a node MUST NOT include a LABEL object in a Resv message for
   that Path message's session and PHOP."


        But, in section 3.1, the PATH message format shows LABEL_REQUEST 
as not an optional object.
        Is not it contradictory? Or, should I take it as a way to make 
RSVP-TE behave as vanilla RSVP, if somebody wanted to do so?
        Can anybody help me out of this dilemma?

Thanks in advance,
Dipak



From owner-mpls@UU.NET  Wed Jan 16 12:05:53 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14193
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 12:05:52 -0500 (EST)
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 QQlybs18348;
	Wed, 16 Jan 2002 17:01:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybs03092
	for mpls-outgoing; Wed, 16 Jan 2002 17:00: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 QQlybs02081
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 17:00:39 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 QQlybr10470
	for <mpls@UU.NET>; Wed, 16 Jan 2002 16:59:39 GMT
Received: from Mail.TRINICOM.COM by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.149.136.4])
	id QQlybr07940
	for <mpls@UU.NET>; Wed, 16 Jan 2002 16:59:38 GMT
Date: Wed, 16 Jan 2002 10:52:52 -0600
Message-Id: <200201161052.AA194707792@Mail.TRINICOM.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "Sean Crocker" <crockers@mail.trinicom.com>
Reply-To: <crockers@mail.trinicom.com>
To: Dipak  <dipak@monmouth.com>, <mpls@UU.NET>
Subject: Re: Is RSVP-TE Label Request optional?
X-Mailer: <IMail v7.03>
Sender: owner-mpls@UU.NET
Precedence: bulk

>Hi all,
>        According to RFC 3209 section 4.2.4 says that "
>
>	If a LABEL_REQUEST object was not present in the Path
>   message, a node MUST NOT include a LABEL object in a Resv message for
>   that Path message's session and PHOP."
>
>
>        But, in section 3.1, the PATH message format shows LABEL_REQUEST 
>as not an optional object.
>        Is not it contradictory? Or, should I take it as a way to make 
>RSVP-TE behave as vanilla RSVP, if somebody wanted to do so?
>        Can anybody help me out of this dilemma?

I think the verbiage in 4.2.4 is meant to cover RSVP and RSVP-TE
operating in the same network, simply making sure "regular" PATHs don't
trigger LABEL objects in the reply RESVs.  Keeping track of resources
allocated for regular RSVP vs. TE might be another issue.

Sean




From owner-mpls@UU.NET  Wed Jan 16 12:16:12 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14479
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 12:16:12 -0500 (EST)
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 QQlybs18473;
	Wed, 16 Jan 2002 17:12:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybs21373
	for mpls-outgoing; Wed, 16 Jan 2002 17:12: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 QQlybs21346
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 17:11: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 QQlybs20746
	for <mpls@uu.net>; Wed, 16 Jan 2002 17:11: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 QQlybs15046
	for <mpls@uu.net>; Wed, 16 Jan 2002 17:11:04 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 MAA08821
	for <mpls@uu.net>; Wed, 16 Jan 2002 12:11:02 -0500 (EST)
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 MAA20020
	for <mpls@uu.net>; Wed, 16 Jan 2002 12:11:03 -0500 (EST)
Message-ID: <3C45B49C.76D49543@marconi.com>
Date: Wed, 16 Jan 2002 12:13:00 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Is RSVP-TE Label Request optional?
References: <200201021311.AA547684466@Mail.TRINICOM.COM> <3C33697E.B72AA58C@marconi.com> <3C45A5C9.4020800@monmouth.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dipak wrote:
> 
> According to RFC 3209 section 4.2.4 says that "
> 
>    If a LABEL_REQUEST object was not present in the Path
>    message, a node MUST NOT include a LABEL object in a Resv
>    message for that Path message's session and PHOP."
> 
>    But, in section 3.1, the PATH message format shows LABEL_REQUEST
>    as not an optional object.
>
> Is not it contradictory? Or, should I take it as a way to make
> RSVP-TE behave as vanilla RSVP, if somebody wanted to do so?
> Can anybody help me out of this dilemma?

Two different situations here.

If this is an RSVP-TE session (defined as using one of the new LSP-based
C-Types for the SESSION object), then LABEL_REQUEST is mandatory.  It is
not required for other session types.  (I don't think LABEL_REQUEST is
illegal for non-LSP session types, but it is of questionable utility.)

When generating a Resv, a LABEL must be included if the corresponding
Path had a LABEL_REQUEST.  This is always true for LSP sessions.  It is
probably not true for non-LSP sessions.

-- David


From owner-mpls@UU.NET  Wed Jan 16 12:18:34 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14544
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 12:18:34 -0500 (EST)
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 QQlybt02885;
	Wed, 16 Jan 2002 17:15:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlybs21626
	for mpls-outgoing; Wed, 16 Jan 2002 17:14:54 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 QQlybs21615
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 17:14: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 QQlybs12879
	for <mpls@UU.NET>; Wed, 16 Jan 2002 17:14: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 QQlybs01311
	for <mpls@UU.NET>; Wed, 16 Jan 2002 17:14: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 MAA09216;
	Wed, 16 Jan 2002 12:14:31 -0500 (EST)
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 MAA20913;
	Wed, 16 Jan 2002 12:14:31 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <CX5HXMV6>; Wed, 16 Jan 2002 12:14:29 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55762F55@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Snigdho Bardalai'" <sbardalai@yahoo.com>, mpls@UU.NET
Subject: RE: Explicit Loose Path Computation
Date: Wed, 16 Jan 2002 12:14:26 -0500
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

Snigdho:

-> My question may have been a little confusing -
-> actually the algorithm should generate an explicit
-> path based on loose route constraint specification.

  One simple solution (though not efficient)

  Take pairs of adjacent EROs from source to destination.
  That is, if A,B,C,D are EROs then take (A,B) as the
  source and destination pair and recursively iterate 
  path computation engine for (B,C), (C,D) etc...

  Finally combine all EROs - what you get is (one of the)
  best matched between A(source) and D(destination).

  lemma: divide and conquer.
  note: take care of accumulative constraints.

--Venkata Naidu
 


From owner-mpls@UU.NET  Wed Jan 16 14:35:57 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18651
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 14:35:57 -0500 (EST)
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 QQlycc23056;
	Wed, 16 Jan 2002 19:30:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlycc11784
	for mpls-outgoing; Wed, 16 Jan 2002 19:30: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 QQlycc11777
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 19:30: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 QQlycb04841
	for <mpls@UU.NET>; Wed, 16 Jan 2002 19:28:13 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlycb15053
	for <mpls@UU.NET>; Wed, 16 Jan 2002 19:28:13 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23923;
	Wed, 16 Jan 2002 14:28:05 -0500 (EST)
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 OAA23840;
	Wed, 16 Jan 2002 14:28:03 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <CX5HXVCM>; Wed, 16 Jan 2002 14:28:02 -0500
Message-ID: <39469E08BD83D411A3D900204840EC55822460@vie-msgusr-01.dc.fore.com>
From: "Abarbanel, Benjamin" <Benjamin.Abarbanel@Marconi.com>
To: "'sven.van_den_bosch@alcatel.be'" <sven.van_den_bosch@alcatel.be>,
        LE ROUX Jean-Louis FTRD/DAC/LAN <jeanlouis.leroux@rd.francetelecom.com>
Cc: "Charlap, David" <David.Charlap@Marconi.com>,
        "'Snigdho Bardalai'"
	 <sbardalai@yahoo.com>, mpls@UU.NET
Subject: RE: Explicit Loose Path Computation
Date: Wed, 16 Jan 2002 14:28:02 -0500
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 think there is more operational reasons to constrict an ERO path based on
certain
Loose, or Strict nodes (hops). The scenarios would be too numerous to
mention. Enough
to say that it is used beyond just optimizing TE multi-area algorithms being
proposed
in IETF.

>> "In draft-vdbosch-tewg-multiarea-branch-te-00.txt, a proposal is made to
>> send several path setup messages in parallel and letting the egress
decide
>> on the actual path that is taken. This does not require specifying the
>> complete explicit route at the ingress. It allows the specification of
any
>> path segment, and it can find the most optimal path through the network.
It
>> achieves this at the cost of extra signalling during LSP setup."
>>

I also believe that CSPF is a more efficient way to compute an ERO that is
constraint
than by using a complex signalling mechanism and finding the ERO Constraint
path.

Ben
-----Original Message-----
From: sven.van_den_bosch@alcatel.be
[mailto:sven.van_den_bosch@alcatel.be]
Sent: Wednesday, January 16, 2002 4:00 AM
To: LE ROUX Jean-Louis FTRD/DAC/LAN
Cc: 'David Charlap'; 'Snigdho Bardalai'; mpls@UU.NET
Subject: RE: Explicit Loose Path Computation


Let's explore this a little bit further.

In my opinion, the proposal for loosely specified parts in the explicit
route (the ABRs probably) makes sense if:
- the ABR of the computing area has more than one ABR alternative in the
destination area
- the computing node knows about the path between the possible ABR pairs
- the computing node knows about the path following the ABR in the
destination area
After all, why would you change the ABR selection if it wasn't to find a
more optimal path? I think the above scenario requires signalling between
the computing node and one or more ABRs. In this case, couldn't we assume
that not only the computing node, but also the explicit route (segment) is
passed?
I agree, however, that it may be interesting to be able to set up more
optimal multi-area LSPs without the need for communication between
computing nodes or specifying the complete explicit route at the ingress.
In draft-vdbosch-tewg-multiarea-branch-te-00.txt, a proposal is made to
send several path setup messages in parallel and letting the egress decide
on the actual path that is taken. This does not require specifying the
complete explicit route at the ingress. It allows the specification of any
path segment, and it can find the most optimal path through the network. It
achieves this at the cost of extra signalling during LSP setup.

Sven.






"LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>
on 16/01/2002 09:36:08
                                                              
                                                              
                                                              
  To:          "'David Charlap'" <David.Charlap@marconi.com>, 
               "'Snigdho Bardalai'" <sbardalai@yahoo.com>     
                                                              
  cc:          mpls@UU.NET(bcc: Sven VAN DEN                  
               BOSCH/BE/ALCATEL)                              
                                                              
                                                              
                                                              
  Subject      RE: Explicit Loose Path Computation            
  :                                                           
                                                              





Are you sure David that there is no real need for loose nodes ?

To my mind loose routes may be relevant in case of multi-area, or multi AS
TE.

The head-end LSR calculates a route that is stirctely explicited in it's
area, because it has a complete topology, and loosely explicited in other
areas, because it has only some recheability information provided by border
routers.

Each border router receving a Path message loosely routed, determines the
strict path in it's area.


JL



-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: mercredi 16 janvier 2002 00:36
To: mpls@UU.NET
Subject: Re: Explicit Loose Path Computation


Snigdho Bardalai wrote:
>
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough routing information
available to automatically compute an ERO, why wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation, where a human
operator can specify certain key nodes, knowing that the topology of the
intervening nodes may change over time.  But any software that
auto-generates these EROs should also be capable of dynamically
recomputing those EROs as the topology changes, meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David




From owner-mpls@UU.NET  Wed Jan 16 16:04:37 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20940
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 16:04:37 -0500 (EST)
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 QQlyci12519;
	Wed, 16 Jan 2002 21:01:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyci12510
	for mpls-outgoing; Wed, 16 Jan 2002 21:00: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 QQlyci11661
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 21:00: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 QQlyci22665
	for <mpls@uu.net>; Wed, 16 Jan 2002 21:00:11 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlyci07993
	for <mpls@uu.net>; Wed, 16 Jan 2002 21:00: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 QAA04051
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:00:08 -0500 (EST)
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 QAA16236
	for <mpls@uu.net>; Wed, 16 Jan 2002 16:00:06 -0500 (EST)
Message-ID: <3C45EA4B.68A9B52C@marconi.com>
Date: Wed, 16 Jan 2002 16:02:03 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: ERO question in RSVP-TE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I've a question regarding explicit route objects (EROs) in RSVP-TE.

RFC 3209 says (section 4.3):

	If a Path message contains multiple EXPLICIT_ROUTE objects,
	only the first object is meaningful.  Subsequent
	EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be
	propagated.

I'm wondering about one specific possible caveat here.  What if there
are two ERO objects, and the first is malformed in a way that would
cause it to be ignored (for instance, it contains no subobjects). 
Should the second ERO then be used?  Or should the second one still be
ignored, even though the first ERO is meaningless?

I'm inclined to believe that the second ERO should still be ignored, but
I'd appreciate some confirmation from others who are working on the
protocol.

-- David


From owner-mpls@UU.NET  Wed Jan 16 16:28:21 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21331
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 16:28:16 -0500 (EST)
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 QQlycj28809;
	Wed, 16 Jan 2002 21:26:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlycj01865
	for mpls-outgoing; Wed, 16 Jan 2002 21:26: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 QQlycj01857
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 21:26: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 QQlycj04171
	for <mpls@UU.NET>; Wed, 16 Jan 2002 21:24:54 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 QQlycj04509
	for <mpls@UU.NET>; Wed, 16 Jan 2002 21:24:53 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.48 2001/12/13 16:27:50 root Exp $) with SMTP id VAA14625
	for <mpls@UU.NET>; Wed, 16 Jan 2002 21:24:52 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011613265824923
 for <mpls@UU.NET>; Wed, 16 Jan 2002 13:26:58 -0800
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <C02FW0AB>; Wed, 16 Jan 2002 13:24:52 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA1A9@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: mpls@UU.NET
Subject: RE: ERO question in RSVP-TE
Date: Wed, 16 Jan 2002 13:24:51 -0800
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 am working on the assumption that the second one will be ignored,
regardless the content of the first ERO object.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:David.Charlap@marconi.com]
> Sent: Wednesday, January 16, 2002 1:02 PM
> To: mpls@UU.NET
> Subject: ERO question in RSVP-TE
> 
> 
> I've a question regarding explicit route objects (EROs) in RSVP-TE.
> 
> RFC 3209 says (section 4.3):
> 
> 	If a Path message contains multiple EXPLICIT_ROUTE objects,
> 	only the first object is meaningful.  Subsequent
> 	EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be
> 	propagated.
> 
> I'm wondering about one specific possible caveat here.  What if there
> are two ERO objects, and the first is malformed in a way that would
> cause it to be ignored (for instance, it contains no subobjects). 
> Should the second ERO then be used?  Or should the second one still be
> ignored, even though the first ERO is meaningless?
> 
> I'm inclined to believe that the second ERO should still be 
> ignored, but
> I'd appreciate some confirmation from others who are working on the
> protocol.
> 
> -- David
> 


From owner-mpls@UU.NET  Wed Jan 16 18:57:04 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23931
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 18:57:04 -0500 (EST)
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 QQlyct26170;
	Wed, 16 Jan 2002 23:56:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyct26926
	for mpls-outgoing; Wed, 16 Jan 2002 23:56:16 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlyct26879
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 23:56:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlyct28225
	for <mpls@UU.NET>; Wed, 16 Jan 2002 23:55:46 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 QQlyct03504
	for <mpls@UU.NET>; Wed, 16 Jan 2002 23:55:46 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id XAA18111
	for <mpls@UU.NET>; Wed, 16 Jan 2002 23:55:45 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011615564320375
 for <mpls@UU.NET>; Wed, 16 Jan 2002 15:56:43 -0800
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <C048AGG7>; Wed, 16 Jan 2002 15:55:44 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA1AE@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: mpls@UU.NET
Subject: RE: ERO question in RSVP-TE
Date: Wed, 16 Jan 2002 15:55:35 -0800
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 similar question regarding the ERO processing:

"It is anticipated that new subobjects may be defined over time.  A
node which encounters an unrecognized subobject during its normal ERO
processing sends a PathErr with the error code "Routing Error" and
error value of "Bad Explicit Route Object" toward the sender.  The
EXPLICIT_ROUTE object is included, truncated (on the left) to the
offending subobject."

In the TE document, there is no definition for the PathErr message. Is it
true then, ERO object can appear in the PathErr message?

Thanks in advance.

- Mark


From owner-mpls@UU.NET  Wed Jan 16 19:34:41 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24564
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 19:34:41 -0500 (EST)
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 QQlycw23266;
	Thu, 17 Jan 2002 00:34:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlycw19760
	for mpls-outgoing; Thu, 17 Jan 2002 00:33:34 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlycw19755
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 00:33: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 QQlycw00881
	for <mpls@uu.net>; Thu, 17 Jan 2002 00:33:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlycw26117
	for <mpls@uu.net>; Thu, 17 Jan 2002 00:33:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA14573 for <mpls@uu.net>; Wed, 16 Jan 2002 19:33:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA04242 for mpls@uu.net; Wed, 16 Jan 2002 19:33:01 -0500 (EST)
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 QQlycw19693
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 00:31:53 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlycw15325
	for <mpls@UU.NET>; Thu, 17 Jan 2002 00:31:33 GMT
Received: from nisser.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nisser.cisco.com [171.71.176.85])
	id QQlycw17983
	for <mpls@UU.NET>; Thu, 17 Jan 2002 00:31:32 GMT
Received: from BORA-W2K1.cisco.com (dhcp-171-69-39-121.cisco.com [171.69.39.121]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA07623; Wed, 16 Jan 2002 16:31:27 -0800 (PST)
Message-Id: <4.3.2.7.2.20020116162740.03050ec8@mira-sjc5-9.cisco.com>
X-Sender: bora@mira-sjc5-9.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 16 Jan 2002 16:28:17 -0800
To: David Charlap <David.Charlap@marconi.com>
From: Bora Akyol <bora@cisco.com>
Subject: Re: ERO question in RSVP-TE
Cc: mpls@UU.NET
In-Reply-To: <3C45EA4B.68A9B52C@marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

I don't see any reason other than bugs to generate such an object stream. 
Safe to ignore both probably.

Bora

At 04:02 PM 1/16/2002 -0500, David Charlap wrote:
>I've a question regarding explicit route objects (EROs) in RSVP-TE.
>
>RFC 3209 says (section 4.3):
>
>         If a Path message contains multiple EXPLICIT_ROUTE objects,
>         only the first object is meaningful.  Subsequent
>         EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be
>         propagated.
>
>I'm wondering about one specific possible caveat here.  What if there
>are two ERO objects, and the first is malformed in a way that would
>cause it to be ignored (for instance, it contains no subobjects).
>Should the second ERO then be used?  Or should the second one still be
>ignored, even though the first ERO is meaningless?
>
>I'm inclined to believe that the second ERO should still be ignored, but
>I'd appreciate some confirmation from others who are working on the
>protocol.
>
>-- David



From owner-mpls@UU.NET  Wed Jan 16 19:41:15 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24711
	for <mpls-archive@lists.ietf.org>; Wed, 16 Jan 2002 19:41:15 -0500 (EST)
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 QQlycw06146;
	Thu, 17 Jan 2002 00:40:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlycw20322
	for mpls-outgoing; Thu, 17 Jan 2002 00:40:16 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 QQlycw20315
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 00:40: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 QQlycw12077
	for <mpls@UU.NET>; Thu, 17 Jan 2002 00:40:09 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 QQlycw05083
	for <mpls@UU.NET>; Thu, 17 Jan 2002 00:40:08 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.48 2001/12/13 16:27:50 root Exp $) with SMTP id AAA11100
	for <mpls@UU.NET>; Thu, 17 Jan 2002 00:40:08 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011616421406169
 for <mpls@UU.NET>; Wed, 16 Jan 2002 16:42:14 -0800
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <C02FX5XA>; Wed, 16 Jan 2002 16:40:07 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA1B2@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: FW: ERO question in RSVP-TE
Date: Wed, 16 Jan 2002 16:39:59 -0800
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 duplicate e-mail. It seems the first one got lost...

-----Original Message-----
From: Feng, Mark 
Sent: Wednesday, January 16, 2002 3:56 PM
To: mpls@UU.NET
Subject: RE: ERO question in RSVP-TE


I have a similar question regarding the ERO processing:

"It is anticipated that new subobjects may be defined over time.  A
node which encounters an unrecognized subobject during its normal ERO
processing sends a PathErr with the error code "Routing Error" and
error value of "Bad Explicit Route Object" toward the sender.  The
EXPLICIT_ROUTE object is included, truncated (on the left) to the
offending subobject."

In the TE document, there is no definition for the PathErr message. Is it
true then, ERO object can appear in the PathErr message?

Thanks in advance.

- Mark


From owner-mpls@UU.NET  Thu Jan 17 02:56:59 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09836
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 02:56:59 -0500 (EST)
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 QQlydz17061;
	Thu, 17 Jan 2002 07:56:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlydz12115
	for mpls-outgoing; Thu, 17 Jan 2002 07:56:02 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 QQlydz12076
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 07:55:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlydz01090
	for <mpls@UU.NET>; Thu, 17 Jan 2002 07:55:46 GMT
From: sven.van_den_bosch@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 QQlydz14194
	for <mpls@UU.NET>; Thu, 17 Jan 2002 07:55:45 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0H7tVp02791;
	Thu, 17 Jan 2002 08:55:32 +0100 (MET)
Subject: RE: Explicit Loose Path Computation
To: "Abarbanel, Benjamin" <Benjamin.Abarbanel@Marconi.com>
Cc: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>,
        "Charlap, David" <David.Charlap@Marconi.com>,
        "'Snigdho Bardalai'" <sbardalai@yahoo.com>, mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF1EC8D6EB.1850452B-ONC1256B44.002ADAE8@net.alcatel.be>
Date: Thu, 17 Jan 2002 08:55:00 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/17/2002 08:55:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Ben,

Thanks for your comment. Would you care to expand on this a little bit?

>>I also believe that CSPF is a more efficient way to compute an ERO that
is
>>constraint
>>than by using a complex signalling mechanism and finding the ERO
Constraint
>>path.

What do you propose to do:
a. use CSPF per area and rely on reachability info to select intermediate
hops
b. use CSPF per area but explicitly specify some hops (maybe the ABRs in
the case of interarea TE). In this case how do you know which ones to
specify?
c. use CSPF and signal "remote" path segments to the computing node that
assembles them to the complete path. This would also require some sort of
(possibly complex) signalling

Sven.





From owner-mpls@UU.NET  Thu Jan 17 11:04:03 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20030
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 11:04:03 -0500 (EST)
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 QQlyfg01027;
	Thu, 17 Jan 2002 16:01:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyfg02148
	for mpls-outgoing; Thu, 17 Jan 2002 16:00: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 QQlyfg02108
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 16:00: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 QQlyfg22662
	for <mpls@uu.net>; Thu, 17 Jan 2002 16:00:42 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyfg00223
	for <mpls@uu.net>; Thu, 17 Jan 2002 16:00: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 LAA06248 for <mpls@uu.net>; Thu, 17 Jan 2002 11:00:41 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14718 for mpls@uu.net; Thu, 17 Jan 2002 11:00:41 -0500 (EST)
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 QQlycs25853
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 16 Jan 2002 23:41: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 QQlycs07193
	for <mpls@uu.net>; Wed, 16 Jan 2002 23:39:19 GMT
Received: from mta008.verizon.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mta008pub.verizon.net [206.46.170.247])
	id QQlycs11765
	for <mpls@uu.net>; Wed, 16 Jan 2002 23:39:19 GMT
Received: from mta008 ([192.168.129.133]) by mta008.verizon.net
          (InterMail vM.5.01.04.02 201-253-122-122-102-20011128) with SMTP
          id <20020116233918.BKNH13950.mta008.verizon.net@mta008>;
          Wed, 16 Jan 2002 17:39:18 -0600
From: Joe Dumont <vze2vf6v@verizon.net>
Reply-To: joe.dumont@verizon.net
To: mpls@UU.NET, ccamp@ops.ietf.org
Subject: Addition to Deletion Proc for GMPLS RSVP
Date: Wed, 16 Jan 2002 17:39:18 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO8859_1
Content-Transfer-Encoding: 7bit
Message-Id: <20020116233918.BKNH13950.mta008.verizon.net@mta008>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I posted this comment a few weeks ago and I have not recevied a response yet.  I have attached the original 
posting:


Hello,

Section 7.2.2 of generalized-rsvp-te-06 does not appear cover the case of an Egress initiated deletion where the ingress node does not support admin status. 

I suggest the following additional wording to be added to the end of section 7.2.2 to clarify this additional error procedure:

"In the case of a non-supporting ingress node, a PathTear may not be returned when an egress node sends a Resv with D and R bits set. To support the case of non-supporting ingress node, the egress SHOULD only wait a configurable period of time for the PathTear message to be returned. Once the period of time has elapsed, the egress node sends a ResvTear message or a PathErr message with Path_state_removed flag set, and normal RSVP takes place. By default for this period SHOULD be 30 seconds."

Regards,

Joe




From owner-mpls@UU.NET  Thu Jan 17 14:05:28 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00592
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 14:05:28 -0500 (EST)
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 QQlyfr13153;
	Thu, 17 Jan 2002 18:59:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyfr11927
	for mpls-outgoing; Thu, 17 Jan 2002 18:59: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 QQlyfr11917
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 18:59: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 QQlyfr00577
	for <mpls@uu.net>; Thu, 17 Jan 2002 18:57:57 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 QQlyfr17225
	for <mpls@uu.net>; Thu, 17 Jan 2002 18:57:56 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 g0HIvn611292;
	Thu, 17 Jan 2002 10:57:49 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200201171857.g0HIvn611292@merlot.juniper.net>
To: sven.van_den_bosch@alcatel.be
cc: mpls@UU.NET
Subject: Re: last call on hierarchy 
In-Reply-To: Your message of "Wed, 16 Jan 2002 12:33:46 +0100."
             <OF809B6E88.45B9028D-ONC1256B43.003E75E1@net.alcatel.be> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2738.1011293868.1@juniper.net>
Date: Thu, 17 Jan 2002 10:57:49 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Sven,

> Hi,
> 
> I would like to clarify two questions regarding the hierarchy draft that is
> currently on last call:
> 
> 1. Dynamic recomputation of the path of the FA-LSP
> 
> If I understand correctly, the path information regarding the FA-LSP is
> made available to other nodes by means of the PATH TLV. 

Correct.

> This information may be used by other nodes for their own path computations. 

Correct.

> They could for instance take it into account when computing a backup path. 

Correct.

> Then if the FA-LSP changes path, primary and backup path of the client 
> LSPs may no longer be disjoint.

Correct.

> My proposal would be to foresee the possibility to restrict the
> reroutability of the FA-LSP and advertise this in the PATH-TLV. In this
> way, nodes that use this information would know whether it is subject to
> change or not.

There may be (at least) two reasons why the FA-LSP gets re-routed:

(1) the current path taken by FA-LSP becomes unfeasible (e.g., one
of the links along the path went down)

(2) there is a "better" path, so FA-LSP is re-routed as part of
optimization.
  
Do you want to restrict re-routability in both cases ? Or only
in the second one ?

> 2. Automatic setup of FA-LSP
> 
> The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets up
> a new FA-LSP.  That is, it initiates a new LSP setup just for the FA-LSP."
> I would like to clarify what happens when two FA-LSPs exist that, when
> concatenated, can replace the new FA-LSP that is proposed to be set up in
> the quoted text.
> 
> I would propose to say that the LSR may set up a new FA-LSP or
> alternatively, it may replace the hop by a sequence of hops for which FAs
> are available.

that would be ok, *provided* that the the strict hop subsequence 
from the ERO carried by the new LSP matches the one resulted from
the concatenation of several FA-LSPs. Agreed ? 

Yakov.


From owner-mpls@UU.NET  Thu Jan 17 16:34:35 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13648
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 16:34:35 -0500 (EST)
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 QQlygc18566;
	Thu, 17 Jan 2002 21:31:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlygc25590
	for mpls-outgoing; Thu, 17 Jan 2002 21:31: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 QQlygc25579
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 17 Jan 2002 21:31: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 QQlygc13649
	for <mpls@UU.NET>; Thu, 17 Jan 2002 21:30:07 GMT
Received: from hopper.math.uwaterloo.ca by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hopper.math.uwaterloo.ca [129.97.78.132])
	id QQlygc27068
	for <mpls@UU.NET>; Thu, 17 Jan 2002 21:30:07 GMT
Received: from localhost (wwszeto@localhost)
	by hopper.math.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id QAA13580
	for <mpls@UU.NET>; Thu, 17 Jan 2002 16:30:02 -0500 (EST)
Date: Thu, 17 Jan 2002 16:30:01 -0500 (EST)
From: "Wayne W. Szeto" <wwszeto@hopper.math.uwaterloo.ca>
To: mpls@UU.NET
Subject: mpls-router emulators?
In-Reply-To: <20020116233918.BKNH13950.mta008.verizon.net@mta008>
Message-ID: <Pine.SOL.4.05.10201171623450.11242-100000@hopper.math.uwaterloo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
Does anyone if there exists any implementation on mpls-router emulator?
I'm aware of two seperate mpls implementations on linux (one at
sourceforge and another one at Cambridge), but I'm looking for a router
emulator (e.g. a unix process acting as a router that accepts and
processes real ip/mpls packets).  I'm also interested to know any ip
router emulators that can be modified to become mpls-enabled. Thanks for
any help.

-ws



From owner-mpls@UU.NET  Thu Jan 17 22:24:32 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19647
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 22:24:31 -0500 (EST)
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 QQlygz21557;
	Fri, 18 Jan 2002 03:23:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlygz24919
	for mpls-outgoing; Fri, 18 Jan 2002 03:23: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 QQlygz24914
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 03:23:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlygz11342
	for <mpls@uu.net>; Fri, 18 Jan 2002 03:23:10 GMT
From: John.Brennen@marconi.com
Received: from hegel.dc.fore.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [169.144.136.143])
	id QQlygz20013
	for <mpls@uu.net>; Fri, 18 Jan 2002 03:23:09 GMT
Received: (from jbrennen@localhost)
	by hegel.dc.fore.com (8.11.6/8.11.1) id g0I3NK813388
	for mpls@uu.net; Thu, 17 Jan 2002 22:23:20 -0500 (EST)
	(envelope-from John.Brennen@marconi.com)
Date: Thu, 17 Jan 2002 22:23:20 -0500 (EST)
Message-Id: <200201180323.g0I3NK813388@hegel.dc.fore.com>
X-Authentication-Warning: hegel.dc.fore.com: jbrennen set sender to John.Brennen@marconi.com using -f
To: mpls@UU.NET
Subject: LDP protocol problem?
Sender: owner-mpls@UU.NET
Precedence: bulk

I think I have found a serious protocol problem in LDP (RFC 3036).
The best way to describe it is to give an example...


Consider the following set of events, in chronological order
 (all messages refer to the same FEC/Label pairing; the session
 supports unsolicited label mappings; and Router B is using
 conservative label retention):


  Router A                          Router B
  --------                          --------

  Sends Label Mapping
                                    Receives Label Mapping
                                    Sends Label Release
                                     (because Router A is not the next hop)
  Sends Label Mapping
   (because the hop count changed)
                                    Router A becomes the next hop
  Receives Label Release
                                    Receives Label Mapping


The problem here is that the Label Mapping message which updates the
hop count and the Label Release message are sent more or less
simultaneously.

The result in the scenario above is that Router A thinks that there is no
valid Label Mapping advertised to Router B.  Router B thinks that it
has a valid Label Mapping.

At least three problems can come from this.  First, Router B can put traffic
onto a label which Router A has reused for another purpose.

Second, Router A may try to readvertise the FEC in the future.
Router B will not accept any such Label Mappings (LMp.10, Appendix A,
RFC 3036), unless Router A is fortunate enough to use the same
label which was originally used.

Third, if Router B tries to release the label, Router A may
report an error.


Is this analysis correct?  Is this a real problem with the protocol?
If so, is it already known?  How can this problem be solved?

    Jack Brennen


From owner-mpls@UU.NET  Thu Jan 17 23:58:59 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22680
	for <mpls-archive@lists.ietf.org>; Thu, 17 Jan 2002 23:58:59 -0500 (EST)
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 QQlyhf24994;
	Fri, 18 Jan 2002 04:58:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhf21625
	for mpls-outgoing; Fri, 18 Jan 2002 04:57: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 QQlyhf21620
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 04:57: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 QQlyhf26149
	for <mpls@uu.net>; Fri, 18 Jan 2002 04:57:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyhf10974
	for <mpls@uu.net>; Fri, 18 Jan 2002 04:57:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA14163 for <mpls@uu.net>; Thu, 17 Jan 2002 23:57:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA17865 for mpls@uu.net; Thu, 17 Jan 2002 23:57:01 -0500 (EST)
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 QQlyhf21588
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 04:56:26 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 QQlyhf22882
	for <mpls@uu.net>; Fri, 18 Jan 2002 04:54:50 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlyhf16074
	for <mpls@uu.net>; Fri, 18 Jan 2002 04:54:49 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT6ADMQ>; Fri, 18 Jan 2002 10:16:21 +0530
Message-ID: <D11B30C7348BD511A40700010283497B40E2D1@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: John.Brennen@marconi.com
Cc: mpls@UU.NET
Subject: RE: LDP protocol problem?
Date: Fri, 18 Jan 2002 10:22:53 +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 faced a similar problem some time back

I think the problem comes because of the configuration of the LDP label
distribution mode, control mode and Request mode.

Particularly here the request node is REQUEST_NEVER though the distribution
mode is DuS. If router B were 'Request When Needed' then it would have
requested A for a label when A becomes its next Hop then the problem would
have been overcome by A sending the mapping again after receiving the
request. I wonder if DuS Ind control with 'Request Never' is not a good
configuration choice

Please correct me if I am wrong.

Regards,
Vijay

-----Original Message-----
From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
Sent: Friday, January 18, 2002 8:53 AM
To: mpls@UU.NET
Subject: LDP protocol problem?


I think I have found a serious protocol problem in LDP (RFC 3036).
The best way to describe it is to give an example...


Consider the following set of events, in chronological order
 (all messages refer to the same FEC/Label pairing; the session
 supports unsolicited label mappings; and Router B is using
 conservative label retention):


  Router A                          Router B
  --------                          --------

  Sends Label Mapping
                                    Receives Label Mapping
                                    Sends Label Release
                                     (because Router A is not the next hop)
  Sends Label Mapping
   (because the hop count changed)
                                    Router A becomes the next hop
  Receives Label Release
                                    Receives Label Mapping


The problem here is that the Label Mapping message which updates the
hop count and the Label Release message are sent more or less
simultaneously.

The result in the scenario above is that Router A thinks that there is no
valid Label Mapping advertised to Router B.  Router B thinks that it
has a valid Label Mapping.

At least three problems can come from this.  First, Router B can put traffic
onto a label which Router A has reused for another purpose.

Second, Router A may try to readvertise the FEC in the future.
Router B will not accept any such Label Mappings (LMp.10, Appendix A,
RFC 3036), unless Router A is fortunate enough to use the same
label which was originally used.

Third, if Router B tries to release the label, Router A may
report an error.


Is this analysis correct?  Is this a real problem with the protocol?
If so, is it already known?  How can this problem be solved?

    Jack Brennen



From owner-mpls@UU.NET  Fri Jan 18 00:16:02 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22853
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 00:16:02 -0500 (EST)
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 QQlyhg13241;
	Fri, 18 Jan 2002 05:14:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhg12864
	for mpls-outgoing; Fri, 18 Jan 2002 05:14: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 QQlyhg12856
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 05:14: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 QQlyhg09295
	for <mpls@UU.NET>; Fri, 18 Jan 2002 05:12:53 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlyhg18730
	for <mpls@UU.NET>; Fri, 18 Jan 2002 05:12:46 GMT
Received: from abhay ([192.168.1.126])
	by multitech.co.in (8.12.1/8.12.1) with SMTP id g0I55Hxf020352;
	Fri, 18 Jan 2002 10:35:17 +0530
Message-ID: <002101c19fdf$beb76d20$7e01a8c0@multitech.co.in>
From: "abhay" <abhay@multitech.co.in>
To: "Snigdho Bardalai" <sbardalai@yahoo.com>, <mpls@UU.NET>
References: <20020116152440.7452.qmail@web14903.mail.yahoo.com>
Subject: Re: Explicit Loose Path Computation
Date: Fri, 18 Jan 2002 10:49:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C1A00D.D8467640"
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

This is a multi-part message in MIME format.

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



Hi Bardalai,
                All route calculation algorithms if specified with a =
loose hop will find a explicit route
                The( Constraint or Rule) Being: The Loose Hop should be =
there in the explicit route.
                Regards,
                Abhay
   =20
----- Original Message -----=20
From: Snigdho Bardalai <sbardalai@yahoo.com>
To: <mpls@UU.NET>
Sent: Wednesday, January 16, 2002 8:54 PM
Subject: RE: Explicit Loose Path Computation


> My question may have been a little confusing -
> actually the algorithm should generate an explicit
> path based on loose route constraint specification.
>=20
> Snigdho
>=20
> Snigdho Bardalai wrote:
> >=20
> > I wanted to find out if anybody has come across an
> > algorithm to compute an explicit loose path.
>=20
> IMO, it seems rather pointless.  If you have enough
> routing information
> available to automatically compute an ERO, why
> wouldn't you want to
> compute a strict ERO?
>=20
> IMO, loose EROs are best used only by manual-creation,
> where a human
> operator can specify certain key nodes, knowing that
> the topology of the
> intervening nodes may change over time.  But any
> software that
> auto-generates these EROs should also be capable of
> dynamically
> recomputing those EROs as the topology changes,
> meaning that there is no
> real need for loose nodes.
>=20
> At least this is my opinion.
>=20
> -- David
>=20
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/

------=_NextPart_000_001E_01C1A00D.D8467640
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>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Bardalai,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; All route calculation algorithms =
if=20
specified with a loose hop will find a explicit route</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;=20
The( Constraint or Rule) Being: The Loose Hop should be there in the =
explicit=20
route.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Abhay</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: Snigdho Bardalai &lt;<A=20
href=3D"mailto:sbardalai@yahoo.com">sbardalai@yahoo.com</A>&gt;</FONT></D=
IV>
<DIV><FONT face=3DArial size=3D2>To: &lt;<A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Wednesday, January 16, 2002 8:54=20
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: RE: Explicit Loose Path=20
Computation</FONT></DIV></DIV>
<DIV><BR></DIV><FONT size=3D2><FONT face=3DArial>&gt; My question may =
have been a=20
little confusing -<BR>&gt; actually the algorithm should generate an=20
explicit<BR>&gt; path based on loose route constraint =
specification.<BR>&gt;=20
<BR>&gt; Snigdho<BR>&gt; <BR>&gt; Snigdho Bardalai wrote:<BR>&gt; &gt; =
<BR>&gt;=20
&gt; I wanted to find out if anybody has come across an<BR>&gt; &gt; =
algorithm=20
to compute an explicit loose path.<BR>&gt; <BR>&gt; IMO, it seems rather =

pointless.&nbsp; If you have enough<BR>&gt; routing information<BR>&gt;=20
available to automatically compute an ERO, why<BR>&gt; wouldn't you want =

to<BR>&gt; compute a strict ERO?<BR>&gt; <BR>&gt; IMO, loose EROs are =
best used=20
only by manual-creation,<BR>&gt; where a human<BR>&gt; operator can =
specify=20
certain key nodes, knowing that<BR>&gt; the topology of the<BR>&gt; =
intervening=20
nodes may change over time.&nbsp; But any<BR>&gt; software that<BR>&gt;=20
auto-generates these EROs should also be capable of<BR>&gt; =
dynamically<BR>&gt;=20
recomputing those EROs as the topology changes,<BR>&gt; meaning that =
there is=20
no<BR>&gt; real need for loose nodes.<BR>&gt; <BR>&gt; At least this is =
my=20
opinion.<BR>&gt; <BR>&gt; -- David<BR>&gt; <BR>&gt;=20
__________________________________________________<BR>&gt; Do You=20
Yahoo!?<BR>&gt; Send FREE video emails in Yahoo! Mail!<BR>&gt; <A=20
href=3D"http://promo.yahoo.com/videomail/">http://promo.yahoo.com/videoma=
il/</A></FONT></FONT></BODY></HTML>

------=_NextPart_000_001E_01C1A00D.D8467640--



From owner-mpls@UU.NET  Fri Jan 18 00:19:08 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22885
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 00:19:08 -0500 (EST)
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 QQlyhh18923;
	Fri, 18 Jan 2002 05:18:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhh13239
	for mpls-outgoing; Fri, 18 Jan 2002 05:18:08 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlyhh13234
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 05:18:04 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 QQlyhh09460
	for <mpls@UU.NET>; Fri, 18 Jan 2002 05:17:53 GMT
Received: from mailhost.iitb.ac.in by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlyhh16463
	for <mpls@UU.NET>; Fri, 18 Jan 2002 05:17:52 GMT
Received: (qmail 30600 invoked from network); 18 Jan 2002 04:58:41 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 18 Jan 2002 04:58:41 -0000
Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121])
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id KAA04358;
	Fri, 18 Jan 2002 10:45:10 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id KAA16277;
	Fri, 18 Jan 2002 10:54:03 +0530
X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Fri, 18 Jan 2002 10:54:03 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: <John.Brennen@marconi.com>
cc: <mpls@UU.NET>
Subject: Re: LDP protocol problem?
In-Reply-To: <200201180323.g0I3NK813388@hegel.dc.fore.com>
Message-ID: <Pine.LNX.4.30.0201181037170.13488-100000@bharati.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

John.Brennen@marconi.com wrote :

>  Router A                          Router B
>  --------                          --------
>
>  Sends Label Mapping
>                                    Receives Label Mapping
>                                    Sends Label Release
>                                     (because Router A is not the next hop)
>  Sends Label Mapping
>   (because the hop count changed)
>                                    Router A becomes the next hop
>  Receives Label Release
>                                    Receives Label Mapping
>
>
>The problem here is that the Label Mapping message which updates the
>hop count and the Label Release message are sent more or less
>simultaneously.

Actually, the problem _may_ not arise, because if you read the note 1. At
the end of process release message (LRl.), it takes care of the scenario
when LSR A is in DU mode and B releases the mapping sent by A. In that
case, A should not send a mapping to lsr B, unless B explicitely requests
it. (Which B would indeed do, unless it is request never.) Well at the
most one can say this is inefficient behavior and not incorrect behavior.
At most what can happen is for that FEC, an LSP can never be created.

However if PHP is used with unsolicited mapping, interesting scenarios can
occur. (This occured to me quite recently)

eg.

Consider

A -- B -- C

(A, B, C tail of some LSP) And when session becomes operational between
LSR A and LSR B, but there exists no session between B and C, B will send
Implicit Null label for some FECs, which it thinks it is egressing.
However, when a session is operational with LSR C, C will egress those
FECs and will send implicit Null labels, which would result in a lot of
withdraw-release and mapping messages between B and A. Also, B has to
install correct bindings in the LIB. Is it ingeneral a good/bad idea to
use PHP when sending DU labels?

Things will not be so bad in case of DoD, because B will send Implicit
Null labels for FECs requested by A only, which _could_ be substantially
less than the ones B sends unsolicitedly.


-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.




From owner-mpls@UU.NET  Fri Jan 18 00:52:57 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23427
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 00:52:57 -0500 (EST)
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 QQlyhj10774;
	Fri, 18 Jan 2002 05:52:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhj15833
	for mpls-outgoing; Fri, 18 Jan 2002 05: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 QQlyhj15828
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 05:51:48 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 QQlyhj11395
	for <mpls@uu.net>; Fri, 18 Jan 2002 05:50:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyhj06292
	for <mpls@uu.net>; Fri, 18 Jan 2002 05:50:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA18332 for <mpls@uu.net>; Fri, 18 Jan 2002 00:50:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA20852 for mpls@uu.net; Fri, 18 Jan 2002 00:50:01 -0500 (EST)
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 QQlyhj15647
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 05:49:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlyhj10763
	for <mpls@uu.net>; Fri, 18 Jan 2002 05:48:46 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlyhj05777
	for <mpls@uu.net>; Fri, 18 Jan 2002 05:48:45 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT6A1D7>; Fri, 18 Jan 2002 11:10:18 +0530
Message-ID: <D11B30C7348BD511A40700010283497B40E421@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
Cc: mpls@UU.NET
Subject: RE: LDP protocol problem?
Date: Fri, 18 Jan 2002 11:16:50 +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

One more point I can think of is - the retention mode . Is it OK to have
Conservative retention mode when operating in DuS Ind Req Never
configuration. Should'nt the rethention and request modes be complementary
so that this kind of situations can be avoided.


Regards,
Vijay

-----Original Message-----
From: Abhijit Gadgil [mailto:gabhijit@ee.iitb.ac.in]
Sent: Friday, January 18, 2002 10:54 AM
To: John.Brennen@marconi.com
Cc: mpls@UU.NET
Subject: Re: LDP protocol problem?


John.Brennen@marconi.com wrote :

>  Router A                          Router B
>  --------                          --------
>
>  Sends Label Mapping
>                                    Receives Label Mapping
>                                    Sends Label Release
>                                     (because Router A is not the next hop)
>  Sends Label Mapping
>   (because the hop count changed)
>                                    Router A becomes the next hop
>  Receives Label Release
>                                    Receives Label Mapping
>
>
>The problem here is that the Label Mapping message which updates the
>hop count and the Label Release message are sent more or less
>simultaneously.

Actually, the problem _may_ not arise, because if you read the note 1. At
the end of process release message (LRl.), it takes care of the scenario
when LSR A is in DU mode and B releases the mapping sent by A. In that
case, A should not send a mapping to lsr B, unless B explicitely requests
it. (Which B would indeed do, unless it is request never.) Well at the
most one can say this is inefficient behavior and not incorrect behavior.
At most what can happen is for that FEC, an LSP can never be created.

However if PHP is used with unsolicited mapping, interesting scenarios can
occur. (This occured to me quite recently)

eg.

Consider

A -- B -- C

(A, B, C tail of some LSP) And when session becomes operational between
LSR A and LSR B, but there exists no session between B and C, B will send
Implicit Null label for some FECs, which it thinks it is egressing.
However, when a session is operational with LSR C, C will egress those
FECs and will send implicit Null labels, which would result in a lot of
withdraw-release and mapping messages between B and A. Also, B has to
install correct bindings in the LIB. Is it ingeneral a good/bad idea to
use PHP when sending DU labels?

Things will not be so bad in case of DoD, because B will send Implicit
Null labels for FECs requested by A only, which _could_ be substantially
less than the ones B sends unsolicitedly.


-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.



From owner-mpls@UU.NET  Fri Jan 18 01:40:54 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23852
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 01:40:54 -0500 (EST)
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 QQlyhm20778;
	Fri, 18 Jan 2002 06:39:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhm09202
	for mpls-outgoing; Fri, 18 Jan 2002 06:39: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 QQlyhm09191
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 06: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 QQlyhm24815
	for <mpls@UU.NET>; Fri, 18 Jan 2002 06:39:20 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlyhm20264
	for <mpls@UU.NET>; Fri, 18 Jan 2002 06:39:16 GMT
Received: from abhay ([192.168.1.126])
	by multitech.co.in (8.12.1/8.12.1) with SMTP id g0I6Vaxf024802;
	Fri, 18 Jan 2002 12:01:39 +0530
Message-ID: <001b01c19feb$d19f6620$7e01a8c0@multitech.co.in>
From: "abhay" <abhay@multitech.co.in>
To: "Tricci So" <tso@caspiannetworks.com>
Cc: <mpls@UU.NET>
References: <65256B3F.00388C46.00@sandesh.hss.hns.com> <3C4240E6.7C7F7AB2@caspiannetworks.com>
Subject: Re: regarding how to ethernet identifies mpls packet.?
Date: Fri, 18 Jan 2002 12:16:06 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0018_01C1A019.E7BE00A0"
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

This is a multi-part message in MIME format.

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

Hi Tricci,
            Let the routing module know about mpls interfaces
            Got the catch ?
            Regards,
            Abhay


----- Original Message -----=20
From: Tricci So <tso@caspiannetworks.com>
Cc: <mpls@UU.NET>
Sent: Monday, January 14, 2002 7:52 AM
Subject: Re: regarding how to ethernet identifies mpls packet.?


> As far as I know, the only way to encapsulate Ethernet over MPLS is to =
refer to the
> Martini draft (see draft-martini-l2circuit-encap-mpls-xx.txt).  There =
is no such
> thing as  protocol type in MPLS to identify the encapsulated packet is =
Ethernet.
> You need to configure or to signal the info for the associated MPLS =
i/f.
>=20
> Tricci
>=20
> mvsjetti@hss.hns.com wrote:
>=20
> > hi,
> >  i am working on MPLS over ethernet .
> > i had gone through the draft    "draft-jagd-mpls-mcast-eth-00.txt"  =
.
> >
> > i was able to get the information on how ethernet identifies mpls =
packet  when
> > it
> > receives a packet form layers below it .(physical layer)
> > (i.e from the standard ethernet type values for MPLS mulicast and
> > unicast values 0x8847 & ox8848 in ethernet header)
> >
> > But when ethernet receives a packet from upper layer(i.e MPLS layer) =
how can
> > it know that it had received from MPLS layer? is there any standard =
method?
> > For example in BSD when ethernet receives a packet form IP it =
compares the
> > address family of destination with AF_INET and determines whether it =
received
> > packet from
> > IP or not ?  Similarly is there any address family  AF_MPLS defined =
for MPLS? if
> > not defined
> > then how can ethernet identify that it had recived packet from MPLS?
> >
> > can anyone  help me out in this issue?
> >
> > thanks in advance
> >
> > mahesh
> >
> > Hughes Software Systems

------=_NextPart_000_0018_01C1A019.E7BE00A0
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>
<DIV><FONT face=3DArial size=3D2>Hi Tricci,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Let=20
the routing module know about mpls interfaces</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Got the catch ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Abhay</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DArial size=3D2>From: Tricci So &lt;<A=20
href=3D"mailto:tso@caspiannetworks.com">tso@caspiannetworks.com</A>&gt;</=
FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Cc: &lt;<A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Monday, January 14, 2002 7:52 =
AM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: Re: regarding how to ethernet =
identifies=20
mpls packet.?</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3DArial size=3D2>&gt; As far as I know, the =
only way to=20
encapsulate Ethernet over MPLS is to refer to the<BR>&gt; Martini draft =
(see=20
draft-martini-l2circuit-encap-mpls-xx.txt).&nbsp; There is no =
such<BR>&gt; thing=20
as&nbsp; protocol type in MPLS to identify the encapsulated packet is=20
Ethernet.<BR>&gt; You need to configure or to signal the info for the =
associated=20
MPLS i/f.<BR>&gt; <BR>&gt; Tricci<BR>&gt; <BR>&gt; <A=20
href=3D"mailto:mvsjetti@hss.hns.com">mvsjetti@hss.hns.com</A> =
wrote:<BR>&gt;=20
<BR>&gt; &gt; hi,<BR>&gt; &gt;&nbsp; i am working on MPLS over ethernet=20
.<BR>&gt; &gt; i had gone through the draft&nbsp;&nbsp;&nbsp;=20
"draft-jagd-mpls-mcast-eth-00.txt"&nbsp; .<BR>&gt; &gt;<BR>&gt; &gt; i =
was able=20
to get the information on how ethernet identifies mpls packet&nbsp; =
when<BR>&gt;=20
&gt; it<BR>&gt; &gt; receives a packet form layers below it .(physical=20
layer)<BR>&gt; &gt; (i.e from the standard ethernet type values for MPLS =

mulicast and<BR>&gt; &gt; unicast values 0x8847 &amp; ox8848 in ethernet =

header)<BR>&gt; &gt;<BR>&gt; &gt; But when ethernet receives a packet =
from upper=20
layer(i.e MPLS layer) how can<BR>&gt; &gt; it know that it had received =
from=20
MPLS layer? is there any standard method?<BR>&gt; &gt; For example in =
BSD when=20
ethernet receives a packet form IP it compares the<BR>&gt; &gt; address =
family=20
of destination with AF_INET and determines whether it received<BR>&gt; =
&gt;=20
packet from<BR>&gt; &gt; IP or not ?&nbsp; Similarly is there any =
address=20
family&nbsp; AF_MPLS defined for MPLS? if<BR>&gt; &gt; not =
defined<BR>&gt; &gt;=20
then how can ethernet identify that it had recived packet from =
MPLS?<BR>&gt;=20
&gt;<BR>&gt; &gt; can anyone&nbsp; help me out in this issue?<BR>&gt;=20
&gt;<BR>&gt; &gt; thanks in advance<BR>&gt; &gt;<BR>&gt; &gt; =
mahesh<BR>&gt;=20
&gt;<BR>&gt; &gt; Hughes Software Systems</FONT></BODY></HTML>

------=_NextPart_000_0018_01C1A019.E7BE00A0--



From owner-mpls@UU.NET  Fri Jan 18 02:18:34 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02698
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 02:18:34 -0500 (EST)
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 QQlyhp15101;
	Fri, 18 Jan 2002 07:17:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhp02097
	for mpls-outgoing; Fri, 18 Jan 2002 07:17: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 QQlyhp02092
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 07:17: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 QQlyhp12300
	for <mpls@uu.net>; Fri, 18 Jan 2002 07:16:38 GMT
From: John.Brennen@marconi.com
Received: from hegel.dc.fore.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [169.144.136.143])
	id QQlyhp13720
	for <mpls@uu.net>; Fri, 18 Jan 2002 07:16:37 GMT
Received: (from jbrennen@localhost)
	by hegel.dc.fore.com (8.11.6/8.11.1) id g0I7Gnr13669
	for mpls@uu.net; Fri, 18 Jan 2002 02:16:49 -0500 (EST)
	(envelope-from John.Brennen@marconi.com)
Date: Fri, 18 Jan 2002 02:16:49 -0500 (EST)
Message-Id: <200201180716.g0I7Gnr13669@hegel.dc.fore.com>
X-Authentication-Warning: hegel.dc.fore.com: jbrennen set sender to John.Brennen@marconi.com using -f
To: mpls@UU.NET
Subject: Re: LDP protocol problem?
Sender: owner-mpls@UU.NET
Precedence: bulk

Vijay wrote:
>I faced a similar problem some time back
>
>I think the problem comes because of the configuration of the LDP label
>distribution mode, control mode and Request mode.
>
>Particularly here the request node is REQUEST_NEVER though the distribution
>mode is DuS. If router B were 'Request When Needed' then it would have
>requested A for a label when A becomes its next Hop then the problem would
>have been overcome by A sending the mapping again after receiving the
>request. I wonder if DuS Ind control with 'Request Never' is not a good
>configuration choice
>
>Please correct me if I am wrong.

The problem also manifests itself if the session is
"Request-when-Needed" and "Downstream-on-Demand."  Example:

  Router A                          Router B
  --------                          --------

                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Request
  Sends Label Mapping (Label 1)
                                    Router A becomes NOT the next hop
                                    Sends Label Abort Request
  Receives Label Abort Request
   (which is ignored)
                                    Receives Label Mapping (Label 1)
                                    Sends Label Release (Label 1)
                                     (because Router A is not the next hop)
  Sends Label Mapping (Label 1)
   (because the hop count changed)
                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Release (Label 1)
                                    Receives Label Mapping (Label 1)
  Receives Label Request
  Sends Label Mapping (Label 2)
                                    Receives Label Mapping (Label 2)
                                    Sends Label Release (Label 2)
  Receives Label Release (Label 2)

The final outcome is the same.  Router B believes that a
Label Mapping exists; Router A believes that no Label Mapping exists.

The problem seems independent of distribution, control, or retention
modes.  The crux of the problem is that when Router A sends a
Label Mapping message which is an "update" message (the same FEC
and Label as a previous message, usually sent to change the
hop count and/or path vector) and then subsequently receives a
Label Release message for that FEC and Label, one of two
situations can exist:

  * If Router B sent the Label Release after receiving the
    "update" message, then Router B is not keeping the label

  * If Router B sent the Label Release before receiving the
    "update" message, then Router B may in fact keep the
    label if his situation changed between sending the
    Label Release and receiving the "update" message.
    (The most likely reason for the situation to change
    would be Router A becoming the next hop for the FEC.)

Router A simply cannot reliably determine which of these
two situations exists on Router B.



From owner-mpls@UU.NET  Fri Jan 18 03:35:50 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04012
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 03:35:50 -0500 (EST)
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 QQlyhu21885;
	Fri, 18 Jan 2002 08:35:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyhu27639
	for mpls-outgoing; Fri, 18 Jan 2002 08:34: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 QQlyhu27628
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 08:34: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 QQlyhu23564
	for <mpls@uu.net>; Fri, 18 Jan 2002 08:34:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyhu20235
	for <mpls@uu.net>; Fri, 18 Jan 2002 08:34:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA26344 for <mpls@uu.net>; Fri, 18 Jan 2002 03:34:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA28405 for mpls@uu.net; Fri, 18 Jan 2002 03:34:02 -0500 (EST)
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 QQlyhu27597
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 08:33: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 QQlyhu15498
	for <mpls@UU.NET>; Fri, 18 Jan 2002 08:33:19 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlyhu05773
	for <mpls@UU.NET>; Fri, 18 Jan 2002 08:33:18 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT6AF0C>; Fri, 18 Jan 2002 13:54:50 +0530
Message-ID: <D11B30C7348BD511A40700010283497B40E50E@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: John.Brennen@marconi.com, mpls@UU.NET
Subject: RE: LDP protocol problem?
Date: Fri, 18 Jan 2002 14:01:22 +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 think the problem is - the release message has no ACK. If the Upstream
waits for a Rel-ACK(in Notification or otherwise) before issuing a new
request for the same FEC to the same downstream and the Upstream when
receiving the mapping 'update' drops it if it were waiting for the Rel-ACK
then the problem would have been avoided. 

A related  problem occurs in CR LDP local repair(ref
:http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
request arrives earlier than the release.

Please correct me if I am wrong

Regards,
Vijay

-----Original Message-----
From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
Sent: Friday, January 18, 2002 12:47 PM
To: mpls@UU.NET
Subject: Re: LDP protocol problem?


Vijay wrote:
>I faced a similar problem some time back
>
>I think the problem comes because of the configuration of the LDP label
>distribution mode, control mode and Request mode.
>
>Particularly here the request node is REQUEST_NEVER though the distribution
>mode is DuS. If router B were 'Request When Needed' then it would have
>requested A for a label when A becomes its next Hop then the problem would
>have been overcome by A sending the mapping again after receiving the
>request. I wonder if DuS Ind control with 'Request Never' is not a good
>configuration choice
>
>Please correct me if I am wrong.

The problem also manifests itself if the session is
"Request-when-Needed" and "Downstream-on-Demand."  Example:

  Router A                          Router B
  --------                          --------

                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Request
  Sends Label Mapping (Label 1)
                                    Router A becomes NOT the next hop
                                    Sends Label Abort Request
  Receives Label Abort Request
   (which is ignored)
                                    Receives Label Mapping (Label 1)
                                    Sends Label Release (Label 1)
                                     (because Router A is not the next hop)
  Sends Label Mapping (Label 1)
   (because the hop count changed)
                                    Router A becomes the next hop
                                    Sends Label Request
  Receives Label Release (Label 1)
                                    Receives Label Mapping (Label 1)
  Receives Label Request
  Sends Label Mapping (Label 2)
                                    Receives Label Mapping (Label 2)
                                    Sends Label Release (Label 2)
  Receives Label Release (Label 2)

The final outcome is the same.  Router B believes that a
Label Mapping exists; Router A believes that no Label Mapping exists.

The problem seems independent of distribution, control, or retention
modes.  The crux of the problem is that when Router A sends a
Label Mapping message which is an "update" message (the same FEC
and Label as a previous message, usually sent to change the
hop count and/or path vector) and then subsequently receives a
Label Release message for that FEC and Label, one of two
situations can exist:

  * If Router B sent the Label Release after receiving the
    "update" message, then Router B is not keeping the label

  * If Router B sent the Label Release before receiving the
    "update" message, then Router B may in fact keep the
    label if his situation changed between sending the
    Label Release and receiving the "update" message.
    (The most likely reason for the situation to change
    would be Router A becoming the next hop for the FEC.)

Router A simply cannot reliably determine which of these
two situations exists on Router B.



From owner-mpls@UU.NET  Fri Jan 18 05:53:24 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06063
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 05:53:24 -0500 (EST)
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 QQlyid19755;
	Fri, 18 Jan 2002 10:52:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyid17869
	for mpls-outgoing; Fri, 18 Jan 2002 10:52: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 QQlyid17864
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 10:52:04 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 QQlyid28479
	for <mpls@UU.NET>; Fri, 18 Jan 2002 10:51:19 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlyid16717
	for <mpls@UU.NET>; Fri, 18 Jan 2002 10:51:17 GMT
Received: (qmail 22954 invoked from network); 18 Jan 2002 10:32:03 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 18 Jan 2002 10:32:03 -0000
Received: from gayatri.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121])
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id QAA04659;
	Fri, 18 Jan 2002 16:18:10 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id QAA29825;
	Fri, 18 Jan 2002 16:27:02 +0530
X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Fri, 18 Jan 2002 16:27:01 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: <John.Brennen@marconi.com>
cc: <mpls@UU.NET>
Subject: Re: LDP protocol problem?
In-Reply-To: <200201180716.g0I7Gnr13669@hegel.dc.fore.com>
Message-ID: <Pine.LNX.4.30.0201181623580.26356-100000@gayatri.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

John.Brennen@marconi.com wrote :

>  Router A                          Router B
>  --------                          --------
>
>                                    Router A becomes the next hop
>                                    Sends Label Request
>  Receives Label Request
>  Sends Label Mapping (Label 1)
>                                    Router A becomes NOT the next hop
>                                    Sends Label Abort Request
>  Receives Label Abort Request
>   (which is ignored)
>                                    Receives Label Mapping (Label 1)
>                                    Sends Label Release (Label 1)
>                                     (because Router A is not the next hop)
>  Sends Label Mapping (Label 1)
>   (because the hop count changed)
>                                    Router A becomes the next hop
>                                    Sends Label Request
>  Receives Label Release (Label 1)
>                                    Receives Label Mapping (Label 1)
>  Receives Label Request
>  Sends Label Mapping (Label 2)
>                                    Receives Label Mapping (Label 2)
>                                    Sends Label Release (Label 2)
>  Receives Label Release (Label 2)
>
>The final outcome is the same.  Router B believes that a
>Label Mapping exists; Router A believes that no Label Mapping exists.

Key point missed here is, LRl. 1. and the note at the end of it.

>
>The problem seems independent of distribution, control, or retention
>modes.

Not really, if B is using liberal retention it wont release the mappings
received as soon as next-hop changes.

>Label Mapping message which is an "update" message (the same FEC
>and Label as a previous message, usually sent to change the
>hop count and/or path vector) and then subsequently receives a
>Label Release message for that FEC and Label, one of two
>situations can exist:
>
>  * If Router B sent the Label Release after receiving the
>    "update" message, then Router B is not keeping the label
>
>  * If Router B sent the Label Release before receiving the
>    "update" message, then Router B may in fact keep the
>    label if his situation changed between sending the
>    Label Release and receiving the "update" message.
>    (The most likely reason for the situation to change
>    would be Router A becoming the next hop for the FEC.)
>
>Router A simply cannot reliably determine which of these
>two situations exists on Router B.
>

-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.




From owner-mpls@UU.NET  Fri Jan 18 10:15:38 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14141
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 10:15:38 -0500 (EST)
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 QQlyiu11352;
	Fri, 18 Jan 2002 15:11:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyiu17437
	for mpls-outgoing; Fri, 18 Jan 2002 15:11: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 QQlyiu17432
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 15:11:18 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 QQlyiu29509
	for <mpls@UU.NET>; Fri, 18 Jan 2002 15:09:48 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlyiu07284
	for <mpls@UU.NET>; Fri, 18 Jan 2002 15:09:47 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 KAA18223
	for <mpls@UU.NET>; Fri, 18 Jan 2002 10:09:46 -0500 (EST)
Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13863
	for <mpls@UU.NET>; Fri, 18 Jan 2002 10:09:46 -0500 (EST)
Message-ID: <3C483AD4.76C9E1EF@marconi.com>
Date: Fri, 18 Jan 2002 10:10:12 -0500
From: Jack Brennen <John.Brennen@marconi.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: LDP protocol problem?
References: <Pine.LNX.4.30.0201181623580.26356-100000@gayatri.ee.iitb.ac.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Abhijit Gadgil wrote:
> 
> John.Brennen@marconi.com wrote :
> 
> >  Router A                          Router B
> >  --------                          --------
> >
> >                                    Router A becomes the next hop
> >                                    Sends Label Request
> >  Receives Label Request
> >  Sends Label Mapping (Label 1)
> >                                    Router A becomes NOT the next hop
> >                                    Sends Label Abort Request
> >  Receives Label Abort Request
> >   (which is ignored)
> >                                    Receives Label Mapping (Label 1)
> >                                    Sends Label Release (Label 1)
> >                                     (because Router A is not the next hop)
> >  Sends Label Mapping (Label 1)
> >   (because the hop count changed)
> >                                    Router A becomes the next hop
> >                                    Sends Label Request
> >  Receives Label Release (Label 1)
> >                                    Receives Label Mapping (Label 1)
> >  Receives Label Request
> >  Sends Label Mapping (Label 2)
> >                                    Receives Label Mapping (Label 2)
> >                                    Sends Label Release (Label 2)
> >  Receives Label Release (Label 2)
> >
> >The final outcome is the same.  Router B believes that a
> >Label Mapping exists; Router A believes that no Label Mapping exists.
> 
> Key point missed here is, LRl. 1. and the note at the end of it.

No, that is not relevant to this problem.  Router A is only
re-advertising the label mapping when it receives a label
request from Router B, just as the Note 1 of LRl.1 specifies.
Note that Router A is sending the "update" Label Mapping before
it sees the Label Release from Router B.

> 
> >
> >The problem seems independent of distribution, control, or retention
> >modes.
> 
> Not really, if B is using liberal retention it wont release the mappings
> received as soon as next-hop changes.
> 

Okay, but Router B may release the first (original) mapping due
to a loop-detection problem, and keep the second (update) mapping
due to the loop-detection problem going away.  It may have nothing
to due with a next-hop change on Router B.

Try this scenario in liberal unsolicited mode:

  Router A                          Router B
  --------                          --------

  Sends Label Mapping
   (Path Vector=<B,C,D,A>)
                                    Receives Label Mapping
  Router A gets a new next hop
   for the FEC
  Sends Label Mapping
   (Path Vector=<E,F,G,A>)
                                    Sends Label Release
                                     (loop detected)
  Receives Label Release
                                    Receives Label Mapping



The specification calls for resending of Label Mapping messages
when the Loop Detection information changes.  These resent messages
look just like first-time Label Mapping messages.  If a resent
Label Mapping message from Router A "crosses on the wire" with a
Label Release message from Router B, we have the unfortunate situation
where Router A thinks that the Label Mapping has been released and
not readvertised, but Router B thinks that the Label Mapping has been
released _and readvertised_.

I can't see how to fix this without changing the specification.
Fortunately, the fix can be easy; simply mark all resent ("update")
Label Mapping messages as such.  Then the receiving router will
never confuse an "update" Label Mapping with a re-advertisement.
If an "update" Label Mapping is received which doesn't correspond
to any currently held label, it is silently ignored.

   Jack Brennen


From owner-mpls@UU.NET  Fri Jan 18 13:56:59 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23309
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 13:56:58 -0500 (EST)
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 QQlyjj19452;
	Fri, 18 Jan 2002 18:56:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjj24518
	for mpls-outgoing; Fri, 18 Jan 2002 18:55:57 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 QQlyjj24512
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 18:55:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlyjj12810
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:54:44 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 QQlyjj04845
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:54:43 GMT
Message-ID: <3C486F6D.68368004@sandburst.com>
Date: Fri, 18 Jan 2002 13:54:37 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: MPLS Mailing List <mpls@UU.NET>
Subject: [Fwd: LDP protocol problem?]
Content-Type: multipart/mixed;
 boundary="------------ED4B9CFB1E4C39ECA9F5B08A"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

oops, meant to send to the list

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray



--------------ED4B9CFB1E4C39ECA9F5B08A
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <3C486B8E.3BD18359@sandburst.com>
Date: Fri, 18 Jan 2002 13:38:06 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
Subject: Re: LDP protocol problem?
References: <D11B30C7348BD511A40700010283497B40E2D1@GAYATRI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vijay,

    Yes.  You should probably stick to the terminology used in the LDP
specification, rather than using the terminology from the Architecture.
There is a mapping, but it does not aid in understanding to have to be
making that mapping several times in just a few short sentences.

    The combination of downstream unsolicited and conservative retention
is not very useful in  general because it results in excessive amounts of
label release messages.  The confusion below should not occur in a good
implementation, but the fact that it can occur in general is attributable
to the use of an unreasonable combination of operating modes.

You wrote:

> I faced a similar problem some time back
>
> I think the problem comes because of the configuration of the LDP label
> distribution mode, control mode and Request mode.
>
> Particularly here the request node is REQUEST_NEVER though the distribution
> mode is DuS. If router B were 'Request When Needed' then it would have
> requested A for a label when A becomes its next Hop then the problem would
> have been overcome by A sending the mapping again after receiving the
> request. I wonder if DuS Ind control with 'Request Never' is not a good
> configuration choice
>
> Please correct me if I am wrong.
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
> Sent: Friday, January 18, 2002 8:53 AM
> To: mpls@UU.NET
> Subject: LDP protocol problem?
>
> I think I have found a serious protocol problem in LDP (RFC 3036).
> The best way to describe it is to give an example...
>
> Consider the following set of events, in chronological order
>  (all messages refer to the same FEC/Label pairing; the session
>  supports unsolicited label mappings; and Router B is using
>  conservative label retention):
>
>   Router A                          Router B
>   --------                          --------
>
>   Sends Label Mapping
>                                     Receives Label Mapping
>                                     Sends Label Release
>                                      (because Router A is not the next hop)
>   Sends Label Mapping
>    (because the hop count changed)
>                                     Router A becomes the next hop
>   Receives Label Release
>                                     Receives Label Mapping
>
> The problem here is that the Label Mapping message which updates the
> hop count and the Label Release message are sent more or less
> simultaneously.
>
> The result in the scenario above is that Router A thinks that there is no
> valid Label Mapping advertised to Router B.  Router B thinks that it
> has a valid Label Mapping.
>
> At least three problems can come from this.  First, Router B can put traffic
> onto a label which Router A has reused for another purpose.
>
> Second, Router A may try to readvertise the FEC in the future.
> Router B will not accept any such Label Mappings (LMp.10, Appendix A,
> RFC 3036), unless Router A is fortunate enough to use the same
> label which was originally used.
>
> Third, if Router B tries to release the label, Router A may
> report an error.
>
> Is this analysis correct?  Is this a real problem with the protocol?
> If so, is it already known?  How can this problem be solved?
>
>     Jack Brennen

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray




--------------ED4B9CFB1E4C39ECA9F5B08A--



From owner-mpls@UU.NET  Fri Jan 18 13:57:51 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23347
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 13:57:51 -0500 (EST)
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 QQlyjj05145;
	Fri, 18 Jan 2002 18:57:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjj24688
	for mpls-outgoing; Fri, 18 Jan 2002 18:57: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 QQlyjj24675
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 18:56: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 QQlyjj03502
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:56:27 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 QQlyjj08233
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:56:27 GMT
Message-ID: <3C486FDA.BDDFB94B@sandburst.com>
Date: Fri, 18 Jan 2002 13:56:26 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
Cc: MPLS Mailing List <mpls@UU.NET>
Subject: Re: LDP protocol problem?
References: <D11B30C7348BD511A40700010283497B40E50E@GAYATRI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vijay,

    I can't support the notion that the Release message needs an ACK.  Recall
that the Release message is itself an ACK to the Withdraw message.  We don't
want to get in the middle of an ACK war...


You wrote:

> I think the problem is - the release message has no ACK. If the Upstream
> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
> request for the same FEC to the same downstream and the Upstream when
> receiving the mapping 'update' drops it if it were waiting for the Rel-ACK
> then the problem would have been avoided.
>
> A related  problem occurs in CR LDP local repair(ref
> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
> request arrives earlier than the release.
>
> Please correct me if I am wrong
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
> Sent: Friday, January 18, 2002 12:47 PM
> To: mpls@UU.NET
> Subject: Re: LDP protocol problem?
>
> Vijay wrote:
> >I faced a similar problem some time back
> >
> >I think the problem comes because of the configuration of the LDP label
> >distribution mode, control mode and Request mode.
> >
> >Particularly here the request node is REQUEST_NEVER though the distribution
> >mode is DuS. If router B were 'Request When Needed' then it would have
> >requested A for a label when A becomes its next Hop then the problem would
> >have been overcome by A sending the mapping again after receiving the
> >request. I wonder if DuS Ind control with 'Request Never' is not a good
> >configuration choice
> >
> >Please correct me if I am wrong.
>
> The problem also manifests itself if the session is
> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>
>   Router A                          Router B
>   --------                          --------
>
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Request
>   Sends Label Mapping (Label 1)
>                                     Router A becomes NOT the next hop
>                                     Sends Label Abort Request
>   Receives Label Abort Request
>    (which is ignored)
>                                     Receives Label Mapping (Label 1)
>                                     Sends Label Release (Label 1)
>                                      (because Router A is not the next hop)
>   Sends Label Mapping (Label 1)
>    (because the hop count changed)
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Release (Label 1)
>                                     Receives Label Mapping (Label 1)
>   Receives Label Request
>   Sends Label Mapping (Label 2)
>                                     Receives Label Mapping (Label 2)
>                                     Sends Label Release (Label 2)
>   Receives Label Release (Label 2)
>
> The final outcome is the same.  Router B believes that a
> Label Mapping exists; Router A believes that no Label Mapping exists.
>
> The problem seems independent of distribution, control, or retention
> modes.  The crux of the problem is that when Router A sends a
> Label Mapping message which is an "update" message (the same FEC
> and Label as a previous message, usually sent to change the
> hop count and/or path vector) and then subsequently receives a
> Label Release message for that FEC and Label, one of two
> situations can exist:
>
>   * If Router B sent the Label Release after receiving the
>     "update" message, then Router B is not keeping the label
>
>   * If Router B sent the Label Release before receiving the
>     "update" message, then Router B may in fact keep the
>     label if his situation changed between sending the
>     Label Release and receiving the "update" message.
>     (The most likely reason for the situation to change
>     would be Router A becoming the next hop for the FEC.)
>
> Router A simply cannot reliably determine which of these
> two situations exists on Router B.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Fri Jan 18 14:00:14 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23421
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 14:00:14 -0500 (EST)
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 QQlyjj03589;
	Fri, 18 Jan 2002 18:56:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjj24561
	for mpls-outgoing; Fri, 18 Jan 2002 18:56:03 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlyjj24513
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 18:55:56 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 QQlyjj11476
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:54:13 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 QQlyjj00221
	for <mpls@UU.NET>; Fri, 18 Jan 2002 18:54:12 GMT
Message-ID: <3C486F53.84ABF819@sandburst.com>
Date: Fri, 18 Jan 2002 13:54:11 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: MPLS Mailing List <mpls@UU.NET>
Subject: [Fwd: LDP protocol problem?]
Content-Type: multipart/mixed;
 boundary="------------D41EC563D1858578F1B0053C"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

oops, meant to send to the list...

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray



--------------D41EC563D1858578F1B0053C
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <3C486F1E.1F06F4D2@sandburst.com>
Date: Fri, 18 Jan 2002 13:53:18 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: John.Brennen@marconi.com
Subject: Re: LDP protocol problem?
References: <200201180716.g0I7Gnr13669@hegel.dc.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John.Brennen@marconi.com wrote:

> Vijay wrote:
> >I faced a similar problem some time back
> >
> >I think the problem comes because of the configuration of the LDP label
> >distribution mode, control mode and Request mode.
> >
> >Particularly here the request node is REQUEST_NEVER though the distribution
> >mode is DuS. If router B were 'Request When Needed' then it would have
> >requested A for a label when A becomes its next Hop then the problem would
> >have been overcome by A sending the mapping again after receiving the
> >request. I wonder if DuS Ind control with 'Request Never' is not a good
> >configuration choice
> >
> >Please correct me if I am wrong.
>
> The problem also manifests itself if the session is
> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>
>   Router A                          Router B
>   --------                          --------
>
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Request
>   Sends Label Mapping (Label 1)
>                                     Router A becomes NOT the next hop
>                                     Sends Label Abort Request
>   Receives Label Abort Request
>    (which is ignored)
>                                     Receives Label Mapping (Label 1)
>                                     Sends Label Release (Label 1)
>                                      (because Router A is not the next hop)
>   Sends Label Mapping (Label 1)
>    (because the hop count changed)
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Release (Label 1)
>                                     Receives Label Mapping (Label 1)
>   Receives Label Request
>   Sends Label Mapping (Label 2)
>                                     Receives Label Mapping (Label 2)
>                                     Sends Label Release (Label 2)

No.  Router B has done a BAD THING.

Label Requests are used as transaction IDs.  In this case,  Router B has abused the
transaction ID concept by using Label 1 (which was received in a Label Mapping
that was not a response to an earlier Label Request - it contains no label request
message ID) as a response to a label request.  It is theoretically possible to do
this, but the router that decides to do this MUST be smart enough to figure out
how to recover from this and other scenarios.  In this scenario, for example, it
is possible for Router B to simply start using Label 2 when it receives it and
release Label 1 at that time.  For Router B to decide to use an unsolicited Label
Mapping as a response for a Label Request is a MYBAD that it has to know
how to fix.

Also, it is most often the case that downstream on demand is used only with
ordered control.  This is because labels received with an unknown hop count
may not be useful since using them may mean that packets are dropped at the
point where the LSP setup is not yet complete.  With ordered control mode,
this scenario is simply not going to come up all that often.

There is always a 'robustness' behavior that is well understood, if not exactly
specified.  If Router A is getting labels it does not know how to handle (it
has no corresponding ILM for these labels), it is a simple matter of software
to realize that it should send a Label Release for those labels to the LSR that
is sending them.

>
>   Receives Label Release (Label 2)
>
> The final outcome is the same.  Router B believes that a
> Label Mapping exists; Router A believes that no Label Mapping exists.
>
> The problem seems independent of distribution, control, or retention
> modes.  The crux of the problem is that when Router A sends a
> Label Mapping message which is an "update" message (the same FEC
> and Label as a previous message, usually sent to change the
> hop count and/or path vector) and then subsequently receives a
> Label Release message for that FEC and Label, one of two
> situations can exist:
>
>   * If Router B sent the Label Release after receiving the
>     "update" message, then Router B is not keeping the label
>
>   * If Router B sent the Label Release before receiving the
>     "update" message, then Router B may in fact keep the
>     label if his situation changed between sending the
>     Label Release and receiving the "update" message.
>     (The most likely reason for the situation to change
>     would be Router A becoming the next hop for the FEC.)
>
> Router A simply cannot reliably determine which of these
> two situations exists on Router B.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray



--------------D41EC563D1858578F1B0053C--



From owner-mpls@UU.NET  Fri Jan 18 14:36:42 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24447
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 14:36:42 -0500 (EST)
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 QQlyjm17600;
	Fri, 18 Jan 2002 19:36:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjm17719
	for mpls-outgoing; Fri, 18 Jan 2002 19:35: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 QQlyjm17712
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 19:35:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlyjm29784
	for <mpls@UU.NET>; Fri, 18 Jan 2002 19:35: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 QQlyjm04408
	for <mpls@UU.NET>; Fri, 18 Jan 2002 19:35:35 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 OAA18664
	for <mpls@UU.NET>; Fri, 18 Jan 2002 14:35:32 -0500 (EST)
Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA21950
	for <mpls@UU.NET>; Fri, 18 Jan 2002 14:35:34 -0500 (EST)
Message-ID: <3C487905.FC637396@marconi.com>
Date: Fri, 18 Jan 2002 14:35:33 -0500
From: Jack Brennen <John.Brennen@marconi.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS Mailing List <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
References: <3C486F53.84ABF819@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 Gray wrote:
> No.  Router B has done a BAD THING.

I won't argue this point, merely because it's not fundamental to my finding
of a possible protocol instability.  The fundamental problem is that an "update"
Label Mapping message can "cross on the wire" with a Label Release message for
the same FEC/Label combination.  It is possible, in several ways, for Router B
to accept the "update" Label Mapping message as if it were a normal unsolicited
Label Mapping, even though it just recently released a Label Mapping for the
same FEC.  Reasons why Router B might do this:

   (1)  The original Label Mapping caused a "loop detection" failure,
        but the "update" Label Mapping did not.
   (2)  Router A was not the next hop when the original Label Mapping
        was processed, but is the next hop when the "update" Label Mapping
        is processed.
   (3)  Router B had no available memory to keep the original Label Mapping,
        but memory became available by the time the "update" Label Mapping
        was processed.

If "update" Label Mapping messages were syntactically different than normal
unsolicited Label Mapping messages, the whole problem could be avoided.  That
is how I would fix the specification if it were my decision.

> There is always a 'robustness' behavior that is well understood, if not exactly
> specified.  If Router A is getting labels it does not know how to handle (it
> has no corresponding ILM for these labels), it is a simple matter of software
> to realize that it should send a Label Release for those labels to the LSR that
> is sending them.

In my examples, Router A thinks that the label has been released by Router B,
so it is free to reassign it to a different FEC -- there may be a corresponding
ILM for the label (on Router A) when Router B actually puts traffic onto it,
in which case Router A won't see anything amiss.

Also, I think you mean that Router A should send a Label Withdraw.  I don't
necessarily agree, but I wouldn't argue too hard against it.

    Jack


From owner-mpls@UU.NET  Fri Jan 18 15:42:07 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26211
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 15:42:07 -0500 (EST)
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 QQlyjq27495;
	Fri, 18 Jan 2002 20:41:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjq12837
	for mpls-outgoing; Fri, 18 Jan 2002 20:41: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 QQlyjq12805
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 20:41: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 QQlyjq20244
	for <mpls@UU.NET>; Fri, 18 Jan 2002 20:40:30 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 QQlyjq25823
	for <mpls@UU.NET>; Fri, 18 Jan 2002 20:40:30 GMT
Message-ID: <3C48883C.173B045@sandburst.com>
Date: Fri, 18 Jan 2002 15:40:29 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Jack Brennen <John.Brennen@marconi.com>
Cc: MPLS Mailing List <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
References: <3C486F53.84ABF819@sandburst.com> <3C487905.FC637396@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jack,

    Yes, I meant Label Withdraw.

    The case where Router A re-issues Label 1, is problematic only for the
time it takes Router B to receive the corresponding Label Mapping.  Once
Router B receives a Label Mapping for a label it already has and a different
FEC, Router B will know that it is screwed up.  It is reasonably well
known that you should not re-use a label you have just removed from service
for some period of time as this is likely to result in miss-routed packets in
any case.  This would be forced in the case where Router A withdraws a label
mapping because Router A cannot then re-use the label until it receives a
Label Release for that label.

    Having a syntactically different messages for the initial and subsequent
update Label Mappings would fix the problem you're describing, but it may
not be necessary.  One simple way to avoid this problem is to treat any label
received unsolicited (when operating in DoD mode) as an update.  If this is
what you do, then you would not end up using any label you did not get as
a result of a Label Request - at least originally.

    I tend to think of DU and Liberal Retention as being a bundled package
and the same for DoD and Conservative Retention.  I told Bob Thomas a
long time ago that - while I think it reasonable for an implementation  to
send Label Requests in DU mode - I do not think it is reasonable for an
implementation to send unsolicited Label Mappings when operating in
the DoD mode.  If it were up to me, in DoD mode, the only Label Mappings
I would not immediately Release would be the ones I asked for and updates
for the ones I asked for.

You wrote:

> Eric Gray wrote:
> > No.  Router B has done a BAD THING.
>
> I won't argue this point, merely because it's not fundamental to my finding
> of a possible protocol instability.  The fundamental problem is that an "update"
> Label Mapping message can "cross on the wire" with a Label Release message for
> the same FEC/Label combination.  It is possible, in several ways, for Router B
> to accept the "update" Label Mapping message as if it were a normal unsolicited
> Label Mapping, even though it just recently released a Label Mapping for the
> same FEC.  Reasons why Router B might do this:
>
>    (1)  The original Label Mapping caused a "loop detection" failure,
>         but the "update" Label Mapping did not.
>    (2)  Router A was not the next hop when the original Label Mapping
>         was processed, but is the next hop when the "update" Label Mapping
>         is processed.
>    (3)  Router B had no available memory to keep the original Label Mapping,
>         but memory became available by the time the "update" Label Mapping
>         was processed.
>
> If "update" Label Mapping messages were syntactically different than normal
> unsolicited Label Mapping messages, the whole problem could be avoided.  That
> is how I would fix the specification if it were my decision.
>
> > There is always a 'robustness' behavior that is well understood, if not exactly
> > specified.  If Router A is getting labels it does not know how to handle (it
> > has no corresponding ILM for these labels), it is a simple matter of software
> > to realize that it should send a Label Release for those labels to the LSR that
> > is sending them.
>
> In my examples, Router A thinks that the label has been released by Router B,
> so it is free to reassign it to a different FEC -- there may be a corresponding
> ILM for the label (on Router A) when Router B actually puts traffic onto it,
> in which case Router A won't see anything amiss.
>
> Also, I think you mean that Router A should send a Label Withdraw.  I don't
> necessarily agree, but I wouldn't argue too hard against it.
>
>     Jack

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Fri Jan 18 16:17:56 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27334
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 16:17:56 -0500 (EST)
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 QQlyjt06498;
	Fri, 18 Jan 2002 21:17:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjt05716
	for mpls-outgoing; Fri, 18 Jan 2002 21:17: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 QQlyjt05709
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 21:16:58 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlyjt17577
	for <mpls@UU.NET>; Fri, 18 Jan 2002 21:16:40 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 QQlyjt07793
	for <mpls@UU.NET>; Fri, 18 Jan 2002 21:16: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 QAA29379
	for <mpls@UU.NET>; Fri, 18 Jan 2002 16:16:37 -0500 (EST)
Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15103
	for <mpls@UU.NET>; Fri, 18 Jan 2002 16:16:39 -0500 (EST)
Message-ID: <3C4890B6.C632B6E4@marconi.com>
Date: Fri, 18 Jan 2002 16:16:38 -0500
From: Jack Brennen <John.Brennen@marconi.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS Mailing List <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
References: <3C486F53.84ABF819@sandburst.com> <3C487905.FC637396@marconi.com> <3C48883C.173B045@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 Gray wrote:
> 
> Jack,
> 
>     Yes, I meant Label Withdraw.
> 
>     The case where Router A re-issues Label 1, is problematic only for the
> time it takes Router B to receive the corresponding Label Mapping.

Yes, I agree.

> Once
> Router B receives a Label Mapping for a label it already has and a different
> FEC, Router B will know that it is screwed up.

Now you have imposed a requirement on Router B to look up a label in its
Label Information Base every time it receives a Label Mapping.  This is expensive
and is not called for in RFC 3036.

Furthermore, LDP explicitly allows a single label to be associated with multiple
FECs.  From 3.5.11.1 (Label Release Message Procedures):

   The FEC TLV may contain the Wildcard FEC Element; if so, it may
   contain no other FEC Elements.  In this case, if the Label Release
   message contains an optional Label TLV, then the label is to be
   released for all FECs to which it is bound.

> It is reasonably well
> known that you should not re-use a label you have just removed from service
> for some period of time as this is likely to result in miss-routed packets in
> any case.

I disagree that this is true from the point of view of Router B; if the downstream
router has advertised a FEC/Label combination, said router is indicating that it is
ready to switch that label now, not at some point in the future.

Your statement is correct from the point of view of Router A; after the last release
for a label is received, Router A should avoid readvertising that label until all
packets in transit have had a chance to clear the network.  But that's not what
my example shows.  Router A is not readvertising a released label, it just looks
that way from Router B's perspective.

> This would be forced in the case where Router A withdraws a label
> mapping because Router A cannot then re-use the label until it receives a
> Label Release for that label.

Correct.  A Label Withdraw message is semantically a request for a release message,
and the label is not actually freed until that Label Release is received.

>     Having a syntactically different messages for the initial and subsequent
> update Label Mappings would fix the problem you're describing, but it may
> not be necessary.  One simple way to avoid this problem is to treat any label
> received unsolicited (when operating in DoD mode) as an update.  If this is
> what you do, then you would not end up using any label you did not get as
> a result of a Label Request - at least originally.

But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:

  Router A                          Router B
  --------                          --------

  Sends Label Mapping
   (Path Vector=<B,C,D,A>)
                                    Receives Label Mapping
  Router A gets a new next hop
   for the FEC
  Sends Label Mapping
   (Path Vector=<E,F,G,A>)
                                    Sends Label Release
                                     (loop detected)
  Receives Label Release
                                    Receives Label Mapping

At the end of this scenario, Router B holds a label which he believes was
validly advertised by Router A.  Router A believes that Router B released
the label.

> 
>     I tend to think of DU and Liberal Retention as being a bundled package
> and the same for DoD and Conservative Retention.

Okay, but RFC 3031 (MPLS Architecture) specifically allows DU & Conservative
to be used together.  See section 5.2.1, scheme 3.

> I told Bob Thomas a
> long time ago that - while I think it reasonable for an implementation  to
> send Label Requests in DU mode - I do not think it is reasonable for an
> implementation to send unsolicited Label Mappings when operating in
> the DoD mode.  If it were up to me, in DoD mode, the only Label Mappings
> I would not immediately Release would be the ones I asked for and updates
> for the ones I asked for.
> 

I agree; if a session is in DoD mode, unsolicited label mappings shouldn't
be sent, and should be released if received.


From owner-mpls@UU.NET  Fri Jan 18 16:52:19 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28506
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 16:52:19 -0500 (EST)
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 QQlyjv07511;
	Fri, 18 Jan 2002 21:51:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyjv08382
	for mpls-outgoing; Fri, 18 Jan 2002 21:51:16 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 QQlyjv08352
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 21:51: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 QQlyjv05325
	for <mpls@UU.NET>; Fri, 18 Jan 2002 21:49:27 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 QQlyjv17088
	for <mpls@UU.NET>; Fri, 18 Jan 2002 21:49:27 GMT
Message-ID: <3C489866.71F7807E@sandburst.com>
Date: Fri, 18 Jan 2002 16:49:26 -0500
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Jack Brennen <John.Brennen@marconi.com>
Cc: MPLS Mailing List <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
References: <3C486F53.84ABF819@sandburst.com> <3C487905.FC637396@marconi.com> <3C48883C.173B045@sandburst.com> <3C4890B6.C632B6E4@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jack,

    Please see below...

You wrote (in part):

> ...
>
> > Once
> > Router B receives a Label Mapping for a label it already has and a different
> > FEC, Router B will know that it is screwed up.
>
> Now you have imposed a requirement on Router B to look up a label in its
> Label Information Base every time it receives a Label Mapping.  This is expensive
> and is not called for in RFC 3036.

It's hard to specify robustness sometimes.  I am sure there are
other ways to know if a label mapping you have received is one
you have previously received and retained then looking it up in
your LIB.  I also seem to recall this being a check in at least
some of the steps in the appendix under receive label mapping.

>
>
> Furthermore, LDP explicitly allows a single label to be associated with multiple
> FECs.  From 3.5.11.1 (Label Release Message Procedures):
>
>    The FEC TLV may contain the Wildcard FEC Element; if so, it may
>    contain no other FEC Elements.  In this case, if the Label Release
>    message contains an optional Label TLV, then the label is to be
>    released for all FECs to which it is bound.

I am pretty sure that you cannot send unsolicited label mappings
for multiple FECs because of the ramifications on the LSPs going
upstream.  But I don't really have the time right at the moment
to put my finger on where it says that in the spec, so I may be
wrong.

>
>
> > It is reasonably well
> > known that you should not re-use a label you have just removed from service
> > for some period of time as this is likely to result in miss-routed packets in
> > any case.
>
> I disagree that this is true from the point of view of Router B; if the downstream
> router has advertised a FEC/Label combination, said router is indicating that it is
> ready to switch that label now, not at some point in the future.
>
> Your statement is correct from the point of view of Router A; after the last release
> for a label is received, Router A should avoid readvertising that label until all
> packets in transit have had a chance to clear the network.  But that's not what
> my example shows.  Router A is not readvertising a released label, it just looks
> that way from Router B's perspective.

And Router A is the one making the commitment to deliver a set
of packets in a certain way.  So only Router A's perspective
counts.  If it waits some reasonable amount of time before it
re-issues a label, then it does not matter what Router B's
point of view is with respect to that label.

>
>
> ...
>
> >     Having a syntactically different messages for the initial and subsequent
> > update Label Mappings would fix the problem you're describing, but it may
> > not be necessary.  One simple way to avoid this problem is to treat any label
> > received unsolicited (when operating in DoD mode) as an update.  If this is
> > what you do, then you would not end up using any label you did not get as
> > a result of a Label Request - at least originally.
>
> But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:
>
>   Router A                          Router B
>   --------                          --------
>
>   Sends Label Mapping
>    (Path Vector=<B,C,D,A>)
>                                     Receives Label Mapping
>   Router A gets a new next hop
>    for the FEC
>   Sends Label Mapping
>    (Path Vector=<E,F,G,A>)
>                                     Sends Label Release
>                                      (loop detected)
>   Receives Label Release
>                                     Receives Label Mapping
>
> At the end of this scenario, Router B holds a label which he believes was
> validly advertised by Router A.  Router A believes that Router B released
> the label.

This is a smallish sort of window, which may be sorted by simply
having Router A send a Label Withdraw when it receives packets
that are labeled with the labels that Router B mistakenly thinks
are valid.  I think that a robust LSR implementation will do
that in any case.

I think it's time for Bob Thomas to take the torch on this one.
The specification is currently being revised for submission as
a draft standard.  If people can convince him that adding some
semantic/syntactic differentiator is a good idea, then it will
be in the next version.  It makes absolutely no difference to
me.

>
>
> >
> >     I tend to think of DU and Liberal Retention as being a bundled package
> > and the same for DoD and Conservative Retention.
>
> Okay, but RFC 3031 (MPLS Architecture) specifically allows DU & Conservative
> to be used together.  See section 5.2.1, scheme 3.

Yeah, but this is a monkey trap.  The fact that it is allowed
does not change the fact that it is a very bad idea.  You have
to realize that DU and Conservative Retention means you will
have to release almost all of the labels you get in any real
world router with any interesting number of interfaces and
peers.  Why would you want to do that?


>
>
> ...

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray




From owner-mpls@UU.NET  Fri Jan 18 18:04:44 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00091
	for <mpls-archive@lists.ietf.org>; Fri, 18 Jan 2002 18:04:44 -0500 (EST)
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 QQlyka06806;
	Fri, 18 Jan 2002 23:04:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyka14705
	for mpls-outgoing; Fri, 18 Jan 2002 23:03: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 QQlyka14700
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 18 Jan 2002 23:03:51 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 QQlyka26755
	for <mpls@uu.net>; Fri, 18 Jan 2002 23:03:31 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 QQlyka13705
	for <mpls@uu.net>; Fri, 18 Jan 2002 23:03:30 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 SAA08219
	for <mpls@uu.net>; Fri, 18 Jan 2002 18:03:28 -0500 (EST)
Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA05705
	for <mpls@uu.net>; Fri, 18 Jan 2002 18:03:30 -0500 (EST)
Message-ID: <3C48A9C1.4D9A80A6@marconi.com>
Date: Fri, 18 Jan 2002 18:03:29 -0500
From: Jack Brennen <John.Brennen@marconi.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: [Fwd: LDP protocol problem?]
References: <3C486F53.84ABF819@sandburst.com> <3C487905.FC637396@marconi.com> <3C48883C.173B045@sandburst.com> <3C4890B6.C632B6E4@marconi.com> <3C489866.71F7807E@sandburst.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> > But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:
> >
> >   Router A                          Router B
> >   --------                          --------
> >
> >   Sends Label Mapping
> >    (Path Vector=<B,C,D,A>)
> >                                     Receives Label Mapping
> >   Router A gets a new next hop
> >    for the FEC
> >   Sends Label Mapping
> >    (Path Vector=<E,F,G,A>)
> >                                     Sends Label Release
> >                                      (loop detected)
> >   Receives Label Release
> >                                     Receives Label Mapping
> >
> > At the end of this scenario, Router B holds a label which he believes was
> > validly advertised by Router A.  Router A believes that Router B released
> > the label.
> 
> This is a smallish sort of window, which may be sorted by simply
> having Router A send a Label Withdraw when it receives packets
> that are labeled with the labels that Router B mistakenly thinks
> are valid.  I think that a robust LSR implementation will do
> that in any case.
> 

But Router A believes Router B to have released the label, so he may
reuse it for another purpose.  When Router B eventually puts traffic
onto the label (which may occur hours later), there is no reason to
believe that the label will still be unassigned.

And it is a smallish sort of window, but I'm not bringing this to the WG's
attention because of a theoretical concern.  This problem is being observed
in our lab under stress conditions.  It really happens in the real world.  :-(

Another way to look at this, which I hope *clearly* demonstrates the
intractable nature of this problem.  Consider these three protocol
conversations:

   Conversation 1                           Conversation 2
   --------------                           --------------

   Router A            Router B             Router A        Router B
   --------            --------             --------        --------
   Send LMap                                Send LMap
                       Recv LMap                            Recv LMap
                       Send LRel                            Send LRel
   NHOP Changes                             Recv LRel
   Send LMap                                NHOP Changes
   Recv LRel                                Send LMap
                       Recv LMap                            Recv LMap


   Conversation 3
   --------------

   Router A            Router B
   --------            --------
   Send LMap
                       Recv LMap
   NHOP Changes
   Send LMap
                       Recv LMap
                       Send LRel
   Recv LRel

These conversations are all legal according to the LDP spec,
and all are reasonably likely to happen.  Note that Router B can't
tell the difference between Conversations 1 & 2, and Router A can't
tell the difference between Conversations 1 & 3.

  Conversation 1:  A ends up with no label allocated, B has a label
  Conversation 2:  A and B both end up with a label allocated
  Conversation 3:  A and B both end up with no label allocated

Clearly, Conversation 1 leads to problems, but neither Router A nor
Router B can distinguish this from the valid Conversations 2 & 3.

This is a deficiency in the protocol, and we can brainstorm any number
of methods to work around the problem, but the problem is there,
and should be addressed.

   Jack


From owner-mpls@UU.NET  Sun Jan 20 12:51:30 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14093
	for <mpls-archive@lists.ietf.org>; Sun, 20 Jan 2002 12:51:30 -0500 (EST)
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 QQlyqp01278;
	Sun, 20 Jan 2002 17:50:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyqp26717
	for mpls-outgoing; Sun, 20 Jan 2002 17:50: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 QQlyqp26711
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 20 Jan 2002 17:50:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlyqp26573
	for <mpls@UU.NET>; Sun, 20 Jan 2002 17:49:29 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlyqp29251
	for <mpls@UU.NET>; Sun, 20 Jan 2002 17:49:28 GMT
Received: (qmail 24608 invoked from network); 20 Jan 2002 17:22:50 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 20 Jan 2002 17:22:50 -0000
Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121])
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id XAA26924;
	Sun, 20 Jan 2002 23:09:12 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id XAA14925;
	Sun, 20 Jan 2002 23:17:59 +0530
X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Sun, 20 Jan 2002 23:17:59 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: Jack Brennen <John.Brennen@marconi.com>
cc: <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
In-Reply-To: <3C48A9C1.4D9A80A6@marconi.com>
Message-ID: <Pine.LNX.4.30.0201202135400.22687-100000@gayatri.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Jack,

Yes I agree to you, a simple solution to this problem could be as follows

Label Release message will carry mesg-id (mandatory)to indicate exactly
this is an ack for which message, this can work for withdraw messages as
well. So there is no need to change the semantics of original mappings and
updates.

The LSR which receives this release, can check the message-id and take a
decision on to what can be done with it. If the mesg-id is older than the
most recently used message-id (to the peer, for that fec), it may ignore
the Release message, silently.

If the Release is as a result of some internal event at LSR, it may use
the message-id field of all zero's to indicate the internal event. (If the
release is being propagated, it can still be interpreted by downstream LSR
as internal event at upstream LSR). In such case, the downstream LSR
should not silently ignore this.

I tried working this scheme for two or three scenario's which you have
specified, it works correctly.

Also as Eric has pointed out on this thread a label release is an ack to
label withdraw message, its not quite unreasonable to send it as nack for
"a specific mapping" message. It doe not complicate the processing of
label mapping message and any LSR does not have to do extra work to check
whether a mapping received is updated mapping or not. An LSR when it needs
to do so, can simply release with proper mesg-id.

Does this sound alright?

-abhijit

Jack Brennen wrote :

>> > But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:
>> >
>> >   Router A                          Router B
>> >   --------                          --------
>> >
>> >   Sends Label Mapping
>> >    (Path Vector=<B,C,D,A>)
>> >                                     Receives Label Mapping
>> >   Router A gets a new next hop
>> >    for the FEC
>> >   Sends Label Mapping
>> >    (Path Vector=<E,F,G,A>)
>> >                                     Sends Label Release
>> >                                      (loop detected)
>> >   Receives Label Release
>> >                                     Receives Label Mapping
>> >
>> > At the end of this scenario, Router B holds a label which he believes was
>> > validly advertised by Router A.  Router A believes that Router B released
>> > the label.
>>
>> This is a smallish sort of window, which may be sorted by simply
>> having Router A send a Label Withdraw when it receives packets
>> that are labeled with the labels that Router B mistakenly thinks
>> are valid.  I think that a robust LSR implementation will do
>> that in any case.
>>
>
>But Router A believes Router B to have released the label, so he may
>reuse it for another purpose.  When Router B eventually puts traffic
>onto the label (which may occur hours later), there is no reason to
>believe that the label will still be unassigned.
>
>And it is a smallish sort of window, but I'm not bringing this to the WG's
>attention because of a theoretical concern.  This problem is being observed
>in our lab under stress conditions.  It really happens in the real world.  :-(
>
>Another way to look at this, which I hope *clearly* demonstrates the
>intractable nature of this problem.  Consider these three protocol
>conversations:
>
>   Conversation 1                           Conversation 2
>   --------------                           --------------
>
>   Router A            Router B             Router A        Router B
>   --------            --------             --------        --------
>   Send LMap                                Send LMap
>                       Recv LMap                            Recv LMap
>                       Send LRel                            Send LRel
>   NHOP Changes                             Recv LRel
>   Send LMap                                NHOP Changes
>   Recv LRel                                Send LMap
>                       Recv LMap                            Recv LMap
>
>
>   Conversation 3
>   --------------
>
>   Router A            Router B
>   --------            --------
>   Send LMap
>                       Recv LMap
>   NHOP Changes
>   Send LMap
>                       Recv LMap
>                       Send LRel
>   Recv LRel
>
>These conversations are all legal according to the LDP spec,
>and all are reasonably likely to happen.  Note that Router B can't
>tell the difference between Conversations 1 & 2, and Router A can't
>tell the difference between Conversations 1 & 3.
>
>  Conversation 1:  A ends up with no label allocated, B has a label
>  Conversation 2:  A and B both end up with a label allocated
>  Conversation 3:  A and B both end up with no label allocated
>
>Clearly, Conversation 1 leads to problems, but neither Router A nor
>Router B can distinguish this from the valid Conversations 2 & 3.
>
>This is a deficiency in the protocol, and we can brainstorm any number
>of methods to work around the problem, but the problem is there,
>and should be addressed.
>
>   Jack
>

-- 
-abhijit

Abhijit Gadgil
Graduate Student,
Dept. of Electrical Engineering,
IIT, Bombay.






From owner-mpls@UU.NET  Mon Jan 21 00:37:14 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22808
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 00:37:14 -0500 (EST)
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 QQlysk09388;
	Mon, 21 Jan 2002 05:35:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlysk17824
	for mpls-outgoing; Mon, 21 Jan 2002 05:35: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 QQlysk17819
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 05:35: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 QQlysk23847
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:35:07 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlysk08315
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:35:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA00379 for <mpls@uu.net>; Mon, 21 Jan 2002 00:35:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA23153 for mpls@uu.net; Mon, 21 Jan 2002 00:35:01 -0500 (EST)
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 QQlysk17757
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 05:34: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 QQlysk18809
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:33:46 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlysk11010
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:33:46 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT6AW41>; Mon, 21 Jan 2002 10:56:02 +0530
Message-ID: <D11B30C7348BD511A40700010283497B425908@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: Eric Gray <eric.gray@sandburst.com>
Cc: mpls@UU.NET
Subject: RE: LDP protocol problem?
Date: Mon, 21 Jan 2002 11:01:44 +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

It is common for set up and release to be a 3 way handshake in many
signalling protocols. If Rel is always triggered by a withdraw then its not
a problem but in situations were it is not don't u think the release needs
to be ACKed.All u need is a Rel ACK status in the notification messages.
This could clear up this and a similar problem in CR LDP. It would also
offer a lot of flexibilty in the Label distribution, control and retention
modes.

Please consider this  and correct me if I am wrong

Regards,
Vijay 

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Saturday, January 19, 2002 12:26 AM
To: Vijayanand C - CTD, Chennai.
Cc: MPLS Mailing List
Subject: Re: LDP protocol problem?


Vijay,

    I can't support the notion that the Release message needs an ACK.
Recall
that the Release message is itself an ACK to the Withdraw message.  We don't
want to get in the middle of an ACK war...


You wrote:

> I think the problem is - the release message has no ACK. If the Upstream
> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
> request for the same FEC to the same downstream and the Upstream when
> receiving the mapping 'update' drops it if it were waiting for the Rel-ACK
> then the problem would have been avoided.
>
> A related  problem occurs in CR LDP local repair(ref
> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
> request arrives earlier than the release.
>
> Please correct me if I am wrong
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
> Sent: Friday, January 18, 2002 12:47 PM
> To: mpls@UU.NET
> Subject: Re: LDP protocol problem?
>
> Vijay wrote:
> >I faced a similar problem some time back
> >
> >I think the problem comes because of the configuration of the LDP label
> >distribution mode, control mode and Request mode.
> >
> >Particularly here the request node is REQUEST_NEVER though the
distribution
> >mode is DuS. If router B were 'Request When Needed' then it would have
> >requested A for a label when A becomes its next Hop then the problem
would
> >have been overcome by A sending the mapping again after receiving the
> >request. I wonder if DuS Ind control with 'Request Never' is not a good
> >configuration choice
> >
> >Please correct me if I am wrong.
>
> The problem also manifests itself if the session is
> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>
>   Router A                          Router B
>   --------                          --------
>
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Request
>   Sends Label Mapping (Label 1)
>                                     Router A becomes NOT the next hop
>                                     Sends Label Abort Request
>   Receives Label Abort Request
>    (which is ignored)
>                                     Receives Label Mapping (Label 1)
>                                     Sends Label Release (Label 1)
>                                      (because Router A is not the next
hop)
>   Sends Label Mapping (Label 1)
>    (because the hop count changed)
>                                     Router A becomes the next hop
>                                     Sends Label Request
>   Receives Label Release (Label 1)
>                                     Receives Label Mapping (Label 1)
>   Receives Label Request
>   Sends Label Mapping (Label 2)
>                                     Receives Label Mapping (Label 2)
>                                     Sends Label Release (Label 2)
>   Receives Label Release (Label 2)
>
> The final outcome is the same.  Router B believes that a
> Label Mapping exists; Router A believes that no Label Mapping exists.
>
> The problem seems independent of distribution, control, or retention
> modes.  The crux of the problem is that when Router A sends a
> Label Mapping message which is an "update" message (the same FEC
> and Label as a previous message, usually sent to change the
> hop count and/or path vector) and then subsequently receives a
> Label Release message for that FEC and Label, one of two
> situations can exist:
>
>   * If Router B sent the Label Release after receiving the
>     "update" message, then Router B is not keeping the label
>
>   * If Router B sent the Label Release before receiving the
>     "update" message, then Router B may in fact keep the
>     label if his situation changed between sending the
>     Label Release and receiving the "update" message.
>     (The most likely reason for the situation to change
>     would be Router A becoming the next hop for the FEC.)
>
> Router A simply cannot reliably determine which of these
> two situations exists on Router B.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray




From owner-mpls@UU.NET  Mon Jan 21 00:48:02 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22924
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 00:48:02 -0500 (EST)
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 QQlysl20906;
	Mon, 21 Jan 2002 05:47:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlysl18854
	for mpls-outgoing; Mon, 21 Jan 2002 05:46:47 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlysl18849
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 05:46: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 QQlysl16833
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:46:28 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlysl02164
	for <mpls@uu.net>; Mon, 21 Jan 2002 05:46:26 GMT
Received: (qmail 19594 invoked from network); 21 Jan 2002 05:27:20 -0000
Received: from bhairav.ee.iitb.ac.in (144.16.100.100)
  by mailhost.iitb.ac.in with SMTP; 21 Jan 2002 05:27:20 -0000
Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121])
	by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id LAA19087;
	Mon, 21 Jan 2002 11:13:42 +0530 (IST)
Received: from localhost (gabhijit@localhost)
	by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id LAA16295;
	Mon, 21 Jan 2002 11:22:41 +0530
X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs
Date: Mon, 21 Jan 2002 11:22:41 +0530 (IST)
From: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
To: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
cc: Eric Gray <eric.gray@sandburst.com>, <mpls@UU.NET>
Subject: RE: LDP protocol problem?
In-Reply-To: <D11B30C7348BD511A40700010283497B425908@GAYATRI>
Message-ID: <Pine.LNX.4.30.0201211116110.15908-100000@bharati.ee.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Vijay,

Please refer to a message posted about release message. I agree with Eric
that ACKing release is not a very good idea. But neverthless a release
message can itself indicate what it exactly is Acking(withdraw) or
Nacking(Mapping) with the mesg-id. So now the ball is in the court of
downstream LSR, to act upon this. It will do so if it finds it necessary.
Otherwise the upstream LSR cannot really help. It solves the problem
indicated by Jack as well. I havent really checked how it will work with
CR-LDP.

Since LDP is anyways using TCP, asking for ack for every message sent is
somewhat unreasonable.

Any thoughts?

-abhijit

Vijayanand C - CTD, Chennai. wrote :

>It is common for set up and release to be a 3 way handshake in many
>signalling protocols. If Rel is always triggered by a withdraw then its not
>a problem but in situations were it is not don't u think the release needs
>to be ACKed.All u need is a Rel ACK status in the notification messages.
>This could clear up this and a similar problem in CR LDP. It would also
>offer a lot of flexibilty in the Label distribution, control and retention
>modes.
>
>Please consider this  and correct me if I am wrong
>
>Regards,
>Vijay
>
>-----Original Message-----
>From: Eric Gray [mailto:eric.gray@sandburst.com]
>Sent: Saturday, January 19, 2002 12:26 AM
>To: Vijayanand C - CTD, Chennai.
>Cc: MPLS Mailing List
>Subject: Re: LDP protocol problem?
>
>
>Vijay,
>
>    I can't support the notion that the Release message needs an ACK.
>Recall
>that the Release message is itself an ACK to the Withdraw message.  We don't
>want to get in the middle of an ACK war...
>
>
>You wrote:
>
>> I think the problem is - the release message has no ACK. If the Upstream
>> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
>> request for the same FEC to the same downstream and the Upstream when
>> receiving the mapping 'update' drops it if it were waiting for the Rel-ACK
>> then the problem would have been avoided.
>>
>> A related  problem occurs in CR LDP local repair(ref
>> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
>> request arrives earlier than the release.
>>
>> Please correct me if I am wrong
>>
>> Regards,
>> Vijay
>>
>> -----Original Message-----
>> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
>> Sent: Friday, January 18, 2002 12:47 PM
>> To: mpls@UU.NET
>> Subject: Re: LDP protocol problem?
>>
>> Vijay wrote:
>> >I faced a similar problem some time back
>> >
>> >I think the problem comes because of the configuration of the LDP label
>> >distribution mode, control mode and Request mode.
>> >
>> >Particularly here the request node is REQUEST_NEVER though the
>distribution
>> >mode is DuS. If router B were 'Request When Needed' then it would have
>> >requested A for a label when A becomes its next Hop then the problem
>would
>> >have been overcome by A sending the mapping again after receiving the
>> >request. I wonder if DuS Ind control with 'Request Never' is not a good
>> >configuration choice
>> >
>> >Please correct me if I am wrong.
>>
>> The problem also manifests itself if the session is
>> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>>
>>   Router A                          Router B
>>   --------                          --------
>>
>>                                     Router A becomes the next hop
>>                                     Sends Label Request
>>   Receives Label Request
>>   Sends Label Mapping (Label 1)
>>                                     Router A becomes NOT the next hop
>>                                     Sends Label Abort Request
>>   Receives Label Abort Request
>>    (which is ignored)
>>                                     Receives Label Mapping (Label 1)
>>                                     Sends Label Release (Label 1)
>>                                      (because Router A is not the next
>hop)
>>   Sends Label Mapping (Label 1)
>>    (because the hop count changed)
>>                                     Router A becomes the next hop
>>                                     Sends Label Request
>>   Receives Label Release (Label 1)
>>                                     Receives Label Mapping (Label 1)
>>   Receives Label Request
>>   Sends Label Mapping (Label 2)
>>                                     Receives Label Mapping (Label 2)
>>                                     Sends Label Release (Label 2)
>>   Receives Label Release (Label 2)
>>
>> The final outcome is the same.  Router B believes that a
>> Label Mapping exists; Router A believes that no Label Mapping exists.
>>
>> The problem seems independent of distribution, control, or retention
>> modes.  The crux of the problem is that when Router A sends a
>> Label Mapping message which is an "update" message (the same FEC
>> and Label as a previous message, usually sent to change the
>> hop count and/or path vector) and then subsequently receives a
>> Label Release message for that FEC and Label, one of two
>> situations can exist:
>>
>>   * If Router B sent the Label Release after receiving the
>>     "update" message, then Router B is not keeping the label
>>
>>   * If Router B sent the Label Release before receiving the
>>     "update" message, then Router B may in fact keep the
>>     label if his situation changed between sending the
>>     Label Release and receiving the "update" message.
>>     (The most likely reason for the situation to change
>>     would be Router A becoming the next hop for the FEC.)
>>
>> Router A simply cannot reliably determine which of these
>> two situations exists on Router B.



From owner-mpls@UU.NET  Mon Jan 21 01:30:38 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23330
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 01:30:38 -0500 (EST)
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 QQlyso17120;
	Mon, 21 Jan 2002 06:30:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlysn11835
	for mpls-outgoing; Mon, 21 Jan 2002 06:29: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 QQlysn11829
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 06:29: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 QQlysn00986
	for <mpls@uu.net>; Mon, 21 Jan 2002 06:29:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlysn26569
	for <mpls@uu.net>; Mon, 21 Jan 2002 06:29:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA04422 for <mpls@uu.net>; Mon, 21 Jan 2002 01:29:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA26077 for mpls@uu.net; Mon, 21 Jan 2002 01:29:01 -0500 (EST)
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 QQlysn11793
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 06:28:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlysn05345
	for <mpls@uu.net>; Mon, 21 Jan 2002 06:27:51 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlysn14175
	for <mpls@uu.net>; Mon, 21 Jan 2002 06:27:50 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <CTT6AXJX>; Mon, 21 Jan 2002 11:50:11 +0530
Message-ID: <D11B30C7348BD511A40700010283497B42594A@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: Abhijit Gadgil <gabhijit@ee.iitb.ac.in>
Cc: mpls@UU.NET
Subject: RE: LDP protocol problem?
Date: Mon, 21 Jan 2002 11:55:47 +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

Abhijit,
ACKing is not merely for ensuring the reliability of PDUs but for triggering
subsequent events in the state machine.

When release is initiated by LDP due to FEC going down or local repair etc.
it does'nt have an ACK and this causes some confusion as in the present case
and in CR LDP local repair (ref
:http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html).
When an  ABORT_REQUEST message in LDP is ACKed by a notification why not a
release which is even more critical because it involves releasing an already
held label. 


Regards,
Vijay


-----Original Message-----
From: Abhijit Gadgil [mailto:gabhijit@ee.iitb.ac.in]
Sent: Monday, January 21, 2002 11:23 AM
To: Vijayanand C - CTD, Chennai.
Cc: Eric Gray; mpls@uu.net
Subject: RE: LDP protocol problem?



Vijay,

Please refer to a message posted about release message. I agree with Eric
that ACKing release is not a very good idea. But neverthless a release
message can itself indicate what it exactly is Acking(withdraw) or
Nacking(Mapping) with the mesg-id. So now the ball is in the court of
downstream LSR, to act upon this. It will do so if it finds it necessary.
Otherwise the upstream LSR cannot really help. It solves the problem
indicated by Jack as well. I havent really checked how it will work with
CR-LDP.

Since LDP is anyways using TCP, asking for ack for every message sent is
somewhat unreasonable.

Any thoughts?

-abhijit

Vijayanand C - CTD, Chennai. wrote :

>It is common for set up and release to be a 3 way handshake in many
>signalling protocols. If Rel is always triggered by a withdraw then its not
>a problem but in situations were it is not don't u think the release needs
>to be ACKed.All u need is a Rel ACK status in the notification messages.
>This could clear up this and a similar problem in CR LDP. It would also
>offer a lot of flexibilty in the Label distribution, control and retention
>modes.
>
>Please consider this  and correct me if I am wrong
>
>Regards,
>Vijay
>
>-----Original Message-----
>From: Eric Gray [mailto:eric.gray@sandburst.com]
>Sent: Saturday, January 19, 2002 12:26 AM
>To: Vijayanand C - CTD, Chennai.
>Cc: MPLS Mailing List
>Subject: Re: LDP protocol problem?
>
>
>Vijay,
>
>    I can't support the notion that the Release message needs an ACK.
>Recall
>that the Release message is itself an ACK to the Withdraw message.  We
don't
>want to get in the middle of an ACK war...
>
>
>You wrote:
>
>> I think the problem is - the release message has no ACK. If the Upstream
>> waits for a Rel-ACK(in Notification or otherwise) before issuing a new
>> request for the same FEC to the same downstream and the Upstream when
>> receiving the mapping 'update' drops it if it were waiting for the
Rel-ACK
>> then the problem would have been avoided.
>>
>> A related  problem occurs in CR LDP local repair(ref
>> :http://cell.onecall.net/mhonarc/mpls/2001-Dec/msg00156.html) when the
>> request arrives earlier than the release.
>>
>> Please correct me if I am wrong
>>
>> Regards,
>> Vijay
>>
>> -----Original Message-----
>> From: John.Brennen@marconi.com [mailto:John.Brennen@marconi.com]
>> Sent: Friday, January 18, 2002 12:47 PM
>> To: mpls@UU.NET
>> Subject: Re: LDP protocol problem?
>>
>> Vijay wrote:
>> >I faced a similar problem some time back
>> >
>> >I think the problem comes because of the configuration of the LDP label
>> >distribution mode, control mode and Request mode.
>> >
>> >Particularly here the request node is REQUEST_NEVER though the
>distribution
>> >mode is DuS. If router B were 'Request When Needed' then it would have
>> >requested A for a label when A becomes its next Hop then the problem
>would
>> >have been overcome by A sending the mapping again after receiving the
>> >request. I wonder if DuS Ind control with 'Request Never' is not a good
>> >configuration choice
>> >
>> >Please correct me if I am wrong.
>>
>> The problem also manifests itself if the session is
>> "Request-when-Needed" and "Downstream-on-Demand."  Example:
>>
>>   Router A                          Router B
>>   --------                          --------
>>
>>                                     Router A becomes the next hop
>>                                     Sends Label Request
>>   Receives Label Request
>>   Sends Label Mapping (Label 1)
>>                                     Router A becomes NOT the next hop
>>                                     Sends Label Abort Request
>>   Receives Label Abort Request
>>    (which is ignored)
>>                                     Receives Label Mapping (Label 1)
>>                                     Sends Label Release (Label 1)
>>                                      (because Router A is not the next
>hop)
>>   Sends Label Mapping (Label 1)
>>    (because the hop count changed)
>>                                     Router A becomes the next hop
>>                                     Sends Label Request
>>   Receives Label Release (Label 1)
>>                                     Receives Label Mapping (Label 1)
>>   Receives Label Request
>>   Sends Label Mapping (Label 2)
>>                                     Receives Label Mapping (Label 2)
>>                                     Sends Label Release (Label 2)
>>   Receives Label Release (Label 2)
>>
>> The final outcome is the same.  Router B believes that a
>> Label Mapping exists; Router A believes that no Label Mapping exists.
>>
>> The problem seems independent of distribution, control, or retention
>> modes.  The crux of the problem is that when Router A sends a
>> Label Mapping message which is an "update" message (the same FEC
>> and Label as a previous message, usually sent to change the
>> hop count and/or path vector) and then subsequently receives a
>> Label Release message for that FEC and Label, one of two
>> situations can exist:
>>
>>   * If Router B sent the Label Release after receiving the
>>     "update" message, then Router B is not keeping the label
>>
>>   * If Router B sent the Label Release before receiving the
>>     "update" message, then Router B may in fact keep the
>>     label if his situation changed between sending the
>>     Label Release and receiving the "update" message.
>>     (The most likely reason for the situation to change
>>     would be Router A becoming the next hop for the FEC.)
>>
>> Router A simply cannot reliably determine which of these
>> two situations exists on Router B.



From owner-mpls@UU.NET  Mon Jan 21 06:52:11 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06225
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 06:52:11 -0500 (EST)
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 QQlytj17642;
	Mon, 21 Jan 2002 11:51:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlytj15368
	for mpls-outgoing; Mon, 21 Jan 2002 11:51: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 QQlytj15317
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 11:50: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 QQlytj01752
	for <mpls@UU.NET>; Mon, 21 Jan 2002 11:49:56 GMT
Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142])
	id QQlytj15262
	for <mpls@UU.NET>; Mon, 21 Jan 2002 11:49:55 GMT
Received: (qmail 16282 invoked from network); 21 Jan 2002 11:30:50 -0000
Received: from mailscan1.iitb.ac.in (HELO iitb.ac.in) (144.16.108.201)
  by mailhost.iitb.ac.in with SMTP; 21 Jan 2002 11:30:50 -0000
X-SMTP-Sending-IP: 144.16.116.2
Received: from akash.it.iitb.ac.in by iitb.ac.in ; 21 Jan 2002 17:19:57 +0530
Received: from cygnus.it.iitb.ac.in (cygnus.it.iitb.ac.in [144.16.116.9])
	by akash.it.iitb.ac.in (8.11.2/8.8.8) with ESMTP id g0LBnhx04178;
	Mon, 21 Jan 2002 17:19:43 +0530
Received: from localhost (praveen@localhost)
	by cygnus.it.iitb.ac.in (8.11.0/8.8.7) with ESMTP id g0LBncb32132;
	Mon, 21 Jan 2002 17:19:38 +0530
Date: Mon, 21 Jan 2002 17:19:38 +0530 (IST)
From: Praveen Kumar <praveen@it.iitb.ac.in>
To: Jack Brennen <John.Brennen@marconi.com>
cc: MPLS Mailing List <mpls@UU.NET>
Subject: Re: [Fwd: LDP protocol problem?]
In-Reply-To: <3C487905.FC637396@marconi.com>
Message-ID: <Pine.LNX.4.21.0201211621460.28478-100000@cygnus.it.iitb.ac.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


On Fri, 18 Jan 2002, Jack Brennen wrote:

> If "update" Label Mapping messages were syntactically different than normal
> unsolicited Label Mapping messages, the whole problem could be avoided.  That
> is how I would fix the specification if it were my decision.

I agree with this.

Label Mapping message allows an optional mesg id field which can indicate
the mesg id of corresponding Label Request Message. Here either 
"update" or "unsolicited" mapping messages are not result of any label
request. So, how about carrying special mandatory (reserved) ids in these
fields, for these two cases. Thus this reserved id can logically/ 
syntactically differentiate these two cases.

For the cases mentioned by jack, LSR A can determine whether the received
release message is result of recently sent update mapping or previous
mapping by using the approach suggested by "gabhijit". 

The differentiation of mapping messages that are sent as a result of label
request, result of update or result of advertisement mode gives more
flexibility to an receiving LSR to take any further (may be 
future) decisions.

Correct me if am wrong.

-- 
S.Praveen Kumar
Graduate Student
KReSIT, IIT-Bombay
web: http://www.it.iitb.ac.in/~praveen




From owner-mpls@UU.NET  Mon Jan 21 13:05:08 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18957
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 13:05:08 -0500 (EST)
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 QQlyui04402;
	Mon, 21 Jan 2002 18:04:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyui23562
	for mpls-outgoing; Mon, 21 Jan 2002 18:04:22 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlyui23553
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 18:04: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 QQlyui01956
	for <mpls@uu.net>; Mon, 21 Jan 2002 18:03:30 GMT
Received: from penguin-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	id QQlyui02170
	for <mpls@uu.net>; Mon, 21 Jan 2002 18:03:30 GMT
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0LI3Sw02095
	for <mpls@uu.net>; Mon, 21 Jan 2002 19:03:29 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Jan 21 19:03:28 2002 +0100
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKKWTR2>; Mon, 21 Jan 2002 19:03:27 +0100
Message-ID: <B3BD65546DECD4118B280002A52CEBF45BFABB@eitrmnt105.tei.ericsson.se>
From: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>
To: mpls@UU.NET
Subject: MPLS label value range
Date: Mon, 21 Jan 2002 19:03:08 +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 all!

I'd like to know which are the values that MPLS labels range over.
e.g. the first 4 bits are reserved, from 5 to x bits are used for ATM ( I don't know, it is just an example)...etc

Thank you!!!

Paola


From owner-mpls@UU.NET  Mon Jan 21 13:18:26 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19253
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 13:18:26 -0500 (EST)
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 QQlyuj00469;
	Mon, 21 Jan 2002 18:17:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyuj03911
	for mpls-outgoing; Mon, 21 Jan 2002 18:17:41 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 QQlyuj03905
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 18:17: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 QQlyuj01628
	for <mpls@uu.net>; Mon, 21 Jan 2002 18:15:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyuj05438
	for <mpls@uu.net>; Mon, 21 Jan 2002 18:15:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22535 for <mpls@uu.net>; Mon, 21 Jan 2002 13:15:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27985 for mpls@uu.net; Mon, 21 Jan 2002 13:15:02 -0500 (EST)
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 QQlyui03384
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 18:14: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 QQlyui07472
	for <mpls@UU.NET>; Mon, 21 Jan 2002 18:13:55 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 QQlyui03970
	for <mpls@UU.NET>; Mon, 21 Jan 2002 18:13:55 GMT
Received: from ASIMHA-W2K.amer.cisco.com (dhcp-64-102-48-157.cisco.com [64.102.48.157])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA16602;
	Mon, 21 Jan 2002 13:13:53 -0500 (EST)
Date: Mon, 21 Jan 2002 13:13:52 -0500 (Eastern Standard Time)
From: Ajay Simha <asimha@cisco.com>
To: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>
cc: mpls@UU.NET
Subject: Re: MPLS label value range
In-Reply-To: <B3BD65546DECD4118B280002A52CEBF45BFABB@eitrmnt105.tei.ericsson.se>
Message-ID: <Pine.WNT.4.40.0201211312370.5984-100000@ASIMHA-W2K.amer.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, 21 Jan 2002, Paola Iovanna (ERI) wrote:

PIE>Hi all!
PIE>
PIE>I'd like to know which are the values that MPLS labels range over.
PIE>e.g. the first 4 bits are reserved, from 5 to x bits are used for ATM
PIE>( I don't know, it is just an example)...etc

Paola,

RFC 3032 section:

2.1. Encoding the Label Stack

has only lables 0 through 15 reserved.

-ajay
PIE>
PIE>Thank you!!!
PIE>
PIE>Paola
PIE>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
Cisco Systems
(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 Jan 21 13:56:32 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19953
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 13:56:32 -0500 (EST)
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 QQlyul00113;
	Mon, 21 Jan 2002 18:55:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyul06607
	for mpls-outgoing; Mon, 21 Jan 2002 18:55: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 QQlyul06602
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 18:55: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 QQlyul17386
	for <mpls@UU.NET>; Mon, 21 Jan 2002 18:54:47 GMT
Received: from hopper.math.uwaterloo.ca by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hopper.math.uwaterloo.ca [129.97.78.132])
	id QQlyul03812
	for <mpls@UU.NET>; Mon, 21 Jan 2002 18:54:47 GMT
Received: from localhost (wwszeto@localhost)
	by hopper.math.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id NAA03352;
	Mon, 21 Jan 2002 13:54:42 -0500 (EST)
Date: Mon, 21 Jan 2002 13:54:42 -0500 (EST)
From: "Wayne W. Szeto" <wwszeto@hopper.math.uwaterloo.ca>
To: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>
cc: mpls@UU.NET
Subject: Re: MPLS label value range
In-Reply-To: <B3BD65546DECD4118B280002A52CEBF45BFABB@eitrmnt105.tei.ericsson.se>
Message-ID: <Pine.SOL.4.05.10201211352060.1696-100000@hopper.math.uwaterloo.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

The range of MPLS labels is from 0 to (2^20 - 1), where label 0-15 are
reserved.  


On Mon, 21 Jan 2002, Paola Iovanna (ERI) wrote:

> Hi all!
> 
> I'd like to know which are the values that MPLS labels range over.
> e.g. the first 4 bits are reserved, from 5 to x bits are used for ATM ( I don't know, it is just an example)...etc
> 
> Thank you!!!
> 
> Paola
> 



From owner-mpls@UU.NET  Mon Jan 21 14:38:34 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21464
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 14:38:33 -0500 (EST)
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 QQlyuo04361;
	Mon, 21 Jan 2002 19:38:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyuo29943
	for mpls-outgoing; Mon, 21 Jan 2002 19:37: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 QQlyuo29938
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 19:37: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 QQlyuo20755
	for <mpls@uu.net>; Mon, 21 Jan 2002 19:37:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyuo24463
	for <mpls@uu.net>; Mon, 21 Jan 2002 19:37:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03902 for <mpls@uu.net>; Mon, 21 Jan 2002 14:37:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA02286 for mpls@uu.net; Mon, 21 Jan 2002 14:37:01 -0500 (EST)
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 QQlyuo29889
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 19:36: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 QQlyuo06938
	for <mpls@uu.net>; Mon, 21 Jan 2002 19:35:59 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyuo23037
	for <mpls@uu.net>; Mon, 21 Jan 2002 19:35:59 GMT
Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03774 for <mpls@uu.net>; Mon, 21 Jan 2002 14:35:58 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA21348 for <mpls@uu.net>; Mon, 21 Jan 2002 14:35:58 -0500 (EST)
Message-Id: <200201211935.OAA21348@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last Call on MTU Sig Ext for LDP
Date: Mon, 21 Jan 2002 14:35:58 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Folks -

As Kireeti just reminded me, we said in SLC that this draft would go
to last call.

So this message begins a two week last call on:

  "MTU Signalling Extensions for LDP" 
   <draft-black-ldp-mtu-extensions-02.txt>

The last call ends 2400 GMT Feb 4, 2002.

...George

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





From owner-mpls@UU.NET  Mon Jan 21 17:12:38 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26703
	for <mpls-archive@lists.ietf.org>; Mon, 21 Jan 2002 17:12:38 -0500 (EST)
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 QQlyuy21478;
	Mon, 21 Jan 2002 22:11:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyuy11115
	for mpls-outgoing; Mon, 21 Jan 2002 22:11: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 QQlyuy11094
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 22:11:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlyuy17892
	for <mpls@uu.net>; Mon, 21 Jan 2002 22:11:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyuy20224
	for <mpls@uu.net>; Mon, 21 Jan 2002 22:11:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21793 for <mpls@uu.net>; Mon, 21 Jan 2002 17:11:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA09798 for mpls@uu.net; Mon, 21 Jan 2002 17:11:01 -0500 (EST)
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 QQlyuy10721
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 21 Jan 2002 22:09:56 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 QQlyuy11020
	for <mpls@UU.NET>; Mon, 21 Jan 2002 22:09:19 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlyuy17758
	for <mpls@UU.NET>; Mon, 21 Jan 2002 22:09:18 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21561; Mon, 21 Jan 2002 17:09:18 -0500 (EST)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA15835; Mon, 21 Jan 2002 17:09:18 -0500 (EST)
Date: Mon, 21 Jan 2002 17:09:18 -0500
From: Eric Osborne <eosborne@cisco.com>
To: "Wayne W. Szeto" <wwszeto@hopper.math.uwaterloo.ca>
Cc: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>, mpls@UU.NET
Subject: Re: MPLS label value range
Message-ID: <20020121170917.C13110@eosborne-u10.cisco.com>
References: <B3BD65546DECD4118B280002A52CEBF45BFABB@eitrmnt105.tei.ericsson.se> <Pine.SOL.4.05.10201211352060.1696-100000@hopper.math.uwaterloo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.SOL.4.05.10201211352060.1696-100000@hopper.math.uwaterloo.ca>; from wwszeto@hopper.math.uwaterloo.ca on Mon, Jan 21, 2002 at 01:54:42PM -0500
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, Jan 21, 2002 at 01:54:42PM -0500, Wayne W. Szeto wrote:
> The range of MPLS labels is from 0 to (2^20 - 1), where label 0-15 are
> reserved.  
> 

...for frame-based.  For cell-based, the range is mostly size of the
VCI/VPI space; see rfc 3035.



eric

> 
> On Mon, 21 Jan 2002, Paola Iovanna (ERI) wrote:
> 
> > Hi all!
> > 
> > I'd like to know which are the values that MPLS labels range over.
> > e.g. the first 4 bits are reserved, from 5 to x bits are used for ATM ( I don't know, it is just an example)...etc
> > 
> > Thank you!!!
> > 
> > Paola
> > 



From owner-mpls@UU.NET  Tue Jan 22 08:06:37 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17036
	for <mpls-archive@lists.ietf.org>; Tue, 22 Jan 2002 08:06:36 -0500 (EST)
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 QQlyxg11199;
	Tue, 22 Jan 2002 13:05:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyxg07782
	for mpls-outgoing; Tue, 22 Jan 2002 13:05: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 QQlyxg07766
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 22 Jan 2002 13:04: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 QQlyxg21199
	for <mpls@UU.NET>; Tue, 22 Jan 2002 13:04:34 GMT
From: sven.van_den_bosch@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 QQlyxg05545
	for <mpls@UU.NET>; Tue, 22 Jan 2002 13:04:33 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0MD4TN09258;
	Tue, 22 Jan 2002 14:04:29 +0100 (MET)
Subject: Re: last call on hierarchy
To: yakov@juniper.net
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF4AE16B95.FA3485EC-ONC1256B49.0047818D@net.alcatel.be>
Date: Tue, 22 Jan 2002 14:04:25 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/22/2002 14:04:28
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

I have added some additional comments to my original mail. Do you think
these issues should be considered during the final revision of the
document?

Thanks,
Sven.

---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on
22/01/2002 14:01 ---------------------------


Sven VAN DEN BOSCH
18/01/2002 09:57

To:   Yakov Rekhter <yakov@juniper.net>
cc:
Subject:  Re: last call on hierarchy  (Document link: Sven VAN DEN BOSCH)

Yakov,

Thanks for your reply. Please see my additional comments marked Sven>>



Yakov Rekhter <yakov@juniper.net> on 17/01/2002 19:57:49
                                                              
                                                              
                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          mpls@UU.NET                                    
                                                              
                                                              
                                                              
  Subject      Re: last call on hierarchy                     
  :                                                           
                                                              





Sven,

> Hi,
>
> I would like to clarify two questions regarding the hierarchy draft that
is
> currently on last call:
>
> 1. Dynamic recomputation of the path of the FA-LSP
>
> If I understand correctly, the path information regarding the FA-LSP is
> made available to other nodes by means of the PATH TLV.

Correct.

> This information may be used by other nodes for their own path
computations.

Correct.

> They could for instance take it into account when computing a backup
path.

Correct.

> Then if the FA-LSP changes path, primary and backup path of the client
> LSPs may no longer be disjoint.

Correct.

> My proposal would be to foresee the possibility to restrict the
> reroutability of the FA-LSP and advertise this in the PATH-TLV. In this
> way, nodes that use this information would know whether it is subject to
> change or not.

There may be (at least) two reasons why the FA-LSP gets re-routed:

(1) the current path taken by FA-LSP becomes unfeasible (e.g., one
of the links along the path went down)

Sven>> I think this argument maybe applies less in the specific example I
gave. When the FA-LSP is rerouted as a result of a failure it can be
regarded by the client LSPs as a link that "cannot fail". In this case any
protection mechanism on the client LSPs should probably not be triggered
and the protection path wouldn't have to be disjoint from the path taken by
the FA-LSP.

(2) there is a "better" path, so FA-LSP is re-routed as part of
optimization.

Do you want to restrict re-routability in both cases ? Or only
in the second one ?

Sven>> You are of course completely right. I should have used more careful
wording. I will try again. I would propose the possibility to restrict the
reroutability of the *primary* path of the FA-LSP and advertise this in the
PATH-TLV. It would leave the decision on whether to reroute for optimality
or not to operator policy but it would allow an LSP that could be impacted
by rerouting the choice not to use the FA-LSP. It can do this when it knows
whether or not the FA-LSP is subject to rerouting.

Sven>> Things brings up another question:Is it possible to use the exact
same ERO hop sequence as the FA-LSP but still not use the FA-LSP (supposing
you want to use the FA-LSP for some LSPs and not for others)?

> 2. Automatic setup of FA-LSP
>
> The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets
up
> a new FA-LSP.  That is, it initiates a new LSP setup just for the
FA-LSP."
> I would like to clarify what happens when two FA-LSPs exist that, when
> concatenated, can replace the new FA-LSP that is proposed to be set up in
> the quoted text.
>
> I would propose to say that the LSR may set up a new FA-LSP or
> alternatively, it may replace the hop by a sequence of hops for which FAs
> are available.

that would be ok, *provided* that the the strict hop subsequence
from the ERO carried by the new LSP matches the one resulted from
the concatenation of several FA-LSPs. Agreed ?

Sven>> In the case that you describe I definitely agree. But I also saw
another case where it is a loose hop over a region. In this case, instead
of setting up a new FA-LSP you might want to use two existing FA-LSPs.
Then, when there is no FA-LSP to the destination edge of the region instead
of making a new one you would need the freedom to expand the ERO using an
intermediate node (another edge of the region which has a FA-LSP with both
edges in the original ERO). I tried to make a drawing below. I am not sure
the last situation ("desired") is allowed by the draft.

input: explicit route A-B-C-D

current network situation:
                           A----B              C----D
                                 \            /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

new situation according to draft (there is no FA-LSP from B to C):
                           A----B--------------C----D
                                 \    FA3     /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

desired new situation: expand ERO to A-B-X-C-D and leave network as is
                           A----B              C----D
                                 \            /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

Sven.



Yakov.







From owner-mpls@UU.NET  Tue Jan 22 11:45:39 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29492
	for <mpls-archive@lists.ietf.org>; Tue, 22 Jan 2002 11:45:39 -0500 (EST)
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 QQlyxu08916;
	Tue, 22 Jan 2002 16:36:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlyxu03385
	for mpls-outgoing; Tue, 22 Jan 2002 16:35: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 QQlyxu03380
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 22 Jan 2002 16:35: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 QQlyxu19162
	for <mpls@UU.NET>; Tue, 22 Jan 2002 16:35:27 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 QQlyxu07584
	for <mpls@UU.NET>; Tue, 22 Jan 2002 16:35:27 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 g0MGYu613265;
	Tue, 22 Jan 2002 08:34:56 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200201221634.g0MGYu613265@merlot.juniper.net>
To: sven.van_den_bosch@alcatel.be
cc: yakov@juniper.net, mpls@UU.NET, yakov@juniper.net
Subject: Re: last call on hierarchy 
In-Reply-To: Your message of "Tue, 22 Jan 2002 14:04:25 +0100."
             <OF4AE16B95.FA3485EC-ONC1256B49.0047818D@net.alcatel.be> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <40083.1011717296.1@juniper.net>
Date: Tue, 22 Jan 2002 08:34:56 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Sven,

> I have added some additional comments to my original mail. Do you think
> these issues should be considered during the final revision of the
> document?

see in-line...

[clipped...]

> Sven>> Things brings up another question:Is it possible to use the exact
> same ERO hop sequence as the FA-LSP but still not use the FA-LSP (supposing
> you want to use the FA-LSP for some LSPs and not for others)?
> 
> > 2. Automatic setup of FA-LSP
> >
> > The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets
> > up a new FA-LSP.  That is, it initiates a new LSP setup just for the
> > FA-LSP."
> > I would like to clarify what happens when two FA-LSPs exist that, when
> > concatenated, can replace the new FA-LSP that is proposed to be set up in
> > the quoted text.
> >
> > I would propose to say that the LSR may set up a new FA-LSP or
> > alternatively, it may replace the hop by a sequence of hops for which FAs
> > are available.
> 
> that would be ok, *provided* that the the strict hop subsequence
> from the ERO carried by the new LSP matches the one resulted from
> the concatenation of several FA-LSPs. Agreed ?
> 
> Sven>> In the case that you describe I definitely agree. 

Ok. So, I'll add the text to cover this.

>                                                          But I also saw
> another case where it is a loose hop over a region. In this case, instead
> of setting up a new FA-LSP you might want to use two existing FA-LSPs.
> Then, when there is no FA-LSP to the destination edge of the region instead
> of making a new one you would need the freedom to expand the ERO using an
> intermediate node (another edge of the region which has a FA-LSP with both
> edges in the original ERO). I tried to make a drawing below. I am not sure
> the last situation ("desired") is allowed by the draft.
> 
> input: explicit route A-B-C-D
> 
> current network situation:
>                            A----B              C----D
>                                  \            /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
> 
> new situation according to draft (there is no FA-LSP from B to C):
>                            A----B--------------C----D
>                                  \    FA3     /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
> 
> desired new situation: expand ERO to A-B-X-C-D and leave network as is
>                            A----B              C----D
>                                  \            /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
> 
> Sven.

That is also a valid case. I'll add the text to the document to
cover this case.

Yakov.


From owner-mpls@UU.NET  Wed Jan 23 07:47:30 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06473
	for <mpls-archive@lists.ietf.org>; Wed, 23 Jan 2002 07:47:30 -0500 (EST)
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 QQlzax21163;
	Wed, 23 Jan 2002 12:46:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzax21617
	for mpls-outgoing; Wed, 23 Jan 2002 12:46: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 QQlzax21594
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 12:46: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 QQlzax19403
	for <mpls@UU.NET>; Wed, 23 Jan 2002 12:46:04 GMT
From: sven.van_den_bosch@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 QQlzax20379
	for <mpls@UU.NET>; Wed, 23 Jan 2002 12:46:02 GMT
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0NCjhR16254;
	Wed, 23 Jan 2002 13:45:43 +0100 (MET)
Subject: Re: last call on hierarchy
To: Yakov Rekhter <yakov@juniper.net>
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF60811509.51A69250-ONC1256B4A.0045B187@net.alcatel.be>
Date: Wed, 23 Jan 2002 13:45:30 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/23/2002 13:45:43
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

Thanks for your clarifications. I look forward to the revised document.

Sven.





Yakov Rekhter <yakov@juniper.net> on 22/01/2002 17:34:56
                                                              
                                                              
                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          yakov@juniper.net, mpls@UU.NET,                
               yakov@juniper.net                              
                                                              
                                                              
                                                              
  Subject      Re: last call on hierarchy                     
  :                                                           
                                                              





Sven,

> I have added some additional comments to my original mail. Do you think
> these issues should be considered during the final revision of the
> document?

see in-line...

[clipped...]

> Sven>> Things brings up another question:Is it possible to use the exact
> same ERO hop sequence as the FA-LSP but still not use the FA-LSP
(supposing
> you want to use the FA-LSP for some LSPs and not for others)?
>
> > 2. Automatic setup of FA-LSP
> >
> > The draft says "Otherwise (if no existing FA-LSP is found), the LSR
sets
> > up a new FA-LSP.  That is, it initiates a new LSP setup just for the
> > FA-LSP."
> > I would like to clarify what happens when two FA-LSPs exist that, when
> > concatenated, can replace the new FA-LSP that is proposed to be set up
in
> > the quoted text.
> >
> > I would propose to say that the LSR may set up a new FA-LSP or
> > alternatively, it may replace the hop by a sequence of hops for which
FAs
> > are available.
>
> that would be ok, *provided* that the the strict hop subsequence
> from the ERO carried by the new LSP matches the one resulted from
> the concatenation of several FA-LSPs. Agreed ?
>
> Sven>> In the case that you describe I definitely agree.

Ok. So, I'll add the text to cover this.

>                                                          But I also saw
> another case where it is a loose hop over a region. In this case, instead
> of setting up a new FA-LSP you might want to use two existing FA-LSPs.
> Then, when there is no FA-LSP to the destination edge of the region
instead
> of making a new one you would need the freedom to expand the ERO using an
> intermediate node (another edge of the region which has a FA-LSP with
both
> edges in the original ERO). I tried to make a drawing below. I am not
sure
> the last situation ("desired") is allowed by the draft.
>
> input: explicit route A-B-C-D
>
> current network situation:
>                            A----B              C----D
>                                  \            /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
>
> new situation according to draft (there is no FA-LSP from B to C):
>                            A----B--------------C----D
>                                  \    FA3     /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
>
> desired new situation: expand ERO to A-B-X-C-D and leave network as is
>                            A----B              C----D
>                                  \            /
>                               FA1 \          / FA2
>                                    \        /
>                                      ---X---
>
> Sven.

That is also a valid case. I'll add the text to the document to
cover this case.

Yakov.





From owner-mpls@UU.NET  Wed Jan 23 10:02:01 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11276
	for <mpls-archive@lists.ietf.org>; Wed, 23 Jan 2002 10:02:01 -0500 (EST)
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 QQlzbg28821;
	Wed, 23 Jan 2002 15:00:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzbf11833
	for mpls-outgoing; Wed, 23 Jan 2002 14:59: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 QQlzbf11827
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 14:59: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 QQlzbf18497
	for <mpls@uu.net>; Wed, 23 Jan 2002 14:59:10 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzbf09248
	for <mpls@uu.net>; Wed, 23 Jan 2002 14:59:10 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 JAA15880 for <mpls@uu.net>; Wed, 23 Jan 2002 09:59:09 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22435 for mpls@uu.net; Wed, 23 Jan 2002 09:59:09 -0500 (EST)
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 QQlyzp04530
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 04:25: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 QQlyzp24025
	for <mpls@uu.net>; Wed, 23 Jan 2002 04:25:05 GMT
Received: from smtp.foundrynet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.foundrynet.com [63.251.100.14])
	id QQlyzp10689
	for <mpls@uu.net>; Wed, 23 Jan 2002 04:25:05 GMT
Received: from mailhost.foundrynet.com (mailhost [63.251.100.20])
	by smtp.foundrynet.com (8.11.6/FoundryNetworks) with ESMTP id g0N4P5U00617
	for <mpls@uu.net>; Tue, 22 Jan 2002 20:25:05 -0800
Received: from jqiu (ns100corpdmz.foundrynet.com [63.251.100.1])
	by mailhost.foundrynet.com (8.11.6/FoundryNetworks) with SMTP id g0N4P3124842
	for <mpls@uu.net>; Tue, 22 Jan 2002 20:25:04 -0800
From: "Zhun Jonathan Qiu" <zhunq@usa.net>
To: <mpls@UU.NET>
Subject: Question about LMp.21 in RFC3036
Date: Tue, 22 Jan 2002 20:25:22 -0800
Message-ID: <NEBBKGKBNKBAPMLKGBHPCEHKCKAA.zhunq@usa.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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, there, I guess this may have been discussed before and if that's case please direct me
to the thread.

In RFC3036, A.1.2 (Receive Label Mapping), when we reach LMp.21, we should have failed the
check in LMp.18, i.e. LSR has NOT previously sent a label mapping for FEC to the peer. So
at this point "PrevAdvLabel" should be undefined. Then how can LMp.21 uses it as a
parameter to "Send_Message"?

Do we need to allocate a new label and advertise at this point?

I think I must be missing something obvious. Please help me out then. Thanks a lot!

Regards,
Jonathan Zhun Qiu



From owner-mpls@UU.NET  Wed Jan 23 11:00:34 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13703
	for <mpls-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:00:34 -0500 (EST)
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 QQlzbj03481;
	Wed, 23 Jan 2002 15:56:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzbj06704
	for mpls-outgoing; Wed, 23 Jan 2002 15:56:13 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlzbj06693
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 15:56:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlzbj19385
	for <mpls@uu.net>; Wed, 23 Jan 2002 15:56:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzbj25176
	for <mpls@uu.net>; Wed, 23 Jan 2002 15:56:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25021 for <mpls@uu.net>; Wed, 23 Jan 2002 10:56:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA25536 for mpls@uu.net; Wed, 23 Jan 2002 10:56:01 -0500 (EST)
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 QQlzbj06577
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 15:55:49 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 QQlzbj15628
	for <mpls@UU.NET>; Wed, 23 Jan 2002 15:55:31 GMT
Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nero.doit.wisc.edu [128.104.17.130])
	id QQlzbj21422
	for <mpls@UU.NET>; Wed, 23 Jan 2002 15:55:30 GMT
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.9.3/8.9.3) id LAA28522;
	Wed, 23 Jan 2002 11:49:31 -0600
Date: Wed, 23 Jan 2002 11:49:31 -0600
From: "James R. Leu" <jleu@mindspring.com>
To: Zhun Jonathan Qiu <zhunq@usa.net>
Cc: mpls@UU.NET
Subject: Re: Question about LMp.21 in RFC3036
Message-ID: <20020123114931.B28504@nero.doit.wisc.edu>
Reply-To: jleu@mindspring.com
References: <NEBBKGKBNKBAPMLKGBHPCEHKCKAA.zhunq@usa.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <NEBBKGKBNKBAPMLKGBHPCEHKCKAA.zhunq@usa.net>; from zhunq@usa.net on Tue, Jan 22, 2002 at 08:25:22PM -0800
Organization: none
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, Jan 22, 2002 at 08:25:22PM -0800, Zhun Jonathan Qiu wrote:
> Hi, there, I guess this may have been discussed before and if that's case please direct me
> to the thread.
> 
> In RFC3036, A.1.2 (Receive Label Mapping), when we reach LMp.21, we should have failed the
> check in LMp.18, i.e. LSR has NOT previously sent a label mapping for FEC to the peer. So
> at this point "PrevAdvLabel" should be undefined. Then how can LMp.21 uses it as a
> parameter to "Send_Message"?
> 
> Do we need to allocate a new label and advertise at this point?
> 
> I think I must be missing something obvious. Please help me out then. Thanks a lot!
> 

My interpretation is:

An LSR may have advertised a label for this FEC to another peer.  In which 
case the LSR can advertise the same label or advertise another label and 
merge the two.

In other words the check in LMp.18 has nothing to do with 'PrevAdvLabel'.

Jim

> Regards,
> Jonathan Zhun Qiu

-- 
James R. Leu



From owner-mpls@UU.NET  Wed Jan 23 13:29:47 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19486
	for <mpls-archive@lists.ietf.org>; Wed, 23 Jan 2002 13:29:47 -0500 (EST)
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 QQlzbt27477;
	Wed, 23 Jan 2002 18:23:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzbt18675
	for mpls-outgoing; Wed, 23 Jan 2002 18:23: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 QQlzbt18670
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 18:23:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlzbt18874
	for <mpls@uu.net>; Wed, 23 Jan 2002 18:21:19 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzbt24012
	for <mpls@uu.net>; Wed, 23 Jan 2002 18:21:19 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 NAA13790 for <mpls@uu.net>; Wed, 23 Jan 2002 13:21:19 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02231 for mpls@uu.net; Wed, 23 Jan 2002 13:21:19 -0500 (EST)
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 QQlzbs17753
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 23 Jan 2002 18:12:48 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 QQlzbs04550
	for <mpls@UU.NET>; Wed, 23 Jan 2002 18:12:23 GMT
Received: from smtp.foundrynet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.foundrynet.com [63.251.100.14])
	id QQlzbs11406
	for <mpls@UU.NET>; Wed, 23 Jan 2002 18:12:23 GMT
Received: from mailhost.foundrynet.com (mailhost [63.251.100.20])
	by smtp.foundrynet.com (8.11.6/FoundryNetworks) with ESMTP id g0NICMU23512;
	Wed, 23 Jan 2002 10:12:23 -0800
Received: from jqiu (ns100corpdmz.foundrynet.com [63.251.100.1])
	by mailhost.foundrynet.com (8.11.6/FoundryNetworks) with SMTP id g0NICM115064;
	Wed, 23 Jan 2002 10:12:22 -0800
From: "Zhun Jonathan Qiu" <zhunq@usa.net>
To: <jleu@mindspring.com>
Cc: <mpls@UU.NET>
Subject: RE: Question about LMp.21 in RFC3036
Date: Wed, 23 Jan 2002 10:12:39 -0800
Message-ID: <NEBBKGKBNKBAPMLKGBHPEEHPCKAA.zhunq@usa.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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <20020123114931.B28504@nero.doit.wisc.edu>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thank you for your reply James! This helps a lot. However, one more question is, if at
this point the LSR hasn't advertised any label for this FEC to any peer, what would be the
value of "PrevAdvLabel" then?

Regards,
Jonathan Zhun Qiu


-----Original Message-----
From: James R. Leu [mailto:jleu@mindspring.com]
Sent: Wednesday, January 23, 2002 9:50 AM
To: Zhun Jonathan Qiu
Cc: mpls@UU.NET
Subject: Re: Question about LMp.21 in RFC3036


On Tue, Jan 22, 2002 at 08:25:22PM -0800, Zhun Jonathan Qiu wrote:
> Hi, there, I guess this may have been discussed before and if that's case please direct
me
> to the thread.
>
> In RFC3036, A.1.2 (Receive Label Mapping), when we reach LMp.21, we should have failed
the
> check in LMp.18, i.e. LSR has NOT previously sent a label mapping for FEC to the peer.
So
> at this point "PrevAdvLabel" should be undefined. Then how can LMp.21 uses it as a
> parameter to "Send_Message"?
>
> Do we need to allocate a new label and advertise at this point?
>
> I think I must be missing something obvious. Please help me out then. Thanks a lot!
>

My interpretation is:

An LSR may have advertised a label for this FEC to another peer.  In which
case the LSR can advertise the same label or advertise another label and
merge the two.

In other words the check in LMp.18 has nothing to do with 'PrevAdvLabel'.

Jim

> Regards,
> Jonathan Zhun Qiu

--
James R. Leu



From owner-mpls@UU.NET  Thu Jan 24 08:25:00 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20874
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 08:25:00 -0500 (EST)
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 QQlzer00312;
	Thu, 24 Jan 2002 13:24:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzer03719
	for mpls-outgoing; Thu, 24 Jan 2002 13:23: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 QQlzer03714
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 13:23:45 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 QQlzer03151
	for <mpls@uu.net>; Thu, 24 Jan 2002 13:22:40 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 QQlzer19530
	for <mpls@uu.net>; Thu, 24 Jan 2002 13:22:39 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0ODMXs08396
	for <mpls@uu.net>; Thu, 24 Jan 2002 14:22:34 +0100 (MET)
To: mpls@UU.NET
Subject: mpls lsr mib
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE4D6357F.F3523952-ONC1256B4B.00490E39@net.alcatel.be>
Date: Thu, 24 Jan 2002 14:22:28 +0100
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/24/2002 14:22:33,
	Serialize complete at 01/24/2002 14:22:33
Content-Type: multipart/alternative; boundary="=_alternative 0049752FC1256B4B_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0049752FC1256B4B_=
Content-Type: text/plain; charset="us-ascii"

Hello Tom et all,

I have a question on the mplsInterfaceConfTable in the mpls lsr mib. 
IAssume that we consider the following:
* Per interface label space used for RSVP signalled LSPs and static LSPs.
* Global label space used for LDP signalled LSPs.

Which value should we then give to the mplsInterfaceLabelMinIn:
* The min label value of the per interface label space (that is, the min 
label value from the RSVP signalled LSPs and the static LSPs)?
* The min label value of the RSVP signalled LSPs.
* The min label value of all LSPs on the interface (=min of all LDP 
signalled, RSVP signalled and static LSPs).

I would appreciate any help you can give me.

Kind regards,

        Francis.

--------------------------------

mplsInterfaceLabelMinIn OBJECT-TYPE
   SYNTAX        MplsLabel
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This is the minimum value of an MPLS label that this
        LSR is willing to receive on this interface."
   ::= { mplsInterfaceConfEntry 2 }

--=_alternative 0049752FC1256B4B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello Tom et all,</font>
<br>
<br><font size=2 face="sans-serif">I have a question on the mplsInterfaceConfTable in the mpls lsr mib. IAssume that we consider the following:</font>
<br><font size=2 face="sans-serif">* Per interface label space used for RSVP signalled LSPs and static LSPs.</font>
<br><font size=2 face="sans-serif">* Global label space used for LDP signalled LSPs.</font>
<br>
<br><font size=2 face="sans-serif">Which value should we then give to the mplsInterfaceLabelMinIn:</font>
<br><font size=2 face="sans-serif">* The min label value of the per interface label space (that is, the min label value from the RSVP signalled LSPs and the static LSPs)?</font>
<br><font size=2 face="sans-serif">* The min label value of the RSVP signalled LSPs.</font>
<br><font size=2 face="sans-serif">* The min label value of all LSPs on the interface (=min of all LDP signalled, RSVP signalled and static LSPs).</font>
<br>
<br><font size=2 face="sans-serif">I would appreciate any help you can give me.</font>
<br>
<br><font size=2 face="sans-serif">Kind regards,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
<br>
<br><font size=2 face="sans-serif">--------------------------------</font>
<br>
<br><font size=2 face="sans-serif">mplsInterfaceLabelMinIn OBJECT-TYPE</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;SYNTAX &nbsp; &nbsp; &nbsp; &nbsp;MplsLabel</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;MAX-ACCESS &nbsp; &nbsp;read-only</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp; &nbsp;current</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;DESCRIPTION</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&quot;This is the minimum value of an MPLS label that this</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; LSR is willing to receive on this interface.&quot;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;::= { mplsInterfaceConfEntry 2 }</font>
<br>
--=_alternative 0049752FC1256B4B_=--


From owner-mpls@UU.NET  Thu Jan 24 09:32:50 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22278
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 09:32:50 -0500 (EST)
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 QQlzew27271;
	Thu, 24 Jan 2002 14:30:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzev29168
	for mpls-outgoing; Thu, 24 Jan 2002 14:29: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 QQlzev29159
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 14:29: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 QQlzev28053
	for <mpls@uu.net>; Thu, 24 Jan 2002 14:29:33 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe14.law9.hotmail.com [64.4.8.118])
	id QQlzev26201
	for <mpls@uu.net>; Thu, 24 Jan 2002 14:29:33 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 24 Jan 2002 06:29:32 -0800
X-Originating-IP: [212.25.110.131]
From: "Doug Degan" <doug_degan@hotmail.com>
To: <mpls@UU.NET>
Subject: fast reroute ?(draft-pan-rsvp-fastreroute-00.txt)
Date: Thu, 24 Jan 2002 16:29:31 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0062_01C1A4F4.4CFB2EF0"
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
Message-ID: <OE14AhN7xrQSVbBTouL00006c25@hotmail.com>
X-OriginalArrivalTime: 24 Jan 2002 14:29:32.0647 (UTC) FILETIME=[8A36E770:01C1A4E3]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C1A4F4.4CFB2EF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi.
I joined this mailing-list just today.=20
and I have a question regarding the above draft:

in 4.3 the first "-" : it is said that when 'protection desired' flag is =
set, the PLR should choose the bypass tunnel.

my question - I think that the choosing should be upon receiving a =
"Resv" message (and have in the RRO the needed information such as =
ignore-node, and label to stick to the merge-point router)

while the SESSION_ATTRIBUTE not belong to the Resv message but to the =
Path message.

how do you solve it? and shouldn't it be explained in this draft??


    douglas.

------=_NextPart_000_0062_01C1A4F4.4CFB2EF0
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I joined this mailing-list just today.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and I have a question regarding the =
above=20
draft:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>in 4.3 the first "-" : it is said that =
when=20
'protection desired' flag is set, the PLR should choose the bypass=20
tunnel.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>my question - I think that the choosing =
should be=20
upon receiving a "Resv" message (and have in the RRO the needed =
information such=20
as ignore-node, and label to stick to the merge-point =
router)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>while the SESSION_ATTRIBUTE not belong =
to the Resv=20
message but to the Path message.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>how do you solve it? and shouldn't it =
be explained=20
in this draft??</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
douglas.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0062_01C1A4F4.4CFB2EF0--


From owner-mpls@UU.NET  Thu Jan 24 09:34:24 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22335
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 09:34:23 -0500 (EST)
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 QQlzew00937;
	Thu, 24 Jan 2002 14:32:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzew29444
	for mpls-outgoing; Thu, 24 Jan 2002 14:32: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 QQlzew29428
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 14:32:01 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 QQlzew05219
	for <mpls@uu.net>; Thu, 24 Jan 2002 14:31:04 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzew01817
	for <mpls@uu.net>; Thu, 24 Jan 2002 14:31:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA12667 for <mpls@uu.net>; Thu, 24 Jan 2002 09:31:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24803 for mpls@uu.net; Thu, 24 Jan 2002 09:31:02 -0500 (EST)
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 QQlzew29237
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 14:30:48 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 QQlzev12180
	for <mpls@UU.NET>; Thu, 24 Jan 2002 14:29:25 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzev29390
	for <mpls@UU.NET>; Thu, 24 Jan 2002 14:29:24 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA12527; Thu, 24 Jan 2002 09:29:24 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAL87559;
	Thu, 24 Jan 2002 09:29:23 -0500 (EST)
Message-Id: <4.3.2.7.2.20020124092247.01ffd2a0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 Jan 2002 09:29:10 -0500
To: francis.arts@alcatel.be
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: mpls lsr mib
Cc: mpls@UU.NET
In-Reply-To: <OFE4D6357F.F3523952-ONC1256B4B.00490E39@net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



>Hello Tom et all,
>
>I have a question on the mplsInterfaceConfTable in the mpls lsr mib. 
>IAssume that we consider the following:
>* Per interface label space used for RSVP signalled LSPs and static LSPs.
>* Global label space used for LDP signalled LSPs.

         First, how can you use two different label spaces to advertise over
the same interface?  I have never heard of this behavior before. One
assigns a per-interface label range that is unique for that interface
only, no?

         --Tom


>Which value should we then give to the mplsInterfaceLabelMinIn:
>* The min label value of the per interface label space (that is, the min 
>label value from the RSVP signalled LSPs and the static LSPs)?
>* The min label value of the RSVP signalled LSPs.
>* The min label value of all LSPs on the interface (=min of all LDP 
>signalled, RSVP signalled and static LSPs).
>
>I would appreciate any help you can give me.
>
>Kind regards,
>
>         Francis.
>
>--------------------------------
>
>mplsInterfaceLabelMinIn OBJECT-TYPE
>    SYNTAX        MplsLabel
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "This is the minimum value of an MPLS label that this
>         LSR is willing to receive on this interface."
>    ::= { mplsInterfaceConfEntry 2 }



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



From owner-mpls@UU.NET  Thu Jan 24 10:01:37 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22862
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 10:01:37 -0500 (EST)
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 QQlzex07598;
	Thu, 24 Jan 2002 14:55:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzex01303
	for mpls-outgoing; Thu, 24 Jan 2002 14:55: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 QQlzex01298
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 14:55: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 QQlzex11418
	for <mpls@UU.NET>; Thu, 24 Jan 2002 14:54:43 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 QQlzex01057
	for <mpls@UU.NET>; Thu, 24 Jan 2002 14:54:42 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0OEsVc04611;
	Thu, 24 Jan 2002 15:54:31 +0100 (MET)
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: mpls@UU.NET
Subject: Re: mpls lsr mib
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFA086B891.212272F3-ONC1256B4B.00511314@net.alcatel.be>
Date: Thu, 24 Jan 2002 15:54:24 +0100
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/24/2002 15:54:31,
	Serialize complete at 01/24/2002 15:54:31
Content-Type: multipart/alternative; boundary="=_alternative 0051DFB4C1256B4B_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0051DFB4C1256B4B_=
Content-Type: text/plain; charset="us-ascii"

Tom,

> First, how can you use two different label spaces to advertise over
> the same interface?  I have never heard of this behavior before. One
> assigns a per-interface label range that is unique for that interface
> only, no?

The idea is to split the label range in 2 partitions that are mutually 
exclusive -1 partition for the per interface label space and 1 partition 
for the global label range. My understanding is that this behavior is also 
supported in the mpls lsr mib where the 
mplsInterfaceLabelParticipationType obejct has then both its perPlatform 
and perInterface set for each ifIndex /= 0.

For example:
* For a static LSP we will use a label from the per interface label space.
* For an LDP established LSP we will use a global label (==> so for LDP we 
will only advertise the global label space).


But the point that this not clear to me, is how the mplsInterfaceLabelMinIn object in the mpls lsr mib should be set in the above approach.

Best regards,

        Francis.

-----------------------------------





"Thomas D. Nadeau" <tnadeau@cisco.com>
24/01/2002 15:29

 
        To:     Francis ARTS/BE/ALCATEL@ALCATEL
        cc:     mpls@UU.NET
        Subject:        Re: mpls lsr mib




>Hello Tom et all,
>
>I have a question on the mplsInterfaceConfTable in the mpls lsr mib. 
>IAssume that we consider the following:
>* Per interface label space used for RSVP signalled LSPs and static LSPs.
>* Global label space used for LDP signalled LSPs.

         First, how can you use two different label spaces to advertise 
over
the same interface?  I have never heard of this behavior before. One
assigns a per-interface label range that is unique for that interface
only, no?

         --Tom


>Which value should we then give to the mplsInterfaceLabelMinIn:
>* The min label value of the per interface label space (that is, the min 
>label value from the RSVP signalled LSPs and the static LSPs)?
>* The min label value of the RSVP signalled LSPs.
>* The min label value of all LSPs on the interface (=min of all LDP 
>signalled, RSVP signalled and static LSPs).
>
>I would appreciate any help you can give me.
>
>Kind regards,
>
>         Francis.
>
>--------------------------------
>
>mplsInterfaceLabelMinIn OBJECT-TYPE
>    SYNTAX        MplsLabel
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "This is the minimum value of an MPLS label that this
>         LSR is willing to receive on this interface."
>    ::= { mplsInterfaceConfEntry 2 }



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




--=_alternative 0051DFB4C1256B4B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Tom,</font>
<br><font size=2 face="Courier New"><br>
&gt; First, how can you use two different label spaces to advertise over<br>
&gt; the same interface? &nbsp;I have never heard of this behavior before. One<br>
&gt; assigns a per-interface label range that is unique for that interface<br>
&gt; only, no?</font>
<br>
<br><font size=2 face="sans-serif">The idea is to split the label range in 2 partitions that are mutually exclusive -1 partition for the per interface label space and 1 partition for the global label range. My understanding is that this behavior is also supported in the mpls lsr mib where the mplsInterfaceLabelParticipationType obejct has then both its perPlatform and perInterface set for each ifIndex /= 0.</font>
<br>
<br><font size=2 face="sans-serif">For example:</font>
<br><font size=2 face="sans-serif">* For a static LSP we will use a label from the per interface label space.</font>
<br><font size=2 face="sans-serif">* For an LDP established LSP we will use a global label (==&gt; so for LDP we will only advertise the global label space).</font>
<br>
<br>
<br><font size=2 face="sans-serif">But the point that this not clear to me, is how the </font><font size=2 face="Courier New">mplsInterfaceLabelMinIn </font><font size=2 face="sans-serif">object in the mpls lsr mib should be set in the above approach.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
<br>
<br><font size=2 face="sans-serif">-----------------------------------</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Thomas D. Nadeau&quot; &lt;tnadeau@cisco.com&gt;</b></font>
<p><font size=1 face="sans-serif">24/01/2002 15:29</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Francis ARTS/BE/ALCATEL@ALCATEL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;mpls@UU.NET</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: mpls lsr mib</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
<br>
&gt;Hello Tom et all,<br>
&gt;<br>
&gt;I have a question on the mplsInterfaceConfTable in the mpls lsr mib. <br>
&gt;IAssume that we consider the following:<br>
&gt;* Per interface label space used for RSVP signalled LSPs and static LSPs.<br>
&gt;* Global label space used for LDP signalled LSPs.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; First, how can you use two different label spaces to advertise over<br>
the same interface? &nbsp;I have never heard of this behavior before. One<br>
assigns a per-interface label range that is unique for that interface<br>
only, no?<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; --Tom<br>
<br>
<br>
&gt;Which value should we then give to the mplsInterfaceLabelMinIn:<br>
&gt;* The min label value of the per interface label space (that is, the min <br>
&gt;label value from the RSVP signalled LSPs and the static LSPs)?<br>
&gt;* The min label value of the RSVP signalled LSPs.<br>
&gt;* The min label value of all LSPs on the interface (=min of all LDP <br>
&gt;signalled, RSVP signalled and static LSPs).<br>
&gt;<br>
&gt;I would appreciate any help you can give me.<br>
&gt;<br>
&gt;Kind regards,<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Francis.<br>
&gt;<br>
&gt;--------------------------------<br>
&gt;<br>
&gt;mplsInterfaceLabelMinIn OBJECT-TYPE<br>
&gt; &nbsp; &nbsp;SYNTAX &nbsp; &nbsp; &nbsp; &nbsp;MplsLabel<br>
&gt; &nbsp; &nbsp;MAX-ACCESS &nbsp; &nbsp;read-only<br>
&gt; &nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp; &nbsp;current<br>
&gt; &nbsp; &nbsp;DESCRIPTION<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;&quot;This is the minimum value of an MPLS label that this<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; LSR is willing to receive on this interface.&quot;<br>
&gt; &nbsp; &nbsp;::= { mplsInterfaceConfEntry 2 }<br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
Mathematics is the supreme nostalgia of our time. <br>
<br>
</font>
<br>
<br>
--=_alternative 0051DFB4C1256B4B_=--


From owner-mpls@UU.NET  Thu Jan 24 10:05:08 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22941
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 10:05:08 -0500 (EST)
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 QQlzey10915;
	Thu, 24 Jan 2002 15:01:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzey06246
	for mpls-outgoing; Thu, 24 Jan 2002 15:01: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 QQlzey06139
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 15:01: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 QQlzey22943
	for <mpls@UU.NET>; Thu, 24 Jan 2002 15:01:11 GMT
Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQlzey17255
	for <mpls@UU.NET>; Thu, 24 Jan 2002 15:01:11 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 g0OF0sR08545;
	Thu, 24 Jan 2002 10:00:54 -0500 (EST)
Message-Id: <4.1.20020124095709.009f8dc0@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 24 Jan 2002 09:59:48 -0600
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: mpls lsr mib
Cc: francis.arts@alcatel.be, mpls@UU.NET
In-Reply-To: <4.3.2.7.2.20020124092247.01ffd2a0@bucket.cisco.com>
References: <OFE4D6357F.F3523952-ONC1256B4B.00490E39@net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:29 AM 1/24/02 -0500, Thomas D. Nadeau wrote:
>
>
>>Hello Tom et all,
>>
>>I have a question on the mplsInterfaceConfTable in the mpls lsr mib. 
>>IAssume that we consider the following:
>>* Per interface label space used for RSVP signalled LSPs and static LSPs.
>>* Global label space used for LDP signalled LSPs.
>
>         First, how can you use two different label spaces to advertise over
>the same interface?  I have never heard of this behavior before. One
>assigns a per-interface label range that is unique for that interface
>only, no?

Having LDP use global labels while RSVP-TE LSPs use per interface labels is
reasonable; certainly, I've heard of it before.  One can partition the
label range given out, so that one range is for the global labels, while
the other is for per-interface.

Alia

>>Which value should we then give to the mplsInterfaceLabelMinIn:
>>* The min label value of the per interface label space (that is, the min 
>>label value from the RSVP signalled LSPs and the static LSPs)?
>>* The min label value of the RSVP signalled LSPs.
>>* The min label value of all LSPs on the interface (=min of all LDP 
>>signalled, RSVP signalled and static LSPs).
>>
>>I would appreciate any help you can give me.
>>
>>Kind regards,
>>
>>         Francis.
>>
>>--------------------------------
>>
>>mplsInterfaceLabelMinIn OBJECT-TYPE
>>    SYNTAX        MplsLabel
>>    MAX-ACCESS    read-only
>>    STATUS        current
>>    DESCRIPTION
>>        "This is the minimum value of an MPLS label that this
>>         LSR is willing to receive on this interface."
>>    ::= { mplsInterfaceConfEntry 2 }
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time. 
>




From owner-mpls@UU.NET  Thu Jan 24 10:49:37 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24301
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 10:49:36 -0500 (EST)
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 QQlzfb05543;
	Thu, 24 Jan 2002 15:45:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfb25429
	for mpls-outgoing; Thu, 24 Jan 2002 15:45: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 QQlzfb25424
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 15:45: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 QQlzfb06927
	for <mpls@uu.net>; Thu, 24 Jan 2002 15:45:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzfb04126
	for <mpls@uu.net>; Thu, 24 Jan 2002 15:45:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21896 for <mpls@uu.net>; Thu, 24 Jan 2002 10:45:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29236 for mpls@uu.net; Thu, 24 Jan 2002 10:45:02 -0500 (EST)
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 QQlzfa25301
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 15: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 QQlzfa15217
	for <mpls@UU.NET>; Thu, 24 Jan 2002 15:44:07 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzfa02839
	for <mpls@UU.NET>; Thu, 24 Jan 2002 15:44:07 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21595; Thu, 24 Jan 2002 10:44:06 -0500 (EST)
Received: from tnadeau1-w2k.cisco.com (ch2-dhcp134-252.cisco.com [161.44.134.252])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAL88820;
	Thu, 24 Jan 2002 10:44:05 -0500 (EST)
Message-Id: <4.3.2.7.2.20020124104151.01d54898@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 24 Jan 2002 10:43:57 -0500
To: Alia Atlas <aatlas@avici.com>
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: Re: mpls lsr mib
Cc: francis.arts@alcatel.be, mpls@UU.NET
In-Reply-To: <4.1.20020124095709.009f8dc0@mailhost.avici.com>
References: <4.3.2.7.2.20020124092247.01ffd2a0@bucket.cisco.com>
 <OFE4D6357F.F3523952-ONC1256B4B.00490E39@net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk



> >>Hello Tom et all,
> >>
> >>I have a question on the mplsInterfaceConfTable in the mpls lsr mib.
> >>IAssume that we consider the following:
> >>* Per interface label space used for RSVP signalled LSPs and static LSPs.
> >>* Global label space used for LDP signalled LSPs.
> >
> >         First, how can you use two different label spaces to advertise over
> >the same interface?  I have never heard of this behavior before. One
> >assigns a per-interface label range that is unique for that interface
> >only, no?
>
>Having LDP use global labels while RSVP-TE LSPs use per interface labels is
>reasonable; certainly, I've heard of it before.  One can partition the
>label range given out, so that one range is for the global labels, while
>the other is for per-interface.

         Yes, it is within the realm of possibility to configure your label
ranges that way. However, what you are talking about is per-application
label space configuration, which is not what the MIB variable is getting at.
It is used to represent per-interface label range configuration or per-platform
label range configuration. These values are configured on interfaces, not on
applications. If you want to divide up the range further (i.e.: per 
application),
that is something the MIB was not intended to do.

         --Tom



>Alia
>
> >>Which value should we then give to the mplsInterfaceLabelMinIn:
> >>* The min label value of the per interface label space (that is, the min
> >>label value from the RSVP signalled LSPs and the static LSPs)?
> >>* The min label value of the RSVP signalled LSPs.
> >>* The min label value of all LSPs on the interface (=min of all LDP
> >>signalled, RSVP signalled and static LSPs).
> >>
> >>I would appreciate any help you can give me.
> >>
> >>Kind regards,
> >>
> >>         Francis.
> >>
> >>--------------------------------
> >>
> >>mplsInterfaceLabelMinIn OBJECT-TYPE
> >>    SYNTAX        MplsLabel
> >>    MAX-ACCESS    read-only
> >>    STATUS        current
> >>    DESCRIPTION
> >>        "This is the minimum value of an MPLS label that this
> >>         LSR is willing to receive on this interface."
> >>    ::= { mplsInterfaceConfEntry 2 }
> >
> >
> >
> >------------------------------------------------------------------------
> >Mathematics is the supreme nostalgia of our time.
> >



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



From owner-mpls@UU.NET  Thu Jan 24 10:57:40 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24660
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 10:57:39 -0500 (EST)
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 QQlzfb18893;
	Thu, 24 Jan 2002 15:54:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfb26118
	for mpls-outgoing; Thu, 24 Jan 2002 15:53: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 QQlzfb26111
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 15:53: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 QQlzfb17754
	for <mpls@uu.net>; Thu, 24 Jan 2002 15:53:12 GMT
Received: from [172.16.1.19] by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.opnet.com [12.145.55.7])
	id QQlzfb17335
	for <mpls@uu.net>; Thu, 24 Jan 2002 15:53:11 GMT
Received: from wtn10216.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58a4895bfcac100113534@>;
 Thu, 24 Jan 2002 10:53:07 -0500
Message-Id: <5.0.0.25.2.20020124105144.030f82c0@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Jan 2002 10:52:01 -0500
To: "Doug Degan" <doug_degan@hotmail.com>, <mpls@UU.NET>
From: Sachin Kalra <skalra@opnet.com>
Subject: Re: fast reroute ?(draft-pan-rsvp-fastreroute-00.txt)
In-Reply-To: <OE14AhN7xrQSVbBTouL00006c25@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_79408082==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_79408082==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Douglas:

Session Object is maintained in PATH state at PLR. When "Resv" Message is 
received at the PLR, the Session Object is accessed from the matching PATH 
State and Bypass Tunnel is chosen accordingly.

Hope this helps,
Sachin Kalra

At 04:29 PM 1/24/02 +0200, Doug Degan wrote:
>hi.
>I joined this mailing-list just today.
>and I have a question regarding the above draft:
>
>in 4.3 the first "-" : it is said that when 'protection desired' flag is 
>set, the PLR should choose the bypass tunnel.
>
>my question - I think that the choosing should be upon receiving a "Resv" 
>message (and have in the RRO the needed information such as ignore-node, 
>and label to stick to the merge-point router)
>
>while the SESSION_ATTRIBUTE not belong to the Resv message but to the Path 
>message.
>
>how do you solve it? and shouldn't it be explained in this draft??
>
>
>     douglas.

===========================================================
Sachin Kalra
Modeling Engineer
OPNET Technologies, Inc.
(240)-497-3000 x2796
===========================================================


--=====================_79408082==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Douglas:<br>
<br>
Session Object is maintained in PATH state at PLR. When &quot;Resv&quot;
Message is received at the PLR, the Session Object is accessed from the
matching PATH State and Bypass Tunnel is chosen accordingly.<br>
<br>
Hope this helps,<br>
Sachin Kalra<br>
<br>
At 04:29 PM 1/24/02 +0200, Doug Degan wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>hi.</font><br>
<font face="arial" size=2>I joined this mailing-list just today.
</font><br>
<font face="arial" size=2>and I have a question regarding the above
draft:</font><br>
&nbsp;<br>
<font face="arial" size=2>in 4.3 the first &quot;-&quot; : it is said
that when 'protection desired' flag is set, the PLR should choose the
bypass tunnel.</font><br>
&nbsp;<br>
<font face="arial" size=2>my question - I think that the choosing should
be upon receiving a &quot;Resv&quot; message (and have in the RRO the
needed information such as ignore-node, and label to stick to the
merge-point router)</font><br>
&nbsp;<br>
<font face="arial" size=2>while the SESSION_ATTRIBUTE not belong to the
Resv message but to the Path message.</font><br>
&nbsp;<br>
<font face="arial" size=2>how do you solve it? and shouldn't it be
explained in this draft??</font><br>
&nbsp;<br>
&nbsp;<br>
<font face="arial" size=2>&nbsp;&nbsp;&nbsp;
douglas.</font></blockquote>
<x-sigsep><p></x-sigsep>
===========================================================<br>
Sachin Kalra<br>
Modeling Engineer<br>
OPNET Technologies, Inc.<br>
(240)-497-3000 x2796<br>
===========================================================<br>
<br>
</html>

--=====================_79408082==_.ALT--



From owner-mpls@UU.NET  Thu Jan 24 11:06:55 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25136
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 11:06:55 -0500 (EST)
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 QQlzfc05376;
	Thu, 24 Jan 2002 16:03:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfc07787
	for mpls-outgoing; Thu, 24 Jan 2002 16:03:11 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlzfc07780
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 16:03:08 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 QQlzfc17918
	for <mpls@UU.NET>; Thu, 24 Jan 2002 16:02:49 GMT
Received: from smtp016.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp016.mail.yahoo.com [216.136.174.113])
	id QQlzfc04552
	for <mpls@UU.NET>; Thu, 24 Jan 2002 16:02:49 GMT
Received: from va-blacksburg1b-214.chvlva.adelphia.net (HELO 1i2in) (68.64.32.214)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Jan 2002 16:02:47 -0000
Message-ID: <006d01c1a4f0$64f700a0$d6204044@chvlva.adelphia.net>
Reply-To: "rajneesh mahajan" <rajneesh_vt@yahoo.com>
From: "rajneesh mahajan" <rajneesh_vt@yahoo.com>
To: <mpls@UU.NET>
References: <OFE4D6357F.F3523952-ONC1256B4B.00490E39@net.alcatel.be>
Subject: Re: mpls lsr mib
Date: Thu, 24 Jan 2002 11:01:10 -0500
Organization: Virginia Tech
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0066_01C1A4C6.6E3F3300"
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_0066_01C1A4C6.6E3F3300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I had a similar problem while implementing this MIB few months back and =
I decided that we should give label range for RSVP and statically =
signalled LSPs (which was per interface as in your case).  LDP label =
range could be obtained from LDP MIB.  Please correct me if I am wrong.

-Rajneesh
  ----- Original Message -----=20
  From: francis.arts@alcatel.be=20
  To: mpls@UU.NET=20
  Sent: Thursday, January 24, 2002 8:22 AM
  Subject: mpls lsr mib



  Hello Tom et all,=20

  I have a question on the mplsInterfaceConfTable in the mpls lsr mib. =
IAssume that we consider the following:=20
  * Per interface label space used for RSVP signalled LSPs and static =
LSPs.=20
  * Global label space used for LDP signalled LSPs.=20

  Which value should we then give to the mplsInterfaceLabelMinIn:=20
  * The min label value of the per interface label space (that is, the =
min label value from the RSVP signalled LSPs and the static LSPs)?=20
  * The min label value of the RSVP signalled LSPs.=20
  * The min label value of all LSPs on the interface (=3Dmin of all LDP =
signalled, RSVP signalled and static LSPs).=20

  I would appreciate any help you can give me.=20

  Kind regards,=20

          Francis.=20

  --------------------------------=20

  mplsInterfaceLabelMinIn OBJECT-TYPE=20
     SYNTAX        MplsLabel=20
     MAX-ACCESS    read-only=20
     STATUS        current=20
     DESCRIPTION=20
         "This is the minimum value of an MPLS label that this=20
          LSR is willing to receive on this interface."=20
     ::=3D { mplsInterfaceConfEntry 2 }=20


------=_NextPart_000_0066_01C1A4C6.6E3F3300
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.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I had a similar problem while =
implementing this MIB=20
few months back and&nbsp;I decided that we&nbsp;should give label range =
for RSVP=20
and statically signalled LSPs (which was per interface as in your =
case).&nbsp;=20
LDP label range could be obtained from LDP MIB.&nbsp; Please correct me =
if I am=20
wrong.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Rajneesh</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dfrancis.arts@alcatel.be=20
  href=3D"mailto:francis.arts@alcatel.be">francis.arts@alcatel.be</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dmpls@UU.NET=20
  href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 24, =
2002 8:22=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> mpls lsr mib</DIV>
  <DIV><BR></DIV><BR><FONT face=3Dsans-serif size=3D2>Hello Tom et =
all,</FONT>=20
  <BR><BR><FONT face=3Dsans-serif size=3D2>I have a question on the=20
  mplsInterfaceConfTable in the mpls lsr mib. IAssume that we consider =
the=20
  following:</FONT> <BR><FONT face=3Dsans-serif size=3D2>* Per interface =
label space=20
  used for RSVP signalled LSPs and static LSPs.</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>* Global label space used for LDP signalled LSPs.</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D2>Which value should we then give to the=20
  mplsInterfaceLabelMinIn:</FONT> <BR><FONT face=3Dsans-serif size=3D2>* =
The min=20
  label value of the per interface label space (that is, the min label =
value=20
  from the RSVP signalled LSPs and the static LSPs)?</FONT> <BR><FONT=20
  face=3Dsans-serif size=3D2>* The min label value of the RSVP signalled =

  LSPs.</FONT> <BR><FONT face=3Dsans-serif size=3D2>* The min label =
value of all=20
  LSPs on the interface (=3Dmin of all LDP signalled, RSVP signalled and =
static=20
  LSPs).</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>I would =
appreciate any help=20
  you can give me.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Kind=20
  regards,</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp; =
&nbsp;=20
  &nbsp; Francis.</FONT> <BR><BR><FONT face=3Dsans-serif=20
  size=3D2>--------------------------------</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
  size=3D2>mplsInterfaceLabelMinIn OBJECT-TYPE</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp;SYNTAX &nbsp; &nbsp; &nbsp; =
&nbsp;MplsLabel</FONT>=20
  <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp;MAX-ACCESS &nbsp;=20
  &nbsp;read-only</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; =
&nbsp;STATUS=20
  &nbsp; &nbsp; &nbsp; &nbsp;current</FONT> <BR><FONT face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp;DESCRIPTION</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>&nbsp;=20
  &nbsp; &nbsp; &nbsp;"This is the minimum value of an MPLS label that=20
  this</FONT> <BR><FONT face=3Dsans-serif size=3D2>&nbsp; &nbsp; &nbsp; =
&nbsp; LSR=20
  is willing to receive on this interface."</FONT> <BR><FONT =
face=3Dsans-serif=20
  size=3D2>&nbsp; &nbsp;::=3D { mplsInterfaceConfEntry 2 }</FONT>=20
<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0066_01C1A4C6.6E3F3300--


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-mpls@UU.NET  Thu Jan 24 11:14:47 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25462
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 11:14:43 -0500 (EST)
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 QQlzfc13404;
	Thu, 24 Jan 2002 16:06:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfc16481
	for mpls-outgoing; Thu, 24 Jan 2002 16:06: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 QQlzfc16336
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 16:06: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 QQlzfc17422
	for <mpls@UU.NET>; Thu, 24 Jan 2002 16:05:42 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 QQlzfc06733
	for <mpls@UU.NET>; Thu, 24 Jan 2002 16:05:41 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0OG5F623179;
	Thu, 24 Jan 2002 17:05:15 +0100 (MET)
To: "Thomas D. Nadeau" <tnadeau@cisco.com>
Cc: Alia Atlas <aatlas@avici.com>, mpls@UU.NET
Subject: Re: mpls lsr mib
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF07B74784.68094CED-ONC1256B4B.005817C4@net.alcatel.be>
Date: Thu, 24 Jan 2002 17:05:03 +0100
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/24/2002 17:05:15,
	Serialize complete at 01/24/2002 17:05:15
Content-Type: multipart/alternative; boundary="=_alternative 005857CEC1256B4B_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 005857CEC1256B4B_=
Content-Type: text/plain; charset="us-ascii"

Tom,

Thanks for your response. It already answers part of my question. Can you 
indicate which value the xaMplsIfConfLabelMinIn should have for a row with ifIndex /= 0:
* The min label value of the **per interface** label space.
OR
* The min label value of all the labels in the per interface **and** per 
platform label spaces.

Best regards,

        Francis.

----------------------------





"Thomas D. Nadeau" <tnadeau@cisco.com>
24/01/2002 16:43

 
        To:     Alia Atlas <aatlas@avici.com>
        cc:     Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET
        Subject:        Re: mpls lsr mib




> >>Hello Tom et all,
> >>
> >>I have a question on the mplsInterfaceConfTable in the mpls lsr mib.
> >>IAssume that we consider the following:
> >>* Per interface label space used for RSVP signalled LSPs and static 
LSPs.
> >>* Global label space used for LDP signalled LSPs.
> >
> >         First, how can you use two different label spaces to advertise 
over
> >the same interface?  I have never heard of this behavior before. One
> >assigns a per-interface label range that is unique for that interface
> >only, no?
>
>Having LDP use global labels while RSVP-TE LSPs use per interface labels 
is
>reasonable; certainly, I've heard of it before.  One can partition the
>label range given out, so that one range is for the global labels, while
>the other is for per-interface.

         Yes, it is within the realm of possibility to configure your 
label
ranges that way. However, what you are talking about is per-application
label space configuration, which is not what the MIB variable is getting 
at.
It is used to represent per-interface label range configuration or 
per-platform
label range configuration. These values are configured on interfaces, not 
on
applications. If you want to divide up the range further (i.e.: per 
application),
that is something the MIB was not intended to do.

         --Tom



>Alia
>
> >>Which value should we then give to the mplsInterfaceLabelMinIn:
> >>* The min label value of the per interface label space (that is, the 
min
> >>label value from the RSVP signalled LSPs and the static LSPs)?
> >>* The min label value of the RSVP signalled LSPs.
> >>* The min label value of all LSPs on the interface (=min of all LDP
> >>signalled, RSVP signalled and static LSPs).
> >>
> >>I would appreciate any help you can give me.
> >>
> >>Kind regards,
> >>
> >>         Francis.
> >>
> >>--------------------------------
> >>
> >>OBJECT-TYPE
> >>    SYNTAX        MplsLabel
> >>    MAX-ACCESS    read-only
> >>    STATUS        current
> >>    DESCRIPTION
> >>        "This is the minimum value of an MPLS label that this
> >>         LSR is willing to receive on this interface."
> >>    ::= { mplsInterfaceConfEntry 2 }
> >
> >
> >
> 
>------------------------------------------------------------------------
> >Mathematics is the supreme nostalgia of our time.
> >



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




--=_alternative 005857CEC1256B4B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Tom,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for your response. It already answers part of my question. Can you indicate which value the </font><font size=2 face="Courier New">xaMplsIfConfLabelMinIn</font><font size=2 face="sans-serif"> should have for a row with ifIndex /= 0:</font>
<br><font size=2 face="sans-serif">* The min label value of the **per interface** label space.</font>
<br><font size=2 face="sans-serif">OR</font>
<br><font size=2 face="sans-serif">* The min label value of all the labels in the per interface **and** per platform label spaces.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
<br>
<br><font size=2 face="sans-serif">----------------------------</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Thomas D. Nadeau&quot; &lt;tnadeau@cisco.com&gt;</b></font>
<p><font size=1 face="sans-serif">24/01/2002 16:43</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Alia Atlas &lt;aatlas@avici.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: mpls lsr mib</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
<br>
&gt; &gt;&gt;Hello Tom et all,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;I have a question on the mplsInterfaceConfTable in the mpls lsr mib.<br>
&gt; &gt;&gt;IAssume that we consider the following:<br>
&gt; &gt;&gt;* Per interface label space used for RSVP signalled LSPs and static LSPs.<br>
&gt; &gt;&gt;* Global label space used for LDP signalled LSPs.<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; First, how can you use two different label spaces to advertise over<br>
&gt; &gt;the same interface? &nbsp;I have never heard of this behavior before. One<br>
&gt; &gt;assigns a per-interface label range that is unique for that interface<br>
&gt; &gt;only, no?<br>
&gt;<br>
&gt;Having LDP use global labels while RSVP-TE LSPs use per interface labels is<br>
&gt;reasonable; certainly, I've heard of it before. &nbsp;One can partition the<br>
&gt;label range given out, so that one range is for the global labels, while<br>
&gt;the other is for per-interface.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; Yes, it is within the realm of possibility to configure your label<br>
ranges that way. However, what you are talking about is per-application<br>
label space configuration, which is not what the MIB variable is getting at.<br>
It is used to represent per-interface label range configuration or per-platform<br>
label range configuration. These values are configured on interfaces, not on<br>
applications. If you want to divide up the range further (i.e.: per <br>
application),<br>
that is something the MIB was not intended to do.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; --Tom<br>
<br>
<br>
<br>
&gt;Alia<br>
&gt;<br>
&gt; &gt;&gt;Which value should we then give to the mplsInterfaceLabelMinIn:<br>
&gt; &gt;&gt;* The min label value of the per interface label space (that is, the min<br>
&gt; &gt;&gt;label value from the RSVP signalled LSPs and the static LSPs)?<br>
&gt; &gt;&gt;* The min label value of the RSVP signalled LSPs.<br>
&gt; &gt;&gt;* The min label value of all LSPs on the interface (=min of all LDP<br>
&gt; &gt;&gt;signalled, RSVP signalled and static LSPs).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;I would appreciate any help you can give me.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;Kind regards,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Francis.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;--------------------------------<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;OBJECT-TYPE<br>
&gt; &gt;&gt; &nbsp; &nbsp;SYNTAX &nbsp; &nbsp; &nbsp; &nbsp;MplsLabel<br>
&gt; &gt;&gt; &nbsp; &nbsp;MAX-ACCESS &nbsp; &nbsp;read-only<br>
&gt; &gt;&gt; &nbsp; &nbsp;STATUS &nbsp; &nbsp; &nbsp; &nbsp;current<br>
&gt; &gt;&gt; &nbsp; &nbsp;DESCRIPTION<br>
&gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;&quot;This is the minimum value of an MPLS label that this<br>
&gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; LSR is willing to receive on this interface.&quot;<br>
&gt; &gt;&gt; &nbsp; &nbsp;::= { mplsInterfaceConfEntry 2 }<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;------------------------------------------------------------------------<br>
&gt; &gt;Mathematics is the supreme nostalgia of our time.<br>
&gt; &gt;<br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
Mathematics is the supreme nostalgia of our time. <br>
<br>
</font>
<br>
<br>
--=_alternative 005857CEC1256B4B_=--


From owner-mpls@UU.NET  Thu Jan 24 11:16:35 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25531
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 11:16:35 -0500 (EST)
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 QQlzfc23502;
	Thu, 24 Jan 2002 16:12:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfc17766
	for mpls-outgoing; Thu, 24 Jan 2002 16:12:42 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlzfc17731
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 16:12:37 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 QQlzfc16080
	for <mpls@uu.net>; Thu, 24 Jan 2002 16:11:49 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe54.law9.hotmail.com [64.4.8.47])
	id QQlzfc16392
	for <mpls@uu.net>; Thu, 24 Jan 2002 16:11:49 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 24 Jan 2002 08:11:44 -0800
X-Originating-IP: [212.25.110.131]
From: "Doug Degan" <doug_degan@hotmail.com>
To: <mpls@UU.NET>
Subject: another FRR question (draft-pan-rsvp-fastreroute-00.txt)
Date: Thu, 24 Jan 2002 18:11:40 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002B_01C1A502.927D5710"
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
Message-ID: <OE54jIvFt9D0kWSxlXp00006cb4@hotmail.com>
X-OriginalArrivalTime: 24 Jan 2002 16:11:44.0909 (UTC) FILETIME=[D153D3D0:01C1A4F1]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C1A502.927D5710
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

according to draft-iwata-mpls-crankback-02.txt (page =
19)SESSION_ATTRIBUTE object flags 0x8 & 0x10 are occupied:
how come they are used in the bypass method?


<!--StartFragment-->
     0x08  End-to-end rerouting desired

       This flag indicates the end-to-end rerouting behavior for an LSP
       under establishment. This can also be used for specifying the
       behavior of end-to-end LSP restoration for established LSPs.

     0x10  Segment-based rerouting (hierarchical rerouting) desired.

       This flag indicates the segment-based rerouting (hierarchical
       rerouting) behavior for an LSP under establishment. This can also
       be used for specifying the segment-based (hierarchical) LSP
       restoration for established LSPs.

=20

------=_NextPart_000_002B_01C1A502.927D5710
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.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>according to =
draft-iwata-mpls-crankback-02.txt=20
(page 19)SESSION_ATTRIBUTE object flags 0x8 &amp; 0x10 are=20
occupied:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>how come they are used in the bypass=20
method?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&lt;!--StartFragment--&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
0x08&nbsp;=20
End-to-end rerouting desired<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
This=20
flag indicates the end-to-end rerouting behavior for an=20
LSP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; under establishment. This =
can also=20
be used for specifying the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
behavior of=20
end-to-end LSP restoration for established =
LSPs.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
0x10&nbsp; Segment-based rerouting (hierarchical rerouting)=20
desired.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This flag indicates =
the=20
segment-based rerouting =
(hierarchical<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
rerouting) behavior for an LSP under establishment. This can=20
also<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be used for specifying the=20
segment-based (hierarchical) LSP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

restoration for established LSPs.<BR></FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;</DIV></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_002B_01C1A502.927D5710--


From owner-mpls@UU.NET  Thu Jan 24 15:55:12 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05439
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 15:55:12 -0500 (EST)
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 QQlzfv07867;
	Thu, 24 Jan 2002 20:47:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzfv29985
	for mpls-outgoing; Thu, 24 Jan 2002 20:47: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 QQlzfv29978
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 24 Jan 2002 20:47: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 QQlzfv17843
	for <mpls@UU.NET>; Thu, 24 Jan 2002 20:45:37 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 QQlzfv05061
	for <mpls@UU.NET>; Thu, 24 Jan 2002 20:45:35 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g0OKjN100256;
	Thu, 24 Jan 2002 21:45:23 +0100 (MET)
To: "rajneesh mahajan" <rajneesh_vt@yahoo.com>
Cc: mpls@UU.NET
Subject: Re: mpls lsr mib
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8FCA6FF5.DFEB63F9-ONC1256B4B.00719AD8@net.alcatel.be>
Date: Thu, 24 Jan 2002 21:45:20 +0100
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/24/2002 21:45:22,
	Serialize complete at 01/24/2002 21:45:22
Content-Type: multipart/alternative; boundary="=_alternative 0071FDD6C1256B4B_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0071FDD6C1256B4B_=
Content-Type: text/plain; charset="us-ascii"

Hi Rajneesh,

Thanks for your reply.

I have a slightly different interpretation on the mplsInterfaceLabelMinIn 
object. When looking at the descriptions in the mib, I understand that the 
mplsInterfaceLabelMinIn object is the minimum label value on an interface 
- be at a label from the local or the global label space.

After all, the description of the mplsInterfaceLabelMinIn object states 
the following:
        If only the
        perPlatform(0) bit is set, then the value of
        mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn,
        mplsInterfaceLabelMinOut, and
        mplsInterfaceLabelMaxOut for this entry must be
        identical to the instance of these objects with
        index 0."

So this text indicates that the global label space also needs to be taken 
into account for the mplsInterfaceLabelMinIn object.

Best regards,

        Francis.

---------------------------------





"rajneesh mahajan" <rajneesh_vt@yahoo.com>
24/01/2002 17:01
Please respond to "rajneesh mahajan"

 
        To:     mpls@UU.NET
        cc:     (bcc: Francis ARTS/BE/ALCATEL)
        Subject:        Re: mpls lsr mib


I had a similar problem while implementing this MIB few months back and I 
decided that we should give label range for RSVP and statically signalled 
LSPs (which was per interface as in your case).  LDP label range could be 
obtained from LDP MIB.  Please correct me if I am wrong.
 
-Rajneesh
----- Original Message ----- 
From: francis.arts@alcatel.be 
To: mpls@UU.NET 
Sent: Thursday, January 24, 2002 8:22 AM
Subject: mpls lsr mib


Hello Tom et all, 

I have a question on the mplsInterfaceConfTable in the mpls lsr mib. 
IAssume that we consider the following: 
* Per interface label space used for RSVP signalled LSPs and static LSPs. 
* Global label space used for LDP signalled LSPs. 

Which value should we then give to the mplsInterfaceLabelMinIn: 
* The min label value of the per interface label space (that is, the min 
label value from the RSVP signalled LSPs and the static LSPs)? 
* The min label value of the RSVP signalled LSPs. 
* The min label value of all LSPs on the interface (=min of all LDP 
signalled, RSVP signalled and static LSPs). 

I would appreciate any help you can give me. 

Kind regards, 

        Francis. 

-------------------------------- 

mplsInterfaceLabelMinIn OBJECT-TYPE 
   SYNTAX        MplsLabel 
   MAX-ACCESS    read-only 
   STATUS        current 
   DESCRIPTION 
       "This is the minimum value of an MPLS label that this 
        LSR is willing to receive on this interface." 
   ::= { mplsInterfaceConfEntry 2 } 


--=_alternative 0071FDD6C1256B4B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hi Rajneesh,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for your reply.</font>
<br>
<br><font size=2 face="sans-serif">I have a slightly different interpretation on the mplsInterfaceLabelMinIn object. When looking at the descriptions in the mib, I understand that the mplsInterfaceLabelMinIn object is the minimum label value on an interface - be at a label from the local or the global label space.</font>
<br>
<br><font size=2 face="sans-serif">After all, the description of the mplsInterfaceLabelMinIn object states the following:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; If only the</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; perPlatform(0) bit is set, then the value of</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; mplsInterfaceLabelMinIn, mplsInterfaceLabelMaxIn,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; mplsInterfaceLabelMinOut, and</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; mplsInterfaceLabelMaxOut for this entry must be</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; identical to the instance of these objects with</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; index 0.&quot;</font>
<br>
<br><font size=2 face="sans-serif">So this text indicates that the global label space also needs to be taken into account for the mplsInterfaceLabelMinIn object.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
<br>
<br><font size=2 face="sans-serif">---------------------------------</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;rajneesh mahajan&quot; &lt;rajneesh_vt@yahoo.com&gt;</b></font>
<p><font size=1 face="sans-serif">24/01/2002 17:01</font>
<br><font size=1 face="sans-serif">Please respond to &quot;rajneesh mahajan&quot;</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;mpls@UU.NET</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Francis ARTS/BE/ALCATEL)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: mpls lsr mib</font></table>
<br>
<br>
<br><font size=2 face="Arial">I had a similar problem while implementing this MIB few months back and I decided that we should give label range for RSVP and statically signalled LSPs (which was per interface as in your case). &nbsp;LDP label range could be obtained from LDP MIB. &nbsp;Please correct me if I am wrong.</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br><font size=2 face="Arial">-Rajneesh</font>
<br><font size=3 face="Times New Roman">----- Original Message ----- </font>
<br><font size=3 face="Times New Roman"><b>From:</b> </font><a href=mailto:francis.arts@alcatel.be><font size=3 color=blue face="Times New Roman"><u>francis.arts@alcatel.be</u></font></a><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><b>To:</b> </font><a href=mailto:mpls@UU.NET><font size=3 color=blue face="Times New Roman"><u>mpls@UU.NET</u></font></a><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Times New Roman"><b>Sent:</b> Thursday, January 24, 2002 8:22 AM</font>
<br><font size=3 face="Times New Roman"><b>Subject:</b> mpls lsr mib</font>
<br>
<br><font size=2 face="sans-serif"><br>
Hello Tom et all,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
I have a question on the mplsInterfaceConfTable in the mpls lsr mib. IAssume that we consider the following:</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
* Per interface label space used for RSVP signalled LSPs and static LSPs.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
* Global label space used for LDP signalled LSPs.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Which value should we then give to the mplsInterfaceLabelMinIn:</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
* The min label value of the per interface label space (that is, the min label value from the RSVP signalled LSPs and the static LSPs)?</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
* The min label value of the RSVP signalled LSPs.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
* The min label value of all LSPs on the interface (=min of all LDP signalled, RSVP signalled and static LSPs).</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
I would appreciate any help you can give me.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Kind regards,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Francis.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
--------------------------------</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
mplsInterfaceLabelMinIn OBJECT-TYPE</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; SYNTAX &nbsp; &nbsp; &nbsp; &nbsp;MplsLabel</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; MAX-ACCESS &nbsp; &nbsp;read-only</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; STATUS &nbsp; &nbsp; &nbsp; &nbsp;current</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; DESCRIPTION</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &quot;This is the minimum value of an MPLS label that this</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;LSR is willing to receive on this interface.&quot;</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
 &nbsp; ::= { mplsInterfaceConfEntry 2 }</font><font size=3 face="Times New Roman"> </font>
<br>
<br>
--=_alternative 0071FDD6C1256B4B_=--


From owner-mpls@UU.NET  Thu Jan 24 21:30:07 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12317
	for <mpls-archive@lists.ietf.org>; Thu, 24 Jan 2002 21:30:07 -0500 (EST)
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 QQlzgr21061;
	Fri, 25 Jan 2002 02:26:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzgr02258
	for mpls-outgoing; Fri, 25 Jan 2002 02:25: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 QQlzgr02253
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 02:25: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 QQlzgr01643
	for <mpls@UU.NET>; Fri, 25 Jan 2002 02:24:19 GMT
Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlzgr13341
	for <mpls@UU.NET>; Fri, 25 Jan 2002 02:24:18 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.48 2001/12/13 16:27:50 root Exp $) with SMTP id CAA03132
	for <mpls@UU.NET>; Fri, 25 Jan 2002 02:24:18 GMT
Received: from FMSMSX016.fm.intel.com ([132.233.42.195])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012418232822850
 for <mpls@UU.NET>; Thu, 24 Jan 2002 18:23:28 -0800
Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <DND12XBC>; Thu, 24 Jan 2002 18:24:17 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA1CD@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RRO question
Date: Thu, 24 Jan 2002 18:24:12 -0800
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 some doubts on the expected behavior of the egress router regarding
the handling of the following scenario.

   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.  A PathErr (or
   ResvErr) message SHOULD be sent back to the sender (or receiver).  An
   error code of "Notify" and an error value of "RRO too large for MTU"
   is used.  If the receiver receives such a ResvErr, it SHOULD send a
   PathErr message with error code of "Notify" and an error value of
   "RRO notification".

When the egress router receives the ResvErr, should it remove the RRO
objects from the Resv message? The problem is that, before the PathErr
reaches the ingress router, subsequent refresh Path message will still have
the RRO object present.

IMO, the egress router should not remove the RRO. When the ingress router
receives the PathErr message, it will remove the RROs in the Path message,
which will trigger the removal of the RRO objects in the corresponding Resv
message.

I would appreciate any comments regarding this.

Thanks in advance.

- Mark 


From owner-mpls@UU.NET  Fri Jan 25 07:02:45 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29746
	for <mpls-archive@lists.ietf.org>; Fri, 25 Jan 2002 07:02:44 -0500 (EST)
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 QQlzie19265;
	Fri, 25 Jan 2002 12:01:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzie19017
	for mpls-outgoing; Fri, 25 Jan 2002 12:01: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 QQlzie18975
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 12:01:20 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 QQlzie20602
	for <mpls@UU.NET>; Fri, 25 Jan 2002 12:01:03 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlzie17997
	for <mpls@UU.NET>; Fri, 25 Jan 2002 12:01:00 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <DKCQMMP2>; Fri, 25 Jan 2002 17:29:27 +0530
Message-ID: <9027F68B07E7D511AE9400B0D0787DC0070414@mailserver.netbrahma.com>
From: Manoj Agiwal <ManojA@netbrahma.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Cc: "'rsvp@isi.edu'" <rsvp@isi.edu>
Subject: Refresh Reduction (out of order) 
Date: Fri, 25 Jan 2002 17:29:21 +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 ,
       As per RFC 2961
         "Out of order messages SHOULD be ignored, i.e., silently dropped."
       If Epoch value of the message is same and new message id is less than
the old one , then message is out of order and hence
it should be dropped .
  For message Id wrap cases ::
"
if ((int) old_id - (int) new_id > 0) {
          new value is less than old value;
       } "
    How you will you differentiate between wrap case and normal out of order
case , since in both cases new message Id will be less than old message ID
and epoch is same .

   
Regards ,
Manoj
 





From owner-mpls@UU.NET  Fri Jan 25 10:09:39 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04582
	for <mpls-archive@lists.ietf.org>; Fri, 25 Jan 2002 10:09:24 -0500 (EST)
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 QQlziq03874;
	Fri, 25 Jan 2002 15:04:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlziq09140
	for mpls-outgoing; Fri, 25 Jan 2002 15:04: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 QQlziq09131
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 15:04:29 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 QQlziq25017
	for <mpls@uu.net>; Fri, 25 Jan 2002 15:04:16 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlziq12623
	for <mpls@uu.net>; Fri, 25 Jan 2002 15:04:16 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10986 for <mpls@uu.net>; Fri, 25 Jan 2002 10:04:15 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA00209 for mpls@uu.net; Fri, 25 Jan 2002 10:04:15 -0500 (EST)
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 QQlzik02031
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 13:43:17 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 QQlzik14838
	for <mpls@uu.net>; Fri, 25 Jan 2002 13:42:15 GMT
Received: from hermes.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmr01.intel.com [192.55.52.18])
	id QQlzik13375
	for <mpls@uu.net>; Fri, 25 Jan 2002 13:42:15 GMT
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.29 2002/01/25 02:32:19 root Exp $) with ESMTP id g0PDfhF24052
	for <mpls@uu.net>; Fri, 25 Jan 2002 13:41:44 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id g0PDfmp01060
	for <mpls@uu.net>; Fri, 25 Jan 2002 13:41:48 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012505414520172
 for <mpls@uu.net>; Fri, 25 Jan 2002 05:41:45 -0800
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 DRBKN4PH; Fri, 25 Jan 2002 05:42:14 -0800
Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19)
	id <4L8K13A6>; Fri, 25 Jan 2002 14:41:53 +0100
Message-ID: <413FBB0BA5AED1119122000083234B1A01FB478E@alpha.igk.intel.com>
From: "Szymanski, Pawel" <Pawel.Szymanski@intel.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: ExpBits in FTN MIB
Date: Fri, 25 Jan 2002 14:41:49 +0100
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,

Can anyone tell me what is the purpose of having mplsFTNExpBits object in
FTN MIB.
It was added in the newest version (4), but its description is rather scant
?

Thank, you

Pawel Szymanski




From owner-mpls@UU.NET  Fri Jan 25 12:54:37 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09230
	for <mpls-archive@lists.ietf.org>; Fri, 25 Jan 2002 12:54:37 -0500 (EST)
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 QQlzjb18730;
	Fri, 25 Jan 2002 17:51:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzjb11258
	for mpls-outgoing; Fri, 25 Jan 2002 17:50: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 QQlzjb11253
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 17:50:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlzjb03102
	for <mpls@UU.NET>; Fri, 25 Jan 2002 17:48: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 QQlzjb22813
	for <mpls@UU.NET>; Fri, 25 Jan 2002 17:48: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 MAA10177;
	Fri, 25 Jan 2002 12:47:57 -0500 (EST)
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 MAA26726;
	Fri, 25 Jan 2002 12:47:57 -0500 (EST)
Message-ID: <3C519AA7.AC0C16DB@marconi.com>
Date: Fri, 25 Jan 2002 12:49:28 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: Manoj Agiwal <ManojA@netbrahma.com>
CC: "'mpls@UU.NET'" <mpls@UU.NET>, "'rsvp@isi.edu'" <rsvp@isi.edu>
Subject: Re: Refresh Reduction (out of order)
References: <9027F68B07E7D511AE9400B0D0787DC0070414@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:
> 
> As per RFC 2961
> "Out of order messages SHOULD be ignored, i.e., silently dropped."
> If Epoch value of the message is same and new message id is less
> than the old one , then message is out of order and hence it should
> be dropped .
>   For message Id wrap cases ::
> "
> if ((int) old_id - (int) new_id > 0) {
>           new value is less than old value;
>        } "
> How you will you differentiate between wrap case and normal out of
> order case , since in both cases new message Id will be less than
> old message ID and epoch is same .

Note the algorithm provided.  It is casting the IDs onto _signed_ ints. 
So any values greater than 2^31 will be negative.

If both IDs are positive (between 0 and 2^31-1), then the subtraction
will result a positive value if the new ID is less than the old ID.

If both IDs are negative (between 2^31 and 2^32-1), then the subtraction
will still result in a positive value if the new ID is less than the old
ID.  Note that when large integers approach the wrap point, their signed
equivalent values (when cast to a signed int) approaches zero from the
negative side.

If one ID is positive and one is negative, the test will work as long as
the delta between the two values is less than half the total range (i.e.
less than 2^31).  The proof of this is left as an exercise for the
reader.

In other words, the above algorithm (cast to signed and subtract) will
work even when the values wrap, as long as the delta between values is
no larger than 2^31.  This is more than sufficient to catch the cases
where a stale message ID might be in transit for longer than expected. 
It won't catch the pathological case where a router is sending out IDs
that are completely wrong, but that's not the problem this is trying to
solve.

-- David


From owner-mpls@UU.NET  Fri Jan 25 13:53:36 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10904
	for <mpls-archive@lists.ietf.org>; Fri, 25 Jan 2002 13:53:36 -0500 (EST)
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 QQlzjf16597;
	Fri, 25 Jan 2002 18:50:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzjf05834
	for mpls-outgoing; Fri, 25 Jan 2002 18:49:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlzjf05829
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 25 Jan 2002 18:49:44 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 QQlzjf14987
	for <mpls@UU.NET>; Fri, 25 Jan 2002 18:49:20 GMT
Received: from calliope1.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQlzjf13340
	for <mpls@UU.NET>; Fri, 25 Jan 2002 18:49:19 GMT
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id SAA04974
	for <mpls@UU.NET>; Fri, 25 Jan 2002 18:49:19 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002012510501223340
 ; Fri, 25 Jan 2002 10:50:12 -0800
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <DQ0SD0GJ>; Fri, 25 Jan 2002 10:49:17 -0800
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA1CE@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'David Charlap'" <David.Charlap@marconi.com>,
        Manoj Agiwal <ManojA@netbrahma.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>, "'rsvp@isi.edu'" <rsvp@isi.edu>
Subject: RE: Refresh Reduction (out of order)
Date: Fri, 25 Jan 2002 10:49:11 -0800
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

One minor comment.

As long as the LSP experiences a state change within the range, so that a
new message ID is allocated, the test would work. This would also depends on
the state change frequency of other LSPs.

There were some discussions on this topic on the RSVP mailing list, if you
are interested. I am not sure the mails are archived though.

- Mark

> -----Original Message-----
> From: David Charlap [mailto:David.Charlap@marconi.com]
> Sent: Friday, January 25, 2002 9:49 AM
> To: Manoj Agiwal
> Cc: 'mpls@UU.NET'; 'rsvp@isi.edu'
> Subject: Re: Refresh Reduction (out of order)
> 
> 
> Manoj Agiwal wrote:
> > 
> > As per RFC 2961
> > "Out of order messages SHOULD be ignored, i.e., silently dropped."
> > If Epoch value of the message is same and new message id is less
> > than the old one , then message is out of order and hence it should
> > be dropped .
> >   For message Id wrap cases ::
> > "
> > if ((int) old_id - (int) new_id > 0) {
> >           new value is less than old value;
> >        } "
> > How you will you differentiate between wrap case and normal out of
> > order case , since in both cases new message Id will be less than
> > old message ID and epoch is same .
> 
> Note the algorithm provided.  It is casting the IDs onto 
> _signed_ ints. 
> So any values greater than 2^31 will be negative.
> 
> If both IDs are positive (between 0 and 2^31-1), then the subtraction
> will result a positive value if the new ID is less than the old ID.
> 
> If both IDs are negative (between 2^31 and 2^32-1), then the 
> subtraction
> will still result in a positive value if the new ID is less 
> than the old
> ID.  Note that when large integers approach the wrap point, 
> their signed
> equivalent values (when cast to a signed int) approaches zero from the
> negative side.
> 
> If one ID is positive and one is negative, the test will work 
> as long as
> the delta between the two values is less than half the total 
> range (i.e.
> less than 2^31).  The proof of this is left as an exercise for the
> reader.
> 
> In other words, the above algorithm (cast to signed and subtract) will
> work even when the values wrap, as long as the delta between values is
> no larger than 2^31.  This is more than sufficient to catch the cases
> where a stale message ID might be in transit for longer than 
> expected. 
> It won't catch the pathological case where a router is sending out IDs
> that are completely wrong, but that's not the problem this is 
> trying to
> solve.
> 
> -- David
> 


From owner-mpls@UU.NET  Mon Jan 28 20:05:07 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12507
	for <mpls-archive@lists.ietf.org>; Mon, 28 Jan 2002 20:05:06 -0500 (EST)
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 QQlzvg08006;
	Tue, 29 Jan 2002 01:01:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzvg19212
	for mpls-outgoing; Tue, 29 Jan 2002 01:01: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 QQlzvg19114
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 01:00:57 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlzvg07760
	for <mpls@UU.NET>; Tue, 29 Jan 2002 01:00:34 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 QQlzvg07394
	for <mpls@UU.NET>; Tue, 29 Jan 2002 01:00:34 GMT
Message-ID: <20020129010034.98184.qmail@web14305.mail.yahoo.com>
Received: from [65.24.148.139] by web14305.mail.yahoo.com via HTTP; Mon, 28 Jan 2002 17:00:34 PST
Date: Mon, 28 Jan 2002 17:00:34 -0800 (PST)
From: anurag sahai <emailsahai@yahoo.com>
Subject: re: Mpls on ns
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi!
I am using ns-1.8 inorder to do some simulations for
the MPLS.

Does any one knows how to configure NS-1.8 for MPLS.

Appreciate your help in advance,

Anurag  


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com


From owner-mpls@UU.NET  Tue Jan 29 08:20:49 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02304
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 08:20:49 -0500 (EST)
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 QQlzxd00112;
	Tue, 29 Jan 2002 13:19:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzxd00652
	for mpls-outgoing; Tue, 29 Jan 2002 13:19: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 QQlzxd00645
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 13:19: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 QQlzxd01782
	for <mpls@uu.net>; Tue, 29 Jan 2002 13:18:56 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzxd28604
	for <mpls@uu.net>; Tue, 29 Jan 2002 13:18:55 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20531 for <mpls@uu.net>; Tue, 29 Jan 2002 08:18:55 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA00968 for mpls@uu.net; Tue, 29 Jan 2002 08:18:55 -0500 (EST)
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 QQlzvf14327
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 00:51:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlzvf25252
	for <mpls@uu.net>; Tue, 29 Jan 2002 00:51:18 GMT
From: schultz@io.iol.unh.edu
Received: from iol.unh.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: io.iol.unh.edu [132.177.123.82])
	id QQlzvf25065
	for <mpls@uu.net>; Tue, 29 Jan 2002 00:51:17 GMT
Received: from io.iol.unh.edu (IDENT:schultz@localhost.localdomain [127.0.0.1])
	by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g0T0pBUj016689
	for <mpls@uu.net>; Mon, 28 Jan 2002 19:51:11 -0500
Received: from localhost (schultz@localhost)
	by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g0T0pBwR016686
	for <mpls@uu.net>; Mon, 28 Jan 2002 19:51:11 -0500
Date: Mon, 28 Jan 2002 19:51:11 -0500 (EST)
To: mpls@UU.NET
Subject: Object Orders
Message-ID: <Pine.LNX.4.43.0201281920460.16319-100000@io.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello,

I have a question about the object orders.

In RFC 2205, section 3.1 states:
An implementation should create messages with the objects in the order
shown here, but accept the objects in any permissible order.

In sections 3.1.3 and 3.1.4, the standard asserts that the INTEGRITY
object must immediately follow the common header.

RFC 2961 also dictates strict ordering rules for the MESSAGE_ID object.

However, RFC 3209 notes: "The ordering of these objects is not important,
so an implementation MUST be prepared to accept objects in any order."

A strict interpretation of this statement would assume that if a device
disregards the object ordering rules, it can still interoperate.

What is the correct behavior for the following situation:

An LSR receives a Path or Resv message that violates the ordering rules.
Does it accept the message and allow the LSP tunnel to form?  Or does it
send an error message as recommended in Appendix B of RFC 2205?

Thanks,
-Ben



From owner-mpls@UU.NET  Tue Jan 29 09:11:37 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03672
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 09:11:37 -0500 (EST)
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 QQlzxg08074;
	Tue, 29 Jan 2002 14:08:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzxg24077
	for mpls-outgoing; Tue, 29 Jan 2002 14:08: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 QQlzxg24070
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 14:08: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 QQlzxg22880
	for <mpls@uu.net>; Tue, 29 Jan 2002 14:07:58 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzxg03907
	for <mpls@uu.net>; Tue, 29 Jan 2002 14:07:58 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24483 for <mpls@uu.net>; Tue, 29 Jan 2002 09:07:58 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03720 for mpls@uu.net; Tue, 29 Jan 2002 09:07:58 -0500 (EST)
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 QQlzxf02797
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 13:47: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 QQlzxf14717
	for <mpls@UU.NET>; Tue, 29 Jan 2002 13:46:10 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe40.law11.hotmail.com [64.4.16.97])
	id QQlzxf07177
	for <mpls@UU.NET>; Tue, 29 Jan 2002 13:46:10 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 29 Jan 2002 05:46:09 -0800
X-Originating-IP: [132.146.249.186]
From: "Takao Okamawari" <takao_uk@hotmail.com>
To: <mpls@UU.NET>
Subject: Label allocation in RSVP-TE
Date: Tue, 29 Jan 2002 13:42:51 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
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
Message-ID: <OE40NNLBIF5C6O5si2G0001668d@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2002 13:46:09.0490 (UTC) FILETIME=[4EAD6B20:01C1A8CB]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all, 

I have a question about label allocation in RSVP-TE.
When a label is drawn from a label space?
On receipt of PATH or on receipt of RESV? (And reason why...)

RFC3209, 4.1.1.1 says, 
"If no label is available, the node sends a PathErr
message ..."
Since PathErr is used to notify a failure of PATH message, 
this reminds me that a label is drawn from a label space
on receipt of the PATH.

On the other hand, Yakov Rekhter says in his book 
(MPLS technology and applications) that
"When an LSR wants to send a RESV message for a new RSVP flow,
the LSR allocates a label from its pool of free labels, 
creates an entry in its LFIB with the incoming label set to 
the allocated label, and sends out the RESV message..." (pp 153)
(Does it mean PathErr is sent when RESV has failed?)

Please let me know.

Takao



From owner-mpls@UU.NET  Tue Jan 29 10:52:11 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06875
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 10:52:10 -0500 (EST)
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 QQlzxn23867;
	Tue, 29 Jan 2002 15:49:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzxn22819
	for mpls-outgoing; Tue, 29 Jan 2002 15: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 QQlzxn22814
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 15:48: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 QQlzxn13916
	for <mpls@UU.NET>; Tue, 29 Jan 2002 15:47:21 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 QQlzxn21424
	for <mpls@UU.NET>; Tue, 29 Jan 2002 15:47:21 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 KAA15050
	for <mpls@UU.NET>; Tue, 29 Jan 2002 10:47:18 -0500 (EST)
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 KAA08780
	for <mpls@UU.NET>; Tue, 29 Jan 2002 10:47:17 -0500 (EST)
Message-ID: <3C56C46D.C20506F9@marconi.com>
Date: Tue, 29 Jan 2002 10:49:01 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Object Orders
References: <Pine.LNX.4.43.0201281920460.16319-100000@io.iol.unh.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

schultz@io.iol.unh.edu wrote:
> 
> I have a question about the object orders.
> 
> In RFC 2205, section 3.1 states:
> An implementation should create messages with the objects in the
> order shown here, but accept the objects in any permissible order.

Please read the previous two sentences as well:

	The BNF implies an order for the objects in a message.
	However, in many (but not all) cases, object order makes no
	logical difference.

Please note the "but not all" clause.  There are some places where
object order is important.

> In sections 3.1.3 and 3.1.4, the standard asserts that the INTEGRITY
> object must immediately follow the common header.

This is one of them.

It's also the case that flow descriptors are illegal until after the
STYLE object.

There are also ordering rules regarding the objects within flow
descriptors.

> RFC 2961 also dictates strict ordering rules for the MESSAGE_ID 
> object.

Yes.  When refresh reduction is used, MESSAGE_ID and ACK objects have
ordering requirements.

> However, RFC 3209 notes: "The ordering of these objects is not
> important, so an implementation MUST be prepared to accept objects
> in any order."

You are reading individual sentences out of context and jumping to the
completely wrong conclusion.

The sentence immediately before the one you quoted says:

	The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST,
	and SESSION_ATTRIBUTE objects is simply a recommendation.

The paragraph is saying that these three object classes do not have any
particular ordering requirements.  It is not saying that you are free to
discard the ordering requirements of all other objects that are
specified in other drafts.

> A strict interpretation of this statement would assume that if a
> device disregards the object ordering rules, it can still
> interoperate.

Be liberal in what you accept.  Be conservative in what you send.

If the object ordering you receive is not explicitly forbidden, then you
should accept the message.  But when you generate your own outgoing
message, you should order the objects according to the BNF in the RFC.

> What is the correct behavior for the following situation:
> 
> An LSR receives a Path or Resv message that violates the ordering
> rules.  Does it accept the message and allow the LSP tunnel to form?
> Or does it send an error message as recommended in Appendix B of
> RFC 2205?

Depends on what the "violation" is.

If you get an INTEGRITY object in the middle of the message, then you
must reject the message.  If you get an ADSPEC before the SESSION
object, then you should accept it.  It all depends on whether the
ordering you receive is explicitly forbidden or not.

Also, please re-read RFC 2205 more closely.  Object ordering violations
do not result in the generation of a PathErr/ResvErr message.  The
message is simply ignored if the order is invalid.

-- David


From owner-mpls@UU.NET  Tue Jan 29 10:57:21 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07024
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 10:57:21 -0500 (EST)
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 QQlzxn00530;
	Tue, 29 Jan 2002 15:53:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzxn23148
	for mpls-outgoing; Tue, 29 Jan 2002 15:53: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 QQlzxn23141
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 15:53: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 QQlzxn26583
	for <mpls@UU.NET>; Tue, 29 Jan 2002 15:53:10 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 QQlzxn29611
	for <mpls@UU.NET>; Tue, 29 Jan 2002 15:53:09 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15871
	for <mpls@UU.NET>; Tue, 29 Jan 2002 10:53:07 -0500 (EST)
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 KAA10917
	for <mpls@UU.NET>; Tue, 29 Jan 2002 10:53:07 -0500 (EST)
Message-ID: <3C56C5CD.ED364F92@marconi.com>
Date: Tue, 29 Jan 2002 10:54:53 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Label allocation in RSVP-TE
References: <OE40NNLBIF5C6O5si2G0001668d@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Takao Okamawari wrote:
> 
> I have a question about label allocation in RSVP-TE.
> When a label is drawn from a label space?
> On receipt of PATH or on receipt of RESV? (And reason why...)

The inbound label (which is sent upstream to the PHOP) may be produced
at any time after receiving the Path message.  The outbound label (which
is received from the NHOP) obviously can not be allocated until after
the Resv arrives, since the label value is specified in that Resv
message.

> RFC3209, 4.1.1.1 says,
> "If no label is available, the node sends a PathErr message ..."
> Since PathErr is used to notify a failure of PATH message,
> this reminds me that a label is drawn from a label space
> on receipt of the PATH.

Not necessarily.  PathErr may also be generated in response to Resv
messages as well.  In RFC 3209, several resv-related conditions (like
failure to allocate labels, and admission control errors) result in
PathErr, and not ResvErr.  The names PathErr and ResvErr are really
misnomers - a PathErr is simply an error message that is sent towards
the ingress node, and a ResvErr is an error message that is sent towards
the egress node.

> On the other hand, Yakov Rekhter says in his book
> (MPLS technology and applications) that
> "When an LSR wants to send a RESV message for a new RSVP flow,
> the LSR allocates a label from its pool of free labels,
> creates an entry in its LFIB with the incoming label set to
> the allocated label, and sends out the RESV message..." (pp 153)
> (Does it mean PathErr is sent when RESV has failed?)

Yes.

-- David


From owner-mpls@UU.NET  Tue Jan 29 11:13:46 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07795
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:13:46 -0500 (EST)
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 QQlzxo25040;
	Tue, 29 Jan 2002 16:11:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzxo14571
	for mpls-outgoing; Tue, 29 Jan 2002 16:11: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 QQlzxo14536
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 16:11: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 QQlzxo01197
	for <mpls@uu.net>; Tue, 29 Jan 2002 16:08:28 GMT
Received: from [172.16.1.19] by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.opnet.com [12.145.55.7])
	id QQlzxo20618
	for <mpls@uu.net>; Tue, 29 Jan 2002 16:08:28 GMT
Received: from wtn10216.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58be56f8daac100113374@> for <mpls@uu.net>;
 Tue, 29 Jan 2002 11:08:12 -0500
Message-Id: <5.0.0.25.2.20020129110745.02ee6070@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 29 Jan 2002 11:08:08 -0500
To: <mpls@UU.NET>
From: Sachin Kalra <skalra@opnet.com>
Subject: Re: Label allocation in RSVP-TE
In-Reply-To: <OE40NNLBIF5C6O5si2G0001668d@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_88385681==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_88385681==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Takao:

Label is drawn from Label Space on receipt of RESV message. The reason for 
doing this is:

At the time when LSP gets signaled, all LSRs (except Ingress LSR) decide 
upon the label they will accept for the LSP, creates entry in their LFIB 
and send that label to their UPSTREAM LSR. As the labels drawn have to be 
forwarded upstream, so they are drawn at the time when LSR receives RESV 
message (Resv message travels upstream)

This approach makes sure that each LSR gets to decide their own incoming 
label for each LSP.

Take Care.
Sachin Kalra


At 01:42 PM 1/29/02 +0000, Takao Okamawari wrote:
>Hi all,
>
>I have a question about label allocation in RSVP-TE.
>When a label is drawn from a label space?
>On receipt of PATH or on receipt of RESV? (And reason why...)
>
>RFC3209, 4.1.1.1 says,
>"If no label is available, the node sends a PathErr
>message ..."
>Since PathErr is used to notify a failure of PATH message,
>this reminds me that a label is drawn from a label space
>on receipt of the PATH.
>
>On the other hand, Yakov Rekhter says in his book
>(MPLS technology and applications) that
>"When an LSR wants to send a RESV message for a new RSVP flow,
>the LSR allocates a label from its pool of free labels,
>creates an entry in its LFIB with the incoming label set to
>the allocated label, and sends out the RESV message..." (pp 153)
>(Does it mean PathErr is sent when RESV has failed?)
>
>Please let me know.
>
>Takao

--=====================_88385681==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Takao:<br>
<br>
Label is drawn from Label Space on receipt of RESV message. The reason
for doing this is:<br>
<br>
At the time when LSP gets signaled, all LSRs (except Ingress LSR) decide
upon the label they will accept for the LSP, creates entry in their LFIB
and send that label to their UPSTREAM LSR. As the labels drawn have to be
forwarded upstream, so they are drawn at the time when LSR receives RESV
message (Resv message travels upstream)<br>
<br>
This approach makes sure that each LSR gets to decide their own incoming
label for each LSP.<br>
<br>
Take Care.<br>
Sachin Kalra<br>
<br>
<br>
At 01:42 PM 1/29/02 +0000, Takao Okamawari wrote:<br>
<blockquote type=cite class=cite cite>Hi all, <br>
<br>
I have a question about label allocation in RSVP-TE.<br>
When a label is drawn from a label space?<br>
On receipt of PATH or on receipt of RESV? (And reason why...)<br>
<br>
RFC3209, 4.1.1.1 says, <br>
&quot;If no label is available, the node sends a PathErr<br>
message ...&quot;<br>
Since PathErr is used to notify a failure of PATH message, <br>
this reminds me that a label is drawn from a label space<br>
on receipt of the PATH.<br>
<br>
On the other hand, Yakov Rekhter says in his book <br>
(MPLS technology and applications) that<br>
&quot;When an LSR wants to send a RESV message for a new RSVP flow,<br>
the LSR allocates a label from its pool of free labels, <br>
creates an entry in its LFIB with the incoming label set to <br>
the allocated label, and sends out the RESV message...&quot; (pp
153)<br>
(Does it mean PathErr is sent when RESV has failed?)<br>
<br>
Please let me know.<br>
<br>
Takao</blockquote></html>

--=====================_88385681==_.ALT--



From owner-mpls@UU.NET  Tue Jan 29 15:35:02 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20148
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 15:35:02 -0500 (EST)
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 QQlzyg19882;
	Tue, 29 Jan 2002 20:31:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzyg24802
	for mpls-outgoing; Tue, 29 Jan 2002 20:31: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 QQlzyg24797
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 29 Jan 2002 20:31:32 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 QQlzyg13428
	for <mpls@uu.net>; Tue, 29 Jan 2002 20:31:23 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f107.law15.hotmail.com [64.4.23.107])
	id QQlzyg25825
	for <mpls@uu.net>; Tue, 29 Jan 2002 20:31:23 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 29 Jan 2002 12:31:22 -0800
Received: from 66.122.42.231 by lw15fd.law15.hotmail.msn.com with HTTP;
	Tue, 29 Jan 2002 20:31:22 GMT
X-Originating-IP: [66.122.42.231]
From: "Mithra Vasudevan" <mithra_vasudevan@hotmail.com>
To: mpls@UU.NET
Subject: LDP with DOD support on Ethernet interface in Cisco
Date: Tue, 29 Jan 2002 20:31:22 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F107y6HYxNKZvEHAoD7000068ba@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2002 20:31:22.0736 (UTC) FILETIME=[EA805700:01C1A903]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello

Can some one clarify. thanks in advance.

1) Does Cisco IOS support LDP with Downstream on Demand mode
over Ethernet interfaces? Currently i observe it supports
LDP with DU mode. ( I use Cisco IOS 12.2<4> T in a 2611 Router)

2) Is it possible to configure LDP to operate with DOD
mode on Ethernet interfaces?

regards
mithra



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



From owner-mpls@UU.NET  Tue Jan 29 23:27:20 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00769
	for <mpls-archive@lists.ietf.org>; Tue, 29 Jan 2002 23:27:20 -0500 (EST)
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 QQlzzl05688;
	Wed, 30 Jan 2002 04:22:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlzzl12980
	for mpls-outgoing; Wed, 30 Jan 2002 04:20: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 QQlzzl12975
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 04:20:24 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 QQlzzl27745
	for <mpls@uu.net>; Wed, 30 Jan 2002 04:20:02 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzzl02442
	for <mpls@uu.net>; Wed, 30 Jan 2002 04:20:02 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA21446 for <mpls@uu.net>; Tue, 29 Jan 2002 23:20:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA13382 for mpls@uu.net; Tue, 29 Jan 2002 23:20:01 -0500 (EST)
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 QQlzzl12909
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 04:19:08 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 QQlzzl01274
	for <mpls@UU.NET>; Wed, 30 Jan 2002 04:18:46 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlzzl00704
	for <mpls@UU.NET>; Wed, 30 Jan 2002 04:18:45 GMT
Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA21409; Tue, 29 Jan 2002 23:18:45 -0500 (EST)
Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA05557; Tue, 29 Jan 2002 23:18:44 -0500 (EST)
Date: Tue, 29 Jan 2002 23:18:44 -0500
From: Eric Osborne <eosborne@cisco.com>
To: Mithra Vasudevan <mithra_vasudevan@hotmail.com>
Cc: mpls@UU.NET
Subject: Re: LDP with DOD support on Ethernet interface in Cisco
Message-ID: <20020129231844.N4391@eosborne-u10.cisco.com>
References: <F107y6HYxNKZvEHAoD7000068ba@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F107y6HYxNKZvEHAoD7000068ba@hotmail.com>; from mithra_vasudevan@hotmail.com on Tue, Jan 29, 2002 at 08:31:22PM +0000
X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C  4951 611E 1819 2E71 8562
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, Jan 29, 2002 at 08:31:22PM +0000, Mithra Vasudevan wrote:
> Hello
> 
> Can some one clarify. thanks in advance.
> 

This list is the wrong place to ask those questions; I'll answer off
line.




eric

> 1) Does Cisco IOS support LDP with Downstream on Demand mode
> over Ethernet interfaces? Currently i observe it supports
> LDP with DU mode. ( I use Cisco IOS 12.2<4> T in a 2611 Router)
> 
> 2) Is it possible to configure LDP to operate with DOD
> mode on Ethernet interfaces?
> 
> regards
> mithra
> 
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From owner-mpls@UU.NET  Wed Jan 30 09:36:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20357
	for <mpls-archive@lists.ietf.org>; Wed, 30 Jan 2002 09:36:23 -0500 (EST)
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 QQmaba03871;
	Wed, 30 Jan 2002 14:33:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaba19635
	for mpls-outgoing; Wed, 30 Jan 2002 14:33: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 QQmaba19630
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 14:33:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmaba10575
	for <mpls@uu.net>; Wed, 30 Jan 2002 14:31:39 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmaba04377
	for <mpls@uu.net>; Wed, 30 Jan 2002 14:31: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 JAA20147 for <mpls@uu.net>; Wed, 30 Jan 2002 09:31:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09963 for mpls@uu.net; Wed, 30 Jan 2002 09:31:38 -0500 (EST)
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 QQmaaf15708
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 09:20:55 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQmaaf19249
	for <mpls@UU.NET>; Wed, 30 Jan 2002 09:20:35 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe53.law11.hotmail.com [64.4.16.46])
	id QQmaaf11556
	for <mpls@UU.NET>; Wed, 30 Jan 2002 09:20:34 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 30 Jan 2002 01:20:33 -0800
X-Originating-IP: [132.146.249.186]
From: "Takao Okamawari" <takao_uk@hotmail.com>
To: <mpls@UU.NET>
References: <OE40NNLBIF5C6O5si2G0001668d@hotmail.com> <3C56C5CD.ED364F92@marconi.com>
Subject: Re: Label allocation in RSVP-TE
Date: Wed, 30 Jan 2002 09:17:12 -0000
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
Message-ID: <OE53TyfPefLJGWSa1aN00000551@hotmail.com>
X-OriginalArrivalTime: 30 Jan 2002 09:20:33.0829 (UTC) FILETIME=[5EB24550:01C1A96F]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi David and Sachin, 

Which is the correct answer with regard to the inbound label?

David Charlap wrote:
> > When a label is drawn from a label space?
> > On receipt of PATH or on receipt of RESV? (And reason why...)
> 
> The inbound label (which is sent upstream to the PHOP) may be produced
> at any time after receiving the Path message.  

Sachin Kalra wrote:
>
> Label is drawn from Label Space on receipt of RESV message. 

Takao




From owner-mpls@UU.NET  Wed Jan 30 09:38:02 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20442
	for <mpls-archive@lists.ietf.org>; Wed, 30 Jan 2002 09:38:02 -0500 (EST)
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 QQmaba05547;
	Wed, 30 Jan 2002 14:34:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaba19674
	for mpls-outgoing; Wed, 30 Jan 2002 14:34: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 QQmaba19665
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 14:34:03 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 QQmaba23164
	for <mpls@uu.net>; Wed, 30 Jan 2002 14:31:26 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmaba04058
	for <mpls@uu.net>; Wed, 30 Jan 2002 14:31:25 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 JAA20130 for <mpls@uu.net>; Wed, 30 Jan 2002 09:31:25 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09957 for mpls@uu.net; Wed, 30 Jan 2002 09:31:25 -0500 (EST)
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 QQlzyu15713
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 00:00:38 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlzyu20075
	for <mpls@UU.NET>; Wed, 30 Jan 2002 00:00:06 GMT
From: schultz@io.iol.unh.edu
Received: from iol.unh.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: io.iol.unh.edu [132.177.123.82])
	id QQlzyu02987
	for <mpls@UU.NET>; Wed, 30 Jan 2002 00:00:05 GMT
Received: from io.iol.unh.edu (IDENT:schultz@localhost.localdomain [127.0.0.1])
	by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g0U004Uj014241;
	Tue, 29 Jan 2002 19:00:04 -0500
Received: from localhost (schultz@localhost)
	by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g0U003TR014238;
	Tue, 29 Jan 2002 19:00:03 -0500
Date: Tue, 29 Jan 2002 19:00:03 -0500 (EST)
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Object Orders
In-Reply-To: <3C56C46D.C20506F9@marconi.com>
Message-ID: <Pine.LNX.4.43.0201291848450.13917-100000@io.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello David,

I agree with you in theory, but I can not find a reference to support the
following example:

> If you get an INTEGRITY object in the middle of the message, then you
> must reject the message.  If you get an ADSPEC before the SESSION
> object, then you should accept it.  It all depends on whether the
> ordering you receive is explicitly forbidden or not.
>
> Also, please re-read RFC 2205 more closely.  Object ordering violations
> do not result in the generation of a PathErr/ResvErr message.  The
> message is simply ignored if the order is invalid.

I apologize for not being more clear in my previous email.  RFCs 2205,
2961 and 3209 do not mention silently discarding or ignoring messages that
violate object order rules.  I am looking for a reference to support
the idea that a device should silently discard messages that violate
these rules.  Does anyone know of one?

Thanks,
-Ben

On Tue, 29 Jan 2002, David Charlap wrote:

> schultz@io.iol.unh.edu wrote:
> >
> > I have a question about the object orders.
> >
> > In RFC 2205, section 3.1 states:
> > An implementation should create messages with the objects in the
> > order shown here, but accept the objects in any permissible order.
>
> Please read the previous two sentences as well:
>
> 	The BNF implies an order for the objects in a message.
> 	However, in many (but not all) cases, object order makes no
> 	logical difference.
>
> Please note the "but not all" clause.  There are some places where
> object order is important.
>
> > In sections 3.1.3 and 3.1.4, the standard asserts that the INTEGRITY
> > object must immediately follow the common header.
>
> This is one of them.
>
> It's also the case that flow descriptors are illegal until after the
> STYLE object.
>
> There are also ordering rules regarding the objects within flow
> descriptors.
>
> > RFC 2961 also dictates strict ordering rules for the MESSAGE_ID
> > object.
>
> Yes.  When refresh reduction is used, MESSAGE_ID and ACK objects have
> ordering requirements.
>
> > However, RFC 3209 notes: "The ordering of these objects is not
> > important, so an implementation MUST be prepared to accept objects
> > in any order."
>
> You are reading individual sentences out of context and jumping to the
> completely wrong conclusion.
>
> The sentence immediately before the one you quoted says:
>
> 	The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST,
> 	and SESSION_ATTRIBUTE objects is simply a recommendation.
>
> The paragraph is saying that these three object classes do not have any
> particular ordering requirements.  It is not saying that you are free to
> discard the ordering requirements of all other objects that are
> specified in other drafts.
>
> > A strict interpretation of this statement would assume that if a
> > device disregards the object ordering rules, it can still
> > interoperate.
>
> Be liberal in what you accept.  Be conservative in what you send.
>
> If the object ordering you receive is not explicitly forbidden, then you
> should accept the message.  But when you generate your own outgoing
> message, you should order the objects according to the BNF in the RFC.
>
> > What is the correct behavior for the following situation:
> >
> > An LSR receives a Path or Resv message that violates the ordering
> > rules.  Does it accept the message and allow the LSP tunnel to form?
> > Or does it send an error message as recommended in Appendix B of
> > RFC 2205?
>
> Depends on what the "violation" is.
>
> If you get an INTEGRITY object in the middle of the message, then you
> must reject the message.  If you get an ADSPEC before the SESSION
> object, then you should accept it.  It all depends on whether the
> ordering you receive is explicitly forbidden or not.
>
> Also, please re-read RFC 2205 more closely.  Object ordering violations
> do not result in the generation of a PathErr/ResvErr message.  The
> message is simply ignored if the order is invalid.
>
> -- David
>



From owner-mpls@UU.NET  Wed Jan 30 10:10:36 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21603
	for <mpls-archive@lists.ietf.org>; Wed, 30 Jan 2002 10:10:36 -0500 (EST)
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 QQmabc23279;
	Wed, 30 Jan 2002 15:06:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmabc06535
	for mpls-outgoing; Wed, 30 Jan 2002 15:06: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 QQmabc06371
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 15:06:29 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 QQmabc06673
	for <mpls@UU.NET>; Wed, 30 Jan 2002 15:06:17 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 QQmabc20180
	for <mpls@UU.NET>; Wed, 30 Jan 2002 15:06:17 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 KAA27878
	for <mpls@UU.NET>; Wed, 30 Jan 2002 10:06:15 -0500 (EST)
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 KAA04185
	for <mpls@UU.NET>; Wed, 30 Jan 2002 10:06:16 -0500 (EST)
Message-ID: <3C580C55.EC9AD4D0@marconi.com>
Date: Wed, 30 Jan 2002 10:08:05 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Label allocation in RSVP-TE
References: <OE40NNLBIF5C6O5si2G0001668d@hotmail.com> <3C56C5CD.ED364F92@marconi.com> <OE53TyfPefLJGWSa1aN00000551@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Takao Okamawari wrote:
> David Charlap wrote:
>>>
>>> When a label is drawn from a label space?
>>> On receipt of PATH or on receipt of RESV? (And reason why...)
>>
>> The inbound label (which is sent upstream to the PHOP) may be
>> produced at any time after receiving the Path message.
> 
> Sachin Kalra wrote:
>>
>> Label is drawn from Label Space on receipt of RESV message.
> 
> Which is the correct answer with regard to the inbound label?

It doesn't matter.  You are the one generating the label.

It must be installed in your forwarding hardware before you complete
your Resv processing.  If you want to choose the label then, you may. 
If you would rather choose it during Path processing, that is also OK. 
This is an implementation detail and is not specified by the standard.

-- David


From owner-mpls@UU.NET  Wed Jan 30 10:24:59 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22249
	for <mpls-archive@lists.ietf.org>; Wed, 30 Jan 2002 10:24:59 -0500 (EST)
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 QQmabd12507;
	Wed, 30 Jan 2002 15:21:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmabd13870
	for mpls-outgoing; Wed, 30 Jan 2002 15:20: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 QQmabd13847
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 30 Jan 2002 15:19:52 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 QQmabd20966
	for <mpls@UU.NET>; Wed, 30 Jan 2002 15:19:23 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 QQmabd09532
	for <mpls@UU.NET>; Wed, 30 Jan 2002 15:19: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 KAA29551
	for <mpls@UU.NET>; Wed, 30 Jan 2002 10:19:21 -0500 (EST)
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 KAA08224
	for <mpls@UU.NET>; Wed, 30 Jan 2002 10:19:21 -0500 (EST)
Message-ID: <3C580F66.4F0CDE5@marconi.com>
Date: Wed, 30 Jan 2002 10:21:10 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Object Orders
References: <Pine.LNX.4.43.0201291848450.13917-100000@io.iol.unh.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

schultz@io.iol.unh.edu wrote:
> 
> I agree with you in theory, but I can not find a reference to
> support the following example:
> 
>> If you get an INTEGRITY object in the middle of the message, then
>> you must reject the message.  If you get an ADSPEC before the
>> SESSION object, then you should accept it.  It all depends on
>> whether the ordering you receive is explicitly forbidden or not.
>>
>> Also, please re-read RFC 2205 more closely.  Object ordering
>> violations do not result in the generation of a PathErr/ResvErr
>> message.  The message is simply ignored if the order is invalid.
> 
> I apologize for not being more clear in my previous email.  RFCs
> 2205, 2961 and 3209 do not mention silently discarding or ignoring
> messages that violate object order rules.  I am looking for a
> reference to support the idea that a device should silently discard
> messages that violate these rules.  Does anyone know of one?

Read Appendix B.  After the description of the last error code, it says:

	...
	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 eerrors 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:

	...
	o    Violation of required object order
	...

If a router is generating messages with the wrong object order, sending
it a PathErr is not going to make it start using the correct order. 
Therefore, there is no point to sending the error in the first place,
which is what Appendix B says.

-- David


From owner-mpls@UU.NET  Thu Jan 31 07:22:13 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24385
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 07:22:12 -0500 (EST)
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 QQmaej01728;
	Thu, 31 Jan 2002 12:21:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaej26986
	for mpls-outgoing; Thu, 31 Jan 2002 12:20: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 QQmaej26972
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 12: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 QQmaej28854
	for <mpls@UU.NET>; Thu, 31 Jan 2002 12:20:23 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQmaej00320
	for <mpls@UU.NET>; Thu, 31 Jan 2002 12:20:16 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <DVTSBLLL>; Thu, 31 Jan 2002 17:48:31 +0530
Message-ID: <9027F68B07E7D511AE9400B0D0787DC0062573@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: rsvp@ISI.EDU, mpls@UU.NET
Subject: Reserve Error : RFC 2205
Date: Thu, 31 Jan 2002 17:48:30 +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,

consider  this topology..

		(1)------(2)------(3)
		----> Path Message
		<---- Resv Message
		-----> ResvErr Message


If Node (2) receives ResvErr, then what should be the IP Address and LIH in
the RSVP-HOP object of the Message..

Regards,
Khuzema.


From owner-mpls@UU.NET  Thu Jan 31 08:43:17 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26062
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 08:43:17 -0500 (EST)
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 QQmaeo17792;
	Thu, 31 Jan 2002 13:42:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaeo23298
	for mpls-outgoing; Thu, 31 Jan 2002 13:42: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 QQmaeo23293
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 13:42: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 QQmaeo14846
	for <mpls@UU.NET>; Thu, 31 Jan 2002 13:41:06 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQmaeo25979
	for <mpls@UU.NET>; Thu, 31 Jan 2002 13:41:04 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <DVTSBL33>; Thu, 31 Jan 2002 19:09:29 +0530
Message-ID: <9027F68B07E7D511AE9400B0D0787DC0062574@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: rsvp@ISI.EDU, mpls@UU.NET
Subject: Reserve Error
Date: Thu, 31 Jan 2002 19:09:28 +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 RSVP, If Reserve Error contains some unknown class/ctype then should it
generate a Reserve Error for it .?

In general..should an error message generate another error message?


Regards,
Khuzema.


From owner-mpls@UU.NET  Thu Jan 31 09:31:59 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27658
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 09:31:59 -0500 (EST)
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 QQmaer14735;
	Thu, 31 Jan 2002 14:29:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaer17106
	for mpls-outgoing; Thu, 31 Jan 2002 14:29: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 QQmaer17101
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 14:29:32 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 QQmaer05117
	for <mpls@uu.net>; Thu, 31 Jan 2002 14:28:33 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmaer11040
	for <mpls@uu.net>; Thu, 31 Jan 2002 14:28: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 JAA12803 for <mpls@uu.net>; Thu, 31 Jan 2002 09:28:32 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA16534 for mpls@uu.net; Thu, 31 Jan 2002 09:28:32 -0500 (EST)
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 QQmaeq15773
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 14:13:14 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 QQmaeq29174
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:12:24 GMT
Received: from brahma.roc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.125.87.14])
	id QQmaeq23711
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:12:21 GMT
Received: from intotoinc.com (IDENT:root@machine100 [172.16.1.100])
	by brahma.roc.com (8.9.3/8.8.7) with ESMTP id TAA17673;
	Thu, 31 Jan 2002 19:47:39 +0530
Message-ID: <3C5950C7.96AD28B2@intotoinc.com>
Date: Thu, 31 Jan 2002 19:42:23 +0530
From: Kiran Kumar A <kiranka@intotoinc.com>
Reply-To: kiranka@intotoinc.com
Organization: INTOTO  Software (India) Pvt. Ltd.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
CC: rsvp@ISI.EDU, mpls@UU.NET
Subject: Re: Reserve Error : RFC 2205
References: <9027F68B07E7D511AE9400B0D0787DC0062573@mailserver.netbrahma.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi khuzema,
            I think RecvErr is b'coz of processing of Resv msg.
If (1) is generating ResvErr msg means that Resv msg received
by (1) has some errors. So in RSVP_HOP the IP destination address
should be the IP addr of (1) and LIH should be the incoming
interface of (1) on which it received Resv msg.

Pl correct me if I'm wrong...........




Khuzema Pithewan wrote:

> Hi,
>
> consider  this topology..
>
>                 (1)------(2)------(3)
>                 ----> Path Message
>                 <---- Resv Message
>                 -----> ResvErr Message
>
> If Node (2) receives ResvErr, then what should be the IP Address and LIH in
> the RSVP-HOP object of the Message..
>
> Regards,
> Khuzema.

--
ThanX N Regards,
Kiran



From owner-mpls@UU.NET  Thu Jan 31 09:58:27 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28414
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 09:58:27 -0500 (EST)
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 QQmaet26443;
	Thu, 31 Jan 2002 14:55:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaet19077
	for mpls-outgoing; Thu, 31 Jan 2002 14:55:03 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQmaet19066
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 14:54: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 QQmaet05613
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:53:36 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQmaet14355
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:53:34 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <DVTSBLQZ>; Thu, 31 Jan 2002 20:21:59 +0530
Message-ID: <9027F68B07E7D511AE9400B0D0787DC0062576@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>, kiranka@intotoinc.com
Cc: rsvp@ISI.EDU, mpls@UU.NET
Subject: RE: Reserve Error
Date: Thu, 31 Jan 2002 20:21:58 +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

RFC 2205 says...

"There are three possible ways that an RSVP implementation can treat an
object with unknown class.  This choice is      determined by the two
high-order bits of the Class-Num octet,as follows. 

 o    Class-Num = 0bbbbbbb
       The entire message should be rejected and an "Unknown Object Class"
error returned. "

does it also holds good for ResvErr/PathErr messages?

Khuzema.



> ----------
> From: 	Kiran Kumar A[SMTP:kiranka@intotoinc.com]
> Reply To: 	kiranka@intotoinc.com
> Sent: 	Thursday, January 31, 2002 8:17 PM
> To: 	Khuzema Pithewan
> Cc: 	rsvp@ISI.EDU; mpls@UU.NET
> Subject: 	Re: Reserve Error
> 
> Hi all,
>          I think if there is any error in
> RSVP Error messages then RSVP won't generate
> again an error message for them. It simply
> drops that messages.
> 
> Pl confirm this.
> 
> 
> Khuzema Pithewan wrote:
> 
> > Hi,
> >
> > In RSVP, If Reserve Error contains some unknown class/ctype then should
> it
> > generate a Reserve Error for it .?
> >
> > In general..should an error message generate another error message?
> >
> > Regards,
> > Khuzema.
> 
> --
> ThanX N Regards,
> Kiran.
> 


From owner-mpls@UU.NET  Thu Jan 31 10:20:45 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29228
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 10:20:44 -0500 (EST)
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 QQmaev27487;
	Thu, 31 Jan 2002 15:17:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaev11432
	for mpls-outgoing; Thu, 31 Jan 2002 15:17: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 QQmaev11421
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 15:17:15 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 QQmaev13389
	for <mpls@UU.NET>; Thu, 31 Jan 2002 15:16:06 GMT
Received: from brahma01.netbrahma.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQmaev27772
	for <mpls@UU.NET>; Thu, 31 Jan 2002 15:16:03 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <DVTSBLRQ>; Thu, 31 Jan 2002 20:44:29 +0530
Message-ID: <9027F68B07E7D511AE9400B0D0787DC0062577@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>,
        Kiran Kumar A
	 <kiranka@intotoinc.com>
Cc: rsvp@ISI.EDU, mpls@UU.NET
Subject: RE: Reserve Error
Date: Thu, 31 Jan 2002 20:44:28 +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

so u mean to say...there should be exception for generating unknown
class/ctype error for Error Messages.
if yes, then dont u think RFC should say it explicity?

Khuzema.

> ----------
> From: 	Kiran Kumar A[SMTP:kiranka@intotoinc.com]
> Sent: 	Thursday, January 31, 2002 8:33 PM
> To: 	Khuzema Pithewan
> Cc: 	rsvp@ISI.EDU; mpls@UU.NET
> Subject: 	Re: Reserve Error
> 
> Hi,
> 
>       My idea is
> if u r rejecting ResvErr msg and generating
> again an error msg for that then how come
> the receiver know that there was an error in
> his receive msg who has generated that
> Resv message.
> 
> 
> 
> ThanX N Regards,
> Kiran.
> 


From owner-mpls@UU.NET  Thu Jan 31 10:23:30 2002
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29337
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 10:23:29 -0500 (EST)
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 QQmael20055;
	Thu, 31 Jan 2002 12:53:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmael29452
	for mpls-outgoing; Thu, 31 Jan 2002 12:52:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQmael29447
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 12:52: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 QQmael18703
	for <mpls@UU.NET>; Thu, 31 Jan 2002 12:51:27 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 QQmael16533
	for <mpls@UU.NET>; Thu, 31 Jan 2002 12:51:26 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 HAA21130;
	Thu, 31 Jan 2002 07:49:00 -0500 (EST)
Subject: Re: Reserve Error : RFC 2205
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
Cc: mpls@UU.NET, rsvp@ISI.EDU
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF83E8C45A.857B1CA9-ON85256B52.0045B830@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 31 Jan 2002 07:48:38 -0500
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 01/31/2002 07:48:39 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,

The IP Address should the node's IP address which causes this ResvErr msg.
Here is the (3) IP address.
For the LIH, it can be got from the Path msg RSVP-HOP object sent from (2)
to (3).

Julia



                                                                                                              
                    Khuzema                                                                                   
                    Pithewan              To:     rsvp@ISI.EDU, mpls@UU.NET                                   
                    <KhuzemaP@netb        cc:     (bcc: Hong Liao/Telcordia)                                  
                    rahma.com>            Subject:     Reserve Error : RFC 2205                               
                                                                                                              
                    01/31/02 07:18                                                                            
                    AM                                                                                        
                                                                                                              
                                                                                                              





Hi,

consider  this topology..

          (1)------(2)------(3)
          ----> Path Message
          <---- Resv Message
          -----> ResvErr Message


If Node (2) receives ResvErr, then what should be the IP Address and LIH in
the RSVP-HOP object of the Message..

Regards,
Khuzema.





From owner-mpls@UU.NET  Thu Jan 31 11:15:17 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01477
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 11:15:17 -0500 (EST)
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 QQmaey13148;
	Thu, 31 Jan 2002 16:13:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaey05730
	for mpls-outgoing; Thu, 31 Jan 2002 16:13: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 QQmaey05725
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 16:13:21 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 QQmaey04508
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:12:38 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmaey16594
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:12: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 LAA25976 for <mpls@uu.net>; Thu, 31 Jan 2002 11:12:38 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22183 for mpls@uu.net; Thu, 31 Jan 2002 11:12:38 -0500 (EST)
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 QQmaet18706
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 14:48:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmaet19924
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:47:28 GMT
Received: from brahma.roc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.125.87.14])
	id QQmaet15796
	for <mpls@UU.NET>; Thu, 31 Jan 2002 14:47:25 GMT
Received: from intotoinc.com (IDENT:root@machine100 [172.16.1.100])
	by brahma.roc.com (8.9.3/8.8.7) with ESMTP id UAA18015;
	Thu, 31 Jan 2002 20:22:52 +0530
Message-ID: <3C595908.1248B616@intotoinc.com>
Date: Thu, 31 Jan 2002 20:17:36 +0530
From: Kiran Kumar A <kiranka@intotoinc.com>
Reply-To: kiranka@intotoinc.com
Organization: INTOTO  Software (India) Pvt. Ltd.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
CC: rsvp@ISI.EDU, mpls@UU.NET
Subject: Re: Reserve Error
References: <9027F68B07E7D511AE9400B0D0787DC0062574@mailserver.netbrahma.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,
         I think if there is any error in
RSVP Error messages then RSVP won't generate
again an error message for them. It simply
drops that messages.

Pl confirm this.


Khuzema Pithewan wrote:

> Hi,
>
> In RSVP, If Reserve Error contains some unknown class/ctype then should it
> generate a Reserve Error for it .?
>
> In general..should an error message generate another error message?
>
> Regards,
> Khuzema.

--
ThanX N Regards,
Kiran.



From owner-mpls@UU.NET  Thu Jan 31 11:17:33 2002
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01613
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 11:17:33 -0500 (EST)
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 QQmaey12362;
	Thu, 31 Jan 2002 16:13:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmaey05708
	for mpls-outgoing; Thu, 31 Jan 2002 16:13: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 QQmaey05698
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 16:13: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 QQmaey00718
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:12:47 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmaey16786
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:12: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 LAA25994 for <mpls@uu.net>; Thu, 31 Jan 2002 11:12:47 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22187 for mpls@uu.net; Thu, 31 Jan 2002 11:12:47 -0500 (EST)
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 QQmaeu00920
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 15:03:30 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 QQmaeu25941
	for <mpls@UU.NET>; Thu, 31 Jan 2002 15:03:12 GMT
Received: from brahma.roc.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.125.87.14])
	id QQmaeu09574
	for <mpls@UU.NET>; Thu, 31 Jan 2002 15:02:55 GMT
Received: from intotoinc.com (IDENT:root@machine100 [172.16.1.100])
	by brahma.roc.com (8.9.3/8.8.7) with ESMTP id UAA18096;
	Thu, 31 Jan 2002 20:38:20 +0530
Message-ID: <3C595CA7.F198C609@intotoinc.com>
Date: Thu, 31 Jan 2002 20:33:03 +0530
From: Kiran Kumar A <kiranka@intotoinc.com>
Organization: INTOTO  Software (India) Pvt. Ltd.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
CC: rsvp@ISI.EDU, mpls@UU.NET
Subject: Re: Reserve Error
References: <9027F68B07E7D511AE9400B0D0787DC0062576@mailserver.netbrahma.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

      My idea is
if u r rejecting ResvErr msg and generating
again an error msg for that then how come
the receiver know that there was an error in
his receive msg who has generated that
Resv message.



ThanX N Regards,
Kiran.



From owner-mpls@UU.NET  Thu Jan 31 12:00:42 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03289
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 12:00:41 -0500 (EST)
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 QQmafb27144;
	Thu, 31 Jan 2002 16:58:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmafb09360
	for mpls-outgoing; Thu, 31 Jan 2002 16:57: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 QQmafb09355
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 16:57:40 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQmafb02146
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:57:07 GMT
From: claus.bauer@tellabs.com
Received: from mx4.tellabs.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mx4.tellabs.com [204.68.180.54])
	id QQmafb25917
	for <mpls@uu.net>; Thu, 31 Jan 2002 16:57:07 GMT
Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101])
	by mx4.tellabs.com (Mirapoint)
	with ESMTP id ACG36897;
	Thu, 31 Jan 2002 10:56:59 -0600 (CST)
Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id KAA22132; Thu, 31 Jan 2002 10:57:00 -0600 (CST)
X-OpenMail-Hops: 1
Date: Thu, 31 Jan 2002 10:57:00 -0600
Message-Id: <H00006c4039817c5.1012496219.mailw02@MHS>
Subject: ietf-mpls-lsp-hierarchy
MIME-Version: 1.0
TO: kireeti@juniper.net, kireeti@juniper.net, mpls@UU.NET
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
	;Creation-Date="Thu, 31 Jan 2002 10:57:00 -0600"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello

a question on ietf-mpls-lsp-hierarchy. Consider an MPLS enabled IP 
network, where each LSR interface is assigned specific interface 
switching capability between PSC-1 and PSC-4. Technically, each LSR 
interface with PSC-n, can also provide PSC-m, n not equal to m. 
1. How is decided which PSC-n value is assigned to an LSR interface ?
2. If an LSP is setup between two LSR interfaces with PSC-n, would it 
not make sense to increase the PSC values to PSC-(n+1) to allow other 
LSPs to be tunneled via this LSP ?
3. The draft states in section 7.2 that the procedure in section 7.2 
applies to each LSR at the edge of a region. Why does it apply to an LSR 
at the end of a region ? I assume that the LSR at the end of a region 
will not originate any FA-LSP in flow direction.

Thanks,
Claus
 



From owner-mpls@UU.NET  Thu Jan 31 13:31:54 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07113
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 13:31:54 -0500 (EST)
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 QQmafh03779;
	Thu, 31 Jan 2002 18:29:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmafh26773
	for mpls-outgoing; Thu, 31 Jan 2002 18:29:16 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 QQmafh26767
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 18:29:07 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 QQmafh18982
	for <mpls@UU.NET>; Thu, 31 Jan 2002 18:28:17 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 QQmafh23561
	for <mpls@UU.NET>; Thu, 31 Jan 2002 18:28:17 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 NAA29516
	for <mpls@UU.NET>; Thu, 31 Jan 2002 13:28:15 -0500 (EST)
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 NAA02039
	for <mpls@UU.NET>; Thu, 31 Jan 2002 13:28:16 -0500 (EST)
Message-ID: <3C598D32.1293CD@marconi.com>
Date: Thu, 31 Jan 2002 13:30:10 -0500
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Reserve Error
References: <9027F68B07E7D511AE9400B0D0787DC0062576@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

Khuzema Pithewan wrote:
> 
> RFC 2205 says...
> 
> "There are three possible ways that an RSVP implementation can
> treat an object with unknown class.  This choice is determined by
> the two high-order bits of the Class-Num octet,as follows.
> 
>  o    Class-Num = 0bbbbbbb
>        The entire message should be rejected and an "Unknown Object
>        Class" error returned. "
> 
> does it also holds good for ResvErr/PathErr messages?

I don't think so.  What kind of error message would you send to indicate
an error in a PathErr/ResvErr message?

Should we now define PathErrErr and ResvErrErr.  What if there is a bad
object in one of those?  How far do you want to go before this becomes
silly?

-- David


From owner-mpls@UU.NET  Thu Jan 31 14:10:23 2002
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08449
	for <mpls-archive@lists.ietf.org>; Thu, 31 Jan 2002 14:10:23 -0500 (EST)
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 QQmafk28285;
	Thu, 31 Jan 2002 19:07:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQmafk12402
	for mpls-outgoing; Thu, 31 Jan 2002 19:07: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 QQmafk12336
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 19:07:03 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQmafk14830
	for <mpls@uu.net>; Thu, 31 Jan 2002 19:06:27 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQmafk13499
	for <mpls@uu.net>; Thu, 31 Jan 2002 19:06:26 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA21402 for <mpls@uu.net>; Thu, 31 Jan 2002 14:06:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01465 for mpls@uu.net; Thu, 31 Jan 2002 14:06:01 -0500 (EST)
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 QQmafk10731
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 31 Jan 2002 19:05: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 QQmafk10220
	for <mpls@UU.NET>; Thu, 31 Jan 2002 19:04:55 GMT
Received: from tnt.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: tnt.isi.edu [128.9.128.128])
	id QQmafk08223
	for <mpls@UU.NET>; Thu, 31 Jan 2002 19:04:54 GMT
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g0VJ4kg01491;
	Thu, 31 Jan 2002 11:04:46 -0800 (PST)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost)
	by gra.isi.edu (8.8.7/8.8.6) id TAA18974;
	Thu, 31 Jan 2002 19:04:46 GMT
Date: Thu, 31 Jan 2002 19:04:46 GMT
Message-Id: <200201311904.TAA18974@gra.isi.edu>
To: rsvp@ISI.EDU, mpls@UU.NET, KhuzemaP@netbrahma.com
Subject: Re: Reserve Error
X-Sun-Charset: US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


  *> From rsvp-owner@ISI.EDU  Thu Jan 31 05:44:17 2002
  *> From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
  *> To: rsvp@ISI.EDU, mpls@UU.NET
  *> Subject: Reserve Error
  *> Date: Thu, 31 Jan 2002 19:09:28 +0530
  *> MIME-Version: 1.0
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> Hi,
  *> 
  *> In RSVP, If Reserve Error contains some unknown class/ctype then should it
  *> generate a Reserve Error for it .?
  *> 
  *> In general..should an error message generate another error message?
  *> 
  *> 

I suspect that you knew the answer to that question before you
asked it.

Bob Braden

  *> Regards,
  *> Khuzema.
  *>